Preparing for challenges associated with any technology central to your workflow is an important part of a comprehensive security and risk management strategy for organizations concerned with the integrity of their system. Inevitably, regardless of the steps you take to prevent problems associated with things like viruses, hardware failures, data breaches, and so on, there will probably be a situation where you are forced to react to an unexpected incident. You must be prepared to evaluate and manage the incident and perhaps even make major changes to your technology or the way you work. But how should you react? I’d like to outline a few factors to weigh when coming up with an incident response policy, so that you have a few guiding principles to keep in mind.
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.
About the Author: Ben Schmerler is a vCIO Consultant at DP Solutions, one of the most reputable IT managed service providers (MSP) in the Mid-Atlantic region. Ben works with his clients to develop a consistent strategy not only for technical security, but also policy/compliance management, system design, integration planning, and other business level technology concerns. You can follow DP Solutions updates on LinkedIn or their website: www.dpsolutions.com. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
