Incidence Response

Darin Roberts //

According to the Identity Theft Resource Center, there were 781 data breaches tracked in 2015.  That is, on average, over 2 per day.  And that represents only the data breaches that were reported by legal requirements or that were reported by news media.  This is the second highest year on record (since 2005).  It isn’t a matter of if you will get breached, it is only a matter of when.

So what are you going to do about it?  You can try to prevent it as much as possible, but what are you going to do when the inevitable happens and there is a breach?  Here is a quick outline of some of the things that should be done if and when the unfortunate event happens.  I will use as the basis of my outline the information from the SANS Incident Management Model.

Throughout this whole process you should remember to document everything that has happened and what you are doing.  In the case that something goes wrong in your process you will be able to see what you did and undo any mistakes.  If it all went well, you will have some great information for when something else happens in the future.

noun_light-bulb_11282  Prepare

Long before you have an incident, you need to be preparing for it.  You need to have all of the policies and procedures in place prior to the problem even arising.  If you have an issue and you need to look through your employees’ computers, do you have permission to do so?  When you find that there is a problem, who is going to be in charge?  What are the steps you will take to proceed to get back to a normal working condition?  If you aren’t a large enough organization to have your own IT department, or just need some backup, who are you going to call to help you through the process?  These, along with many other questions, need to be thought out before the incident occurs.

After you have prepared, the next steps become much more manageable.  While it will still cause you problems to return to life as usual, you will not be wondering what to do.  Preparation is the first and probably the most important step to take, but it must be done prior to the incident.



The first thing you should identify should be the person who is going to be handling your incidents.  You should have a system in place so you know who to contact and who will be in charge.

You also need to make sure that something really took place.  What systems are affected, and who needs to be told?  Is it only an isolated incident, or is it widespread and affects many systems?  Identification can be difficult.  Even if you have identified something has happened or is happening, it is even more challenging to understand the type, extent and magnitude of the problem.  It might be a good idea to have a company at the ready to aid in identification of incidents.



Prior to an incident, you need to have a plan in place that will help determine strategies of containment.  If your system has been breached, you should know exactly what to do before you have identified the problem.  Are you going to shut down the system, disconnect if from the network, or just turn a certain function(s) off?  Obviously the severity of the issue will determine what processes you will take to contain the issue, but determining beforehand will make those decisions much simpler and quicker.

During the containment phase you should gathering information and evidence.  The evidence should be used to help fix the issue, but it also could be useful in the case of legal proceedings.  Again, documentation during this phase is critical.  You should log all that you are doing.



After you have contained the incident, the next step is to remove it.  This can sometimes be a tricky step in the process.  Sometimes it can be as easy as running an antivirus or spyware scanner or you may need to restore from a backup and patch your system to fix any known vulnerabilities.  If you do a restore, make sure that the original is not infected as well.

As part of the preparation phase there are things you can do to make eradication much simpler.  If you take the time to have a standard configuration for your systems, restoring will be easier than if each system has its own configuration.  The more standard your systems are, the quicker the restore will be.



Recovery is putting everything back together.  Again, standardizing systems will make this much easier.  What are you going to do to prevent this from happening again?  Is it going to be hardware changes, software changes, patches, password rule changes?  Is it going to be building security?  Even after you are back up and running, you need to work on prevention so this incident doesn’t repeat itself.


Lessons Learned

After you have put Humpty Dumpty back together again, you need to sit down with your Incidence Response Team and talk about lessons learned.  With all of your copious notes and documentation, you will have some great information to go through and talk about.  Maybe you need to go back and do some more preparation, maybe you need to do more identification on who should be in charge.  You might need to revamp your containment procedures.  If you don’t learn from what has happened, you have wasted a great opportunity.

While it is never a comfortable situation to be compromised, it is possible to make it easier on you and your organization.  Preparation before the incident can go a long way in getting back to normal.  And learning from not only the incident itself, but how you respond to it, will help you improve preparations and handle the next one when it comes.



Mason Pokladnik, Gold Paper, 2007,