Who’d have thought that there are IT security lessons to be learned from a new approach the UK Government took to reducing speeding? But the concept of changing people’s mindsets to think about road safety rather than speeding is, rather peculiarly, a great fit for the IT security issues organizations currently face with the increased prevalence of malware, ransomware, phishing, and other nasty things. This blog also sheds light onto the traditional use, or misuse, of experts (in this case in the IT security domain) – and hopefully at least one of your eyes will be opened to the opportunity to improve your company’s approach to IT security for the better.
Experts are good; every organization needs them (well, the real experts not the self-proclaimed ones you see on LinkedIn). They bring a deep and complex understanding of their field, how it’s changing, and the implications of external factors that need to be considered and addressed. Within IT service management (ITSM) we see experts in many areas. We rely on their detailed knowledge in aspects like capacity, networks, storage, in second line support for those unexpected and complex failures, to tell us about new opportunities like cloud, and for big scary things such as security.
Thus, experts are a necessary “tool” and we need to take them seriously. After all, they’re often expensive, so we should seek optimal value from their advice and act upon it. Few would argue with this thinking, I’m sure.
Like All Tools, Experts Need to Be Used Wisely
I know it sounds funny, but experts are often one of our most valuable business (and ITSM) tools, however getting the best value from experts involves working with them, not just listening and then doing.
Like any tool, from a hammer to a space shuttle, to get the best value we need to see the context, and understand what we want to achieve. Once we know that, then we can apply expertise to help us travel in the chosen direction. However, starting instead with detailed expert advice we can easily be sent in the wrong direction (of travel).
For example, let’s compare an “off the shelf, by the book” security policy with the use of speed – sorry, safety – cameras on UK roads. Note that this is not a random choice of words or analogy; it’s based on the UK government’s common-sense change of policy a few years back when they changed the color of the cameras – turning them from speed traps to safety cameras.
Solving the “Why” before the “What”
What the UK government did in 2015 was to finally ask a question that should have been asked before the introduction of speed cameras: “What are we trying to achieve?” There was finally a “Riddle me this, Batman” moment.
Speed cameras had originally been installed across the UK simply because they could be, in that:
- The technology existed
- Other countries had done it
- There was advice on where to position them and process results
So, what originally happened was a UK implementation, of speed-camera technology, based on using the technology for what it could do – catching vehicles exceeding the speed limits. And, of course, the best way to do this is to make the cameras as unnoticeable as possible. Hide them behind trees, round bends, and paint them in camouflage-friendly colors such as “drab gray.” It all worked so well that many millions of pounds were generated from fining speeding motorists.
However, what the cameras didn’t do was reduce driving speeds. Duh!
Eventually, it was realized that what society really wanted was:
- Drivers adhering to the speed limit
- Safer roads for all users, with vehicles slowed in dangerous places
- Less lives lost, and less people injured in accidents
Once you factor in these goals, how and where you position speed cameras changes. So too do your critical success factors and key performance indicators (KPIs). It’s easy to measure the success of your speed camera initiative by the profit it creates: total of fines received less implementation and maintenance costs. But if you’re doing this to slow drivers down, then every fine issued is actually a failure, not a success. Saved lives, injuries, and disruption is harder to measure and rather more subjective. But I think we’d all agree that it’s what the safety cameras should be about.
Do You Have IT Policies Like This?
You can, fairly easily, make the same kind of mistake with an IT security policy. Its main aim shouldn’t be to catch people breaking the rules but to instead make them follow rules that keep everyone safe. Speeding doesn’t just put the bad drivers at risk but the good ones too (since bad drivers tend to drive into other innocent people). And security transgressors don’t just put themselves at risk; just about every stakeholder stands to be affected.
What you actually need is for security incidents not to happen, rather than to have them detected quickly and sanctions imposed. So, we should be working on the security equivalent of painting the speed cameras bright yellow. And some of that equivalency might be through:
- Counting success through the absence of excitement – no breaches, no-one found doing anything silly
- Rewarding careful and considerate behavior – like checking the obvious things
- Making it obvious why and how people are being monitored – and demonstrating this is for protection rather than punishment
And one last security-policy thought from the UK’s approach to speeding. In the UK, for most drivers captured by a speed camera for the first time, the consequence isn’t a fine or penalty points on your license. Instead, it’s a speed-awareness training session. I’ve heard that they’re entertaining and useful sessions – can’t we make learning about security fun too?
So, the next time you’re using an expert to help with security, or anything else related to ITSM or IT, ensure that what they know is used as the means to a desired “end” and not the end itself.