October 26, 2009 PCI X-Ray: File Integrity Monitoring. by John Kindervag for Security & Risk Professionals. Making Leaders Successful Every Day

October 26, 2009 by John Kindervag for Security & Risk Professionals Making Leaders Successful Every Day

October 26, 2009 This is the seventh document in the PCI X-Ray series. by John Kindervag with Robert Whiteley and Margaret Ryan Executive Summary To effectively deal with the broad and complex requirements of Payment Card Industry (PCI) data security, you need to break the elements apart to provide enhanced clarity. We ve designed the PCI X-Ray series to provide actionable information to help Forrester Research clients become PCIcompliant. This document deals with file integrity monitoring (FIM) for PCI, while providing practical technical guidance to help ensure PCI compliance before your auditor shows up to develop the Report on Compliance (ROC). table of Contents 2 Forrester s PCI X-Ray Series 2 Don t Be A Statistic: FIM Helps Detect Attackers Using Custom Malware 4 What The PCI DSS Says About File Integrity Monitoring File Integrity Monitoring Is A Function, Not A Product Define: FIM Is Designed To Alert You To Unauthorized Changes Diagnose: How Would You Know If An Attacker Had Installed Malicious Software? Treat: Deploying FIM Is Critical In Today s Threat Environment Follow Up: Diligence Is Demanded By This Ever-Changing Threat Environment recommendations 9 File Integrity Monitoring Is A Critical Last Line Of Defense NOTES & RESOURCES In developing this report, Forrester drew from a wealth of analyst experience, insight, and research through advisory and inquiry discussions with end users, vendors, and regulators across industry sectors. Related Research Documents PCI X-Ray: Network Segmentation July 17, 2009 PCI X-Ray: IDS And IPS April 8, 2009 PCI X-Ray: Firewalls February 13, 2009 PCI X-Ray: What s New in 1.2? January 30, 2009 PCI X-Ray: Log Management October 20, 2008 PCI X-Ray: Wireless Security October 1, 2008 Confessions Of A QSA: The Inside Story Of PCI Compliance September 11, 2008 2009, Forrester Research, Inc. All rights reserved. Unauthorized reproduction is strictly prohibited. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. Forrester, Technographics, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. To purchase reprints of this document, please email clientsupport@forrester.com. For additional information, go to www.forrester.com.

2 Forrester s PCI X-ray series This is the seventh in a series of reports that deal with specific requirements of the PCI DSS. They are designed to provide security and risk professionals with guidance and transparency within the PCI arena, allowing each part of the standard to be fully revealed. Just as an x-ray can see beneath the skin to the underlying details of a medical issue, the PCI X-Ray series exposes PCI to the light. This series focuses on the individual elements of PCI to facilitate the compliance process. This PCI X-Ray is composed of two parts an overview to provide a general summary of a specific part of PCI and a reference architecture diagram that provides a visual representation about the issues raised. By dissecting PCI into its component pieces, we will make PCI more understandable and provide you with enhanced knowledge and insight into creating a compliant credit card environment. To simplify PCI compliance, these X-Rays facilitate four proactive steps: Define. Just as each disease must be defined to be understood, this series will define the parts of PCI in an understandable way to make PCI flow into the organization. Diagnose. Once diseases have been defined and documented, physicians can look at a patient and diagnose the disease. PCI is similar in that you can t find a problem without understanding it first; only then can you look at the cardholder environment, see where the problems are, and decide what needs to be fixed. Treat. When the disease is finally diagnosed, treatment can begin. A doctor doesn t just indiscriminately inject medicines into a patient without a plan. PCI practitioners should use the diagnosis to define a treatment regimen that will effectively eliminate the problem. Follow up. Medical professionals are very aware that a disease thought to be cured can often recur without warning. In the PCI world, the practitioner must remain diligent to ensure that each element within the PCI environment remains in compliance. New devices or applications, configuration changes, and industry developments can all conspire to take the network out of compliance. Regular checkups are encouraged. Don t Be a Statistic: FIM helps detect Attackers using custom malware With the recent and highly publicized credit card breaches of companies such as Hannaford Supermarkets and Heartland Payment Systems, the perils of custom malware have come to light. As attackers become increasingly sophisticated, diligence and agility are the keys to staying ahead of threats. In an effort to bypass widely deployed controls such as antivirus, cybercriminals are creating customized software for individual targets. As a result, we see three prevailing trends. Specifically, hackers are: Bypassing basic antimalware controls successfully. Because this type of malware is so individualized, it has not been seen by malware vendors. Antimalware still relies heavily on October 26, 2009 2009, Forrester Research, Inc. Reproduction Prohibited

