Beyond PCI Checklists:

Transcription

1 Beyond PCI Checklists: Securing Cardholder Data with Tripwire s enhanced File Integrity Monitoring white paper Configuration Control for Virtual and Physical Infrastructures

2 Contents 4 The PCI DSS Configuration Controls 6 The PCI DSS Change Process Controls 8 How Tripwire Helps 9 Meeting PCI Requirements and Securing the data Center 2 WHITE PAPER Beyond PCI Checklists

3 Introduction According to the New York Times, on January 19, 2009, Heartland Payment Systems disclosed that they may have exposed the credit information of tens of millions of credit and debit card holders in what may be one of the largest data compromises to date. Heartland had been compliant with the Payment Card Industry Data Security Standard (PCI DSS), the standard designed by the major credit card companies to protect consumers, merchants and banks from the theft or loss of credit information and any subsequent fraudulent activity. 1 The Heartland security breach illustrates a concerning trend toward organizations achieving PCI compliance, but still suffering a major breach. Being PCI Compliant Does Not Ensure Security The PCI DSS applies to any organization that accepts, stores or processes payment cards of any type and is a comprehensive checklist of actions these organizations must take to improve the security of global payment systems. Although the adoption of PCI DSS by an organization will most likely improve its security posture, being compliant with the PCI DSS does not ensure the organization is secure. As security practitioners, if we mechanically follow the PCI DSS checklist and our organization suffers a data security breach, we are still held responsible, and our organization still gets fined, suffers brand damage and may lose its ability to process credit card transactions. While checklists are useful tools, following them can lull us into a false sense of security. To rely solely on the PCI DSS checklists to secure cardholder data is similar to a pilot relying only on the pre-flight checklist before takeoff, then colliding with another plane during takeoff. A checklist is not enough. In reality, the goal of effective security controls is to prevent security breaches from occurring, and when they do, to allow quick detection and recovery. This requires not just following a checklist, but understanding the organization s compliance and security objectives, understanding what the top risks to achieving those objectives are, having adequate situational awareness to identify where we need controls to mitigate those risk, and then having implementing and monitoring the correct production controls. Two Areas Of Risks: Configuration And Change In this paper, we will first review the high-level goals of the PCI DSS. Then, we will examine two areas of technical controls required by the PCI DSS relevant to configurations and change, and present the primary risks that they are designed to mitigate. These controls span most of the PCI DSS requirements, either implicitly or explicitly. In Part I we discuss the first area, configuration controls, which require that specific configuration settings are correct. Returning to the airplane analogy, in a pre-flight checklist, configuration controls equate to checking that fuel levels are correct, the baggage door indicator light indicates the door is closed, the flaps are in the correct setting for takeoff, and so forth. In Part II we discuss the second area, change process controls, which ensure required activities have been completed properly. In a pre-flight checklist, these equate to ensuring that the pilot checks that the flap controls have the appropriate range of motion, that all maintenance issues were appropriately addressed, the pilot has signed all the required forms, the flight attendants correctly performed the safety presentation, and the pilot and copilot visually check the runway for other plans before takeoff, and so forth. These activities must be validated not just at one point in time, but regularly over an entire period of time (i.e. the entire year between PCI audits). The Intent of Configuration and Change Process Controls For the PCI DSS, configuration controls ensure that all computing systems 2 in the cardholder data environment are configured correctly. For example, PCI DSS Requirement 1 deals with firewalls, and includes requirements that all firewall settings are set to deny all, that audit logging is enabled, that required password aging is enabled, and so forth. On the other hand, change process controls ensure all changes to those computing systems in the cardholder data environment were adequately tested, authorized and verified. For example, PCI DSS Requirement 1 also requires evidence that all changes to firewall rules are detected and authorized by management. Other PCI Requirements require that all application software and operating system patches are tested by management for correct functionality before deployment into production. Configuration controls tend to more explicit, and can be verified merely by examining production configuration settings to the PCI DSS standard. This often makes configuration controls easier to test. 3 WHITE PAPER Beyond PCI Checklists

