Every day, after you get your first cup of coffee, do you scan the mainframe security system violation and logging reports looking for abnormal behavior, strange activity, etc.? Given the size of these, do you do a thorough job of it? How much time has elapsed from the time any activity occurred to the time you got to this?
When I first developed these reports for ACF2 (dataset and resource) we had systems that ran at a rate of a few MIPS – maybe 10-20. The current IBM z13™ will process 110,000 MIPS. The volume of processing has grown exponentially and so has the volume of security incidents – either loggings or violations – produced each day. Remember that the violations and loggings are there to highlight activity which may affect sensitive data – either the organization’s sensitive data or the z/OS system itself – for, if the z/OS system is modified illicitly, this may be the vehicle for actually accessing or modifying sensitive data by bypassing the z/OS security system controls. In case you didn’t realize this – if someone can modify the z/OS system and libraries by doing something as simple as link editing a program with the Authorized Program attribute and storing it in an Authorized Library, they can then execute that program and utilize that authorization with relatively simple code to bypass whatever controls you have in place in ACF2, RACF or Top Secret.
We have to utilize mechanisms that will not only highlight the incidents we should be concerned about, but, also in a timely manner, notify the correct personnel that there may be an issue that has to be dealt with.
Remember, the insider threat is composed of two different attack vectors. Of course, we all think about the insider who goes rogue for one reason or another and uses his or her authority to perpetrate the crime. But, there is also the outside hacker who obtains an insider identity and leverages that for the crime. This is how the Swedish Government system, which was hosted by the Logica service provider, was attacked. The 3270 connections were not encrypted and Per Gottfried Svartholm Warg obtained a Userid and Password which he used to obtain access to Logica. One scary piece of information about this attack was that the system did not notice it and raise an alarm. It was a sharp Computer Operator at Logica who noticed unusual activity and notified the appropriate personnel.
There are two issues here: First is the level of criticality of the data being accessed – is it sensitive production data or a sensitive transaction? Or critical z/OS libraries and data?
The second issue is the concern over the access itself and the correlation of all the data that is available from multiple sources to make the presentation more easily understandable and actionable. For instance, if the access or update was initiated from a desk in an organization’s secure building (this is probably OK), from an address in one of the nearby suburbs (probably someone working from home – but a little higher on the concern level), or from a different city (maybe someone traveling, but should be checked into) or from a different country, like China (definitely a level of concern). The SIEM products have the capability of correlating all the events, including the mainframe data if there is a mainframe agent, and presenting them in an understandable and actionable format.
SIEM Process for Mainframe
The mainframe security logs do not display this location information and it is a critical piece in determining the level of concern. Also, the fact that the security reports are usually run overnight and not looked at until the next morning means that the incidents that are of a higher level of concern are not addressed in an appropriate timeframe or at all, especially if the reports are hundreds of pages long.
When we installed ACF2 at our first customer in May 1978, the Pontiac Motor Division of General Motors, the Security Officer, Gerry Lyons, looked at the first reports and said: “That’s Jack upstairs. He’s looking at the dataset containing our radio inventory because he’s trying to optimize the model-year build out of our cars based upon our inventory. You can’t put an inexpensive radio in an expensive car nor an expensive radio in an inexpensive car.” Gerry knew all the users, he knew all the data and the business functions being performed. Now, with the size of today’s user community and the volume of data, this is virtually impossible.
Enter the Security Information & Event Management (SIEM) products and, in particular, the ones that have z/OS mainframe agents, which can dynamically filter the incidents (observed via the SMF record recordings, system log recordings, direct calls to their Application Program Interface, etc.) of potential value and transmit them immediately to the SIEM. At the SIEM system, these incidents, which are identified by the z/OS Terminal Name, can be correlated with the initiating IP address, giving the location and information and, if it seems to be a potentially critical event, a text message or e-mail can be sent to the Security Officer(s) and an incident opened to assure follow-up.
The best product I’ve seen is this area is the Correlog SIEM or its Mainframe Visualizer, combined with its Mainframe Agent for z/OS. It works with virtually all the other SIEM products (having specifically been certified for IBM’s QRadar and HP’s ArcSight and integrated with Splunk), sending messages directly in their native formats that do not require another translation step. But the combination of Correlog’s Mainframe Agent for z/OS and either its SIEM or Visualizer product returns the most valued results. This product set has the capability of recognizing and highlighting the security incidents that are the most concerning and notifying security personnel immediately. Then, the security personnel can make a few phone calls and either identify the events as not being of concern or begin blocking access to the mainframe systems for this user.
The mainframe systems report just the terminal name. In order to dynamically translate the terminal name to an IP address, which then can be used for location information, a SIEM product that can associate the original connection information with the event information is required, making something that is more readily understood and actionable. The SIEM products can then make the translation from IP address to location instantly and thus make it easy for the Security Officer to comprehend what is happening and the risk level.
One of the great features of the Correlog product is the ability to define groups of datasets, such as APF, system, sensitive production, etc. and then, when an incident is detected, take different actions and notifications based upon the kind of sensitive data it is, whether the action was allowed or whether the security system blocked it. The Correlog Agent for z/OS also processes DB2 Events, audited CICS transactions and many other z/OS events. The action could be an SMS message or an e-mail and it can send a message to the help desk to open a ticket for the security operations staff to follow up on. Similarly, specific console messages can be analyzed for incident follow up, such as application-specific messages that provide data not available from SMF, which could invoke notifications to the production support personnel.
Another area of concern is the use of the TSO capability IND$FILE, which transfers data from a z/OS dataset to the user’s PC and the use of the FTP protocol. Just because a user has read access to the data, this does not imply that he should be able to download it to his PC and then, possibly, distribute it all over the world. Correlog now has the ability to monitor these activities and notify the correct security personnel.
Most Exfiltration Takes Place Long Before You Find Out About It.
Too often, security incidents go unrecognized and it is weeks or months later when they come to light. IBM has stated that the average time to realize a breach has occurred is 205 days and usually it is a client or the FBI who notices it. We have to make a concerted effort to recognize these critical events and take the appropriate action in a very short period of time to protect our mainframe systems. The only way to accomplish this with the volume of loggings and violations on z/OS systems is via a mechanism which will identify the potentially significant ones, correlate that to a location and notify the appropriate security personnel. The Correlog SIEM Agent for z/OS and the Correlog Visualizer for z/OS provide this capability for z/OS systems.