Compliance and security are supposedly about risk management. Both seek to reduce the chances that threats and their risks will be able to successfully exploit a target. But they are imperceptibly different in a single way that has huge consequences. This article is about how to most efficiently turn compliance into real computer security risk reduction.
Difference Between Compliance and Security
The difference between compliance and security is that compliance has as its objective a sweeping set of security controls to which all regulated entities must seek to comply. The average compliance document is many dozens to hundreds of pages long and contains many dozens to many hundreds of controls. The regulated entities are expected to employ all those controls to regulatory satisfaction. If the regulated entity undergoes a compliance audit, the controls not met will be marked as non-compliant. The regulated entity will be told to fix the deviations. No one involved, especially senior management, wants to have any audit deviations. Anyone involved with implementing those security controls will be told to fix the deviations. Compliance is very much a “check list” type of risk management.
The Problem
The problem is that compliance attempts to “do it all at once”, with very little consideration of actual risk reduction, with the biggest risks mitigated first and best. The average compliance audit will find a dozen or more substandard-implemented controls. The regulated entity will be given a list of the poor controls and then told to go fix them. A compliance auditor or document WILL NEVER say go fix this one first, fix this one next and worry about these later on. Nope, a compliance document will more likely say, “Go fix these 20 things, now, all at once!” A compliance auditor will almost never rank deviations as “Go fix this first, go fix this next, go fix this last!”. But real-life threats have different levels of risk, and some of those risks are far greater than others.
For example, social engineering and phishing have been the top reasons for malicious data breaches for over three decades. Unpatched software has been the number two reason for that same time period. They were the number one and number two problems in the 1990s and they are the number one and number two problems today. Together, social engineering and unpatched software have been the top reasons for successful malicious data breaches for the entirety of computer history. No other root cause threat comes close, even though there are threats (e.g., USB keys, boot viruses, etc.) that do cause problems for brief periods of time. But year-in, year-out, social engineering and unpatched software are the number one and number two problems…by far. If your organization gets compromised by malware or a hacker, it is very, very likely that the root cause of the successful exploit had origins in one or two of those causes.
But you would not know that by reading any compliance document.
Every compliance document is pages and pages of controls. And yes, they always contain controls that talk about mitigating social engineering and patch management, but the coverages of those two items don’t get any special treatment. They are not talked about as top risks. They are not called out as items that the regulated entities should pay special attention to. No, it is the exact opposite. Most compliance documents give scant treatment to these two threats and the controls that mitigate them. If you can find a compliance document that gives more than a few paragraphs of coverage to each of these two topics, while not devoting five to 10 times the amount of space to many other topics, you have found a unicorn. A reader of any compliance document could be forgiven for not seeing that social engineering and patching have any special significance or heightened risk to their organization. Fighting social engineering and better patching are THE BEST TWO mitigations any organization can implement to significantly reduce security risk, but you would not know it to read a compliance document. You would not know it to read a compliance audit. You would not know it to talk to almost anyone involved in the process.
How To Fix
You fix by evaluating all compliance documents and control documents through the prism of real risk. Computer security is about risk management. So, actually start with risk before using the compliance document and before trying to figure out what to fix first. When a compliance auditor hands you 10 or 20 things to fix, ask yourself, “Which of these things has the most real risk associated with them?” Then focus on the highest risk mitigations first and best.
For most organizations, mitigating social engineering and better patching are the number one and number two best things they can do. But maybe your organization is getting successfully attacked all the time because of its poor password policy, overly permissive permissions, unencrypted wireless networks, software bugs, because of untrustworthy insiders or because of compromised, trusted, partners. Your mission, should you choose to accept it (i.e., mission possible), is to figure out what cybersecurity root causes have allowed badness into your environment (e.g., malware, hackers, etc.) in the recent past and are most likely to allow badness into your environment in the near future; and then concentrate on mitigating those risks first and best.
Your New Action Plan
Right now, if you do not have this, get your team together and figure out your organization’s true biggest threats. Not the ones that the media is talking about…cloud threats…encryption…RFID wireless sniffing…but the ones that are right now allowing the occasional malware program to get on someone’s computer. In every environment, of at least moderate size, there are malware programs that get onto people’s computers. I do not mean the ones that get detected and stopped as they are downloaded, before they have had a chance to do something bad. But the ones that were on someone’s computer, already sitting on the disk, or executed, before they were detected and removed. Ask yourself, how did that malware get there in the first place? That should be the question asked about every bit of malware that gets onto someone’s computer, every time!
Develop a risk assessment where you and your team cognitively agree on what the biggest threats are. If you do not have any malware ever sneaking past your defenses…everything is caught as it downloads before it is executed…count yourself lucky. But in most environments, the things that do get by your existing defenses, are going to be because of social engineering and unpatched software…usually. Whatever your most risky threats and risks are…again, maybe they are something else…get everyone to agree on what those biggest threats are. If you and your team simply do not know, go with the biggest threats in the world against computers since the invention of computers – social engineering and unpatched software. If I threw a third top risk in there, it would be password reuse by employees or overly permission permissions. Whatever your top risks are, whatever you have estimated your top threats to be, get everyone to agree on them, and then document them.
Then go out and try to mitigate those risks, however you can do it, using the best, layered, defense-in-depth set of policies, technical defenses and education. When someone does a compliance audit and brings back an unranked list of things that you are supposed to fix, prioritize (or re-prioritize if already ranked) according to your organization’s risk assessment. When asked to go fix 10 or 20 things at once, ask yourself, “What one or two things should I be doing first and best out of this larger list?” That is the difference between a good computer security person and a great security person.
There are a lot of ways your organization can be attacked. Start by concentrating on the most likely methods. You would be surprised by how many organizations do not do this. None of the compliance documents do this. So, take your compliance requirements and filter them through your own risk management filter.
Note: The Center for Internet Security’s recently released CIS Controls v8 Guide has a related risk management addendum with this advice as well. It is not accidental. The author of this article had many conversations with some of the key developers about this concept.
Compliance Plus gives you:
