Chapter 13 You’re Compliant, Now What

Introduction

Congratulations, you passed! Depending on where you were when you started, you may have worked long and hard to get here. So now you can kick back, relax, and wait until your next annual audit, right? It would be great if it were that easy, but unfortunately it’s not. Security (and Payment Card Industry [PCI] compliance in particular) requires constant maintenance. In this chapter we will discuss how you can best spend your time now to ensure compliance in the future. First, we will discuss why you should think about security as a process instead of an event. We will then make suggestions on periodic review and training that should be happening in your organization. Last, we will outline some suggestions on performing a self-audit on your own network.

Security is a PROCESS, Not an Event

Security is not something that can be achieved, and then forgotten about. Contrary to some security vendor’s claims and some management hopes, you cannot install some magical device on your network that will make you eternally secure. Security is a process of constantly assessing your risks then working to mitigate them to a reasonable level. These risks are ever-changing, so processes and technology to stop them should be ever-changing as well.

One thing to keep in mind is that you were never 100 percent secure to begin with. Even if you’ve done everything you can find to secure your systems, an attacker can still find ways in. In fact, it’s actually very difficult to prove that you are secure and it’s relatively easy to prove that you are insecure. To prove that you are secure you must prove that every possible risk (remember, these are constantly changing) is protected against. To prove insecurity you only have to find one attack vector that isn’t fully mitigated against. This could be an attack vector that you have never thought of. It could be one that only one attacker in the whole world knows about, and if that attacker decides to target your company, then despite all you have done he could successfully attack your network. Also, the more complex a system is the harder it is to secure. It is very difficult to have a system that’s completely secure that actually does something useful, like serve a Web page or allow a user to send an e-mail. In general, today’s systems are very complex, and therefore hard to secure.

Second, risks, technologies, and your organization are changing constantly. New attacks are invented constantly. New technologies and software are implemented in your network on a regular basis. New people come to your company and current employees likely forget things from time to time. To remedy this new security, measures need to be invented and people need to be trained regularly.

Third, it’s impossible to be PCI compliant without approaching security as a process. All of the requirements require some sort of maintenance. Logs need to be reviewed, systems and policies need to be updated, and security assessments need to be run. These are all part of the security process that keeps your company as safe as possible from attacks.

Plan for Periodic Review and Training, Don’t Stop Now!

It’s important to plan now for future review and training. Working with technology in an organization can get very hectic, and if you put off planning then you are far less likely to do it. It’s important to review your security polices and practices often to verify they’re actually being implemented. Many times great policies are in place but never enforced and so they are never actually followed. It’s also important to train your employees often to ensure that they understand and are reminded of your security policies. Periodic training also emphasizes the importance of security polices to employees so they’re more likely to follow them.

Here are some ideas of things you may want to review with employees at your organization:

• Passwords What makes a good password? Remind them never to share their password with anyone for any reason. Warn them of common mistakes such as writing passwords on a post-it note and sticking it on the computer monitor.
• Social Engineering Don’t let people fool you. Make policies for visitors clear to ensure that a malicious visitor won’t leave with information they shouldn’t have. Also, you could review polices for verifying an employees identity when they make requests (such as password resets) over the phone or in some other non-face-to-face situation.
• Physical Access Verify that everyone knows what a visitors badge looks like and knows what the company policies are with regards to where visitors are allowed to go and where they are not allowed to go.
• Correctly Storing and Destroying Sensitive Material Help employees keep up-to-date with company polices that require that sensitive data be destroyed. For example, it’s important that employees are trained on destroying paper and electronic media that contains confidential data when it’s not longer needed.

Your Information Technology (IT) staff also needs to be regularly trained on security. For example:

• Secure Coding Practices Software engineers don’t necessarily need to be security experts, however, it’s important that they understand secure coding practices. For example, anyone working on a Web application should be aware of cross-site scripting (XSS) and Structured Query Language (SQL) injection bugs. Programmers should also be aware of unsafe functions that may be available in their language, and their safer alternative functions.
• Systems administrators should be kept up-to-date with secure practices that are related to the systems they administer. They should know how to securely install and configure these systems.
• Security professionals at your company must be trained regularly. Depending on the size of your company, this may be a few or several employees. These are the people are responsible for securing your systems day in and day out. They must receive periodic training to help them be aware of new technologies and new attacks.

You should also regularly review the PCI requirements. You should choose a review schedule that doesn’t take so much time that you will never actually get to it, but that allows you to review often enough that you will have PCI requirements fresh in your mind. We recommend that you set aside a certain day a month for your review. A good rule of thumb is to review all PCI requirements quarterly. Currently, this would mean four requirements a month, which should be easily manageable. Reviewing on this schedule should also keep you in great shape for your quarterly scan and annual audit. This will also keep you up-to-date with any changes in the PCI requirements.

PCI Self-Audit

In this section we’ll go over each PCI requirement and give some ideas on how you can audit each requirement to verify that you are currently in compliance. Often times when a company first becomes PCI compliant you have to make many changes to their current security policy. Because of this, it’s very important to audit any new policy changes you’ve made to verify that they are working at your organization. This way you can find weak points in your policy or employee education that need to be addressed.

The PCI Security Council provides some great documents to help you with your self assessment. For example, the Self-assessment Questionnaire can help you determine your company’s current compliance level. You should periodically review these documents, and look for ways to improve your company’s security posture.

There are also many freely available and commercial security tools that can be used to test your company’s level of compliance. For example, Nessus is a fantastic vulnerability assessment tool that is free and works on both Windows and Linux. There are also many great free port scanning tools such as SuperScan or Nmap. Many of these tools are available on a live Linux CD called Backtrack (www.remote-exploit.org/backtrack.html) that contains many tools to help assess network security. Several mini-tutorials are contained throughout the chapter on how to use some of the most important tools from this CD to help test your PCI compliance.

In the following section each requirement is broken up into two parts. Under the “Policy Checks” heading we discuss policies that should be reviewed to verify that they are up-to-date. In the “Hands-on Assessments” sections we give some ideas on testing these policies to ensure that they have been properly implemented.

Requirement 1

Requirement 1 is about firewall and router configuration policies.

1.1 Policy Checks

Obtain a copy of the firewall and router configuration standards and verify it is up-to-date with your current configuration and that the following items are included:

