Based on some of the comments I get from blog readers and articles I see espousing the “compliance is not security” mantra, I think it is time for a refresher on where compliance fits into an organization’s security program or any other audit/assessment program.
As a reminder, Miriam Webster defines compliance as:
“Conformity in fulfilling official requirements”
Therefore, for PCI, an organization is conforming to the PCI DSS when they assess. For ISO 27K, the organization is conforming to the ISO 27K standard. For a financial audit, an organization conforms to the Generally Accepted Audit Principles (GAAP). The list can go on and on.
Where things get confusing and messy is whether or not the compliance program is detailed and tight enough to ensure security. Programs such as the PCI DSS, ISO 27K and others have to be written in such a way that any organization (regardless of technology, architecture, applications, etc.) can assess to it. Whether we are talking about the PCI DSS, ISO 27K, COBIT or any other assessment program, there must be flexibility to allow for all sorts of solutions, not just a preferred or “perfect” one. As a result, there is a lot of flexibility built in that produces a not so tight security program. This therefore means that being secure requires going beyond what the compliance program requires.
But compliance is only a part of an overall security program. I have discussed the control triad in prior posts, but it bears repeating here. There are three parts to any effective security program: protection, detection and correction.
A good compliance program is part detection and part correction. The detection side of compliance relates to detecting controls that are not functioning as designed or are missing altogether. Changes to the environment are always the culprit in controls not functioning properly or missing. The correction side of compliance is defining what needs to be corrected in order to address the shortcomings determined during an audit/assessment.
Where the “compliance does not equal security” naysayers first go wrong is with ignoring execution. A compliance program is all about assessing the execution of an organization’s security program and ensuring that an organization is executing that program flawlessly. But an annual assessment such as with the current PCI process is only part of the overall compliance process. Compliance must be assessed constantly which is why the PCI SSC is introducing the concept of business as usual (BAU). BAU is meant to drive organizations to constantly assess compliance with requirements based on their risk assessment. Some requirements may have to be assessed daily, whereas other requirements might only be assessed weekly, monthly or even semi-annually
A working compliance program points out any execution issues with the security program and recommends solutions. To paraphrase the numerous security professionals that has pointed this out over the years, “To ensure the security of our organization, we have to get it right every minute of every hour of every day. Attackers only have to get it right once.” Therefore a compliance program is the mechanism that keeps the security program functioning as close to “right” as is humanly possible. But as I always point out, security is not perfect. So even with a good compliance program, security issues will still occur.
But that is where security has its biggest issues are with execution. If organizations could execute any security program, even the PCI DSS, with almost 100% accuracy every day, the number and seriousness of data breaches would be virtually non-existent. But that is where most organizations get burned is with execution. I have yet to encounter any organization that can execute all parts of any security program above 90% and that is on a good day. In most cases organizations are well below that percentage. As a result, regardless of the security measures in place, the controls are not functioning as defined and therefore security holes abound resulting in a myriad of ways to defeat security. Add in the human errors that occur and I think you start to understand the challenges of keeping a security program working effectively.
The second place that the naysayers go wrong is not recognizing the inherent limitations of the assessment programs. Every security program I have ever encountered has a multitude of limitations due to the necessity that they fit all situations. Then there is the fact that they are, after all, mere baselines for security, not a “be all to end all”. To truly be secure an organization must go well beyond what the PCI DSS, ISO 27K or any other security programs call out. That is not to say that a company cannot be reasonably secure following only these programs. But then we go back to my earlier statement that the program must be executed close to 100% compliance every day which is where organizations get burned. It is not the program that causes the security issues; it’s the inability to execute the security program consistently that is the cause.
As I said earlier, all security programs are the bare minimum for security. As a result, in order to be secure an organization needs to go beyond the requirements specified by any security program. Unfortunately, it is the rare organization that goes beyond any of the recognized security programs. Why? For most organizations, the security personnel just do not have the time to develop their security program beyond what is already called out by ISO 27K or PCI DSS. Some of this is due to staffing issues, but more often than not, it is due to a lack of upper management recognition and understanding of what true security really takes in personnel, time and other resources. A lot of that lack of understanding comes from the organization’s risk assessment or more likely the lack of one. Without a good understanding of the information security risks to the organization, it is very hard to determine what measures need to be taken, why they need to be taken and what resources are necessary. Once everyone can understand the risks, then a true security program can be developed for the organization taking into account the PCI DSS, ISO 27K or any other security standards that need to be followed.
Finally, compliance programs are never ever static. They need to be constantly adjusted to reflect the introduction of new technologies, changes to the existing environment and the removal of technologies.
For example, if an organization implements a new security information and event management (SIEM) solution, the compliance program needs to be changed to reflect that new SIEM. The most likely changes are the addition of new conditions that will be monitored for and alerts generated. The compliance program needs to add those new conditions to their testing and make sure that alerts are truly generated when the conditions are encountered. In addition, if the new SIEM introduces any changes to existing alerts, those changes also need to be adjusted in the compliance testing. Finally, if some SIEM conditions are being removed, the compliance program needs to reflect that removal as well.
Changes to the environment also need to be reflected in the compliance program. Application changes can result in changes to the compliance program particularly if the application controls its own authentication processes, encryption of sensitive data and other critical controls. Another area is network changes that also need to be reflected in a compliance program. While adding new physical locations is typically only a minor change to a compliance program, changing firewalls, routers or switches can result in significant changes to the compliance program.
One of the biggest things neglected with compliance is when technology is removed from the environment. Nine times out of 10, the compliance team is never notified of the decommissioning of equipment. Security professionals might think that compliance is not affected if something is removed. However the control environment might be significantly affected with the removal of technology because security is unaware of other areas that are relying on a technology for controls. Then once the compliance team comes out for their assessment they find that, with the removal of certain technology, there are now numerous controls that are no longer performing as designed and security gaps exist as a result.
An example of a change that can adversely affect compliance but is typically overlooked is staff reductions. One of my clients a number of years ago terminated a number of personnel in an effort to save costs. A couple of the staff let go were performing manual processes that were critical to monitoring the security environment and identifying security issues that were critical to their PCI compliance efforts. Management believed that these people were superfluous to their operation, i.e., a nice way of saying they were unnecessary overhead, so they were terminated. Obviously when these people were terminated, those critical controls were no longer functioning. To add insult to injury, this situation was not identified until almost 10 months later during their PCI compliance assessment. Then the organization had only two months to somehow put these critical controls back into place without the necessary resources to do them manually. What eventually happened was that people had to step up and add these tasks to their own already heavy workloads. While that got the organization through their PCI assessment for the current period, the stress of keeping those controls operating as designed proved to be too much and some people quit creating new control failure situations. Ultimately management had to admit that more people were needed as well as some new tools were necessary to minimize control failures as well as minimize the number of people required.
The bottom line is that the compliance assessment process is the check and balance to make sure that an organization’s security program is designed appropriately and is functioning effectively. Hopefully you now have an appreciation as to the purpose of an effective compliance program and why it is important to the overall security process.
So the next time you say that “compliance is not security” think about this post and understand the implications of your statement. Without the compliance process, you have no idea as to whether your security program is effective or not.