For an independent company, starting its own Security Operation Center might sound like a good idea. However, it turns out that it often presents a huge challenge with very mixed results. Thus, we will review some of the themes that can lead to internal failures of SOC projects based on our customer’s feedback.

The SIEM implementation

Implementing a SIEM is not a major challenge. However, setting it up requires a varied body of knowledge and a lot of experience. First of all, the selected product requires specific technical knowledge in the following areas:

• The organization and operation of a large volume of data
• Sorting events to keep only the essential ones, and not being overwhelmed by useless data
• The creation of relevant detection rules that respond to threats defined by input from the Incident Response and Business Risk Analysis teams

In addition to SIEM related knowledge, it is necessary to have an excellent general knowledge of networking, perimeter security, and system administration to be able to efficiently onboard log sources into the SIEM.

Finally, it is vital to be able to set up the processes and means to facilitate fast alert classification, regular testing and the review of detection rules, to ensure a good quality of service. This organization covers the detection of suspicious behaviour, alert triage and analysis, SIEM operational maintenance, as well as Incident Response preparation.

From SIEM to SOC: light and fuel the fire

To illustrate the fundamental activities in place around the SIEM, we can use fire allegory. Indeed, to trigger the firing alerts, we need fuel or an oxidizer such as events, flows, etc, which in this case will be the parsing activities, and a spark, the correlation rule. This serie of events enable the firing alerts to be the basis of our analysis and detection activities. Once the SIEM architecture is in place, we will be able to hook up a set of management processes whose aim will be the central mission of a SOC; detect and alert about suspicious behaviours.

SOC: The incident funnel

Once our events are received and automatically processed by rules, the highest level of the funnel is in place as our SIEM trigger alerts. It is now necessary to configure the lower levels of the funnel to receive and process the alerts. The aim is to determine whether these alerts should be turned into security incidents or not. This is where the analysts come in.

Drawing on their technical knowledge and experience, in partnership with the relevant system teams, their mission is to determine whether an alert is a proven security incident, or whether this is just a false positive. Generally speaking, it implies that a whitelisting should be implemented.

As part of a proven security incident, they pass the torch to the incident response teams. These teams will be in charge of remediation activities. The funnel view allows us to illustrate the different missions of a SOC ranging from processing a large volume of log items to the detection of security incidents including the response to incidents by authorized-to-intervene specialists (CERT / CSIRT).

Detection by adding and managing Use Cases

As already described, an organization must identify, classify, and prioritize the threats they are exposed to depending on the business to protect. For this, a risk analysis is necessary to define critical and damaging scenarios. These use cases, coupled with a good knowledge of the current threats’ trend, make it possible to develop and excecute effective detection rules. Implementing these rules without clear established objectives will lead to an activity’s slowdown. Indeed, this may happen in the face of high alert volumes and poor decision making by those responsible for escalations.

Besides, a detection rule, once implemented, is not immutable. The threat context evolves as well as the IS in which it is implemented. It is, therefore, required to “keep these rules alive” and to provide time for resources. Surely the resources need to review rules regularly, improve them, eliminate false positives, possibly replace or deactivate a rule, etc.

Final word

As we saw above, wanting to create your own SOC can be a real challenge. It is possible to summarize the key components around 4 dimensions:

• Maturity: having a perspective the business risks resulting from current threats to the business
• Experience: Security teams in the implementation, management and operation of detection rules according to a specific context
• Specific skills: technical skills around Security and IT Infrastructure but also in terms of communication with other teams
• Coverage: For the service schedules and the attack surface.

We have to consider these elements before launching a project to correctly define the precise scope of the SOC. Failure to consider these elements often leads to the slippage of a SOC implementation project. Plus, it quickly results in escalating service costs, which outweighs the benefits gained leading to the abandonment of sponsors. Once these elements are considered, it is important to define a clear and small scope. Indeed it allows us to gain experience and a gradual widening of the scope. This is as often an excellent approach to adopt.