IR-02

No

IR-02(01)

No

IR-02(02)

No

CMS Baltimore Data Center -

EDC4

CMS Baltimore Data Center -

EDC4

CMS Baltimore Data Center -

EDC4

CMS Baltimore Data Center -

EDC4

CMS Baltimore Data Center -

EDC4

CMS Baltimore Data Center -

EDC4

CMS Baltimore Data Center -

EDC4

IR-08

No

IR-09

CMS Baltimore Data Center -

EDC4

No

IR-09(01)

No

IR-09(02)

CMS Baltimore Data Center -

EDC4

No

IR-09(03)

No

IR-09(04)

CMS Baltimore Data Center -

EDC4

No

The organization provides incident response training to information system users consistent with assigned roles and responsibilities:

a. Within [Assignment: organization- defined time period] of assuming an incident response role or responsibility;

b. When required by information system changes; and

c. [Assignment: organization-defined frequency] thereafter

The organization provides incident response training to information system users consistent with assigned roles and responsibilities:

a. Within one (1) month of assuming an incident response role or responsibility;

b. When required by information system changes; and

c. [Assignment: organization-defined frequency] thereafter

The organization tests the incident response capability for the information system:

[Assignment: organization- defined frequency] using [Assignment: organization- defined tests] to determine the incident response effectiveness and documents the results

Ensure regular practices have been implemented to prevent information security and privacy incidents. The list below taken from NIST SP 800-61 Rev. 2 provides a brief overview of some of the main recommended practices for securing networks, systems and applications.

• Risk Assessments: Periodic risk assessments of systems and applications should determine what risks are posed by combinations of threats and vulnerabilities. This should include understanding the applicable threats, including organization-specific threats. Each risk should be prioritized, and the risks can be mitigated, transferred, or accepted until a reasonable overall level of risk is reached. Another benefit of conducting risk assessments regularly is that critical resources are identified, allowing staff to emphasize monitoring and response activities for those resources

The CMS standard for risk assessment requires that the results of the risk assessment are reviewed at least annually and that the risk assessment is updated at least every three years or when a significant change occurs.

• Host Security: All hosts should be hardened appropriately using

standard configurations. In addition to keeping each host properly patched, hosts should be configured to follow the principle of least privilege, granting users only the privileges necessary for performing authorized tasks. Hosts should have auditing enabled and should log significant security-related events. The security of hosts and configurations should be continuously monitored. Many organizations use Security Content Automation Protocol (SCAP) configuration checklists to assist in securing hosts consistently and effectively.

The CMS standard requires the implementation of the latest security configuration baselines established by the HHS, U.S. Government Configuration Baselines (USGCB), and the National Checklist Program (NCP).

• Network Security: The network perimeter should be configured to deny all activity that is not expressly permitted. This includes securing all connection points, such as virtual private networks (VPNs) and dedicated connections to other organizations.

The CMS standard requires that the information system at managed interfaces denies network communications traffic by default and allows network communications traffic by exception (i.e., deny all, permit by exception).

• Malware Prevention: Software to detect and stop malware should be deployed throughout the organization. Malware protection should be deployed at the host level (e.g., server and workstation operating systems), the application server level (e.g., email server, web proxies), and the application client level (e.g., email clients, instant messaging clients). The CMS standard requires that malicious code protection mechanisms are implemented as follows:
  • Desktops: Malicious code scanning software is configured to perform critical system file scans no less often than once every twelve (12) hours and full system scans no less often than once every seventy-two (72) hours.
  • Servers (to include databases and applications): Malicious code scanning software is configured to perform critical system file scans no less often than once every twelve (12) hours and full system scans no less often than once every seventy-two (72) hours.

In addition, malicious code protection mechanisms should be updated whenever new releases are available in accordance with CMS configuration management policy and procedures. Antivirus definitions should be updated in near-real-time. Malicious code protection mechanisms should be configured to lock and quarantine malicious code and send alerts to administrators in response to malicious code detection.

• User Awareness and Training: Users should be made aware of policies and procedures regarding appropriate use of networks, systems, and applications as well as the policy and procedures for safeguarding data that is not in digital form (e.g., PII in paper form). Applicable lessons learned from previous incidents should also be shared with users to evaluate how actions taken by the user could affect the organization. Improving user awareness regarding incidents should reduce the frequency of incidents. IT staff should be trained to maintain networks, systems, and applications in accordance with the organization’s security standards. All users should be trained to protect printed hard/paper copies of data, including PII.

The CMS standard requires all general users receive security and privacy awareness training annually. The incident response training is incorporated into the annual Information Systems Security and Privacy Awareness Training. All EUA users must take the CBT Training located at CMS Information Technology Security and Privacy web page. The training must be delivered to all EUA users initially prior to account issuance and annually thereafter.

• Maintain Inventory: Maintain an accurate inventory of information system components identifying those components that store, transmit, and/or process PII. An accurate inventory facilitates the implementation of the appropriate information security and privacy controls and is critical to preventing, detecting and responding to information security incidents.

Prepare for Common Attack Vectors. The attack vectors listed below are not intended to provide definitive classification for incidents; but rather, to simply list common methods of attack, which can be used as a basis for detection:

