CS Incident Response
What is an Incident
Anything negative or dangerous for our networks or computer systems might be called an incident. It suggests mischief or an attempt to cause harm to the organization. Not every incident will be handled by an IRT (“Incident Response Team”) because not all incidents have a significant impact, but when they do, the IRT is called in to assist in handling the event in a reliable and professional manner.
The IRT should always work to guarantee the best possible outcome for incidents and be closely matched to the business objectives and goals of the organization. This usually entails minimizing financial losses, preventing attackers from moving laterally, and stopping them before they can accomplish their goals.
IRT - Incident Response Team
A team devoted to handling cyber security incidents is called an IRT. The team may just include experts in cyber security, but if resources from other groups are added as well, they may work much better together. Think about the significant effects the following units can have on your team’s performance in particular scenarios:
- Cyber Security Specialist – We all know these belong on the team.
- Security Operations – They might have insights into developing matters and can support with a birds eye view of the situation.
- IT-Operations
- Network Operations
- Development
- Legal
- HR
PICERL - A Methodology
The PICERL Methodology is formally called NIST-SP 800-61 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) and contains an overview of a methodology which can be applied to incident response.
This methodology should be viewed as a process that allows you to move both forward and backward, rather than as a waterfall model. This is crucial to make sure you handle any situations completely.
The six phases of reaction to an incident:
Preparation
The purpose of this phase is to prepare for handling incident response. An IRT should think about a lot of things to make sure they are ready.
Playbooks and procedures that specify how the organization should react to particular types of incidents should be developed as part of the preparation process. It’s important to decide ahead of time on the Rules of Engagement, including how the team will react. Is it ever appropriate for the team to monitor a threat in the environment in order to get important information about, say, how the threat entered, who the threat is, and what it is they are attempting to accomplish?
The group should also make sure they have access to the logs, data, and information required for responding. The team is doomed to failure if they are unable to access the systems they are responding to or if the systems are unable to provide an accurate description of the situation.
Up-to-date resources and documentation, as well as established secure communication routes, are essential. The group should make sure managers and relevant business units are able to get regular updates on the status of issues that affect them.
The success of the team also depends on the supporting components of the organization and the team itself receiving training. In addition to pursuing qualifications and training, incident responders can work to persuade other members of the team not to fall prey to threats.
Identification
Examining information and occurrences in an effort to identify something that belongs in the incident category. Although the SOC is frequently assigned this responsibility, the IRT is welcome to participate and attempt to enhance the identification using their expertise.
Alerts from security-related instruments like SIEMs (Security Information Event Management System), IDS/IPS (Intrusion Detection/Prevention Systems), and EDR (Endpoint Detection and Response) are frequently the basis for creating incidents. A user calling the team, sending an email to the IRT’s inbox, or opening a ticket in an incident case management system are some other ways that someone can report an incident to the team.
The identification phase’s objective is to find incidents and determine their scope and impact. Among the crucial queries the group should pose to itself are:
- What is the criticality and sensitivity of the platform breached?
- Is the platform used elsewhere, meaning there is a potential for further compromise if nothing is done in time?
- How many users and systems are involved?
- What kinds of credentials has the attackers got, and where else can they be re-used?
The team proceeds to the next level of containment if an incident requires attention.
Containment
The goal of containment should be to halt the assailants in their tracks and limit more harm. By taking this action, you should be able to prevent further harm to the company and ensure that the attackers are unable to accomplish their goals.
As soon as feasible, the IRT should decide whether imaging and a backup are necessary. Imaging and backup are helpful for storing evidence for later. This procedure ought to aim to safeguard:
- A copy of the hard-drives involved for file forensics
- A copy of the memory of the involved systems for memory forensics
Depending greatly on the specific occurrence, the IRT has a variety of options for stopping the attackers:
- Blocking the attackers in the Firewall
- Disconnecting network connectivity to the compromised systems
- Turning systems offline
- Changing passwords
- Asking ISP (“Internet Service Provider”) or other partners for help in stopping the attackers
In order for the IRT to proceed onto the eradication phase, actions taken during the containment phase aim to fast bring an end to the attacker.
Eradication
The IRT can proceed into the eradication phase, also known as the remediation phase, if containment has been carried out correctly. Eliminating the artifacts of the adversary is the aim of this phase.
There are simple ways to guarantee eradication, like this:
- Restoring from a known good backup
- Rebuilding the service
It’s important to remember that confinement may need reapplying changes and settings that were made, should they be undone by restoring or rebuilding. Occasionally, though, IRT needs to manually attempt to eliminate the remnants of an attacker.
Recovery
The IRT’s target condition is returning to regular operations. Acceptance testing from the business units may be required for this. Ideally, we incorporate incident information into monitoring solutions. We are interested in learning whether the attackers reappear out of the blue, perhaps due to relics that were overlooked during eradication.
Lessons Learned
The last stage is applying the lessons we learned from the event. There will undoubtedly be a lot to learn from the event, such as:
- Did the IRT have the necessary knowledge, tools and accesses to perform their work with high efficiency?
- Was there any logs missing which could have made the IRT efforts easier and faster?
- Are there any processes that could be improved to prevent similar incidents taking place in the future?
After the lessons learned phase, a report that provides an executive summary and review of everything that happened during the incident is usually concluded.
