CIRT Case Classification (Draft)

CSIRT Case Classification (Example for Enterprise CSIRT)

I. Scope

It is critical that the CSIRT provide consistent and timely response to the customer, and that sensitive information is handled appropriately. This document provides the guidelines needed for CSIRT Incident Managers (IM) to classify the case category, criticality level, and sensitivity level for each CSIRT case. This information will be entered into the Incident Tracking System (ITS) when a case is created. Consistent case classification is required for the CSIRT to provide accurate reporting to management on a regular basis. In addition, the classifications will provide CSIRT IM’s with proper case handling procedures and will form the basis of SLA’s between the CSIRT and other Company departments.

II. Incident Categories

All incidents managed by the CSIRT should be classified into one of the categories listed in the table below.

Incident Category	Sensitivity*	Description
Denial of service	S3	DOS or DDOS attack.
Forensics	S1	Any forensic work to be done by CSIRT.
Compromised Information	S1	Attempted or successful destruction, corruption, or disclosure of sensitive corporate information or Intellectual Property.
Compromised Asset	S1, S2	Compromised host (root account, Trojan, rootkit), network device, application, user account. This includes malware-infected hosts where an attacker is actively controlling the host.
Unlawful activity	S1	Theft / Fraud / Human Safety / Child Porn. Computer-related incidents of a criminal nature, likely involving law enforcement, Global Investigations, or Loss Prevention.
Internal Hacking	S1, S2, S3	Reconnaissance or Suspicious activity originating from inside the Company corporate network, excluding malware.
External Hacking	S1, S2, S3	Reconnaissance or Suspicious Activity originating from outside the Company corporate network (partner network, Internet), excluding malware.
Malware	S3	A virus or worm typically affecting multiple corporate devices. This does not include compromised hosts that are being actively controlled by an attacker via a backdoor or Trojan. (See Compromised Asset)
Email	S3	Spoofed email, SPAM, and other email security-related events.
Consulting	S1, S2, S3	Security consulting unrelated to any confirmed incident.
Policy Violations	S1, S2, S3	Sharing offensive material, sharing/possession of copyright material. Deliberate violation of Infosec policy. Inappropriate use of corporate asset such as computer, network, or application. Unauthorized escalation of privileges or deliberate attempt to subvert access controls.
* - Sensitivity will vary depending on circumstances. Guidelines are provided.

III. Criticality Classification

The criticality matrix defines the minimal customer response time and ongoing communication requirements for a case. The criticality level should be entered into the ITS when a case is created, and it should not be altered at any point during the case lifecycle except when it was incorrectly classified in the first place. Typically the IM will determine the criticality level. In some cases it will be appropriate for the IM to work with the customer to determine the criticality level.

Criticality Classification

Criticality Level

Criticality Level Definition

Typical Incident Categories

Initial Response Time

Ongoing Response (Critical Phase)

Ongoing Response (Resolution Phase)

Ongoing Communication Requirement

Incident affecting critical systems or information with potential to be revenue or customer impacting.

- Denial of service

- Compromised Asset (critical)

- Internal Hacking (active)

- External Hacking (active)

- Virus / Worm (outbreak)

- Destruction of property (critical)

60 Minutes

CSIRT Incident Manager assigned to work case on 24x7 basis.

CSIRT Incident Manager assigned to work on case during normal business hours.

Case update sent to appropriate parties on a daily basis during critical phase. If CSIRT involvement is necessary to restore critical systems to service then case update will be sent a minimum of every 2 hours.

Case update sent to appropriate parties on a weekly basis during resolution phase.

Incident affecting non-critical systems or information, not revenue or customer impacting. Employee investigations that are time sensitive should typically be classified at this level.

- Internal Hacking (not active)

- External Hacking (not active)

- Unauthorized access.

- Policy violations

- Unlawful activity.

- Compromised information.

- Compromised asset. (non-critical)

- Destruction of property (non-critical)

4 Hours

CSIRT Incident Manager assigned to work case on 24x7 basis.

CSIRT Incident Manager assigned to work on case during normal business hours.

Case update sent to appropriate parties on a daily basis during critical phase.

Case update sent to appropriate parties on a weekly basis during resolution phase.

Possible incident, non-critical systems. Incident or employee investigations that are not time sensitive. Long-term investigations involving extensive research and/or detailed forensic work.

- Email

- Forensics Request

- Inappropriate use of property.

