CFTC_Cyber_Incident_Response_Plan_v1.1-_4-02-2018.pdf

Commodity Futures Trading Commission Office of Data and Technology

Cybersecurity Incident Response Plan

February 2018 Controlled Unclassified Information // CUI Page 1 of 41

Cybersecurity Incident Response Plan

Version 1.1

ODT, PPS, SOC

CFTC

Office of Data and

Technology

February 2018 Controlled Unclassified Information // CUI Page 2 of 41

Table of Contents

1.0 Introduction

1.1 Background

1.2 Scope

1.3 Purpose

2.0 Incident Response Overview

2.1 Mission Statement

2.2 Incident Response Capability Structure

2.3 Incident Response Team Model

2.3.1 Managed Security Services Provider

2.4 Incident Declaration Criteria

2.4.1 US-CERT Reporting

2.5 Incident Response Workflow

3.0 Incident Handling Phases

3.1 Preparation

3.1.1 Preventing Incidents

3.2 Detection and Analysis

3.2.1 Attack Vectors

3.2.2 Signs of a Potential Incident

3.2.3 Incident Analysis

3.2.4 Incident Declaration

3.2.5 Evidence Gathering and Handling – Chain of Custody

3.2.6 Federal Incident Reporting Guidelines

3.2.7 Federal Agency Incident Categories

3.2.8 Incident Notification

3.3 Containment

3.4 Eradication and Recovery

3.5 Post-Incident Activity

3.5.1 Lessons Learned

3.5.2 Using Collected Incident Data for Report Metrics

4.0 Roles and Responsibilities

4.1 Employee and System Users (including contractors)

4.2 Cybersecurity Incident Response Team (CSIRT)

4.2.1 Incident Coordinator Lead or CSIRT Manager

4.2.2 Incident Handler

4.2.3 Cybersecurity Incident Response Team Member

Appendix A: Containment by Incident Type

February 2018 Controlled Unclassified Information // CUI Page 3 of 41

Appendix B: Applicable Laws, Regulations and Guidelines

Appendix C: Definitions and Acronyms

February 2018 Controlled Unclassified Information // CUI Page 4 of 41

Document Approval

February 2018 Controlled Unclassified Information // CUI Page 5 of 41

Document Change History

Date Version Revised by Change Description

2016/05/24 1.0 A. Hinnerichs Initial draft

2017/03/31 1.0 J. Christianson Final revision 1.0

2018/02/07 1.1 J. Christianson Changes required for compliance

2018/04/02 1.2 Y. Risheq Added Incident Location

2018/04/02 1.3 Y. Risheq Added Signature Page

The Cybersecurity Incident Response Plan (IRP) is available on Security Operations Center (SOC) SharePoint site were “Read-Only” access is given to authorized users only. The Cybersecurity Operations Manager approves all access to this document and has read/write access to the SharePoint site.

The Chief Information Security Officer (CISO) or Designee will be notified with any major changes to IRP. The Cybersecurity Operations Manager will have to review and update the IRP on an annual basis.

This document shall be disseminated to the following staff:

• Chief Information Officer (CIO)

• Chief Information Security Officer (CISO)

• Security Operations Center Manager

• Security Operations Center Team Members

• Need to know authorized employees/contractors

February 2018 Controlled Unclassified Information // CUI Page 6 of 41

1.0 Introduction

1.1 Background

The Federal Information Security Management Act (FISMA) of 2002 requires Federal agencies to establish incident response capabilities. The Commodity Futures Trading Commission (CFTC), Office of Data and Technology (ODT), Policy and Planning Branch must designate a primary and secondary point of contact (POC and SPOC) with US-CERT and report all incidents consistent with CFTC’s incident response policy on Responding to Incidents Involving CFTC Confidential Information and according to the Federal Incident Reporting Guidelines and Requirements (http://www.us-cert.gov/government-users/reporting-requirements). CFTC is responsible for determining specific ways in which these requirements are to be fulfilled.

In accordance with the Office of Management and Budget (OMB) memorandum 06-19, Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, dated July 12, 2006, CFTC, as a Federal government agency, is required to establish an incident response capability which includes the following actions:

• Creating an incident response plan (IRP)

• Establishing a Computer Security Incident Response Team (CSIRT) with a mission statement to support the IRP

• Developing procedures for properly identifying and performing incident handling and reporting, based on the incident response plan

• Setting guidelines for communicating with outside parties regarding incidents

• Selecting a team structure and staffing model – Computer Security Incident Response Team

(CSIRT) comprising staff from the Security Operations Center (SOC), other IT Security staff, and other ODT sections as appropriate, with one POC and one Secondary POC

• Establishing relationships between the CSIRT and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)

• Staffing the CSIRT and training the incident response handlers

• Determining what services the incident response team should provide

