8 Guidelines for Monitoring Mainframe Security Controls per PCI DSS Requirements Payment Card Industry Security Standards Council on data security requirement #5: Protect all systems against malware and regularly update anti-virus software or programs okay got it, but what about my mainframe? When you fi rst read the Payment Card Industry Data Security Standard (PCI DSS) requirement #5 on anti-virus protection for all systems, was your initial thought what about my mainframe? Surely, the Security Standards Council is aware that mainframes are an integral component of enterprisesized networks across the globe, but perhaps they are not aware of the place mainframe computing holds in the credit-card processing chain: Mainframe is the platform of choice at 25 of the top 25 global banks. Mainframe is the platform of choice by 23 of the top 25 U.S. retailers. Mainframes are said to hold 70% of the most critical enterprise data, and IBM says 100% of all credit card transactions pass through a mainframe. At some point today, your data will come in contact with a mainframe. The fact of the matter is that PCI standards have, until recently, addressed distributed systems as this is where the money has been for cybercriminals and in most environments, the path of least resistance. There have been however, documented successful external mainframe breaches. The question then becomes how do you address your PCI DSS anti-virus requirements on your mainframe? Many vendors offer anti-virus programs that protect peripherals near the mainframe (fi rewalls, routers, VMs, etc.), but the generally-held belief is that mainframes are virus-free. We still however, have millions of credit card transactions going through mainframes daily and if you are going to conduct business where a credit card is involved, you are going to have to comply with the PCI DSS requirement that states you must maintain a vulnerability management program regardless of the operating system (PCI DSS Requirement #5). One little-known workaround that will act as a compensatory control for this particular requirement is File Integrity Monitoring (FIM), a function that essentially takes a snapshot of your healthy and secure OS fi le state, then monitors it periodically and reports when there is a change in its recorded secure state. This FIM process would also include the recording of any access attempts (even by authorized administrators) to fi les even if no fi les had been accessed or changed.
3 barriers for FIM on a mainframe FIM is well known and widely practiced in distributed environments but is much more diffi cult with a mainframe. First off, mainframe systems are generally siloed from the distributed systems that run Security Information & Event Management (SIEM) systems. SIEM systems are part of an enterprise security ecosystem that contains log fi le management, event log management, anti-virus, FIM, and other controls for maintaining a secure network perimeter. A second inhibitor for deploying a FIM process across mainframe environments is the language and personnel barrier. Distributed systems and security administrators (and compliance auditors) would struggle if they were offered access to a mainframe green screen then asked to unearth evidence of an internal breach or investigate if any mainframe system fi les had been accessed. Add to the fact that distributed system admins rarely even interact with mainframe system programmers and you start to get a picture of the silos prevalent in large enterprise networks. Thirdly, mainframe systems do not generally talk to these distributed SIEM systems in real time. Interactions mostly take place via nightly reports or programs scheduled to run when system resources are minimal. For a SIEM system to succeed, it needs live and up-to-the-second information that alerts an administrator (or help desk) to investigate a possible security violation or anti-virus threat. Years of siloed mainframe-versusdistributed computing existence have created two worlds of enterprise systems management mainframe people and mainframe technology in one world, distributed resources in the other. To further widen this gap, the mainframe people rarely communicate with the distributed people on things IT systems-related. If you are lucky enough to have programmers who can write some homegrown code that can convert mainframe log fi les (a.k.a. SMF records with specifi c code numbers) to a fi le type (RFC 3164 syslog, or the specialized syslog variants such as CEF and LEEF required by ArcSight and QRadar) that a SIEM system can read and use for threat detection, you are somewhat ahead of the curve. However, this homegrown code will most likely run with a batch of other programs every night. For security tracking and alerting purposes, by the time you are notifi ed of a potential breach or virus, several hours and possibly days, may have passed. 2 /
PCI DSS says maintain a secure network and systems but you will never have a secure network without a FIM policy for your mainframe with real-time data Let s face it, the mainframe is a strategic IT asset in nearly all of the world s largest banks and retailers. Mainframes are also an integral part of Healthcare and Government IT, as well as many government contractors that manufacture U.S. defense systems. The amount of payment card/personal data, medical records data and government intellectual property on mainframes today has to be a staggering number. The consequences of lost data from these systems should be of high concern to consumers and paramount to Government National Security. It seems almost hypocritical that we entrust mainframe systems to highly strategic and sensitive data, yet relegate them to the outer most reaches of network perimeter defense with security notifi cations that are hours, perhaps days old. For an enterprise SIEM system, even minutes to receive security notifi cations is too late depending on the remediation practice of the organization considering how long would it take to download a schematic for an F16 or surface-to-air missile or 10,000 credit card numbers. How much data could be siphoned off over the course of a few hours? Even if downloaded at low bandwidth so as to not alert performance monitoring systems (sometimes a component of SIEM systems to help detect threats) a hacker could conceivably download gigabytes of data over the course of a few hours. One only has to look no farther than the Target breach of 2013 for evidence of the importance of real-time event data from the SIEM system. In an event that took place during holiday shopping season the heaviest credit card processing time of the year 19 days went by before the retail giant took corrective action. The breach affected 110 million customers and forced the resignation of both the CIO and CEO. We can only wonder what would have happened had there been real-time FIM notifi cations or intrusion detection with immediate alerts from Target s SIEM system. One thing is for sure: The damage would have been substantially less had remediation taken place minutes after initial breach versus 19 days. The Target breach did originate from distributed P.O.S. systems, but the point here is that the policy for mainframe alerting should be no different from distributed system alerting. So what mainframe monitoring procedures can you put in place for PCI DSS in a distributed information security world? 3/ 3
8 guidelines for monitoring mainframe security controls as outlined by PCI DSS s Requirements and Security Assessment Procedures The PCI Security Standards Council offers best practices for implementing PCI DSS into business-as-usual activities for monitoring security controls. But as stated earlier, the PCI standard s original intended target appears to have been distributed systems. At the time the standard was developed (2004), mainframes for decades had been under lock and key and because they resided in a different world of users, they were not generally included alongside distributed systems, in spite of the proliferation of the IT security vendor landscape. But the mainframe has remained a workhorse within large enterprise datacenters and a high percentage of identity, banking and highly classifi ed government data is accessed on mainframes through distributed and web-based operating systems. The threat potential is there. The 2014 Verizon Data Breach Investigations Report reveals nearly 12,000 incidents related to insider misuse with 88 percent of those incidents attributed to privilege abuse. Clearly, in a large enterprise s IT ecosystem (employees, contractors, partners, etc.), there are many resources with hands-on access to some highly-valuable and extremely sensitive data. For effective enterprise SIEM, the inclusion of mainframe log data is without question. However, because of the two different worlds of IT (distributed vs. mainframe), very few organizations are capable of including live, real-time mainframe log data into their SIEM system. The gap between the two worlds must be narrowed to reduce the probability of breach to systems tethered to our bank accounts and data stores linked to national security. Below are 8 guidelines for monitoring mainframe security controls to narrow the gap between the 2 worlds of IT to bring the mainframe closer to the defense perimeter as an integral part of an enterprise SIEM strategy. These guidelines focus on basic mainframe File Integrity Monitoring controls that facilitate the anti-virus clause in version 3.0 of PCI DSS, as well as established best-practices for polling live mainframe data for inclusion into a SIEM where further correlation and analysis can be conducted for threat detection. 1. From your SIEM, monitor user access to fi les on your mainframe. The list of available, distributed SIEM systems that are able to monitor IBM z/os fi les is very small, especially where you require them to issue real time alerts of suspicious mainframe activities. However, you can tell RACF (IBM s Resource Access Control Facility, similar to Microsoft s Active Directory) to give you the ID and level of privilege a user has that has just accessed an operating system or other sensitive fi le on a mainframe. But you must. 4 /
2. Monitor the mainframe user activity in real time. Receiving a notifi cation at midnight (as in the mainframe nightly reports example earlier) that a user copied a fi le they had no business accessing eight hours earlier is not real-time SIEM. Monitoring is one step. But next you must 3. Take the real-time log data (in IBM z/os, these are SMF records) and port them into your SIEM, but it must be in a format that your SIEM can read (industry standard is RFC 3164 syslog type and includes CEF and LEEF types as stated above). Then store the newly-converted syslogs (there may be millions of them) to compliance standards and correlate them for potential malicious user behavior. You must be sure however to 4. Know which IBM z/os SMF records have the most meaning for security event correlation. Just as you do not need to correlate all distributed log data just the most meaningful you also do not need to collect all mainframe SMF events. Below is an example of just a few SMF Record Types you will want to consider for inclusion into your SIEM system: a. SMF 15 record = a dataset was written b. SMF 18 record = a dataset has been renamed c. SMF 80 record = all IBM RACF and CA Top Secret security data including event type, user ID, terminal name, etc. d. SMF 100, 101 & 102 records = all things DB2 related, critical for PCI DSS compliance e. SMF 119 record = TCP/IP or FTP activity Note: CorreLog SIEM Agent for z/os has a large volume of SMF record types it will convert for SIEM systems, and includes certifi ed integration for IBM QRadar and HP ArcSight. More information on the SIEM Agent for z/os can be found on correlog.com. 5. Implement compliance scorecards you can fl ag your SIEM system to report on messages of specifi c type that have PCI DSS implications. For instance, PCI DSS requirement #6 centers on maintaining secure systems and applications. Your SIEM system can be set up to correlate user activity related to systems that hold credit card data and report their access on the scorecard. Any activity that looks suspicious can be immediately logged into a help-desk system and investigated. These messages can also be indexed and archived for forensics in the event of a breach. 6. Your scorecard can also track access to cardholder data by business need-to-know (PCI DSS Requirement #7). When a privileged user accesses a credit card data store, your SIEM should log that activity. / 5
7. PCI DSS Requirement #9 deals with restricting physical access to the data (the fi le store must be off-site). This obviously means at some point, remote access to the data by privileged users will occur. Your SIEM needs to have an encryption policy for data at rest and in-transit, and again, you need to have a record of the transmission as part of your log management strategy. 8. Centralize your data and index it. Aggregating log data in a central location is a critical timeand money-saver. When we talk to customers about life after implementation most say the aggregation of log data has been one of the most signifi cant differences in terms of time saved a single instance of the log data. What used to take multiple resources many hours sometimes days across multiple databases to fi nd is now found by one resource using a single SIEM system. Much of PCI DSS is obvious to see, however... Many PCI DSS requirements are obvious assign a unique ID to each user, regularly update anti-virus software, change the vendor defaults for passwords things that make common sense to those of us outside looking in. In reality however, things are not always so black-and-white. We live in the age of doing more IT work with far less resource and perhaps the vulnerable enterprise hasn t had the chance to fi x the obvious to comply with PCI DSS requirements. What will help is implementing a proactive SIEM system that will log activity and alert a system admin or initiate a help-desk ticket when a potential issue arises. Nineteen days went by before Target took action on a breach that affected 110 million customers and cost the careers of the company s CEO and CIO. Paying attention to just a few of the PCI DSS requirements and incorporating a simple scorecard into the SIEM system would have prevented much of the data exposure and nearly irreversible damage to the retailer s brand. Did you have this conversation shortly after the Target Breach? 6 /
This breach, now behind us, is but a year old. Yet in the eyes of global media and the immediacy of the Internet, it has mostly been forgotten by mainstream media, replaced by fresher retail and banking breaches, and even a Government agency or two. For the Retail Industry battling the cyber onslaught, the breaches making news headlines are part inspiration part fuel to the fi re to right the defi ciencies of lagging SIEM strategies and indifference to PCI DSS requirements. One thing is for certain: cyber-criminals will continue to attack the path of least resistance. The question you have to ask of your business is this: How diffi cult will it be to steal my data today? If you have a PCI DSS strategy in place and are following some hopefully all of the guidelines above, chances are excellent hackers will bypass your network and fi nd lower-hanging fruit. If not, prepare to be a news headline, much like a recent CEO/CIO pair were not too long ago. The CorreLog SIEM Agent for IBM converts z/os security events in real time to distributed syslog format and delivers them directly to SIEM systems such as IBM QRadar (certifi ed), HP ArcSight (certifi ed) Splunk, McAfee ESM and the CorreLog Correlation Server. CorreLog dbdefender for DB2 provides database activity monitoring (DAM) for the secure state of DB2. Certifi ed for LEEF / 7
About CorreLog, Inc. CorreLog, Inc. is the leading independent software vendor (ISV) for IT security log management and event correlation spanning both distributed and mainframe platforms. CorreLog s fl agship products are CorreLog Correlation Server, CorreLog SIEM Agent for z/os, CorreLog Visualizer for z/os, and CorreLog dbdefender for DB2. CorreLog Server leverages its unique correlation engine that manages user/system event logs through Syslog, Syslog-NG, and SNMP protocols. SIEM Agent for z/os converts mainframe SMF data to distributed syslog format for real-time transmission to security information and event management (SIEM) systems. Visualizer for z/os provides live z/os dashboard data within CorreLog Server. dbdefender provides real-time DB2 data to SIEM systems for real-time, with enhanced visibility to the secure state of DB2. For auditing and forensics, CorreLog solutions facilitate regulatory requirements set forth by PCI DSS, HIPAA, Sarbanes-Oxley, IRS Pub. 1075, GLBA, FISMA, NERC, and many other standards. CorreLog markets its solutions through both direct sales channels and indirect partner channels. For more information on CorreLog products, please visit http:///library. CorreLog SIEM Server 1004 Collier Center Way, 1st Floor Naples, Florida 34110 1-877-CorreLog / +1-239-514-3331 info@correlog.com CorreLog 2014. All rights reserved.