I have a confession to make: Like many security professionals, I have a love-hate relationship with Governance, Risk Management and Regulatory Compliance (GRC).
The hateful side of the relationship is based on the very simple premise that I don’t really believe that GRC is particularly effective. I say this because it hasn’t made the internet or the average organization safer from attack– at least not when that attack is executed by a resourceful or talented entity. In many situations, it actually has quite the opposite effect. It has taken valuable and scarce time, resources and budget away from providing actual security. Furthermore, it has left nothing but misinformation, ignorance and complacency in its wake.
GRC also opened up the information security field to people who, to put it bluntly, are about as technical as my left foot. They wouldn’t be able to lock down a network or harden a system if their lives depended on it. Hacking their way out of a paper bag would be problematic – yet alone an actual computer. You know the type of people I am talking about – the clipboard holders – the CISSP boot camp graduates – people more used to using Excel than Nmap. The apologists will claim that a deep level of technical expertise is not necessary – that GRC is meant to bridge the gap between technical jargon and business processes. To them I say, Poppycock! That doesn’t really keep hackers out, does it? The track record of GRC in regards to computer security is sketchy to say the least.
The biggest problem I see with GRC (and I say “the biggest” very consciously – because the list of other problems is quite extensive) is that it frames the goal of information security in entirely different terms than is necessary. No longer is the aim to be secure. The real goal now is to be compliant.
You don’t believe me? Then look at the long and growing obituary of insecurity victims from the past few years. The chances are astronomically high that if you show me a data breach, you are showing me an organization that was compliant with some standard or another. Let’s just say that there are very few conversations between hackers on IRC where one warns the other, “Don’t hack them, they follow ISO 27001.”
To a security guru, GRC feels like a waste of time. We know it will not really make us more secure, but it has to be done. It will provide artificial challenges that make a difficult task even harder, with very little gain or advantage in return other than a report containing lists of items with a marked checkbox. It will force you to buy solutions and technologies whose real benefit are objectively only on paper, and it will cost a large chunk of your hard-fought for and still too low budget and resource pool. Many of the requirements are traditionally only related to security in a very roundabout way. Some of these include monitoring whether users are surfing private sites during work time for example, enforcing accounting standards, or ensuring that you have backup power for the datacenter.
A cynic may claim that it is as though someone decided that real security is just too expensive to achieve. So we will go for compliance instead. By doing that, we have not just thrown out the baby with the bathwater; we have actually thrown out the bathtub, towel, soap, and the bathroom altogether.
It has weakened and diluted the very real and very necessary feeling of risk and naked exposure that is a catalyst for wanting to actually be secure. You can see after a data breach that all of a sudden security is taken seriously–after the damage has been done.
This is a real pity. GRC applied to Network and Information Security really began because the recognition arose that IT security was important and desirable. Unbelievably, despite media focus on hackers and hacks, despite having their customer data and intellectual property stolen, many organizations did not realize this before. So the powers that be, whether a government, VISA, or whoever, decided in their infinite wisdom that there should be a minimum requirement for security.
Of course, once you make a bold demand like that, you are going to have to define precisely what is expected of everyone. How else should you know how much enough security is enough? How else will you be able to evaluate whether all of the demands have been met and everything is done as expected?
So security had to be formalized, structured and presented in a manner that a non-technical person can understand. And that is where it really all went wrong. We wanted everyone to make an effort at being secure – only somehow we ended up with GRC instead.
But once you lay down a fixed set of rules, it won’t be long before they are tested to the extreme. Loopholes are sought. Minimum requirements are turned into a standard. It’s not that these guys can’t hack; they just don’t hack computers, they hack regulations. Essentially, it is too easy to cheat.
Compliance says you need a Firewall? Check! Firewall is in place. It’s not configured well, you say? That’s not really required though, because it is not mentioned at all. And we just spent so much money on that compliance reporting solution that we had to have, that there is no money left – but no worries because we are compliant!
It is not that the guidance that GRC provides is by its nature inherently flawed. It provides a really good framework for a knowledgeable security architect to build a security policy around. But it does still depend on knowledge and skill – which has not gotten any easier to find or develop, despite appearances. It makes security seem easy. Easy to commoditize; easy to implement; easy to purchase. Although most times in practice, it is an incredibly complex method of throwing time and money out of the window.
At the beginning of this column, I said I had a Love-Hate relationship, so I guess it is time we get to the love part.
GRC has had a few good effects. Foremost, it forces companies to at least be aware that there is a need to address security. I can remember when Payment Card Industry Compliance first came out and many companies had to out their security approaches and policies for the first time – we laughed and we cried. From the SOHO ADSL router being used as a firewall to protect credit card processing terminals, to the excuse that an end of life product can’t be patched so it doesn’t need to be, the variety of gross negligence was incredible.
From that point of view, at least now the average script kiddie attack or virus outbreak will have a far more difficult time in succeeding.
But for me the most powerful and useful aspect of GRC is that a wiley and cunning security guru can (and should) use GRC for leverage. It is only natural that an executive who has to choose between the financial bottom line and a hypothetical future risk he cannot fully comprehend will always chose the financial bottom line. It’s his job after all. This is where GRC shines and proves its real worth, because you can take that excruciatingly difficult choice off of his hands. You can help him to do the secure thing. GRC gives you that power– if you wield it skillfully.
Related Reading: Raise Your Company’s Enterprise Risk Management IQ