Prepare for the inevitable: You are going to be the victim of a cyberattack. That attack could be a major cybersecurity incident using sophisticated hacks, malware or a possible data breach. Regardless of the scope or type of incident and the affected systems, having a planned and tested incident response process is key to preventing further damage and ensuring business continuity.
You may need a full-fledged computer security incident response team (CSIRT) to handle this type of action. More likely, existing IT staff and front-line employees will need to know how to handle an attack to ensure business continuity operations.
What is an Incident Response Plan?
An effective incident response (IR) plan is a combination of people, process and technology that is documented, tested and trained toward in the event of a security breach. The purpose of the incident response plan is to prevent data and monetary loss and to resume normal operations.
In some cases, having an incident response plan is a requirement for acquiring digital insurance or for achieving compliance while working with respective parties. Effective incident response planning should include a comprehensive plan that not only coaches your information security and incident response team members, but the organization as a whole.
Why is it Important?
An incident response process is key to mitigating the fallout of security events. There are short-term effects of an information security event, such as being locked out of systems or data. And there are long-term effects of a security event, like loss of public trust or shareholders, law enforcement involvement, fines, loss of business partners and more.
The incident response plan should be vetted by an outside party, such as an insurer or one of your key technology partners. Those parties can provide you with valuable context specific to your industry vertical and/or technology ecosystem that can help you win the day when facing a potential incident.
Examples of an Incident Response Plan
The National Institute of Standards in Technology (NIST) has readily available resources that can guide you in building an incident response plan. Take the word of experts into account when building an effective incident response.
The NIST offers a few different models for building an incident response plan:
- Central: A central body, such as a CSIRT, handles the incident response
- Distributed: Multiple response teams are responsible for a location or affected systems
- Coordinated: A central team/body conveys response plans to the affected teams
What model will work best for your business? Answering this fundamental question will help structure the rest of the incident response plan along with next steps. Once you choose a model, you can move onto defining incident response phases.
There are 4 incident response phases:
- Detection and analysis
- Containment, eradication and recovery
- Post-event activity
Each step is important to the process, but preparation will win the day. The more prepared you are, the more you can limit the creep of a breach.
Steps of an Incident Response Plan
Templates for incident response plans can be easily located online. Make sure yours covers what action an employee should immediately take.
Before even communicating up that there is an issue, the employee should know how to respond in one of the following ways:
- Power Off: Make sure you segment and depower the machine in question. Don’t forget to unplug the ethernet cord. It’s important to note that some information security professionals would argue that powering off the machine is the opposite of what you should do. The truth is that it really depends on who is responding to the threat. A trained infosec professional should not power off the machine, as they have an actual grounding in threat intelligence and may be able to identify the potential incident via the short-term memory on the machine. But your front-line workers shouldn’t have to shoulder that burden of criticality. The best bet is to get them to take action to mitigate the spread and prevent further damage.
- Don’t Delete: This is the hardest rule to follow because it goes against your instinct. If you delete the file that you believe is malicious, you will delete the trail that allows a forensic investigator to determine the root cause of the incident. This could have massive ramifications with regards to a legal situation like a lawsuit or insurance claim. Segment and isolate the machine and power it down.
The incident response plan should include a structure of who needs to know about a possible security breach. The front-line responder needs to know who to tell first and what to do next while the responding manager takes charge of communicating with the rest of the employees and marketing communicates with customers, shareholders and the public, as needed.
Front-line managers might need to know about a current investigation or they might not. Most phishing attempts will force the issue, spamming the same illegitimate email message across the entire domain, which will force the need to send a company-wide email. Front-line managers should be concerned with their team(s) and their customers in the following ways:
- Manage Teams: Front-line managers should understand the situation well enough to give their team marching orders. For example, should their team members continue working? Should they disconnect from Wi-Fi? Should they be turning off their machines? The front-line manager should have these answers readily available.
- Manage Customers: If the incident was a phishing attempt, the entire address book of the user could have been contacted and contact information may be vulnerable. Front-line managers should have a template email in place to send out in case of security events.
Your marketing folks should have a “break glass in case of emergency” kit ready to go in the event of a cybersecurity incident. It should include the following elements.
- Social Media Posts: Communicate your knowledge of the issue and your intent to investigate and protect.
- Email to Customers: Draft a message that informs your customers and supply chain of the incident.
- Email to Employees: Draft a message to send to employees before the mass communication goes out.
- Email to Shareholders: Draft a message to inform shareholders, if applicable.
- Communications Schedule: Create a schedule of how often your team is going to update and follow up with the customers and supply chain network moving forward.
- Call to Action: Set down the call to action and back away. You don’t need your customer base to do anything other than be aware and be vigilant.
How to Train Your Team: War Gaming
Training your team on security policies is the first step. All employees need to understand how to react in the moment.
Requiring staff to sign off on an employee handbook isn’t enough to prevent future incidents. Employees should understand the types of incidents they could be a target for, such as the all-too-common phishing attempt. You don’t need everyone in your company to be a security analyst, but you should be able to show them what suspicious behavior outside of company protocol looks like and how to deal with it.
Anyone who handles or manages a system that holds personally identifiable information (PII) including data as simple as contact information records may need an extra level of attention when you are training your team around incident handling. These files can often be the end game of the threat actor, whether they intend to ransom them or steal them.
Earlier in this article we defined that preparation is the single-most important element of a response plan. What exactly does that mean? In many cases, being prepared means being experienced. So how do you create cybersecurity breach response experience for your team?
War gaming could be the solution. War gaming is one of the most important steps when it comes to incident response planning. It sounds intense because it is. Take your employees, in particular your first responders, through a breach incident exercise, and don’t stop with entry-level employees. An effective war game exercise also involves the executive suite and multiple departments.
Holding a post-mortem briefing with your incident response team members after the incident has taken place and the fallout has mostly been uncovered is a key component to preventing it from happening again. This type of follow up is important because your employees need to understand how the breach could have been prevented in the first place.
“Looking back to look ahead” is a key element of threat intelligence and risk assessment. If you are able to identify the root cause of the breach via, for instance, the logs on your firewall or security information and event management (SIEM) software, you may be able to automate a response that can prevent the breach the next time it rolls around.
Post-incident you will also need to inform your customers, vendors and technology partners of the incident in order to move forward as a community.
It’s important to stay humble when going through the incident response process. Assume you will be attacked as opposed to thinking you are too strong to be affected. Remaining humble in your planning, training and communications will help to mitigate any unforeseen perception hits to your organization.
Get articles like this delivered right to your inbox with IT Careers Newsletter. Subscribe today and save 10% on your next CompTIA purchase.
Read more from David Landsberger: