Incident Response: What SOC owes you

You can know little about SOC, but it will still be intuitively clear that only two things are important in his work: identifying incidents and responding to them. Moreover, if we do not take situations when we are dealing with complex internal fraud or signs of the activities of a professional group, the response usually consists of a number of very simple technical measures (removing the virus body or software, blocking access or an account) and organizational measures (clarification of information from users or verification and enrichment of the results of the analysis in sources inaccessible to monitoring). However, for several reasons, in recent years, the response process on the customer side has begun to be substantially modified, and this has also required changes from the SOC. Moreover, since it is a matter of response, where “not only everything” is significant – accuracy, completeness, and speed of action – we can say with high probability that if your internal or external SOC does not take into account the new requirements for this process, you You can work out the incident normally.

Now among our customers there are many of those who are more convenient to receive 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 locks, which theoretically can cause problems in business processes, or advise on work that is partially necessary to carry out on their side, such as blocking accounts, isolating the host, etc.

But the majority still prefers to deal with the technical response on their own, and they require us to detect the incident in a timely manner, analyze and filter out false positives, and provide an analytical report with recommendations on the priority actions in response to the 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 analyzing attacks (as can be seen from the previous paragraph, this was not required). Nevertheless, it was always about information security specialists who understood the risks, threats and the context of what was happening.

Recently, the responsibility for the completeness and timeliness of the response on the customer side is increasingly distributed between the IS and IT services, and that’s why.

First, there have been significantly more incidents and suspicions of incidents. If before the average number of alerts was measured by one or two hundred a month, now it has increased several times. Part of the problem is the increase in entropy in corporate infrastructures due to the constant (and not always fixed) changes that are caused by what is now commonly called the digital term “digitalization”. A side effect is that user actions acquire wider variability, and technical solutions more often classify them as behavioral anomalies, which, in turn, can be mistaken for an attacker’s activity. These are false positives, let’s say, of the first type.

Secondly, the activity of attackers, of course, is also constantly growing (in other words, there are more attacks), this is noted by us, other industry players, and customers themselves. As a result, SOC must constantly invent more and more tricky scripts for detecting attacks and without fail 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 customer actions and the need for incident information to contain an external context (whose workstation is it, is it customary to use remote access means in the company, and if so, which, who they can be used and 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 IS, but with IT departments. And this is very logical: incidents that require removal of software or account lockout are routed directly to IT, which require network isolation of the host — to network units + helpdesk, and so on. If the company has its own monitoring center, then it is often obligated to transfer to IT IT operations from the SIEM system.

However, any change in the process is the risk of its slowdown, the risk of incomplete informing the parties and, ultimately, a decrease in efficiency. Fortunately, most companies understand this, therefore (and sometimes due to legal requirements, in particular, the creation of GosSOPKA centers), there is a growing demand for verifying the actual level of response – the completeness, quality and timing of the implementation of recommendations by IT and information security departments company.

However, before conducting checks, 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. By trial and error, we have compiled a list of requirements for incident information sent to the customer.

These incident analysis results should clearly identify the person responsible for the technical response.

What are the pitfalls here: in order to correctly identify such a person in charge, it is necessary to accurately identify the place of occurrence of the incident – a specific department, the criticality of the host, its business affiliation, 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 the incident. For example, a bank is ready to respond to a virus infection in a machine 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 AWS of the CBD, the incident requires an immediate response and involvement, including the CISO of the customer to coordinate the risk, as well as the specialists of the communication center on the site for immediate isolation of 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 professionals, but also applicants who can more accurately determine the risks associated with its implementation, and downloading information about orders 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 engage when, at what stage and for what – should 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, therefore scripts are developed jointly.

The incident card should be adapted for specialists with a background in IT and without knowledge in information security

This also applies to the description of the threat, and its risks, and the level of detail of the description of response recommendations. Moreover, in an ideal embodiment, the sequence of necessary actions should be divided into a tree of mandatory and auxiliary events. For example, if the SOC recorded the launch of the Remote Admin Tool on the final host, but the audit level is not enough to distinguish the user’s activity from the potential backdoor launch by an attacker, then the first and mandatory point will be the specialist’s communication with the user to find out if he initiated this activity. If the answer is yes, this is a regular activity or, as a maximum, a violation of IS policy. If negative, it can be part of a hacker attack and requires completely different response work.

Verification of response results should include the possibility of technical control both of the fact of the implementation of recommendations (using logs in SIEM or other tools), and the fact that the incident will not be repeated in the future

Let’s continue with the example of running RAT on the host. For example, we went along the first branch – user activity that violated information security policies. In this case, the IT service will be given a recommendation to remove the RAT on the host. In addition to the controlled launch of the uninstall script or to verify the absence / presence of the utility on the host, inventory tools should also be used to link with the old incident upon repeated operation. This signals not only a repeated violation, but also a possible poor-quality implementation of the recommendation by the response.

Finally, the context or delta neighborhood of the incident is of great importance. It is very important what exactly happened to this machine / account in the last time interval, if there were any similar or potentially related incidents that could gather in the kill chain. This information allows you to quickly determine if you need to immediately involve the security or Incident Response Team provider in the incident.

Each SOC is looking for its answers to these challenges and can perform these tasks using different tools, the main thing is to control that it basically does it. Because on small incidents, delays and stutters in the response can be imperceptible, and on critical incidents, an unresolved process simply will not work. And the guilty as if “will not be.”

Similar Posts

Leave a Reply