MITRE publication ‘11 Strategies for a World-Class SOC Centre’. Strategy #3 ‘Align your SOC structure to your company's needs’. Part 1

Ruslan Rakhmetov, Security Vision

Despite similar principles, the process of building and the target SOC structure depend on the business requirements of customers, the state of cyber security, current threats and cyber risks. In Strategy #3 ‘Build a SOC structure according to the company's needs’ the authors of the publication consider various options of SOC structures, SOC organisational models, SOC premises, as well as discuss the feasibility of outsourcing SOC functions and introducing a 24-hour duty shift.

1. Drivers of SOC structure selection

1.1 The mission to be accomplished and the business to be protected influence the choice of SOC structure in terms of the understanding of:

- business needs: size and maturity level of the company, feasibility and amount of resources allocated to the SOC, interaction of departments, selection of priorities in SOC activities;

- the level of cyber risks of the customer company: depending on the confidentiality of processed information and legislative requirements for its protection, the interest of attackers in this company, the need to use the functionality of redundancy of technical means and ensuring the continuity of SOC operation;

- activities of business units and employees of the company: ensuring interaction with various groups of stakeholders, analysts' understanding of business processes, needs and daily operations of the company's units.

As a result, the authors of the publication note that the further the SOC analyst is from the protected assets (in the physical, logical and hierarchical sense), the less context for situational awareness he/she will have; in case of large companies with a large number of branches and subdivisions, the solution may be to build a hierarchical SOC model with parent and subsidiary SOC structures.

1.2 Planned accountability and responsibility of the SOC

The SOC centre needs a set of authorities to address the challenges of cyber incident management and the SOC structure should facilitate the development of a common identity, set of authorities and responsibilities, and the acquisition of appropriate resources.

1.3 What services the SOC will provide:

The set of services and tasks that a SOC can perform is very broad, ranging from trivial monitoring of IS incidents to vulnerability scans, pen-tests, cyber threat hunting, and cyber intelligence. In large companies, as a rule, certain IS tasks are already handled by departments other than the SOC, but their effective solution may also require the involvement of SOC analysts.

1.4 Operational efficiency

There is a worldwide shortage of qualified IS specialists, and consolidation of experts into a single SOC centre unit will not only allow their knowledge and skills to be applied more effectively, but will also enable them to improve their skills and work more efficiently.

1.5 Boundaries of SOC monitoring and protection responsibilities

Most SOCs are responsible for monitoring and responding to IS incidents in the IT infrastructure (traditional on-prem, cloud and remote environments) as well as in mobile and OT infrastructure. Depending on the customer's business and the convergence between OT and IT networks, the SOC centre's area of responsibility will include both IT and OT elements. Combining the functions of IT and OT protection under the roof of one SOC provides both certain advantages (faster threat detection, reduced communication time, more detailed understanding of incidents and cyberthreats) and creates difficulties (the need for specialists with appropriate qualifications, the use of IT and OT protection solutions applicable to IT and OT, possible technological or organisational limitations of the SOC).

2 SOC organisational models

The structural model of the SOC depends on the scale and specificity of the customer, whose hierarchical structure may determine the appropriate SOC structure (parent/parent SOC and several subordinate SOCs). The SOC structure should also take into account the role model of the SOC personnel and the organisational structure of the SOC itself.

The authors of the publication point out the following possible types of SOC organisational models:

2.1 On-demand response. It is used in small business organisations with up to 1000 users/devices. With this model, the company does not have a dedicated response team, resources are brought in on demand when an incident occurs, and incident management processes are generally not well defined.

2.2 IS as an additional burden. Used in small businesses, small institutions with up to 1000 users/devices. In such a model, no formal SOC is defined, but some management processes may be performed by company employees (e.g. system administrators), with some response procedures formalised.

2.3 Distributed SOC. This model is used in SME organisations, small regional institutions, with 1000 to 10000 users/devices. The SOC has formalised authority, the team of such a decentralised SOC consists of employees from different departments of the company, and the SOC personnel can combine their incident response duties with other tasks.

2.4 Centralised SOC. This model is used by a variety of companies, from medium to large, as well as federal level institutions, with the number of users/devices from 10000 to 100000. When using this model, resources are consolidated within a single unit (SOC centre) and SOC employees have clearly defined roles. This SOC organisational model is the most common and most of the advice in this publication applies to it.

2.5 Federated SOC. This type of SOC model is best suited to companies with an extensive holding structure of branches and subsidiaries that operate fairly independently of each other (e.g. in the case of a recent merger or acquisition where the businesses are not yet integrated into a single structure), with the number of users/devices ranging from 100,000 to millions. The SOC in such a case may be both centralised and hierarchical, but with subsidiary SOCs that are fairly independent of each other, while sharing some common policies and authorities.

