Is the Payment Card Industry Data Security Standard (PCI DSS) a useful guideline for implementing application security, or should organizations take steps beyond the mandated PCI compliance checklist?
An important first point to make is that compliance is not security. Organizations viewing it as such are going to run into problems regardless of whether they use the PCI compliance checklist or another set of compliance standards.
There are a couple of reasons for this. These standards are "one size fits all," and the process that creates them tends to water down their effectiveness. In addition, many organizations try to minimize the scope of their PCI exposure, and this can lead to decisions that are defensible within the strictures of the standards but do not actually address relevant risks appropriately. Checking checkboxes will not make you secure.
Organizations should aim to move beyond the 'all or nothing' approach mandated by a PCI compliance checklist.
That said, the PCI DSS is not without value, but, ultimately, it is insufficient on its own to act as a basis for an effective software security program. One notable aspect of the PCI DSS is that it was the first major commercial standard to mandate specific application security measures. This had great potential to help organizations improve the security of the software they were producing and deploying, but, in practice, the PCI compliance checklist is pretty limited in its scope. For one thing, the interpretation and enforcement has been too variable and subject to competing auditor interpretations. And, second, the software security portions of the PCI DSS led to organizations undertaking a lot of activity, but in many cases it did not necessarily result in a lot of progress.
A healthier approach is for organizations to base their software assurance programs on a more comprehensive compliance framework like the Open Software Assurance Maturity Model (OpenSAMM). OpenSAMM covers twelve different types of activities and describes three different levels of maturity for the implementation of each of these activities. This better reflects the various assurance activities incorporated into software security programs as well as the decisions these organizations make about different degrees of breadth and depth of coverage, frequency and customization of the activities to the specific organization's situation. The expanded framework allows the organization to tune the goals and rollout plan to specific situations. Addressing PCI compliance may be included, but OpenSAMM allows for further tailoring for different business units that have different threats and different risk profiles.
So how can an organization build a software assurance program on OpenSAMM? First, OpenSAMM can be used to benchmark the current state of affairs. Many organizations do not have a handle on the scale of the problem -- how many teams, how many applications, what measures are currently in place. OpenSAMM lets an organization look at the different assurance activities they have in place. It shows how comprehensive their approach is to these activities. Organizations should aim to move beyond the "all or nothing" approach mandated by a PCI compliance checklist.
After benchmarking, the organization can use OpenSAMM to create a roadmap. Software security programs require organizations to change their behavior, and change does not happen overnight. OpenSAMM allows organizations to target where they want to end up and to schedule steps along the way toward reaching their goals. Based on this roadmap, organizations can track their progress and review whether or not the behavior changes being made have resulted in the desired reduction in open vulnerabilities, vulnerability introduction rates and the associated risk.
While the PCI DSS does provide some commentary on portions of a software security program, organizations that want to better address the risk associated with their software are far better off using a more comprehensive framework. Using OpenSAMM can form the basis of their software assurance activities.
Do you have a question to ask our experts? Let us know and we'll pass it on!
This was first published in March 2013