Last week I had the pleasure of conducting a 1 day Advanced PCI course that included details of the changes between v2.0 and v3.0. It was clear that there is not only continued confusion regarding the ‘new’ content, but that the less scrupulous vendors of QSA and penetration testing services are using this confusion to charge more for the same service.
I have warned of this previously, but let’s be very clear. If you are being asked for more money based on the v3.0 changes, your service provider is:
- Confused about what the changes mean themselves;
- Covering up for not performing their work properly in previous years;
- Lying to you.
I fully understand the pressures QSA companies are under with regard price compression, competition and so forth, but using this DSS update to raise prices is unconscionable.
Here is an example;
Requirement 1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
In v2.0 of the DSS the ‘Testing Procedures’ states; “1.3.3 Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”
In theory, the QSA could just say; “[QSA company] verified that direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.” However, in the ‘ROC Reporting Instructions for PCI DSS v2.0, September 2011‘ your QSA is responsible to do far more;
Identify the network documents/diagrams specifying that direct connections are not allowed for traffic between the Internet and the cardholder data environment:
i. Inbound ii. Outbound
Describe how observed firewall/router configurations prevent direct connections between the Internet and the cardholder data environment:
i. Inbound ii. Outbound
Describe how observed traffic between the Internet and the cardholder data environment confirms that direct connections are not permitted:
i. Inbound ii. Outbound
Now look at v3.0; “1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”
Other than changing ‘verify’ to ‘examine’, the reporting instructions are STILL not fully built into the new standard, but are getting closer. So the vast majority of the DSS v3.0 is just clarification of validation requirements based on a document that is already more than 2 years old.
To put this another way; your QSA and YOU were responsible for performing 95% of what’s in the v3.0 for the last 2 years. The other 5% are things you SHOULD have been doing anyway if your QSA was doing their job, and you were doing security properly:
2.4 – Maintain an inventory of system components that are in scope for PCI DSS
Seriously? How could you have EVER achieved compliance without having an asset inventory of some sort?
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
Verify that coding techniques actually address the ‘high vulnerabilities’? What ELSE would it be doing?
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.
The sad part is that they actually had to add this, as a lot of breaches were caused by NOT having this in place. Vendor due diligence is almost universally poor across PCI relevant service providers, and this is entirely the fault of each organisation, not the SSC.
9.9 Examine documented policies and procedures to verify they include:
Maintaining a list of devices
Periodically inspecting devices to look for tampering or substitution
Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices
If you weren’t doing this already you deserve what you get.
10.x [Logging Stuff]
Significant clarification of what’s expected in logging and monitoring, and will only negatively impact those organisations doing the bare minimum to get through PCI.
11.3.x [Penetration Testing Stuff]
Nothing in here is different from the intent of penetration testing all the way back to v1.0, and if your QSA says things have changed, they have been doing it wrong all along.
12.8.x [Service Provider Stuff]
The only organisations this will negatively affect are service providers who were hiding the true extent of their service coverage, and clients trying to outsource responsibility of PCI compliance to others. If your organisation’s vendor due diligence and vendor management programs don’t already cover this, it’s your fault.
If you want a more complete listing of the changes, go here; PCI DSS v3.0 – Mapping to v2.0_v07NOV13.xlsx
Every QSA company has training courses, white papers, presentations and God knows what else trying to explain the difference between v2.0 and v3.0. If you want to save your time and money, learn how to do SECURITY properly and PCI will make perfect sense.
Take the phrase ‘cardholder data’ out of the DSS and replace it with ‘personal information about your family’. Name ONE requirement you don’t want in place?