• A policy for making changes to firewall configurations. This should include a testing procedure and a requirement that management signs off on any changes.
• An up-to-date network diagram of connections to all systems that deal with cardholder data. This should show a firewall at any Internet connection and between the demilitarized zone (DMZ) and internal network.
• A requirement that a firewall be placed at each connection to the Internet and between the DMZ and internal network.
• A description of groups, roles, and responsibilities for logical management of network components.
• Justification and documentation for any protocols being used besides Hypertext Markup Language (HTTP), Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN).
• Justification and documentation for using any risky protocols such as File Transfer Protocol (FTP).
• A procedure for a quarterly review of firewall and router rule sets.

1.1 Hands-on Assessments

Interview firewall and router administrators and verify that the change policy was followed in the most recent changes to the firewall configuration. Verify that management is signing off on changes to the firewall by obtaining and reviewing the signed forms. A great tool to help you audit your firewall compliance and check your network diagram is a port scanner such as Nmap or SuperScan. For example, you can run a port scanner on your network and compare the list of hosts returned by the port scanner to your network diagram. While running a port scan on a network may not find all the hosts, it will at least find all the hosts with open ports. In Section 1.2 we’ll outline some methods for testing the firewalls between the Internet and your networks and between the DMZ and your internal network.

1.2 Policy Checks

Verify that policies are up-to-date that require firewalls between the Internet and DMZ and the DMZ and the internal network.

1.2 Hands-on Assessments

Run a port scanner against routers and firewalls that segregate the Internet from your networks and the DMZ from the internal network, to verify that these routers and firewalls are properly restricting traffic. For example, if you use a port scanning tool from the Internet against your network, it should only return ports appropriate to do business on your systems. If you find protocols other than HTTP, SSL, SSH, or VPN being used, then they must be justified and documented in your firewall policy. If there is no business reason for these protocols, they should be disabled and a review should happen to determine how and why there were enabled. You should also inspect the configuration on firewalls on a regular basis to ensure they are properly configured as prescribed in your firewall policy.

1.3 Policy Checks

Verify that you have an up-to-date policy that requires the following configuration settings on firewall and routers between publicly accessible servers and systems (a wireless network is considered a publicly accessible network) and systems storing cardholder data.

• Traffic from the Internet is only allowed through the firewall between the Internet and the DMZ if the destination IP addresses is within the DMZ.
• Internal IP addresses in the DMZ must be filtered by firewalls so they are not allowed to flow from the DMZ to the Internet.
• Stateful packet filtering (also called dynamic packet filtering) must be enabled on all firewalls.
• Databases storing credit card data must be on the internal network and not in the DMZ.
• Only traffic that is required to conduct business should be allowed in and out of your network. Your firewall should restrict all other traffic.
• Router and firewall configuration files must also be synchronized and up-to-date. Verify that running configurations and start-up configurations are the same for all routers and firewalls. This means that when you reboot your routers and firewalls, they will be using the same configurations they were before the reset.
• By default all traffic in and out of your network should be explicitly denied, and then only protocols required to do business should be allowed.
• A firewall must exist between any wireless networks and internal networks that store cardholder data. Check your network diagram discussed in Requirement 1.1 to verify that this firewall is on your diagram.
• Any company-owned mobile computer or employee-owned computer must have a personal firewall installed on it, which must be configured to comply with your company firewall standards. It must also be configured in such a way that the employee cannot alter the configuration.

1.3 Hands-on Assessments

Examine your firewalls and routers between the Internet and the DMZ to verify that they only allow traffic through, and that their destination Internet Protocol (IP) is an IP in the DMZ. Examine these configurations to ensure internal DMZ addresses are filtered from passing back out to the Internet. You can test to see if stateful packet filtering is working by using Nmap on all Transmission Control Protocol (TCP) ports with syn reset or syn act options set. If you receive a response, then stateful packet filtering is not properly enabled. You should also examine the configuration of your database server to verify that a firewall exists between it and the DMZ.

You can run a port scan to verify that only protocols required for business are allowed through the firewall. Take a sample of the firewall and router configurations to verify that they are up-to-date and that the running configurations match the boot-up configurations. Verify that firewalls rules start with an explicit deny all, and then only protocols needed for business are enabled. Examine wireless connections in your network to verify that a firewall is installed between the wireless network and any network where wireless data is stored. Take a sample of mobile and employee-owned systems to verify that a software firewall is installed and enabled, and that the settings cannot be altered by the employee.

1.4 Policy Check

Your firewall policy should mandate that not direct access is made between the external network and internal computers that store credit card data. Also, it should mandate that outbound traffic from payment card applications be restricted to only go to IP addresses in the DMZ.

1.4 Hands-on Assessment

Check firewall policies to verify that no direct (non-firewalled) access to systems within the internal network is allowed. Examine firewall and router configurations to verify that traffic from the internal network is only allowed to access IP addresses within the DMZ.

1.5 Policy Check

Your policy must require that your firewall use IP masquerading to block RFC 1918 address space from traveling from internal networks to the Internet.

1.5 Hands-on Assessment

Review firewall configurations to verify that network address translation (NAT) or other technology is used, which restricts broadcasting RFC 1918 IP addresses from the internal network to the Internet.

Requirement 2

Requirement 2 verifies that you are not putting systems live with default security settings.

2.1 Policy Checks

Verify that your policy requires that system defaults must be changed before you install a system on the network. This includes settings such as passwords, Simple Network Management Protocol (SNMP) community strings, removal of unnecessary accounts, and so forth. Your policy must also require that vendor defaults for wireless devices are changed before they are placed on the network.

2.1 Hands-on Assessment

Nessus includes several plugins that will try to use default accounts to log into systems. Alternatively, you may want to either attempt to log in manually using default passwords, or use a tool such as THC-Hydra to do this for you. For wireless networks there are several tools such as Netstumbler and Kismet that will find some default configurations. For example, you can use these tools to find access points that are not using encryption or that are broadcasting default Service Set Identifier’s (SSIDs). It’s also important to check the configuration on these devices to verify that they are correct. For example, you could take a sample of wireless access points and verify that they are using non-default Wireless Encryption Protocol (WEP) keys (if WEP is enabled). You should also verify that SSID broadcasting is off and they are not using the default SSID. The SNMP community strings on wireless access points must also be changed from the default. If possible, Wi-Fi Protected Access 2 (WPA2) or Wi-Fi Protected Access (WPA) should be enabled on all access points (whenever possible WPA2 should be used). Verify that if there are other security-related default settings on the wireless access point, that they are changed from the defaults.

2.2 Policy Checks

