PCI–DSS is a security standard baseline. As such, it should be thought of as a minimum standard for security. And it’s unreasonable to expect compliance with the minimum would eliminate all breaches. The PCI standard is a great tool for assisting organizations with substandard security controls by helping them understand high priority security requirements and by “incentivizing” management to appropriate funds and resources to achieve compliance. For organizations with little internal incentives for good security, PCI can be a great enabler to get security programs started.
So why not just make PCI more stringent to reduce breaches? The changing threat landscape creates new vulnerabilities, tactics, and targets constantly. To have an auditable standard, there needs to be stability with the requirements. This stability makes it difficult to create stringent fixed requirements to counter dynamic threats. Tightening the PCI standard may introduce requirements to outdated threats which would be a waste of organizations resources.
Essentially, PCI is a good starting point and a good standard to audit against, but just “hitting the checklist” isn’t going to create good security. Although PCI is a point-in-time audit, maintaining compliance is not. In order to sustain compliance, organizations have to go beyond the checklist. Good security starts with understanding the business (processes, assets, resources), and the threats and vulnerabilities to it.
From there security needs to be built into the organization and monitored and adjusted constantly, not just at audit points. Organizations need to consider security part of every business process instead of an add-on. Even if achieving PCI compliance is the main business objective, developing a strong security program can be less expensive in the long run than just meeting the checklist at a point in time. Often, without having a strong security program the organization will quickly fall out of compliance and have to dedicate additional resources to go back and mitigate missed issues. When new business processes are designed, ask the questions: How are we going to monitor this? How are we going to alert on failures or anomalies? Who reviews and responds to these issues? How do we update, maintain, patch, and retire the process? How do we identify new threats and vulnerabilities to the process? How are we going to log all of this for historical review and audits? These are just a few examples of steps for security lifecycle management, one part of a good security program.
Reducing breaches begins with understanding and promoting good security throughout an organization. By focusing on building security into processes, and not just chasing the rubberstamp of compliance, ongoing overall security can be achieved.
Tags: Data Security, IT Security, PCI Compliance
^ This post was written by: William
