How to properly deploy a Security Operation Center?

What is a SOC?

A SOC is an entity that relies on both software and organized security analysts to detect, analyze, report, respond to and prevent cybersecurity incidents.

To carry out these missions, the SOC relies on the analysis of very large volumes of data, analyzed in real-time.

As this GBHackers article explains, “Foran organization to be considered a SOC, it must provide a means for constituents to report suspected cybersecurity incidents, incident handling assistance to its members, and dissemination of incident information to stakeholders and external parties.”

What preparations should be made before deploying a SOC?

Defining your needs

Before being deployed, a SOC must be designed to meet specific needs, which are unique to each company. No two SOCs are alike. For some entities, part of these needs stems from national regulatory requirements. At the European level, it is the NIS directive that qualifies certain companies as operators of essential services.

Thinking about data collection

In addition to the rules imposed by national and international laws, the design is based on several studies. These studies aim to define detection rules (to which we devote a paragraph below). They are designed to cover risks based on the most likely use cases that concern the greatest number of people (detection of phishing, malware, etc.) or scenarios more specific to each context. A SOC thus identifies what differs from a standard.

To collect the data needed to design the detection rules, it is necessary to:

• Perform a risk analysis.
• Identify the collectible data and that covers the risks identified in the analysis.

Thinking about work organization

Building a SOC requires a complex organization because it remains operational 24/7/365. A context that raises certain questions in terms of recruitment and work organization: without analysts, there is no SOC.

SOC: the construction phase or “build” phase

Once the above information is collected, the “build” phase begins. This phase is quite technical since it is the configuration of the SIEM, or Security Information and Event Management. This is the software that allows detecting an incident or deviance. The SIEM is configured to meet the needs and security context of each company.

To do this, it must collect data.

SIEM: what data should be collected?

The main purpose of the “build” phase is:

• to set up the SIEM.
• ensure the collection of data.
• extract and normalize data.
• enrich the data with contextual information.
• to set up the correlation rules.

The data collected comes from sources as diverse as:

• applications.
• user workstations and terminals (if the company uses an EDR device).
• infrastructure or security equipment (relay, firewall, anti-virus, etc.).
• Windows & Linux servers, physical, virtualized, on-site, or in the cloud.
• connected objects, industrial systems, etc.

SIEM: How do you determine the detection rules?

The implementation of detection scenarios is a complex process. These are based on the analysis and correlation of the collected data.

To determine the right scenarios for your company, infrastructure rules, and so-called “business” rules will be established. These rules are bound to evolve according to the realities of the field and in particular, the state of the threat, permanent monitoring of the logs is planned.

SOC, SIEM: managing false positives

The SOC is designed to generate alerts when anomalies are detected. However, these alerts can be false positives. That is, they are not real threats. To limit these false alerts as much as possible, a precise definition of the threats and the actions of a scenario are necessary.

A poorly configured SIEM wastes a lot of analyst time. So, it is better to spend the time necessary to determine the configuration for your company.

It should be noted that the incorporation of threat intelligence – also known as Threat Intelligence – remains an effective solution for the investigation phase in particular.

Management of the SOC operations phase

The deployment of a SOC in a company goes through the RUN phase: this is the conduct of the SOC. It is a matter of ensuring that alerts are reported, and investigations are carried out.

As seen above, a SOC must be operated continuously. This requires human resources. You need analysts, operators, and experts to manage and monitor the SOC. Several options are available to you in this RUN phase. You can choose to form an internal team or hire the services of an external team.

It is also possible to host the company’s SIEM within the company’s infrastructure. Many companies opt for cloud hosting. The organization of the personnel in charge of the SOC must be the subject of a more thorough study and respect the regulatory framework, about day/night rotations.

As an illustration, in France, in 2020, the average salary of a junior SOC analyst is around 38,000 euros per year. To be able to operate 24/7, a company needs at least six analysts per team, which represents at least 230,000 euros each year. In addition to these costs, there are the costs of recruitment, management, and maintenance of skills, as well as the acquisition, development, or integration of software and infrastructure whose maintenance in operational or security conditions must be guaranteed. It is also necessary to consider the time needed to set up the system to be operational.

Thus, not all companies have the means to build their SOC. So, they turn to cybersecurity service providers.

Automating alert management

Automating some of the tedious tasks involved in running the SOC would be a great help to operators and analysts. Many automation tools, including those for alert management, exist on the market. Others are still under development. It is important to choose them according to their real performance and maturity.

However, the implementation of automation requires a prerequisite in terms of efficiency and maturity of the orchestrated detection systems.

Conclusion

A well-configured SOC is your best ally in detecting threats. Also, detection and correlation rules must be regularly questioned and updated by expert, experienced teams who are aware of the business context. Safety is a set of processes, not a product.

As a complement to the technology you invest in, more and more organizations are choosing to set up their own SOC (Security Operations Center). This whitepaper aims to guide you on how to set up your own SOC. Download it here.