3 signatures of known viruses, worms, and Trojans to be effective. By using custom-developed software, attackers increase the likelihood of a successful implementation. Stealing credit card data without enterprise detection. The result of this type of bespoke malware has been a spectacular series of credit card breaches. Because cybercriminals go to extreme efforts to ensure that their cooked-to-order code does not look malicious, it can be very difficult to detect. Getting detected, if at all, by back-end monitoring from credit card companies. Card brands often discover breaches by triangulating fraud using a technique known as Common Point of Purchase (CPP). 1 For example, it was the card brands that first notified Heartland Payments Systems that it had been breached. 2 The risk of suffering a breach from this type of attack vector can be reduced by deploying file integrity monitoring (FIM) tools within the cardholder data network (CHDN) to provide immediate alerts if unauthorized software, such as custom malware, is being deployed. Should traditional antimalware solutions fail to discover this covert malware, properly configured FIM tools will alert you of an unauthorized installation of software (see Figure 1). Figure 1 Anatomy Of A Custom Malware Attack 4 1 6 HSM 3 2 5 Merchant Vulnerable server Credit card database 1. Hacker exploits a vulnerable server and installs custom-built stealth sniffer. 2. Custom malware is not seen by antivirus software. Sniffer fires up. 3. Store sends credit card information for processing to credit card switch. 4. Credit card switch transfers credit card information to processor. 5. Malware sniffs traffic destined for HSM (encryption appliance). 6. Hacker receives packet captures from malware and retrieves credit card information. 53859 Source: Forrester Research, Inc. 2009, Forrester Research, Inc. Reproduction Prohibited October 26, 2009

4 What the PCI DSS says about File Integrity Monitoring The PCI DSS specifies FIM primarily in Requirement 11.5: Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. Other requirements in the PCI DSS discuss how to monitor FIM tools and mandate inclusion of FIM alerts into policy. The intent of Requirement 11.5 is to provide organizations with a last line of defense against the exploitation of critical resources within the CHDN, primarily servers. By deploying FIM solutions, organizations gain the ability to catch the installation of malware in the act and prevent an embarrassing and costly data breach. File Integrity Monitoring Is A Function, Not A Product The PCI DSS calls for the deployment of file-integrity monitoring software. While single-purpose FIM software exists and can meet this compliance obligation, there are other tools that may meet the intent of 11.5 in your organization. For example, we ve seen compliant organizations use: Log management and SIM solutions. Many log management solutions use agents on servers to collect server logs and meet the logging requirements specified in Requirement 10. 3 These agents often have the ability to provide change detection and FIM capabilities. The upside here is that these agents will then automatically pull this data into the log or security information management (SIM) tool, which is specified in Requirement 10.6. 4 Configuration and patch management tools. Many organizations use automated tools to provide configuration and patch management capabilities on an enterprisewide basis. These types of tools may have FIM built in, although it is often not publicized by the vendor. Host IPS and whitelisting software. It s common for companies to deploy host IPS (HIPS) or whitelisting software to critical servers. By definition, this type of software functions as a FIM tool in that it will not allow unauthorized software to be deployed. Using these tools for FIM is an excellent way to leverage existing security investments to meet PCI compliance obligations. Define: FIM Is Designed To Alert You To Unauthorized Changes To increase the security on your CHDN resources, FIM should be deployed where possible to protect your servers from unauthorized changes, especially the installation of illicit and potentially malicious software (see Figure 2). There are three fundamental metrics tracked by FIM: October 26, 2009 2009, Forrester Research, Inc. Reproduction Prohibited