2.6 Coordinating SOC. The model is used in large companies or government agencies (ministries, departments) with the number of users/devices from one million. This type of SOC is responsible for coordinating the activities of subordinate SOCs, focuses mainly on providing situational awareness and high-level cyber incident management, but does not manage the operational activities of the SOC centres it coordinates.

2.7 Hierarchical SOC. The model is similar to a coordinating SOC, the difference being more active involvement in the operations of subordinate SOC centres, for example, by providing services to subordinate SOCs and coordinating their functions.

2.8 National SOC. This type of centre is applied at the state level, is responsible for the state of national cybersecurity, shares information on cyber threats, cyber incidents and vulnerabilities among multiple companies and institutions, and can coordinate response to incidents of global scale.

2.9 A MSSP (Managed Security Service Provider) or SOC-as-a-service (SOC-as-a-service). This model can be used by companies of different sizes with different number of users. Its advantages are in the outsourcing model of the services provided and the ability of the customer to quickly connect the services and purchase them as needed.

3. Possible organisational structures of a centralised SOC

Having considered above various organisational models of SOC, the authors of the publication write that the most common in most cases will be the centralised SOC model, which has the following advantages:

- Dedicated resources, specialisation in cyber incident management;

- Ownership, engagement, unified goal setting and a developed common identity for the response team;

- Centralised monitoring and management of all cyber incidents, synchronisation of all resources;

- Effective teamwork and synergy due to the absence of organisational barriers;

- Cost effectiveness, cost reduction;

- Higher authority and power of the SOC compared to other models;

- Qualified and motivated team of dedicated experts;

- Continuous increase in process maturity and efficiency due to a unified goal and a cohesive team;

- Unambiguously defined area of responsibility and mission.

The following is a description of some possible SOC organisational structures.

3.1 A conditional (typical) centralised SOC

In the example of a typical centralised SOC, the following are highlighted:

- A SOC management team responsible for managing the SOC's operations, planning activities, strategy development and process improvement, business continuity and business recovery planning, and developing and monitoring metrics for evaluating SOC performance. This level will include the SOC Manager, who is responsible for SOC operations and performance, measuring performance and planning SOC development.

- Cyber Incident Triage, Analysis, and Response Team, responsible for monitoring and triaging alerts and reports of potential incidents from various sources, analysing and investigating incidents, containment, remediation, and recovery actions, and coordinating response activities. Additionally, this team may be involved in forensic analysis of incident artefacts, VPO analysis, response to incidents with on-site customer visits. This is a key SOC team that enables the core functions of cyber incident management, the data for which may come from a variety of sources and in a variety of ways.

