In the spring of 2005, someone broke into a web application for the Assignment Management System of the United States Air Force, and stole 33,000 records. As data breaches go — judged by numbers alone — this is a drop in the bucket. But judging by extent of loss, the breach was expansive. The hackers stole the names, career information, birth dates, social security numbers, marital status, number of children and academic records of 33,000 Air Force Officers. Three years later, no one knows where the data went.
In June of this year, Section 6.6 of the PCI Data Security Standards (DSS) becomes mandatory. Online merchants that process credit card payments must either conduct a code review for their applications or install an application-layer firewall. The standard offers a choice, but there really isn’t any choice at all. If an organization is going to successfully protect its data, it must aim for preventing a breach, not passing an audit. This means, first, finding and fixing the vulnerabilities in software, second, building security into the development process, and third, protecting applications once they’re deployed.
Hannaford Bros, a supermarket chain based in New England, passed a PCI audit and then got hacked. They lost 4.2 million credit and debit card numbers, which has led to 1,800 cases of fraud to date. During the past two years, as the PCI standards have slowly been implemented, the number of data breaches has increased from 158 incidents in 2005 to 443 incidents in 2007, for a total of 212 million records. In other words, the bad guys are still out in front of the good guys. And that’s why PCI keeps evolving. But, in order to win this battle, companies must invest in security, not just in compliance.
The USAF responded to their breach with a multi-million dollar effort to identify and eliminate their security holes. This initiative incorporated a heavy reliance on source code analysis to fix the problems at the root cause, as well as targeted investments in application firewalls, web application scanning tools, and database firewalls. The key to their approach was having the right motivation. They didn’t launch this initiative to pass an audit. They did it to ensure their software was secure. The result has been a comprehensive and dedicated deployment. As software drives nearly every military activity today, it’s comforting to know they have the right approach to deal with the threat.
The PCI council knows that analyzing the code early is the right thing to do, as they stress the importance of building security into the development process. All following quotes come from the PCI council, and they all emphasize the importance of the code.
- “…it is recommended that reviews and scans also be performed as early as possible in the development process.”
- “Tools should be made available to software developers and integrated into their development suite as much as practical.”
- “The reviews or assessments should be incorporated into the SDLC and performed prior to the application’s being deployed into the production environment.”
- “Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines.”
- “Review custom application code to identify coding vulnerabilities.”
- “Cover prevention of common coding vulnerabilities in software development processes.”
Bottom line: build security in. If you want to have the best chance of passing a PCI audit and preventing a breach, fix the code first, and then monitor it in real-time.
PCI Section 6.6 is a productive step forward and encourages companies to do just this, but as with many standards, companies can interpret the mandates in many ways. A bad interpretation and a weak implementation will mean a false sense of security. Passing a PCI compliance audit is necessary, but compliance alone does not protect your company from a breach.