The content of this post is solely the responsibility of the author. AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article.
"Why are you here if you cannot decrypt our data?" This is how people sometimes react to the arrival of the external incident response team. In this article, I will try to answer this question, but at the same time, I am going to describe the stages of incident response, list the main mistakes that play into the hands of hackers, and give basic advice on how to respond.
Let's start by defining what a security incident is. Although the concept is straightforward, various companies may interpret it differently. For instance, some companies may consider incidents to include situations such as a power supply failure or a hard drive malfunction, while others may only classify malicious actions as incidents.
In theory, an incident is a moment when some kind of undesirable event occurs. In practice, the definition of an "undesirable event" is determined by each company's own interpretation and perspective.
For one organization, the discovery of a phishing email is what requires investigation. Other companies may not see the point in worrying about such incidents. For instance, they may not be concerned about a phishing email being opened on an employee device in a remote location not connected to the main infrastructure since it poses no immediate threat.
There are also interesting cases here. For example, online traders consider a drop in the speed of interaction with the online exchange by 1% to be a serious incident. In many industries, proper incident response steps and cybersecurity in general, cannot be overestimated. But if we are talking about serious incidents, then most often, these are events related to the penetration of an attacker into the corporate network. This annoys the vast majority of business leaders.
Incident response stages
While the interpretation of certain events as security incidents may vary depending on various factors such as context and threat model, the response steps are often the same. These response steps are primarily based on the old SANS standard, which is widely used by many security professionals.
SANS identifies six stages of incident response:
- Lessons learned
It is important to note that the external response team is not immediately involved in this process.
Preparation involves properly aligning organizational and technical processes. These are universal measures that should be implemented effectively across all areas:
- Inventory networks
- Build subnets correctly
- Use correct security controls and tools
- Hire the right people
All this is not directly related to the external response team and, at the same time, affects its work significantly. The response is based on preparatory steps. For example, it relies heavily on the log retention policy.
Each attack has its own dwell time - the time from an attacker entering the network until their activity is detected. If the attack has an extended dwell time (three-four months) and the logs are kept for seven days, it will be much more difficult for the investigation team to find the "entry point." The required data will no longer be available. If such a situation arises, the response team can take action, but the likelihood of achieving a 100% successful outcome is significantly reduced.
This stage is entirely based on how well the preparation was done in the first stage. If everything is done correctly, there is a good chance that you will discover something in advance that can potentially lead to an unacceptable event.
Even primitive and basic steps can greatly increase the likelihood of early detection of a cyber threat. By building your own Security Operations Center (SOC) or engaging a capable third-party provider and implementing effective monitoring practices, you can greatly improve your chances of detecting potential security incidents. Careful preparation allows you to detect an attack in its early stages before the attacker has done any harm.
Ideally, the response process should be initiated at this stage. Alas, in practice, there are many cases when the sad consequences of an attack are the only thing due to which the incident is detected. Everything goes along the logical chain: preparation is terrible, detection and analysis fail, and an incident occurs. And the investigation, in this case, turns out to be a non-trivial task.
This stage is performed in close cooperation between the external response team and the customer. IT personnel often simply reboot computers before the external incident response team arrives. Yes, this is also a containment method, although not the most elegant.
The problem is that this deprives the response team of a lot of important data. And what is more important, it does not always work. Today hackers rarely use just one technique to achieve persistence. They usually employ Remote Desktop Protocol (RDP) for lateral movement, and stopping them is not always easy. Therefore, joint analytics are vital to understand which connection is legitimate and which is not. When the external response team and their customers work together closely, it becomes simpler to understand the situation and develop effective tactics to contain specific threats.
At this stage, it is generally expected that the incident response team has already provided the customer with an incident analysis, including malware analysis, indicators of compromise, etc. A thorough process of scanning the network is in progress, followed by the removal of all detected anomalies.
At this stage, a consistent and accurate restoration of the customer's IT systems is carried out. It implies not just recovering from backups but also the reactivation and testing of information security tools.
Usually, restoring protections is a fairly simple task. The fact is that attackers, as a rule, act just by bypassing protection mechanisms. They get administrative privileges and, if possible, "turn off" security solutions. Yes, hackers can use malware that interferes with Windows logging or disrupt Critical Event Management, but such cases are relatively rare.
Although not a common occurrence, some attackers may leave bookmarks to enable repeated attacks. It is vital to remain vigilant and check for such bookmarks, even in the case of a seemingly straightforward attack.
It may seem that the incident response team's main task is to restore everything to its previous state, but this is a simplification. The response team is invited for a different purpose. Its tasks are to understand:
- The attack vector used by the hackers.
- The specific entry point used to gain unauthorized access to the IT systems.
- A detailed timeline of how the attack progressed.
- Identification of potential prevention measures that could have been implemented at different stages.
- Recommendations for addressing the root cause of the incident to prevent future attacks.
The answers help give better recommendations. For example:
- If the attack started with phishing, it is advised to set up an email sandbox, adjust spam filters, and train employees.
- If a vulnerability is to blame, changing the update\patch and network monitoring procedures is recommended.
Why is the final stage so important? First, most attacks are not very inventive. Actually, they are formulaic. Therefore, you can draw conclusions from one attack and prevent a dozen similar ones.
Second, the hackers usually come back. Here is a real-life example. The IR team identified an entry point, studied that PC, and found that some files were encrypted a year before the incident. It turned out that the customers were aware but did not pay attention to the incident since the first time, it caused almost no damage. As a result, a second attack occurred through the same entry point. This time, hackers spent a little more of their time and encrypted everything and destroyed the entire domain.
Third, without adequate response procedures, it is impossible to enhance security awareness training and incident detection, which serve as the bedrock of a company's security system.
How to improve security
Basic knowledge is important
The basic things you probably already know about are already cool and very useful. Every year, thousands of companies fall victim to attacks due to the most banal reasons. The most common cases are the exploitation of unpatched vulnerabilities. The second common thing is phishing.
So, a significant number of potential security issues can be mitigated by prioritizing effective patch management, maintaining an accurate inventory of infrastructure, and providing staff with training in digital hygiene.
There are a lot of organizations that have already done all the basic things. However, it does not guarantee the complete absence of incidents. They can be recommended to run penetration tests. However, you need to "grow up" to this kind of thing. It makes no sense to conduct penetration testing when only 20% of the infrastructure is covered with Intrusion Detection and Response (IDR\IDS) solutions.
Follow trends and industry reports
Numerous security reports and news can tell you what tools and attacks hackers use. This way, you can establish relevant security criteria for your company. The reports often provide specific recommendations on how to protect from a particular attack. One of the best sources for such information is MITRE ATT&CK Matrix.
Do not panic, and do not do rash things
A typical mistake is to reboot all the computers involved in the attack. Yes, there are urgent situations when this is crucial, but, if possible, please make copies of infected machines. This will enable you to preserve evidence for any subsequent investigation.
In general, do not act impulsively. Quite often, upon discovering encrypted files, employees immediately disconnect the power supply. This approach is akin to gambling. Nothing can be guaranteed after that. Yes, the encryption stops, and you can probably save several untouched files. On the other hand, such an abrupt stop corrupts the disc and data affected by the encryption process. Even if the security community comes up with a decryptor or you pay a ransom (which is not recommended), restoring data whose encryption has been interrupted may not be possible.
Contacting the experts
Is it possible to cope with an attack on our own? Yes, if you have well-established procedures. Mitigation efforts can be prioritized. It is not very difficult to protect mobile devices, implement multi-factor authentication, or set efficient patch management procedures. From a financial standpoint, relying on backups and minimizing recovery time can be an acceptable strategy. However, when it is essential to stop the attack promptly, determine the exact nature of the incident, understand who is to blame, and chart an effective course of action - there are no alternatives - call the external response team.