For the purposes of clarification in this document with regard to incident response, the CFTC consists of the following teams:

• The Computer Security Incident Response Team (CSIRT), comprised primarily with ODT staff, which handles all cyber related security incidents governed primarily by the this document, the Cybersecurity Incident Response Plan (CSIRP)

• The agency level Incident Response Team, comprised of designees for the Office of General Counsel (OGC), Human Resources Branch (HRB), the Privacy Office, and the Cybersecurity Incident Response Coordinator, which handles and is governed primarily by CFTC policy POL-OED-ESB-2, Responding to Incidents Involving CFTC Confidential Information http://www.us-cert.gov/government-users/reporting-requirements

February 2018 Controlled Unclassified Information // CUI Page 7 of 41

In addition, in accordance with CFTC policy POL-OED-ESB-2, Responding to Incidents Involving CFTC Confidential Information, CSIRT shall report all incidents involving personally identifiable information (PII) to US- CERT within one hour of discovering the incident. The CSIRT must also notify the agency’s Incident Response Team in accordance with the aforementioned policy by sending an email to the designated email address potentialincident@cftc.gov and convening a meeting to brief the agency level Incident Response Team for all potential incidents involving confidential information or PII.

1.2 Scope

A computer incident within the Federal Government as defined by NIST Special Publication 800- 61 Rev 2 “Computer Security Incident Handling Guide” is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard computer security practices. The CSIRT will handle any event which may constitute a computer crime (violations of applicable Federal and/or State laws) or any event which adversely changes the security posture of the agency or circumvents security polices developed to prevent financial loss and/or the destruction, theft, or compromise of proprietary information. These types of events include, but not limited to:

1. Loss or theft of devices or data that contain Personally Identifiable Information (PII)

2. Loss or theft or compromise of data or information protected by applicable law

3. Virus or malware attack or infection that CSC team cannot remove or handle

4. Vandalism, sabotage or unauthorized access or changes to configuration,

5. Denial of Service or Distributed Denial of Services or any unwanted disruption by an/a attacker/hacker/staff/contractor

6. Pornography /online gambling/online gaming

7. Malicious destruction or modification of data and/or information (e.g. website defacement)

8. Other type of incidents that potentially threatens the security of our computer systems, such as compromise of systems privileges (root access) or exceeding authorized access of CFTC’s information systems and/or electronic data

9. Any other cyber-criminal activities including illegal distribution of illegal software, child pornography, scamming and spamming

1.3 Purpose

The Cybersecurity Incident Response Plan (CSIRP) provides guidelines for responding and reporting security incidents that may potentially affect the ability of CFTC to conduct its mission.

The CSIRP will address:

• Any event or incident that compromises system integrity

• Any event or incident that denies access to or use of IT resources mailto:potentialincident@cftc.gov http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

February 2018 Controlled Unclassified Information // CUI Page 8 of 41

• Any event or incident that compromises the sensitivity of information stored in, processed by, or transmitted by a system

• Any adverse event that violates the computer security policies, acceptable use policies, or standard computer security practices

• The Incident Response Life Cycle Management processes

• Formation of an Incident Response Team (IRT), their roles and responsibilities

The CSIRT enables the CFTC as a Federal government agency to more effectively respond to security incidents and to mitigate or contain the damage caused by those incidents. By providing CSIRT members access to timely training, best practices, tools, and trusted communication with team members, the CSIRT can help mobilize resources to quickly respond to incidents that may affect adversely the mission of the CFTC. The CFTC Incident Response Standard Operating Procedures (SOP) provides detailed checklists for handling and reporting common incident response scenarios.

The Policies identified in this CSIRP will assist the CFTC in responding and reporting to security incidents. The CSIRP will be updated whenever there’s a need to improve the incident response process, a change in CFTC systems that may affect security, or when new regulation, directive or guidance is released from the CFTC’s upper management, National Institute of Standards and Technology (NIST), Office of Management and Budget (OMB), Department of Homeland Security (DHS), United States Congress, or any other federal Government entity with the appropriate authority.

February 2018 Controlled Unclassified Information // CUI Page 9 of 41

2.0 Incident Response Overview

2.1 Mission Statement

The CFTC CSIRT consists of trusted computer incident response members who cooperatively handle critical security incidents and promote incident prevention programs in support of CFTC information system infrastructure. The CSIRT shall:

• Establish a Cybersecurity Incident Response Plan (this document) for CFTC to prepare, to detect and analyze, to contain and recover and to document lessons learned

• Evaluate, validate, declare, respond and report cyber security incident(s)

• Lead the response to major cyber incidents affecting CFTC

• Conduct cyber security incident simulation exercises to improve the agency’s preparation and response capabilities

• Work with other teams to integrate incident responses into daily operations such as Malware

Response Process (Continuity of Operation Plan, where applicable)

