Myths and legends of SOC builders, or 3 misconceptions about centers for monitoring and responding to cyber attacks

V SOC-Forum, the largest event on the practice of detecting and analyzing incidents in Russia, will start tomorrow. I am sure that many readers of this hub will be there and hear a lot of professional reports in this area of ​​information security. But in addition to the terms, definitions and established practice, which is covered at the SOC Forum, in real life, each of you probably heard a lot of different opinions about the functioning of SOC, protection against APT attacks, etc. Today we will discuss several popular myths and legends.







We are interested in your opinion on each of them, so we are waiting for your comments. Welcome to cat.

Myth 1 - SOC on one string, or the magic of analyzing network traffic

Very often, when discussing with the customer comprehensive protection against external intruders, we hear: “And we have hardware A, it is enriched with vendor expertise and information about new threats, and it completely protects us from external attacks.” And okay, if after these words we were shown a multi-module Anti-APT solution, we would still have questions, but there would have been much less of them. Most often, behind this "universal device" is an ordinary IDS, sometimes with basic functionality for analyzing https traffic. We do not call into question the expertise of vendors in the field of cybersecurity and their knowledge about the activities of hackers, as well as the usefulness of recording and analyzing network traffic (this topic will certainly be repeatedly raised at the Forum), but we nevertheless want to focus on the limitations of the approach, with which SOC focuses only on network events.

• Let's start with the base and some already beaten up. Since 2013, we have been observing hacker attacks conducted without the use of malware as such and, at least, without a module for interacting with the management server. To the attackers come legitimate remote administration tools (Remote Access Tools), which with the correct configuration file behave indistinguishable from users who like to work from home, or the work of remote administrators in companies with a low level of IT maturity. At the level of network events, it is simply impossible to distinguish one session from another, and for a complete analysis of the method and reasons for starting a session, information from end systems is needed.
• If the idea of ​​RAT is disgusting to the attacker or they are not applicable in a specific attack case, the https protocol comes to the rescue as a way of interaction. On a copy of the traffic, protocol decryption is not possible, therefore the sensor has to be content solely with information about the packet headers. This is only useful when the control center is in a specific area and can be calculated by IP. But more often we are talking about large hosting services or public services (we wrote about hacking Wordpress pages earlier ), which does not allow us to identify where the legitimate connection is and where the compromised one.
• For all its usefulness, network connections (and we usually talk about a piece of iron in the perimeter area) record only the relationship between the control center and the top chain of bot clients. Often, current attackers use a chain of proxy C&C servers (the first level of infrastructure capture) to communicate with internal bot clients. At this point, restrictions on the location of the equipment do not fully detect the attack.
• For all the variety of actions of an attacker, he periodically does not need to come from the Internet at all. It is possible to compromise a remote access account, and then work under the legitimate rights of an administrator or user. Increasingly, groups are using the supply chain methodology, starting an attack by hacking a contractor, who often has a static and poorly controlled channel to the infrastructure and all the same privileged accounts. There are more and more vectors every year, and they are farther away from classical remedies.
• In general, SOC is not only about countering hackers. Internal attackers, violation of IS policies or fraud, downloading or compromising client data, and much more, are also part of a comprehensive SOC approach. And it requires much more complex techniques and tools in its work.

Myth 2 - SOC without legs, or Work without the first line

One of our favorite legends. Jokes about SOC, where only 1 person works, so he is a little 1st, a little 2nd and a little 3rd support line, have already flooded the Internet. But a lot of customers, having heard various reports and read articles, start talking about the need for a magic piece of iron / procedure / technology (underline as necessary), which will automate and solve all the problems of the first line. And since often in the customer’s head the 1st line is equivalent to the 24 * 7 mode of operation (all the others, as a rule, work according to the standard schedule), this automatically creates the feeling of a significant reduction in personnel costs and generates conversations in the key “1st line does not needed, let's start building right away with the second. "



The key problem of this legend, in our opinion, is the confusion in terminology. Often, when the speaker talks about the 1st line, he is guided by ITIL practices, where atomic tasks really fall into the hands of operators:

• task reception
• classification
• adding context (asset or information system)
• prioritization or prioritization
• Appointment to the person responsible for the system / examination / queue.

When it comes to such problems, of course, no dedicated first line is needed: these processes, although not easy, are completely automated. What we mean by the first line, we have already written several times - for example here ). Still, the first line is not a substitute for automation, and not even a team working exclusively on a playbook. These employees are inquisitive and searching, although they have only basic skills in analyzing events and investigating incidents. In ITIL terms, such a line would be called 2nd, which immediately removes all questions and discrepancies.



