04-11-19 | References
The new PCI DSS 3.0 document contains a number of clarifications, additional guidance and evolving requirements, according to how the PCI SSC refers to the changes. The part we’re going to focus on is the evolving requirements, as they represent the changes that ensure that the standards are up to date with emerging threats and changes in the market. They also represent the greatest changes between the old and new documents, and are relevant to merchants and service providers that are already PCI DSS compliant, but may need to update according to the newly added requirements.
1.1.3 – Current diagram that shows all cardholder data flows across systems and networks
Why they added it: Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network. Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices.
2.4 – Maintain an inventory of system components that are in scope for PCI DSS.
Why they added it: Maintaining a current list of all system components will enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls. Without an inventory, some system components could be forgotten, and be inadvertently excluded from the organization’s configuration standards.
5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.
Why they added it: Typically, mainframes, mid-range computers (such as AS/400) and similar systems may not currently be commonly targeted or affected by malware. However, industry trends for malicious software can change quickly, so it is important for organizations to be aware of new malware that might affect their systems—for example, by monitoring vendor security notices and anti-virus news groups to determine whether their systems might be coming under threat from new and evolving malware.
Trends in malicious software should be included in the identification of new security vulnerabilities, and methods to address new trends should be incorporated into the company’s configuration standards and protection mechanisms as needed
5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.
Why they added it: Anti-virus that continually runs and is unable to be altered will provide persistent security against malware.
Use of policy-based controls on all systems to ensure anti-malware protections cannot be altered or disabled will help prevent system weaknesses from being exploited by malicious software. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active—for example, disconnecting the unprotected system from the Internet while the anti-virus protection is disabled, and running a full scan after it is re-enabled.
Note: 6.5.10 applies to web applications and application interfaces (internal or external). Additionally, the requirement is a best practice until June 30, 2015, after which it becomes a requirement:
6.5.10 – Broken authentication and session management
Why they added it: Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.
8.2.3 – Passwords/phrases must meet the following:
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
Why they added it: This requirement specifies that a min. of seven characters and both numeric and alphabetic characters should be used for passwords/phrases. For cases where this min. can’t be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. NIST SP 800-63-1 defines “entropy” as a “measure of the difficulty of guessing or determining a password or key.”
8.5.1 – Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.
Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.
Why they added it: To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer. Technologies, such as two-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.
8.6 – Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
Why they added it: If user authentication mechanisms such as tokens, smart cards, and certificates can be used by multiple accounts, it may be impossible to identify the individual using the authentication mechanism. Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely identify the user of the account will prevent unauthorized users from gaining access through use of a shared authentication mechanism.
9.3 – Control physical access for onsite personnel to the sensitive areas as follows:
Why they added it: Controlling physical access to the CDE helps ensure that only authorized personnel with a legitimate business need are granted access. When personnel leave the organization, all physical access mechanisms should be returned or disabled promptly (as soon as possible) upon their departure, to ensure personnel cannot gain physical access to the CDE once their employment has ended.
9.9 – Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
Note: These requirements apply to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.
Note: Requirement 9.9 is a best practice until June 30, 2015, after which it becomes a requirement.
Why they added it: Criminals attempt to steal cardholder data by stealing and/or manipulating card-reading devices and terminals. For example, they will try to steal devices so they can learn how to break into them, and they often try to replace legitimate devices with fraudulent devices that send them payment card information every time a card is entered. Criminals will also try to add “skimming” components to the outside of devices, which are designed to capture payment card details before they even enter the device—for example, by attaching an additional card reader on top of the legitimate card reader so that the payment card details are captured twice: once by the criminal’s component and then by the device’s legitimate component. In this way, transactions may still be completed without interruption while the criminal is “skimming” the payment card information during the process.
This requirement is recommended, but not required, for manual key-entry components such as computer keyboards and POS keypads.
Additional best practices on skimming prevention are available on the PCI SSC website.
10.2.5 – Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges
Why they added it: Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts that may have been used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account.
10.2.6 – Initialization, stopping, or pausing of the audit logs
Why they added it: Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions.
11.1 – Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.
Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices
Why they added it: Implementation and/or exploitation of wireless technology within a network are some of the most common paths for malicious users to gain access to the network and cardholder data. If a wireless device or network is installed without a company’s knowledge, it can allow an attacker to easily and “invisibly” enter the network. Unauthorized wireless devices may be hidden within or attached to a computer or other system component, or be attached directly to a network port or network device, such as a switch or router. Any such unauthorized device could result in an unauthorized access point into the environment. (More in the PCI DSS 3.0 doc…)
11.3 – Implement a methodology for penetration testing that includes the following:
Note: This update to Requirement 11.3 is a best practice until June 30, 2015, after which it becomes a requirement. PCI DSS v2.0 requirements for penetration testing must be followed until v3.0 is in place.
Why they added it: The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment.
This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks. (More in the PCI DSS 3.0 doc…)
11.3.4 – If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.
Why they added it: Penetration testing is an important tool to confirm that any segmentation in place to isolate the CDE from other networks is effective. The penetration testing should focus on the segmentation controls, both from outside the entity’s network and from inside the network but outside of the CDE, to confirm that they are not able to get through the segmentation controls to access the CDE. For example, network testing and/or scanning for open ports, to verify no connectivity between in-scope and out-of-scope networks.
11.5.1 – Implement a process to respond to any alerts generated by the change-detection solution
Why they added it: See above.
12.2 Implement a risk-assessment process that:
Why they added it: A risk assessment enables an organization to identify threats and associated vulnerabilities with the potential to negatively impact their business. Resources can then be effectively allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized.
Performing risk assessments at least annually and upon significant changes allows the organization to keep up to date with organizational changes and evolving threats, trends, and technologies.
12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
Why they added it: Knowing your service providers’ PCI DSS compliance status provides assurance and awareness about whether they comply with the same requirements that your organization is subject to. If the service provider offers a variety of services, this requirement should apply to those services delivered to the client, and those services in scope for the client’s PCI DSS assessment.
The specific information an entity maintains will depend on the particular agreement with their providers, the type of service, etc. The intent is for the assessed entity to understand which PCI DSS requirements their providers have agreed to meet.
12.9 Additional requirement for service providers: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Note: This requirement is a best practice until June 30, 2015, after which it becomes a requirement.
Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.
Why they added it: This requirement applies when the entity being assessed is a service provider. In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities.
The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.
The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.
