Incident Reporting and Response

Incident response methodologies typically emphasize preparation—not only establishing an incident response capability so that the organization is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.

Tools and resources must be prepared for a possible incident. These are intended to be a starting point for discussion about which tools and resources your organization's incident handlers need. For example, smartphones are one way to have resilient emergency communication and coordination mechanisms. An organization should have multiple (separate and different) communication and coordination mechanisms in case of failure of one mechanism.

• Incident Handler Communications and Facilities
• Incident Analysis Hardware and Software
• Incident Analysis Resources
• Incident Mitigation Software

All your organization staff have a responsibility to remain vigilant and protect the data stored within the systems we support. Any event that threatens the confidentiality, integrity, or availability of the information resources we support or utilize internally should immediately be reported to a supervisor or the Incident Response Manager if a supervisor is unavailable. Supervisors should immediately bring the incident to the attention of the IRM.

Once an anomalous activity has been reported, the IRM must determine the level of intervention required. Other members of the IRT may be required to provide input during this phase to help determine if an actual security threat exists. If it is determined that there is an active security threat or evidence of an earlier intrusion, the IRM will alert the entire IRT immediately so that the situation may be dealt with as expeditiously as possible.

Containment strategies vary based on the type of incident. For example, the strategy for containing an email-borne malware infection is quite different from that of a network-based DDoS attack. Organizations should create separate containment strategies for each major incident type, with criteria clearly documented to facilitate decision-making. Criteria for determining the appropriate strategy include:

• Potential damage to and theft of resources;
• Need for evidence preservation;
• Service availability (e.g., network connectivity, services provided to external parties);
• Time and resources needed to implement the strategy;
• Effectiveness of the strategy (e.g., partial containment, full containment);
• Duration of the solution (e.g., an emergency workaround to be removed in four hours, a temporary workaround to be removed in two weeks, permanent solution).

your organization uses an asset inventory solution to automatically collect evidence and data about all policies. The evidence collected can be exported automatically or manually, depending on the needs.

Although the primary reason for gathering evidence during an incident is to resolve the incident, it may also be needed for legal proceedings. In such cases, it is important to document how all evidence, including compromised systems, has been preserved. Evidence should be collected according to procedures that meet all applicable laws and regulations that have been developed from previous discussions with legal staff and appropriate law enforcement agencies so that any evidence can be admissible in court. Also, evidence should be accounted for at all times; whenever evidence is transferred from person to person, chain of custody forms should detail the transfer and include each party's signature. A detailed log should be kept for all evidence, including the following:

• Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) addresses, and IP addresses of a computer);
• Name, title, and phone number of each individual who collected or handled the evidence during the investigation;
• Time and date (including time zone) of each occurrence of evidence handling;
• Locations where the evidence was stored.

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 they can be remediated. For some incidents, eradication is either not necessary or is performed during recovery.

Eradication may involve such actions as:

• Conduct a detailed vulnerability assessment;
• Determine symptoms and cause related to the affected system(s);
• Strengthen the defenses surrounding the affected system(s);
• Update the Incident ticket with Eradication details.

Recovery may involve such actions as:

• Restoring systems from clean backups
• Rebuilding systems from scratch
• Replacing compromised files with clean versions
• Installing patches
• Changing passwords
• Tightening network perimeter security (e.g., firewall rulesets, boundary router access control lists).

Higher levels of system logging or network monitoring are often part of the recovery process. Once a resource is successfully attacked, it is often attacked again, or other resources within the organization are attacked similarly.

Post-Incident Review Meeting

After the conclusion of the incident, the IRM and possibly select members from the IRT will meet with management to discuss the event in detail, review response procedures, and construct a Process Improvement Plan (PIP) to prevent a reoccurrence of that or similar incidents. The compiled Incident Report constructed by the IRM will serve as a guide for this meeting.

As a whole, the group will review the presented information and will determine any weakness in the process, as well as all the appropriate actions moving forward to modify the plan, address any vulnerabilities, and establish which communication is required in case of various stakeholders.

Process Improvement Plan

The IRM will draft a Process Improvement Plan (PIP) based on the results of this meeting. The plan should discuss any applicable items necessary to prevent future incidents to the extent practicable, including cost and time frame requirements where possible. The PIP will also include a review strategy to ensure all recommendations made in the PIP are met in a timely fashion and are functioning appropriately. Areas of focus may include, but are not limited to:

• New hardware or software required
• Patch or upgrade plans
• Training plans (technical, end-users, etc.)
• Policy or procedural change recommendations
• Recommendations for changes to the Incident Response Plan
• Regional communications recommendations

Lessons Learned

Lessons learned activities should produce a set of objective and subjective data regarding each incident. Over time, the collected incident data should be useful in several capacities. The data, particularly the total hours of involvement and the cost, may be used to justify additional funding of the incident response team. A study of incident characteristics may indicate systemic security weaknesses and threats, as well as changes in incident trends. This data can be put back into the risk assessment process, ultimately leading to the selection and implementation of additional controls.

IR Tabletop

Tabletop is an IR exercise that simulates (almost real-world) security incident events to develop a high-level understanding of current cybersecurity processes, and how information, alerts, and communication traverses the environment. This exercise becomes a critical success factor in the development and maintenance of a comprehensive, integrated, and security-focused incident response plan.

