SOC Mistake #5: You treat the SOC as a Project, not a BAU Activity
Building an effective and efficient Security Operations Centre can take a matter of years. Yes, you can build a foundational level of capability in several months (and it’s what companies used to pay me to do in my previous role), but it takes time for processes to be tuned and become muscle memory for the analysts;; to tweak the detection logic to filter out false positives; to optimise the triage and intrusion analysis playbooks al while minimising the risk of a real attack sneaking in as a false negative; – these activities all take time.
The transition from foundational baseline, implemented during the project to stand-up the initial capability, to the BAU capability is achieved through the implementation of repeatable and measurable processes, along with the metrics that provide the required telemetry for the SOC manager to make operational improvements: for instance “get analyst X who demonstrates competence to train analyst Y, who shows a weakness”; “retire use case A because the operational overhead of dealing with both real events and false positives exceeds the value of the mitigated risk to the business”; and “reinforce processes to analyst b who aren’t following the event’s playbooks but aren’t demonstrating improvements in effective or efficiency”. The reality is that most security operation centres aren’t even putting in the processes, let-ot-loan measurement to make them better – they’re deploying technology, putting people in front of the technologies UI and ending there. I’ll discuss metrics more in a later Mistake in this series.
Even with the right processes and measurement, it can means that it there is a period of 2 – 3 years for a SOC to reach it’s optimum maturity level (depending on what the business has defined that as) – during this time there will be new threat actors, new vulnerabilities, new systems implemented within the organisation and new defences. All of these changes of the goalposts need to be taken into account – putting a stake in the ground today on day one of the SOC build and saying we’re going to build this capability, using these event sources with these use cases over a 3 year period is a honourable endeveavour, but by time you finish in 2019, you’ll have a SOC fit for 2016. This is one of the reasons that when I was at HP we encouraged customers to see their requirements as fluid and likely to change overtime, whether this was due to discovering their baseline level of maturity was well off the mark after we started work; that the nature of their infrastructure or business changed or whether budgets got cut – the reality is the end point is a moving target and the best way to get there is small incremental steps.
I used to work for someone who’d come from an Audit background. She couldn’t see the requirement for many of our documents to be living breathing working documents: for instance our Attack Vectors and associated Indicators of Compromise and Contextual Enrichments events – this would change on a daily basis based on the availability of new events sources, new vulnerabilities and to compensate for adaptive behaviour by threat actors creating new attack vectors. Revision history, role-based access restrictions and change control are import – be she wanted locked down documentation, reviewed and changed on – at most – a quarterly basis, I wanted a Wiki (which allowed approval of changes, rollback and complete revision history) allowing constant improvement as a part of BAU.
With this in mind, consideration needs to be taken into account of not just the deployment of a SIEM and log management solution, along with recruiting and training some analysts, but to the ongoing operation of the SOC and the continual investment in time, effort and money needed to keep the SOC on target.
