Incident Response Plan: The Tool You Hope You Never Need

Written by Simone Erskine | May 15, 2019 5:55:00 PM

This is an original article written by Isaac Wright, a Cybersecurity Analyst and Trainer at Alpine Security.

It’s no question that in cybersecurity, defense is the best defense. In the constantly changing threat landscape, the tie often goes to the attacker, and businesses are forced to act like turtles putting up shells of security to ward off threats.  That is not always a bad thing; using a well-constructed defense- in- depth plan can greatly limit the likelihood of a successful attack.  I would like to believe we can get to a 99.99% level of security.  Even if that were true, that extra .01% keeps me up at night. What do we do if the controls fail? How do we respond then? What do we do the other 1% of the time? Once we find out that our emails have been hacked, or our money has been stolen is not the time to ask, “what now?” Even worse, what do you do when you suspect that an insider has embezzled funds and the evidence is located on their computer? Though we invest in and rely on our security controls, it is unfortunately not always enough.  We must have a plan for the .01%.

Those Who Fail to Plan, Plan to Fail.

In the world of cybersecurity, one of the biggest reasons companies find themselves becoming victims is because they fail to plan for their IT growth, especially for security. Often small to medium business put little to no thought into cybersecurity until after they have become a victim. As a business grows the need to protect that growth comes with a lot of hard decisions. Many times, a balance must be struck between expanding revenue, generating sources like equipment, and personnel and infrastructures like email servers and IT staff. Many businesses quickly find themselves outgrowing their IT infrastructure before they even realize it has happened. They often don’t realize they have a problem until a compromise or critical failure takes place.

What’s At Stake?

It is imperative to consider what is at stake.  The answer is possibly more than you think. Recently a client asked me to give them some case studies to show what the costs of not being properly prepared could be. In one case a small business had $1.5M stolen from their bank accounts over a period of three days using a fairly straightforward cyberattack. Within a few weeks, they were forced to lay off employees and file bankruptcy. Other less obvious risks arise that business may not know how to deal with until it is too late. What happens if an employee uses a personal device on the company network for illegal activity? Is the company protected? What if an employee embezzles funds from a partner corporation and millions in contracts are tied up in litigation? What do you do with that employee’s computers and devices? These are the types of situations that we see on a daily basis and represent that .01 % of cases in which one wrong move could mean the difference between liquidation and salvation. Obviously, we cannot plan for everything, but having a well-laid incident response plan and a trained team in place to execute can prevent a lot of grief in the long run.

What is an Incident Response Plan (IRP)?

The goal of an incident response plan is to have an answer prepared for those “what if” situations. The type of situation can vary from a power outage to a data breach, and the depth of the incident response planning should be based on the likelihood of an event taking place and the severity and level of impact if it does. The incident response plan will outline important information about communications during critical events; it may go as far as to outline authority and decision making matrices to ensure that risk is accepted at the appropriate level.

Key Areas to Cover

Incident response planning can be a daunting task at first glance. There is no end to the number of circumstances that can arise. The real key is to outline how to respond to incidents in a methodical manner, as well as identify who is responsible for acting during a crisis (see Incident Response Team below). The process of incident response is generally broken into 6 areas. Specific checklists and policies can be created for known risks, but these same steps can be used when an event you are unprepared for arises.

1.       Preparation – Creating policies and establishing standards for what constitutes an incident. Practicing and conducting drills or exercises to respond to incidents.

2.       Identification/ Detection – Tactics techniques and procedures to detect an incident in progress.

3.       Containment – Taking steps to prevent the spread or continuation of a breach or incident. This could be as simple as segregating a computer from a network or as complex as removing access to major systems.

4.       Eradication – Remove any corrupt or infected files, restore backups, ensure no other systems have been impacted. Restore or replace affected systems.

5.       Recovery – Return all systems to full operation.

6.       Review Lessons Learned – Identifying what went right or wrong from the incident for future use.

These steps may seem simple at first glance but can quickly become complicated. For example, If an IT staff member determines that a website has been infiltrated does that member then have the authority to take the web server offline while further investigation is conducted? How much revenue will be lost during the outage? Will other system be impacted? What are the risks of operating with a potentially compromised system? Outlining how much risk is acceptable and what level of management is responsible for accepting that risk is critical prior to an incident taking place.

Also of note, the preservation of evidence should be kept at the forefront during all of these stages, especially if there are legal or financial implications for the company or its employees. In some cases, evidence can be destroyed or made useless by something as simple as turning off a computer. Therefore training staff on what to do in these situations is so important. If there are any legal or financial implications, it may be worth bringing in a certified digital forensics team to assist with the protection of evidence. If that is a function that doesn’t exist in-house, bringing in an outside cyber forensics team should be part of the IRP.

Incident Response Team (IRT)

An important aspect of incident response planning is the establishment and training of an IRT. The IRT will be the boots on the ground that will lead the efforts during a cyber incident. While they may not do all the work themselves, these will be the key players who will oversee and coordinate the response to cyber incidents. It may be unrealistic to have all staff trained to handle an incident, so having a team of staff identified and trained ahead of time is key to proper indecent handling. The team should be small enough to be agile, as well as contain multidiscipline employees to allow for perspective and cross-functionality. Ideally, the team will be led by the CISO and contain members of the IT staff. It may also be wise to consider having personnel from other business units, especially legal, HR, and public relations.

Practice, Practice, Practice.

Having an incident response plan sounds good on paper (pun intended), but it is important to test the plan on a regular basis. This will ensure that the team is still current on their responsibilities, able to identify holes in the plan, and give you an opportunity to update for any changes since the last time the IRT was practiced or used. I recommend testing IRP at least semiannually and revisiting it anytime major changes are made to the business or its infrastructures.

 

View the full article.

Interested in learning more? See our upcoming events below and be sure to join us!

Risk Management: The Importance of Cybersecurity for Defense Manufacturing

June 19  |  Kane County

July 19  |  Quad Cities

July 29  |  DuPage County

July 30  |  Peoria

Questions about this event? Please contact Emily Lee at elee@imec.org or 309-677-4633.

View our other upcoming events.