- The Cyber Threat Intelligence Management Team (CTI, Cyber Threat Intelligence). CTI (Cyber Threat Intelligence), Cyber Threat Intelligence, Search and Analysis, Analytics and Advanced SOC functions, which is responsible for cyber threat data management (collecting, processing, enriching, analysing, distributing and providing access to cyber threat data relevant to the company, in close cooperation with other SOC groups), searching for cyber threats, configuring sensors and analytical platforms, customising analysis tools and detecting cyber attacks. Additionally, this group can perform such tasks as Data Science and machine learning, cyberattack emulation and audits, defence against insider intruders, deception activities (deceiving and confusing intruders to hide company assets and learning attackers' TTPs). The work of this group allows the SOC to focus on cyber threats relevant to the company and relevant groups of attackers, and provides the necessary information to SOC members developing correlation rules, signatures, and response playbooks. The result of this group's interaction with other SOC teams will be synchronisation and synergy of cyber threat search results, detection rules, triage and cyber incident investigation.

- Architecture, engineering and administration group responsible for configuring SOC hardware and infrastructure, developing and managing SOC tools, developing and managing the analytics platform, deploying and managing the SOC environment, and developing customised solutions. The authors of the document strongly recommend that this group should not be taken outside the SOC, i.e. outsourcing (both external and internal), due to the need for centralised management of SOC technical facilities, improving the quality of work of the engineering team in direct close interaction with SOC members, and the ability to manage engineering resources more efficiently.

- Situational Awareness, Communications and Training Group, which is responsible for providing stakeholders with situational awareness of the customer company's cyber security and cyber threats, conducting internal and external training, and conducting cyber exercises. The work of this group affects the reputation of the SOC within the company, allowing it to gain more authority and resources.

3.2 A small, centralised SOC

In the case of small SOC centres, with 5 to 20 employees, some functions such as forensics and VPO analysis, customer visits, cyber threat hunting, working with Data Science, and developing in-house technical tools may not be performed on a regular basis. In addition, the authors of the paper recommend combining some functions in one group in smaller SOCs. For example, the CTI group can be combined with the main incident response group, the engineering support group may not be divided into specialisations (technical tools or SOC infrastructure), and SOC managers can participate in the investigation of complex incidents, conduct forensics and research of VPO. The SOC may also perform vulnerability management functions, in which case a separate team may be responsible for inventorying information assets, scanning for vulnerabilities, analysing vulnerability reports, managing security updates and mitigating vulnerability exploitation risks.

3.3 A large centralised SOC

Large SOC centres will have more functionality and high-level positions, functional groups will be more specialised, more response activities will be able to be templated and regulated. For example, the incident response team may have a separate team to triage incidents, and will be able to conduct site visits to customers, conduct forensic investigations and VPO analyses on a regular basis using specialised tools. The cyber threat search, cyber threat data management, and insider breach teams can be strong stand-alone units. There can be a dedicated pen-tester team specialising in customer infrastructure and working closely with the vulnerability management function. Internal development of customised tools may be strengthened, the application of Data Science and machine learning may be more extensive. Engineering teams may be given different directions according to the specialisations and needs of the SOC, and the interaction between different SOC departments, with partners and stakeholders will require special attention.

3.4 Choosing between a tiered and a non-tiered SOC model

In most long-standing SOC-centres there is a classical division by levels (Tier) of functioning, the so-called L1/L2/L3 levels (on L1 the incoming flow of incidents is processed, on L2/L3 - their detailed analysis, research, forensics if necessary). At the same time, it is not necessary to divide SOC into levels at all, and an unleveled SOC model can be based on specialisations and functions of teams. The authors of the publication point out that the choice of SOC model in terms of levels depends on a particular customer, but they give recommendations for effective organisation of both models.

For SOC with a tiering model it is recommended to:

- Not only define target metrics, but also ensure that they are understood by analysts and regularly updated, and that analysts agree with them;

- Other SOC employees should not look at L1 operators ‘top down’, the labour of all SOC employees regardless of level should be respected;

- Promote successful L1 operators to higher positions, allow them to automate the activities they perform;

- Do not require L1 operators to necessarily move to higher levels and positions after a certain amount of time;

- Compensation should not be tied to a position or role, but should be based primarily on the success of the individual employee.

For SOCs with a tierless model, it is recommended to:

- Allow SOC workers to grow without compromising the quality of response, for this purpose more experienced colleagues can help newcomers, response scripts can also be used;

- Assist workers in prioritising their actions, provide clear guidance on priority actions;

- Manage the distribution of job responsibilities and eliminate duplicate functions;

- Build a collaborative and supportive work culture.

The application of both models should enable SOC centres to perform the following functions well:

- Respond to all alerts, triage them;

- Respond to alerts in a timely manner, without compromising quality in favour of meeting timelines;

- Handle all alerts thoroughly, recognising that some alerts may take a long time to analyse;

- Give each SOC employee tasks according to their level of knowledge and skills;

- Provide employees with opportunities for growth;

- Improve the level of quality of work and repeatability of actions, and try to avoid mistakes in performing active response actions, as they can lead to negative consequences such as business process downtime.

3.5 Hierarchical structure of SOC centres

In the case of large, complex hierarchical organisational structures of the customer company, it may probably be necessary to organise a hierarchy of SOC centres. In such a hierarchical structure, the parent SOC would focus on strategic situational awareness and support for the fulfilment of cyber security objectives within the customer's structures, while subsidiary SOCs would operate ‘closer to the ground’, performing their tasks at the level of individual business units or subsidiaries of the customer.

3.6 Coordinating SOC

A coordinating SOC at its level may provide certain unique capabilities to subordinate SOCs:

- Strategic analysis of attacker TTPs relevant to the customer's infrastructure and its subsidiaries;

- Operational delivery of up-to-date and relevant cyber threat data, including indicators of compromise, as well as advisories, fresh signatures, machine learning models, and analytics for SIEM systems;

- VPO analyses, forensic research, emergency response to dangerous cyber incidents;

- Aggregation and sharing of knowledge, best practices, IS process descriptions, technical guidelines and recommendations;

- Provision of sites and facilities for secure interaction and collaboration between subordinate SOC centres;

- Centralised management and provision of licenses for technical facilities of SOC-centres;

- Training of employees of subordinate SOCs in the use of technical tools, response to cyber incidents, vulnerability management and pen-tests; cyber training and cyber-attack drills/simulations.