You hear this common lament from security professionals, "Compliance is not security." This remark has always sounded like an excuse to me. I suppose the reason is that most people who utter this phrase always seem to have questionable security practices. But since I hear this complaint so often, I thought I should see if these people have a point. So, like The MythBusters, I decided to see if this saying held water.
Information security is predicated on complying with 'what is deemed' an adequate set of security policies, standards, and procedures structured on a "defense in depth" strategy. Conversely, if you are not complying with an adequate set of security policies, standards, and practices, 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 or with the standards or frameworks.
The first thing I did was to get the definition for the term 'compliance' from Webster's dictionary. Compliance is defined as:
"Conformity in fulfilling official requirements."
That definition says it all. If you are conforming to defined requirements, then you are compliant. Therefore, whether or not an organization is secure comes down to whether or not the requirements they comply with are deemed adequate to ensure the organization's security. If you are complying with the given standard or framework and your organization has security problems, then the standard being followed is the problem. However, suppose your policies, standards, and procedures are not adequate. In that case, complying with any standard or framework will likely be a constant struggle, if not impossible.
Compliance starts with the appropriate security policies, standards, and procedures. For example, suppose you are not following security best practices suitable for your organization from a recognized source such as NIST or similar. In that case, all of your compliance will not matter because your security policies, standards, and procedures are flawed and/or incomplete. So, the first order of business is getting the appropriate security best practices in place.
The next necessary step is training your personnel to ensure their compliance with your security policies, standards, and procedures. Security training and awareness of your organization means that they understand the security risks present in today's computing environments and the reasons for your security policies, standards, and procedures. Unfortunately, most organizations miss the rationale of security policies, standards, and procedures and why training provides limited results. It is hard to get people to comply with security policies, standards, and procedures if you are not entirely explaining them. Without a complete explanation, your personnel will ignore them as meaningless or pointless. You can have all the latest, most incredible technological security solutions in the world, but if your personnel is not complying with them, all of that technology is worthless.
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 to get the job done. Security does not have to be challenging, but it does take more than slamming some firewalls and intrusion prevention gear down, tossing a security information and event management solution into the mix, and thinking you are done. Security is a never-ending journey because attackers are consistently producing all sorts of new ways to attack you.
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 suppose your security policies, standards, and procedures are appropriate and detailed. In that case, your organization is not as secure as it can be unless your personnel and devices comply 100% of the time. To confirm these facts, look at the breach analysis reports year after year. There are breaches because of non-compliance with at least one, but usually many, of an organization's security policies, standards, and/or procedures.
The bottom line is that much to the chagrin of most information security practitioners and senior management, security is neither perfect nor will it ever be.
Over the years, there have been many discussions about whether security frameworks are adequate. The critical thing to remember is that these standards or frameworks 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 be doing more? Definitely! But efforts beyond the chosen standard or framework depend on your particular environment.
To be secure, an organization must go beyond any security program's specified requirements. Unfortunately, it is a rare organization that goes beyond recognized security programs. Why? For most organizations, the security personnel does not have the time to develop their security program beyond what is already called out by a framework. A lot of this 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 hard to determine what measures need to be taken, why they need to be taken and what resources are necessary. Once everyone understands the risks, a proper security program can be developed for the organization considering the security standards that must be followed.
The rub in all of this is that, based on the breach reports from Verizon Business Services and others, as well as compliance testing reports I have reviewed, not one organization is ever 100% compliant. Every organization I am aware of 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, how will a different framework 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, how will a less rigorous framework make you secure? The answer is that it will not.
This brings me to the rumblings of late regarding rethinking defense in depth. Defense in depth is predicated on using layers of security devices and controls to minimize the risk of a security incident, not to prevent an incident although you might get lucky completely. For example, firewalls are the sledgehammer 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 log data from the firewalls, IDS/IPS, routers, switches, and servers to identify any "sneaky" attacks using the protocols we allow. The layers cover the various holes we need to have 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 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 we manage and control through detection and correction.
The other thing defense in depth relies on is the control triad of Prevention, Detection and Correction. The idea is 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. Then, 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 include a root cause analysis of an incident, an internal audit of user accounts and user rights, or bringing in a network security team to assess your security architecture and controls. These activities will result in findings and recommendations to improve your security systems and controls.
You also need to monitor your personnel's compliance with your policies, standards and procedures. Unfortunately, anything less than 100% compliance means you have security gaps. Some of those gaps may be small and/or covered by other security elements as part of your defense-in-depth strategy. But some of those gaps may be huge and put your entire organization at risk. These huge gaps need immediate attention and personnel retraining to ensure that they get closed quickly and do not occur again. It is the act of closing the loop that makes security successful. If you are not correcting mistakes or improving your security policies, standards and procedures, you will be doomed to failure.
Changes to the environment also need to be reflected in the compliance program. For example, 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 must be reflected in a compliance program, particularly when adding another data center or a new cloud instance.
One of the biggest things neglected with compliance is when technology is removed from the environment. Nine times out of ten, 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 removal of technology might significantly affect the control environment because operations are unaware of other areas relying on technology for controls. Then once the compliance team comes out for their assessment, they find that, with the removal of that technology, there are now numerous controls that are no longer performing as designed and security gaps exist as a result.
Another example of a change that can adversely affect compliance but is typically overlooked are staff reductions. One of my clients several years ago went through a significant staff reduction. A number of the staff let go were performing manual processes to monitor the security environment and identifying security issues critical to their various compliance efforts. When these people were terminated, those essential controls were no longer functioning as designed. To add insult to injury, this situation continued for almost ten months when their compliance assessments were performed. Then the organization had only two months to somehow put these critical controls back into place without the necessary resources to do them manually. To get through their assessments, personnel had to step up and add these tasks to their already heavy workloads. While that got the organization through its compliance assessments for the current period, the stress of keeping those controls operating as designed proved to be too much. Some people quit, creating new control failure situations that ultimately resulted in a breach. Management had to admit that more people were needed and some new tools to eliminate the control failures and minimize the number of people required.
The takeaways I would like you to leave with are:
Truvantis is a cybersecurity, compliance, and privacy consulting organization with comprehensive expertise in implementing, testing, auditing, and operating information security programs. We specialize in helping our clients improve their cybersecurity posture through practical, effective, and actionable programs—balancing security, technology, business impact, and organizational risk tolerance.
Jeff Hall
Principal Security Consultant, Truvantis, Inc.
Jeff Hall is a principal security consultant at Truvantis, Inc. He has over 30 years of technology and compliance project experience. Jeff has done significant work in financial institutions, health care, manufacturing, and distribution industries, including security assessments, strategic technology planning and application implementation. Jeff is part of the PCI Dream Team and is the writer of the PCI Guru blog (http://pciguru.blog).