Silos within the SOC Team Part 1: Know your sh*t
I’ve seen a great amount of improvement in the integration of these three teams within the dozens of SOCs within enterprises I’ve visited over the past year, but there is a still a long way to go.
Too many threat intelligence functions are still focused on the collection and dissemination, and less on the analysis. The quality, context and ultimate usability of threat intelligence is down to the analysis stage that (should) sit between collection and dissemination. I also still see an overwhelming focus on tactical threat intelligence, such as Indicators of Compromise, rather than the more operational and strategic capability to identify potential adversaries and their targets within the business.
The reasons for both the lack of analysis and focus on tactical intelligence typically both come down to the same problem: not understanding the assets in use within the business and how those assets support the operations of the business or organisation. While Indicators of Compromise provide useful trail heads for Hunt Team functions, blindly hunting down these without the context of whether the IoC is even valid in your environment is a waste of time and effort.
Too often I see security operations department bemoaning the lack of asset information as “IT’s fault” and I see IT waiting on some mythical CMDB project that will deliver perfection…..but always is two years off from completion. Then I see the CMDB project that started a decade ago finally delivering results, only for the requirement set at the beginning of the project to understand virtualised environments fail to deliver in 2020s reality of containerisation and CI/CD deployment models.
The first thing any organisation that truly wants to manage its cyber risk, rather than deliver compliance with external obligations, has to do is understand what it has and how it supports the business. Am I suggesting a waterfall-based massive project to establish a definitive body of knowledge of all assets in the business? In short, no - but they may be the ultimate destination. With the current level of maturity in most organisations around asset and change management, any improvement is a step forward. As always, my mantra is deliver these incremental small improvements day-after-day, week-after-week, month-after-month, while continuing to adjust direction to changes in technology and adversary behaviour, and you will eventually get closer to the destination.
So what does this look like in reality? Well the first things to realise is that everyone is busy and no-one likes change. So going out to IT, who may already have their unicorn CMDB project on the back-burner, and saying that you need asset information to prioritise, investigate and resolve incidents might not cut much sway. My experience in delivering transformation in cyber security operations over the past couple of decades has been that politics and culture are far bigger impediments to success than budget and headcount (once you get over a very base level of capability). So how do you motivate others to work with you, especially considering the often frought relationships between IT and cyber security in many enterprises?
Firstly, show them how much time they are wasting with the status quo. In order to do this you need an ability to analyse the time spent in each stage, and sub-stage, of the detection-triage-investigation-response timeline. This is where many traditional Security Orchestration Automation and Response (SOAR) platforms come unstuck - many of the vendors have strengths in particular aspects of this timeline such as enrichment, playbooks or orchestration - but very few actually handle the end-to-end timeline, including driving process and controls improvements, from a holistic end-to-end perspective. Some have case-management, but from the within-the-SOC perspective. pushing events out to the third-party ticketing system when it crosses a swimlane, loosing fidelity, context and granularity of measurement.
To build this picture to support your case for change, you need granular information on which role worked on what and for how long. Ideally you will also have information on what the type of incident being investigation could mean to the business, in terms of a loss event (whether this is a set value or a loss distribution). It is at this point in time, armed with these metrics, that you can start to build a picture of both the manual effort made by the IT teams to identify assets within the business and the increased risk exposure caused by the time delay. Share this information with the IT team first, you now have both carrot and stick: they’re aware of how much time they’re wasting on manual processes and they’re also aware you can present a timeline showing quick turnaround at the other stages of the incident timeline (that is the case, right???) and then a huge delay in awaiting response on IT asset context.
Hopefully this helps you build the bridges, but now you’ll need to work together on what the solution is. Well, this is be part 2 of this series