5 Figure 2 PCI X-Ray File Integrity Monitoring Checklist: Defining PCI Compliance PCI requirement 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6. 11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider). 12.9.5 Include alerts from intrusiondetection, intrusion-prevention, and fileintegrity monitoring systems. Define This requirement ensures that the logs specified in Requirement 10 are not changeable. Logs are used for alerting and forensic investigations and must, therefore, be accurate. Because Requirement 12.9.5 specifies that by policy, file integrity monitoring is grouped together with IDS and IPS solutions, it is a best practice that FIM tools be sent to the log server and reviewed daily. File integrity monitoring tools should be deployed on resources, typically servers, within the cardholder data network to monitor various files for unauthorized changes. The intent is to provide an alerting mechanism if files are changed by malicious insiders or outsiders. Incident response policy must include a provision to monitor and respond to alerts from FIM tools. 53859 Source: Forrester Research, Inc. Policy: Does the proposed system change fall within written policy? This policy must also be compliant with the PCI DSS. Any out-of-policy changes should trigger an alert and be denied, if possible. Authorization: Is the proposed system change authorized? Answering this question may require information from your help desk or change management systems. Alerts from FIM must tie into a global view of the proposed change so that it can be stopped or investigated if needed, although purpose-built FIM software may have integrated this functionality into 2009, Forrester Research, Inc. Reproduction Prohibited October 26, 2009

6 its management console. Additionally, some tools with FIM functionality such as HIPS or whitelisting software may, by default, deny changes that have not been pre-authorized. Compliance: Is the proposed change compliant with PCI or other compliance obligations? You ll need to deploy a system capable of cross-referencing PCI and other compliance initiatives to automatically determine if a proposed state change is compliant. This may be built into the FIM tool or may require feeding FIM data into a SIM or governance, risk, and compliance (GRC) tool. FIM allows enterprises to track deviations from their golden image. This is the initial, approved software build that has been approved for deployment within an organization. By using FIM, you will always be able to know the state of the deployed software and be able to ensure that it is compliant with PCI at all times. Should an unauthorized attempt to deviate from this compliant state be made, the organization can quickly identify the attempt and remediate against it. Diagnose: How Would You Know If An Attacker Had Installed Malicious Software? The landmark Heartland Payment Systems breach begs the question, Would you know if custom malware had been installed in your organization? (see Figure 3). According to the Department of Justice indictment of the Heartland hacker Albert Gonzalez: On or about November 6, 2007, GONZALEZ transferred a computer file to the Ukrainian Server named injector.exe that matched malware placed on both Heartland and Company A s servers during the hacks of those companies. 5 Based on information from Heartland Payment, it was not aware of the breach until the week of January 12, 2009. 6 Heartland Payment was in a breach condition for at least 18 months and did not discover the breach on its own. This underscores the criticality of FIM tools deployed within the CHDN. Treat: Deploying FIM Is Critical In Today s Threat Environment Since PCI requires FIM deployment, companies falling under PCI have no choice but to comply and install some type of solution to ensure the integrity of their CHDN resources (see Figure 4). Unfortunately, many companies don t understand FIM and think that this functionality is built into their antivirus (AV) software. Avoid the most common pitfalls of: Overreacting and replacing your AV vendor. When a client is hit with a custom software attack, their first reaction is to be angry with their antivirus provider. Forrester recently spoke with an organization that suffered this type of malware attack. They reacted predictably, blaming their AV vendor and threatening to replace that vendor s software with a competitor s. They gave the offending malware to the AV vendor and were shocked that the vendor had not seen that particular strain of malware before this attack. Custom malware writers are often subscribers to October 26, 2009 2009, Forrester Research, Inc. Reproduction Prohibited