I would not want to ignore questions 24 * 7. About the organization of the shift, the efficiency of operators and analysts at night, psychological blindness when viewing events, too much has been said. The integral conclusions are approximately the same - the first SOC line and a round-the-clock shift become ineffective and unnecessary. For our part, over the years, we have also tried different methods and at the moment, the federal level of SOC allows us to minimize the risks of specialist fatigue during the night shift (a critical incident is simply sent to a different time zone), nevertheless, I would like to note a few points.

• Reducing shift times for the operator is a very good idea. Work on the principle of IT duty for a day or three in information security is rather impossible. However, maintaining focus on incidents is very important ...
• BUT ... the operator of the 1st line does not sit, like the operator from the movie "The Matrix", looking at the stream of raw events in search of anomalies. At least in no SOC known to us have we encountered such an approach. His job is to analyze regular reports and hunts, or work out scenarios for identifying incidents. In this mode of switching attention and types of activity (with the right balance of numbers on the line), the risks of rapid psychological blindness seem to us minimal.

And in conclusion - no matter how far automation has gone, it is customary to leave a specialist who monitors the situation with machines and robots at any critical production site. And if your fork in this case is “can automation help me not to allocate 5-6 rates for the shift shift”, then our answer is unequivocal: it cannot.

Myth 3 - Perfect SOC without a single break, or We work without false positives

The more you build SOC or work with an MSSP / MDR provider, the more you want the ideal. Now, a lot of customers have gone through fire, water and copper pipes of the first independent approaches to the projectile or pilots / contracts with external suppliers and everyone is trying to somehow strive for the ideal. And the ideal in the eyes of the head / person responsible for the external service is usually expressed by the phrase "every alert is a confirmed incident" or "we are not monitoring suspicions - we are recording attacks." And in terms of key performance aspects, it's hard to argue with that statement. But, as always, the devil is in the details.



Most SOCs are aimed at an effective, in-depth analysis of the incident across all available information. And they are increasingly approaching perfection, when they have the opportunity to receive shells logs for her. Let us examine an example of an incident on the facts of the operation of network indicators of virus software (the address of communication with the control center) - to identify them, it’s enough just some information on network flows to the Internet, for example, firewall logs, but they often give a false result. It is enough for the attacker to hide his malware management server on the hosting, and we will automatically encounter a large number of false positives. For effective filtering and analysis of an incident, it is necessary to localize activities on the initiating host (triggered processes, open sockets, etc.). And this leads us to the need to connect events from all hosts on the network.



Total: in order for SOC to come close to the possibility of detecting attacks exclusively, without false positives, we need to ensure maximum monitoring coverage of the infrastructure - ideally, to collect ALL logs from ALL objects.



This leads us to several problems at once.

1. Actual opposition of IT departments to raising the level of audit or installing additional systems for collection (to avoid evil, we will not even touch on the topic of connecting ACS segments and technologists). Compatibility tests, an unpredictable increase in the load on systems and other factors that can affect the overall availability of the infrastructure are the trigger for the next round of the war between IT and information security. And most often they simply leave big white spots on the infrastructure monitoring map from the SOC.
2. Maintaining full coverage. It is not possible to collect all the logs from all servers. For example, in new systems, logs may simply not be included. Often during the process of changing servers, the audit settings on workstations and access restrictions are partially or completely lost. In addition, the settings must be updated as new attack vectors appear. All this creates operational costs for providing full coverage, significantly higher than often the risks from an incomplete review by monitoring, and certainly higher than the costs of a potential false positive response.
3. The third problem leads us to the old DOOM game. Because, among other things, full coverage requires you to enter codes.
   
   
   
   a. IDKFA - full ammunition in the form of endless server capacities for collecting and storing events and, which is much sadder from an economic point of view, - endless licenses for SIEM and other SOC tools.
   
   
   
   b. IDDQD is a huge and immortal SOC team that in each incident will be able to analyze all its obvious and indirect features.

The coincidence of such factors, tasks and the amount of budgets for information security is considered the case of a meeting of the green elephant and therefore is not considered as a typical situation in the life of SOC. So, identifying only confirmed attacks (with all the desire to analyze as deeply as possible with automatic tools) is a little fantastic dream of modern security guards.

Instead of an afterword

We tried to discuss only the most frequent myths of the SOC building industry. Therefore, in complex backwaters of launching processes for monitoring and responding to incidents, we advise you to be as skeptical about incoming information, verify it in different sources and maximize fear of counterfeiting of unconfirmed judgments.



And may the Force be with you;).