• Work with law enforcement entities during cyber-crime incidents affecting CFTC, if required

• Encourage and promote the development of team member skill sets, quality security products, policies & service

• Develop and apply best computer security practices where possible

2.2 Incident Response Capability Structure

The CFTC CSIRT consists of a Point of Contact (POC) or CSIRT Team lead and a secondary or alternate POC, and a designated system level incident response point of contact. Because technical skills in system administration, network administration and intrusion detection are necessary for the incident response team’s success, periodic training as well as cross training is required and should be conducted for the team. The team will handle event or incidents by analyzing the collected data, the event logs or dashboard to determine the impact of the incident, prioritize, contain, eradicate and recover from the incident. For this reason, a POC is established. If the POC has to perform forensic/technical tasks then an alternate POC should be established or designated to collect information from the technical support staff and communicate to the stakeholders.

2.3 Incident Response Team Model

The guidance stated in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-61 Rev2, Computer Security Incident Handling Guide, identifies three categories for incident response team (IRT) models. Of the three incident response team models, CFTC has adopted the following incident response team model:

February 2018 Controlled Unclassified Information // CUI Page 10 of 41

Central Incident Response Team (CIRT) - A single incident response team handles incidents throughout CFTC. This model is effective for small organizations and for large organizations with minimal geographic diversity in terms of computing resources.

2.3.1 Managed Security Services Provider

The Policy and Planning branch of ODT currently utilizes an external Managed Security Services Provider (MSSP). The Managed Security Services enables 24x7x365 continuous security monitoring, alerting and incident response. This provides the CFTC with added protection on all devices, databases, appliances and applications being monitored by CFTC’s Security Information and Event Management (SIEM) platform, while expanding threat intelligence and reporting. Incident management, attacks, spoofing, probes, and exploits are identified, threat level assessed, and critical events escalated to CFTC’s internally staffed Security Operations Center.

All notification requirements and incident response assistance is governed by the existing Service Level Agreement for these services. A call tree and process matrix is included with the SLA’s outlining how the MSSP vendor participates as a member of the incident response process.

2.4 Incident Declaration Criteria

NIST Special Publication 800-61 Rev 2 defines an Incident as “A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” Or more generally an incident is anytime something happens that could have a negative impact on the confidentiality, integrity, or availability of data on CFTC systems. There is basically no lower boundary on what is an incident.

2.4.1 US-CERT Reporting

Agencies must report information security incidents, where the confidentiality, integrity, or availability of a federal information system of a civilian Executive Branch agency is potentially compromised, to the NCCIC/US-CERT with the required data elements, as well as any other available information, within one hour of being identified by the agency’s top-level Computer Security Incident Response Team (CSIRT), Security Operations Center (SOC), or information technology department. In some cases, it may not be feasible to have complete and validated information for the section below (Submitting Incident Notifications) prior to reporting. Agencies should provide their best estimate at the time of notification and report updated information as it becomes available. Events that have been found by the reporting agency not to impact confidentiality, integrity or availability may be reported voluntarily to US-CERT; however, they may not be included in the FISMA Annual Report to Congress.

Incident Reports to the US-CERT will contain the following information (where available):

1. Identify the current level of impact on agency functions or services (Functional Impact).

2. Identify the type of information lost, compromised, or corrupted (Information Impact).

February 2018 Controlled Unclassified Information // CUI Page 11 of 41

3. Estimate the scope of time and resources needed to recover from the incident (Recoverability).

4. Identify when the activity was first detected.

5. Identify the number of systems, records, and users impacted.

6. Identify the network location of the observed activity.

7. Identify point of contact information for additional follow-up.

Incidents reported to the US-CERT should also be reported as appropriate to ODT senior management (e.g. CISO, CIO, or designee). Reports to the US-CERT should only contain the detail necessary to perform their required monitoring functions. Further, no Personally Identifiable Information (PII) will be included in any reported information to the US-CERT.

2.5 Incident Response Workflow

The following diagram illustrates a typical Incident Response workflow, including the reporting requirements. It should be noted that in some cases, a user may choose to directly report to the CFTC SOC of an incident rather than going thru the CFTC’ Help Desk and staff.

February 2018 Controlled Unclassified Information // CUI Page 12 of 41

Figure 1: Incident Response Team Workflow

February 2018 Controlled Unclassified Information // CUI Page 13 of 41

3.0 Incident Handling Phases

The incident response process consists of several phases, from initial preparation through post-incident analysis. The initial phase involves establishing and training an incident response team, and acquiring the necessary tools and resources. During preparation, the CFTC attempts to limit the number of incidents that will occur by selecting and implementing a set of controls based on the results of risk assessments. However, residual risk will inevitably persist after controls are implemented; furthermore, no control is foolproof. Detection of security breaches is thus necessary to alert the CFTC whenever incidents occur. In keeping with the severity of the incident, the CFTC CSIRT can act to mitigate the impact of the incident by containing it and ultimately recovering from

