Today we’ll talk about the Security Operations Center (SOC) from people who don’t create and configure it, but who check how others did it. The effectiveness of the SOC built for your company independently or by someone from the outside is checked. The check answers the question “Does the SOC fulfill the tasks assigned to it or not, and how effective is it?”. After all, the presence of SOC does not mean that it works as it should and you are aware of any possible incidents and other security problems. We will tell about our experience in SOC verification in different companies within our projects.



For those who already know what SOC is and what it is drunk with, we suggest immediately go to the second part of the article. We suggest that you read the rest of the article in its entirety.

Part 1. A little about SOC for beginners

Protection of information systems comes first in almost any industry. Any unauthorized access to information can lead to serious problems for the company.

The information system of any, even the smallest company, is complex, and all its parts must be protected according to the same principle - first organizational, then preventive measures, then surveillance tools that detect anomalies, and response tools. People are at the last, but not least, stage of combating threats, although it happens that a security problem can be solved without involving people, for example, by automatically blocking ports or disconnecting the machine from the public network. The tools used to protect each of the components of the system may vary from company to company, but there is a general trend - gradually companies, regardless of their size, come to the idea of ​​implementing the SOC - Security Operation Center.

There are several reasons for this:

• Using SOC reduces the cost of manually tracking security incidents
• system events gather in one place, less likely that any of them will be lost;
• SOC allows you to configure rules for classifying events as security incidents in accordance with the needs and characteristics of a particular company;
• SOC allows you to minimize the time of detection and response to security incidents, thereby reducing the potential damage to the company;
• the logs that fall into the SOC are brought to a single look, which allows you to effectively investigate security incidents, even if an attacker attempts to notice the traces of his presence in the system.

SOC is an infrastructure with many interconnected components, its basis is SIEM (Security information and event management). SIEM is a data collection, normalization and correlation system that collects logs from web servers, host machines and other infrastructure components, as well as information security tools installed on devices of the organization’s network, correlates and processes them to bring them back to normal. This is the main task of SIEM - to bring a huge number of logs from different sources to a single format for the convenience of detecting the relationships between them. This is necessary for another component of SOC - SOC analysts who, looking at the huge lists of logs from SIEM, must respond to some of the events on their own or transfer them to work for security specialists.

There are no two identical SOCs because its configuration is individual for each organization. The main stages of creating SOC are as follows:

• defining a protected infrastructure, both organizationally and technically;
• installation of all possible / necessary means of protection and monitoring, as well as their configuration;
• selection of a suitable SIEM and its adjustment depending on the features of the company;
• creating event correlation rules;
• selection of the SOC team - people whose work will be monitoring events and making corrections to the rules of correlation, as well as responding to security events.

Even after everything has been defined, installed and configured, no one can guarantee that now SOC works as you would like or as shown in beautiful presentations from SIEM developers. The fundamental problem with using any means of protection is that virtually no one knows how effectively they work. It is important not only to install and run them, but also to make sure that the measures taken are effective. The level of maturity of the company in matters of security is also extremely important.

Since SOC is a complex and multi-component structure, it is important to understand that at each of the listed stages of its creation, something may go wrong. And this is likely to affect the overall security of the system and the efficiency of the SOC itself.

Part 2. What happens if you do not check the effectiveness of the SOC, but leave everything as it is?

To begin with, something may go wrong, even with the slightest change in the organization’s infrastructure . And they happen quite often - someone leaves, new people come, something breaks, hardware and software are updated, and much more. In this case, the settings of the SPI and the correlation rules should be promptly changed, but they often forget about it, and when they remember, it is too late.



The next part of the SOC where errors may occur is remedies, from which information enters SIEM, can be configured incorrectly and skip actions directed to the system from the outside. And if the attacker's action is not detected by any of the existing SZI, then it will not get into the logs and will not be in SIEM, and most likely the security service will not know about it soon.



The problem may be in SIEMeh. It may not work as you would like. Events that fall into it may be correlated incorrectly due to errors in the correlation rules, which will lead to the skipping of the attacker's actions. It is worth clarifying here that there is not always enough data from one source. There are cases when, to determine security incidents, it is necessary to combine data from several sources at once in order to get a complete picture of what is happening in the system. But it may turn out that the rule is configured so that to determine what happened the incident may not be enough data from one source, which indicate the fact of its completion. Those. a puzzle consisting of data from several sources will not work out. Also, the rules for some security events may not exist at all.

At the stage of correlationevents in SIEM several problems can arise at once. One of them may be a delay in the transmission of events from some sources, which may interfere with successful correlation.

