Beyond PCI Checklists:

Securing Cardholder Data with Tripwire’s

enhanced File Integrity Monitoring

white paper

Configuration Control for

Virtual and Physical Infrastructures
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

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 “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, having 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,
3 | WHITE PAPER | Beyond PCI Checklists
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
4 | WHITE PAPER | Beyond PCI Checklists
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.”
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 dis-
abled or do not use the vendor-supplied default passwords.
 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
5 | WHITE PAPER | Beyond PCI Checklists
• %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 using
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
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 track-
ing, alerting, and analysis when something does go wrong.
Determining the cause of a compromise is very difficult without
system activity logs.”
 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.
6 | WHITE PAPER | Beyond PCI Checklists
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
data warehouse or database.
• Storing cardholder data securely.
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-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
7 | WHITE PAPER | Beyond PCI Checklists
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:
• Have a change calendar (or “forward schedule of change” in
ITIL language) of authorized and scheduled changes
• Detect all changes on production computing systems
• 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 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 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.
8 | WHITE PAPER | Beyond PCI Checklists
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.
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 deplet-
ing 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.
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
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 practitio-
ners, 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 imple-
ment 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, 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/

9 | WHITE PAPER | Beyond PCI Checklists

 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.

www.tripwire.com

©2009 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