As with most aspects of cyber security, building a reactive security function has no correct answer. As the cyber landscape develops, the silver bullet product and other definite answers seem to be further and further away from being achievable. Being in a position where you are tasked to protect an organisation from something defined as “the cyber security threat” can be very daunting. If one tries to google “protection against cyber security threats” or “mitigating cyber risk,” you may just end up with more questions than answers.

This blog post is written mainly for individuals looking to build a function that will respond to security threats within an organisation. I could have called the function a SOC, CSIRT, CSOC, cyber defence centre etc., but in lack of a good term that defines the whole umbrella, I’ll refer to it as a reactive function. I also hope the train of thought presented here will help those with existing functions to identify areas of improvement. Especially in terms of tying your capabilities together!

What does building a reactive security function entail?

There are few blueprints that explain exactly how organisations should organise themselves in order to respond to potential security threats out there. The good old IDS based central SOC has seen its heyday, and we now see a shift towards more distributed approaches as a result of DevOps and cloud workloads. Early adopters saw this early in Google and Netflix where you see more of a “you build it, you secure it” approach. Both for prevention and detection.

Understanding what operating model suits your organisation is difficult enough, but understanding what steps to take, at what time and how fast you need to get there on a strategic and tactical level is equally difficult. If you are looking to start from scratch, or if you already have a function in place, it’s important that you realise what steps should be taken to ensure success.

How many times have we seen larger initiatives to build a SOC or another reactive security function be driven by technology or specific capabilities? For instance starting off acquiring a SIEM tool or SOC/MDR provider without understanding that particular capability's role in a larger picture. This leads to a non-cohesive approach, which more often than not leads to a lack of understanding of whether the efforts made are the right ones at the right time, and if they support the business objectives at all.

In the figure below, I want to show how a journey to build a reactive function could look like. I also want to show how an approach driven by a particular technology or capability could leave you with more questions than answers. The goal should be to understand why you are implementing the particular capability at that particular time.

To illustrate how to implement a larger capability its necessary to include several steps and multiple dimensions - strategic as well as operational. I’ve tried to visualise a structured approach to building a larger capability which entails the “journey” one takes when starting from scratch.

This approach attempts to build a function that provides answers to why certain tasks are being performed, and at what time. Taking you all the way from business goals down to particular operational tasks. Having this common foundation stemming from the business’ goals will make it easier to prioritise which tasks pushes towards these goals, and which do not.

The approach forces you to reflect over what is important to the business and what specific capabilities you could implement to enable the business. The process also covers steps for defining a strategy where you will have to make it clear how far you want to go, when you will get there and how you intend to take that journey.

Theoretical vs Practical

While writing this post, I reflected around common denominators for the projects that implement a reactive security function successfully. That commonality is depressingly, pain. Incidents are usually what triggers investments into cyber security. Such occurrences will very often require acquisition of capabilities in hurry, leaving you without the luxury of planning all your steps ahead. This comes at the expense of not being at the appropriate maturity level when making these investments. For instance not having stand up basic monitoring with some response capabilities and without having made plans of how to support these functions over time. Realistically, I believe most organisations can relate to this.

If you find yourself reading this, realising you skipped most of the “non-technical” steps, I think there will be value in backtracking and performing the strategic steps to better understand if the steps you already took made sense and how to set yourself up to take the next.

Lastly… Be concrete! A flashy strategy is seldom worth its time and effort unless it shows how you intend to operationalise your goals into capabilities that will yield value. So let’s get specific!

You have some high flying thoughts about the steps you want to take... Now how do we get specific?

Having a clear understanding of dependencies and synergies is imperative when designing your function. There will be tools out there that will help you define requirements, for example in guidelines provided by NIST, ISO, SIM3, FIRST and many more. These organisations provide maturity assessments and lists of typical capabilities you would need, which can be used as inspiration to fill your project plan. From there, defining an operational model will help you understand how these capabilities and technologies will be interconnected. As such, it can also be used to identify missing capabilities in terms of personnel, competency or other dependencies such as governance, risk and compliance elements that will play a larger role for how you understand the landscape you are meant to protect.