4 Without automation, verifying change process controls can be more difficult to test than configuration controls. Instead of checking for correctness at a single point in time, change process controls ensure that management and supervisory controls have been reliable and consistent over a period of time. For instance, to ensure that all application changes were tested, we must first assemble the population of all application changes in the specified period, and then substantiate that management signed off on all of them as being adequately tested. These tests can be automated to a significant degree. For instance, if an organization has a change audit/reconciliation monitoring technology that can reconcile detected production changes with authorized and tested changes, management can rely on these reports to show that no unauthorized or untested changes were made. The PCI DSS Configuration Controls In this section, we examine the broad requirements where the PCI DSS requires configuration controls. For each requirement, we will explain the requirement intent and provide specific examples of how to fulfill them. To ensure compliance with configuration controls, we can either inspect these settings manually or use automated tools. Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 1 of the PCI DSS states: Firewalls are computer devices that control computer traffic allowed between a company s network (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within a company s internal trusted network. The cardholder data environment is an example of a more sensitive area within the trusted network of a company. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employees Internet access through desktop browsers, employees access, dedicated connection such as business to business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network. PCI DSS requires that we configure firewalls securely. PCI DSS Requirement 1 has four sub-requirements; for example, Requirement 1.1, which states that we must establish firewall and router configuration standards. And Requirement 1.2, states that we must build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment. In order to fulfill these requirements, for each firewall or router in the cardholder data environment, we must be able to block unauthorized services (e.g., FTP, IP finger, IP source routing, etc.), ensure that role-based administration is enabled, ensure that access settings only allow authorized resources to change or access security settings, etc. Specifications of what firewall settings must be set to achieve compliance with the PCI DSS can be found in many checklists and other technical guidance. This includes: The Center For Internet Security (CIS) ( The Defense Information Systems Agency (DISA) ( The SANS Institute ( Firewall vendors Verifying correctness of these settings can be done manually. However, automated tools are preferable, as they increase reliability, reduce the risk of human error, and reduce the time and effort required. Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Requirement 2 of the PCI DSS states: Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information. The application stack consists of applications, databases, operating systems and network devices. Each computing system in each of these layers has configuration settings and user accounts that may use vendor-supplied defaults. For each of the computing systems in the cardholder data environment, PCI DSS requires evidence that configuration settings are set securely, and that default user accounts have been either disabled or do not use the vendor-supplied default passwords. 4 WHITE PAPER Beyond PCI Checklists

5 PCI DSS Requirement 2 has a number of sub-requirements. For example, PCI DSS Requirement 2.2 states that we must develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards as defined. In order to comply with this requirement, for Microsoft Windows servers, we must ensure that the security configurations are set correctly, such as: Minimum Password Age Is Greater than or Equal to 1 Day Allow Anonymous SID/Name Translation: Disabled Do Not Allow Anonymous Enumeration of SAM Accounts: Enabled Do Not Allow Anonymous Enumeration of SAM Accounts and Share: Enabled Requirement 7: Restrict access to cardholder data by business need to know Requirement 7 of the PCI DSS states: To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job. Each computing system in the application stack may have user accounts that management has not explicitly assigned to an authorized user (e.g., guest and service accounts). For each of these computing systems, we must identify and disable all accounts not explicitly authorized by management. PCI DSS Requirement 7 has a number of sub-requirements. For example, Requirement specifies that system components with multiple users must restrict access on a user s need to know, and must default to deny all. In order to comply with this requirement, we must ensure that the configurations are properly set. On Microsoft Windows servers, this would include: Disabling the Microsoft Windows AppMgr permissions Ensuring that the ability to access system files is properly restricted, including %SystemRoot%\system32\cacls.exe %SystemRoot%\system32\debug.exe %SystemRoot%\system32\drwatson.exe %SystemRoot%\system32\drwtsn32.exe %SystemRoot%\system32\edlin.exe %SystemRoot%\system32\eventcreate.exe Requirement 8: Assign a unique ID to each person with computer access Requirement 8 of the PCI DSS states: Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. PCI DSS Requirement 8 requires that all user activity on computing systems can be traced to an authorized user, prohibiting use of shared accounts, and so forth. For instance, Requirement 8.4 states that we must render all passwords unreadable during transmission and storage on all system components using strong cryptography, while Requirement 8.5 states that we must ensure proper user authentication and password management for non-consumer users and administrators on all system components. In order to comply with this requirement, all authorized accounts must have strong password controls such as password strength, aging and expiration policies. In addition, we must ensure that for each asset in the application stack, we set password policies according to the PCI DSS requirements. To achieve this, we must ensure that the relevant configurations settings are set properly. This includes: All system components must enable audit logging Maximum password age is less than 90 days Minimum password length is greater than or equal to 7 Password complexity: enabled Password history memory is greater than or equal to 4 Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 10 of the PCI DSS states: Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs. 5 WHITE PAPER Beyond PCI Checklists

6 For each IT asset in the application stack, we must ensure that logging mechanisms are enabled to track user activities. System activity logs in all environments enable post-mortem forensics analysis if something does go wrong (e.g., security breach, lost cardholder information, service outage or impairment, etc.). This also enables root cause analysis and impact analysis. PCI DSS Requirement 10 has a number of sub-requirements. For instance, Requirement states that we must log all individual user accesses to cardholder data, and Requirement states that we must have access to all audit trails. In order to comply with Requirement 10, we must ensure that the configurations are properly set. On Microsoft Windows servers, this includes ensuring that the following settings are enabled: Audit Logon of Domain Accounts Audit Logon Events Audit Account Management In order to comply with Requirement 10, we must also ensure that the configurations for event logging are properly configured and sized, to ensure that relevant data is not discarded due to small log spool sizes. For example: Application Event Log Size Is Greater than or Equal to 16 MB System Event Log Size Is Greater than or Equal to 16 MB Security Event Log Size Is Greater than or Equal to 80 MB Conclusion In Part I: Configuration Controls, the examples of settings that we must configure by no means represent the entire list of settings that must be configured to achieve PCI compliance. These examples are intended to show the type of checklist items we must verify to be compliant with the PCI DSS. The PCI DSS Change Process Controls In this section, we examine each requirement for the change process controls the PCI DSS requires. Just as we did for the earlier configuration controls, we ll explain the intent behind each requirement. We ll also provide steps we can take to fulfill them. To ensure compliance with change process controls, we can either inspect these settings manually or use automated tools. Requirement 1: Install and maintain a firewall configuration to protect cardholder data In Part I, we noted that Requirement 1 requires that certain firewall settings be set correctly. However, it s not enough to verify that the configurations are secure at a single point in time; we need to demonstrate that all changes to firewall settings are detected and authorized by management and that none of those changes take us out of compliance with the PCI DSS configuration requirements. In fact, Requirement states that we must establish firewall configuration standards that include a formal process for approving and testing all external network connections and changes to the firewall configuration. To fulfill this part of the PCI DSS Requirement 1, we must: Detect all changes made to the firewalls in the cardholder data environment. Have in place a workflow that management uses to approve proposed changes. Have a manual or automated means of reconciling detecting changes with authorized changes, validating that all changes made were indeed authorized. By doing this, we can generate a change process control report that substantiates that all changes in the cardholder data environment were approved and tested by management. Requirement 3: Protect stored cardholder data Requirement 3 of the PCI DSS states: Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted s. To fulfill PCI DSS Requirement 3, we must protect stored cardholder data by: Ensuring that applications prevent prohibited cardholder data such as CVV and AV2 3 from being stored in system logs, a data warehouse or database. Storing cardholder data securely. 6 WHITE PAPER Beyond PCI Checklists

7 To prevent the storage of prohibited cardholder data, we must verify that the computing systems that support the frontend processes (order entry, POS, etc.) and back-end processes (authorization and settlement, customer support, accounting, etc.) involved in credit card processing do not store such data. We usually verify this by inspecting the code or asking the relevant system vendors to verify PCI compliance. However, just as with the configuration controls, testing that prohibited cardholder data is not stored is only reliable for that single point in time. Instead, we need to ensure that no code or configuration changes occur over time that could cause prohibited cardholder data to be stored. For instance, any of the following changes could result in prohibited data being stored: Enabling application debug logging Changing a configuration setting at the application level Changing a database configuration setting Adding or changing a database stored procedure Furthermore, the PCI DSS requires that we store cardholder data securely. To do this, we must ensure that all computing systems that store cardholder data are configured securely and in accordance with PCI DSS requirements. 4 Because cardholder data is primarily processed and stored in the application and database, we can often meet this objective by verifying that those systems are properly configured. But again, it is not enough to verify that configuration settings are correct at a single point in time; we must ensure that all changes to configuration settings are authorized and do not take us out of compliance with PCI DSS requirements. To fulfill PCI DSS Requirement 3, we must: Detect all changes made to any computing systems that support the front- and back-end processes involved in credit card processing as well as any computing systems that store cardholder data. Have a workflow that ensures management signs off on approved changes. Have a manual or automated means of reconciling detected changes with authorized changes to validate that all changes that were made were indeed authorized. Requirement 4: Encrypt transmission of cardholder data across open, public networks Requirement 4 of the PCI DSS states: Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments. PCI DSS requires that all cardholder data be encrypted during transmission. Encryption typically is done by end-to-end encryption at the operating system level, or in rare cases, at the network level. Although we test and verify that cardholder data has been encrypted, once again, this is only for a single point in time. An untested or unauthorized change to an operating system file, library, or network setting could result in disabling encryption; for this reason, we must detect all changes made to the operating system and network to ensure they don t jeopardize functionality and that they were authorized before release into production. To fulfill this requirement, we must complete the same three activities seen for Requirements 1 and 3: detect all changes, have a workflow in place that ensures changes are approved, and have a means of ensuring detected changes were authorized. Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software. To comply with PCI DSS Requirement 6, we must apply security patches to the applications, database, operating system, and network on a regular basis. A major risk is that scheduled updates and patches are not completed as planned; for instance, the patch management system only successfully completes on 490 of the 500 production systems, leaving 10 systems in a vulnerable and insecure state. To mitigate this risk, we must ensure that planned and scheduled changes are deployed completely, accurately and within the specified timeframe. To do this we must: Have a change calendar (or forward schedule of change in ITIL language) of authorized and scheduled changes Detect all changes on production computing systems 7 WHITE PAPER Beyond PCI Checklists

8 Be able to detect when scheduled changes were not implemented properly (i.e., a scheduled patch was not deployed completely, accurately, or within in the required timeframe) Requirement 11: Regularly test security systems and processes Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. PCI DSS requires that all computing systems, computing system components, processes, and system software are adequately secured. Achieving this requires that we first test components for correct functionality and vulnerabilities, and then ensure tested components have not changed in a way that would invalidate previous testing results. The second element, ensuring that change doesn t invalidate these certification and test results, is what is specified by PCI DSS Requirement 11.5, which requires organizations to 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. In order to fulfill this requirement, we must: Detect all changes made to any computing systems that support the front-end and back-end processes involved in credit card processing and to any computing systems that store cardholder data. Have a workflow that ensures management signs off on approved changes. Have a manual or automated means of reconciling detected changes with authorized changes to validate that all changes made were indeed authorized. How Tripwire Helps Tripwire has helped over 6,500 organizations meet compliance requirements and secure their IT infrastructure with its leading product Tripwire Enterprise. The Tripwire Enterprise solution delivers Enhanced File Integrity Monitoring which combines configuration assessment with file integrity monitoring to meet the configuration and change process controls described in the preceding sections. Meeting Configuration Control Requirements The configuration assessment component of Tripwire Enhanced File Integrity Monitoring helps meet the configuration control requirements of the PCI DSS. Tripwire does this by ensuring that configurations of computing systems in the cardholder environment those in scope for the PCI DSS comply with the configuration settings required by the PCI DSS. This is accomplished by comparing the current state of each configuration setting against settings required by the PCI DSS against Tripwire s policy for PCI which is based on vendor hardening standards certified by the Center for Internet Security (CIS). The results of the assessment show which configuration settings are out of compliance, and also provides prescriptive guidance for getting those settings into a compliant state. Meeting Change Process Control Requirements Once the initial configuration assessment is made, as described in 4.1, Tripwire s Enhanced File Integrity Monitoring technology will continuously detect change made to any critical system files, configuration files, or content files. Each detected change will trigger these actions which are required by item 11.5 of the PCI DSS: Determine if the change was authorized by reconciling it with approved changes, and If the change was made to a configuration file (versus, for example, a system or content file), automatically retest it to determine if the file is still in a compliant state. Continuous Change Detection and Analysis Tripwire s Enhanced File Integrity Monitoring continuously detects change, immediately analyzes it, and generates alerts of unauthorized or out-of-compliance changes without depleting computing resources. Tripwire Enterprise software is able to do this by detecting and analyzing changes as they happen rather than doing mega-scans every week, month or even every quarter as typical monitoring and assessment product do. By detecting incremental change, Tripwire Enterprise maintains a version history of the changes which supports detailed and active reports and makes forensics faster and easier. 8 WHITE PAPER Beyond PCI Checklists

9 Broad Coverage and Expert Assistance for PCI DSS Finally, Tripwire has shown a long-standing commitment to helping organizations meet PCI compliance and secure the cardholder environment, with solutions that ensure security and compliance from the corporate datacenter, including virtual infrastructure, out to point-of-sale (POS) devices like self-serve kiosks, card processing machines and registers. In addition, Tripwire Professional Services has deep expertise helping organizations implement, manage, and even customize implementations of Tripwire Enterprise to ensure they fully and immediately benefit from their Tripwire PCI solution. Meeting PCI Requirements and Securing the Data Center Clearly, many organizations have fallen short of the intent of the PCI DSS. The numerous security breaches that occur in spite of having passed an audit point to a need for us to take a long, hard look at what we, as IT security and compliance practitioners, really need to do to secure the cardholder environment. A good first step is to identify the configuration and change process controls described by the PCI DSS that, if not properly implemented, can lead to increased security risk to computing systems in the cardholder environment. We must also implement proven solutions like Tripwire Enterprise, which provide Enhanced File Integrity Monitoring for automated configuration assessment and file integrity monitoring, to get key files and configurations into a secure and compliant state and keep them there continuously. 1 PCI Data Security Standard 1.2. October 1, Published by the PCI Security Standards Council. security_standards/pci_dss_download.html 2 In this paper, the term computing systems is used, consistent with the PCI DSS parlance. In previous papers, the term IT assets was used. 3 Prohibited cardholder data is defined by PCI to be any personally identifiable information (PII) associated with a cardholder: Primary Account Number (PAN) that includes expiration date, cardholder name and address, CVV (Card Verification Values) or CVC Card track data (magnetic stripe) 4 Case Studies of Using GAIT for Business and IT Risk To Scope PCI Compliance. Published by The Institute of Internal Auditors. September 16, gait-pci-scenario/ 9 WHITE PAPER Beyond PCI Checklists

10 About Tripwire Tripwire helps over 6,500 enterprises worldwide reduce security risk, attain compliance and increase operational efficiency across virtual and physical environments. With its industry leading configuration assessment and change auditing software solutions, IT organizations achieve and maintain configuration control. Tripwire is headquartered in Portland, Oregon, with offices worldwide Tripwire, Inc. Tripwire is a registered trademark of Tripwire, Inc. All other product and company names are property of their respective owners. All rights reserved. WPBCL1