I was recently on a Webinar presented by a major security vendor and one of their points was that executive management is finally starting to realize that compliance does not equal security. If you read this blog regularly, you know I really do not like the phrase “compliance does not equal security” and I view it as a convenient dodge by those who use it as a way to weasel out of their responsibilities.
But during this Webinar I had an epiphany regarding this topic. It is the confusion between security, compliance testing and reporting and the act of compliance by your technology, employees and business partners with your organization’s security policies, standards and procedures that is the problem.
I know I am just asking for flame mail with this post, but I am so tired of people looking to blame everyone but themselves about their inadequacies surrounding information security. As I have done before, to paraphrase Tom Hank’s character in ‘A League of Their Own’, “There’s a reason security is hard. If it wasn’t hard, everyone would do it.”
Security is not always easy, particularly when upper management does not have buy in. But even when upper management supports security efforts, I have seen security personnel not take advantage of that fact and get the job done. Security does not have to be hard, but it does take more than just slamming some firewalls and intrusion prevention gear down, tossing a SIEM into the mix and thinking you are done. Security is a never ending journey because someone is always coming up with new ways to attack you.
Anyway, to start off, let us take a look at some definitions first so we are all on the same page.
Compliance is defined as:
“Conformity in fulfilling official requirements.”
“Official requirements?” Could that possible mean your organization’s security policies, standards and procedures? You bet. In this instance, we are talking about those that correspond to the PCI DSS, but this also applies to ISO 27K, FISMA, HIPAA, GLBA or any multitude of frameworks and regulatory requirements.
Conformity is defined as:
“Compliance with standards, rules, or laws.”
Based on these definitions, security is all predicated on complying with what are deemed an adequate set of security policies, standards and procedures. Conversely, if you are not complying with an adequate set of security policies, standards and procedures, then your organization cannot be as secure as it could be. As a result, compliance has to equal security as long as the security policies, standards and procedures are considered adequate. Therefore security professionals that quote the mantra, “compliance does not equal security” either have a problem with the compliance side of the equation (most likely) or with the standards/frameworks (the dodge).
Over the years there have been a lot of discussions about the PCI DSS, ISO 27K, FISMA and other security frameworks and whether or not they are adequate. The important thing to remember is that all of these standards or frameworks are merely ante into the information security game. They are the bare minimum or a baseline to get to a basic level of security. Should you being doing more? Definitely, but what those efforts beyond the standard/framework are depends on what you are trying to secure, your network and application architectures and a multitude of other factors related to your computing environment and how it is used. Those are factors that cannot be taken into account by any standard/framework because they would start to become impossible for others to follow and implement. The bottom line here is that if you want someone to tell you exactly what to do to secure your networks and applications, go hire a consultant you trust and they will tell you everything you want to know.
The rub in all of this is that, based on the breach reports from Verizon Business Services, Trustwave, et.al. as well as compliance testing reports I have reviewed, none of you out there are 100% compliant to begin with, let alone even close. Every organization I am aware has problems complying with the basics, let alone with any advanced security requirements in the published standards/frameworks. So if you cannot comply with what you already have, explain to me how a different framework is going to change that fact unless it is less stringent than the framework you are already trying to use? And if that other framework is less stringent, while that may solve the compliance issue (which I seriously doubt), exactly how is a less stringent framework going to make you secure? The answer is that it will not make you secure.
What security professionals struggle with is that compliance is a never ending, 24x7x365 effort. Drop your guard for an instant and it can be game over. But provided your security policies, standards and procedures are appropriate and detailed (the reason why you want to use an appropriate standard/framework), your organization is not as secure as it can be unless your personnel and devices comply 100% of the time with every defined security policy, standard and procedure. If you want confirmation of these facts, again, just look at the breach analysis reports year after year. The reason there are breaches is because of non-compliance with one, but usually more, of an organization’s security policies, standards and/or procedures.
This brings me to the rumblings of late regarding a rethinking of defense in depth. Defense in depth is predicated on using layers of security devices and controls to minimize the risk that a security incident occurs not to completely prevent an incident although you might get lucky. For example, firewalls are the sledge hammer of security tools. However, because we need to have ports open for outsiders to access applications, we follow our firewalls with intrusion detection/prevention devices to ensure that no one abuses the protocols used by the ports. We follow that up with monitoring of log data from the firewalls, IDS/IPS, routers, switches and servers to identify any “sneaky” attacks using the protocols we allow. The layers are there to cover the various holes we need to have in order to make our networks and applications function. The tighter and smaller we can make those holes, the more secure we will be, but there will still be some amount of risk. So we bring in more layers to cover those risks until it is more expensive to address the risk than to accept the risk. That remaining risk is the residual risk that we therefore manage and control through detection and correction.
The other thing defense in depth relies on is the control triad. The idea being that, because you cannot entirely prevent every security incident, you need a way to detect the incident so that you can take action to stop or minimize the impact of the incident. You follow that up with periodic assessments of your control environment to identify and correct any deficiencies or improve your program based on new information regarding security. The follow up assessments can be activities such as a root cause analysis (RCA) of an incident, an internal audit of user accounts and user rights or brining in a network security team to assess your security architecture and controls. All of these activities will result in findings and recommendations to make your security systems and controls better.
And that brings us full circle to the PCI assessment. It is merely a tool used by the acquiring banks, card brands, processors and others to obtain reasonable assurance that your organization is doing what it can to minimize the possibility of a breach of cardholder data. It is not meant to be, nor could it ever be, an absolute complete assessment of an organization’s security posture and therefore provide absolute assurance that a breach will not occur (even though the PCI SSC and card brands tend to imply that fact). Compliance assessments are only a snapshot of personnel and device compliance at the time the reports were written. This is no different than going to the doctor for your annual physical which results in a snapshot of your health at that point in time. It is not that those compliance reports are worthless; they just need to be referenced and used properly based on the fact that they are a snapshot. Just as your doctor will tell you to lose weight or stop smoking, compliance reports provide recommendations on where you can make improvements or adjustments in your policies, standards and procedures based on what compliance evidence was found, or not found, during the assessment.
So, what are the lessons to be learned?
- Security is not and never will be perfect; there will always be residual risk that must be managed and controlled.
- Compliance does equal security, at least as best as your preferred standard or framework defines it plus whatever enhancements you have made.
- Compliance assessments and reports point out where your organization was not compliant and needs to do better, not to prove your organization is secure.
Use the tools at your disposal correctly, stay current on threats and monitor your security posture and you will likely live a long, prosperous and secure life.
Keep hiding behind “compliance does not equal security” and you will forever be living off of your “luck” until it runs out (usually sooner rather than later).
