…or at least, it should be
A recent PCI compliance report from Verizon contains some interesting findings.
It starts off with what seems like good news: compliance rates between audits are increasing, with an 80% increase in the number of companies being validated as PCI-DSS compliant at their interim assessments. However, 80% of companies are still not compliant. It’s easy to get big percentage gains from a small base, but we still have a long way to go—as we saw in the news over the past year or so. The Verizon report quotes a PwC survey that found a 66% growth in security incidents since 2009, with 43 million incidents in 2009 alone.
Unfortunately, the bad security news continued. In that compliance increase with PCI-DSS mandates, there is one area where compliance fell: testing security systems went from 40% in 2013 to 33% in 2014.
The real problem however is that even among the companies that were compliant, fewer than one-third were still compliant a year later.
This is compliance as an event: “Quick, the auditors are here! Get everything ship-shape! Okay, they’re gone—relax…”
There are many problems with this approach:
- Disruption: Treating the audit as an emergency pretty much guarantees something will go wrong. Working on unfamiliar systems, making changes by hand, working at night or over the weekend—all of these are factors that contribute to the chance of a misstep taking down a production system, leaving the company open to a breach or a violation, or both.
- Sustainability: An emergency means that you drop everything else that you were working on. By definition, you can’t do that too often, or the everyday work won’t get done. Every time you interrupt a process, it takes time to recover from the disruption and get back up to speed, so the delay is always greater than the duration of the disruption.
- Effectiveness: Managing by emergency simply won’t be very effective, because as the statistic above demonstrates, as soon as everybody goes back to their day jobs, the compliance level starts dropping again. This raises the likelihood of another fire drill at some point in the future.
- Exposure: One of the reasons to go through the arduous PCI-DSS compliance process is to be protected from the consequences of fraud. If a merchant can prove that their systems were secure and that the fraud occurred elsewhere in the payment chain, their losses will be covered. The wrinkle is that they need to be able to prove that they were in compliance at the time of the breach. If the fraud occurred in the window between audits, there may be a problem. This principle is currently being explored in the courts.
- Coverage: According to the Verizon report, in 2014, two-thirds of organizations did not adequately test the security of all in-scope systems. Because of the factors listed above, many organizations seek to circumscribe their exposure to PCI-DSS audits by limiting their scope. However, the ever-increasing complexity of modern applications makes it difficult to draw that line correctly. In addition, development systems may not be formally in scope, but any code developed in an open environment may fail when deployed into a compliant environment. This means that it makes sense to extend audit coverage beyond the obviously in-scope systems—but this is impossible because of the effort and disruption involved.
For all of these reasons, organizations that need to achieve effective PCI-DSS compliance and maintain it over time must develop a sustainable approach to continuous compliance.
BMC can help: our Server Automation and Network Automation solutions include turnkey PCI-DSS content that covers both audit and, crucially, remediation. Fully updated for PCI-DSS v3, this content is free to users with current maintenance, as are all updates.
This enables users to perform a scan of their entire IT estate (or a subset) with no effort whatsoever and immediately get an understanding of the current state of their environment. They can then go through the list of violations and choose whether to remediate using out-of-the-box automated actions or define exceptions where the remediation may cause other issues or disruptions.
Often, that moment of deciding what to remediate can cause the greatest problems in the process, as the audit or security teams have to ask the operations team to make the changes. However, the operations team may be wary of causing issues or simply be overwhelmed with other tasks, and so delay is introduced into the process.
The fact that the out-of-the-box content includes both audit and remediation, combined with integration to change management and approval systems, takes the friction out of that communication and helps to make compliance a process, not an event.
- Security Automation And The SecOps Crisis
- Cloud Security Trends to Watch in 2017
- 4 Use Cases to Automate the Gap with Service Process Orchestration
- IT Consumerization–External End Users Matter Too
- What is Automation? – Part 2 – IT Orchestration