Your configuration standards for systems in your network must be up-to-date with the following:

• Current industry-accepted hardening standards for your systems from industry-respected organizations including SANS, NIST, and CIS.
• Require that only one primary function is implemented per server (e.g., you cannot be running a primary Web and primary database server on the same machine).
• Require that all insecure services or protocols, or those services or protocols not required for that system to perform its functions, should be disabled.
• Require that system security parameters are configured to lock down the system as much as possible.
• Require that all unnecessary functionality is removed from systems, such as scripts, drivers, Web servers, and so forth.

2.2 Hands-on Assessments

You should take a sample of systems in your organization and verify they are compliant with your policy. For example, you should take a sample of critical servers or wireless access points and verify that only one primary function is implemented per server. You should take a sample of system components, critical servers, and wireless access points and inspection-enabled services, daemons, and protocols. You should verify that only necessary services and protocols are enabled. You should also interview and work to educate system administrators on things they can do to lock down systems. For example, verify that security parameter settings are set correctly for each system. Also verify that all unnecessary components such as driver scripts and so forth are removed. There are many network assessment tools that will help you do this, including Nessus. Microsoft Baseline Security Analyzer can also be very helpful in assessing basic lockdown settings on Windows machines.

2.3 Policy Checks

Verify that your policy requires all non-console initiative access be encrypted. For example, your policy should require that SSH, VPN, SSL, or similar technology is used instead of unencrypted HTTP, Telnet, or other unencrypted protocol.

2.3 Hands-on Assessments

Take a sample of systems on your network and have the system administrator’s log into various accounts remotely while you observe them. Verify that they are using SSH or other encrypted protocol to manage these systems remotely. Also examine system configurations to verify that Telnet and other insecure administrative services are disabled on systems on your network.

2.4 Policy Checks

If you are a shared hosting provider, your policy must require that each entity’s hosted environment and data are protected. You should also have a policy in place that outlines how to perform a timely forensics investigation if a system is compromised.

2.4 Hands-on Assessments

This requirement only applies to hosting providers. If you are a hosting provider, then you should examine the configuration of your systems to verify that a user only has access to their own cardholder data environment. For example, no entity should be using a shared Web server user ID. Also, each user’s Common Gateway Interface (CGI) scripts must be created and run as a unique user. Verify that no application process is run using a privileged user account such as Administrator. Verify that each entity only has permissions to read, write, and execute their own files and directories and required system files. Sometimes users need read permission to certain system binaries, if required, but they should never have write permission. Inspect the configuration to verify that reading log entries is restricted to the entity that owns them. Inspect the systems to verify that restrictions are in place to prevent a single user from monopolizing the systems, such as using up all the disk space, memory, bandwidth or central processing unit (CPU). Verify that logs are being kept of all actions taking place on the system.

Requirement 3

Requirement 3 is used to ensure that cardholder data is protected when it is stored on you systems.

3.1 Policy Checks

Verify that your policies and procedures are up-to-date with the following items:

• Specify how long credit card data needs to be kept and specify the legal, regulatory, and/or business reasons for the specified length. The length specified should be the minimum amount of time needed to meet legal, regulatory, and/or business reasons.
• Coverage of all cardholder data storage should be included. For example, secure data storage on mainframes, database servers, transfer servers, and so forth should be included in the policies and procedures.
• A description of an automatic process in place removal of the data was no longer needed.

3.1 Hands-on Assessments

Take a sample of systems that store cardholder data including mainframes, database servers, transfer servers, and so forth. Verify that data is being stored for exactly as long as your policy directs. Also verify that your automatic process for removal of cardholder data is working correctly by sampling systems and verifying that data is removed.

3.2 Policy Checks

Verify that your policy includes the following in relation to sensitive authorization cardholder data:

• If the sensitive authorization data is received then deleted, it must be deleted in a secure way that renders it unrecoverable.
• The full contents of the magnetic strips must never be stored.
• The 3- or 4-digit card validation code (sometimes called the CVV2, CVC2, CID, or CAV2) must not be stored after the card is authorized.
• The personal identification number (PIN) or encrypted PIN block must not be stored after the card is authorized.

3.2 Hands-on Assessments

Either manually or using log parsing tools, you should look through transaction logs, history files, trace files, debugging logs, as well as incoming transaction data, several database schemas, and the database content to verify that sensitive authorization data is not being stored after authorization of the card is complete. Sensitive authorization data includes the full contents of the magnetic strip, the 3- or 4-digit card validation code, and the PIN.

3.3 Policy Checks

Your policy must require that any time the primary account number (PAN) is displayed it must be masked, except when there’s a specific need for the entire number. A maximum of either the first 6 or last 4 digits can be displayed.

3.3 Hands-on Assessments

Obtain samples of various locations where the credit card number appears, and verify that only the truncated number is shown unless the full number needs to specifically be shown. This includes account numbers shown on Web pages, invoices, transaction receipts, and so forth.

3.4 Policy Checks

Your policy must require that the PAN is at least rendered unreadable anywhere it is stored using a strong one-way hash, truncation, index token and pad, or strong encryption. If you are using disk encryption instead of file or column level database encryption, verify that your policy requires that the encryption process must not be tied to the operating system’s access control mechanisms. Also verify that your policy requires that cardholder data stored for wireless networks is encrypted or sanitized there.

3.4 Hands-on Assessments

Take a sample of systems and verify that any time a PAN is stored, it is at least rendered unreadable using a strong one-way hash, truncation, index token and pad, or strong encryption (such as 128-bit Triple-Data Encryption Standard [DES] or 256-bit Advanced Encryption Standard [AES]). Take a sample of data from database servers to verify that account numbers are not being stored in the clear. Sample removable media (e.g., backups) and audit logs to verify unencrypted account numbers are not being stored. Also take a sample of data coming from wireless networks to verify that it is encrypted when stored.

If you are using disk encryption, verify that the logical access to files is implemented using a mechanism separate from one included with your native file system. Sample systems to verify that the encryption keys are not stored on a local system. They should instead be stored on a floppy disk, CD-ROM, or other removable media and should be physically stored in a secure location. Take a sample of removable media that contain credit card account numbers and verify that account numbers are encrypted on the media.

3.5 Policy Checks

Verify that you have an updated policy that covers secure storage of encryption keys that would prevent their disclosure and misuse. Verify that the policy specifies that there are very few custodians. The policy should specify appropriate forms and locations for storing keys (keys should be stored in the fewest locations possible).

