Posts
PCI DSS v2.0 was officially released in October 2010 and demonstrated that changes had been made mainly for clarity to maintain the quality of assessments. There have been numerous changes, many of which seek to be more specific around test procedures that are required. The other main changes to the standard are highlighted below:
- Scoping;
- Inclusion of Virtualisation;
- Storage;
- Time Synchronisation;
- Scanning;
- Wireless and IDS/IPS;
- Evolving Requirements: Applications.
Scoping
As with any PCI DSS assessment, it is important that proper scoping is conducted. Changes have been made to ensure that the scope has been clearly defined with emphasis on the following points:
- Requirement to identify all locations of cardholder data flow;
- Explicit requirement for merchants / service providers to identify and explicitly define all of the locations and flows of cardholder data annually before they begin their assessment;
- Documentation must be presented that shows how the PCI DSS scope was confirmed and the scoping results so that the assessor can review and accept as evidence if appropriate;
- Consider all areas of stored electronic and physical media containing cardholder data. This should include (but not be limited to) databases, mail orders, faxes, call recordings, emails, temporary files and log files;
- “System components” also include any virtualisation components.
- Organisations may need to be more proactive and spend more time understanding where cardholder data is processed, stored or transmitted;
- Expect the QSA to spend more time verifying the scope, specifically the data flows and storage locations;
- Expect to be asked to present evidence of how the controls are adequate to segment the scope, and prove that testing has been conducted outside of this scope to ensure that there is no additional pollution.
Virtualisation is now officially recognised and therefore all virtualised system components should be reviewed to determine whether they are in scope for PCI DSS. If they are in scope, then the PCI DSS controls will apply depending on the context of the components. For example:
- Virtualised servers would require all PCI DSS requirements applicable for servers;
- Virtualised firewalls and routers would require all PCI DSS requirements applicable for firewalls and routers;
- Virtualised system components would require all PCI DSS requirements applicable for that particular type of system component.
- Including virtualised system components within the scope should not come as a surprise. If virtualisation technologies have not been included in the scope before, then your QSA may spend time reviewing the setup and corresponding documentation for that component;
- Sysnet have always applied the requirements in this manner, so there should be minimal uplift to any customers engaged with our QSA’s.
Emphasis has been made to prevent access to both truncated and hashed versions of the PAN as well as the PAN itself. With special tools, it takes a trivial amount of time and effort to use these two elements to generate a PAN.
Review the following:
- Implementation of controls to ensure that the hashed and truncated values cannot be correlated to reconstruct the original PAN;
- Whether you need to keep both truncated and hashed versions –if you don’t need it, don’t store it.
Main impact:
- Adding additional controls may provide additional expenses;
- It may prove difficult to add additional controls depending on your implementation;
- Storage of both versions may be by design currently, and making this change may prove difficult. Further work would need to be conducted to understand the risk and impact around any change.
It is important to ensure that your clocks are accurate, in order to aid any forensic work. To support this, there must be clear and documented processes for distributing time through your cardholder data environment.
Previously there has been a bias towards using NTP. In the new standard references to any particular technology is removed.
Whatever time synchronisation you decide to use, make sure you use approved sources and have the distribution of time documented appropriately.Main impact:
- Flexibility to use other time synchronisation technologies that may be more suitable for your environment;
Scanning
This is a very important area to consider. PCI DSS requirement 11.2 is now split into further subtests to explicitly conduct internal (11.2.1) and external (11.2.2) test procedures for vulnerability scanning. Why? In many cases organisations may rely on external vendors to conduct external testing. This change may indicate that organisations fall into trouble when required to demonstrate internal testing.
- Conduct internal testing at least on a quarterly basis;
- Conduct internal rescans until there is a passing scan;
- Document scanning procedures and provide document evidence of the outcome of both internal and external scans.
- For those who have not conducted internal testing you should start this process as soon as possible. Failure to demonstrate the required internal testing evidence could jeopardise your next PCI compliance review.
Organisation should not neglect the fact that rogue wireless devices are easy to implement and therefore post a significant threat. A few changes have been made:
- PCI DSS requirement 2.1.1 is split into further test procedures, but something is missing? There is no reference to WPA (or in fact any wireless technology);
- PCI DSS requirement 11.1 includes “physical/logical inspections of system components and infrastructure”;
- PCI DSS v2.0 mandates that IDS/IPS may be configured to monitor the perimeter and all critical points within the cardholder data environment.
- Organisations will need to give consideration to moving to WPA2 some serious thought. Or they will need to bolster the current wireless implementations with enterprise level security rather than just using Pre-Shared Keys (PSK). A better position may be to, ask yourself “Is sending cardholder data over wireless the best way”. Again, if you don’t need it then don’t use it;
- Physical/logical inspections of system components provides greater flexibility to meet the test procedures, especially for small organisations with few resources, who currently may not be knowledgeable in using specialist wireless scanning and IDS/IPS software;
- Wireless IDS/IPS systems at critical points in the CDE, may mean less system management overheads and potentially less false positives.
Two extra requirements that PCI DSS v2.0 has included to spice things up will keep those involved with software development and patching busy:
- PCI DSS requirement 6.2 not only requires the ability to identify security vulnerabilities, but also to assign a risk ranking;
- PCI DSS 6.5 has been refined as a reminder that the requirements apply to all software and not just web applications. Furthermore, 6.5.6 requires addressing of “High” risk vulnerabilities, which have been identified using the new risk ranking processes in PCI DSS requirement 6.2.
- Organisations must start developing risk ranking processes at their earliest opportunity;
- This risk ranking could also work in your favour. The standard risk ranking provided by the vendors may not be appropriate within your environment. This may allow additional time for testing and scheduled rollout rather than reactionary installation;
- Organisations will be required to spend time demonstrating proper secure software development lifecycle for all internally-developed applications within scope for PCI DSS.
To the relief for most organisations, PCI DSS will have minimal impact. The changes made have been for clarity of the test procedures and in recognition of advancing technology and threats. The main points are:
- Organisations should properly scope where their cardholder data is. It is difficult to secure the data if it is not known where it is;
- Expect your QSA to spend more time verifying the scope, reviewing the current technologies (which may now be considered not fit for purpose) and gathering evidence.
Will there be future updates to the PCI DSS?
The PCI DSS now uses a three-year life cycle and the next standard should be released around October 2013. The following diagram is taken from the official Lifecycle for Changes to PCI DSS and PA-DSS demonstrating the phases of the three year cycle.
Based on PCI DSS v2.0, it is envisaged that the new version will: - Have further improvements in scoping;
- Clarifying assessment procedures;
- Include considerations for advances in technology as well as threats;
- Other areas as we do not yet know what the future holds.
Final reminder to organisations
It is imperative that organisations focus on their business processes and not just the technology. All organisations must understand they are obliged to protect customers cardholder data –PCI DSS applies all year and it is not just for the assessment.
As advances are made to technology, standards and regulations, organisations must not stand still. All organisations should consider undergoing QSA lead “health-checks” throughout the year to accommodate and review the impact of the change, in order to assist them with remaining PCI DSS compliant.
For further information on our PCI compliance services, please contact one of our Sales representatives by calling +353 (0)1 495 1300 or by completing our Online Enquiry Form or Request a Call Back Form.
