Thursday, April 20, 2017 By Kevin Beaver, IANS Faculty
What's the first thing everyone seems to talk about when information security is brought up? What about when a new business is starting up, or even when existing organizations are undergoing an audit? The first thing that comes up every time is security policies. Got a risk? There’s a policy for that. Concerned about experiencing a breach? No worries, there’s a policy that covers it.
There's a policy for acceptable usage and one for data classification. Data backups, patching and system maintenance are often documented in policies as well. Mobile, the cloud, you name it – security policies are everywhere. And they’re creating a serious false sense of security from the smallest startups to the largest enterprises.
IT people often write these security policies. In fact, IT is where policies often begin and end. Users don’t know about them and management is quick to proclaim that policies are in place to keep things in check. It all looks good on paper. That is, until the first breach occurs.
If you lived on another planet, were teleported to earth and read about all of the data breaches and security incidents happening around the globe, you would probably wonder what's causing all of this. After all, organizations have security policies that lay out, often in great detail, how things work and how things go down in and around IT. You would expect, given the level of effort that goes into security policy development and oversight, that an organization could not possibly get breached with all of these rules in place.
Here's the problem: those rules really mean nothing in the grand scheme of things. Sure, auditors love them. Management wants to see them so they can tell their colleagues about them. Policies just make everyone on the perimeter – and outside – of IT feel all warm and fuzzy.
Turning Words into Action
At the end of the day, though, words on paper that talk about how things are supposed to work have no real substance and do very little in terms of risk mitigation. There's a big gap between what you say you're doing in security and what's actually being done. And everybody knows where the weaknesses are. There’s just too much bureaucracy, culture and political nonsense getting in the way.
It’s not the policies that get hacked. Systems do. Applications do. People do. I can’t tell you how many times I have seen businesses with excellent documentation on the administrative/operations side and horrible security vulnerabilities on the technical side. We have to stop spending so much valuable time, money and effort on writing security policies that go nowhere other than the network-share likely to never be seen again.
Putting on my expert witness hat, I’ve seen time and again where security policies create more problems than they solve. Many organizations are saying they do X, Y and Z, but they're often doing quite the opposite. And guess what? Lawyers and their litigation support team are calling these organizations out on it. Is this the way you want to run your security program? I know it's not, but still, you've got to figure out what you're going to do to bridge the gap between your wayward documentation and reality.
It can get disheartening if you let it, but I like to focus on all of the opportunities that are out there for us. There’s always an upside, especially when you focus on what matters.
As security professionals, we need to stop relying on words and let our actions do the talking. Technical controls have to be in place in order for policies to be enforced in most situations. Where that’s not possible or feasible, do something else – whatever it takes. There’s always more. Doing nothing is the easy way out and it’s the fast path to bigger security challenges. We, as information security leaders in our organizations, have to decide how it's going to be.
Are we going to let lackadaisical, documentation-centric expectations from auditors, regulators and executives drive our security program, or are we going to spend more time on what’s fruitful and build true substance into our programs? We're going to have to address this at some point, so why not start now before someone – one of our own users, a contractor or external attacker – makes us look bad?
Kevin Beaver, CISSP is an independent information security consultant, writer, professional speaker, and expert witness with Atlanta, Georgia-based Principle Logic, LLC. Kevin has written/co-written 12 books on information security including the best-selling Hacking For Dummies (currently in its 5th edition).