3.5 Hands-on Assessments

Verify that encryption keys are stored securely and are protected against disclosure and misuse. Also verify that key custodian assignments are up-to-date and access is restricted to only a few key custodians. Examine critical systems and verify that keys are stored separately from data in a secure location that only the key custodians have access to.

3.6 Policy Checks

Verify that the key management process is up-to-date and contains the following items.

• If you are a service provider and you share keys with customers for transmission of cardholder data, your policy must require that you provide documentation to your customers that describes how to securely store keys.
• Strong keys must be generated and used.
• Keys must be securely distributed and stored.
• Keys must be periodically changed; this must happen at least once a year.
• Old keys must be securely destroyed.
• Split knowledge and dual control of keys (keys where two or three key custodians have parts of a key and all are needed to reconstruct it) is used for keys that encrypt sensitive data.
• Procedures should prevent keys from being replaced without authorization.
• Keys that have been compromised or are suspected to be comprised must be replaced.
• Old or invalid keys must be revocated (e.g., with Rivest, Shamir, & Adleman [RSA] keys).
• Key management custodians must sign a form showing they understand their responsibilities.

3.6 Hands-on Assessments

Take a sample of critical systems and verify that you are currently generating and using strong keys. You can interview key custodians to verify that the keys are being securely distributed and securely stored. Find out when the last time was when the keys were changed and verify that this complies with the policy. Verify that keys are being securely destroyed. You can also interview key custodians to verify that keys are being split into two or three pieces for critical information. Also verify that over time the key sections have not all been given to one custodian. Verify that procedures are in place and working that prevent unauthorized substitution of keys. Verify that personnel responsible are familiar with and have followed policies to replace keys that have been compromised or are suspected to have been compromised. Also verify that those responsible are aware of and are following procedures for revocation old and invalid keys (e.g., RSA keys). Obtain copies of forms signed by key custodians that verify they understand and accept key-custodian responsibilities.

Requirement 4

Requirement 4 works to verify that you keep confidential data secure while it’s traveling over networks.

4.1 Policy Checks

Verify that there is an up-to-date policy in place that contains the following items:

• Require that strong cryptography and secure protocols (such as SSL, TLS, or Internet Protocol Security [IPSEC]) be used to ensure secure transmission of cardholder data.
• Require that wireless networks use WPA, WPA2, IPSEC, VPN or SSL/TLS. WEP cannot be used by itself to protect confidential data on the network.
• Require that if WEP is being used, there is a minimum of 104-bit encryption key with a 24-bit initialization value and that it is only used in conjunction with WPA or WPA2, VPN, SSL, or TLS. Your policy should also require that WEP keys are rotated at least quarterly and automatically if your systems support this. Your access points must also restrict access based on Media Access Control (MAC) addresses.

4.1 Hands-on Assessments

Take a sample of your network devices and systems and verify that they are using strong encryption such as SSL, TLS, or IPSEC for transmission of confidential data. For example, for SSL or TLS Web pages, you should take a sample of pages that should be secure and verify that HTTPS appears in the Uniform Resource Locator (URL). You can also take a sample of transactions as they are received to verify they are encrypted (this can be done using a network sniffer such as Wireshark). Review the configuration of your systems to verify that only trusted SSL and TLS keys and certificates are accepted. When reviewing the configuration, you should verify that proper encryption strength is being used.

Anytime a wireless network is carrying cardholder data it should be encrypted. Verify that WPA or WPA2 is used whenever possible. You can also use IPSEC, VPN, SSL, or TLS instead of, or in conjunction with, WPA or WPA2. If WEP is being used, sample access point configurations to verify that a minimum of a 104-bit encryption key and a 24-bit initialization value is being used. Also, if WEP is being used, it should be in conjunction with WPA, WPA2, VPN, SSL, or TLS. Verify that access points are configured so that shared WEP keys are rotated at least quarterly or automatically if your system is capable of this. Also, by looking at a sample of access point configurations, verify that access is restricted based on MAC addresses.

4.2 Policy Checks

Verify that a policy is in place that requires that e-mail is always encrypted when it contains credit card account numbers. Unencrypted credit card data should never be sent over e-mail.

4.2 Hands-on Assessments

If you are sending PANs over e-mail, verify that your system is correctly configured to strongly encrypt these e-mails. You may also want to obtain a sample of e-mails and verify that credit card numbers are not being sent in the clear. Also interview employees to verify that they are following the company policy.

Requirement 5

Requirement 5 mandates that antivirus is on the systems and is up-to-date.

5.1 Policy Checks

Your policy must require that all computers have anti-virus software running on them that is capable of protecting against viruses and other types of malicious software, including spyware.

5.1 Hands-on Assessments

Take a sample of critical servers and wireless access points and verify the anti-virus software is installed. Verify that anti-virus software is capable of detecting, protecting against, and removing viruses and other types of malicious software, including spyware.

5.2 Policy Checks

Your policy must require that anti-virus software is up-to-date, running at all times, and capable of logging its activities.

5.2 Hands-on Assessments

Take a sample of systems, critical servers, and wireless access points and verify that anti-virus software is up-to-date, currently running, and generating audit logs. Verify that the master install has automatic updates and periodic scans enabled. Also verify that logs are being retained in accordance with your company’s policy for log retention.

Requirement 6

Requirements 6 is used to verify that you develop and maintain secure systems and applications. This ensures you have the most recent patches installed and that you are using secure methods for developing software.

6.1 Policy Checks

An up-to-date policy must be in place that requires that all systems are patched with vendor-supplied patches within 30 days of a patch being released.

6.1 Hands-on Assessment

Take a sample of several different types of systems (critical servers, wireless access points, and so forth) and verify that they have all software patches installed on them. A software patch must never be out for more than 30 days without being installed on your systems. You may also use a tools such as Nessus or Microsoft Baseline Security Analyzer to help find systems that are missing patches.

6.2 Policy Checks

Verify that a policy is in place that outlines a method for receiving notifications about newly discovered security vulnerabilities.

6.2 Hands-on Assessment

Verify that your company is receiving news about the latest vulnerabilities that pertain to your systems. For example, you should be subscribed to an alert service that will send notifications about newly discovered problems. Several such services are freely available on the Internet. Interview employees responsible for securing systems to verify that they are receiving these alerts and are using the information to identify and mitigate new vulnerabilities.

6.3 Policy Checks

Examine your written software development processes to verify that it includes the following items:

