Home > Articles > Responding to a Breach

Responding to a Breach

Chapter Description

In this sample chapter from Investigating the Cyber Breach: The Digital Forensics Guide for the Network Engineer, you will explore the basic concepts for proper incident response procedure to understand why organizations commonly fail at the process when responding to a breach. The authors also share techniques used by organizations that have a successful incident response plan and provide an overview of industry-proven components required to build an incident response process within your organization.

Incident Response Plan

The best way to deal with data breaches is to ensure they do not happen. The best armor is staying out of gunshot. The best soccer (football) strategy is to score more goals than the other team. Sure, that all sounds great, but the real world doesn’t work that way. On today’s networks, you will likely have to respond to some sort of cyber incident. This means it is prudent to have a plan in place to deal with those situations. Having a cyber incident response plan is very much like having a fire extinguisher in your house. You may never need it, but if you do, you will be glad it’s there.

Before we continue, let’s look at the types of situations you might need to respond to. For a foundation behind developing a response plan, we loosely follow the guidelines defined in NIST Publication 800-61 Revision 2, which you can find at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf. According to the document, a cyber incident is composed of one or more major cyber events. Cyber events can include but are not limited to the following:

  • Stolen laptops or other sensitive computer equipment that contains data

  • Attackers compromising internal networks and using those systems to fuel a botnet

  • Ransomware outbreaks that make systems unusable

  • Users exposing sensitive information in a public manner intentionally or unintentionally

As you can imagine, there can be hundreds of different use cases. The important point to remember is that an event is an observable artifact that could introduce risk into an organization. It is also important to know that responding to an incident may be required by law or regulation and have specific required tasks, such as what information is released to the public about the incident. During initial incident response cases, the first few minutes can determine the difference between a conviction on a sensitive legal matter to not accomplishing anything. The preparedness plan should include a process around evidence preservation. It is imperative that you treat all cases as if they will lead to legal action even if it is likely not to happen. You may not entirely realize the full impact of what you are investigating until much later. This is why we cover proper data preservation and continually remind you to follow those steps every time you investigate evidence. Be prepared to hear this advice over and over again as you read this book.

A general incident response preparedness plan should include a section on how to handle and preserve evidence. We recommend the following guidelines:

  1. Do not access, log in, or change compromised systems.

  2. Do not turn off compromised systems.

  3. Isolate compromised systems from the network. Unplug wired connections. If a system is wireless, enclose it in a Faraday cage or other enclosure.

  4. Collect and clone all data in a forensically sound manner.

  5. Document everything and take photographs if possible.

Before you begin creating a response plan, it is critical to understand the environment. At this stage, mature organizations should have most of the documentation available for review. The reality for most organizations is that a review process is required to accurately represent and understand the current environment. This is the stage when you are going to spending time interviewing staff with the goal of understanding details around their jobs, what they support, and the risks associated with the data. At a minimum, we recommend you start with the following:

  1. Review all network, application, and workflow documents that are available.

  2. Identify and map critical data and assets to network, application, and workflow documents.

  3. Request any recent network assessment and security audits.

  4. Interview members of each department to gain an understanding of the environment.

  5. Review security operations center (SOC), help desk, and general IT support departments.

In later chapters, we also discuss specific network configurations you should ensure are enabled and configured correctly. This includes appropriate logging and retention management configuration of devices. Part of your incident response plan should be to make sure the following security policies are configured on your network devices:

  1. Logging in to a central syslog server is enabled.

  2. Appropriate log retention is configured.

  3. Configuration of logs from the IoT, PCs and workstations, security devices, and network devices is enabled.

  4. Correlation of logs to threat intelligence feeds is occurring through a SIEM or similar centralized security type of product.

5. Assembling Your Incident Response Team | Next Section Previous Section

There are currently no related articles. Please check back later.