Operating Model

Designing an operating model will help you enumerate and understand the components required when
building a SOC. It acts as the foundation for the various aspects of your design. By considering the threat
you are faced with, and the assets you are monitoring, you will be able to design a target operating
model (TOM) that is proportionate to your requirements.

Target Operating Model Architecture

A TOM architecture that considers your requirements and illustrates how the various components of a
SOC are related and how they work together to deliver security to your organization. It’s important to be
pragmatic and honest with your operating model, so that what you’re aiming for is proportionate and
achievable. That said, it should be developed with growth in mind so that you can adapt your capability
as your requirements and threat will change over time. Like most architectures, it will evolve as you go,
so don’t expect to stick to your original design, it’s a cumulative and iterative process. Remember what
you’re designing is a target operating model and it may take years to implement it fully.

Finally, it’s important to remember that there isn’t a golden panacea, there is no one-size-fits all
approach. This section will enable you to design a bespoke operating model that works for your
organization.

Things to Consider
It is important that the operating model you develop is proportionate to the threats you face and what
you are trying to protect.
Designing an Operating Model
Having developed a picture of the threats that your organization is trying to defend itself against and a
picture of the assets you need to monitor, you can now start to consider what your operating model
should include.
Target Operating Model
Having gone through the process of enumerating your threat profile, defining the SOC scope, and
evaluating what services would be proportionate for your SOC, you should be able to put it all together.

Things to Consider
It is important that the operating model you develop is proportionate to the threats you face and what
you are trying to protect. These aspects are explored in detail below, before moving on to a discussion
of their impact on the design of your operating model.
Threat Profile
The capabilities of your SOC should be proportionate to the threat faced by your organisation. This
means that the first task should be to define that threat profile. Your threat profile will influence your
approach to detecting attacks, and have implications for other SOC functions, such as the skills required
by your SOC analysts. Whilst some organisations with an extremely high threat profile may require a
SOC that can detect and respond to even the most sophisticated attacks, most will not. For example, the
threats facing a small retailer are likely to be different to the threats facing a large retail bank. There are
various ways of defining the threat profile of an organisation. However, it is advisable to consider the
sophistication of attackers you are expecting might target your organisation.
STIX v2.1
STIX v2.1 is an extremely useful framework for this as it provides a scale of definitions for threat actor
sophistication. These range from threat actors with little understanding and average computer skills to
professional and state actors who can work with and develop new vulnerabilities and affect the supply
chain. It is important to conduct an honest and reasoned assessment of the sophistication of threat
actor(s) that you suspect may target your organisation. Detecting an attack conducted by an “Innovator”
level actor is significantly more difficult than an “Expert” level actor, therefore this will have a significant
impact on your SOC design. Finally, it's ok to start with a lower capability and then improve as the SOC
matures, it's important to walk before you run.

Assets
It can be very difficult for a SOC to provide the same level of monitoring for an entire IT estate. For this
reason, SOC must understand what the organisation's most critical assets are, and the business context
in which they operate. This allows resources to be prioritised. Where possible work with existing IT
operations as they will be able to provide invaluable insight into the IT estate.

Understand the System and Context

The more detail the better, as this will help in building a baseline for normal operation. This is essential if
you want to detect when the system is operating abnormally and therefore, potentially under attack.
Your model of baseline activity should involve enumerating user and data flows, profiling user behaviour
and understanding how security controls are intended to work. Where possible, include the system
designers and developers in modelling a baseline, as they can provide valuable insight into the system,
also highlighting any potential vulnerabilities.
Threat Modelling
You should identify the most sensitive areas or targets within your system. What would an
(appropriately sophisticated) adversary be interested in exploiting? How would they go about doing so?
This kind of exercise should also be closely tied to Threat Intelligence, so that the scenarios and
hypotheses reflect real world scenarios and attacks. The Onboarding page discusses how this exercise
can be used to ingest systems in the SOC.
Impact Assessment
Understanding the impact of compromise of systems, service or assets will help you prioritise what you
monitor, how you monitor it and what you will do to respond to a detected attack. This approach is
important as the compromise of even the smallest systems can have a huge impact.