- Policy violations.

48 Hours

Case is worked as CSIRT time/resources are available.

Case update sent to appropriate parties on a weekly basis.

Definitions:

Initial Response Time – This specifies the maximum amount of time that should elapse before a CSIRT Incident Manager responds to the customer. Again, this is the maximum amount of time. In most cases the IM will response sooner than the specified response time. At a minimum, the following should occur within this timeframe:

Initial assessment and triage.
Case classification is determined.
The case will be entered into the ITS.
The case ownership will be established. (Either the on-call IM will own the case, or it will be assigned to another IM).
An email will be sent to the customer. This is the initial “we have your case” email. This email will include various information ( to be defined in another document ) such as the date/time of the request, ITS case number, the name, phone, and email of the incident manager, a CSIRT escalation contact, the criticality and sensitivity level of the case, and an indication of when the customer will receive case updates. Ideally, the ITS will generate this email automatically when a case is entered into the system.

Ongoing Response Requirement - This specifies the level of service that the customer will receive from the CSIRT.
Ongoing Communication Requirement – This specifies the frequency in which communications with the customer should occur throughout the case lifecycle. These are the minimum requirements, communications may occur more frequently as required.
Incident Phases:

Incident Phase	Description	Typical Activities
Critical Phase	The period of time in the case lifecycle when active incident response is required in order to ensure the successful resolution of the case. Typically this includes system or service outages, and/or urgent evidence preservation.	Detection, assessment, triage, containment, evidence preservation, initial recovery
Resolution Phase	The period of time in the case lifecycle when active incident response is not required to successfully resolve the case.	Evidence collection, analysis and investigation, forensics, remediation, full recovery, post-mortem.
Notes: The ITS should be modified to include a drop-down selection for incident phase ( ‘Critical’, ‘Resolution’, ‘N/A’ ). For cases that are classified as C1 or C2 this field will be set to Critical when the case is opened, and will be reset to ‘Resolution’ at the appropriate time in the case lifecycle. For cases that are not time-sensitive (typically C3) the IM will set this field to ‘N/A’. Having this distinction will allow CSIRT personnel and Security Operations management to easily distinguish between cases that are critical and active from those that are not being actively worked.

IV. Sensitivity Classification

CSIRT IM’s should always apply the “need to know” principle when communicating case details with other parties. The sensitivity matrix below helps to define “need to know” by classifying cases according to sensitivity level. The ‘Required’ column defines the parties that “need to know” for a given sensitivity level. The ‘Optional’ column defines the other parties that may be included on communications, if necessary. Typically the IM will determine the sensitivity level. In some cases it will be appropriate for the IM to work with the customer to determine the sensitivity level.

Sensitivity Classification
Sensitivity Level	Sensitivity Level Definition	Typical Incident Categories	Required On Case Communications **	Optional On Case Communications **	ITS Access ***
1	Extremely Sensitive.	- Global Investigations Initiated. - Forensics Request - Destruction of property. - Compromised asset. - Compromised information. - Unlawful activity. - Inappropriate use of property. - Policy violations	CSIRT, CPOC	CSIRTM	CSIRT, CSIRTM
2	Sensitive.	- External Hacking - Internal Hacking - Unauthorized Access	CSIRT, CPOC	Security Operations, OWNERS	Security Operations
3	Not Sensitive.	- Denial of service. - Virus / Worm - Email	CSIRT, CPOC	ANY	ALL Agents in ITS
Definitions: CPOC: The customer point of contact, the person that initiated the case with the CSIRT. This is the person in GI/LP/CIAP that initiated a case with the CSIRT. CSIRT: This includes the dedicated CSIRT members, and the CSIRT IM handling the case. CSIRTM: Manager of Security Operations, Director of Infosec. Security Operations: The Infosec Security Operations group. (this includes CSIRT and CSIRTM). OWNERS: The owners of the affected device/application (system administrator, webmaster, etc.) ANY: Any other relevant parties that may be affected including various company groups. It is left to the discretion of the IM to determine who should be included. ITS: Incident Tracking System, Notes: ** “Case Communications” include the following: Initial email from CSIRT to customer, periodic case reports to customer, and final case report to customer. It is not necessary to include these parties on all interim communications that occur throughout the life of a case, just the case updates and summary.

Author: Dustin Schieber dschiebe@cisco.com Gavin Reid gavreid@cisco.com

Incident Phase