Cyber Security - Incident Response Part 3.3: Recovery | EN
Hi everyone, after a long break, we continue with our Incident Response series’s second to last article. At this stage, we will renew/repair the infected systems we isolated and destroy and make our systems function again.
In the recovery step, an IR team must think about these three items three times. These repetitive thought notes should include the following:
Question 1: Were we hasty?
After identifying and isolating all vulnerable systems sequentially, we need to provide an initial review of whether we have completely eliminated the threat or infection. If there is any doubt, we should go back to the Analysis step and re-run the following steps.
In most organizations, the importance of speed in getting rid of a threat or infection is confused with IR speed. The rate of completion (except 4) of all phases of IR 1–3 is essential for an institution if it is progressed correctly. However, sometimes when action is taken to eliminate the risk, the 1st and 2nd steps are skipped quickly, and the sub-headings in the 3rd step are addressed rapidly.
As a result of this process;
- The extent and impact of the incident cannot be measured due to insufficient analysis.
- Since there is insufficient analysis data, infected systems cannot be detected, so full containment cannot be done.
- Since the containment needs to be included, the analysis step is not returned during the containment process, and eradication is done quickly.
- Rapid eradication is always a significant risk; It causes deficiencies in bringing together the related parts of case analysis and case investigation. For this reason, we cannot see the parts of the whole, and we analyze the event partially.
Question 2: Are our reinstallation and backup inventories clean?
We should check whether our image files in virtualization environments are clean. In the same way, we should check the latest status of our backups and check if there is a possible change.
In a possible cyber breach, the attacker will try to contaminate systems and datasets for persistence. This will be achieved by adding commands that will provide persistence to the reinstallation and backup inventory or by modifying malicious images. For this reason, the control of the images used in the virtualization environment with the image samples kept before the event should be provided. A secure image should be created quickly by using an image from scratch and applying the necessary CIS tightening and agents. In backup environments, the backup systems included in the network should be specially checked, and forensic examination should be provided if required.
Question 3: Have the Credentials and connections of Users, Service Accounts, and APIs been checked?
Password and token renewal of service accounts, API integrations, and users interacting with the environment must be ensured in the environments included in the containment.
In a possible cyber security breach, attackers collect user-pass information from machines, systems, applications and eavesdropping on the network. Therefore, AD and App users, service users, and API connections interacting during the event should be checked. Abnormal inputs and connections should be investigated. Correlations for post-event follow-up should be developed and followed up by the SOC team. This account, service, and APIs should be followed separately by distinguishing their ties with the internal and external environment. Before the incident, attempts made to these systems should be examined. Those with suspicious reputations should be blocked and reported by finding external IP contacts and following up during and after the incident.
And it should not be forgotten that after a cyber breach, nothing can be the same as before. Therefore, even if systems are fully repaired and remain functional, there will always be danger and fear. This is why we should never stop watching and being cautious.
And so we come to the end of this part. Thank you so much for reading and your excellent feedback. See you…