Designing an Operating Model

Having developed a picture of the threats that your organisation is trying to defend itself against and a
picture of the assets you need to monitor, you can now start to consider what your operating model
should include. The diagram below sketches the various typical capabilities of a SOC in the context of
sophistication and volume of attacks. Though this is quite difficult to illustrate and predict, this diagram
can be used as a rough guide to help you reason about the level of capability you should be aiming for.

SOC Capability Matrix

You may not have any real idea about the volume of attack but at this stage it is not so important, the
main outcome needs to be defining what level of capability is proportionate for your organisation, given
the potential sophistication of attacks in your threat profile. Remember that this is cumulative, so if you
perceive that your organisation would be targeted by highly sophisticated adversaries, you will need to
ensure that your SOC has all the preceding capabilities. In this example, in support of threat hunting you
would need to ensure that you have a mature use-case development capability and so on. The details
about what these functions include are covered in the Detection section of this guidance.

SOC Pillars
A useful approach when designing a SOC operating model is to split it into the following key pillars.
Informing the SOC – This is where you can place functions like Threat Intelligence, where the output
should be used as direction for the SOCs capabilities. In smaller SOCs this could simply be a third-party
intelligence feed.
Developing Capability
Here you would take the output of the informing function, SOC requirements or analyst ideas, and turn
them into a technical detection capability. You can also include engineering teams here to ensure that
the SOC capability is maintained and improved.
Detect and Respond
This is the bread and butter for most SOCs, when something abnormal, malicious or suspicious is
detected, the SOC needs to respond to it. This is where incidents are managed by teams such as Incident
Response or Incident Management.
Supporting the SOC
Depending on the size of your organisation or the scope of the SOC, you may require a supporting
function. This is where Customer relationship management or system onboarding would live and
typically would call on the other technical functions as required.

Informing
the SOC

Supporting
the SOC

React & Developing

Respond Capabiltiy

SOC Flows
As the diagram roughly illustrates, each pillar feeds into the next and its by establishing these links,
avoiding silos of information and knowledge, that enables your SOC to mature and respond to the ever-
changing threat landscape.

SOC Functions
To help you understand what functions you may need to include in your operating model design; the
most common core SOC functions are listed below. Note that there may be differing names for these
functions in circulation and some functions may be combined.
Threat Intelligence (TI)
This is the function that should provide the SOC with information about current cyber threats to the
organisation and IT estate. This typically includes indicators of compromise (IOCs) and qualitative
information about threat actors.
Threat Hunting
This is the function that aims to perform proactive, iterative, and human-centric identification of cyber
threats that have evaded existing security controls.
Content Development or Analytics
This is the team that turns actionable threat intelligence into programmatic detection rules within the
SOC tools. Which in turn are then used to identify suspicious behaviour from within your systems and
services.
Engineering
This team is typically responsible for the maintenance of the SOC tooling, the technical onboarding of
logs (sometimes referred to as plumbing) and ensuring all the systems are running.
Incident Response or Handling
This is the team that responds to security events by investigating the root cause of an event. Their main
objective is to determine whether an event should be escalated into a security incident.
Incident Management (IM)
When an event is confirmed as a security incident the SOC will pass the event to its IM team (which may
be a static team or a dynamic team that is stood up in response). This team will have a multitude of
responsibilities, from communications to technical reactions, all with the goal of reducing the impact
and controlling the damage caused by the security incident.

In addition to these core functions, some organisations may add other functions to the SOC:
Vulnerability Management
A SOC that is required to identify and manage vulnerabilities within the estate will require significantly
different resources (for example, the expertise and tools to test, patch and evaluate system builds). It
will require the SOC to be far more interactive with systems and this comes with greater responsibility. It
is important that the additional resources required for this function are captured within the design.
Insider Threat
A SOC that is required to detect and respond to insider threats will also have a different setup,
compared to a SOC geared only towards external threats. They aren’t mutually exclusive, but as
monitoring employees is a sensitive subject, any capability (specifically toolsets) that performs such a
task should be segregated. This is because the SOC and its staff, along with other business systems and
staff might be subject to security monitoring and investigations in response to security incidents.