it. In general, CSIRT prioritizes the handling of the incident based on the business impact or consequence to the CFTC’s operations and mission. Containment usually takes priority over Eradication and Recovery.

The CSIRT will establish and follow procedures basing their response on the incident assessment.

The CSIRT may create additional procedures which are not foreseen in the Incident Response Plan.

If there’s no applicable procedure in place, the CSIRT must document what was done and later establish a procedure for the incident.

After the incident is adequately handled, the CFTC CSIRT issues a report that details the cause and estimated impact of the incident and follows up with a lesson learned section to discuss the steps the CFTC should take to prevent future incidents.

The major phases of the incident response process—Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity—are described in detail in this document below. The figure below illustrates the life cycle for the incident response capability that the CFTC adopts.

Figure 2: Incident response Life Cycle

February 2018 Controlled Unclassified Information // CUI Page 14 of 41

3.1 Preparation

The Cyber Security Operations team which includes the Security Operations Center (SOC) will perform continuous monitoring activities on the different critical security controls. However, although the CFTC has implemented a set of controls based on the results of risk assessments, residual risk will inevitably persist and emerge as changes in systems and new threats/vulnerabilities are discovered.

The Customer Service Center (CSC) operates from 7:30am – 5:30pm Monday through Friday (this is based on current contract requirements). The CSC, the Cyber Security Operations team and the Network Operations team, as well as the Cyber Security Incident Response Team (which is a mix of selected staff from the above teams) will use procedures and methodologies outlined in SOPs and this document as a standard approach for handling different types of incidents.

3.1.1 Preventing Incidents

The CFTC deploys multiple layers of protection across the different attack vectors. Any gaps in coverage are brought to the Chief Information Security Officer’s (CISO) attention as soon as possible by the Security Engineering team in the Policy and Planning division of ODT or the Cyber Security Operations team. Details of the layered security controls, techniques and tools the CFTC Cyber Security Operations team deploys are not described in this document and are only briefed to individuals with a need to know

CFTC performs periodic vulnerability scans of the servers and workstations as well as real-time scans of each file as it is downloaded, opened, or executed. The antivirus software is configured to disinfect and quarantine infected files and protecting the systems from real-time virus attacks. All servers also have been configured to have the Anti-virus software to do a daily scan. Any issue will generate an alert email to the Security Administrator.

CFTC uses a Network-based Intrusion Detection/Protection System (IDS/IPS) to actively monitor the edge routers, firewalls and servers to identify if unauthorized access were attempted. Alerts are configured to monitor if an unauthorized access has occurred.

CFTC uses security portfolio of applications to monitor resources on the servers to establish baselines of server utilization, review events logs and configure alerts to be generated when there is a significant deviation from the baselines.

Aside from all the appliances and software based technical controls, there are also other management and operations controls such as Access controls, Passwords controls, and Physical Security controls. Other administrative and operations controls include separation of duties, least privileges and the need to know principles.

February 2018 Controlled Unclassified Information // CUI Page 15 of 41

3.2 Detection and Analysis

Section 3.2 provides information about detecting incidents through the use of automatic scans, intrusion detection systems (IDSs), logs, and other mechanisms.

Figure 3: Incident Response Life Cycle (Detection and Analyses)

3.2.1 Attack Vectors

Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handling every incident. The SOC team and other ODT sections should be generally prepared to handle any incident, but should also focus on being prepared to handle incidents that use common attack vectors. Different types of incidents merit different response strategies. The attack vectors listed below can be used as a basis for defining more specific handling procedures.

• External/Removable Media: An attack executed from removable media or a peripheral device-for example, malicious code spreading onto a system from an infected USB flash drive

• Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a DDoS intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, CAPTCHAS, or digital signatures)

• Web: An attack executed from a website or web-based application—for example, a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware

• Email: An attack executed via an email message or attachment—for example, exploit code disguised as an attached document or a link to a malicious website in the body of an email message to trick user to click on it (Phishing)

February 2018 Controlled Unclassified Information // CUI Page 16 of 41

• Impersonation: An attack involving replacement of something benign with something malicious—for example, spoofing, man in the middle attacks, rogue wireless access points, and broken authentication, SQL injection attacks all involve impersonation

• Improper Usage: Any incident resulting from violation of CFTC Acceptable Use or Rules of Behavior and other Security Policies by an authorized user, excluding the above categories.

For example, a user installs file sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system

• Loss or Theft of Equipment: The loss or theft of a computing device or media used by the agency, such as a laptop, smartphone, or authentication token. (Please refer to CFTC SOP- 028 Loss or Stolen Equipment handling procedures.)

• Other: An attack that does not fit into any of the other categories

