Incident Handling​

Peter, I can't eat red lobster. No seriously, I prefer the blue ones they are not as snappy. If you have landed on this page, you might be curious to know what Incident Handling is or how to address security incidents in your organization correctly.

Incident handling is a plan of action for dealing with intrusions, cyber-theft, denial of service or any other information security-related events. Most people assume a security incident as an intrusion but don't forget insider crime, intentional or unintentional events that may cause loss of data or service. Other things to consider are intellectual property like trade secrets, patents, copyrights, and trademarks. The critical point in incident handling is to act upon the security threat, and it will not matter how great of a plan you may have if your watching things happen. Rember time is always against you so act quickly to minimize the damage. Your method of action must also comply with the laws set forth by your local, state, and federal governments.

Before we dive into the actual handling process, I want to clarify what an incident, event, and alert are. Alerts build up to an event and events lead to an incident. Typical incidents include unauthorized use of an account, unauthorized use of system privileges, or execution of malicious code that destroys or exfiltrates data. Company policy will determine the differences between alerts and events, but incidents almost always imply harm or an attempt to harm a computer system. This harm may not still be what you expect because things like floods or fires are considered an incident.
On the contrary, an event is any observable occurrence in a system and or network. Some examples of activities include but not limited to system boot sequence, system crash, or packet flooding. You might have thought a packet flood to be an incident, but this may very well be legit traffic. You're not receiving a denial of service attack you are merely the popular guy on the street. Events however are, they tell a story, and so you should log and record these events. Having this information in multiple places helps legitimize your claims if you happen to be in court. Two is better than one.

The six stages of incident handling are; Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. You can call these steps what you like; however, these are the industry standard terms set by SANS. It helps me remember them using the acronym "Peter I Can't eat red lobster." When an incident happens, it's wise to take time to think. It's important to act quickly but do so that you minimize mistakes. Incident handling is very much like first aid and errors can be life-threatening or in this case, one could ruin evidence. When an incident happens, follow your plan, document everything, and don't skip any steps. NIST has developed a comprehensive Incident handling plan at the link below.

NIST Security incident handling guild

Before we move into detail for each step of your incident handling plan, remember to share experiences with other organizations and other teams. Bad guys always share information, and if we as security professionals don't do the same, they will still have a step ahead of us.

Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned

If this has been helpful to you, please support this blog by buying a coffee