Incident Management Homework Help

Kelly School of Business
Indiana University
Information Systems Graduate Programs

Incident

• The word “incident” could mean different things to different organizations. So the first step for an organization is to define the meaning of an “incident”.
• NIST defines an ‘event’ as “any observable occurrence in a system or network.” E.g. a user connecting to a file share, firewall blocking a connection attempt, etc.
• Adverse events are events with a negative consequence.
• NIST defines an ‘incident’ as “a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.”
• An “event” becomes an “incident” when the consequences of that event are significant in the organizational context.

NIST: Computer Security: Incident Handling Guide

Types of security related incidents

Ponemon Institute: 2014 Cost of Data Breach Study: Global Analysis

Average Cost of Data Breaches per Incident

Measured in $ (millions)

Ponemon Institute: 2014 Cost of Data Breach Study: Global Analysis

Common Attack Vectors for Incidents

• External/Removable media (e.g., flash drive, CD) or a peripheral device
• Attrition or brute force methods to compromise, degrade, or destroy systems, networks, or services
• Attacks from a website or web-based application
• Attack executed via an email message or attachment
• Violation of an organization’s acceptable usage policies by an authorized user
• Loss or theft of a computing device or media used by the organization

NIST: Computer Security: Incident Handling Guide

Need for Incident Response

• Responses to incidents require a consistent incident handling methodology, so that the appropriate actions are taken every time
• Minimizes loss or theft of information and disruption of services
• Information gained during incident handling can better prepare the organization for handling future incidents and to provide stronger protection for systems and data
• Helps to deal with legal issues that may arise during incidents
• Supports compliance with law, regulations, and policy directing a coordinated, effective defense against information security threats

Handling an Incident

Preparation – Prevention of Incidents

Although incident response teams are generally not responsible for securing resources, they can be advocates of sound security practices. Some recommended practices for preventing incidents by securing networks, systems, and applications are:

• Risk Assessments
• Host Security: All hosts should be hardened appropriately using standard configurations
• Network Security: The network perimeter should be configured to deny all activity that is not expressly permitted, includes securing all connection points, VPNs, and dedicated connections to other organizations. Includes firewalls and Intrusion Prevention Systems (IPS)
• Malware Prevention: Software to detect and stop malware should be deployed throughout the organization at the host, application server and application client levels User Awareness and Training

Preparation – Getting Ready for Incidents

Preparation involves establishing the capability to respond to incidents and preventing incidents. Some facilities and tools for incident response are:

• Incident Handler Communications and Facilities: Contact information, reporting mechanisms, issue tracking system, smartphones, encryption software for communicating within the team, war room, secure storage facility for securing evidence and other sensitive materials
• Incident Analysis Hardware and Software: Digital forensic workstations, backup devices, laptops, spare workstations, servers, networking equipment, packet sniffers, protocol analyzers, digital forensic software
• Incident Analysis Resources: Port lists, application and OS documentation, network diagrams, lists of critical assets current baselines of expected network, system, and application activity; cryptographic hashes of critical files
• Incident Mitigation Software: Access to images of clean OS and application installations for restoration and recovery purposes

Detection and Analysis - Detection

The various stages of detection and analysis are:

• Identifying signs of an incident:
• Precursor is a sign that an incident may occur in the future
• Indicator is a sign that an incident may have occurred or may be occurring now
• Identifying sources of precursors and indicators

Intrusion Detection and Prevention Systems

IDS Management

• Types
• Network IDS (NIDS)
• Host-based IDS (HIDS)
• IDS requires expert administration and overall management of the solution
• Employ technically competent administrator
• Update system periodically
• Be aware that IDS itself may be vulnerable to attack
• Intruders may try to disable IDS or overload the system
• Attacks on IDS may be a distraction for another attack

IDS Analysis Engine Methods

• Anomaly Detection
• Pattern matching IDS
• Stateful matching IDS
• Anomaly-based engine
• Statistical Anomaly-based IDS
• Protocol Anomaly-based IDS
• Traffic Anomaly-based IDS

Security Event Information Management (SEIM)

