PCI DSS 2.0 Fun Facts

| January 1, 2011

pci-compliance.jpgBy Dr. Anton Chuvakin @ Security Warrior Consulting

Do not think of PCI DSS 2.0, that came out this October, as “PCI DSS 1.3!”

Instead, think about is as PCI DSS 1.2.2.  Despite the great fanfare, the changes in PCI DSS are small and tactical.  Don’t get me wrong, a lot of very useful clarifications, reminders and explanations have been added to the standards – both PCI DSS and PA-DSS.  However, a lot of media attention has made it sound as if the PCI Council has “changed everything … again,” and that is simply not the case.  Some of the requirements that are frequently seen by merchants as too specific have been made more generic, while some that have received criticism for being too have vaporous, have been tightened down.

Let’s go through a few of the interesting changes in PCI DSS and try to predict what the impact would be in the coming year of 2011 as PCI DSS 2.0 is put into practice.

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:/root}

First, the standard now reminds us that the “use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide.” This small change is incredibly useful, in my opinion, as many merchants have mistakenly assumed that the use of the payment application from PA-DSS list somehow magically makes them PCI compliant. Many breaches have resulted from PA-DSS listed applications being implemented in blatantly insecure (and non-compliant) manner – all the way down to remote access from the Internet without a password.

Also important is the newly highlighted need to “verify that no cardholder data exists outside of the currently defined cardholder data environment.” This makes scoping the environment easier and thus alleviating some of the more common PCI concerns and scoping “errors.”

A long-awaited change to PCI DSS requirements concerns virtualization – but with a stretch – it can be called a major change. The infamous requirement 2.2.1 now says that “where virtualization technologies are in use, implement only one primary function per virtual system component.” Virtualization now officially in – and that is a good and timely change to the standard.

Another interesting changed area is related to ranking of vulnerabilities and patch or mitigation planning. It is not official that merchants must “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.” My guess here is that a lot of people read too much into this change of Requirement 6.2. It pretty much means the same: “bad vulnerability to a PCI-scope system? Fix it soon!”

I don’t believe it will lead to reduced patching and increased risk acceptance, but there is such risk.  In any case, this is what sensible organizations have been doing since the beginning of time… ehh… the 1990s. CVSS rankings – including not only base but environmental scores – are a great way to accomplish it.

An example of change where the requirements have been made more generic concerns log management.  Specifically, Requirement 10.4 now avoids the mention of NTP and instead states: “using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.” There are no new requirements (you still need to sync time), but there are more details added and specific technology references removed. There is definitely more importance placed on this one in PCI 2.0, as this is the way to assure that log data would be useful for analysis and review.

On the wireless side, the standard has added examples of technologies that can help with wireless security: “methods that may be used in the process [or wireless ‘scanning’] include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.”  Unfortunately, I predict that many organizations will choose the lowest and the least effective methods mentioned above – wireline discovery of rogue access points.

It is interesting how a small, seemingly insignificant, change may cause a lot of good. I predict that separating internal vulnerability scanning into a separate requirement will do just that. A new 11.2.1 states: “Perform quarterly internal vulnerability scans.”  It used to be rolled into 11.2 and separation is a good idea: internal scanning was completely ignored by many merchants, sadly. And now this requirement got its own number and would be easier to track. Same thing happened to scanning after changes (a new 11.2.3) which is just as good. Finally, ‘rescan internal until fixed’ is a useful reminder for merchants who sometimes just scan for scanning’s sake.

Another change concerns the risk management process: “Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)”  Indeed, adding specific examples to Requirement 12.1.2 as well as a testing procedure is handy. We just don’t need people creating their own silly “risk” “assessment” methods…

Another additional clarification concerns IDS and IPS deployment: “Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment, and alert personnel to suspected compromises.” This made 11.4 more palatable to merchants and easier to validate since it used to just say “use IDS/IPS.”

So, is PCI DSS perfect now? Well, we know better than that – no external standard can ever make anybody secure or even “as secure as they need.” Still, PCI now sports many small but useful changes that will help merchants protect the cardholder data. This version has a potential of surviving unscathed for three years, as per the council’s new lifecycle.

ABOUT THE AUTHOR:

Dr. Anton Chuvakin (http://www.chuvakin.org/) is a recognized security expert in the field of log management and PCI DSS compliance.  He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook"; he is now working on a book about computer logs.  Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list http://www.info-secure.org/) . His blog http://www.securitywarrior.org/ is one of the most popular in the industry.

In addition, Anton teaches classes (including his own SANS class on log management) and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries.  He works on emerging security standards and serves on the advisory boards of several security start-ups.

Currently, Anton is running his security consulting practice http://www.securitywarriorconsulting.com/, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations.  Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University. 

Category: /root

Comments are closed.