
The unintended consequences of good security
My bag felt light yesterday morning. I didn’t think much of it until I got to the station and realised why: my laptop was still at home.
For a moment, I considered going back. Twenty minutes home, a couple of minutes to grab it, then perhaps another thirty to get back to the station. I’d lose an hour, possibly my parking space and maybe another train. Everything would be getting tight for my first meeting.
So I decided to chance it.
Maybe I don’t need a laptop
Actually, most of my day would be fine. I had my work phone for a Teams call and could take notes on that too. The RFP response I needed to review would have to wait until I got home, and I’d need to work into the evening, but that wasn’t the end of the world. In some ways, it was a nice demonstration of how much less dependent we’ve become on a particular device.
Then I remembered the presentation.
The deck was in OneDrive and I’d sent a link to my team the day before. I could open it on my work phone, but that wasn’t much use for presenting to a room — I couldn’t access my notes at the same time. I had my personal iPhone and iPad with me, though. Surely I could just open the presentation in a browser on one of those?
No. And, to be fair, that’s exactly what our information protection controls are there to prevent. The presentation was classified Internal and my personal devices are unmanaged. I wasn’t trying to download it or keep a copy; I just wanted to open it in a browser long enough to put it on a meeting-room screen.
There must be another way
So I did what people do when technology gets in the way: I started looking for an alternative approach. At that moment I wasn’t thinking like a technology leader, considering information classification, device management and acceptable risk. I was just a user, trying to get stuff done.
Could I get the link onto another device? Could I open it differently? Could I ask a colleague to present it for me? Eventually, I presented from a colleague’s laptop. Problem solved, and without moving the information somewhere it shouldn’t be.
But it left me thinking about the friction we introduce in the name of security. We might understand all the individual layers and controls we’ve put in place, but our users don’t experience them individually. They experience the cumulative friction when something they need to do doesn’t work.
And their need to get stuff done doesn’t disappear.
Friction changes behaviour
That’s the bit I think we sometimes miss. When we introduce a security control, we quite rightly think about the behaviour we want to prevent. I would argue that we should spend some time thinking about the behaviour the control might create too.
I needed to present that deck, so when one route was closed I looked for another. I found an approved route, but make legitimate work difficult enough and people will inevitably find other ways to get it done. That’s not necessarily because they’re malicious or careless. Sometimes they’re just users with a meeting starting in ten minutes.
That makes security friction more than a user-experience problem. A control can reduce one risk while inadvertently encouraging behaviours that create another.
I’ve seen this before. One organisation I worked for introduced a multilayered information classification scheme intended to help people protect information appropriately. The choices were complicated enough that some users responded by marking almost everything as unclassified. A policy designed to improve information protection had inadvertently encouraged people to do the opposite. Not because they didn’t care about security, but because the secure way of working had become too difficult.
There isn’t an easy answer to this. Removing the controls isn’t it, but neither is assuming that tighter controls are always better controls.
Somewhere between information protection and getting the job done is a judgement about acceptable risk. When we’re making that judgement, we need to consider not only what a control prevents, but what it encourages people to do instead.