Security systems must provide support for routine security administrator or help desk tasks: Password reset calls to security administrators or help desks are costly. Security systems must provide an interactive, secure password reset capability.
Relational databases are normally used for reporting but the current products don’t directly support them: Current security systems recommend that control and event data be unloaded from their proprietary file formats and SMF and then reloaded into a relational database for reporting. Then, these databases can be used for reporting. The benefits of using relational databases can be vast, especially if users and events are categorized by security category (e.g., HIPAA, SOX, etc. and level of importance (e.g., critical, important, etc.). Then, simple SQL or a multitude of reporting tools can be used to extract and report on what’s been happening in the enterprise’s security. The often unrecognized advantage of using a relational database is that the mainframe database packages support Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) access. So, from a server or even the security officer’s PC, the database can be interactively interrogated to extract the information needed.
An example might be a security officer who notices a violation attempt by an individual against sensitive data. The interactive capability provided by server or PC access would easily allow the security officer to, with a few mouse clicks, inquire about all the access violations and loggings generated by that individual over the last week. If this is significant, the interactive report could easily be packaged into an Adobe Acrobat PDF file and attached to an email sent by the security officer to the individual’s supervisor, asking for an explanation. This process is so easy to do via the supporting server or PC, and so powerful that all security systems should be providing this capability.
Unfortunately, using the current system’s unload and reload process means the data is almost immediately out-of-date. Security systems must either use the relational database as their primary data store or find a mechanism to keep a relational database in synch with its proprietary database and generated SMF event records.
Mainframe-style security controls must be extended to the enterprise: It’s not unusual for the mainframe to be a part of a complex with thousands of Linux, Unix or Windows servers. Although analysts say that about 75 percent of critical business data still resides on the mainframe, a significant amount of access to that data is via these distributed servers. A mechanism must be created to administer security as a single or small number of images using similar or, better yet, the same concepts and controls.
Some large organizations are moving their distributed security administration under their mainframe security organizations because mainframes have had unsurpassed security implementations for decades and mainframe security officers fully understand the controls necessary from an organizational perspective. However, the mainframe- style security controls aren’t available on the distributed servers, so these organizations lack the tools they’re familiar with and which have worked successfully for them.
This situation isn’t dissimilar to what existed 25 years ago, before IBM’s implementation of the centralized External Security Manager. Each delivery system had its own security system and database. There was no consistency in security, there were a multitude of different security definitions and databases, and it was difficult to even understand what the overall security was. The implementation of the External Security Manager provided the capability for a single security image. Something similar is needed for today’s enterprise collection of both mainframes and many other servers. Of course, since this situation involves multiple systems, any solution has to take into account data caching to reduce network requirements and improve response time and provide for database redundancy and failover.
So, even though the mainframe security systems have worked well over the last 25 years, there are issues facing today’s security officers that have been brought on by the:
- Massive increase in the size of today’s systems
- Size of the distributed, non-mainframe, security environment
- Departure of the people who knew the system well and understood the security systems
- Influx of new people who really did not grow up in the mainframe environment.
There’s still much to be done to keep mainframes, and the rest of the enterprise, as secure as they were 25 years ago. Security officers will continue to have a great challenge to keep everything in control. Z