Yesterday, I blogged about the new PCI DSS 3.0 document that contains a number of clarifications, additional guidance and evolving (new) requirements. The part I’m 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.
Yesterday, I blogged about the new PCI DSS 3.0 document that contains a number of clarifications, additional guidance and evolving (new) requirements. The part I’m 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.
For a complete list of the new PCI DSS 3.0 requirements, visit our site: PCI DSS 3.0: Complete List of Newly Added Requirements.
More Read
8.2.3 – Passwords/phrases must meet the following:
- Require a minimum length of at least seven characters.
- Contain both numeric and alphabetic characters.
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 minimum 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:
- Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
- Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
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:
- Access must be authorized and based on individual job function.
- Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.
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 sothat 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.
(Data security / shutterstock)