Example Possible Event Description Possible Incident Type Files are missing on a workstation. Unexplained modification or deletion of data Unauthorized Access A known working password no longer works.

Inability of one or more users to log in to an account Unauthorized Access

A user receives an email message not originating from the Help Desk that requests actions to be taken to protect systems from a virus.

A virus/worm email hoax

Malicious Code

A user is unable to log in to an account.

Successful or failed attempt to compromise a user account Unauthorized Access

Unauthorized personnel are using restricted resources.

Misuse of system resources by valid users Unauthorized Access

An unusual error message is displayed on the screen.

Unexplained attempts to write to system files or changes in system files

Unauthorized Access, Malicious Code

Irregular activity occurs, such as sporadic opening of programs.

Unusual usage patterns Unauthorized Access, Malicious Code

An unknown individual solicits an employee for personal or proprietary information.

Attempts to "Social Engineer" or otherwise convince users/administrators to provide information to unauthorized parties

Other

Figure 4: Suspicious activities a User may encounter

The incident handler coordinates and determines whether the suspicious event may have been caused by a misconfiguration or some other actions. By following recommended procedures in this plan, a CSC technician or incident handler should be able to confirm that a potential security incident has occurred; the incident handler may escalate to the CSIRT after he/she has determined what type of potential security incident occurred and how many systems were affected. The CSIRT lead may then declare an incident has occurred and launch the Cybersecurity Incident Response Plan.

3.2.2 Signs of a Potential Incident

February 2018 Controlled Unclassified Information // CUI Page 17 of 41

Potential incidents may be detected through many different means, with varying levels of detail and fidelity. The CFTC’s automated detection capabilities may provide analysts with what appear to be adverse events on the network. Adverse events may also be detected through manual means, such as problems reported by users. A potential incident may only be declared an incident by the CSIRT Manager or designated SOC lead. Some incidents have overt signs that can be easily detected, whereas others are almost impossible to detect without automation.

Signs of an incident commonly referred to Indicators of Compromise (IoC) fall into one of two categories: Precursors and Indicators. A precursor is a sign that an adverse event may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. Some examples are listed below, but are not inclusive of all possible scenarios:

• The network intrusion detection sensor alerts when a buffer overflow attempt occurs

• The antivirus software alerts when it detects that a host is infected with a worm

• Finding widespread backdoor Trojans on endpoints and/or network file shares

• The Web server crashes

• Users complain of slow access to hosts on the Internet

• The system administrator sees a filename with unusual characters

• Finding system exploit code embedded in email attachments or delivered via Web pages

• The e-mail administrator sees a large number of bounced e-mails with suspicious content

• A user calls the help desk to report a threatening e-mail message

• The host records an auditing configuration change in its log

• The application logs multiple failed login attempts from an unfamiliar remote system

• Increase in elevated logons (unauthorized) late at night

• The network administrator notices an unusual deviation from typical network traffic flows such as large, unexpected flows of data from within the network – from servers to servers, server to client, client to server or network to network

• Discovering gigabytes of data appearing in places where that data should not exist

• Discovering compressed or “zipped” file using unknown encryption utilities

Some of CFTC tools that we use can detect activities that are likely to precede an incident. For example, a network IDS sensor may detect unusual port scan activity targeted at a group of hosts, which occurs shortly before a DoS attack is launched against one of the same hosts. The intrusion detection alerts regarding the scanning activity serve as a precursor of the subsequent DoS incident.

Other examples of precursors are as follows:

• Web server log entries that show the usage of a Web vulnerability scanner

• An announcement or alert from known source (e.g. US-CERT) of a new exploit that targets a vulnerability of the CFTC’s mail server

• Receiving a threat stating that a group or a person or a country will attack CFTC or government agencies

February 2018 Controlled Unclassified Information // CUI Page 18 of 41

Not every attack can be detected through precursors. Some attacks have no precursors, whereas other attacks generate precursors that the current CFTC security tools may not be able to detect. If precursors are detected, the SOC may have an opportunity to prevent the incident by altering its security posture through automated or manual means to save a target from attack such as blocking an IP address. In the most serious cases, the SOC may decide to act as if an incident is already occurring, so that the risk is mitigated quickly. At the minimum, the SOC can monitor certain activity more closely such as connection attempts to a particular host or a certain type of network traffic.

Precursors and indications are identified using many different sources with the most common being computer security software such as IDS, Antivirus and spyware software and hardware alerts, logs, available information and people.

The CFTC Cyber Security Operations team subscribes to different sources of threat intelligence, interfaces with DHS/US-CERT and other federal government agencies to share and collect these indicators of compromise (IoC).

3.2.3 Incident Analysis

