Document Comparison
PCI-DSS-v1.0.pdf
→
pci_dss_v1-1.pdf
72% similar
12 → 17
Pages
5107 → 6435
Words
34
Content Changes
Content Changes
34 content changes. 12 administrative changes (dates, page numbers) hidden.
Added
p. 2
Requirement 12: Maintain a policy that addresses information security 2 Payment Card Industry (PCI) Data Security Standard This document describes the 12 Payment Card Industry (PCI) Data Security Standard (DSS) requirements. These PCI DSS requirements are organized in 6 logically related groups, which are “control objectives.” The following table illustrates commonly used elements of cardholder and sensitive authentication data; whether storage of each data element is permitted or prohibited; and if each data element must be protected. This table is not exhaustive, but is presented to illustrate the different types of requirements that apply to each data element.
PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.
* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements …
PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.
* These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements …
Added
p. 6
Requirement 3: Protect stored cardholder data Encryption is a critical component of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.
Added
p. 6
• Strong one-way hash functions (hashed indexes)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key management processes and procedures.
The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.” 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control 6 Payment Card Industry (PCI) Data Security Standard mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key management processes and procedures.
The MINIMUM account information that must be rendered unreadable is the PAN.
If for some reason, a company is unable to encrypt cardholder data, refer to Appendix B: “Compensating Controls for Encryption of Stored Data.” 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control 6 Payment Card Industry (PCI) Data Security Standard mechanisms (for example, by not using local system or Active Directory accounts). Decryption keys must not be tied to user accounts.
Added
p. 7
• As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
• At least annually. 3.6.5 Destruction of old keys 3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key) 3.6.7 Prevention of unauthorized substitution of keys 3.6.8 Replacement of known or suspected compromised keys 3.6.9 Revocation of old or invalid keys 3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.
Requirement 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit.
• At least annually. 3.6.5 Destruction of old keys 3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key) 3.6.7 Prevention of unauthorized substitution of keys 3.6.8 Replacement of known or suspected compromised keys 3.6.9 Revocation of old or invalid keys 3.6.10 Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.
Requirement 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit.
Added
p. 7
• Use with a minimum 104-bit encryption key and 24 bit-initialization value
• Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS
• Rotate shared WEP keys quarterly (or automatically if the technology permits)
• Rotate shared WEP keys whenever there are changes in personnel with access to keys
• Restrict access based on media access code (MAC) address. 4.2 Never send unencrypted PANs by e-mail.
• Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS
• Rotate shared WEP keys quarterly (or automatically if the technology permits)
• Rotate shared WEP keys whenever there are changes in personnel with access to keys
• Restrict access based on media access code (MAC) address. 4.2 Never send unencrypted PANs by e-mail.
Added
p. 9
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.
• Installing an application layer firewall in front of web-facing applications.
Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.
Added
p. 10
• Token devices (e.g., SecureID, certificates, or public key)
Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis if something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis if something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
Added
p. 13
• added to the environment). These penetration tests must include the following: 11.3.1 Network-layer penetration tests 11.3.2 Application-layer penetration tests. 11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up-to-date. 11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files; and configure the software to perform critical file comparisons at least weekly. Critical files are not necessarily only those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and …
Added
p. 17
The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Companies should be aware that a particular compensating control will not be effective in all environments. Each compensating control must be thoroughly evaluated after implementation to ensure effectiveness.
The following guidance provides compensating controls when companies are unable to render cardholder data unreadable per requirement 3.4.
Compensating Controls for Requirement 3.4 For companies unable to render cardholder data unreadable (for example, by encryption) due to technical constraints or business limitations, compensating controls may be considered. Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.
Companies that consider compensating controls for rendering cardholder data unreadable must understand the risk to the data posed by maintaining readable cardholder …
The following guidance provides compensating controls when companies are unable to render cardholder data unreadable per requirement 3.4.
Compensating Controls for Requirement 3.4 For companies unable to render cardholder data unreadable (for example, by encryption) due to technical constraints or business limitations, compensating controls may be considered. Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.
Companies that consider compensating controls for rendering cardholder data unreadable must understand the risk to the data posed by maintaining readable cardholder …
Removed
p. 1
Requirement 12: Maintain a policy that addresses information security Note that these Payment Card Industry (PCI) Data Security Requirements apply to all Members, merchants, and service providers that store, process or transmit cardholder data. Additionally, these security requirements apply to all “system components” which is defined as any network component, server, or application included in, or connected to, the cardholder data environment. Network components, include, but are not limited to, firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Servers include, but are not limited to, web, database, authentication, DNS, mail, proxy, and NTP. Applications include all purchased and custom applications, including internal and external (web) applications.
Modified
p. 1 → 2
Requirement 1: Install and maintain a firewall configuration to protect data
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Modified
p. 1 → 2
Requirement 3: Protect stored data
Requirement 3: Protect stored cardholder data
Modified
p. 1 → 2
Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks Maintain a Vulnerability Management Program
Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program
Modified
p. 1 → 2
Requirement 7: Restrict access to data by business need-to-know
Requirement 7: Restrict access to cardholder data by business need-to-know
Modified
p. 1 → 2
Requirement 11: Regularly test security systems and processes.
Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy
Removed
p. 2
Requirement 1: Install and maintain a firewall configuration to protect data.
Firewalls are computer devices that control computer traffic allowed into a company’s network from outside, as well as traffic into more sensitive areas within a company’s internal network. All systems need to be protected from unauthorized access from the Internet, whether for e-commerce, employees’ Internet-based access via desktop browsers, or employees’ email access. Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.
Firewalls are computer devices that control computer traffic allowed into a company’s network from outside, as well as traffic into more sensitive areas within a company’s internal network. All systems need to be protected from unauthorized access from the Internet, whether for e-commerce, employees’ Internet-based access via desktop browsers, or employees’ email access. Often, seemingly insignificant paths to and from the Internet can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.
Modified
p. 3 → 5
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Hackers (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information.
Removed
p. 4
Requirement 3: Protect Stored Data Encryption is the ultimate protection mechanism because even if someone breaks through all other protection mechanisms and gains access to encrypted data, they will not be able to read the data without further breaking the encryption. This is an illustration of the defense in depth principle.
Removed
p. 5
Requirement 4: Encrypt transmission of cardholder and sensitive information across public networks.
Sensitive information must be encrypted during transmission over the Internet, because it is easy and common for a hacker to intercept and/or divert data while in transit.
Sensitive information must be encrypted during transmission over the Internet, because it is easy and common for a hacker to intercept and/or divert data while in transit.
Removed
p. 5
Many vulnerabilities and malicious viruses enter the network via employees’ email activities. Anti-virus software must be used on all email systems and desktops to protect systems from malicious software.
Modified
p. 5 → 8
Requirement 5: Use and regularly update anti-virus software or programs.
Requirement 5: Use and regularly update anti-virus software or programs Many vulnerabilities and malicious viruses enter the network via employees’ e-mail activities. Anti-virus software must be used on all systems commonly affected by viruses to protect systems from malicious software.
Modified
p. 5 → 8
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 via vendor security patches, and all systems should have current software patches to protect against exploitation by employees, external hackers, and viruses. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
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. All systems must have the most recently released, appropriate software patches to protect against exploitation by employees, external hackers, and viruses. Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed …
Removed
p. 6
This ensures critical data can only be accessed in an authorized manner.
Modified
p. 6 → 9
Requirement 7: Restrict access to data by business need-to-know.
Requirement 7: Restrict access to cardholder data by business need-to-know This requirement ensures critical data can only be accessed by authorized personnel.
Removed
p. 7
This ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Modified
p. 7 → 10
Requirement 8: Assign a unique ID to each person with computer access.
Requirement 8: Assign a unique ID to each person with computer access Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
Modified
p. 8 → 11
Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data allows the opportunity to access devices or data, and remove systems or hardcopies, and should be appropriately restricted.
Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted.
Removed
p. 9
Requirement 10: Track and monitor all access to network resources and cardholder data.
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
Modified
p. 9 → 12
• added should not cause an alert). 10.6 Review logs for all system components at least daily. Log reviews should include those servers that perform security functions like IDS and authentication (AAA) servers (e.g RADIUS). 10.7 Retain your audit trail history for a period that is consistent with its effective use, as well as legal regulations. An audit history usually covers a period of at least one year, with a minimum of 3 months available online.
• added should not cause an alert). 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.
Removed
p. 10
• added to environment). 11.4 Use network intrusion detection systems, host-based intrusion detection systems, and/or intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up to date. 11.5 Deploy file integrity monitoring to alert personnel to unauthorized modification of critical system or content files, and perform critical file comparisons at least daily (or more frequently if the process can be automated). Critical files are not necessarily those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the merchant or service provider.
Modified
p. 10 → 13
Requirement 11: Regularly test security systems and processes Vulnerabilities are continually being discovered by hackers/researchers and introduced by new software. Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and through changes.
Requirement 11: Regularly test security systems and processes Vulnerabilities are being discovered continually by hackers and researchers, and being introduced by new software. Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and with any changes in software.
Modified
p. 10 → 13
• added to environment, web server
• added to the environment, or a web server
Removed
p. 11
A strong security policy sets the security tone for the whole company, and lets employees know what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it.
Modified
p. 11 → 14
Requirement 12: Maintain a policy that addresses information security for employees and contractors.
Requirement 12: Maintain a policy that addresses information security for employees and contractors A strong security policy sets the security tone for the whole company and informs employees what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it.