This situational awareness plays an important role when building your function. Having a strong GRC backbone with insights into values, risks, assets and your threat landscape is essential to be able to contextualise and rationalise the “five Ws” when making priorities, choices and decisions.

To exemplify, I’ve visualised an operating model I was presented awhile back which has four interconnected pillars:

• Situational awareness
• Incident response
• Detection development
• Security monitoring

These four pillars will be connected in many shapes and forms, each with their own set of capabilities. By visualising these intertwined connections and branches we quickly get a visualisation of your capability needs. However, what it does not show is how much we need of each capability, when we need it and how we will get it. This is where understanding your own business and the threat landscape you reside in comes in together with investment opportunity - aka your situational awareness!

Are you set up for success?

Dependencies, dependencies, dependencies…

You’ve read the guidelines and used the frameworks. You now have a great plan. As well as management support. You designed how your function is going to look like. All is good!

But is your plan set up with necessary means to succeed? Realising where a reactive security function resides in the overall security ecosystem is important. And order is key!

We want to put ourselves in a position to detect when the bad guys come knocking on our door, but also to kick them to the curb when need be. However, to get there requires an understanding of which steps need to be taken prior to others. I.e building a lot of reactive mechanisms such as detection will be a frustrating effort if there are no resources or preventative mechanisms that are put in place to reduce noise over time.

Let me draw a parallel to policing. We use police to enforce laws and regulations in a community that desires to live peacefully together. Philosophically, you could say that police are there to ensure that our way of life is not threatened. Efficient policing of a community does not start and end with cars patrolling around, where the quality of the policing is defined by who sits in the police car or what type of police car is used. It will be defined by multiple aspect such as, funding, access to resources, structure, training, legislative support, etc. Your reactive security function will have similar dependencies.

Triangles of cyber security

To explore these dependencies, I’d like to show how Forrester depicts their “targeted attack hierarchy of needs.”

As you can see, the reactive aspect of cyber security is placed at the very top of the pyramid. This means it’s going to be hard to know how much detection and response you want to build (or acquire) without a form of foundational strategy guiding your direction.

Detection and response efforts will be drowned in a sea of alarms if one fails to implement protective mechanisms prior to reactive mechanisms. If your organisation has no one that focuses on the “fundamentals”, performing tasks such as patch management, resources to administer proxies, firewall and identities, it’s going to be a tall order to build a reactive product that will eliminate the risks tied to preventative capabilities. And in many cases, if there are no preventative mechanisms in place, you cannot do detection.

Lastly, I want to emphasise the importance of building a function that allows for automation and orchestration. It’s a necessity to keep up with the amount of information thrown at what we today call “security analysts” but tomorrow will refer to as “security engineers”

If the prerequisites of detection and response are not met, it’s not likely that you will be able to efficiently provide the capabilities you see relevant for the business based on the journey depicted in Figure 1 or the operational model you have designed.

We want to be able to act!

We're not finished with the dependencies...

In the very end, after going through all the different steps above, our goal is to be in a position where we can counteract adversaries. We want to be certain that we have the necessary competency and man/womanpower to combat threats that your organisation might face.

Matt Swann at Microsoft has depicted his own incident response hierarchy of needs which I think fits well together with Forrester’s triangle. Where Forrester focuses more on security as a whole, Matt Swann shows the needs of the reactive function in more detail.

There will be multiple capabilities, technologies, and competencies tied to these different needs at different levels. These need to be defined in your operation model, and this triangle insinuates the order of implementation.

Final remarks

Building a reactive function, no matter if you called it a SOC, CSIRT, CSOC, cyber defence centre etc., will never be about silver bullets or definite answers. Hopefully this blog post has provided some “food for thought” and inspiration to help identify areas of improvement to your function – both if you are looking to start from scratch, or if you already have a function in place.