The Payment Card Industry has been shaken recently by numerous breaches that have successfully exploited malware on Point-of Sale (POS) systems to steal payment card data at retailers of all sizes around the country. Backoff and BlackPOS are two of the latest variations of memory scraping malware that targets POS systems and is responsible for the theft of cardholder data in over 1,000 organizations in the U.S. alone.
The majority of these merchants reported compliance with the PCI Data Security Standard (DSS) at the time they were breached. As an information security professional who has performed numerous PCI DSS validation assessments, including many breached entities; I’d like to clear up a few misconceptions about the whole PCI compliance program.
PCI is about security – not compliance. That has been a foundational component of the PCI DSS since the beginning, but this foundational concept has been misunderstood and misapplied (for numerous reasons) so the PCI Security Standards Council felt they had to spell it out in PCI DSS v3.0 and make it explicitly clear that security activities as prescribed by the framework should be built into your daily, continuous “business as usual” practices.
PCI is about security – not compliance.
The PCI validation process has never been just a report on compliance (which only about 1% of companies actually have to provide) and evidence of passing quarterly external scans. It is a comprehensive security framework that has six major goals that any security expert would say “yes, that about covers it,” divided into 12 major areas and in excess of 400 specific controls in PCI DSS v3.0. The six major areas are as follows:
- Build and maintain a secure network
- Protect cardholder data
- Maintain a vulnerability management program
- Implement strong access control measures
- Regularly monitor and test networks
- Maintain an information security policy
The PCI DSS, as a set of security requirements, does not presume that organizations will not be breached, but rather tries to set organizations up for detecting the compromise early, and hopefully minimizing the damage. Now in its third major version release, the PCI DSS stands as a fairly comprehensive framework for building and maintaining an effective information security program. PCI DSS v3.0 includes an explicit call to make the standard a part of daily “business as usual” security activities which reflects the basic security practices that most security professionals would agree must be followed by any company:
- Monitoring of security controls to ensure they are operating effectively and as intended.
- Ensuring that all failures in security controls are detected and responded to in a timely manner.
- Review of changes to the environment prior to completion of the change, and:
- Determining the potential impact to PCI DSS scope (for example, a new firewall rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS).
- Identifying PCI DSS requirements applicable to systems and networks affected by the changes (for example, if a new system is in scope for PCI DSS, it would need to be configured per system configuration standards, including FIM, AV, patches, audit logging, etc., and would need to be added to the quarterly vulnerability scan schedule).
- Updating PCI DSS scope and implement security controls as appropriate.
- Formal review of the impact to PCI DSS scope based on organizational changes.
- Periodic reviews and communications to confirm that PCI DSS requirements are in-place and personnel are following secure processes.
- Review of hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS.
The PCI security framework has not been properly presented, embraced, practiced, or assessed by the PCI community at large
The root of the problem is that so many companies have been required to put a security program in place and they take a minimal approach, struggle to hire and retain qualified security professionals, and rely on security technologies to do the job in an automated fashion so they are victimized by countless vendors selling an endless array of point solutions. You need technology involved to combat the threat to your technology, and you need qualified people at the controls. This largely doesn’t happen in these companies. Period.
The PCI security framework has not been properly presented, embraced, practiced, or assessed by the PCI community at large – rather the majority of effort goes into minimizing the “cost” and “easing the burden” of having to comply with PCI security standards. The PCI DSS has never been a point-in-time assessment – but that is what vendor marketing likes to claim it is, and customers unwittingly believe it.
There are numerous reasons why this is the case, but one significant problem is the way vendors are relatively unregulated in terms of the “solutions” they offer, and they are often the only “expertise” to which the majority of companies have any access or exposure. Even worse, the vendors tend to be the primary influencers of the PCI standards as a whole. I attended the 2014 North American PCI Community Meeting last week and based on what the Council announced by way of new “interpretation” and “guidance” within numerous presentations during the meeting, the vendors are continuing to successfully influence the Council’s interpretations and guidelines in order to assure their products/solutions can meet the requirements.
Is poorly practiced security better or worse than no security?
The most obvious case was evidenced in the “clarification” of the new Self-Assessment Questionnaire A-EP where the Council seemed to back off its published qualification that outsourced websites would need to adhere to a greatly expanded subset of PCI DSS requirements and also require ASV scanning of the website itself. Web hosting companies clearly won a political battle in order to continue offering “quick and easy” websites to their clientele.
PCI has been working for 10+ years. There are thousands of companies that now have some semblance of a security program where they had none before, and wouldn’t have if not for the PCI security program.
Has any other regulatory compliance standard or security framework had as long a shelf-life or far reaching impact on as many companies as PCI has had? I’m not aware of any.
So the question remains: is poorly practiced security better or worse than no security?
No matter any of our opinions, PCI is not going away any time soon.