• Software must be developed using an industry standard security development lifecycle.
• All changes, including patch, must be tested before the product is deployed.
• The test and development environment must be separate from the production environment.
• There must be separation of duties between personnel assigned to develop and test software and those assigned to the production environment.
• Live account numbers must never be used in development, or they must be sanitized before they are used.
• Test data and accounts must be removed before it is put on production systems.
• Custom application accounts, usernames, and passwords must be removed before applications become active or are released.
• Custom code must be reviewed to identify coding vulnerabilities prior to being put into production or being released to customers.

6.3 Hands-on Assessment

Interview developers to verify that the chosen security development lifecycle is being followed and is working to find and remove vulnerable code. Also verify with those responsible that all changes are tested before they are put into production. Interview employees to verify that testing and development environments are separate from production environments and that there is a separation of duties for personnel assigned to test/development and production environments.

Verify that live account numbers are never used in testing and development, or that they are sanitized before they are used. Take a sample of production systems to verify test data and accounts have been removed before putting a system into production. Verify in the sample that custom application accounts, usernames, and passwords are removed before software is made active or released to customers.

You should also interview employees to verify that an individual or team other than the code author reviews code for security problems before new code is put into production or changes are made to current code.

6.4 Policy Checks

Verify that change control procedures are in place for security patches and software modifications that include the following items;

• Require that there is documentation of customer impact for any change made.
• Appropriate management personnel must sign-off on any changes.
• Operational testing must be performed for any changes.
• A back-out procedure must be in place for any changes.

6.4 Hands-on Assessment

Examine the three most recent software modifications or security patches for a sample of critical system components, and trace verify that the correct procedures were followed. For example, verify that customer impact was documented. Obtain management sign-off forms to verify that the correct management personnel signed off the change before it was done. Interview those who are responsible for testing and verify it was done for the most recent changes. Verify that back-out procedures are documented for each sample change.

6.5 Policy Checks

Verify that your software development process is up-to-date that requires all software is developed using industry-accepted secure coding guidelines such as Open Web Application Security Project (OWASP). It should specifically outline procedures to help secure Web applications against the following common vulnerabilities:

• Invalidated input
• Broken access controls
• Broken authentication and session management
• XSS
• Buffer overflows
• SQL injection or other injection flaws
• Error handling flaws
• Insecure storage
• Denial of service
• Insecure configuration management

6.5 Hands-on Assessment

Interview developers to verify they are using techniques to protect against vulnerabilities outlined in your software development process as described above. Verify with your testing team that these vulnerabilities are being tested for. Verify that programmers are being educated on secure programming techniques.

6.6 Policy Checks

Verify that your company has a policy that requires the use of a Web Application Firewall (WAF) and/or a code review of all custom Web application code. Also verify that code is re-evaluated after corrections are made.

6.6 Hands-on Assessment

Verify that a WAF is in place or that an outside group that specializes in auditing code for security vulnerabilities is performing regular security audits periodically and whenever there is a large change in the code base. If you’re using a WAF, inspect its configuration to ensure that it is updated regularly.

Requirement 7

Requirement 7 ensures that only those who need to know sensitive information are given access to it.

7.1 Policy Checks

Verify that your policy is up-to-date that mandates that only personnel whose job requires that they have access to sensitive data are given access to sensitive data. Your policy must require that management signs a form that authorizes any personnel access to sensitive data.

7.1 Hands-on Assessment

Periodically obtain a sample of management sign-off forms and compare them to the access controls on associated systems, to verify that no more access is given than what is specified on the form.

7.2 Policy Checks

Your policy must require that systems with multiple users are set with default deny-all access to cardholder data, then specifically give access only to users who need access to the information.

7.2 Hands-on Assessment

Take a sample of critical systems and verify that they are set to deny-all access by default, and then only allow those that specifically need access to the information to perform their job. Verify the access controls set are still consistent with user’s current jobs.

Requirement 8

Requirement 8 verifies that unique identification is being used to access systems and that only authorized people can perform operations.

8.1 Policy Checks

A policy must be in place that requires all users to have unique user IDs.

8.1 Hands-on Assessment

Take a sample of user IDs and verify everyone is using a unique username to access systems that contain sensitive data. Depending on the scale of your network, sometimes you can check logs to verify that all logins for a certain ID come from that user’s computer. If you find exceptions (especially if there are a lot of exceptions), you may need to confront that person to see why the logins are taking place elsewhere. If they’ve shared their login information with another user, then proper steps should be taken to educate the user and fix the problem so it doesn’t continue to happen.

8.2 Policy Checks

A policy should be in place that prohibits accounts that only need a user ID to log in. A password, token device, or biometrics must be required to log into any account.

8.2 Hands-on Assessment

Take a sample of critical systems on your network and verify that they are configured to require a username and a password, token device, or biometrics to authenticate users. You may also watch a sample of employees log into critical systems to verify one of the above methods is used in conjunction with their username.

8.3 Policy Checks

A policy must be in place that mandates that two-factor is required for remote access to networks. Technologies such as RADIUS or TACACS with a token, or VPN with individual certificates should be used.

8.3 Hands-on Assessment

Inspect system configurations to verify that technologies that require two-factor authentication are used. Verify that technologies such as Remote Authentication Dial-In User Server (RADIUS) or Terminal Access Controller Access Control System (TACACS) with a token, or a VPN with individual certificates are used. You can also take a sample of employees and ask them to login as if they were logging in remotely, and verify they’re required to use two-factor authentication.

8.4 Policy Checks

A policy must be in place that requires that all passwords on all systems are encrypted when they’re stored or transmitted

8.4 Hands-on Assessment

Take a sample of your system components (including network devices, wireless access points, and critical systems) and verify that passwords are encrypted when stored and transmitted. Most systems by default will only store passwords encrypted. For example, misconfigured Cisco routers can store passwords in the clear. If you are a service provider, take a sample of password files to verify that customer passwords are encrypted.

8.5 Policy Checks

Verify that password polices are in place for non-customer users and administrators that includes the following items:

