Incident Management Assignment 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.

Incident Management Assignment Help By Online Tutoring and Guided Sessions at AssignmentHelp.Net

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