When dealing with report of any event which adversely changes the security posture of the CFTC or circumvents security polices or the destruction, loss, theft, or compromise of proprietary information including a malware that can’t be removed, Incident Handler(s) should assume that an incident is occurring until they have confirmed that the threat has been neutralized. The Incident Handler should perform analysis of the incident, verify the incident did happen, prioritize and then determine the solution(s). Depending on the scope of the incident, an Incident Coordinator shall be designated to perform all coordination between different teams and writing a log of the Incident Response Process while other incident handlers will perform analysis and determine solutions.

The CSIRT is responsible for analyzing ambiguous, contradictory, and incomplete symptoms to determine what has happened.

The CSIRT should work quickly to analyze and validate each incident, documenting each step taken.

When the team believes that an incident has occurred, the team should rapidly perform an initial analysis to determine the incident’s scope, such as which networks, systems, hosts or applications are affected; who or what originated the incident; and how the incident is occurring (e.g., what tools or attack methods are being used, what vulnerabilities are being exploited). The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident. When in doubt, incident handlers from the SOC should assume the worst until additional analysis indicates otherwise. The incident handlers should use the following sections as a tool to make incident analysis easier and more effective.

3.2.3.1 Profile Networks and Systems

Profiling is measuring the characteristics of expected activity (such as baselines) so that changes to it can be more easily identified. We can simply ask question such as “what is the normal” profile (be it

February 2018 Controlled Unclassified Information // CUI Page 19 of 41 bandwidth, usage, file size, CPU cycle, etc.) Examples of profiling are running file integrity checking software on hosts to derive checksums for critical files and monitoring network bandwidth usage and host resource usage to determine what the average and peak usage levels are on various days and times. If the profiling process is automated, changes to activity can be detected and reported to administrators quickly. In practice, it is difficult to detect incidents accurately using most profiling techniques. The SOC has the ability to use profiling as one of several detection and analysis techniques.

3.2.3.2 Understand Normal Behaviors

SOC members should study networks, systems, and applications to gain a solid understanding of what their normal behavior is so that abnormal behavior can be recognized more easily. Without a solid understanding of what “usual” or “normal” is, it will be very difficult to define what “unusual” or “abnormal” is. No incident handler will have a comprehensive knowledge of all behavior throughout the environment, but handlers should know which experts or who in CFTC could fill in the gaps. Beside periodic cross-training, another way to gain this knowledge is through reviewing log entries and security alerts.

It may be tedious if filtering is not used to condense the logs to a reasonable size. As handlers become more familiar with the logs and alerts, they should be able to focus on unexplained entries, which are usually more important to investigate. Reviewing the logs also give the analyst an indication of the reliability of each source. Reviewing logs and investigating interesting entries are also good preparation for handling incidents, which requires these skills.

3.2.3.3 Use Log Data.

Information regarding an incident may be recorded in several places, such as firewall, router, network IDS, host IDS, and application logs. The incident handler(s) shall review the logs to determine if there are any abnormal activities. CFTC is using Security Information and Event Management to help the collection, storage, analysis and management of IT infrastructure event and security logs. The Cyber Security Operations team correlates these events and security logs with threat intelligence networks to make quick determinations whether specific events are malicious.

3.2.3.4 Perform Event Correlation

Evidence of an incident may be captured in several logs that are separately residing on different hosts. Each log may contain different types of data regarding the incident—a firewall log may have the source IP address that was used, whereas an application log may contain a username. Sensors may detect that an attack was launched against a particular host, but it may not know if the attack was successful. Report from user(s) may pinpoint an event that might have occurred. The analyst may need to examine the host’s logs to determine that information. Correlating events among multiple indication sources can be invaluable in validating whether a particular incident occurred, as well as rapidly consolidating the pieces of data.

February 2018 Controlled Unclassified Information // CUI Page 20 of 41

3.2.3.5 Keep All Host Clocks Synchronized.

CFTC is using Network Time Protocol (NTP) to synchronize servers and other network devices clocks with NIST atomic clock. This helps the Incident Response Team to correlate events more accurately. The SIEM presents all logs captured from the environment and displays the time in the Eastern Time zone for analytical purposes.

3.2.3.6 Maintain and Use a Knowledge Base of Information.

The SOC team shares and collaborates text documents and spreadsheets or diagrams on the SharePoint site for sharing information, knowledge and skills among team members. The collaboration site that serves as the “knowledge base” contains useful and relevant information for the SOC related to cybersecurity.

3.2.3.7 Use Internet Search Engines for Research.

The SOC will use comprehensive Internet search engines such as Google and Bing to find information on unusual activity, particularly scanning. The SOC team will also perform filters on the data so that categories of indications that tend to be insignificant are not shown to the indication analyst. Or filter indications so that only categories of indications that are of the highest significance are shown to the analyst.

3.2.3.8 Seek Assistance from Others

Occasionally, the team will be unable to determine the full cause and nature of an incident. If the team lacks sufficient information to contain and eradicate the incident, then they should consult with resources, internal (e.g., Network Operations staff) and/or external resources (e.g., US-CERT, other CSIRTs, or contractors with incident response expertise) for analysis, containment, and eradication assistance.

3.2.4 Incident Declaration

The designated incident handler coordinates and determines whether the suspicious event may have been caused by a misconfiguration or some other actions. By following standard operating procedures in this plan, a CSC technician or incident handler should be able to confirm that a potential security incident has occurred; the CSIRT incident handler may escalate to the CSIRT manager or SOC Lead after he/she has determined what type of potential security incident occurred and how many systems were affected. The Incident Coordinator, Government SOC Lead, or other designee may then declare an incident has occurred and launch the Cybersecurity Incident Response Plan.

Incidents are documented at several different levels to support management and program review.

Any event or incident that requires more than passing review by the CSIRT should be entered in the Incident Management Tool. Any event or incident that requires more than standard responses, responses outside the SOC team, or may require management review or intervention should be

February 2018 Controlled Unclassified Information // CUI Page 21 of 41 documented within the Incident Management Tool. Incidents should be reported to the US-CERT in accordance with current US-CERT / OMB requirements.

In the event of a particularly large or complex incident, it may be judicious to assign one person the role of maintaining the documentation for the incident response, separate from the individual directing the response.

3.2.5 Evidence Gathering and Handling – Chain of Custody

Any incident could potentially involve legal actions and/or involve federal law enforcement depending on the nature of the incident. All artifacts gathered as a result of the incident response process shall be preserved forensically and stored in a secured environment. If a forensically sound preservation of incident related evidence is not possible, approved alternate methods shall be employed and documented. The appropriate chain of custody documentation shall be completed for all evidence gathered and evidence handling best practices employed. The CFTC Digital Forensics Laboratory and SOC shall be the operational facility for the purposes of live or post mortem electronic evidence analysis.

3.2.6 Federal Incident Reporting Guidelines

The Cyber Security Incident Response Team (CSIRT) must notify US-CERT according to the Federal Incident Reporting Guidelines.

Depending on the criticality of the incident; it is not always feasible to gather all the information prior to reporting. In particular, within one hour, agencies must report information security incidents, where the confidentiality, integrity, or availability of CFTC information systems is potentially compromised. All incidents reported to US-CERT should contain the required elements as prescribed in the most recent US-CERT guidelines (see section 2.4.1). Use the following sections for identification within these categories.

The CFTC CSIRT adopts the following US-CERT impact, recoverability, and threat vector definitions:

3.2.6.1 Functional Impact of the Incident

Incidents targeting IT systems typically impact the business functionality that those systems provide, resulting in some type of negative impact to the users of those systems. Incident handlers should consider how the incident will impact the existing functionality of the affected systems. Incident handlers should consider not only the current functional impact of the incident, but also the likely future functional impact of the incident if it is not immediately contained. US-CERT Functional Impact Definitions:

Impact Description HIGH Organization has lost the ability to provide all critical services to all system users.

MEDIUM Organization has lost the ability to provide a critical service to a subset of system users.

February 2018 Controlled Unclassified Information // CUI Page 22 of 41

Figure 5: Functional Impact of the Incident

3.2.6.2 Information Impact of the Incident

Incidents may affect the confidentiality, integrity, and availability of the agency’s information. For example, a malicious agent may exfiltrated sensitive information. Incident handlers should consider how this information exfiltration will impact the agency’s overall mission. An incident that results in the exfiltration of sensitive information may also affect other agencies if any of the data pertained to a partner agency. US-CERT Information Impact Definitions:

Impact Description

CLASSIFIED

The confidentiality of classified information was compromised.

PROPRIETARY The confidentiality of unclassified proprietary information, such as protected critical infrastructure information (PCII), intellectual property, or trade secrets was compromised.

PRIVACY The confidentiality of personally identifiable information (PII ) or personal health information (PHI) was compromised.

INTEGRITY The necessary integrity of information was modified without authorization.

NONE No information was exfiltrated, modified, deleted, or otherwise compromised.

Figure 6: Information Impact of the Incident

3.2.6.3 Recoverability from the Incident

The size of the incident and the type of resources it affects will determine the amount of time and resources that must be spent on recovering from that incident. In some instances it is not possible to recover from an incident (e.g., if the confidentiality of sensitive information has been compromised) and it would not make sense to spend limited resources on an elongated incident handling cycle, unless that effort was directed at ensuring that a similar incident did not occur in the future. In other cases, an incident may require far more resources to handle than what CFTC has available. The CSIRT should consider the effort necessary to actually recover from an incident and carefully weigh that against the value the recovery effort will create and any requirements related to incident handling. US-CERT Recoverability Definitions:

Impact Description REGULAR Time to recovery is predictable with existing resources.

SUPPLEMENTED Time to recovery is predictable with additional resources.

EXTENDED Time to recovery is unpredictable; additional resources and outside help are needed.

NOT RECOVERABLE Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly).

