Building a Security Operations Centre (SOC)

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.

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.

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.

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.

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

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 actually 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 in a position 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 as a whole 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 mindset. Understanding how an attacker might target, and attempt to exploit your systems, is fundamental to detection and response.

The SOC analyst

Good analysts are at the heart of an effective SOC, they have the ability to 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 resembles 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 triaging any events in incident handling. Exposure to all these areas is extremely valuable.

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 also 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.

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 in order to meet the evolving needs of the organisation.

Managing the operation of a SOC requires robust governance in order 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 centre.

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 as a whole.

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 in order 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.

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:

• An 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 the 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 centre 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 on SOC actions. In line with good security practice this should follow the principle of least privilege and access to this should be extremely limited.