You may know little about the SOC, but it will still be intuitively clear that there are only two things that matter most in its work: identifying incidents and responding to them. At the same time, if you do not take the situation when we are dealing with complex internal fraud or signs of the activity of a professional group, the response, as a rule, consists of a number of very simple technical measures (removal of the viral body or software, blocking access or account) and organizational measures (clarification of information from users or verification and enrichment of the analysis results in sources inaccessible to monitoring). However, for a number of reasons, the customer response process has begun to change significantly in recent years, and this required changes on the part of the SOC. Moreover, since we are talking about a response, where “not only everything” is important - and accuracy,both completeness and speed of action - it is highly likely that if your internal or external SOC does not take into account the new requirements for this process, you will not be able to handle the incident normally.
Now there are many of our customers who are more comfortable with receiving a response as a "full cycle" service - in this case, we block the attack on the company's defenses and accompany the response process in the area of responsibility of the IT service. For example, we help with the justification of blocking, which theoretically can lead to problems in business processes, or we advise on work that partially needs to be done on their side - account blocking, host isolation, etc.
But the majority still prefer to engage in technical response on their own, and they require from us timely detection of an incident, analysis and filtering of false positives, as well as providing analytical information with recommendations on priority actions in response to an incident.
Who was previously involved in this process and was responsible for the result on the part of the customer? As a rule, one or two information security specialists who combined response work with other tasks of the department and did not always have deep niche expertise in attack analysis (as you can see from the previous paragraph, this was not required). Nevertheless, it has always been about information security specialists who understand the risks, threats and the context of what is happening.
Recently, responsibility for the completeness and timeliness of response on the customer's side is increasingly distributed between information security and IT services, and here's why.
First, the number of incidents and suspicions of incidents has increased significantly. If earlier the average number of notifications was measured by one or two hundred per month, now it has increased several times. Part of the problem is the growth of entropy in corporate infrastructures due to constant (and not always fixed) changes, which are caused by what is now commonly called the fashionable term "digitalization" or "digital transformation". A side effect is that user actions become more varied, and technical solutions are more likely to classify them as behavioral anomalies, which, in turn, can be mistaken for an attacker by a security officer. These are false positives, let's say, of the first type.
Secondly, the activity of cybercriminals, of course, is also constantly growing (in other words, the number of attacks is growing), this is noted by us, other industry players, and the customers themselves. As a result, the SOC must constantly invent more and more clever attack detection scenarios and make sure to connect them to the customer. This, of course, also leads to an increase in the number of operations, an increase in the non-determinism of the customer's actions and the need for information about the incident to contain an external context (whose workstation is it, is it customary in the company to use remote access tools, and if so, which ones, who they can be used for what, and the like).
Actually, this leads to the fact that in order to speed up the response process, more and more companies are trying to transfer the external SOC to direct interaction not with information security, but with IT departments. And this is quite logical: incidents requiring software removal or account lockout are directly sent to IT, requiring network isolation of the host - to network departments + helpdesk and so on. If the company has its own monitoring center, then it is often obliged to transfer triggers from the SIEM system to IT.
However, any change in the process is the risk of slowing it down, the risk of incomplete information to the parties and, ultimately, a decrease in efficiency. Fortunately, most companies understand this, therefore (and sometimes due to legislative requirements - in particular, on the creation of GosSOPKA centers) there is now a growing demand for checking the actual level of response - completeness, quality and timing of recommendations from IT and information security departments companies.
However, before conducting audits, it is necessary to give people a tool to achieve the result, in other words, the SOC must adapt the results of the analysis of each incident for clear routing in IT. Through trial and error, we have compiled a list of requirements for incident information sent to the customer.
In these results of the analysis of the incident, the employee responsible for the technical response should be clearly identified.What
are the pitfalls: in order to correctly identify such a person in charge, it is necessary to accurately identify the location of the incident - a specific department, the criticality of the host, its business affiliation, the type of incident. This requires a very deep immersion in the customer's infrastructure at the inventory stage (and, very importantly, constant updating of this data).
The same information is needed to determine the criticality of an incident. For example, the bank is ready to react to a virus infection of a car in a branch in Magadan much more slowly and with the help of a local information security specialist. If we are talking about the local AWP of the KBR, the incident requires an immediate response and involvement, including the customer's CISO to coordinate the risk, as well as the specialists of the communication center on the site to immediately isolate the host.
Responding to an attack on a web application in the e-commerce segment, as a rule, requires the involvement of not only security personnel, but also application specialists who can more accurately determine the risks associated with its implementation, and unloading information about orders from the database on the same host, on the contrary, in no case should it involve either applicants (they are one of the potential attackers), or even IT specialists, but in addition to information security, it often requires the participation of the economic security service.
All these scenarios - whom we involve when, at what stage and for what purpose - must be worked out in advance and agreed with the customer. SOC knows better about information security, but the customer knows his business better and what risks are most critical for him, so the scripts are developed together.
This also applies to the description of the threat and its risks, and the level of detail in the description of the response recommendations. Moreover, ideally, the sequence of required actions should be divided into a tree of mandatory and auxiliary events. For example, if the SOC records the launch of the Remote Admin Tool on the end host, but the audit level is not enough to distinguish user activity from a potential launch of a backdoor by an attacker, then the first and mandatory point will be the communication of the specialist with the user to find out whether he initiated this activity. If the answer is yes, this is regular activity or, at most, a violation of the information security policy. If negative, it can be part of a hacker attack and requires completely different response work.
Checking the response results should contain the possibility of technical control of both the fact of implementation of the recommendations (using logs in SIEM or other tools) and the fact that the incident will not recur in the future.
Let's continue the example with running RAT on the host. For example, we went to the first branch - user activity that violated information security policies. In this case, the IT service will be advised to remove the RAT on the host. In addition to the controlled launch of the deletion script or checking for the absence / presence of a utility on the host, inventory tools should link with the old incident when it is re-triggered. This signals not only a repeated violation, but also about a possible poor-quality implementation of the recommendation by the response.
Finally, the context or delta neighborhood of the incident is important. It is very important what exactly happened to this machine / account during the last time interval, whether there were any similar or potentially related incidents that could be collected in the kill chain. This information allows you to quickly determine whether you need to immediately involve the security or Incident Response Team of the provider in the incident.
Each SOC is looking for its own answers to these challenges and can perform these tasks using different tools, the main thing is to control that it does it in principle. Because on minor incidents, delays and hesitations in response can be imperceptible, and on critical incidents, an unregulated process simply will not work. And it is as if there will be no guilty ones.