The New PCI Software Security Framework — What You Need To Know Now

The Payment Card Industry Security Standards Council just launched the PCI Software Security Framework targeting application security. After over a year of work with a broad expert task force, on which I served as a volunteer to provide feedback on the new standards, the first two standards — the Secure Software Standard and the Secure Life Cycle (Secure SLC) Standard — were released January 16. The Validation Framework is scheduled for later this year.

The council is making these changes to respond to the massive changes in the software world. The old standards didn’t align well with modern software development, which is driven by Agile and DevOps, cloud, containers, application programming interfaces and open-source libraries. The new standards raise the bar significantly, but they also give companies a lot more flexibility in how they protect their applications and APIs.

A major theme in the new standard is the idea of “continuous application security.” First, organizations have to continuously monitor threats and defenses and adapt if the threat changes. Second, they must continuously test application security controls and provide evidence that they are not weak, ineffective or flawed. Notice that the burden is on the development organization to produce this evidence. The qualified security assessor will review it to ensure that it is accurate, complete and compelling.

Here are the big takeaways from this new release:

1. Get started now. The new framework is a big change from what’s come before. Organizations should get started right now to adapt their processes and tools to get ready for compliance with this new approach. I recommend downloading a copy of the standards and doing a quick review to see where you have significant gaps. If you’ve identified your threats, selected strong defenses and tested those defenses (with evidence), and you have visibility into application layer attacks, you should be in pretty good shape. If not, now is the time to start getting ready.

2. Start using IAST. Organizations now have the flexibility to choose the best approach for verifying each requirement. The standard adds the new and powerful Interactive Application Security Testing as an approved option for automated security testing. Historically, the PCI required “code review” or automated scanning, which introduces slowdowns, bottlenecks and false alarms. In the new standard, you can choose the best approach to testing for your business. IAST is the latest approach to testing modern web applications and web APIs and is generally easier, faster and more accurate than legacy tools.

3. Shift left and shift right. The new standard acknowledges that security testing must occur early in the software development process, rather than a scan or penetration test pre-deployment. This is really extending left. But, more importantly, the PCI has also acknowledged that application security must extend right into production, with attack detection and exploit prevention in operational environments.

4. Get your open source under control.Most companies don’t have a handle on exactly which open source they are building their business on, much less exactly which version of each library is running on every development, test and production server. Under the new standards, you’re going to have to know which open-source libraries you are using, continuously monitor for new vulnerabilities and deploy protection within hours of a new disclosure. You may want to look at runtime application self-protection to prevent vulnerabilities from being exploited and give you breathing room to respond.

5. Understand your threat model. The new standard isn’t just a list of controls that you have to have even if they don’t make sense. The new model is objective-based, meaning that you can choose the defenses you actually need based on the threats your software actually faces. Creating threat models for your business applications and APIs isn’t difficult. I’d recommend creating a business-level threat model and then more specific models at the application layer.

I think these new standards are probably going to be disruptive for organizations building software, particularly if you’ve been treating PCI as a compliance, check-the-box exercise. But from a security perspective, the new standard isn’t an unreasonably high bar. The requirements here are what I would consider a bare minimum for sites handling credit card data. I’ve called it “basic blocking and tackling.” Organizations should take solace in the fact that doing security right generally accelerates software development, enables innovation and saves money — even in the short term.

The PCI standards have always been controversial, and this new framework will certainly cause a lot of discussion. But I believe that over time, the PCI council has helped raise the bar for millions of organizations, from huge credit card companies to mom-and-pop stores. I’m confident this standard will do the same.