US-CERT Federal Incident Notification Guidelines (2015)

See new federal incident notification guidelines. The new incident reporting guidelines specify additional mandatory reporting fields.

 Downloadable PDF version of this guideline document available here.

This document provides guidance to Federal Government Departments and Agencies (D/As); State, Local, Tribal, and Territorial government entities; Information Sharing and Analysis Centers (ISACs); and foreign, commercial, and private sector organizations for submitting incident notifications to the United States Computer Emergency Readiness Team (US-CERT). A computer security incident within the Federal Government is defined by the National Institute of Standards and Technology (NIST) and US-CERT as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

US-CERT acts as the federal information security incident center for the United States Federal Government per the Federal Information Security Management Act of 2002 (FISMA).[1] Pursuant to FISMA, each federal agency is required to notify and consult with US-CERT regarding information security incidents involving the information and information systems (managed by a federal agency, contractor, or other source) that support the operations and assets of the agency.[2] This includes incidents involving Control Systems, which include Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), Programmable Logic Controllers (PLCs) and other types of industrial measurement and control systems. Reporting by all other entities is voluntary.

These guidelines support US-CERT in executing its mission objectives and enable the following benefits:

• Greater quality of information - Alignment with incident reporting and handling guidance from NIST 800-61 Revision 2 to introduce functional, informational and recoverability impact classifications, allowing US-CERT to better recognize significant incidents.
• Improved information sharing and situational awareness - Establishing a one-hour notification time frame for all incidents to improve US-CERT’s ability to understand cybersecurity events affecting the government.
• Faster incident response times - Moving cause analysis to the closing phase of the incident handling process to expedite initial notification. 

Table of Contents

• Standard Data Elements
• Incident Notification
• Impact Classifications
• Threat Vectors
• Threat Vectors Taxonomy
• Cause Analysis
• Incident Examples
   

Standard Data Elements

To facilitate effective and consistent incident handling, US-CERT has established a standard set of data elements to collect for each incident report. Incident notifications should include a description of the incident and as much of the following information as possible:

Important: Ensure that any technology used to capture sensitive incident information, including Personally Identifiable Information (PII), is properly secured to preserve confidentiality and integrity.

• Contact information for both the impacted and reporting organizations (unless submitting an anonymous report)
• Details describing any vulnerabilities involved (i.e., Common Vulnerabilities and Exposures (CVE) identifiers)
• Date/Time of occurrence, including time zone
• Date/Time of detection and identification, including time zone
• Related indicators (e.g. hostnames, domain names, network traffic characteristics, registry keys, X.509 certificates, MD5 file signatures)
• Threat vectors, if known (see Threat Vector Taxonomy and Cause Analysis flowchart)
• Prioritization factors (i.e. functional impact, information impact, and recoverability)
• Source and Destination Internet Protocol (IP) address, port, and protocol
• Operating System(s) affected
• Mitigating factors (e.g. full disk encryption or two-factor authentication)
• Mitigation actions taken, if applicable
• System Function(s) (e.g. web server, domain controller, or workstation)
• Physical system location(s) (e.g. Washington DC, Los Angeles, CA)
• Sources, methods, or tools used to identify the incident (e.g. Intrusion Detection System or audit log analysis) 

Back to Top
 

Incident Notification

Notifying US-CERT of a computer security incident is mandatory when the confidentiality, integrity, or availability of a Federal Government information system has been confirmed to be compromised. Notification of incidents which have no confirmed functional or information impact such as passive scans, phishing attempts, attempted access, or thwarted exploits may be submitted to US-CERT voluntarily. For voluntary reports, please identify the threat vector and any potential indicators of compromise before notification.

Requirement: US-CERT must be notified of all computer security incidents involving a Federal Government Information system with a confirmed impact to confidentiality, integrity or availability within one hour of being positively identified by the agency’s top-level Computer Security Incident Response Team (CSIRT), Security Operations Center (SOC), or Information Technology (IT) department.

It is imperative for reporting agencies to adhere to the one-hour timeframe and provide all available information. Do not delay reporting in order to provide further details (i.e. root cause, vulnerabilities exploited, or mitigation actions taken) as this may result in high risk to the system or enterprise. If the cause of the incident is later identified, the threat vector may be updated in a follow-up report.

Follow the steps below to send an incident notification to US-CERT:

1. Identify functional impact (see Impact Classification table)  *required
2. Identify information impact (see Impact Classification table)  *required
3. Identify impact to recoverability (see Impact Classification table)  *required
4. Identify threat vector (see Cause Analysis flowchart), if possible
5. Provide any mitigation details, if possible
6. Provide contact information and any available incident details  *required  

Important:  Please refrain from adding sensitive Personally Identifiable Information [6] (PII) to incident submissions. Any contact information collected will be handled according to the DHS Website Privacy Policy. [3]

7. Submit to US-CERT. Please note that batched reports (multiple, separate incidents in a single submission) will be considered invalid. Reports may be submitted using the US- CERT Incident Reporting Form or by using the contact information available from the US-CERT website.

Back to Top
 

Impact Classifications

Please use the table below to identify the impact of the incident. Incidents may affect multiple types of data; therefore, D/As may select multiple options when identifying the information impact. The security categorization of federal information and information systems must be determined in accordance with Federal Information Processing Standards (FIPS) Publication 199. Specific thresholds for loss of service availability (i.e. all, subset, loss of efficiency) must be defined by the reporting organization.