7 many AV vendors solutions so they can test their malware against known antimalware agents. FIM is frequently the only way to detect this type of sophisticated attack. Failing to look at currently deployed technologies to see if they support FIM. Companies without any type of FIM capability should immediately deploy a PCI compliant FIM tool. If you re unsure if you have FIM capability in your environment, you should inventory any control that may potentially have this function, such as patch management or configuration management systems, and check with the vendor to see if the existing solution can support FIM for PCI. If so, make certain this feature is enabled and configured to meet all of the PCI requirements regarding FIM for PCI. Figure 3 PCI X-Ray File Integrity Monitoring Checklist: Diagnosing PCI Compliance PCI requirement 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6. 11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider). 12.9.5 Include alerts from intrusiondetection, intrusion-prevention, and fileintegrity monitoring systems. Diagnose This requirement should not demand a separate product but should be built into any PCI compliant log management solution deployed in your organization. Review product information from your chosen log management solution to determine if it meets this requirement. Review FIM configurations to determine if alerts from the systems are being forwarded to log management tools. Determine if FIM tools have been deployed on resources within the cardholder data network. Ensure that these tools are set up to alert if unauthorized changes to files are made. FIM tools may include specialized change detection software or other solutions that have the ability to monitor for changes, such as some log management solutions, patch management solutions, or configuration management solutions. Review incident response policy documentation to ensure that file integrity monitoring alerts are specified in the policy. 53859 Source: Forrester Research, Inc. 2009, Forrester Research, Inc. Reproduction Prohibited October 26, 2009

8 Figure 4 PCI X-Ray File Integrity Monitoring Checklist: Treating PCI Compliance PCI requirement 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6. 11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. Note: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider). 12.9.5 Include alerts from intrusiondetection, intrusion-prevention, and fileintegrity monitoring systems. Treat The only treatment is to deploy a PCI compliant log management solution. Configure FIM tools to send alerts and other pertinent information to logging systems. Verify that the log management solution is correctly receiving and parsing the FIM log data. Deploy appropriate FIM tools on resources that fall within the scope of your PCI obligation. Add the review of FIM alerts if it is not included in the policy documentation. 53859 Source: Forrester Research, Inc. Follow Up: Diligence Is Demanded By This Ever-Changing Threat Environment PCI requires constant vigilance. It s easy to let compliance slip. One of the benefits of FIM is that it helps maintain a constant state of compliance. One of the myths of PCI is that many of the organizations that have suffered breaches were PCI-compliant and therefore there s something wrong with PCI. The truth, however, is that no company that has ever been breached was compliant at the time of the breach. As part of the ongoing PCI hygiene, you should: October 26, 2009 2009, Forrester Research, Inc. Reproduction Prohibited

