So, I posted this to my corporate blog as well, but wanted to save myself a copy in case it isn't received very well over there. Enjoy.
PCI DSS version 1.2 will be available for general use tomorrow, October 1. The SSC has standardized on a 24-month cycle for revisions and new versions, so other than the potential for additional supplements or clarifying documents, this is it for the next couple of years. The summary of changes document is here, and the FAQ for the summary of changes is here. Obviously you can read the actual document yourselves, so I’m not going to reproduce it here verbatim. However, I will happily critique the changes.
As usual, I’ll be candid with you: I’m very disappointed in the SSC for what amounts to trivial changes that fall far short of improving the standard in a meaningful way. Let’s have a look at the finished product.
Requirement 1 – A much needed change related to the review of firewall rules. After heavy lobbying from participating organizations, the required review frequency has been reduced to every six months, down from once per quarter.
Requirement 2 – meh. Ok, they removed references to WEP, but seriously, if any merchant is still using WEP after the TJ Max debacle, you deserve to get owned.
Requirement 3 – meh.
Requirement 4 – SAY WHAT?! Quote, “No new WEP implementations allowed after March 31, 2009” and “current implementations must be discontinued by June 30, 2010.” Sadly, those are NOT typos. Merchants, note my comment regarding Requirement 2, regardless of what the SSC is saying.
Requirement 5 – What exactly does “AV must address all known types of malicious software” mean? Do these guys even use anti-virus software?! Apparently not, else they would know the major players often need a miracle just to detect the most prevalent malware out there right now, much less address it (XP Antivirus 2008 anyone?).
Requirement 6 – whoop-dee-do. Web Application Security deserved the most attention out of this revision, hands down. Epic fail for the SSC. Edit: Removed the bashing of the SSC for not changing the compliance requirement to the latest OWASP Top 10 version. As someone pointed out in the comments of my corporate blog, the new assessment procedures list "the latest OWASP Top 10" as the guideline for compliance, and specifically list the 2007 categories. That said, they still fail in the area of more meaningful requirements in arguably the least secure area of enterprises.
Requirement 7 – meh.
Requirement 8 – meh.
Requirement 9 – meh.
Requirement 10 – duh.
Requirement 11 – Ok, we got some decent clarification here. Believe it or not, there were some organizations out there that thought they could get away with “some cheap, young hackers” doing their quarterly assessments. Names withheld to protect the guilty and clueless. The SSC also clarified that internal, as well as external penetration tests are required, and that any qualified consultant or firm can perform the tests – they do not have to be a QSA or ASV. This is great news for my Indy brothas and sistas out there (sup Fish!). Note, HP is an ASV, so this hasn’t ever been an issue for us.
Requirement 12 – meh overall, but I realize this was needed to combat the “check in the box” mentality of a lot of companies out there. Now, other than the specific examples cited with each requirement, there is something the next version of the DSS sorely needed – laboratory and/or hands-on verification of requirement compliance, a la what they started with the PA-DSS. All QSAs and designated SAQ persons are not created equal, and they need some help. There are a lot of shenanigans going on out there that could be eliminated with a detailed checklist of what to look for when validating the compliance of technical solutions – e.g. Web Application Firewalls. I wanted to see specific items validated such as a policy review, logs (look for proof of inspection and blocks), and configuration (is it in monitor, learn, or block mode?).
Finally, I’d like to see a technical QSA designation – someone that has a system integrator’s knowledge of networks, systems, and the policy and processes necessary to truly comply with the spirit of the DSS and secure our Enterprises. In conclusion, I hope the authors of version 1.2 weren’t getting paid, but if they were, the SSC needs to get their money back.
PCI DSS version 1.2 will be available for general use tomorrow, October 1. The SSC has standardized on a 24-month cycle for revisions and new versions, so other than the potential for additional supplements or clarifying documents, this is it for the next couple of years. The summary of changes document is here, and the FAQ for the summary of changes is here. Obviously you can read the actual document yourselves, so I’m not going to reproduce it here verbatim. However, I will happily critique the changes.
As usual, I’ll be candid with you: I’m very disappointed in the SSC for what amounts to trivial changes that fall far short of improving the standard in a meaningful way. Let’s have a look at the finished product.
Requirement 1 – A much needed change related to the review of firewall rules. After heavy lobbying from participating organizations, the required review frequency has been reduced to every six months, down from once per quarter.
Requirement 2 – meh. Ok, they removed references to WEP, but seriously, if any merchant is still using WEP after the TJ Max debacle, you deserve to get owned.
Requirement 3 – meh.
Requirement 4 – SAY WHAT?! Quote, “No new WEP implementations allowed after March 31, 2009” and “current implementations must be discontinued by June 30, 2010.” Sadly, those are NOT typos. Merchants, note my comment regarding Requirement 2, regardless of what the SSC is saying.
Requirement 5 – What exactly does “AV must address all known types of malicious software” mean? Do these guys even use anti-virus software?! Apparently not, else they would know the major players often need a miracle just to detect the most prevalent malware out there right now, much less address it (XP Antivirus 2008 anyone?).
Requirement 6 – whoop-dee-do. Web Application Security deserved the most attention out of this revision, hands down. Epic fail for the SSC. Edit: Removed the bashing of the SSC for not changing the compliance requirement to the latest OWASP Top 10 version. As someone pointed out in the comments of my corporate blog, the new assessment procedures list "the latest OWASP Top 10" as the guideline for compliance, and specifically list the 2007 categories. That said, they still fail in the area of more meaningful requirements in arguably the least secure area of enterprises.
Requirement 7 – meh.
Requirement 8 – meh.
Requirement 9 – meh.
Requirement 10 – duh.
Requirement 11 – Ok, we got some decent clarification here. Believe it or not, there were some organizations out there that thought they could get away with “some cheap, young hackers” doing their quarterly assessments. Names withheld to protect the guilty and clueless. The SSC also clarified that internal, as well as external penetration tests are required, and that any qualified consultant or firm can perform the tests – they do not have to be a QSA or ASV. This is great news for my Indy brothas and sistas out there (sup Fish!). Note, HP is an ASV, so this hasn’t ever been an issue for us.
Requirement 12 – meh overall, but I realize this was needed to combat the “check in the box” mentality of a lot of companies out there. Now, other than the specific examples cited with each requirement, there is something the next version of the DSS sorely needed – laboratory and/or hands-on verification of requirement compliance, a la what they started with the PA-DSS. All QSAs and designated SAQ persons are not created equal, and they need some help. There are a lot of shenanigans going on out there that could be eliminated with a detailed checklist of what to look for when validating the compliance of technical solutions – e.g. Web Application Firewalls. I wanted to see specific items validated such as a policy review, logs (look for proof of inspection and blocks), and configuration (is it in monitor, learn, or block mode?).
Finally, I’d like to see a technical QSA designation – someone that has a system integrator’s knowledge of networks, systems, and the policy and processes necessary to truly comply with the spirit of the DSS and secure our Enterprises. In conclusion, I hope the authors of version 1.2 weren’t getting paid, but if they were, the SSC needs to get their money back.
No comments:
Post a Comment