Shiny kit isn’t always what you need

This article appeared on LinkedIn on 5th April 2017, and you can read it in full here. 

Earlier this week I saw an item on LinkedIn where someone was asking advice about building a SOC (Security Operations Centre). It set me thinking that often we see a great clamour for solutions, for the latest shiny bit of kit with flashing lights and a cool name, but do we ever stop to wonder why we need it?

Before we even look at equipment or software, the very first step should be to look at our business objectives. Why are we doing what we do, and do our objectives help achieve that? What is our end goal? Without knowing this, how can we possibly determine the best solution for our needs? 

We should then look at our risk registers, to identify the key areas of risk, and to determine whether by mitigating any of those we will reach our end goal – or at least be closer to it than we currently are. How many of those risks require human interaction, and how many are dependent on hardware and software?

Looking at our policies and procedures next, we should try to establish whether they are helping us achieve our stated aims, or are they hindering that task? Are we able to amend the working processes in a way that makes them cost effective and help us meet our business goals? 

Do your staff understand the business objectives, and are they appropriately skilled / experienced to help reach those objectives? If not, what do they need to help them understand, and what training / guidance do they need? 

Once you’ve gone through all these steps, you’ll have a good idea of what’s missing, what is preventing you from achieving your business goals. Write these down, as they will form the basis of a specification document which will identify the requirements of any solutions you need. It might not be that big shiny box from vendor A: it might be additional training for your staff, it might be a paper based process or it might be a bit of software instead. You’ll also have some idea of the level of risk, and how much money you’re able to devote to addressing the gap, through a cost benefits analysis. This will help determine your budget for any additional actions / solutions you find that you need. In some cases it boils down to scale, and the type of business. For example, why would an SME with 5 people working in an office need their own SOC? They may need one, but could probably outsource it rather than build and maintain their own much more cheaply.  

I’ve worked on a number of consulting engagements where the client has told me they need the latest and greatest bit of kit, but when pressed for the reason behind this decision they could only come up with “because all my competitors are using it so I should have it too” or “the salesman told me it would solve all my problems”. Those are hardly sound business reasons, wouldn’t you agree? 

I was speaking at an event recently, one of a long series, and the moderator told be before it began that they’d had quite a few people in, from the intelligence community as well as vendors, telling the attendees that this gadget or this software would solve all their problems, would address their biggest issues, would remove most of their risk. Fabulous claims, but how could they be sure? They didn’t know the attendees’ businesses, they didn’t know the policies, processes, controls and systems the attendees already had in place, they didn’t know what the attendees’ risks were – so how could they possibly offer a solution? It doesn’t make logical sense, does it?  

I’m reading a really good book at the moment, called Start With Why by Simon Sinek. It very sensibly suggests that before setting out to build a new business, or to grow an existing venture, you should ask yourself why you are doing it. The same applies to technical solutions I think – work out why you are doing what you are doing, and why you need to change, then take things from there. The answer may not be that super cool shiny box with lots of flashing lights.