Locality
Most SOCs will outsource some of their operations, even if it is just the signatures that your tools will
use for detection. There are many benefits to developing In-house functions, including better contextual
awareness of the business, which will aid any investigations that need to take place. However, from a
business point of view, it can also be effective to outsource a function if it is seldom used, or if the SOC
simply doesn’t have the resources to implement the function internally. When considering which
components of the SOC to outsource, it is important to determine the pros and cons of doing so. The
table below is intended to help you think about these decisions.
Example In house Outsourced

Pros Cons Pros Cons

Better business Resource Typically, an abundance of TI that Potentially very generic.

Threat Intel (TI) context. intensive. is shared across many Lacking business context.
Can look for intel Cost. organisations, a wide net.
relating to specific,
relevant threats.

Digital Forensics Better business Not always Can be called upon when Potentially lacking
and Incident context required. required. business context. Delayed
(DFIR) and expedited access incident response.
to devices.

This table is not intended to be exhaustive. The goal is to show the process of deciding which
components could be outsourced.

Resources
Finding the right people for the job may be one of the largest constraints when trying to implement your
operating model. This is an area where it becomes clear that your operating model is a target. Because it
is likely that it will take time to get the right people or train existing staff to deliver what is required. By
defining a threat profile and understanding the scope of the SOC you should be able to evaluate the
number of resources required to deliver it. Like the design process this will likely take multiple iterations
to get right. It’s impossible to prescribe exactly what people or skills you will need, however, there are
some key considerations:
Skills
The exact skill sets required by your SOC analysts will be influenced by the approach you take to attack
detection. However, you should ensure that the team have a wide range of technical skills and
experience needed to deliver the detection approach that you decide upon. It is extremely useful if your
team can understand the attacker’s mindset. Understanding how an attacker might target, and attempt
to exploit your systems, is fundamental to detection and response.
SOC Analyst
Good analysts are at the heart of an effective SOC, they can adapt to changing circumstances, learning
as they go, researching what an attacker might do next. Investing in the people that work in the SOC will
pay dividends. Analysts should be directed according to business needs and current circumstances.
However, you should be wary of pigeonholing analysts and isolating tasks. This often leads to issues, like
triage fatigue, poor job satisfaction and therefore poor security. The diagram below shows how analysts
can be involved in the development of a detection use-case. From understanding the threat in threat
intelligence, developing the use-case in a content development team, and triggering any events in
incident handling. Exposure to all these areas is extremely valuable.
 Threat
Intelligence

Analysts

Incident Use-case
Handling Development

Analyst Rotation
Enabling analysts to be part of and understand the SOC lifecycle often leads to better security. This is
because they will have more exposure to the context of systems, threat intelligence, detections, alerts
and encourages greater collaboration and synergy. This broadening of experience should not override
any subject specialisms, which should be taken full advantage of but where possible diversifying skills
should be a priority.

Governance
Thought should be given to where the SOC best fits under the organisational structure. It’s important to
ensure that reporting lines and oversight are appropriate for the work being performed. As part of this
the SOC will need to determine which metrics are being reported. Metrics can evolve over time to meet
the evolving needs of the organisation. Managing the operation of a SOC requires robust governance to
make sure the SOC is operating legally, complying with regulation, organisational policies and ensuring
that the SOC powers are not misused or abused. A SOC will no doubt be faced with questions such as
“Can you tell me what employee x was doing all day” and answering that question might not fall within
the remit of the security operations center. Defining where that line is will depend on what your
requirements are, however, be wary that diverting resources away from detecting security events might
have a detrimental effect on the capability of the SOC. SOCs can often have operating principles to
ensure that their work is legitimate, some examples:

• The SOC will operate within the boundary of the law, relevant regulation, organisational policy
etc.
 • Sensitive data will only be collected/searched/indexed to detect malicious, suspicious or abusive
behaviour that might harm the reputation, prosperity and security of the organisation.
• Data will only be held until it is no longer required or up to a maximum of x months.

Further Considerations
At this point, the various parts of a SOC design should be coming together, but there are of course,
further considerations.

