Awareness is growing that all companies, including both enterprises and small- to mid-size organizations, need a cybersecurity incident response plan. No organization, regardless of size, is exempt from cybersecurity threats, and having an established plan of action that immediately executes following a security breach is crucial to limit incident costs and damages to the company’s reputation.
Of course, there are hundreds of possible considerations – not to mention moving parts – that must all fit together seamlessly and execute flawlessly for successful incident response. Some companies, particularly those that haven’t yet experienced a major security incident, don’t know where to begin, let alone what to prioritize. ITeck’s Chris Duncan joined 33 cybersecurity experts in recommending how to approach building your company’s Cybersecurity Incident Response Plan (CIRP). Chris’s recommendations are below. Read the original article on Digital Guardian here.When considering your CIRP, breaking sections down into smaller elements may reduce the overwhelming nature of developing a comprehensive strategy.
- From the start, view the CIRP as a part of a larger IT master plan and how it interacts with the other components of that plan.
- Next, look at the CIRP from both reactive and proactive perspectives. Events that hold the potential of data loss should be treated the same as events that have caused data loss.
- From there, break down your actions into the key parts of incident response:
- Plan for both specific scenarios as well as general responses based on resources impacted and severity of incident.
- After the incident itself has been resolved, what a company does next from legal obligations to public relations, is just as crucial.
Cybersecurity Incident Response Plans (CIRP), like computers themselves, are not as simple as they seem on the surface and should be modular…
In the larger scheme of things, your CIRP should be a component of, and dovetail with, your grand IT master plan containing your policies and standards (rules of doing things), procedures (how to do things), the CIRP (what to do when things go wrong), and disaster recovery or business continuity (how to recover when things really go wrong). The CIRP itself is also broken down in to various components. These of course need to be highly customized to the specific needs, scenarios, and regulations of each individual organization. The goal of this method is to create a decision tree that no matter who “grabs the book”, they will have a tool to help them make a decision and take action quickly.
In incident response, time is critical; hesitation is damaging.
The first compartmentalization of a broad CIRP is between proactive and reactive. Most people view incident response as purely reactive, but it should be treated in a proactive manner as well. A user getting a new computer or a new phone is an incident. When they do so, the device being replaced becomes a potential conduit for data loss. Phones have company email, contacts and sometimes even password lists. Quite often, especially around the holiday times, the IT department is not even aware that someone has replaced their phone without taking necessary precautions. At a minimum, phones should be factory wiped before handing them down or trading them in. With new computer equipment, the former system’s hard drive needs to be securely wiped before being put back into inventory or disposed of. In general, try to think of any method or medium used to transmit or store data and determine what events put this data at risk. Those are your potential incidents and need proactive responses to prevent loss.
Reactive responses are innately more urgent. The common practice for incident response breaks down into the following steps: Identify, Contain, Address, Recover, and Postmortem. All of these steps need to be swift but accurate. A misidentification or misdirection in action could cost time and data. Identification of an incident can come in many forms. Hopefully it’s from a deterrent employed detecting the incident as it’s happening so immediate action may be taken. All too often it’s after the fact when the detritus of a breach is discovered (where did that user account come from?) or when the ramifications are felt from data being publicly released (WikiLeaks) or used to compromise people (identity theft) or compromise resources (breaking into other systems).
Identifying is broken down into determining root cause and determining damage. It is critical to determine the actual root cause. You may be responding to “no one can access company files” when the actual incident you need to respond to is “one of our systems got ransomware.” The incident may seem to be “We’re under a denial of service attack,” when the real issue might be that attack is a smoke screen for the extraction of data (also known as a “sneeze attack”). Recognizing the difference is key to reacting quickly and correctly.
Once the incident is identified, stop the bleeding. Containment can be broken down into two facets, active and passive, depending on the incident identified. If it’s an active incident happening right now, e.g., your files are in the process of being encrypted, data is being downloaded, or there is a denial of service attack, you might need to take dramatic action. This may be unplugging a system from the network or shutting down the company access to the internet. But do what it takes to stop loss of data.
By passive, we mean the damage has already been done. You’ve discovered someone has broken into your network, data was leaked, or a laptop was stolen. The response is still just as urgent, but you can be more precise in your tools and methods such as changing everyone’s password rather than cutting off the internet and stopping business.
Addressing the problem involves fixing the root cause. Someone may have stolen a password and broken in. You changed all passwords to mitigate the damage, but you still need to remedy the actual cause. Was there a key logger on someone’s computer? We’ll need to scan, find out and fix it in addition to the password changes. When addressing an incident, thoroughness will reap long-term rewards; the cause may not be the only cause. In our example, the key logger gave away the password that allowed the breach, but it may have been a free game downloaded that allowed – and will allow again – the key logger to be installed.
Recovery is the most dependent upon being prepared before any incident has occurred, and arguably the one that should have the most resources and focus of a company because it’s not only essential to an incident response but to overall business continuity in times of disaster. Recovery may be divided into two phases: immediate/temporary and permanent. The goal in recovering from an incident, as it is during a disaster, is to first get your organization working again, temporarily, and second to get back to a state of normalcy, permanently. If equipment or services are down, this may mean running off of backup resources until the primary resources are restored. If data was damaged, it could mean restoring from backups but then rekeying information until you are up to date.
During the recovery phase, keep in mind who or what is affected. Internal users? Outside customers? The company brand or intellectual property? With data breaches and compromised security, recovery is not limited to just the restoring of data or repairing equipment. Depending on the type of data and your industry, you may be required to disclose to governmental authorities and customers who might have been affected, that a breach has occurred, and possibly provide reparations such as free credit monitoring. Any medical information covered by HIPAA, any personally identifiable information, information that could be used for identity theft, or account information such as login names and passwords are all examples in which persons should be identified. This in turn impacts the company’s brand and reputation.
Disclosure is not necessarily always immediately after discovery. There are several cases of high profile data breaches in which the disclosure was years after the occurrence. Had LinkedIn announced their data hack in 2012 when it occurred, it would have been one of the largest breaches at the time. By waiting until 2016, the loss was rather small in comparison to Home Depot and Target and subsequently damage to the brand was minimalized. Between 2012 and 2016, the incident was under internal review and not considered closed yet, which would have triggered the requirement for disclosure. How and when you should notify depends upon the laws and regulations covering your industry, officers of your company, the marketing department or a damage control PR firm, and your lawyers.
The postmortem involves lessons learned, and like the rest of our steps, is done in two parts: how did we handle the situation; can we do better? And how do we prevent it from happening again? Postmortems are essential. They improve the process and prevent recurrence. Unless gross negligence was at the heart of the issue, they should not be used for finger pointing or blame as people trying to protect themselves may prevent the real causes from coming to the surface, leaving your firm exposed yet again.
By considering how to break down your cybersecurity incident response plan into various smaller components, you will be able to easily compose a comprehensive strategy to cover a wide range of incidents. And always, ALWAYS have good backups.