Understanding Incident Response with NIST framework : Part 1

This blog is all about what is incident response and how we deal with incidents occurs in corporate.

Before comming to what is incident response we have to clear difference in events and incidents.

Incident and Event

• Event : This is an observed occurrence within a system or network. It ranges from a user connecting to a file server, a user sending emails, or anti-malware software blocking an infection.
• Incident : This is a violation of security policies or practices by an adversary to negatively affect the organization through actions such as exfiltrating data, encrypting through ransomware, or causing a denial of services.

What is incident response ?

An incident handling and response process is a structured way to deal with security incidents, like cyberattacks, data breaches.

Normally different framework have different way to handle incident response but at the end all are same that is incident response. Here we are going to follow NIST framework that is commonly used in industrial standards. For better understanding I will subdivide the steps where explanation is needed.

Incidents Response

• Preparation: This is where you get ready for the unexpected. You’ll identify your critical systems and data, develop an incident response plan (IRP), and create a team to handle incidents: Computer Security Incident Response Team (CSIRT) or an Incident Response Team (IRT) with clear roles and responsibilities. Conduct regular response team training and awareness programs for all employees. Ensure the availability of the necessary tools, software and hardware required for incident detection, analysis and response.
• Detection and Analysis: This is where you figure out if something is wrong. You’ll use security tools and monitoring to identify incidents, and then analyze them to understand the scope and impact.
• Containment, Eradication, and Recovery: This is where you stop the incident, get rid of the threat, and get things back to normal. This might involve isolating infected systems, removing malware, and restoring data from backups.
• Post-Incident Activity: This is where you learn from the experience. You’ll do a post-incident review to identify what went wrong and how to improve your response for next time.

In the 3rd step we combine 3 process for better understanding let’s see each of them in broad manner:

• Containment: Damage limitation is paramount, therefore, isolating affected systems and preserving forensic evidence is required.
• Eradication: Adversarial artifacts and techniques will be removed, restoring affected systems.
• Recovery & Lessons Learned: Business operations are to resume fully after removing all threats and restoring systems to full function. Additionally, the organization considers the experience, updates its response capabilities, and conducts updated training based on the incident.

I think you are clear with all steps. Let’s move to document. How we can document all processes and artifacts.

Preparing The Documentation

Incident documentation would be a lifesaver for an organization. The information gathered could be used as evidence in a criminal cyber attack or instrumental in developing mitigation plans, and lessons learned assessments. This means that incident responders need to develop note-taking and detail-oriented skills.

Policies

Defining principles and guidelines for security processes is vital while conducting your preparation. This ensures that techniques are well-known towards handling an incident. The policies need to be visible to employees, users and other stakeholders, for example, through warning banners, which would inform on the prohibition of unauthorized activities and limit the presumption of privacy within the organization.

Additionally, the policies should outline the organization’s authority towards monitoring the network and all the systems under its roof. Policies would need to be reviewed by a legal team and aligned to local privacy laws and regulations.

Communication Plan & Chain of Custody

Accompanying the policies would be a communication plan outlining who within the CSIRT team should be the point of contact and what procedures should be followed. For example, the CSIRT may have operations members who are always on call to receive reports on suspected incidents. These reports should trigger a chain of actions, including when to notify law enforcement, media personnel, or third parties. Additionally, the team would keep track of the flow of information and manage evidence forms and documents, such as the chain of custody documents. These documents are meant to track the flow of information, evidence handling and reporting when addressing any incident. A template of such a document can be downloaded from this task above.

I think we are now clear with documentation and incident response in next blog I will cover how we can start with incident response with practical scenario. Stay tune! If you like the blog please follow and press clap 👏 and motivate me.