Introduction

As we always say at Infosecnirvana, “Every Attacker leaves behind a trail”. Identifying the trail in an organization’s infrastructure is the main goal of Incident Detection and this is where all the cutting edge technology, talented people and mature processes come together. From Perimeter protection devices like Firewalls (Both Network & Application), IDS/IPS, Breach Detection Systems (FireEye, Fidelis, etc.), to Endpoint Protection Systems like AV-AS, HIDS, there are a host of security management systems that help to detect potential Security incidents needing action. Even Physical Security systems, Industrial control systems, etc. can be detecting Incidents. Never before has incident detection been important than today and it comes as little surprise when organizations globally want to look at Incident Detection as an important tenet in their security posture. But before embarking on an Incident detection journey, it is important to understand the basics of Incident detection and how it forms the foundations of CSIRT functions world over. So let us start with the introduction.

Security Events are not Security Incidents:  Confused??? Don’t be. Yes, Security events are not Security incidents. Both are different and here’s Why? Security products and technologies generate several actionable items. Helpdesk, Consumers, Business, Audit and compliance and even a Security guard reports Security issues. All these together are “Security Events”. However, not all of these events are fit enough to become Security Incidents. The Events have to be carefully validated for Relevance, Authenticity, Impact and Urgency. Only after this initial validation does an event qualify as a Security incident worth investigating. In short “A Security Incident is a Qualified Security Event”. If a team where to focus on every single Security event as a Security Incident, it will be an Operational nightmare. Hence it is important to perform Event Management or Event Handling.

Event Management: Every organization should have an effective Event Management process. The Event management philosophy should be “Many inputs (Event Reporting) but One Output (Incident)”. At a broad level there are 2 major Input sources to a Central Event Management system. They are described below:

• Automated Event Reporting: Most of the Security tools and technologies today generate several Security events daily. However, it is always difficult to individually handle these events when there are several point products in the market today. But, with the advent of SIEM, gathering, correlating and real-time alerting of these Security events is now possible. In SIEM parlance, this is done using “Use Cases”. Years back, we published a post on “Use Case Development Framework for SIEM” which went in enough details on how to build Use Cases on SIEM. This Automated Event reporting thus becomes the most important input into the Central Event Management function.
• Manual Event Reporting: Anyone from the Business, Legal, Consumers, End Users etc. can report potential Security events to an organization. Generally, most of the organizations have a IT Helpdesk as the central reporting desk for such issues. The reporting is typically done through and email system or through a phone call. Several organizations have an online self help ticketing system to report such events too. However, these have to be handled manually.

Event Qualification:

Once the events are reported automatically or manually, the next step is Event Qualification. Before making a determination whether the event is an Security Incident or not, a few deterministic questions need to be answered. Some of those are listed below:

• Date – Date of event discovery
• Time – Time of event discovery
• Time Zone – Time zone of the event source is critical when systems or businesses are geographically dispersed
• How was the event discovered?
• What is the impact of this event and what locations are impacted?
• Is the event ongoing?
• Event Reporter contact information?
• Type of data or systems affected (if available)

Based on the responses, an initial determination can be made about the nature of the event. If this event is a Non-Security related event, they it can be routed to the respective teams for further investigation and resolution. If the event is indeed a Security related, it is raised to the Incident Detection & Response team or the CSIRT team as a Security Incident for further investigation and response.

After generating a Incident…

Once an Incident is generated from Event/Events, it has to be classified and categorized. This is the main function of Incident Classification function.

Go back or Continue reading Part 2 – Incident Classification

Introduction:

As discussed in Part 1 – Incident Detection, once the incident is detected, it needs to be categorized appropriately for Type, Severity and Impact so that necessary response actions can be taken. Incident Classification as such has two major parts to it – One is the Incident Categorization and the other is the Incident Severity Rating. Categorization assists in putting the events in to a common bucket for better coordinated and consistent handling while the Severity ratings assist in assigning a “sense of urgency” to the Incident detected. Without Incident Classification, a CSIRT function can quickly disintegrate into a pile of Operational mess. In fact, many organizations struggle with this aspect of CSIRT function.  Hence, In this post, we will try to help readers with a simple  and practical approach that we have seen work when it comes to Incident Classification.

Incident Categorization:

As mentioned at the beginning of the post, Categorization is similar to bucketing. However, the biggest question organizations face is “How do I bucket incidents?”, “What reference can I use”.

To order this, I am going to use two popular categorization standards. One if the all famous NIST categorization standard, and the other is the FIRST categorization standard.

NIST Categories:

US Federal agency has been at the forefront of Incident detection and response and they have come up with Incident categories to assist in Incident reporting and response.  In the diagram below, you can see the NIST categories listed.

FIRST Categories: 

Apart from NIST, organizations like FIRST have also come out with several guidelines for Incident Categorization. The diagram below shows one of their examples (from Cisco) for Categorization.

Now, both these models may not suit you entirely, but in general, we believe have at least 5 or 6 Categories will assist in better Incident Categorization. For example:

• CAT 1 – Unauthorized Access, Compromised machine, Compromised Asset, Data Theft, Espionage etc.
• CAT 2 – Denial of Service (DoS/DDoS)
• CAT 3 – Malware or Malicious Code
• CAT 4 – Reconnaissance or Scans or Probes etc. 
• CAT 5 – Policy Violations or Improper Usage
• CAT 6 – Others or Uncategorised 

This above categorization does a few things to combine the best of both worlds from NIST and FIRST and order them in a nice fashion in order of importance. CAT 1 being the most critical category and CAT 6 being uncategorised.

Incident Severity Rating:

Now that the Incident has been categorized, it is important to assign a Severity rating to the same. Severity ratings are typically done using Likelihood and Impact. One of the matrix which comes in quite handy is given below.

As you can see, the Severity rating is basically a 5 step scale from Very Low to Critical. It has Impact and Likelihood as a matrix to help decide the severity. Both Impact and Likelihood typically arbitrary and left to the judgement of the person handling the Incident. However, many organizations tend to define this as much as possible.

Impact, a more business risk related term can be quantified by using Asset Values, Data Sensitivity Classifications, etc. while Likelihood is a more technical input arising out of the “Incident” itself like “Well known exploit = Easily Available = Likely” or “Current Infection Vector in our organization = Currently Spreading = Almost Certain”.

In Summary, With the Incident Categorization and Severity rating, you can easily bucket an incident thereby completing the Incident Classification phase of CSIRT Framework.

Go Back or Proceed with Part 3 – Incident Handling