Why PCI DSS cannot replace common sense and holistic risk assessment

Last week, the Federal Trade Commission (FTC) gave 45 days to nine QSA companies to respond to detailed questions about how they measure compliance with the PCI DSS. Credit card fraud statistics recently published at NASDAQ states that approximately 31.8 million US consumers had their credit cards breached in 2014, more than three times the number affected in 2013. Numerous data breaches of PCI compliant companies in the past years have put PCI DSS efficiency into question. However, the vast majority of the breached companies have at least one of the following points in common:

• Missed or incomplete PCI requirements for some part of their in-scope infrastructure.
• Wrong Cardholder Data Environment (CDE) scope definition, omitting systems that must be in the scope.
• Ad-hoc security control implementation, passing compliance for the sake of compliance, not data security.
• Incomplete risk management strategy, lack of continuous risk re-assessment and monitoring.

Compliance is not designed to eliminate cybercrime

As well as any other cybersecurity compliance standards, PCI DSS is not designed to stop hacking and cybercrime, it’s rather a minimum acceptable security level that any merchant accepting payments by credit cards must maintain. PCI compliance is like a driving license: it allows you to drive on public roads, however if you cause an accident resulting in serious damage, nobody will blame the licensing authority for issuing your license or put in question the overall efficiency of driving licenses.

The driving license cannot totally prevent accidents, neither can PCI totally eliminate security breaches. Moreover, if every car driver would respect all the rules of road, we could have avoided 99% of accidents and save millions of lives. But unfortunately, it’s just impossible to control every single driver even for alcohol before getting behind the wheel, not even speaking about unintentional driving mistakes. The same principles apply to PCI DSS – it just defines the minimum security level before allowing a merchant to accept credit card payments, but it cannot, and is actually not designed to, eliminate the cybercrime and data breaches.

[ ALSO ON CSO: Practical tips to ensure PCI DSS compliance when dealing with message queues ]

Ninety-nine percent of car accidents are caused by mistakes (intentional or not). It would be fair to say that 99% of breached PCI compliant companies were actually breached because some parts of the PCI DSS standard were not (entirely) enforced and respected at the time of the breach.

Practical examples: PCI DSS compliance for web applications

If we exclude data breaches via trusted third parties, physical attacks (skimming, attacks against PoS terminals, etc) and insider threats, the majority of the remaining security incidents usually start or involve insecure web applications. So, let’s have a more detailed look on what PCI DSS 3.1 requires for the in-scope web applications, and what common sense can suggest in order to achieve both security and compliance.

PCI DSS requirement 6: “Develop and maintain secure systems and applications” is probably one of the most important requirements for the [web] applications in scope of CDE. However, many organizations often misinterpret the requirement as well as its practical implementation.

For example, PCI requirement 6.2 says to “install critical security patches within one month of release”. The Council maintains such a long delay due to some complicated production systems, where every single patch needs to be thoroughly tested before deployment into production. For the majority of e-commerce web applications, however, the deadline of critical flaws patching should be within eight business hours, otherwise you just invite cybercriminals into your network. Many people say that PCI doesn’t care about merchants’ systems availability, however if it were the case, the deadline would be 24 hours or less.

Requirements 6.3 and 6.4 address secure SDLC, change control and secure coding standards within the organization. However, even the most competent software developers fall victim to emergent business needs, fatigue, or group mistakes leading to insecure code and configurations deployed to production servers. When you have one hour to build a new feature to outperform the competitor, you can hardly speak about secure coding and relevant code testing procedures. Therefore, if management decides to be competitive on the market sacrificing cybersecurity, it shall not have any illusions that last year’s PCI compliance audit will prevent any upcoming security problems.

Requirement 6.6 demands that merchants either deploy a web application firewall, or conduct regular security assessments of the in-scope web applications to address common coding vulnerabilities (at a minimum all vulnerabilities in requirements 6.5.x, highlighting that “the vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum baseline”). The standard provides merchants with a great freedom of security control selection to comply with the requirement, saying that the assessment can be performed by “using either manual or automated vulnerability security assessment tools or methods”.

However, today no automated software can reliably detect all the 6.5.x vulnerabilities in all cases. For example the 6.5.10 “Broken Authentication and session management” or 6.5.8 “Improper Access Control” are very complicated to detect using only automated DAST and even SAST tools. However, as almost every vulnerability scanner that exists on the market today proudly claims that it detects all variations of such flaws, many merchants consider quarterly scanning of their web applications an ultimate solution for the 6.6 requirement. Obviously, once compromised, many stakeholders start erroneously blaming PCI DSS inefficiency.

Holistic and ongoing risk assessment is the key both to security and compliance

Omitting wrongly defined CDE, an incomplete or irregular risk assessment is even worse than partial PCI DSS misinterpretation: often a CDE isolation can be easily bypassed if the entire corporate network is compromised. Make sure that your corporate risk assessment process covers not only the CDE scope, but also all other systems and networks on an ongoing basis. PCI DSS should be a baseline for any corporate IT infrastructure that has an ingoing or outgoing Internet connection, not only for the CDE.

Jan Schreuder, Partner, cybersecurity leader from PwC Switzerland comments: “PCI DSS compliance is only one element of your overall security risk management approach. We often see organizations take a ‘tick the box’ approach to PCI DSS compliance without a full understanding and assessment of the cyber threats they face, the potential impact of those threats on their business, and the key controls they have in place to manage the risks. This often leads to spreading their security budget and resources too thinly rather than focusing them on the controls that are really important to manage the risks.”

Make sure that you know how to drive, and you will easily get your driving license. Make sure that your primary goal is to secure your network and data in an efficient and ongoing manner, and you will easily pass PCI DSS compliance.