How to distribute SOC tasks | Kaspersky official blog

Credit to Author: Sergey Soldatov| Date: Fri, 02 Sep 2022 17:22:13 +0000

Advanced cyberthreats keep throwing up increasingly challenging tasks for enterprise security operations centers (SOCs) to contend with. Organizations are also having to deal with internal problems, such as a lack of security talent, professional burnout, and tight budgets. A typical SOC consists of analysts who take the brunt of the alert triage and incident analysis, experts who analyze the most advanced threats, threat intelligence specialists, and a management team. While high-volume routine tasks are assigned to the analysts, there needs to be a way for them to organize their work as effectively as possible.

There are different approaches to the structuring and alert processing of a security operations center. According to an ESG report, there are in fact three approaches – with not one much more popular than another. More than a quarter (28%) of organizations say analysts in their SOC are tiered based on their skills and level of responsibility; in 36% of firms, employees are assigned to individual threat vectors; and another 36% say that their analysts all work together in a common alert line (as in – queue), regardless of skills or threat vectors.

Let’s drill down into these three different approaches, look at the pluses and minuses of each, and see if there are any other lifehacks available for staff in SOCs. It’s worth noting that the approaches listed below are not set in stone, and that in practice they’re usually mixed together to meet the needs of a particular organization.

1. Classic approach

The option chosen by 28% of organizations in fact represents the more classical approach to structuring a SOC. Analysts are separated into lines, with the first line processing all incoming alerts. They triage them and handle the ones they can deal with. If the incident is too complicated and the first line doesn’t have instructions on how to respond to it – or if it is a human-driven attack (which means an attacker is performing actions in real time instead of using automated tools) – then the incident goes to the second line.

Staff in the second line are more experienced. They either work through incidents according to a common line, or share them according to individual specializations – for example threats to OS (Linux or Windows) or network related threats. There is sometimes a third line which can be further divided into areas of specialization. This allows the first line to handle the most typical threats, the second to work with more advanced incidents, and the most sophisticated to be passed to the third line.

This structure allows for a heavy flow of alerts to be processed in the first line, where entry-level professionals can improve their skills in alert analysis. It also frees up more skilled analysts on the second or third lines, allowing them to develop more profound and specific knowledge. The effectiveness of alert handling should also increase through this structure, as more experienced employees process the more sophisticated incidents. But to make the approach work, very detailed instructions need to be developed for the first line, creating a large amount of preparation work.

2. Assignment on vectors, threat types, or areas of competency

Used by 36% of respondents, this model involves assigning analysts to different threat vectors, such as network attacks, attacks on servers or web applications, insider threats, or DDoS. Other parameters for division could be the type of system (such as endpoints, cloud or data centers) or its criticality: if it’s not critical, the incident is processed in the first line; for critical systems the task would go to the second line.

In practice, the first and second approaches are often used together as a hybrid model. For example, the first line deals with all incoming alerts, and if there are any cases of a specific type, they send these to specialists on the second or the third line that have been assigned to this specialization.

The benefit of this approach is that individuals can dive very deep into their fields of expertise, which ensures a high level of competency and quality in the incident response. It does, however, make it difficult to find a replacement for such specialists if necessary.

3. Single line

In this approach, used by 36% of organizations, analysts all share a common incident line. This means all experts work in the same line, with the same level of expertise, and can handle the majority of incidents within the line. However, there still can be some division, with the most sophisticated incidents often still going to a dedicated group of highly skilled professionals.

The structure of Kaspersky SOC is very close to this approach, with a distinguishing feature: an AI analyst takes the role of the first line. Thanks to its machine-learning model, it automatically filters out a part of false positive alerts, which saves analyst capacity. The technology also highlights any interesting details in the alerts and simplifies handling for analysts.

In the second line, any experts can examine any incident in a common line. If a member of staff cannot handle the incident, they can escalate it to a so-called “virtual line”. It’s virtual because it isn’t always there – only being created when the incident is escalated from the current line. Unlike the second line, its composition is not fixed – so it can include other experts from the second line who are free at the time, or highly qualified professionals in the third line who do not usually handle regular incidents – instead working to develop detection logic and perform proactive threat hunting.

With this approach, analysts can more broadly improve their skills – not limited to a specific attack vector or threat complexity. They become more experienced, which increases the overall maturity and effectiveness of the SOC. The variety of alerts can also reduce the risk of burnout because of monotonous work. On top of this, there’s always a covering party, which can pick up any escalated alerts.

On the other hand, this approach can become too labor-intensive as it requires more skilled personnel, and therefore a more challenging team composition, as well as requiring investment in development and proper implementation of AI analysis.

Another solution for the burnout problem

While the structure of an SOC is key to making it work effectively, there’s another lifehack that can provide employees with a break from routine tasks. In Kaspersky’s SOC, each analyst has two days per month when they do not process alerts and switch to more creative tasks. This could be improving some process, manually hunting threats, programming automation for SOC routines, reviewing reported incidents, or preparing a list of typical mistakes to improve the quality of the incident cards prepared for clients. Or they could spend time on self-education.

Also, if a team leader sees an employee making more mistakes than usual, they can suggest that they use one or both of those days as soon as possible – to take a break from the alert triage routine and clear their head.

Switching from routine tasks also allows the analysts to have a rest and reduce any stress from the monotonous work of processing alerts. An employer can encourage their team with bonuses if they offer valuable improvements to the security operations processes during their “self-days”.

SOC models may differ from business to business depending on their maturity, budgets and relevant cybersecurity risks. But we have also seen some global trends reshaping the SOC structure. The first is the automation of security operations and alert triage – for example with SOAR systems. Having access to all systems through a single point can greatly speed up alert processing. The second trend is the shortage of skilled professionals, meaning SOCs need universal specialists who can deal with a wide range of threats. While we’ve yet to see how these models will change under these trends, it’s a good time to analyze the current state of the people and processes in the security operations center and see what improvements are needed to stay protected from cyberthreats.

https://blog.kaspersky.com/feed/