Image
Incident Severity and Classification
What were the consequences associated with the incident? A virus infecting a PC and rendering it temporarily unusable is a much different incident than, say, CryptoLocker infecting a server rendering production data unavailable, unreadable and unusable. While both incidents require prompt attention, one incident is likely to impact just one person, while the other could affect the entire organization. It goes without saying that much more dramatic steps should be taken to prevent and, if necessary, deal with incidents in the example with the server.Security Incidents vs. Infrastructure Incidents
CryptoLocker can bring your work to a halt, and that technical threat represents an existential threat to your system. But other incidents can represent similar interruptions to your work and aren’t necessarily a threat to the integrity of your data. One such example is the recent Distributed Denial of Service (DDoS) attack on Dyn that brought down a large swathe of the Internet. While your data was probably safe, if you need to access data outside of your local resources (which today is almost a given), this is also an incident for which you should develop a reactionary policy. The same kind of thinking also applies to incidents such as floods or fires.Reporting, Responsibility and Resources... the 3 R's of Incident Response
Regardless of who has to deal with the incident, every person in an organization that implements a policy like this needs to have awareness of the policy and the chain of command when it comes to reporting and reacting to incidents. It’s very important that users don’t go too far in trying to deal with incidents on their own, regardless of their relative responsibility in how the incident occurred in the first place, as this can often cause many unintentional negative consequences. Additionally, any incident response policy should consider the actual resources needed to deal with even the most dramatic incidents. A plan doesn’t work if the means of accomplishing the steps outlined in it are not feasible due to a lack of people, money, hardware, or whatever other resources are needed to respond properly.Be Reasonable and Know Your Limits
Just because you define a plan in an incident response policy, you need to be sure that the parties involved are prepared to be a part of that response. For example, if you lack a knowledgeable local IT person in your office, perhaps it should be outlined that your third-party vendor is responsible for doing things like pulling down backup data or wiring up that replacement switch. Remember, we are presumably in risky territory when we are responding to incidents, so it’s not the time to hold back on using experts to deal with these challenges if it’s appropriate. Another part of being reasonable is focusing on plausible incidents. Oftentimes, I tell my smaller clients not to plan for far-fetched scenarios that go well beyond what they can reasonably prepare for.Communication
Who needs to know about the incident? Is this an internal problem that some or all of the staff needs to be aware of? Or is the incident significant enough that clients, partners, or other third-parties need to be made aware of it, either for ethical or legal reasons? It’s important you consider who is impacted by these incidents and define who reaches out to them and in what fashion. You should also be aware of how these incidents might affect your agreements with others. If you make guarantees to business partners, those guarantees aren’t nullified because of an incident.Testing
This probably doesn’t require much explanation, but it’s one thing to plan for an incident, and it’s another to be confident in the effectiveness of your reaction to an incident. This means making sure that technical measures are tested, response team members are well-educated on their roles, and the response policy itself is updated often and reflects the current status of the organization. When the incident is resolved, it’s important to ask how other organization policies, not just incident response, may need to change in light of new information. These aren’t the only things to consider when developing your own incident response policy, but as you can probably tell, the parameters of your policy should fit the impact to your organization and be flexible enough to deal with different kinds of incidents.Image
