Today we will talk about Security Operations Center (SOC) by people who do not create and customize it, but check how others have done it. Under the test gets the efficiency of the SOC, built for your company independently or by someone from the outside. The check answers the question “Does 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 talk about our experience in checking SOC in different companies within our projects.



For those who already know what SOC is and what they drink it with, we suggest you immediately go to the second part of the article. The rest offer to read the entire article.

Part 1. A bit about SOC for beginners

Protection of information systems comes out on top 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 observation tools detecting anomalies, and response tools. At last, but not least, the stage of fighting threats is people, although it happens that the security problem can be solved without attracting 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 be different from company to company, but there is a general trend - companies gradually, 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 are collected in one place, less likely that some of them will be lost;
• SOC allows you to customize the rules for classifying security incidents according to the needs and peculiarities of a particular company;
• SOC allows you to minimize the time it takes to detect and respond to security incidents, thereby reducing the potential damage to the company;
• logs that fall into SOC are reduced to a single view, which allows you to effectively investigate security incidents, even if an attacker attempts to sweep away traces of his presence in the system.

SOC is an infrastructure with many interrelated components, its basis is SIEM (Security information and event management). SIEM is a system for collecting, normalizing and correlating data, which collects logs from web servers, host machines, and other infrastructure components, as well as information security tools installed on organization's network devices, correlates and processes them to bring them to a normalized look. This is the main task of SIEM - to bring to a single format a huge number of logs from different sources for the convenience of detecting the relationships between them. This is necessary for one more component of SOC, SOC analysts, who, looking at the huge lists of logs from SIEM, should respond to some of the events themselves or transfer them to the work of security specialists.

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

• definition of the protected infrastructure, both at the organizational and at the technical level;
• installation of all possible / necessary means of protection and monitoring, as well as their setting;
• Selection of a suitable SIEM and its adjustment depending on the company’s features;
• creating event correlation rules;
• SOC team selection - people whose job will be to monitor events and make corrections to correlation rules, as well as to respond to security events.

Even after everything is determined, installed and configured, no one guarantees that SOC now works as you would like, or as shown in the beautiful presentations from SIEM developers. The fundamental problem with the use of any means of protection is that almost 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. Also extremely important is the level of maturity of the company in matters of security.

Since SOC is a complex and complex 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 don’t check the effectiveness of SOC, but leave everything as it is?

Let's start with the fact that something can go wrong, even with the slightest changes in the infrastructure of the organization. And they occur quite often - someone leaves, new people come, something breaks, hardware and software are updated, and much more. In this case, the GIS settings and correlation rules should be quickly changed, but they often forget about it, and when they remember, it is too late.



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



The problem may be in the SIEM . 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 omission of the attacker's actions. It is worth clarifying here that data from one source is not always enough. 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 set up in such a way that to determine the incident that happened, there may not be enough data from one source, which indicate the fact of its occurrence. Those. There will be a puzzle consisting of data from several sources. Also, the rules for some security events may be absent altogether.

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

The rules for assigning events to incidents in the SIEM may be configured incorrectly by themselves, or they may be missing for any events. Also, incidents are usually of a level of importance, the incorrect definition of which can lead to big problems.



People working with the SIEM, whose task is to respond to security incidents, can also cause missed attacks and subsequent information security problems. They may skip some signals from the SIEM or respond incorrectly to the attacker's actions for various reasons. There is also a problem that people leave sooner or later, and new employees need time to study.

Given the above, SOC testing to test performance is extremely important both during the implementation phase of a SOC 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. SOC Performance Review

SOC testing in a company can be conducted in several scenarios. We will tell about those that seem to us the most effective.

SOC testing tasks include checking security by replicating typical behavioral scenarios of intruders. These include:

• brute forceing accounts of other users using brute force, as well as using the password spraying technique. The use of 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, often the password spraying technique is forgotten and, accordingly, the SOC rules are difficult to detect for such an attack;
• downloading data from a web resource, whether it is a corporate wiki or 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 whose behalf the attacker works. A simple example is attempts to authorize a user from the 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 techniques of filtering the transmitted data. This is primarily about dns and icmp tunnels, but sometimes it makes sense to start with simpler checks, for example, try to look for an open tcp or udp port, as well as an additional gateway (gateway). To search for gateways, by the way, there is a modified implementation of one popular tool from one of the employees.

This list of checks can be continued for a long time. The most important thing is 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 knowledge of infrastructure - whitebox.

More about each of them.

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

Such a model assumes that an attacker who does not have any additional information has obtained access to the company’s network and any of its 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 through directories, accounts, sends to all ports all the known exploits, throws XSS, SQLi, RCE, SSTI, NoSQLi, etc web applications. In general, he behaves extremely aggressively in the hope of hacking at least something. During the audit, the auditors imitate the actions of such an intruder, maintaining a given degree of insanity, but are ready to stop at any time at the request of the SOC or in case of technical problems. By the way, an unexpected and pleasant result can be the discovery of vulnerable services and applications in the company's infrastructure.

Another testing model is the whitebox. In this case, the script is unfair employee. Usually at this point auditors are well-versed in the customer’s network and can play such a role. The behavior of a potential intruder in this case can be characterized by high selectivity of both the means and the targets of the attack. Here you can already draw some parallels with APT attacks . The auditors attack only the weakest places in their view and use thoughtful and narrowly focused attack vectors, as well as trying to gain access to sensitive information outside the competence of the role of their account with a subsequent attempt to pump it out of the protected perimeter. All the actions they are trying to perform in such a way as to go unnoticed by the company's security service.

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

Finally, when the idea of ​​the security of the tested infrastructure is developed, the 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. Such interaction between auditors and SOC analysts can be very productive, and during the consultation it will help to detect logical errors and omissions in setting up SOC components. Their root is usually a lack of insight from SOC analysts on 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 offenders.

Such a complex of activities allows you to:

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

For assistance in writing this article, I express my gratitude to Denis _ttffdd_ Rybin and Ivan Chalykin .