• System and audit logs provide valuable information on the operation of systems
• However they do not provide a view into events that may be affecting multiple systems or where multiple systems have some information that may be required to detect an incident and track it back to its sources
• SEIM solutions provide a common platform for log collection, collation, and analysis in real time to allow for effective and efficient responses
• They can also provide reports on historical events using log information from multiple sources

Detection and Analysis - Analysis

• Incident Analysis is difficult to perform reliably. The following list can be used to perform easier and effective analysis:
• Profile Networks and Systems to measure characteristics of expected activity
• Understand Normal System Behaviors so that abnormal behavior can be recognized more easily
• Create a Log Retention Policy to decide how long should log data be maintained
• Perform Event Correlation among multiple indicator sources to validate an incident’s occurrence
• Keep All Host Clocks Synchronized for consistent timestamps in logs for analysis and retention
• Maintain and Use a Knowledge Base of Information that handlers can refer to quickly during incident analysis
• Use Internet Search Engines for Research
• Run Packet Sniffers to Collect Additional Data
• Filter the Data to eliminate insignificant and/or show indicators of the highest significance
• Seek Assistance from Others (internal and external resources) to contain and eradicate the incident

Detection and Analysis - Analysis

• Incident Documentation

• Lead to a more efficient, more systematic, and less error-prone handling of the problem
• Information could be used as evidence in a court of law if legal prosecution is pursued
• Incident Prioritization - Incidents should be handled based on
• Functional Impact of the Incident
• Information Impact of the Incident
• Recoverability from the Incident

• Incident Notification

• Incident response policies should include provisions concerning incident reporting—at a minimum, what must be reported to whom and at what times

Containment, Eradication, and Recovery

• Choosing a Containment Strategy

• Containment provides time for developing a tailored remediation strategy
• Decisions for containment are much easier to make if there are predetermined strategies and procedures for containing the incident
• Strategies should be developed based on definition of acceptable risks levels
• In some cases, containment strategy may cause additional damage

• Evidence Gathering and Handling

• Gathering evidence helps resolve the incident and may also be needed for legal proceedings
• Evidence should be collected according to procedures so that it can be admissible in court
• Chain of custody forms should be filled out whenever evidence is transferred from person to person

Containment, Eradication, and Recovery

• Identifying the Attacking Hosts

• Validating the attacking host’s IP address
• Researching the attacking host through search engines
• Using incident databases shared by multiple organizations might give insights
• Monitoring possible attacker communication channels to obtain data about attackers

• Eradication and Recovery

• Eradication is to eliminate components of the incident (e.g., deleting malware, etc.)
• Recovery is the process of restoring systems to normal operation, confirming that systems are functioning normally, and that vulnerabilities have been remediated
• Eradication and recovery should be done in a prioritized and phased approach:
• Early phases should focus on increasing security with relatively quick high value changes
• Later phases should focus on longer-term changes to keep the enterprise as secure as possible

Intrusion Responses

• Dropping suspicious packets at firewall
• Denying access to a user displaying suspicious activity
• Reporting activity to other hosts
• Updating configurations within IDS
• Alarms and Signals

• Lessons Learned

• Each incident response team should evolve to reflect new threats, improved technology, and lessons learned
• Holding a “lessons learned” meeting with all involved parties after a major incident (and optionally periodically), can help improve security measures and the incident handling process
• Incidents performed through new attack methods should be studied more carefully
• Ensuring that people who are and will be responsible for incident response operations are included in the meeting
• All major points of agreement and action items should be documented
• Incident response policies, procedures and training materials can be updated with the lessons learned
• Creating a follow-up report for each incident can be valuable for future use

• Using Collected Incident Data

• Lessons learned activities should produce a set of objective and subjective data regarding each incident.
• A study of incident characteristics may indicate systemic security weaknesses and threats, as well as changes in incident trends
• Another good use of the data is measuring the success of the incident response team
• Possible metrics for incident-related data include:
• Number of Incidents Handled
• Time Per Incident
• Objective Assessment of Each Incident
• Subjective Assessment of Each Incident

Source: NIST: Computer Security: Incident Handling Guide

• Evidence Retention

