Incident Handling – the dead horse that won’t die

By Ron Simmons

Do you have a documented and tested incident handling program? To my surprise, some a majority of companies lack this basic necessity. Putting something in place may take some time, but here are some tips and suggestions to help get started.

Define: incident

For those familiar with ITIL (Information Technology Infrastructure Library), it is important to note a security incident is not the same as an ITIL incident. ITIL describes and incident as and event that is not a part of the standard operation in these terms an incident is the start of a service delivery or problem management process.

While in security events are the starting point for us, they are issues in the enterprise that could lead up and incident. The best definition of incident that I have read out there is “An incident is any situation that exceeds normal risk management processes.”

Instead of focusing on a specific type of incident, an “Incident handling” process must be designed to be broad enough to support any type of threat or exposure to organizations systems, data, and/or physical infrastructure, etc…. Breaches happen in many forms now days, improper disposal of documentation, lose of equipment, system compromises, all the way to the janitor attempting to sell DOE restricted data. However when you think about it, an incident may not end up in a breach, but a breach will always be an incident. Breaches encompass many forms of data, personal information, financial account information, health care information, trade or governmental secrets, and the list goes on.

Simple is always effective, and it is no different when it comes to incident handling. Good incident handling does not require a novel. To get started, keep terms general, include process flow charts and check lists. When responding to an incident, these will keep everyone on track and ensure all actions are documented.

The process can be broken down in 5 simple steps:

 1.   Prepare (for incidents)

 2.   Identify

 3.   Incident handling

 4.   Recover (from incident)

 5.   Lessons learned

 

Preparation – Proactive

Preparation is the most critical element. Document the guidelines to handle incidents. Preparation ensures you will be better equipped to handle most situations as they come up.

First start by identifying what your organization has that it considers critical assets. This could be technology, customer data, physical assets, even services that are offered. Then you need to identify what types of threats does your company face. Keep it simple here, no need to go into specifics, IS threats, physical threats, insider threats, etc…. Then document your policy, guidelines, and checklists on how to identify, resolve, and recover from them.

Remember to keep it general, there is no way you can identify all possible threats down to exacts.

Identification

This is the most difficult step of this process. The ability to gather “events” is crucial – without it, the incident could be missed. An organization has to know the sources of the events and what their meanings are in order to validate and event and move into the incident handling process. The best piece of advice anyone could get here is “log… and log everything.” Without logs you can and most likely will miss the event that leads to your incident. The last thing anyone wants is for an outside company to discover the incident before you do as a company.

To help you could come up with cheat sheet to assist your employees in identification of incidents.

Incident Handling

Here is where we stop the bleeding. Once the incident has been identified assemble your strike team, move in, and eradicate the incident. Here is where preparation comes in:  if the documentation is in order, including the procedures on how to handle different types of incidents, then dealing with them in a rapid and efficient way will be a snap.

Recovery

“Simply” put things back to normal. Make sure that back to normal does not include the risk that was abused in the first place to create this incident. In a cyber incident this normally means rebuild from scratch. Be careful if you decide to restored from backup, if can not or have not identified exactly when the breach or incident happened, you could restore back to the bad state and have to start all over. It is best to restore your configurations from your configuration management system.

Lessons Learned

Take what you have learned from this and return to the preparation phase and make modifications as necessary. These modifications could also mean changes to the production systems, the physical environment and even the training you give your employees. Sometimes these changes could seem silly, but you still need to heed the warnings and make the change.

---

http://en.wikipedia.org/wiki/ITIL

http://www.knowledgetransfer.net/dictionary/ITIL/en/Incident.htm

http://securosis.com/2008/08/20/the-best-incident-response-training-you-can-buy-for-free/

http://darkreading.com/security/attacks/showArticle.jhtml?articleID=212902962