• External/Removable Media: An attack executed from removable media or a peripheral device, for example, malicious code spreading onto a system from an infected universal serial bus (USB) flash drive.
• Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a Distributed Denial of Service (DDoS) intended to impair or deny access to a service or application; or 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.
• Impersonation: An attack involving replacement of something benign with something malicious; for example: spoofing, man in the middle attacks, rogue wireless access points, and structured query language (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; for example, a user installs file sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system.

Recognize the Signs of an Incident.  Signs of an incident fall into one of two categories: precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. Precursors and indicators are identified using many different sources, with the most common being computer security software alerts, logs, publicly available information, and people. The table below, taken from NIST SP 800-61 Rev. 2, lists common sources of precursors and indicators for each category.

Table 3: Common Sources of Precursors and Indicators

Alerts

Logs

Publicly Available Information

People

Report and Analyze the Incident. Report the incident using the procedures outlined in Section 3.5 Incident Reporting. Once reported the IMT and frontline IR responders analyze the incident. The following are recommendations taken from NIST-SP 800-61 Rev. 4 Computer Security Incident Handling Guide for making incident analysis easier and more effective:

• Profile Networks and Systems: Profiling is measuring the characteristics of expected activity so that changes to it can be more easily identified. Examples of profiling are running file integrity checking software on hosts to derive checksums for critical files and monitoring network bandwidth usage to determine what the average and peak usage levels are on various days and times. In practice, it is difficult to detect incidents accurately using most profiling techniques; organizations should use profiling as one of several detection and analysis techniques.
• Understand Normal Behaviors: Incident response team members should study networks, systems, and applications to understand what the normal behavior is so that abnormal behavior can be recognized more easily. No incident handler will have a comprehensive knowledge of all behavior throughout the environment, but handlers should know which experts could fill in the gaps. One way to gain this knowledge is through reviewing log entries and security alerts. This 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, handlers should be able to focus on unexplained entries, which are usually more important to investigate. Conducting frequent log reviews should keep the knowledge fresh, and the analyst should be able to notice trends and changes over time. The reviews also give the analyst an indication of the reliability of each source.
• Create a Log Retention Policy: Information regarding an incident may be recorded in several places, such as firewall, IDPS, and application logs. Creating and implementing a log retention policy that specifies how long log data should be maintained may be extremely helpful in analysis because older log entries may show reconnaissance activity or previous instances of similar attacks. Another reason for retaining logs is that incidents may not be discovered until days, weeks, or even months later. The length of time to maintain log data is dependent on several factors, including the organization’s data retention policies and the volume of data. See NIST SP 800-92, Guide to Computer Security Log Management for additional recommendations related to logging.
• Perform Event Correlation: Evidence of an incident may be captured in several logs that each contain different types of data, firewall log may have the source IP address that was used, whereas an application log may contain a username. A network IDPS may detect that an attack was launched against a particular host, but it may not know if the attack was successful. The analyst may need to examine the host’s logs to determine that information.

Correlating events among multiple indicator sources can be invaluable in validating whether a particular incident occurred.

• Keep All Host Clocks Synchronized: Protocols such as the Network Time Protocol (NTP) synchronize clocks among hosts. Event correlation will be more complicated if the devices reporting events have inconsistent clock settings. From an evidentiary standpoint, it is preferable to have consistent timestamps in logs, for example, to have three logs that show an attack occurred at 12:07:01 a.m., rather than logs that list the attack as occurring at 12:07:01, 12:10:35, and 11:07:06.
• Maintain and Use a Knowledge Base of Information: The knowledge base should include information that handlers need for referencing quickly during incident analysis. Although it is possible to build a knowledge base with a complex structure, a simple approach can be effective. Text documents, spreadsheets, and relatively simple databases provide effective, flexible, and searchable mechanisms for sharing data among team members. The knowledge base should also contain a variety of information, including explanations of the significance and validity of precursors and indicators, such as IDPS alerts, operating system log entries, and application error codes.
• Use Internet Search Engines for Research: Internet search engines can help analysts find information on unusual activity. For example, an analyst may see some unusual connection attempts targeting TCP port 22912. Performing a search on the terms “TCP,” “port,” and “22912” may return some hits that contain logs of similar activity or even an explanation of the significance of the port number. Note that separate workstations should be used for research to minimize the risk to the organization from conducting these searches.
• Run Packet Sniffers to Collect Additional Data: Sometimes the indicators do not record enough detail to permit the handler to understand what is occurring. If an incident is occurring over a network, the fastest way to collect the necessary data may be to have a packet sniffer capture the network traffic. Configuring the sniffer to record traffic that matches specified criteria should keep the volume of data manageable and minimize the inadvertent capture of other information. Because of privacy concerns, some organizations may require incident handlers to request and receive permission before using packet sniffers.
• Filter the Data: There is simply not enough time to review and analyze all the indicators; at minimum, the most suspicious activity should be investigated. One effective strategy is to filter out categories of indicators that tend to be insignificant. Another filtering strategy is to show only the categories of indicators that are of the highest significance; however, this approach carries substantial risk because new malicious activity may not fall into one of the chosen indicator categories.
• 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 it should consult with internal resources (e.g., information security staff) and external resources (e.g., US-CERT, other CSIRTs (Computer Security Incident Response Teams), contractors with incident response expertise). It is important to accurately determine the cause of each incident so that it can be fully contained.

Establish communication method and notify the appropriate CMS personnel. The Incident Notification Table located in the Incident Response Steps for CISO (Appendix A) is a guide on notification steps per incident type. The list below provides examples of individuals that may require notification in the event of an incident:

• CIO
• CISO
• Deputy CISO
• SOP
• HHS Office of the Inspector General (OIG)
• Local information response team within the organization
• External incident response team (if appropriate)
• System Owner
• Information System Security Owner
• System Business Owner
• System Cyber Risk Advisor
• CMS Office of Human Capital (for cases involving employees, such as harassment through email)
• CMS Office of Financial Management (in the case where extra funding is needed for investigation activities)
• CMS Office of Communications (for incidents that may generate publicity)
• CMS Office of Legislation (for incidents with potential legal ramifications)
• US-CERT (required for Federal agencies and systems operated on behalf of the Federal government).
• Individual (whose PII has been compromised)

• Lead the investigation and resolution of information security and privacy incidents and breaches across CMS.
• Once an incident has been validated, the incumbent CISO will follow the steps in the CISO Playbook which is attached as Appendix A. This playbook details the CISO’s responsibilities, the scenarios to be considered and the relevant incident response contacts during an event.

• Notify and deliver incident situation reports to CMS CISO.
• Coordinate Incident Response activities

• Coordinate/Support incident response activities with CISO.
• In the event of a PII/PHI breach, coordinate with the system Business Owner and HHS PIRT to handle notifying affected individuals
• Provide overall direction for incident handling which includes all incidents involving PII/PHI.

• Works with IMT Lead to coordinate incident response activities related to their assigned CMS information systems.
• In the event of a PII/PHI breach, coordinate with the Senior Official for Privacy and HHS PIRT to handle notifying affected individuals

• Notify IMT of incident situation
• Ensure Incident Response form has been completed as accurately as possible at the time of the initial report.

• Update the ServiceNow ticket as the situation arises and follow up with the CMS IT Helpdesk until incident has been resolved.

CCIC IMT and CCIC SOC

Analysts

CMS IT Service Desk CCIC IMT and CCIC SOC

Analysts

CMS Users

1. Requires personnel to report suspected security incidents to the organizational incident response capability within [Assignment: organization-defined time period]
2. Reports security, privacy and supply chain incident information to [Assignment: organization-defined authorities]

The organization:

1. Requires personnel to report actual or suspected security and privacy incidents to the organizational incident response capability within 1 hour of discovery/notification; and
    
2. Reports security, privacy and supply chain incident information to CMS IT Service Help Desk.

a. Incident Response Plan is reviewed and approved by [Assignment: organization- defined personnel or role];

b. Distributes copies of the incident response plan to [Assignment organization- defined incident response personnel (identified by name and/or role) and organizational elements]

c. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;

d. Communicates incident response plan changes to [Assignment: organization- defined incident response personnel (identified by name and/or by role) and organizational elements]; and Protects the incident response plan from unauthorized disclosure and modification

a. Incident Response Plan is reviewed and approved by the applicable Business Owner at least annually.

b. Distributes copies of the incident response plan to CMS CIO, CMS CISO, ISSO, CMS OIG Computer Crime Unit (CCU), All personnel within the CMS Incident Response Team, PII Breach Response Team and Operations Centers.

c. Reviewed annually updated as required

d. Communicates incident response plan changes to all stakeholders.

• Receive notification from DCTSO Director or IR Fed Lead

IMT SOP

ISPG Directors

• Does this incident potentially include a criminal element and, therefore, require notification of law enforcement? If so, engage HHS Office of the Inspector General.
• Was this incident reported to HHS Office of Civil Rights (OCR) in accordance with HIPAA and for Protected Health Information (PHI)? Refer to the OCR website for any details about the event / incident.

Obtain situational awareness of the potential incident and the likely

impact(s) on CMS data and /or CMS FISMA systems.

• Receive incident situation reports from IMT

IMT SOP

ISPG Directors System Owner

Data Guardian, ISSO, CRA

Conduct security bridge with stakeholders to review incident to obtain a greater understanding of the incident’s impacts and implications. Also,

discuss potential response needs, such as deployment of response capabilities.

• Receive incident status reports from IMT
• CISO/Deputy CISO will coordinate with IMT to ensure all stakeholders are on security bridge (e.g., SOP, OL, OA, HHS)

IMT SOP OC OL OA

ISPG Directors System Owner

Data Guardian, ISSO, CRA

• Does this incident potentially include a criminal element and, therefore, require notification of law enforcement? If so, engage HHS Office of the Inspector General.
• Does CMS have relevant experience or capabilities that it could deploy?

• OC/OL will keep the response teams apprised of public or legislative affairs matters related to the event/incident (e.g., Congressional inquiries and media monitoring)
• If communication of CMS risks or potential impacts is necessary, coordinate development of messaging and identify communication channels
• Receive impact analysis and make a decision regarding additional analysis of impacts to CMS

IMT SOP OC OL OA

ISPG Directors System Owner

Data Guardian, ISSO, CRA

Determine specific CMS impacts (e.g., PII, PHI, FTI, contracts, & other business partners) and Determine specific impacts to CMS data (e.g., PII,

PHI, FTI)

• Receive incident status reports from IMT
• Provide guidance to IR staff about cadence of status reporting
• Escalate incident to HHS leadership
• When findings are presented, consider if public and/or external communication may be appropriate (even if it is not legally necessary or required)

IMT SOP OC OL OA HHS

ISPG Directors System Owner

Data Guardian, ISSO, CRA

• In accordance with OMB M-20-04, report “major incidents” to Congress within seven days.
• When evaluating impacts to CMS systems, engage business owners and system owners (including ISSOs) and include the impacts to their environments in status reports.
• If sensitive information other than PII, PHI, or FTI (e.g., proprietary information) is at risk, consider the risk to the agency and determine appropriate next steps.

Conduct security bridge with stakeholders to review incident to obtain a greater understanding of the incident’s impacts and implications. Also,

discuss potential response needs, such as deployment of response capabilities.

• Receive incident status reports from IMT
• CISO/Deputy CISO will likely lead the meeting(s)/call(s), with

IMT SOP OC OL OA HHS

ISPG Directors System Owner

Data Guardian, ISSO, CRA

• Receive incident status reports from IMT and provide additional guidance/direction as necessary

IMT SOP OC OL OA HHS

ISPG Directors System Owner

Data Guardian, ISSO, CRA

Monitor event/incident to assess changes in risk to CMS systems and/or data

• If changes in risk to CMS systems and/or data are evident, go to Step 2A

• Receive incident status reports from IMT and provide counsel to leadership and response teams as appropriate
• OC/OL: Determine if monitoring of media and Congressional sources is necessary, and communicate requests or news to leadership and response teams. Coordinate requests for information or messages that may need to be communicated externally

IMT SOP OC OL OA HHS

ISPG Directors System Owner

Data Guardian, ISSO, CRA

• Participate in IMT-led lessons learned development process and inform recommendations
• Review lessons learned and submit to business & system owners
• Review and support POA&Ms as required

IMT SOP

ISPG Directors System Owner

Data Guardian, ISSO, CRA

• Review final Security Incident Report (SIR)
• Report closure of incident as appropriate/necessary

IMT SOP

ISPG Directors System Owner

Data Guardian, ISSO, CRA

• IMT
• HHS CSIRC
• CIO
• CISO
• SOP
• Deputy CISO

• CMS IT Service Desk notifies IMT of an incident
• CMS incident tickets are mirrored in the HHS Archer, which notifies HHS CSIRC

• SO
• BO
• ISSO
• DG
• CRA
• US-CERT

• IMT alerts CMS Personnel.
• HHS CSIRC handles US- CERT reporting.

• ISPG (to convene Breach Analysis Team)
• Individuals affected by PII/PHI compromise
• HHS PIRT

• IMT alerts ISPG of suspected breach
• CMS SOP and BO create a notification plan for affected individuals, subject to review by HHS PIRT

• HHS OCR
• Media outlets, as appropriate

The following key terms and definitions relate to incident response:

Administrative Vulnerability: An administrative vulnerability is a security weakness caused by incorrect or inadequate implementation of a system’s existing security features by the system administrator, security officer, or users. An administrative vulnerability is not the result of a design deficiency. It is characterized by the fact that the full correction of the vulnerability is possible through a change in the implementation of the system or the establishment of a special administrative or security procedure for the system administrators and users. Poor passwords and inadequately maintained systems are the leading causes of this type of vulnerability.

Breach: A breach is an incident that poses a reasonable risk of harm to the applicable individuals. For the purposes of Office of Management and Budget (OMB) OMB M-17-12 (for PII incidents) and Health Information Technology for Economic and Clinical Health (HITECH) Act (for PHI incidents) reporting requirements, a privacy incident does not rise to the level of a breach until it has been determined that the use or disclosure of the protected information compromises the security or privacy of the protected individual(s) and poses a reasonable risk of harm to the applicable individuals. For any CMS privacy incident, the determination of whether it may rise to the level of a breach is made (exclusively) by the CMS Breach Analysis Team (BAT), which determines whether the privacy incident poses a significant risk of financial, reputational, or other harm to the individual(s).

Event: An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt. Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data.

Federal Tax Information (FTI): Generally, Federal Tax Returns and return information are confidential,

as required by Internal Revenue Code (IRC) Section 6103. The information is used by the Internal Revenue Service (IRS) is considered FTI and ensure that agencies, bodies, and commissions are

maintaining appropriate safeguards to protect the information confidentiality. [IRS 1075] Tax return information that is not provided by the IRS falls under PII.

Incident Response: Incident response outlines steps for reporting incidents and lists actions to be taken to resolve information systems security and privacy related incidents.  Handling an incident entails forming a team with the necessary technical capabilities to resolve an incident, engaging the appropriate personnel to aid in the resolution and reporting of such incidents to the proper authorities as required, and report closeout after an incident has been resolved.

Privacy Incident: A Privacy Incident is a Security Incident that involves Personally Identifiable Information (PII) or Protected Health Information (PHI), or Federal Tax Information (FTI) where there is a loss of control, compromise, unauthorized disclosure, unauthorized acquisition, unauthorized access, or any similar term referring to situations where persons other than authorized users or any other than authorized purposes. Users must have access or potential access to PII, PHI and/or FTI in usable form whether physical or electronic.

Privacy incident scenarios include, but are not limited to:

• Loss of federal, contractor, or personal electronic devices that store PII, PHI and/or FTI affiliated with CMS activities (i.e., laptops, cell phones that can store data, disks, thumb-drives, flash drives, compact disks, etc.)
• Loss of hard copy documents containing PII, PHI and/or FTI
• Sharing paper or electronic documents containing PII, PHI and/or FTI with individuals who are not authorized to access it
• Accessing paper or electronic documents containing PII, PHI and/or FTI without authorization or for reasons not related to job performance
• Emailing or faxing documents containing PII, PHI and/or FTI to inappropriate recipients, whether intentionally or unintentionally
• Posting PII, PHI and/or FTI, whether intentionally or unintentionally, to a public website
• Mailing hard copy documents containing PII, PHI and/or FTI to the incorrect address
• Leaving documents containing PII, PHI and/or FTI exposed in an area where individuals without approved access could read, copy, or move for future use

Security Incident: In accordance with NIST SP 800-61 Revision 2, Computer Security Incident Handling Guide, a Security Incident is defined as an event that meets one or more of the following criteria:

• The successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in any information system processing information on behalf of CMS. It also means the loss of data through theft or device misplacement, loss or misplacement of hardcopy documents and misrouting of mail, all of which may have the potential to put CMS data at risk of unauthorized access, use, disclosure, modification, or destruction
• An occurrence that jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits
• A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices

Technical Vulnerability: A technical vulnerability is a hardware, firmware, or software weakness or design deficiency that leaves a system open to potential exploitation, either externally or internally, thus increasing the risk of compromise, alteration of information, or denial of service.

<Insert the roles and responsibilities associated with this plan. Possible roles include:

• Business Owners:
• Information System Owner(s)
• Cyber Risk Advisors (CRA)
• Information System Security Officer (i.e., ISSO)
• CCIC Incident Management Team (i.e., CCIC IMT)

For a detailed description of the responsibilities associated with these role please refer to the CMS IS2P2 located at: https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2

• Data Destruction or Corruption: The loss of data integrity can take many forms including changing permissions on files making the files writable by non-privileged users, deleting data files and or programs, changing audit files to cover-up an intrusion, changing configuration files that determine how and what data is stored and ingesting information from other sources that may be corrupt
• Data Compromise and Data Spills: Data compromise is the exposure of information to a person not authorized to access that information either through clearance level or formal authorization. This could happen when a person accesses a system not authorized to access or through a data spill. Data spill is the release of information to another system or person not authorized to access that information, even though the person is authorized to access the system on which the data was released. This can occur through the loss of control, improper storage, improper classification, or improper escorting of media, computer equipment (with memory), and computer generated output
• Malicious Software (Malware): Malicious code is software based attacks used by crackers/hackers to gain privileges, capture passwords, and/or modify audit logs to exclude unauthorized activity. Malicious code is particularly troublesome in that it is typically written to masquerade its presence and, thus, is often difficult to detect. Self-replicating malicious code such as viruses and worms can replicate rapidly, thereby making containment an especially difficult problem. The following is a brief listing of various software attacks:
  1. Virus: It is propagated via a triggering mechanism (e.g., event time) with a mission (e.g., delete files, corrupt data, send data).
  2. Worm: An unwanted, self-replicating autonomous process (or set of processes) that penetrates computers using automated hacking techniques.
  3. Trojan Horse: A useful and innocent program containing additional hidden code that allows unauthorized computer network exploitation (CNE), falsification, or destruction of data.

1. Spyware: Surreptitiously installed malicious software that is intended to track and report the usage of a target system or collect other data the author wishes to obtain.
2. Rootkit Software: Software that is intended to take full or partial control of a system at the lowest levels. Contamination is defined as inappropriate introduction of data into a system.
3. Privileged User Misuse: Privileged user misuse occurs when a trusted user or operator attempts to damage the system or compromise the information it contains.
4. Security Support Structure Configuration Modification: Software, hardware and system configurations contributing to the Security Support Structure (SSS) are controlled. SSS’ are essential to maintaining the security policies of the system Unauthorized modifications to these configurations can increase the risk to the system.

Note: These categories of incidents are not necessarily mutually exclusive.

• Malicious Code: Malicious code is software or firmware intentionally inserted into an information system for an unauthorized purpose
• System Failures: Procedures Failures or Improper Acts. A secure operating environment depends upon proper operation and use of systems. Failure to comply with established procedures, or errors/limitations in the procedures for a CMS system, can damage CMS reputation and increase vulnerability/risk to the system or application. While advances in computer technology enable the building of increased security into the CMS architecture, much still depends upon the people operating and using the system(s). Improper acts may be differentiated from insider attack according to intent. With improper acts, someone may knowingly violate policy and procedures, but is not intending to damage the system or compromise the information it contains
• Intrusions or Break-Ins: An intrusion or break-in is entry into and use of a system by an unauthorized individual
• Insider Attack: Insider attacks can provide the greatest risk. In an insider attack, a trusted user or operator attempts to damage the system or compromise the information it contains

As with any information system, attacks can originate through certain avenues or routes. An attack avenue is a path or means by which an attacker can gain access to a computer or network server in order to deliver a payload or malicious outcome. Attack avenues enable attackers to exploit system vulnerabilities, including the human element. If a system were locked in a vault with security personnel surrounding it, and if the system were not connected to any other system or network, there would be virtually no avenue of attack. However, there are numerous avenues of attack.

• Local and/or partner networks
• Unauthorized devices (including non-approved connections to a local network)
• Gateways to outside networks
• Communications devices
• Shared disks
• Removable media
• Downloaded software
• Direct physical access

One of the major concerns of a verifiable computer security attack is that sensitive PII is compromised. The release of sensitive information to people without the proper need-to-know or formal authorization jeopardizes the tenant of Confidentiality, Integrity and Availability (CIA). In addition, users may lose trust in computing systems and become hesitant to use one that has a high frequency of incidents or even a high frequency of events that cause the user to distrust the integrity of the federal system. Moreover, users become disenfranchised with any action that causes all or part of the network’s service to be stopped entirely, interrupted, or degraded sufficiently to impact operations; as with a DoS attack. The list of impacts from attacks that compromise computer security include:

• Denial of Service
• Loss or Alteration of Data or Programs
• Privacy Incident, including those resulting in identity theft or data breach
• Loss of Trust in Computing Systems
• The loss of intellectual property and CMS confidential information
• Reputational damage to the organization
• The additional cost of securing networks, insurance, and recovery from attacks

Preparation ensures that the organization is ready to respond to incidents, but can also prevent incidents by ensuring that systems, networks, and applications are sufficiently secure. The following describes the techniques utilized by the <system name> and to prepare for security and privacy incidents.

<Describe the activities and methods in place for the information system to prepare for information security incidents. Examples of preparation methods are, implementing incident response tools, establishing security baselines, and running periodic announced training and/or unannounced drills. For additional information on preparation activities please review Section 3.3.1 Preparation of the CMS RMH Chapter 8 Incident Response.>

<Describe how incidents involving PII are to be handled, including the policies and procedures that have been developed and how those policies and procedures are communicated to the staff. Staff should be informed of the consequences of their actions for inappropriate use and handling of PII. Describe how it is determined that the existing processes are adequate and that staff understand their responsibilities. Describe how suspected or known incidents involving PII are reported to the business owner, information system owner, CRA, ISSO, and CCIC IMT. Describe what information needs to be reported, and to whom.>

Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handling every incident. Organizations should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors. Different types of incidents merit different response strategies. The following section describes the techniques utilized by the <system name> to detect and analyze security incidents

<Describe the activities and methods in place for the information system to detect and analyze for information security incidents. Examples of detection and analysis methods are, prepare for common attack vectors, recognize the signs of an incident, and document and prioritize the incident. For additional information on preparation, activities please review Section 3.3.2 Detection and Analysis of the CMS RMH Chapter 8 Incident Response.>

<Describe the activities and methods in place to detect and analyze incidents involving PII that are the responsibility of the information staff. Describe how it is ensured that the analysis process includes an evaluation of whether an incident involved PII, focusing on both known and suspected breaches of PII. Detection of an incident involving PII also requires reporting internally, to US-CERT, and externally, as appropriate; this is a CCIC IMT responsibility.>

Containment

Containment is important before an incident overwhelms resources or increases damage. Most incidents require containment, so that is an important consideration early in the course of handling each incident. Containment provides time for developing a tailored remediation strategy. An essential part of containment is decision-making. Such decisions are much easier to make if there are predetermined strategies and procedures for containing the incident. The following section describes the containment strategies and procedures for the <system name>:

<Describe the strategies and procedures in place for the information system to contain information security incidents. Examples of containment strategies are, shut down a system, disconnect it from a network, and/or disable certain functions. For additional information on Containment activities, review Section 3.3.3 Containment, Eradication and Recovery of the CMS RMH Chapter 8 Incident Response.>

<Describe the strategies and procedures in place for containing incidents involving PII.>

After an incident has been contained, eradication may be necessary to eliminate components of the incident, such as deleting malware and disabling breached user accounts, as well as identifying and mitigating all vulnerabilities that were exploited. During eradication, it is important to identify all affected hosts within the organization so that the hosts can be remediated. For some incidents, eradication is either not necessary or is performed during recovery.

<Describe the activities and methods in place for the information system to eradicate and recover from information security incidents. Examples methods for eradication are delete malware, disable breached accounts, identify and mitigate vulnerabilities that were exploited. Examples activities associated with recovering from information security incidents are restore systems to normal operation, confirm that systems are functioning normally, and remediate vulnerabilities to prevent similar incidents. For additional information on Eradication and Recovery activities review Section 3.3.3 Containment, Eradication and Recovery of the CMS RMH Chapter 8 Incident Response.>

<Describe if media sanitization steps are performed when PII needs to be deleted from media during recovery. PII should not be sanitized until a determination has been made about whether the PII must be preserved as evidence. Describe if forensics techniques are needed to ensure preservation of evidence. If PII was accessed, how is it determined how many records or individuals were affected. These activities should be coordinated with the CCIC IMT.>

After an incident has been eradicated and recovery completed, each incident response team should evolve to reflect upon new threats, improve technology, and document lessons learned. Holding a lessons learned meeting with all involved parties after a major incident, and optionally after lesser incidents, can be extremely helpful in improving information security measures and the incident handling process.

<Describe the activities and methods in place for the information system to conduct post-incident activity after information security incidents. Examples methods for post-incident activity are: to conduct a lesson learned meeting, document the lessons learned, update the IRP and associated procedures as necessary, and ensure evidence is retained and archived. For additional information on post-incident activity review Post-Incident Activity of the CMS RMH Chapter 8 Incident Response.>

<Describe the activities and methods in place to conduct post-incident activity after incidents involving PII. This should include how the IRP is continually updated and improved based on the lessons learned during each incident. Sharing information within CMS and US-CERT to help protect against future incidents is a CCIC responsibility.>

Business Owner

<insert name>

<insert email>

<insert phone>

CMS IT Service Desk

<insert name>

<insert email>

<insert phone>

Cybersecurity Risk Advisor (CRA)

<insert name>

<insert email>

<insert phone>

Data Guardian

<insert name>

<insert email>

<insert phone>
 

Incident Management Team

<insert name>

<insert email>

<insert phone>

Incident Responders

<insert name>

<insert email>

<insert phone>

Information System Security Officer (ISSO)

<insert name>

<insert email>

<insert phone>

System Administrators

<insert name>

<insert email>

<insert phone>

System Developers

<insert name>

<insert email>

<insert phone>

Business Owner (BO)
<insert signature>

<insert name>

<insert title>

<insert email>

<insert phone>

Information System Security Officer (ISSO)

<insert signature>

<insert name>

<insert title>

<insert email>

<insert phone>

<Insert a list of questions regarding the scenario that address the exercise objective.  Below are sample questions taken from NIST Special Publication 800-61 Computer Security Incident Handling Guide>

Preparation:

1. Would the organization consider this activity to be an incident?  If so, which of the organization’s policies does this activity violate?
2. What measures are in place to attempt to prevent this type of incident from occurring or to limit its impact?

Detection and Analysis:

1. What precursors of the incident, if any, might the organization detect?  Would any precursors cause the organization to take action before the incident occurred?
2. What indicators of the incident might the organization detect?  Which indicators would cause someone to think that an incident might have occurred?
3. What additional tools might be needed to detect this particular incident?
4. How would the incident response team analyze and validate this incident?  What personnel would be involved in the analysis and validation process?
5. To which people and groups within the organization would the team report the incident?
6. How would the team prioritize the handling of this incident?

Containment, Eradication, and Recovery:

1. What strategy should the organization take to contain the incident?  Why is this strategy preferable to others?
2. What could happen if the incident were not contained?
3. What additional tools might be needed to respond to this particular incident?
4. Which personnel would be involved in the containment, eradication, and/or recovery processes?
5. What sources of evidence, if any, should the organization acquire?  How would the evidence be acquired?  Where would it be stored?  How long should it be retained?

Post-Incident Activity:

1. Who would attend the lessons learned meeting regarding this incident?
2. What could be done to prevent similar incidents from occurring in the future?
3. What could be done to improve detection of similar incidents?

General Questions:

1. How many incident response team members would participate in handling this incident?
2. Besides the incident response team, what groups within the organization would be involved in handling this incident?
3. To which external parties would the team report the incident?  When would each report occur?
4. How would each report be made?  What information would you report or not report, and why?
5. What other communications with external parties may occur?
6. What tools and resources would the team use in handling this incident?
7. What aspects of the handling would have been different if the incident had occurred at a different day and time (on-hours versus off-hours)?
8. What aspects of the handling would have been different if the incident had occurred at a different physical location (onsite versus offsite)?

• Introductions
• Review Exercise Scope and Logistics
• Scenario Walk-Through & review of test questions (Exercise Facilitator)
• Data Collector records observations (on-going)
• Conduct exercise debrief/hotwash
• Exercise Participants released
• Complete After-Action Report (Exercise Facilitator & Data Collector only)

• The organization should consider developing a communications plan that establishes standardized communications requirements, addresses how stolen documents will be investigated, and describes procedures for personnel incident response team working with organizations to investigate breaches.
• The organization should identify weaknesses in the incident handling plan and procedures to ensure that all essential personnel can be contacted in the event of sensitive document breach.

• The agency should examine the criteria for ALL personnel having access to sensitive organization documents.  In addition, all personnel might need to attend a security training and awareness course on how to report incidents or suspicious activities.

On a Saturday afternoon, external users start having problems accessing the organization’s public websites. Over the next hour, the problem worsens to the point where nearly every access attempt fails. Meanwhile, a member of the organization’s networking staff responds to alerts from an Internet border router and determines that the organization’s Internet bandwidth is being consumed by an unusually large volume of User Datagram Protocol (UDP) packets to and from both the organization’s public DNS servers. Analysis of the traffic shows that the DNS servers are receiving high volumes of requests from a single external IP address. Also, all the DNS requests from that address come from the same source port.

The following are additional questions for this scenario:

1. Whom should the organization contact regarding the external IP address in question?
2. Suppose that after the initial containment measures were put in place, the network administrators detected that nine internal hosts were also attempting the same unusual requests to the DNS server. How would that affect the handling of this incident?
3. Suppose that two of the nine internal hosts disconnected from the network before their system owners were identified. How would the system owners be identified?

On a Tuesday morning, a new worm is released; it spreads itself through removable media, and it can copy itself to open Windows shares. When the worm infects a host, it installs a DDoS agent. The organization has already incurred widespread infections before antivirus signatures become available several hours after the worm started to spread.

The following are additional questions for this scenario:

1. How would the incident response team identify all infected hosts?
2. How would the organization attempt to prevent the worm from entering the organization before antivirus signatures were released?
3. How would the organization attempt to prevent the worm from being spread by infected hosts before antivirus signatures were released?
4. Would the organization attempt to patch all vulnerable machines? If so, how would this be done?
5. How would the handling of this incident change if infected hosts that had received the DDoS agent had been configured to attack another organization’s website the next morning?
6. How would the handling of this incident change if one or more of the infected hosts contained sensitive personally identifiable information regarding the organization’s employees?
7. How would the incident response team keep the organization’s users informed about the status of the incident?
8. What additional measures would the team perform for hosts that are not currently connected to the network (e.g., staff members on vacation, offsite employees who connect occasionally)?

On a Monday morning, the organization’s legal department receives a call from the Federal Bureau of Investigation (FBI) regarding some suspicious activity involving the organization’s systems. Later that day, an FBI agent meets with members of management and the legal department to discuss the activity. The FBI has been investigating activity involving public posting of sensitive government documents, and some of the documents reportedly belong to the organization. The agent asks for the organization’s assistance, and management asks for the incident response team’s assistance in acquiring the necessary evidence to determine if these documents are legitimate or not and how they might have been leaked.

The following are additional questions for this scenario:

1. From what sources might the incident response team gather evidence?
2. What would the team do to keep the investigation confidential?
3. How would the handling of this incident change if the team identified an internal host responsible for the leaks?
4. How would the handling of this incident change if the team found a rootkit installed on the internal host responsible for the leaks?

On a Tuesday night, a database administrator performs some off-hours maintenance on several production database servers. The administrator notices some unfamiliar and unusual directory names on one of the servers. After reviewing the directory listings and viewing some of the files, the administrator concludes that the server has been attacked and calls the incident response team for assistance. The team’s investigation determines that the attacker successfully gained root access to the server six weeks ago.

The following are additional questions for this scenario:

1. What sources might the team use to determine when the compromise had occurred?
2. How would the handling of this incident change if the team found that the database server had been running a packet sniffer and capturing passwords from the network?
3. How would the handling of this incident change if the team found that the server was running a process that would copy a database containing sensitive customer information (including personally identifiable information) each night and transfer it to an external address?
4. How would the handling of this incident change if the team discovered a rootkit on the server?

On a Sunday night, one of the organization’s network intrusion detection sensors alerts on anomalous outbound network activity involving large file transfers. The intrusion analyst reviews the alerts; it appears that thousands of .RAR files are being copied from an internal host to an external host, and the external host is located in another country. The analyst contacts the incident response team so that it can investigate the activity further. The team is unable to see what the .RAR files hold because their contents are encrypted. Analysis of the internal host containing the .RAR files shows signs of a bot installation.

The following are additional questions for this scenario:

1. How would the team determine what was most likely inside the .RAR files? Which other teams might assist the incident response team?
2. If the incident response team determined that the initial compromise had been performed through a wireless network card in the internal host, how would the team further investigate this activity?
3. If the incident response team determined that the internal host was being used to stage sensitive files from other hosts within the enterprise, how would the team further investigate this activity?

On a Wednesday evening, the organization’s physical security team receives a call from a payroll administrator who saw an unknown person leave her office, run down the hallway, and exit the building. The administrator had left her workstation unlocked and unattended for only a few minutes. The payroll program is still logged in and on the main menu, as it was when she left it, but the administrator notices that the mouse appears to have been moved. The incident response team has been asked to acquire evidence related to the incident and to determine what actions were performed.

The following are additional questions for this scenario:

1. How would the team determine what actions had been performed?
2. How would the handling of this incident differ if the payroll administrator had recognized the person leaving her office as a former payroll department employee?
3. How would the handling of this incident differ if the team had reason to believe that the person was a current employee?
4. How would the handling of this incident differ if the physical security team determined that the person had used social engineering techniques to gain physical access to the building?
5. How would the handling of this incident differ if logs from the previous week showed an unusually large number of failed remote login attempts using the payroll administrator’s user ID?
6. How would the handling of this incident differ if the incident response team discovered that a keystroke logger was installed on the computer two weeks earlier?

On a Thursday afternoon, a network intrusion detection sensor records vulnerability scanning activity directed at internal hosts that is being generated by an internal IP address. Because the intrusion detection analyst is unaware of any authorized, scheduled vulnerability scanning activity, she reports the activity to the incident response team. When the team begins the analysis, it discovers that the activity has stopped and that there is no longer a host using the IP address.

The following are additional questions for this scenario:

1. What data sources might contain information regarding the identity of the vulnerability scanning host?
2. How would the team identify who had been performing the vulnerability scans?
3. How would the handling of this incident differ if the vulnerability scanning were directed at the organization’s most critical hosts?
4. How would the handling of this incident differ if the vulnerability scanning were directed at external hosts?
5. How would the handling of this incident differ if the internal IP address was associated with the organization’s wireless guest network?
6. How would the handling of this incident differ if the physical security staff discovered that someone had broken into the facility half an hour before the vulnerability scanning occurred?

On a Saturday night, network intrusion detection software records an inbound connection originating from a watchlist IP address. The intrusion detection analyst determines that the connection is being made to the organization’s VPN server and contacts the incident response team. The team reviews the intrusion detection, firewall, and VPN server logs and identifies the user ID that was authenticated for the session and the name of the user associated with the user ID.

The following are additional questions for this scenario:

1. What should the team’s next step be (e.g., calling the user at home, disabling the user ID, disconnecting the VPN session)? Why should this step be performed first? What step should be performed second?
2. How would the handling of this incident differ if the external IP address belonged to an open proxy?
3. How would the handling of this incident differ if the ID had been used to initiate VPN connections from several external IP addresses without the knowledge of the user?
4. Suppose that the identified user’s computer had become compromised by a game containing a Trojan horse that was downloaded by a family member. How would this affect the team’s analysis of the incident? How would this affect evidence gathering and handling? What should the team do in terms of eradicating the incident from the user’s computer?
5. Suppose that the user installed antivirus software and determined that the Trojan horse had included a keystroke logger. How would this affect the handling of the incident? How would this affect the handling of the incident if the user were a system administrator? How would this affect the handling of the incident if the user were a high-ranking executive in the organization?

On a Thursday afternoon, 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.

The following are additional questions for this scenario:

1. What should the incident response team do differently, if anything, in response to the notification of the threats?
2. What impact could heightened physical security controls have on the team’s responses to incidents?

The organization prohibits the use of peer-to-peer file sharing services. The organization’s network intrusion detection sensors have signatures enabled that can detect the usage of several popular peer-to-peer 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.

1. What factors should be used to prioritize the handling of this incident (e.g., the apparent content of the files that are being shared)?
2. What privacy considerations may impact the handling of this incident?
3. How would the handling of this incident differ if the computer performing peer-to-peer file sharing also contains sensitive personally identifiable information?

On a Monday morning, the organization’s help desk receives calls from three users on the same floor of a building who state that they are having problems with their wireless access. A network administrator who is asked to assist in resolving the problem brings a laptop with wireless access to the users’ floor. As he views his wireless networking configuration, he notices that there is a new access point listed as being available. He checks with his teammates and determines that this access point was not deployed by his team, so that it is most likely a rogue access point that was established without permission.

1. What should be the first major step in handling this incident (e.g., physically finding the rogue access point, logically attaching to the access point)?
2. What is the fastest way to locate the access point? What is the most covert way to locate the access point?
3. How would the handling of this incident differ if the access point had been deployed by an external party (e.g., contractor) temporarily working at the organization’s office?
4. How would the handling of this incident differ if an intrusion detection analyst reported signs of suspicious activity involving some of the workstations on the same floor of the building?
5. How would the handling of this incident differ if the access point had been removed while the team was still attempting to physically locate it?