Loading ...
Often times one will hear the catchphrase that “Compliance isn’t the goal; security needs to be the goal.”
Unfortunately, it seems to me this is a misguided statement for a few reasons.
First, “security” is not an end state. In other words, it’s not something that can be reached or achieved. There are always threats against the environment. One cannot say: “Now we’re secure.” One can say, “We have a reasonable degree of assurance that…”
Second, “security” cannot be measured, per say. While there are “security metrics”, these metrics reflect the risk in the environment in quantitative terms. For example, if one surveyed the level of anti-virus signatures for a host of machines in a given environment, it would provide a basis to understand the state of the enterprise and the current risk level. It would not tell you if you are secure or not. Even though security itself cannot be measured, risk can be generally assessed though.
Third, and this is really the crux of this post, compliance should be considered a risk reduction method aimed at improving one’s security posture.
PCI compliance is a case in point: the aim is to significantly reduce data leaks and thereby prevent fraud.
In addition to compliance/regulations, we have a number of methodologies and frameworks aimed at reducing risk. By their nature, such frameworks and methodologies are invariably incomplete, although most are very wide ranging in scope. Checklists, “best practices”, COBIT, OCTIVE, NIST 800-100 are all examples of methodologies used to reduce risk. Naturally some are better than others, but which one is implemented is based on a number of factors such as cost/benefit and skill of labor implementing the risk reduction methodology.
I decided to write this post due to something I read on Risk Management Insight. Alex writes:
At the end of the day, folks who are unclear in how they can put together a logical, rational model for the way the world around them works will transfer the risk that they might be wrong to someone or something else. In Donn Parker’s case, or in Richard’s case, this is “best practices”. Now note that this is an intelligent and perfectly valid thing to do - I used to transfer the risk by using “government standards” like 800-30 even though I thought it was sub-optimal as a risk expression. But even “best practices” are, in and of themselves, a means to attempt to address risk. They are just a method with much less rigor than I’d be comfortable using at this point. [Emphasis mine.]
I go a step further and say these are attempts to lower risk in the environment, not simply transfer it.
3 Comments
Ken,
Thank you for considering my thoughts and opinions. I’ve written my thoughts on the blog, but I did want to repeat myself here just to clarify.
When you says that best practices are attempts to lower risk, I agree. But organizational risk wasn’t the point of my use of the concept of risk transference in that quote. My assertion is that individuals will be doing risk analysis, whether they like to say they are or not. The only question is with what rigor.
Some people (Donn and maybe Richard) are uncomfortable with their understanding of probabilities. So rather than be wrong in making a belief statement about probabilities, they transfer the risk of being wrong about probabilities to a checklist. This transfer of risk is a completely independent “risk issue” than their capability to lower the risk to their stakeholders. It is a personal risk analysis they’re doing about their ability to perform accurate risk analysis.
Now I believe that checklists and compliance mandates are really inefficient means to lower risk to stakeholders. The other non-FAIR risk assessment methodologies mentioned there less so in theory, but so inefficient in practice as to cause significant frustration.
Hi Alex,
1. Thanks for clarifying what you mean by the term transfer in your previous post.
2. I agree that compliance may leave gaps (as per your BITS AUP example). Although, that wasn’t the focus of my post. I did not mean to insinuate that compliance could not lead to a “negative impact”, as per your language, due to such gaps.
3. Compliance is still a form of risk reduction. It’s a distinction people seem to forget when they talk about compliance vs. security, as if they have completely different objectives.
Ken,
We’re agreed on all points! This whole discussion by blogging thing is somewhat inefficient at times
The nice thing is, I’m starting to mellow on compliance a little as a result.