Basic Incident Response Planning
As every security minded person will tell you; it’s a question of when, not if, something happens. In response to this, all types of security backup plans and procedures have become commonplace. Things like Business continuity planning, Disaster recovery, mirrored hosting and Incident Response.
With the rapid increase in cybercrime, I think we can’t afford to not have e a procedure in place, no matter the size of your network. Therefore I would like to share some general basics on building an incident response plan.
Incident response is a must
To make Incident Response effective, it helps to have an overview of what you’re trying to protect. Often this is done by identifying the “crown jewels” of the company, the systems, and information considered critical for continued existence. For obvious reasons, you’ll want to focus most efforts here.
But don’t forget the other important components of your environment, having client data leak, your homepage defaced or you’re CEO’s twitter account compromised could all result in heavy reputational damage.
I’m not saying these components should be covered with the same level of scrutiny as the operational system of a nuclear powerplant, but they should at least be considered.
Now that you know what you’re trying to protect; you know what you want to avoid. A good starting point is to define your Threat landscape, an overview of incidents that threaten you specifically.
If you perform a substantial amount of remote tech-support, you have a high risk of social engineering attacks from attackers posing as clients asking for their confidential information. But if you’re more focused on financial transactions, Malware in the form of Remote Access Tools (RAT’s) would be a more common threat.
Being aware of what you’re facing will help you focus your efforts. You might not be fully prepared for world-shattering events, but you will be ready for incidents shattering your world.
Create an action plan
Identify, Contain, Eradicate (ICE) my three basic steps for incident response. This will work in almost every situation, but it isn’t going to be pretty.
Ideally, you want a plan that is more comprehensive, that not only tries to remediate the incident but also performs damage control along the way and considers both operations, legal and business requirements.
Making a plan that works isn’t too hard but making a plan that works well is going to require a team effort and a lot of practice.
Practice your plan
Once you know what to do its time for a test run. Running incident simulations can help you and your team identify areas of improvement as well as gain confidence in what to do.
I’ve seen many instances of teams concluding that they completely forgot one thing or another. Sometimes simple things are forgotten like the phone tree or mailing list. Discovering these gaps in your plan can turn out to be critical during the actual response.
So now that you’ve got your incident response plan ready and have practiced it a few times what’s next? Keep improving!
Incident simulations should be run annually to make sure everyone knows what’s going on, even though you don’t need to involve the entire organization for this. These lessons learned can then help you improve the response plan even further.
Finally, keep your plan up to date to the latest threats. The threat landscape is constantly changing, and you should prepare accordingly. Knowing what’s happening to others in your industry or region will greatly help in this.