Configuration Control for
Virtual and Physical Infrastructures
whIte PaPer
Beyond PCI Checklists:
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
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 “pro-tect 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 secu-rity 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 take-off. 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 achiev-ing those objectives are, havachiev-ing adequate situational awareness to identify where we need controls to mitigate those risk, and then having implementing and monitoring the correct produc-tion 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 miti-gate. 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 con-trols, 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 appro-priate 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 pre-sentation, 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 comput-ing systems2 in the cardholder data environment are configured
correctly. For example, PCI DSS Requirement 1 deals with fire-walls, 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 appli-cation 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 con-trols easier to test.
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 pro-cess 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 applica-tion 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 com-pany’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 environ-ment 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’ e-mail 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 compo-nents 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) (www.cisecurity.org) • The Defense Information Systems Agency (DISA)
(www.disa.mil)
• The SANS Institute (www.sans.org) • 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 sys-tems. These passwords and settings are well known by hacker communities and are easily determined via public information.”
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 vul-nerabilities 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 configura-tions 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 pro-cesses 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 7.2.3 specifies that system compo-nents 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 com-puting 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
dur-ing transmission and storage on all system components usdur-ing strong cryptography,” while Requirement 8.5 states that we
must “ensure proper user authentication and password
manage-ment 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 configura-tions 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
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 impair-ment, etc.). This also enables root cause analysis and impact analysis.
PCI DSS Requirement 10 has a number of sub-requirements. For instance, Requirement 10.2.1 states that we must log “all
individual user accesses to cardholder data,” and Requirement
10.2.3 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 config-ured 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 set-tings 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 set-tings 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 1.1.1 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 envi-ronment 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 meth-ods 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 neces-sary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.”
To fulfill PCI DSS Requirement 3, we must protect stored cardholder data by:
• Ensuring that applications prevent prohibited cardholder data such as CVV and AV23 from being stored in system logs, a
To prevent the storage of prohibited cardholder data, we must verify that the computing systems that support the front-end processes (order entry, POS, etc.) and back-front-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 rel-evant 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 pro-hibited 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 accor-dance 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 set-tings 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 sup-port 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 authentica-tion 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 dur-ing 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 oper-ating system file, library, or network setting could result in disabling encryption; for this reason, we must detect all chang-es 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 sys-tems must have the most recently released, appropriate software patches to protect against exploitation and compromise of card-holder 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:
• Be able to detect when scheduled changes were not imple-mented 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 soft-ware. 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 sys-tem components, processes, and syssys-tem 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 unau-thorized 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 sup-port 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 configura-tion 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 set-tings 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.
1 PCI data Security Standard 1.2. october 1, 2008. Published by the PCI Security Standards Council. https://www.pcisecuritystandards.org/ 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
iden-tifiable 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, 2008. http://www.theiia.org/itaudit/features/in-depth-features-5-1-08/ gait-pci-scenario/
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 imple-mentations of Tripwire Enterprise to ensure they fully—and immediately—benefit from their Tripwire PCI solution.
Meeting PCI requirements
and Securing the data Center
aBout trIPwIre
