“The Council is looking for equivalent controls that address malware and all types of threats referenced in Requirement 5, which are often found in traditional anti-virus solutions. If another type of solution (application whitelisting, for example) addresses the identical threats with a different methodology than a signature-based approach, it may still be acceptable to meet the requirement.”

This is an important step forward for organizations who must meet PCI Data Security Standards (DSS) to prevent malware on their endpoints. Many recent attacks that have led to card holder data theft have involved a wide blend of techniques that featured placing malware on servers and other endpoints. This was certainly the case in the recent data breach involving the Heartland data breach where a variety of malware, backdoors, and packet sniffers were placed on key systems and resulted in the loss of over 130 million credit card numbers.

Application whitelisting would have gone far to thwart these types of threat. By restricting applications that are authorized on a given system, it removes the threat of a hacker using an unpatched vulnerability to place malicious code on the system because that code will not be allowed to run.

We applaud the PCI Security Standards Council for taking this step and moved their standard officially forward to address the serious threat of malware on endpoints. This is something that standards like NERC-CIP have also embraced and will certainly be more prevalent in the future. We are happy to see that our call to action in our recent post “Time For an Update of PCI Anti-Virus Requirements: Take a lesson from NERC CIP” has come to pass so quickly.

Nearly 80 percent of retailers and organizations that handle credit card transactions have been hit with a data breach, but more than 70 percent still don’t consider security strategic to their operations, according to a new report released today.

This apparent incongruity has more to do with organizations accepting a certain level of risk with doing business on the Internet, says Brian Contos, chief security strategist at Imperva, which commissioned the 2009 PCI DSS Compliance Survey conducted by the Ponemon Institute.

“Roughly 30 percent take [PCI security] seriously,” Contos says. “And the others see it as a check box.”

Despite the fact that 80 percent of retailers have experienced a data breach, only 70 percent consider security strategic to their operations and only 30 percent take PCI security seriously. The question is, is this an indictment of the retailers or the PCI standards themselves?

It doesn’t help that there have been a number of data breaches in the news recently where the victim was fully PCI compliant. In fact, Robert Carr, the CEO of Heartland, the company that was a victim of a data breach that exposed over 100 million credit cards, slammed both his auditors and PCI standards in a recent interview:

What have you learned in recent months regarding how exactly the burglars were able to get in? What have investigators flagged in terms of the big security holes that were exploited?
Carr: “The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem. The QSAs in our shop didn’t even know this was a common attack vector being used against other companies. We learned that 300 other companies had been attacked by the same malware. I thought, ‘You’ve got to be kidding me.’ That people would know the exact attack vector and not tell major players in the industry is unthinkable to me. I still can’t reconcile that.”

How did the QSAs respond when you expressed this view?
Carr: “In the post-Enron environment, the auditors have contracts with clients that essentially absolve them of gross negligence. The false reports we got for 6 years, we have no recourse. No grounds for litigation. That was a stunning thing to learn. In fairness to QSAs, their job is very difficult, but up until this point, we certainly didn’t understand the limitations of PCI and the entire assessment process. PCI compliance doesn’t mean secure. We and others were declared PCI compliant shortly before the intrusions.”

A key to this story is something that everyone should understand. PCI Compliant doesn’t mean you are secure. Carr stating that a company the size of Heartland didn’t understand this is questionable in my opinion, but the failure of their auditors to expose known vulnerabilities with clear fixes is a problem as well.

The PCI guidelines simply provide a minimum framework for establishing a secure environment. It is up to the company to provide the appropriate people and processes to support their technology investments to create a secure environment.

The culprit? Unauthorized code on their servers resulted in the exposure of the credit card data. Despite the protections employed to protect the card data on servers, they were done in by simple malware on a system in their infrastructure.

The exposure experienced by Network Solutions is not unique. One of the greatest threats to any company connected to the Internet is the prevalence of malware and the number of systems that belong to botnets. We recently blogged about two botnets formed by the new clampi trojan and the older conficker malware. Unfortunately, traditional blacklist antivirus technology is no longer capable of preventing infection and standards that target the protection of critical assets ought to take that into account.

To that extent, I would like to contrast the two requirements mandating system security in PCI DSS relative to those in NERC CIP. NERC CIP requirements calls for security that can detect, prevent, deter, and mitigate malware. The actual R4 requirement from NERC-CIP 007 is shown here:

• R4. Malicious Software Prevention – The Responsible Entity shall use antivirus software and other malicious software (“malware”) prevention tools, where technically feasible, to detect, prevent, deter, and mitigate the introduction, exposure, and propagation of malware on all Cyber Assets within the Electronic Security Perimeter(s).
• R4.1. The Responsible Entity shall document and implement antivirus and malware prevention tools. In the case where antivirus software and malware prevention tools are not installed, the Responsible Entity shall document compensating measure(s) applied to mitigate risk exposure or an acceptance of risk.
• R4.2. The Responsible Entity shall document and implement a process for the update of antivirus and malware prevention “signatures.” The process must address testing and installing the signatures.

PCI on the other hand does not have this granularity and focuses instead solely on the use of antivirus. Here is the relevant PCI requirement mandating the use of antivirus:

• 5.1. Deploy antivirus software on all systems commonly affected by malicious software (particularly personal computers and servers).
• 5.1.1. Ensure that all antivirus programs are capable of detecting, removing, and protecting against all known types of malicious software.
• 5.2. Ensure that all antivirus mechanisms are current, actively running, and capable of generating audit logs.

The security of the systems in an organization’s IT infrastructure remains one of the greatest challenges to providing strong security. Application whitelisting’s purpose in life is to prevent unauthorized code from residing on critical assets. It’s time for organizations to start thinking about how they can proactively protect these devices instead of simply providing a checkbox for antivirus. Let us know what you think in the poll above.