Interviews

Trick or treat

by Mark Rowe

Mike Bursell, Chief Security Architect at Red Hat, a cloud and other platform IT company, offers a security lesson from Hallowe’en.

I don’t really “do” Hallowe’en: mainly because I’m curmudgeonly British, and because I don’t like sharing confectionary with anyone without a good reason. But as I was preparing to shut myself into the house, close the curtains and pretend that nobody was at home, it occurred to me that the whole ghastly “trick or treat” business actually might have something to teach us as security professionals.

As my North American colleagues explain it, the point of trick or treating is that young visitors come to your house and offer to scare you. You have the option to accept being scared, or to bribe the putative perpetrators into not scaring you by offering them a handful of mass-manufactured sugary goodness or a selection of home-baked quinoa tortilla chips if you’re from a particularly hip urban quartier.

Here’s what occurred to me: everybody takes the “treat” option, but we need to be scared. If we don’t let ourselves be scared from time to time, then personally, organisationally, it’s easy to slip into one of two modes: complacency or panic.

In complacency mode, you’re kind of aware that there are threats out there, but you decide that you’re probably safe with the measures you have in place, and as long as you apply the patches that your vendors send you within eight to twelve weeks, then, well, what’s the worst than can happen? The answer, if we’re honest with ourselves, is that when an attack or compromise happens, the day-to-day business of your organisation can come crashing down at your feet, you’re left with a reputational mess, prosecution under the GDPR and an invitation from the Board to find a new job elsewhere (and no, they’re not going to provide a reference).

In panic mode, we spend our time seeing the worst, worrying that every network spike is a DDoS attack, patching systems with the latest patches before assessing the impact on production systems, and stopping our development teams from deploying anything because they haven’t followed the 64-step process that you hammered out during an all-nighter five years ago when your boss asked what the organisation’s Secure Development Lifecycle process was the day before. And the worst that can happen in this case? Paralysis, distrust and a blame game when your organisation can’t innovate as quickly as the competition, leading to the same invitation from the Board to reconsider your position that arose from complacency.

So, of course, there’s a middle way. We need to be ready to respond, but also allow changes to take place. How do we do that, though? Well, we need to allow ourselves to be scared. Humans learn when they’re exposed to something new and have that little kick of adrenaline. I’m not advocating opening up all of your systems to all and sundry and letting the those attackers wreak havoc over your business – that’s the equivalent of going down into the cellar alone in just your night clothes and a flickering candle when half of your friends have already mysteriously disappeared – but what you can do is take some control and, most important, prepare.

The first thing you can do is a risk assessment. What data, what systems, which people, which processes, would affect your business the most if they were compromised, lost or disabled? What would that impact look like? Once you know this, you can decide where to expend the most effort in defence. You can also think about the most likely types of attacks and attackers – but don’t get too hung up on this, as it’s the unexpected that will surprise you every time. To address what’s unexpected, there are things you can do: you might get a penetration team in, or just do some brainstorming internally, for instance. And if you do, make sure you get people from all over the company: HR, legal, sales, and office services will all bring different perspectives that you and your team will never consider on your own.

It may seem counterintuitive, but much of our preparation shouldn’t necessarily be proactive, but actually be about helping people to be reactive when things go wrong. It’s no longer of matter of “if” we’re attacked, but “when”, and once people realise that, and know that they should be doing in the event of something unexpected, they – and you – will be much happier. You need to explain to everybody – from CEO to receptionist – what to look out for, and what to do. Often “what to do” will be reporting something to a particular email address or telephone number, but if there is no process, there is no chance for people to do their right thing, and they are likely to freeze or to panic, neither of which are what you want.

Most important of all? Automate. There’s only so much analysis that people can do, and they can only move so quickly. Machines can’t make clever decisions – though the growth of Machine Learning and Artificial Intelligence systems are bringing that ability closer – but they can act consistently and fast. And though they may be able to move fast, it is up to you to consider what actions they should be taking – is it more important to keep the sales systems up or address a possible malware attack, for instance? This ties in with your risk assessment. They may also be bad at anticipating the unexpected – so you need to consider what they should be watching. And they will never see everything – the news report on a new ransomware attack, the visitor placing a USB drive in an unauthorised machine – you can reassure your staff that there will always be a place for humans in the mix. Or, of course, zombies, werewolves or vampires: whatever takes your fancy.

Related News

Newsletter

Subscribe to our weekly newsletter to stay on top of security news and events.

© 2024 Professional Security Magazine. All rights reserved.

Website by MSEC Marketing