Cyber Security Incident Response

What is an Incident

An Incident can be classified as something adverse, a threat, to our computer systems or networks. It implies harm or someone attempting to harm the organization. Not all Incidents will be handled by an IRT ("Incident Response Team") as they do not necessarily have an impact, but those which do the IRT is summoned to help deal with the incident in a predictable and high quality manner.

The IRT should be closely aligned to the organizations business objectives and goals and always strive to ensure the best outcome of incidents. Typically this involves reducing monetary losses, prevent attackers from doing lateral movement and stopping them before they can reach their objectives.

IRT - Incident Response Team

An IRT is a dedicated team to tackle Cyber Security Incidents. The team may consist of Cyber Security specialists only, but may synergize greatly if resources from other grouping are also included. Consider how having the following units can greatly impact how your team can perform in certain situations:

• 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.

Do not consider this methodology as a waterfall model, but instead as a process where you can go forwards and backwards. This is important to ensure you fully deal with incidents that happen.

The 6 stages of Incident Response:

Preparation

This phase is for getting ready to deal with incident response. There are many things an IRT should consider to make sure they are prepared.

Preparation should include development of playbooks and procedures which dictates how the organization should respond to certain kinds of incidents. Rules of Engagement should also be determined in advance: how should the team respond? Should the team actively try to contain and clear threats, or is it sometimes acceptable to monitor a threat in the environment to learn valuable intelligence on for example how they broke in, who they are and what they are after?

The team should also ensure they have the necessary logs, information and access needed to conduct responses. If the team cannot access the systems they are responding on, or if the systems can not accurately describe the incident, the team is set up for failure.

Tools and documentation should be up to date and safe communication channels already negotiated. The team should ensure the necessary business units and managers can receive continuous updates on the development of incidents which impact them.

Training for both the team and supporting parts of the organization is also essential for the teams success. Incident Responders can seek training and certifications and the team can try influence the rest of the organization to not become victims of threats.

Identification

Looking through data and events, trying to point our finger at something which should be classified as an incident. This task is often sourced to the SOC, but the IRT can partake in this activity and with their knowledge try improve the identification.

Incidents are often created based on alerts from security related tools such as EDR ("Endpoint Detection and Response"), IDS/IPS ("Intrusion Detection/Prevention Systems") or SIEM's ("Security Information Event Management System"). Incidents can also occur by someone telling the team of a problem, for example a user calling the team, an email to the IRT's email inbox or a ticket in a incident case management system.

The goal of the identification phase is to discover incidents and conclude their impact and reach. Important questions the team should ask themselves include:

• 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?

If an incident needs to be responded to, the team moves into the next phase containment.

Containment

Containment should try stop the attackers in their tracks and prevent further damages. This step should ensure the organization does not incur any more damages and ensure the attackers can not reach their objectives.

The IRT should as soon as possible consider if a backup and imaging should be done. Backup and imaging is useful to preserve evidence for later. This process should try to secure:

• A copy of the hard-drives involved for file forensics
• A copy of the memory of the involved systems for memory forensics

There are many actions the IRT can do to stop the attackers, which very much depends on the incident in question:

• 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

Actions performed in the containment phase tries to quickly terminate the attacker so the IRT can move into the eradication phase.

Eradication

If containment has been properly performed, the IRT can move into the eradication phase, sometimes called the remediation phase. In this phase the goal is to remove the attackers artifacts.

There are quick options to ensure eradication, for example:

• Restoring from a known good backup
• Rebuilding the service

If changes and configurations have been implemented as part of containment, keep in mind that restoring or rebuilding may undo these changes and they would have to be reapplied. Sometimes, however, IRT must manually try to remove the artifacts left behind from an attacker.

Recovery

Restoring to normal operations is the target state for the IRT. This might involve acceptance testing from the business units. Ideally we add monitoring solutions with information about the incident. We want to discover if the attackers suddenly return, for example because of artifacts we failed to remove during eradication.

Lessons Learned

The final phase involves us taking lessons from the incident. There is bound to be many lessons from the incident, for example:

• 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?

The lessons learned phase typically concludes a report that details an executive summary and overview over all which took place during the incident.