• Organizations should establish policy for how long evidence from an incident should be retained. Factors to be considered during policy creation:
• Prosecution
• If it is possible that the attacker will be prosecuted, evidence may need to be retained until all legal actions have been completed (maybe several years)
• Some seemingly unimportant data might be key to explaining an incident
• Data Retention
• Retention policies state how long certain types of data may be kept
• Cost
• Cost of storing data over disks for a number of years might be substantial
• Devices that can use stored hardware and media must also be retained

Incident Response Management

Incident Response Management

• Incident Response Management involves:
• Creating Policy,
• Devising an incident response Plan,
• Establishing incident response Procedures,
• Setting up a team, and
• Handling the incident
• Preparation
• Detection and Analysis
• Containment, Eradication and Recovery
• Post-Incident Activity

Incident Response Policy

• Key elements of policy are:
• Statement of management commitment
• Purpose and objectives of the policy
• Scope of the policy
• Whom it applies to
• What it applies to, and
• Circumstances it applies to
• Definition of computer security incidents and related terms

Incident Response Policy

• Organizational structure
• Definition of roles and responsibilities
• Levels of authority
• Requirements and guidelines for reporting and external communications
• Escalation points in the incident management process
• Prioritization or severity ratings of incidents
• Performance measures
• Reporting and contact forms

Incident Response Plan

An incident response plan provides the roadmap for implementing the incident response capability. Elements of the plan are:

• Mission
• Strategies and goals
• Senior management approval
• Organizational approach to incident response
• How the incident response team will communicate with the rest of the organization and with other organizations
• Metrics for measuring the incident response capability and its effectiveness
• Roadmap for maturing the incident response capability
• How the program fits into the overall organization

Incident Response Procedure

• Procedures should be based on the incident response policy and plan
• Standard Operating Procedures (SOPs) should delineate technical processes, techniques, checklists, and forms
• SOPs should be detailed enough to ensure that priorities of the organization are reflected in response operations
• Following standardized responses should minimize errors, particularly those that might be caused by stressful incident handling situations
• SOPs should be tested to validate their accuracy and usefulness
• Training should be provided for SOP users; SOP documents can be used as an instructional tool

Need for Information Exchange with Outside Parties

• Organizations may need to communicate with outside parties regarding an incident
• Discussion of incidents with other involved parties, such as ISPs, vendors of vulnerable software, and/or other incident response teams
• Proactively sharing relevant incident indicator information with peers to improve detection and analysis of incidents
• Discussion with the public affairs office, legal department, and management to establish policies and procedures regarding information sharing.
• All contacts and communications with outside parties should be documented for liability and evidentiary purposes
• Legal requirement to report varies from country to country/jurisdiction

Incident Response Team Models

• Central Incident Response Team
• Single team handles incidents throughout the organization
• Effective for small organizations, or organizations with minimal geographic diversity
• Distributed Incident Response Teams
• Multiple teams, each responsible for a particular logical or physical segment
• Effective for large organizations, or for organizations with major computing resources at distant locations
• However, the teams should be part of a single coordinated entity so that the incident response process is consistent
• Coordinating Team
• One team provides advice to other teams without having authority over those teams

Incident Response Team Staffing

Incident response teams can also use any of three staffing models:

• Employees - The organization performs all of its incident response work, with limited technical and administrative support from contractors.
• Partially Outsourced – a portion of the incident response work is outsourced. Commonly, organizations outsource:
• 24/7 monitoring of intrusion detection sensors, firewalls, and other security devices to an offsite managed security services provider (MSSP)
• Basic incident response work in-house and call on contractors to assist with handling incidents, particularly those that are more serious or widespread
• Fully Outsourced - Incident response work is completely outsourced, typically to an onsite contractor

Incident Response Team Model Selection

Factors for team model selection are:

• Need for 24/7 Availability
• Full-Time Versus Part-Time Team Members
• Employee Morale
• Cost
• Staff Expertise

When considering outsourcing, organizations should keep these issues in mind:

• Current and future quality of Work Lack of Organization-Specific Knowledge
• Division of responsibilities Handling Incidents at Multiple Locations
• Sensitive information to be revealed Maintaining Incident Response Skills In-House