“A strong incident response plan is a key component of any organization’s cyber defense,” says Lucie Hayward, Managing Consultant with Kroll’s Cyber Investigations division. Yet the term “incident response,” in and of itself, is a bit of a misnomer. “Incident response” implies after-actions, but in reality, as indicated in Hayward’s statement, incident response is a lot of hard, detailed preparation work that must be undertaken well in advance of a detected incident or breach. Hayward and her team assist clients in responding to cyber incidents, and she says that the actions an organization has to take once an incident or breach has been declared can vary widely based on whether or not the affected organization completed this pre-work.
Out along the edges
One of the first things organizations must do in planning incident response procedures wrote Hayward in a co-authored blog published last year, is to understand the difference between an “incident,” an “event,” and a “breach.” Casual use of terminology can lead to confusion about each category’s specific meaning (and the resultant response). While information security practitioners might know the actual definitions and differences, incident response involves participation from executives and line of business managers, and it’s not safe to assume everyone is on the same page. Therefore, security teams should clearly define each of the terms.
According to the National Institute of Standards and Technology (NIST), “A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” US-CERT provides some examples of such incidents:
- Attempts (either failed or successful) to gain unauthorized access to a system or its data
- Unwanted disruption or denial of service
- The unauthorized use of a system for the processing or storage of data
- Changes to system hardware, firmware, or software characteristics without the owner's knowledge, instruction, or consent
NIST defines an event as “any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt.” An “event” is, therefore, not necessarily negative or harmful.
A data breach, on the other hand, is an information security incident in which sensitive, proprietary, or confidential data is accessed, viewed, stolen, or in any way used by unauthorized parties or systems.
Always where I burn to be
With terminology now clarified and advanced planning completed, when a potential cyber issue arises and it is in fact an incident or breach, Hayward says the first step is to “determine authority to call an incident.” Declaring an incident shouldn’t be taken lightly, and serious conversations should take place behind closed doors before any announcement. Once an incident is determined, to ensure consistency and clarity, one designated person from the incident response team should be appointed to formally declare an incident. It’s only at that point that the incident response plan kicks into high gear.
Each person on the incident response team should be aware of, prepared to enact, and have practiced his or her role during a declared incident. This includes any “backups,” or alternate players who might be involved if the primary person is unavailable or unable to perform her/his duties. Different participants will need to play different roles during an incident; some individuals will have job-specific technical responsibilities (analysis, containment, eradication), while other actions (communication and coordination) could be managed by several appropriately-skilled members of the team. Assigning duties, says Hayward, is critically important and “will minimize confusion when tough decisions need to be made” or when information needs to be communicated internally, externally, or both.
The further on the edge
Sticking with the theme of “assignment,” Hayward recommends response teams avoid assigning a severity level to the incident, for example, a “high, medium, low” or “1 through 10,” as some companies are inclined to do. Incident responders should not rush to judgement, neither overreacting nor assuming the incident is minor until all facts have been gathered. It’s only after all steps have been completed that the organization can truly understand how much damage or loss has occurred, and so the best advice Hayward can offer is to “consider every incident a top priority” and proceed according to plan. She adds that processes for what happens when and by whom should be outlined in the planning stages and followed during the incident, regardless of any suspicions about the overall severity. There may be times during an incident when facts are gathered and it becomes crucial to pivot and react to an incident-specific need; those opportunities for diversion should be spelled out in the plan and, most importantly, tested and practiced during table top exercises or mock incidents. Making snap decisions during a heightened situation is ill-advised, and incident response teams will do well to establish guidelines and policies ahead of time, then practice and test them regularly so that everyone is prepared when an incident hits.
In that same vein, in the hustle and bustle that inevitably accompanies an incident it’s easy to misplace important items like network diagrams or contact information for critical vendors or partners, says Hayward. For this reason, she advises teams to “gather pertinent information” as part of incident response planning and store it in an accessible place. Keep in mind that email, databases, storage, segments of the network, etc. might not be available during an incident, so it’s sensible to keep backup copies in air-gapped locations and/or stored in hard copy.
A final one of Hayward’s “Important Steps” for building an incident response plan is to remember that your organizations and its data, people, assets, partnerships, and capabilities are constantly evolving. As a result, it’s imperative to review, update, and revise the incident response plan accordingly. Take into account, too, any lessons learned from prior incidents. Response teams should always perform post-incident assessments to discuss what went right, what went wrong, and what could use minor adjusting. Any conclusions from those conversations should be integrated in the plan along with any environmental considerations, if appropriate.
The hotter the intensity
The most fundamental part of incident response planning is to understand that it’s a living, breathing cycle. An organization can’t slap a plan together and expect that plan to carry the team through the next three to five years. New challenges and changes will appear at every turn, and organizations that remember to include those adjustments in their plan will be much more equipped to handle—and recover from—an incident.
Click here for more information on our InfoSec World Conference & Expo in Orlando from April 3-5.
More Infosec Articles