The rules for classifying events as incidents in SIEM may not be configured correctly on their own, or they may not be available for any events. Also, incidents usually have a severity level, which if not correctly identified can lead to big problems.



Peoplethose working with SIEM, whose job it is to respond to security incidents, can also cause missed attacks and subsequent information security problems. They may miss some signals from SIEM or react incorrectly to the attacker's actions for various reasons. There is also the problem that people will quit sooner or later, and new employees need time to train.

Given the above, SOC testing to verify performance is extremely important both at the SOC implementation stage and over time. Since the specialists of our company already have experience in this matter, we decided to describe the main points and nuances.

Part 3. Checking the effectiveness of SOC

SOC testing at a company can be conducted in several scenarios. Let's talk about those that seem most effective to us.

SOC testing tasks include security testing by reproducing typical behavior scenarios inherent to cybercriminals. These include:

• iterating through the accounts of other users using brute force, as well as using the password spraying technique. Using this technique is possible if you have access to the list of existing accounts in the system, for example, through the address book of the mail client. In our experience, password spraying techniques are often forgotten and, accordingly, SOC rules can hardly detect such an attack;
• pumping data from a web resource, be it a corporate wiki or a task manager. Such an attack can be carried out including using various web crawling and directory brute mechanisms. Separately, auditors pay attention to API services and their capabilities;
• repeated attempts to access resources or projects that are outside the competence of the role on behalf of which the attacker works. A simple example is attempts to authorize a user from a group of developers on the resources of network administrators and security services;
• Attempts to download a large amount of information from the corporate network using bypass filtering techniques. This is primarily about dns and icmp tunnels, but sometimes it makes sense to start with simpler checks, for example, try looking for a tcp or udp port open outside, as well as an additional gateway. To search for gateways, by the way, there is a revised implementation of one popular tool from one of the employees.

A similar list of checks can be continued for a long time. It is most important to be guided by the real needs of the client and the checks implemented by him.

SOC testing can be done in two ways:

• blindly - blackbox;
• with infrastructure knowledge - whitebox.

More details about each of them.

First of all, you should check the operation of SOC in blackbox testing mode. Its essence is that the employees of the SOC department are not aware of the work being carried out and react to all events in combat mode. Auditors / pentesters are given access to the corporate network, and accounts can also be given from the most widely used services in the company.

Such a model assumes that an attacker who does not have any additional information gained access to the company’s network and any of the existing accounts in an unknown way. The actions of such an attacker are characterized by a high degree of randomness and “noise”. He actively scans the network, iterates over directories, accounts, sends all exploits he knows to all ports, throws up XSS, SQLi, RCE, SSTI, NoSQLi, etc web applications with vectors. In general, he behaves extremely aggressively in the hope of hacking at least something. Auditors during the audit simulate the actions of such an attacker, maintaining a given degree of insanity, but are ready to stop at any time at the request of the SOC service or if technical problems arise. By the way

Another testing model is whitebox. In this case, the scenario of an unscrupulous employee is worked out. Usually, at this point, the auditors are well versed in the customer’s network and can play such a role. The behavior of a potential attacker in this case can be characterized by the high selectivity of both the means and the targets of the attack. Here it is already possible to draw some parallels with APT attacks . Auditors attack only the weakest places in their opinion and use well-thought-out and narrowly targeted attack vectors, and also try to access sensitive information outside the competence of their account role with the subsequent attempt to pump it out of the secure perimeter. They try to perform all actions in such a way as to go unnoticed by the company's security service.

After testing, the analysis and comparison of the results obtained by the auditors and the incidents detected by SOC employees usually begins. This stage will provide a general picture of the effectiveness of the current work of SOC and can serve as a starting point for all further plans to expand existing checks and approaches.

Finally, when an idea of ​​the security of the tested infrastructure is compiled, auditors can use the whitebox testing to analyze the existing set of rules, as well as the events on the basis of which these rules are formed. This interaction between auditors and SOC analysts can be very productive, and during the consultation will help to identify logical errors and omissions in the configuration of SOC components. Their root is usually the lack of understanding by SOC analysts of how a real attacker can act and what tricks he can perform on systems.

Conclusion

The most critical services that deserve closer attention are tested separately using two models of intruders.

A similar set of measures allows you to:

• significantly increase the awareness of security managers about the state of their infrastructure;
• conduct military exercises for the SOC department with the opportunity to get advice from experts in the field of audit;
• detect and correct existing errors in the work of SOC, as well as generally increase the company's security.

For help in writing this article, I thank Denis _ttffdd_ Rybin and Ivan Chalykin .