Three methods for SOC structure and alert processing
How to delegate SOC responsibilities in order to address both the cybersecurity skills shortage and fatigue.
Advanced cyberthreats continue to provide more difficult jobs for business security operations centres (SOCs). Organizations must also cope with internal issues such as a shortage of security skills, professional burnout, and limited finances. A typical SOC is made up of analysts who handle alert triage and incident analysis, experts who study advanced threats, threat intelligence professionals, and a management team. While the analysts are assigned high-volume regular duties, there must be a mechanism for them to arrange their work as effectively as possible.
A security operations center’s structure and alert processing can be approached in a variety of ways. According to an ESG assessment, there are three ways, with none being significantly more popular than the others. More than a quarter (28%) of organisations report that analysts in their SOC are assigned to individual threat vectors based on their skills and level of responsibility; 36% report that employees are assigned to individual threat vectors; and 36% report that all analysts work together in a common alert line (as in-queue), regardless of skills or threat vectors.
Let’s go deeper into these three techniques, weigh the benefits and drawbacks of each, and see whether there are any more lifehacks accessible to SOC personnel. It’s important to note that the methodologies stated below aren’t written in stone, and that, in fact, they’re frequently combined to match the demands of a certain company.
-
Traditional method
The solution picked by 28% of firms illustrates the more traditional approach to SOC structure. Analysts work in lines, with the first line handling all incoming alarms. They triage them and deal with the ones they can. If the event is too sophisticated and the first line lacks instructions on how to respond to it, or if it is a human-driven attack (meaning an attacker is executing activities in real time rather than utilising automated tools), the problem is escalated to the second line.
Second-line workers have greater experience. They either work through occurrences along a similar line or share them based on unique expertise, such as risks to operating systems (Linux or Windows) or network-related threats. There is occasionally a third line, which is further subdivided into areas of specialty. This allows the first line to manage the most common threats, the second line to handle more complex occurrences, and the third line to handle the most sophisticated attacks.
This structure enables a high volume of alerts to be handled in the first line, where entry-level workers may enhance their alert analysis abilities. It also makes more skilled analysts available on the second or third lines. allowing them to gain more in-depth and specific information This structure should also improve the efficacy of alert handling as more experienced staff handle more complex issues. However, in order for the strategy to function, highly specific instructions for the first line must be prepared, resulting in a significant amount of preparation work.
-
Assignment of vectors, danger kinds, or competency areas
This methodology, which was used by 36% of respondents, comprises allocating analysts to several threat vectors, such as network assaults, attacks on servers or online applications, insider threats, or DDoS. Other characteristics for division might include the kind of system (such as endpoints, cloud, or data centres) or its criticality: if the event is not critical, it is treated in the first line. The work would be delegated to the second line for important systems.
In reality, the first and second techniques are frequently combined to form a hybrid model. For example, the first line handles all incoming alerts, and if any instances of a certain type are found, they are sent to experts on the second or third lines who have been assigned to this speciality.
The advantage of this strategy is that employees may go deeply into their areas of expertise, ensuring a high degree of skill and quality in incident response. It does, however, make finding a substitute for such expertise difficult if necessary.
-
Use a single line
Analysts all share a common event line in this technique, which is employed by 36% of firms. This implies that all specialists operate in the same line, with the same degree of competence, and are capable of handling the vast majority of occurrences inside the line. However, there is still considerable separation, with the most complex occurrences frequently being assigned to a dedicated group of highly qualified personnel.
The structure of Kaspersky SOC is fairly similar to this strategy, with one key difference: an AI analyst serves as the first line of defence. Its machine-learning methodology automatically filters out a portion of false positive signals, saving analyst capacity. The system also highlights any important features in the notifications, making them easier for analysts to handle.
In the second line, any expert can investigate any incident that occurs in a common line. If a member of staff is unable to manage the situation, it might be escalated to a “virtual line.” It’s virtual since it’s not constantly there, only appearing when an event is escalated from the current line. Unlike the second line, its composition is not fixed, so it may include other experts from the second line who are available at the time, or highly qualified professionals from the third line who do not typically handle regular incidents, but instead work to develop detection logic and perform proactive threat hunting.
With this technique, analysts may broaden their expertise rather than focus on a certain attack vector or threat complexity. They gain experience, which boosts their expertise, which boosts the SOC’s overall maturity and efficacy. The diversity of notifications can help lower the danger of burnout due to repetitive employment. In addition, there is always a covering party that may take up any escalated alarms.
On the other hand, this technique can become excessively labor-intensive because it demands more trained employees and hence a more difficult team composition, as well as investment in AI analysis creation and effective implementation.
Another answer to the problem of burnout
While a SOC’s structure is critical to its effectiveness, there is another lifehack that can give staff a reprieve from monotonous activities. Each analyst in Kaspersky’s SOC gets two days each month when they do not handle alerts and instead focus on more creative things. This might include optimising a process, manually hunting risks, implementing automation for SOC processes, analysing reported events, or compiling a list of common errors to improve the quality of incident cards presented to clients. They might also devote time to self-education.
Also, if a team leader notices an employee making more mistakes than normal, they might propose that they take advantage of one or both of those days as soon as possible to take a break from the alert triage routine and clear their thoughts.
Switching from typical jobs also enables analysts to relax and relieve tension caused by the boring labour of processing warnings. Employers can reward their teams with bonuses if they make significant changes to the security operations procedures during their “self-days.”
SOC models may change from one company to the next based on maturity, funding, and applicable cybersecurity concerns. However, several worldwide changes have reshaped the SOC structure. The first is security operations and alert triage automation, such as SOAR systems. Having access to all systems from a single place can significantly accelerate alert processing. The second trend is a scarcity of trained experts, which means that SOCs require generalists who can deal with a wide spectrum of risks. While we have yet to see how these models will alter as a result of these developments, now is a good moment to assess the existing condition of the people and processes in the security operations centre and determine what adjustments are required to remain secure against cyberthreats.