Note: Please refrain from reporting incidents involving non-cyber PII exposures or classified data spillage (i.e. unsecured hard copies) to US-CERT. Notify your organization’s Privacy Office of all non-cyber incidents involving PII. Contact your Security Office for further guidance on responding to classified data spillage. 

Back to Top

Threat Vectors

To clearly communicate incidents throughout the Federal Government and supported organizations, it is necessary for government incident response teams to adopt a common set of terms and relationships between those terms. All elements of the Federal Government should use this common taxonomy.

Below is a high-level set of concepts and descriptions developed from guidance in NIST SP 800- 61 Revision 2. Federal civilian agencies are to utilize the following threat vectors taxonomy when sending cybersecurity incident notifications to US-CERT. 

Back to Top 
 

Threat Vectors Taxonomy

Back to Top

Cause Analysis

Use the decision tree below to assist in identifying the appropriate threat vector: 

Back to Top

Incident Examples

Scenario # 1: SQL Injection

An agency reports a successful SQL injection attack on an internal web server. The report confirms that customer data was exfiltrated and an unknown administrator’s account credentials were modified. The agency is requesting assistance to contain and recover from the incident.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: Low
Information Impact: Privacy, Integrity
Recoverability: Extended
Threat Vector: Web

Scenario #2: Anonymous Threat

The organization’s physical security team receives a call from an IT manager, reporting that two of her employees just received anonymous threats against the organization’s systems. Based on an investigation, the physical security team believes that the threats should be taken seriously and notifies the appropriate internal teams, including the incident response team, of the threats.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: None
Recoverability: Not Applicable
Threat Vector: Other

Scenario #3: Peer-to-Peer File Sharing

The organization prohibits the use of peer-to-peer (P2P) file sharing services. The organization’s network intrusion detection sensors have signatures enabled that can detect the usage of several popular P2P file sharing services. On a Monday evening, an intrusion detection analyst notices that several file sharing alerts have occurred during the past three hours, all involving the same internal IP address. Upon further investigation, the analyst confirmed that the internal users transmitted unlicensed software during the incident.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: Proprietary
Recoverability: Regular
Threat Vector: Improper Usage

Scenario #4: Unknown Wireless Access Point

A wireless intrusion detection system detects an unauthorized wireless access point (WAP) in close vicinity to agency facilities. The WAP’s Service Set Identifier is similar to that of an authorized device. Additionally, the unauthorized WAP is causing interference with several authorized WAPs. Physical security is contacted to assist in remediating the issue.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: Low
Information Impact: None
Recoverability: Supplemented
Threat Vector: Impersonation

Scenario #5: Lost Mobile Device

On 05-15-14 at approximately 9:20am PST, the Help Desk received a report of a missing/lost blackberry smart phone. The appropriate staff has been notified to terminate the phone service. There was no known PII or Controlled Unclassified Information (CUI) information on the device. A "kill-pill" message will be sent to the mobile device that functionally wipes and disables the handset. The device is encrypted with a NIST FIPS 140-2 evaluated and listed encryption. Site does not allow files to be downloaded and locally stored. The device is used for phone/email purposes.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: None
Recoverability: Regular
Threat Vector: Loss or Theft of Equipment

Scenario #6: Distributed Denial of Service (DDoS)

A DDoS attack was launched against an agency server causing a firewall failover. The agency experienced a minor outage for approximately 1 hour before the device was fully recovered. Further investigation identified the attack as a DNS amplification attack. There may be additional protocols and ports involved. Agency does not require remote or on-site assistance to recover from the incident.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: Low
Information Impact: None
Recoverability: Regular
Threat Vector: Attrition

Scenario #7: Data Exfiltration

An OMB MAX account was compromised and used to view 100+ webpages and documents on the OMB MAX server.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: Privacy
Recoverability: Regular
Threat Vector: Impersonation

Scenario #8: Malware infection

An agency identified a system that was exposed to malicious content in the form of a Trojan Downloader. The exposure resulted from access to a malicious Internet web site identified and validated through audit log analysis. Enterprise anti-virus solutions detected the malicious content, but failed to prevent infection. The exposure has corrupted the integrity of the data and has impacted the availability of resources. The agency is coordinating with impacted stakeholders to mitigate further risk exposure.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: Low
Information Impact: Integrity
Recoverability: Regular
Threat Vector: Web

Scenario #9: Phishing

A user responded to a phishing email asking for her web mail login details. The attacker then used the disclosed credentials to access the user’s webmail account and send out phishing spam.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: Privacy
Recoverability: Regular
Threat Vector: Impersonation

Scenario #10: Man-in-the-Middle

Agency reports successful man-in-the-middle attack on a public wireless network involving the capture of authentication credentials.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: Privacy
Recoverability: Regular
Threat Vector: Impersonation

Scenario # 11: Unauthorized Access without Data Breach

During the course of daily scans, an agency’s system detects an unknown host on the internal network. After further analysis the agency’s computer incident response team identifies that the intruder used obfuscation techniques to breach an agency network. They uncover that the individual did not access agency data due to internal security and access controls. In response the agency updated firewall rules to block the intruder’s system.

Correct Impact Classification and Threat Vector selections: 
Functional Impact: None
Information Impact: Integrity
Recoverability: Regular
Threat Vector: Other

Back to Top