• Policies must be in place to control addition, deletion, and modification of user IDs.
• Outline a process for verifying a user’s identity when resetting their password, especially if they’ve requested the reset over the phone, e-mail, or other non-face-to-face method.
• Require that first time passwords for new users are not the same.
• Access for terminated employees is removed promptly.
• There are no accounts on the systems that have been inactive for over 90 days.
• Vendor accounts used for remote maintenance must only be active when they are in use.
• All employees that have access to cardholder data must be educated on password policies.
• Group, shared, or generic passwords and accounts cannot be used.
• Passwords must be changed at least every 90 days.
• Passwords must be at least 7 characters long and use both alphabetic and numeric characters.
• Not allow users to reuse any of their pervious four passwords.
• Require that an account is locked after six or more failed login attempts, and remain locked out for 30 minutes or until the administrator unlocks the account.
• Require that sessions that are idle for 15 minutes require the user to re-enter their password.
• Authentication procedures must be in place for all access to databases containing cardholder data.

8.5 Hands-on Assessment

You should have authorization forms for user accounts. Obtain these and verify that the access users are given on systems matches with what the form says they should have. Verify that only administrators have access to administrative consoles on wireless networks. Interview system administrators to verify that they are following company procedures to verify the identity of users when password resets are requested by email, Web, over the phone, or other method that’s not face-to-face. You could test this by choosing a sample of employees and have them request a password reset and verify the correct procedure is followed.

You can interview system administrators to verify that unique first-time passwords are given to new users. You could also test this periodically by using the normal procedure to request two fake new users (use the same procedure that’s in place to set up new users including having management sign a form). Compare the passwords these users have been given to verify they’re not the same, and then promptly have these accounts removed from the system.

You also need to verify terminated employees have their access revoked. To verify this, obtain a list of all employees terminated over the last 6 months and check a sample of these accounts to verify they have been terminated. Inspect systems to verify that there are no accounts on the system that have been inactive for more than 90 days. Also take a sample of vendor accounts used for maintenance and verify they’re only active if they are currently being used.

Interview a sample of users to verify that they understand password policies and that periodic review of policies is taking place. This education can include things such as how to choose a good password, how to get a new password when needed, and how to protect your password (e.g., no post-its with your password and don’t ever give it to anyone under any circumstances).

Take a sample of systems and determine that generic accounts (such as guest) are not enabled. You may also want to review system logs to verify that group and generic accounts are not being used. Review the password policy with system administrators to verify they understand it. As part of this, you should verify that administrators never give out shared accounts even when requested.

Verify that critical servers, system components, and wireless access points require that passwords are changed every 90 days by inspecting the configuration settings on a sample of systems. You can also obtain log files for a sample of systems to find when the last change was made. Verify that the settings for these systems require passwords that are at least 7 characters long with both numeric and alphabetic characters, and that it keeps a history of past passwords and doesn’t allow the user to re-use any of their previous four passwords. Also verify that systems are configured so that after six failed login attempts to an account then that account is locked. A simple way to test this is to use a known account, try to login more than six times, and confirm that the account is locked. The account should stay locked for 30 minutes or until the administrator unlocks it. You may also login to an account and wait for 15 minutes to verify it requires you to login again and check this setting on the servers. You also need to check database servers that contain credit card data and verify they require authentication for any user or application to use it. Also verify that only administrators are allowed to execute SQL queries on the server.

Requirement 9

Requirement 9 verifies that physical security is working. To test this one you will likely have to get up from your desk and do some walking.

9.1 Policy Checks

Verify that a policy is in place that mandates critical systems be physically secured using locks, cameras, and so forth. Also verify that your policy requires that backup tapes are stored for at least three months and that network jacks and network equipment are adequately protected.

9.1 Hands-on Assessment

Verify that badge readers, locks, and other physical security measures are being used to secure systems that store credit card data. One way to test this is to look on your network map and pick a sample of systems and go to the system administrator over that system and have them take you to that system. Verify that cameras are installed and running that monitor traffic into and out of these areas. To verify that tapes are being kept for at least three months, approach the employee that is responsible for archiving tapes and ask for tapes from three months ago.

You also need to verify that publicly accessible jacks are physically protected. For example, conference rooms with network jacks in them should be locked when not in use. Also, measures such as disallowing DHCP in conference rooms would help deter malicious users from using these jacks. Alternatively, if your policy requires it, you can verify that people are escorted at all times when they’re in areas with live network jacks. You also need to verify that wireless access points, gateways, and handheld devices are physically secured (e.g., locked in a closet).

9.2 Policy Checks

A policy must be in place that outlines assigning badges to visitors and precautions that should be taken to protect your environment from malicious visitors.

9.2 Hands-on Assessment

To verify that the policy is being followed, you can observer a contractor or a visitor entering your organization and verify that they get a badge and that it’s easy to distinguish them from employees. Depending on the company you work for, you may even want to invite a friend to visit and verify that they are given a badge. You can also interview employees responsible for badges to verify they understand the policy. You should also periodically educate all users on actions to take if a visitor or someone without a badge is found wandering around your organization.

9.3 Policy Checks

Policies must require that visitors need authorization before entering areas where cardholder data is processed. Also, visitors must be given badges or other physical token that makes them easy to distinguish from employees. Visitor tokens or badges must expire and they must be asked to surrendered them when the visitor exits.

9.3 Hands-on Assessment

Interview employees to verify that authorization is required to enter areas where cardholder data is processed. Verify that employees know what to do if an unauthorized visitor attempts to enter a sensitive area in the company. Compare an employees badge to a visitor’s badge or token to verify that they are different enough to make them easy to distinguish from an employee’s badge. Observe visitors as they leave, to verify that they are asked to surrender their badge.

9.4 Policy Checks

A policy that requires a visitor’s log be kept for at least three months for all visitors that enter your organization, unless this is restricted by law.

9.4 Hands-on Assessment

Ask for a copy of the visitors log and verify it’s being used. You can also invite someone to visit you at work and verify later that his or her name appears in the log. Request copies of logs from three months ago to verify that visitor’s logs are kept for at least three months.

9.5 Policy Checks

Policies must require that off-site backups are in a physically secure and fireproof location.

9.5 Hands-on Assessment

Periodically, visit the site where your media is stored to verify that it is stored in a secure and fireproof location.

9.6 Policy Checks

Policies must mandate that controls are in place for securing paper and electronic media in computer rooms and data centers. This would include items such as receipts, reports, faxes, computers, network systems, CDs, and disks.

9.6 Hands-on Assessment

Visit locations in your organization that should be securely storing paper and electronic media, and verify that the media is being stored in accordance with your company policy. This would also make a great subject for a review class with employees who work with cardholder data.

9.7 Policy Checks

Policies must require that media containing cardholder data be marked confidential. Also, when backups are taken off-site, they must use a secure carrier or other method that can be tracked.

9.7 Hands-on Assessment