The tabletop session should cover:

• Understand the role of Security and their interaction with other parts of the organization
• Understand the importance of emergency response procedures from all groups within an organization (IT, Legal, HR, Marketing)
• Provide insight into response capabilities to a Ransomware or other "real world" situation
• Discuss overall effectiveness of internal/external communications

Maintain all documentation surrounding every security incident, including all work papers, notes, meeting minutes, and other items relevant to a possible investigation.

Organizations should establish a policy for how long evidence from an incident should be retained. Most organizations choose to retain all evidence for months or years after the incident ends. The following factors should be considered during the policy creation:

• Prosecution: if the attacker may be prosecuted, evidence may need to be retained until all legal actions have been completed. In some cases, this may take several years. Furthermore, evidence that seems insignificant now may become more important in the future. For example, if an attacker can use the knowledge gathered in one attack to perform a more severe attack later, evidence from the first attack may be key to explaining how the second attack was accomplished.

• Data Retention: most organizations have data retention policies that state how long certain types of data may be kept. For example, an organization may state that email messages should be retained for only 180 days. If a disk image contains thousands of emails, the organization may not want the image to be kept for more than 180 days unless it is necessary.

• Cost: original hardware (e.g., hard drives, compromised systems) that is stored as evidence, as well as hard drives and removable media that are used to hold disk images, are generally individually inexpensive. However, if an organization stores many such components for years, the cost can be substantial. The organization must also retain functional computers that can use the stored hardware and media.

Whether notification is required, its format and its timing will be determined by IRT in cooperation with legal counsel.

For more information, see Breach Notification Procedure

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.

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 their authorized tasks. Hosts should have auditing enabled and should log significant security-related events. The security of hosts and their configurations should be continuously monitored. Many organizations use Security Content Automation Protocol (SCAP) expressed operating system and application configuration checklists to assist in securing hosts consistently and effectively.

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.

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).

User Awareness and Training

Users should be made aware of policies and procedures regarding the appropriate use of networks, systems, and applications. Applicable lessons learned from previous incidents should also be shared with users so they can see how their actions could affect the organization. Improving user awareness regarding incidents should reduce the frequency of incidents. IT staff should be trained so that they can maintain their networks, systems, and applications per the organization's security standards.

More information on awareness and training can be found in the Security Training and Awareness Policy

Cyber Security Incident

A Cyber Security Incident is any event that threatens the confidentiality, integrity, or availability of the information resources we support or utilize internally, especially sensitive information whose theft or loss may be harmful to employees, customers, partners, or the organization as a business.

Incident Response Team (IRT)

The IRT is made up of experts across different fields in the organization whose charge is to navigate the organization through a Cyber Security Incident from the initial investigation to mitigation, to post-incident review. Members include an Incident Response Manager, technical hardware and networking experts, front-end software experts, communications experts, and legal experts.

Incident Response Manager (IRM)

The IRM oversees all aspects of the Cyber Security Incident, especially the IRT. The key focuses of the IRM will be to ensure proper implementation of the procedures outlined in the Cyber Security Incident Response Plan, to keep appropriate Incident Logs throughout the incident, and to act as the key liaison between IRT experts and the organization's management team. After a Cyber Security Incident, the IRM will conduct a review of the incident and produce both an Incident Summary Report and a Process Improvement Plan.

Cyber Security Incident Log

The Cyber Security Incident Log will capture critical information about a Cyber Security Incident and the organization's response to that incident and should be maintained while the incident is in progress.

Incident Summary Report (ISR)

The ISR is a document prepared by the IRM after a Cyber Security Incident and will provide a detailed summary of the incident, including how and why it may have occurred, estimated data loss, affected parties, and impacted services. Finally, it will examine the procedures of the Cyber Security Incident Response Plan, including how the IRT followed the procedures and whether updates are required.

Process Improvement Plan (PIP)

The PIP is a document prepared by the IRM after a Cyber Security Incident and will provide recommendations for avoiding or minimizing the impact of future Cyber Security Incidents based upon the "lessons learned" from the recently-completed incident. This plan should be kept confidential for security purposes.

Incident Severity Levels

• Critical: causing business interruptions and may result in a Protected or Confidential data breach;
• Major: causing business interruptions but may not result in a data breach;
• Minor: all other incidents that are not posing any business interruptions.

Incident Classification (as per ENISA)

• Abusive Content – harmful speech, spam, harassment, child porn, sexual or violent content;
• Malicious Code – malware, rootkit, virus, worm, trojan, spyware;
• Information Gathering – scanning, sniffing, social engineering;
• Intrusion Attempts – exploiting known vulnerabilities, login attempts, 0-days, new attack signature;
• Intrusions – privileged account compromise, unprivileged account compromise, application compromise, bot;
• Availability – DoS, DDoS, sabotage, outage (no malice)
• Information Content Security – unauthorized access to information, unauthorized modification of information;
• Fraud - unauthorized use of resources, copyright, masquerade, phishing;
• Other - all incidents which do not fit in one of the given categories should be put into this class.