LOW Organization has experienced a loss of efficiency, but can still provide all critical services to all users with minimal effect on performance.

NONE Organization has experienced no loss in ability to provide all services to all users.

February 2018 Controlled Unclassified Information // CUI Page 23 of 41

NOT APPLICABLE Incident does not require recovery.

Figure 7: Recoverability from the Incident

3.2.6.4 Threat Vector

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.

Threat Vector Description Example Unknown Cause of attack is unidentified.

This option is acceptable if cause (vector) is unknown upon initial report. The threat vector may be updated in a follow-up report.

Attrition An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services.

Denial of Service intended to impair or deny access to an application; a brute force attack against an authentication mechanism, such as passwords or digital signatures.

Web An attack executed from a website or web-based application.

Cross-site scripting attack used to steal credentials, or a redirect to a site that exploits a browser vulnerability and installs malware.

Email An attack executed via an email message or attachment.

Exploit code disguised as an attached document, or a link to a malicious website in the body of an email message.

External/ Removable Media

An attack executed from removable media or a peripheral device.

Malicious code spreading onto a system from an infected USB flash drive.

Impersonation/ Spoofing

An attack involving replacement of legitimate content/services with a malicious substitute.

Spoofing, man in the middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation.

Improper Usage Any incident resulting from violation of an organization's acceptable usage policies by an authorized user, excluding the above categories.