Take a sample of media containing cardholder data and verify it is marked “confidential.” Obtain the log that shows any media that is taken off-site and verify it is logged and that it’s being sent using a secured carrier or other method that can be tracked. You can also interview employees to verify that correct processes are being followed for marking sensitive data and sending it off-site.

9.8 Policy Checks

Policies must require that management approve all media that is moved from secure areas.

9.8 Hands-on Assessment

Obtain a recent sample of off-site media tracking logs and verify they had management’s authorization before being moved.

9.9 Policy Checks

Verify that a policy is in place that requires strict control over media that contains credit card data, and that an inventory log is kept.

9.9 Hands-on Assessment

Get a copy of the most recent inventory log to verify that logging and inventory is happening. Go through the log and verify that the media is being stored securely.

9.10 Policy Checks

Policies must require that all media containing cardholder data must be securely destroyed when it is no longer need for legal or business reasons. Hardcopies must be run through a cross-cut shredder, incinerated, or pulped. Electronic media must be purged, degaussed, shredded, or otherwise destroyed in such a way that it cannot be reconstructed.

9.10 Hands-on Assessment

Interview employees to verify that media is being destroyed correctly. Take a sample of devices such as shredders, incinerators, and so forth to verify they work properly. Also, examine containers for material that will be destroyed to verify it’s locked (e.g., a “to-be-shredded” container). Verify that electronic media is being destroyed correctly using a method described in your policy. You should also periodically educate employees on proper procedures to destroy media.

Requirement 10

Requirement 10 is used to verify you are correctly monitoring and testing your networks.

10.1 Policy Checks

A processes must exist for linking all system component access to specific users.

10.1 Hands-on Assessment

Interview system administrators to verify that audit logs are enabled on all systems. You can also take a sample of critical systems, including wireless networks, and verify that audit trails are enabled.

10.2 Policy Checks

Your policy must mandate that audit logs contain enough information to reconstruct the following:

• All access to cardholder data
• Actions taken by administrative privileges must be logged
• Any access to audit logs must be reviewed
• Invalid login attempts
• Identification and authentication mechanism are used
• Initialization of audit logs is logged
• Creation and deletion of system level objects is logged

10.2 Hands-on Assessment

Take a sample of access logs and verify that audit logs contain enough information to reconstruct all of the information above.

10.3 Policy Checks

Your policy must mandate that the following are contained in audit trail entries for all system components:

• User identification
• Type of event
• Date and time stamp
• If it was a success or failure
• Where the event originated
• Name of effected system, component, or resource

10.3 Hands-on Assessment

Get a sample of audit trails from various system components and verify that they include all of the information required above.

10.4 Policy Checks

A policy must be in place that requires that all system clocks are synchronized.

10.4 Hands-on Assessment

Take a sample of various servers to verify their system times are synchronized. Check their settings to verify they’re getting their time from internal Network Time Protocol (NTP) servers instead of external sources (the exception is your NTP server can be receiving updates externally). Also verify that the most recent NTP is being used. You also need to verify that systems are set up to only receive time updates from certain hosts (your internal NTP servers).

10.5 Policy Checks

A policy must require that audit trails are secured so they cannot be altered by any users by including the following items:

• Viewing audit logs must be limited to users who need them for job-related reasons.
• Audit trail files must be protected against unauthorized modifications.
• Audit trail files must be promptly backed up to a centralized server or other media that is difficult to alter.
• Logs from wireless networks must be copied to a log server on the internal Local Area Network (LAN).
• File integrity monitoring and change detection must be in place to verify that log data cannot be altered without alters being generated.

10.5 Hands-on Assessment

Take a sample of systems and verify that only individuals with job-related needs have access to the audit trail files. Verify that current audit trail files are protected using access controls, physical, and/or network segmentation. Verify that the audit trail is being backed up by checking system settings and obtaining backup copies. Periodically restore one of these backups to verify the backup system is working correctly. You also need to verify that integrity monitoring or change detection software is being used to monitor any changes in the access log (adding new events to the audit trail does not need to be logged).

10.6 Policy Checks

Verify that your log review policy is up-to-date and requires that logs are reviewed at least daily on any critical servers, and those that perform security functions such as intrusion detection systems, authorization server, and accounting protocol servers. This daily review can be done using log parsing and alerting tools.

10.6 Hands-on Assessment

Interview employees responsible for daily log reviews to verify they are happening and exceptions are being followed up on. For example, you may want to ask them what events happened that day.

10.7 Policy Checks

Your policy must require that at least a years worth of audit trails be available online or on tape.

10.7 Hands-on Assessment

Take a sample of critical systems and verify that you have at least a years worth of audit trails online or on tape.

Requirement 11

Requirement 11 mandates that you verify that regular security tests are being done on your system.

11.1 Policy Checks

Your policy must require that security controls, limitations, and network connections be tested at least annually to verify that they are working correctly to identify and stop unauthorized access attempts. Wireless analyzers must be used at least quarterly to identify all wireless devices in use.

11.1 Hands-on Assessment

Interview personnel responsible for running periodic tests to verify controls used to stop unauthorized access attempts are being tested as prescribed in the security policy. You should also run Kismet, Netsumbler, or other wireless analyzer to identify all wireless devices on your network.

11.2 Policy Checks

Policies must require that internal and external network vulnerability scans be done at least quarterly or after any significant change in your network.

11.2 Hands-on Assessment

You will likely have an Approved Scanning Vendor (ASV) running external scans quarterly, but you need to run internal ones as well. There are many great commercial and free tools out there to help you do this. A free tool that does very well at assessing network vulnerabilities is Nessus. You may also want to run your own external vulnerability scans to verify that the ASV’s results are accurate.

11.3 Policy Checks

Policies must require that penetration tests must be performed at least annually and after any significant change in your network.

11.3 Hands-on Assessment

Verify that you have the results of the most recent annual penetration tests. Also verify that if there were any large changes to your network that a penetration test occurred and you have the results available. Verify that both network-layer and application-layer penetration tests are performed.

11.4 Policy Checks

Policies must be in place that require that Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) systems are installed, up-to-date and monitored.

11.4 Hands-on Assessment

Verify that your IDS/IPS systems are running and are up-to-date. Also verify that employees are monitoring them and that the alert system is working correctly by checking IDS/IPS configurations and interviewing employees responsible for monitoring them.

11.5 Policy Checks

Policies must require that file integrity software is installed and monitored to detect changes in critical files.

