Incident Response Primer

Chapter 2. Incident Identification and Categorization

Now you understand the terminology as well as some of the problems your organization can face with the types of people who may be after your resources. You can start gathering information to sort the wheat from the chaff, as it were, meaning you are looking to skim the incidents from the events and perform some triage. You need to make determinations as to what should be done about the incident—does it require additional work or can it be closed? What is the criticality of it, meaning what systems or data may be impacted by the incident? Since an incident by definition is an adverse event, all incidents should be addressed in some way. But some incidents are going to be more urgent than others.

To start responding to incidents, you first need some data to determine when the event happened, along with additional data that can answer the question as to whether an event is really an incident, rather than something completely pedestrian. There are a number of things to consider when you are thinking about inputs to this process. You can look at logs, which nearly all devices generate, and you can also look at how you handle those logs. Of course, just gathering the logs is not enough. You need a way to generate actionable information based on the logs. For this, you need some way to correlate log information to apply some intelligence (ideally automated) the data you’ve gathered.

And just having the data is not enough, either. ...