9 Ensure FIM is running, but don t use it as a PCI crutch. Clearly, several breaches occurred because the company had not properly deployed FIM and was therefore unaware of the installation of malicious software. FIM could have foiled some of the most noteworthy breaches in recent memory. PCI is merely a minimum baseline, and companies should protect themselves based upon current threats, which are ever-changing. Don t fall victim to the checkbox mentality; review and update FIM policy regularly. It s important to maintain your FIM solution. Too many organizations configure these tools once and then never check up on them again. In their mind, they checked a box and it s time to move on. Don t let this checkbox mentality invade your organization. Make sure you reassess your FIM tool policies on a regular basis. Given the criticality of FIM in today s threat environment, reviewing your FIM policy on a quarterly basis in conjunction with your approved scanning vendor (ASV) scans is a good idea. Recommendations file integrity monitoring is a critical last line of defense The companies breached in the Gonzalez attacks provide an object lesson to all organizations that store, process, or transmit credit card data. These threats are real, costly, and constantly evolving. FIM may well be your last line of defense. When attackers have bypassed other controls within your infrastructure, FIM can save you from a damaging data breach. Make your FIM investment pay off by: Leveraging existing controls to provide FIM functionality. You may already have a FIM tool in place. Look at solutions that handle configuration information to see if they might meet the FIM requirements stated in the PCI DSS. Patch management, HIPS, and whitelisting software are the most logical starting points. Taking FIM alerts seriously. It s easy to ignore alerts. FIM alerts should be configured so that they only fire when something potentially dangerous is happening. Don t leave the tool in its default configuration, but spend the requisite amount by allocating a security analyst to consistently review the FIM configuration for at least the first six months of the deployment to properly configure the tool. Nothing is more damaging than a breach alert that is ignored. Remembering to include FIM in incident response. Many companies just assume (or hope) they will never be breached. But let s be clear: You will not jinx yourself if you plan for responding to a breach in advance. It should never be a surprise when a breach occurs. Plan for failure and have a worst-case scenario practiced and ready. If they aren t already, make sure FIM alerts are part of your formal incident response policy documentation. Review this annually with business, IT, compliance, legal, and PR executives so they understand the correct incident escalation steps. 2009, Forrester Research, Inc. Reproduction Prohibited October 26, 2009

10 Endnotes 1 Source: Visa (http://usa.visa.com/download/merchants/cpp_fraud_overview.pdf). 2 According to Heartland Payment Systems, it was unaware of the breach until notified by Visa and MasterCard that a breach had occurred. Source: Heartland Payment Systems Uncovers Malicious Software In Its Processing System, Heartland Payment Systems press release, January 20, 2009 (http:// www.2008breach.com/information20090120.asp). 3 In the early years of credit card security, the card brands put significant effort into determining the attack vectors of credit card breaches. There was very little log data available to use in reconstructing the crime. Therefore, the brands introduced requirements for logging in to their individual cardholder protection efforts so that they could find out what happened if there was a breach. Eventually these requirements found their way into the PCI DSS. The logging requirements true purpose is to provide forensic data for breach investigation. See the October 20, 2008, PCI X-Ray: Log Management report. 4 Requirement 10 of the PCI DSS mandates that all access to network resources and cardholder data must be tracked and monitored. According to the PCI DSS v1.2, Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. See the April 30, 2009, Market Overview: Security Information Management (SIM) report. 5 Source: US Department of Justice (http://www.usdoj.gov/usao/nj/press/press/files/pdffiles/gonzindictment. pdf). 6 Source: Heartland Payment Systems (http://www.2008breach.com/heartlandfaq.asp). October 26, 2009 2009, Forrester Research, Inc. Reproduction Prohibited

Making Leaders Successful Every Day Headquarters Forrester Research, Inc. 400 Technology Square Cambridge, MA 02139 USA Tel: +1 617.613.6000 Fax: +1 617.613.5000 Email: forrester@forrester.com Nasdaq symbol: FORR www.forrester.com Research and Sales Offices Australia Israel Brazil Japan Canada Korea Denmark The Netherlands France Switzerland Germany United Kingdom Hong Kong United States India For a complete list of worldwide locations, visit www.forrester.com/about. For information on hard-copy or electronic reprints, please contact Client Support at +1 866.367.7378, +1 617.613.5730, or clientsupport@forrester.com. We offer quantity discounts and special pricing for academic and nonprofit institutions. Forrester Research, Inc. (Nasdaq: FORR) is an independent research company that provides pragmatic and forwardthinking advice to global leaders in business and technology. Forrester works with professionals in 20 key roles at major companies providing proprietary research, customer insight, consulting, events, and peer-to-peer executive programs. For more than 26 years, Forrester has been making IT, marketing, and technology industry leaders successful every day. For more information, visit www.forrester.com. 53859