Filed under: IIS & HTTP
PCI DSS is a set of standards developed by major credit card companies to keep credit card information secure and reduce fraud. The standards apply to any organization that processes, stores, or transmits credit card data. Occasionally, the PCI Security Standards Council will announce updates to the standards, which may require approved companies to make changes to their security hardware, software, and practices. The latest updates (PCI DSS Standards 3.0) were introduced a few months back, but recent documentation has shed a bit more light on you need to do to start preparing for compliance once the new rules come into effect on January 1, 2014.
The full Requirements and Security Assessment Procedures can be read here.
Business as Usual
In the previous version of the PCI DSS standard, the method of security acted as a one-point-in-time check box. This meant that organizations weren’t necessarily compliant throughout the year, but rather prepared for a specific test date. The overarching theme of the new requirements is an approach to make PCI DSS compliance a business as usual practice of ongoing securing, testing, evaluation, and education.
Inventory System Components
This is one of the new requirements (Req. 2.4) that may end up being quite a headache for IT to keep up with. Going forward, an inventory of all system components – both hardware and software – will need to be tracked, including a description and function/use for each. The guidance states that the purpose of this is to “enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls.” This means anytime a new piece of hardware or software is added or replaced, organizations will need to update their inventory. This could get fairly tiresome considering how quickly things tend to change in IT.
Systems not commonly affected by malware and antivirus will now have to undergo periodic evaluations (Req. 5.1.2). This requirement implements personnel interviews to “verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software” so as to confirm that such systems can continue in use without anti-virus. The goal of this requirement is to ensure that systems evolve as threats do, and that organizations stay apprised of any changes in the threat landscape.
The pentesting rules (Req. 11.3 and 11.3.4) are some of the more beefy new requirements found in PCI DSS 3.0. The new rules indicate that a methodology for penetration testing must be implemented and should be based on industry-accepted pentesting approaches, such as NIST SP800- 115, which is the “Technical Guide Information Security Testing and Assessment” from the National Institute of Standards and Technology.
- Includes testing from both inside and outside the network
- Includes testing to validate any segmentation and scope-reduction controls
- Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
- Defines network-layer penetration tests to include components that support network functions as well as operating systems
- Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
- Specifies retention of penetration testing results and remediation activities results
The new penetration testing guidance is quite extensive, but only remains a best practice until June 30, 2015 after which is becomes a requirement.
Keeping Track of Service Providers
Two requirements that pertain to companies like Port80 Software (those who provide tools or services that help achieve PCI DSS compliance) are Requirements 12.8.5 and 12.9. Requirement 12.8.5 speaks to the need to keep track of vendors that provide such services: “maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.” Requirement 12.9 focuses on the need for service providers to acknowledge in writing that they assume responsibility for the security of cardholder data that “the service provider possesses or otherwise stores.”
Key PCI DSS Requirements
- Req. 2.4 – maintain an inventory of system components in scope for PCI DSS to support development of configuration standards NEW!
Req. 5.1.2 – evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software NEW!
- Req. 5.3 – ensure that anti-virus solutions are actively running (formerly in 5.2), and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis NEW!
- Req. 6.5.10 – for coding practices to protect against broken authentication and session management (Effective July 1, 2015)
- Req. 8.2.3 – combined minimum password complexity and strength requirements into one, and increased flexibility for alternatives
- Req. 8.5.1 – for service providers with remote access to customer premises, use unique authentication credentials for each customer* NEW!
- Req. 8.6 – where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) these must be linked to an individual account and ensure only the intended user can gain access NEW!
- Req. 9.3 – control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination
- Req. 9.9 – protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution
- Req. 11.3 and 11.3.4 – implement a methodology for penetration testing; if segmentation is used to isolate the cardholder data environment from other networks, perform penetration tests to verify that the segmentation methods are operational and effective NEW!
- Req. 11.5.1 – implement a process to respond to any alerts generated by the change- detection mechanism
- Req. 12.3.8 – procedure to verify policy is implemented for disconnecting remote access sessions after a specific period of inactivity NEW!
- Req. 12.8.5 – maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity NEW!
- Req. 12.9 – for service providers, provide the written, agreement/acknowledgment to their customers as specified at requirement 12.8.2 NEW!
In the press release announcing the new requirements, Derek Brink, Vice President and Research Fellow at the Aberdeen group addressed the positive changes. “The stakeholders in the payment card community seem to be working to put security and compliance in the right relationship – i.e., that compliance does not drive security; compliance is the result of foundational security practices.”
A world where security is based on the implementation and execution of best practices rather than driven by rules and compliances is indeed a more secure one. At Port80, we agree with this approach, but understand the challenges associated with it. If your organization has questions or needs help tackling PCI DSS version 3.0, please get in touch and we’ll be glad to lend a hand.No Comments »