11.5 Hands-on Assessment

Sample systems with critical files to verify that file integrity software is being used and is working correctly. Depending on your setup, you may want to test this by slightly modifying a protected file and verify an alert is sent.

Requirement 12

Requirement 12 is about maintaining your security policy and educating employees about these policies.

12.1 Policy Checks

Your security policy must be up-to-date and address all requirements in the PCI specification. Your policy must also include an annual process for identifying threats and vulnerabilities and perform a formal risk assessment. Your policy must also include a requirement to review the security policy itself at least once a year.

12.1 Hands-on Assessment

Review the policy to verify that it is being kept up-to-date and is being reviewed at least annually. Interview employees to verify that a formal risk assessment is occurring at least annually.

12.2 Policy Checks

Policies must require that daily operational security procedures are consistent with current PCI requirements.

12.2 Hands-on Assessment

Obtain a copy of security procedures and verify they are up-to-date with current PCI requirements. Also verify that your procedures are being followed by employees at your company.

12.3 Policy Checks

Verify that a policy exists for critical technology usage that defines proper use for all employees and contractors. This policy must include the following:

• Management must explicitly approve employee usage of critical technologies.
• Authentication must be in place to use critical technologies.
• A list must be maintained of all devices and personnel with access to critical technologies.
• All devices must be labeled with owner, contact information, and purpose.
• Requirements for acceptable locations on the network for critical technologies.
• A list must be maintained of all company-approved technologies.
• A requirement that requires that modem sessions are disconnected after a predefined period of inactivity.
• Modems for vendors must only be activated when they are needed by vendors, and deactivated immediately after use.
• Require that when cardholder data is accessed remotely via a modem, that it is prohibited to store cardholder data on a local hard drive, floppy disk, or other external media. It should also prohibit copy and paste and print functionality during remote access.

12.3 Hands-on Assessment

Interview management to verify that critical technologies are not being used without management approval. You can also obtain management sign-off forms to verify they are being used. Inspect configurations on a sample of critical systems to verify that authentication is in place to access these systems. Obtain the list of all devices and personnel authorized to use devices and verify that it is up-to-date. Sample network devices to verify they are labeled with owner, contact information, and purpose. Verify that the location of critical technology is in compliance with your security policy. Verify that products being used are on the list of company-approved products. Sample modems to verify they are configured to automatically disconnect after a predefined period of inactivity, and vendor modems are only activated when needed by vendors. Interview employees to verify that cardholder data is not being stored locally or on removable media, and that copy-and-paste and print functionally is prohibited during remote access.

12.4 Policy Checks

Verify that your policy is up-to-date that defines employee and contractor’s security responsibilities.

12.4 Hands-on Assessment

Interview employees and contractors to verify that they understand their security responsibilities.

12.5 Policy Checks

Review that the following assignments are up-to-date in the security policy:

• Somebody is responsible for creating and distributing security policies and procedures.
• Somebody is formally assigned to monitor and analyze security events and distributing information to appropriate personnel.
• Somebody is formally assigned to create and distribute security incident response and escalation.
• Somebody is formally assigned to manage administrative accounts.
• Somebody is formally assigned monitor all access to data.

12.5 Hands-on Assessment

Interview employees to verify they understand and are following the polices as described above.

12.6 Policy Checks

Verify that your policy outlines a formal security awareness program to make all employees aware of the importance of cardholder data security. This should include educating employees when they are hired and at least annually. There must also be a requirement that mandates employees sign a form acknowledging they have read and understand the company’s security policy and procedures.

12.6 Hands-on Assessment

Interview a sample of employees, some new and some older, and verify that they have been properly educated on the company’s security policies and procedures. Also verify that you have forms on file that show they have read and understand the procedure.

12.7 Policy Checks

A policy must be in place that requires that Human Resources perform background checks on new employees before they are hired.

12.7 Hands-on Assessment

Interview Human Resources to verify that background checks are happening.

12.8 Policy Checks

Verify that new contracts with service providers contain language that requires compliance with PCI standards that and that the third party is in charge of securing cardholder data.

12.8 Hands-on Assessment

Review a sample of contracts with third parties to verify that PCI compliance and securing cardholder data is part of the contract.

12.9 Policy Checks

Verify that your Incident Response Plan is up-to-date and that your policy requires that it’s tested at least annually. Verify that you are aware of any new laws that you would need to comply with in the event of the compromise and that your incident response plan is updated accordingly. Also verify that your policy requires that personnel is available 24/7 to respond to alerts. It should require that employees are trained to know how to respond to security breaches. Your policy should also contain a requirement for intrusion detection and prevention and fire integrity monitoring.

12.9 Hands-on Assessment

Interview employees to verify that the plan is being well tested at least annually. Verify that you are researching new laws that would impact the requirements in your incident response plan. Also verify that there is somebody on alert 24/7 to respond to problems. Verify that your staff is being adequately trained on how to respond to a security breach. Also verify that intrusion detection and file integrity monitoring are in place and are being monitored.

12.10 Policy Checks

Verify that you have a policy in place for managing connections to processors and service providers that includes the following items:

• An up-to-date list of connected entities.
• Require that proper due diligence is happening before connecting to an entity.
• Require that any entity that you are connecting to is PCI compliant.
• Require that connecting and disconnecting follows and established process.

12.10 Hands-on Assessment

Obtain your list of connected entities and verify that it is up-to-date. Also interview employees to verify that due diligence is being performed prior to connecting to processors and service providers. Verify that as part of this check they verify that they are PCI compliant. Also interview employees to verify that processes for connecting and disconnecting to processors and service providers is being followed.

Summary

Security is fleeting. You’ve got it one minute and it’s gone the next, but there are some steps that can be taken to keep yourself as secure as possible. Working with management and employees you can keep your company in a good position to combat many attacks now and in the future. Some very important parts to help keep you secure now and in the future is keeping your policy up-to-date, periodically assessing your security, and periodic training.

Solutions Fast Track

Security is a PROCESS, not an event

• You can’t achieve security; it’s a never ending process.
• You must constantly be assessing and working to mitigate risks.

Planning for periodic review and training, don’t stop now

• You should plan now to train and review.
• Train your employees regularly to keep them reminded and up-to-date on company policies.
• Review the PCI requirements regularly to keep yourself up-to-date.

Performing a PCI Self Audit

• Regularly audit your systems to ensure they are still PCI compliant.
• Regularly review your policies to verify they are up-to-date and are working at your company.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.