User installs file-sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system.

Loss or Theft of Equipment

The loss or theft of a computing device or media used by the organization.

A misplaced laptop or mobile device

Other An attack does not fit into any other vector

Figure 8: Threat Vector Examples

February 2018 Controlled Unclassified Information // CUI Page 24 of 41

3.2.7 Federal Agency Incident Categories

The taxonomy below provides a common platform to execute the US-CERT mission. CFTC is required to use the following incident and event categories and reporting timeframe criteria as described in the previous section. Note that US-CERT reporting is no longer based on the incident category, but upon determination of an impact to the confidentiality, integrity or availability of CFTC systems or data.

Category Name Description

CAT 0 Exercise/ Network Defense Testing

This category is used during state, federal, national, international exercises and approved activity testing of internal/external network defenses or responses.

CAT 1 Unauthorized Access

In this category an individual gains logical or physical access without permission to a federal agency network, system, application, data, or other resource

CAT 2 Denial of Service (DoS)

An attack that successfully prevents or impairs the normal authorized functionality of networks, systems or applications by exhausting resources. This activity includes being the victim or participating in the DoS.

CAT 3 Malicious Code

Successful installation of malicious software (e.g., virus, worm, Trojan horse, or other code-based malicious entity) that infects an operating system or application. Agencies are NOT required to report malicious logic that has been successfully quarantined by antivirus (AV) software.

CAT 4 Improper Usage A person violates acceptable computing use policies.

CAT 5

Scans/Probes/ Attempted Access

This category includes any activity that seeks to access or identify a federal agency computer, open ports, protocols, service, or any combination for later exploit. This activity does not directly result in a compromise or denial of service.

CAT 6 Investigation Unconfirmed incidents that are potentially malicious or anomalous activity deemed by the reporting entity to warrant further review.

Figure 9: Federal Agency Incident Categories

3.2.8 Incident Notification

The CSIRP provides detailed instructions for notification to executive management and the incident response team members.

3.2.8.1 Voice, text, data or email notification

During normal support hours (7am x 7pm Mon-Fri), the SOC team member will contact the appropriate person to escalate, declare, or report the status of the incident using any of the following method:

• In person or by office phone

• Mobile phone

February 2018 Controlled Unclassified Information // CUI Page 25 of 41

• Text message

• Home phone, if applicable

• Any other number the person has voluntarily listed in the emergency contact list

During non-support hours, using best effort, the SOC team member can contact the appropriate person:

• Home phone

• Mobile phone

• Text message

• Any other number the person has listed in the emergency contact list

• Any other number the person has voluntarily listed in the emergency contact list

If email is being used, the email will have a link to the investigation within the Incident Management Tool. Additionally, the email may also include the following:

1. Brief description of the incident.

2. What kinds of actions required/taken?

3. Whether Phone Tree/notification tree was activated?

4. Whether a CSIRT meeting is needed? If yes, how urgent?

5. Other information that sender/report person wants to catch the recipient’s attention.

3.2.8.2 Emergency Notification Communication Plan

ODT personnel will use processes described in the CSIRP to communicate notification of and requirements for actions for a potential incident. Response activities for incidents will be directed as High Classification.

Any potential incidents reported through any means shall result in notification to the CSIRT manager…