Continual Improvement
Continual improvement is critical to the success of a SOC, because the environment they operate in and
the adversaries which they face, are constantly evolving. These challenges fall into three broad
categories:
Ever-Changing Environment
Your organisation will most likely be constantly evolving, your business might change, making you more
attractive to attackers. The assets you are trying to protect might change leading to gaps in your
monitoring capability. If you incorporate review cycles into your SOC processes, you should be able to
stay on top of this.
Changing Threat Landscape
Attackers continually update their methods and motivations may change. This is where Threat
Intelligence comes into play.
Maintaining Detection Effectiveness
All detection approaches require a SOC to build and maintain its detection methods in order to remain
effective. This includes building new security alert logic and investing in the continued development of
your analysts.

Hours of Operation
Whilst cyber-attacks can occur at any time of the day, when deciding what hours of operation are
needed, there are some significant considerations. For example, maintaining a 24/7 SOC will require
significantly more staff than a 9-5 operation with out-of-hours on-call. While a 24/7 provides round the
clock monitoring, and may be appropriate in high threat scenarios, a 9-5 operation still provides 100%
more monitoring than having no SOC at all.
What are the hours of operation of other IT functions?
Most significant incidents will require other IT functions to be part of the response. Consider the hours
of operation of these teams. The effectiveness of a 24/7 SOC would be greatly reduced if other IT
functions are only covered 9-5 with no on-call arrangements.
Does the organisation already have a 24/7 IT function that can receive high priority security alerts?
Some organisations will already have 24/7 coverage being performed by another IT team, such as a data
center operations team. Consider routing high priority out-of-hours security alerts to this team for initial
triage, before escalating to SOC analysts.
Consider sending high priority alerts to out-of-hours on-call SOC analysts
Alternatively, if you decide that you need the ability to respond to potential incidents immediately,
consider using alerts to automatically notify an on-call SOC analyst.

SOC Security
Keeping the data and services within your SOC secure is essential because the information gathered by a
SOC can be considered very sensitive and, as such, would make an attractive target for a threat actor.
This information may include sensitive information about your organisation, personally identifiable
information (PII), financial data, or even details of the security controls implemented across your IT
estate. Additionally, if they had access to this information, malicious actors could benefit from being
able to access or modify it, to hide their tracks, enhance their attacks or even evade any post-incident
clean-up operations. Some key considerations of SOC security are:
Sensitive Data
This is a difficult aspect to control, especially in SOCs with large sets of customers and systems to
protect. It is important that the SOC operates within its legal and regulatory requirements and ensures
that the appropriate controls are in place to enforce this. This could be validation of data ingest or alerts
to detect sensitive data.
Segregation
You should segregate SOC services so that, if a component of your IT estate is compromised, the
attacker will not have a direct route to your SOC data.
Separation of Duties
There is a risk that users with highly privileged administrator accounts could perform malicious activity
within your organisation. For this reason, SOC services should reside in a separate security domain. This
means any potential attacks that leverage administrator accounts would be detected and the threat
actor would not be able to affect the audit trail.
Auditing
It is important that the users (SOC staff) of the SOC’s services are accountable. This can be done by
creating privileged accounts and functions that can report and alert SOC actions. In line with good
security practice this should follow the principle of least privilege and access to this should be extremely
limited.

Target Operating Model

Having gone through the process of enumerating your threat profile, defining the SOC scope, and
evaluating what services would be proportionate for your SOC, you should be able to put it all together.

It’s common for SOC operating models to be represented on a single page:

 Very basic operating model diagram

Basic Operating Model

The diagram above is very basic and your design will likely differ. However, it is important to keep it
simple at the start and revisit the model as the design process continues. Once you’re able to start
digging down into each of the pillars or functions it is important to capture how each component should
be interacting with others and most importantly what the key outputs are. There are many ways to map
this but if you’re stuck, the SIPOC model is very useful. Once the dependencies, inputs, processes, and
outputs are enumerated and understood, you can start establishing technology requirements and find
the most appropriate tools for your SOC. When you’re able to proceed:

The next section covers the principles of Onboarding, an area that is often underestimated and
therefore, under resourced.