Security Audit: The Pitfalls of Third-Party Assessments

Posted on by John Linkous

Everyone is aware of last year’s data breach at Target. Millions of records of cardholder data were stolen and Target is still recovering, with current costs at $148 million. What's not well-known, or openly discussed, is the behind-the-scenes conversations the company has had with its PCI assessor and the standards organization.

The PCI Security Standards Council (SSC), consisting of major credit card companies including VISA, MasterCard, and American Express (and others), developed  the data security standards dictating how cardholder data (including credit and debit card numbers, and personal identifying information of the cardholders) should be processed, transmitted, and stored. The council has long mandated that retailers implement minimum security controls before they can accept credit and debit cards for payment.

After the retailer implements security, someone has to verify it. In this case, that is the PCI assessor, who functions as a qualified security assessor (QSA). In effect, the PCI assessor functions as the eyes and ears of the PCI SSC.

Of course, the Target data breach threw a big wrench into that relationship. What happens when the assessor gives a green light to the retailer, but the retailer experiences a data breach anyway? Such is the problem we are currently faced with.

While we are talking about PCI SSC here, this situation could just as easily have happened with the North American Electric Reliability Corporation (NERC) over the CIP energy standard, the Department of Health and Human Services (DHHS) with HIPAA, or the Public Company Accounting Oversight Board (PCAOB) regarding SOX. There are some critical lessons to be learned from the Target-PCI scenario.

For the standards body, it's important to understand that there is a big difference between intent and what's in the published standard. It's the job of the PCI SSC to make sure that there is no room for ambiguity between the organization that conducts assessments on their behalf and the retailers who are controlling cardholder data.

For security audit firms, it's an important lesson in being thorough—and an understanding that history can bite you if you're not careful. The PCI assessor in question allegedly gave a green-light PCI assessment prior to the data breach; they're now facing a whirlwind of legal issues, not to mention a public relations nightmare. Taking a "greatest common denominator" approach to security assessments will minimize these types of risks.

Finally, for retailers, perhaps the most important lesson is simply one of diligence. While it's true that—even with standards such as those PCI applied—there's no such thing as "100% secure," the spirit of these standards is that they're intended to be a starting point, not a definitive and complete solution to the problem of insecurity.

For organizations that process, store, and transmit cardholder data, the security of that information needs to be one of their top concerns (right after remaining financially viable). But it's important to remember that standards like those established by PCI are not an end state: They're a starting point. Similarly, auditors need to remember that they are representing the standards body—and in most cases, cutting corners or accepting less-than-reasonable compensating controls is not an option. Finally, the standards bodies themselves need to ensure that they're providing enough prescriptive detail to avoid any gaps between how a retailer or assessor evaluates a security control and what was intended. It's only when all three groups are on the same page that the number of data breaches will be reduced, and everyone wins.

John Linkous

, Technology Advisor

Business Perspectives

risk management legislation

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community