Risk Analysis
Incident Response Planning
- Incident response planning covers the identification of, classification of, and response to an incident
- An incident is an attack against an information asset that poses a clear threat to the confidentiality, integrity, or availability of information resources
- Attacks are only classified as incidents if they have the following characteristics:
- Are directed against information assets
- Have a realistic chance of success
- Could threaten the confidentiality, integrity, or availability of information resources
- IR is more reactive, than proactive, with the exception of the planning that must occur to prepare the IR teams to be ready to react to an incident
*
Incident Response Planning
Incident response planning covers the identification of, classification of, and response to an incident.
The IRP is made up of activities that are to be performed when an incident has been identified.
An incident is an attack against an information asset that poses a clear threat to the confidentiality, integrity, or availability of information resources.
Attacks are only classified as incidents if they have the following characteristics:
- Are directed against information assets
- Have a realistic chance of success
- Could threaten the confidentiality, integrity, or availability of information resources.
Incident Response Planning
Incident response (IR) is the set of activities taken to plan for, detect, and correct the impact of an incident on information resources.
IR is more reactive, than proactive, with the exception of the planning that must occur to prepare the IR teams to be ready to react to an incident.
Planning for an incident requires a detailed understanding of the scenarios developed for the BIA.
Incident Response Plan
- Format and Content
- The plan must be organized to support quick and easy access to the information needed
- Storage
- The plan should be protected as sensitive information
- On the other hand, the organization needs this information readily available
- Testing
- An untested plan is not a useful plan. The levels of testing strategies can vary
*
Incident Response Plan
Format and Content.
The IR plan must be organized so that, the organization supports, rather than impedes quick and easy access to the information needed.
This can be accomplished through a number of measures, the simplest of which is to create a directory of incidents, with tabbed sections for each possible incident.
When an individual needs to respond to an incident, he or she simply opens the binder, flips to the appropriate section, and follows the clearly outlined procedures for an assigned role.
Incident Response Plan
Storage.
The information in the IR plan should be protected as sensitive information. If attackers know how a company responds to a particular incident, it could improve their chances of success in the attack.
On the other hand, the organization needs this information readily available, usually within reach of the information assets that must be manipulated during or immediately after the attack.
The bottom line is that individuals responding to the incident should not have to search frantically for needed information, especially under stress.
Incident Response Plan
Testing.
A plan untested is not a useful plan. The levels of testing strategies can vary:
- Checklist.
- Structured walk-through.
- Simulation.
- Parallel.
- Full-interruption.
Incident Detection
- The most common occurrence is a complaint about technology support, often delivered to the help desk
- Possible detections:
- intrusion detection systems, both host-based and network-based
- virus detection software
- systems administrators
- end users
- Only through careful training can the organization hope to quickly identify and classify an incident
- Once an attack is properly identified, the organization can respond
*
Incident Detection
Individuals sometimes bring an unusual occurrence to the attention of systems administrators, security administrators, or their bosses.
The most common occurrence is a complaint about technology support, often delivered to the help desk.
The mechanisms that could potentially detect an incident include intrusion detection systems, both host-based and network-based, virus detection software, systems administrators, and even the end user.
Incident Detection
Only by carefully training the user, the help desk, and all security personnel on the analysis and identification of attacks can the organization hope to quickly identify and classify an incident.
Once an attack is properly identified, the organization can effectively execute the corresponding procedures from the IR plan.
Incident classification is the process of examining a potential incident, or incident candidate, and determining whether or not the candidate constitutes an actual incident.
Incident Indicators
Possible indicators of incidents:
- Presence of unfamiliar files
- Unknown programs or processes
- Unusual consumption of computing resources
- Unusual system crashes
Probable indicators of incidents:
- Activities at unexpected times
- Presence of new accounts
- Reported attacks
- Notification from IDS
Definite indicators of incidents:
- Use of dormant accounts
- Changes to logs
- Presence of hacker tools
- Notifications by partner or peer
- Notification by hacker
Predefined situations that signal an automatic incident:
- Loss of availability
- Loss of integrity
- Loss of confidentiality
- Violation of policy
- Violation of law
*
Incident Indicators
There are a number of occurrences that could signal the presence of an incident candidate.
Possible indicators of incidents:
1) Presence of unfamiliar files.
2) Presence or execution of unknown programs or processes.
3) Unusual consumption of computing resources.
4) Unusual system crashes.
Probable indicators of incidents:
1) Activities at unexpected times.
2) Presence of new accounts.
3) Reported attacks.
4) Notification from IDS.
Incident Indicators
Definite indicators of incidents.
1) Use of dormant accounts.
2) Changes to logs.
3) Presence of hacker tools.
4) Notifications by partner or peer.
5) Notification by hacker.
Predefined situations that signal an automatic incident:
1) Loss of availability.
2) Loss of integrity.
3) Loss of confidentiality.
4) Violation of policy.
5) Violation of law.
Incident or Disaster
- When Does an Incident Become a Disaster?
- the organization is unable to mitigate the impact of an incident during the incident
- the level of damage or destruction is so severe the organization is unable to quickly recover
- It is up to the organization to decide which incidents are to be classified as disasters and thus receive the appropriate level of response
*
Incident Indicators
When Does an Incident Become a Disaster?
1) the organization is unable to mitigate the impact of an incident during the incident,
2) the level of damage or destruction is so severe the organization is unable to quickly recover. The difference may be subtle.
It is up to the organization to decide which incidents are to be classified as disasters and thus receive the appropriate level of response.
Incident Reaction
- Incident reaction consists of actions that guide the organization to stop the incident, mitigate the impact of the incident, and provide information for the recovery from the incident
- In reacting to the incident there are a number of actions that must occur quickly including:
- notification of key personnel
- assignment of tasks
- documentation of the incident
*
Incident Reaction
Incident reaction consists of actions outlined in the IRP that guide the organization in attempting to stop the incident, mitigate the impact of the incident, and provide information for the recovery from the incident.
In reacting to the incident there are a number of actions that must occur quickly.
These include notification of key personnel, assignment of tasks, and documentation of the incident.
Documenting an Incident
- Documenting the event is important:
- First, it is important to ensure that the event is recorded for the organization’s records, to know what happened, and how it happened, and what actions were taken. The documentation should record the who, what, when, where, why, and how of the even
- Second, it is important to prove, should it ever be questioned, that the organization did everything possible to prevent the spread of the incident
- Finally, the recorded incident can also be used as a simulation in future training sessions
*
Documenting an Incident
Documenting the event is important.
First, it is important to ensure that the event is recorded for the organization’s records, to know what happened, and how it happened, and what actions were taken. The documentation should record the who, what, when, where, why and how of the event.
Second, it is important to prove, should it ever be questioned, that the organization did everything possible to prevent the spread of the incident.
The recorded incident can also be used as a simulation in future training sessions.
Incident Containment Strategies
- Before an incident can be contained, the affected areas of the information and information systems must be determined
- The organization can stop the incident and attempt to recover control through a number of strategies including:
- severing the affected circuits
- disabling accounts
- reconfiguring a firewall
- The ultimate containment option, reserved for only the most drastic of scenarios, involves a full stop of all computers and network devices in the organization
*
Incident Containment Strategies
One of the most critical components of incident reaction is to stop the incident or contain its scope or impact.
However, sometimes situations prevent the most direct measures associated with simply “cutting the wire.”
Before an incident can be contained, the affected areas of the information and information systems must be determined.
In general, incident containment strategies focus on two tasks: stopping the incident and recovering control of the systems.
Incident Containment Strategies
The organization can stop the incident and attempt to recover control through a number of strategies. If the Incident:
- originates outside the organization, the simplest and most straightforward approach is to sever the affected circuits.
- is using compromised accounts, the accounts can be disabled.
- is coming in through a firewall, the firewall can be reconfigured to block that particular traffic.
- is using a particular service or process, that process or service can be disabled temporarily.
- is using the organization’s systems to propagate itself, you can take down that particular application or server.
The ultimate containment option, reserved for only the most drastic of scenarios, involves a full stop of all computers and network devices in the organization.
The bottom line is that containment consists of isolating the channels, processes, services, or computers and removing the losses from that source of the incident.
Incident Recovery
- Once the incident has been contained, and control of the systems regained, the next stage is recovery
- The first task is to identify the human resources needed and launch them into action
- The full extent of the damage must be assessed
- The organization repairs vulnerabilities, addresses any shortcomings in safeguards, and restores the data and services of the systems
*
INCIDENT RECOVERY
Once the incident has been contained, and control of the systems regained, the next stage is recovery.
As with reaction to the incident, the first task is to identify the human resources needed for the recovery and launch them into action.
The full extent of the damage must be assessed.
The process of computer forensics entails determining how the incident occurred and what happened.
The organization repairs vulnerabilities, addresses any shortcomings in safeguards, and restores the data and services of the systems.
Damage Assessment
- There are several sources of information:
- including system logs
- intrusion detection logs
- configuration logs and documents
- documentation from the incident response
- results of a detailed assessment of systems and data storage
- Computer evidence must be carefully collected, documented, and maintained to be acceptable in formal proceedings
- Individuals assessing damage need special training
*
Damage Assessment
Incident damage assessment is the immediate determination of the scope of the breach of CIA of information and assets after an incident.
There are several sources of information on the type, scope, and extent of damage, including system logs, intrusion detection logs, configuration logs and documents, the documentation from the incident response, and the results of a detailed assessment of systems and data storage.
Based on this information, the IR team must begin to examine the current state of the information and systems and compare them to a known state.
Damage Assessment
Related to the task of incident damage assessment is the field of computer forensics.
Computer forensics is the process of collecting, analyzing, and preserving computer-related evidence. Evidence proves an action or intent.
Computer evidence must be carefully collected, documented, and maintained to be acceptable in formal or informal proceedings.
Circumstances requires that individuals who look for the damage receive special training, should it be determined that the incident is part of a crime or may result in a civil action.
Recovery
In the recovery process:
- Identify the vulnerabilities that allowed the incident to occur and spread and resolve them
- Address the safeguards that failed to stop or limit the incident, or were missing from the system in the first place. Install, replace or upgrade them
- Evaluate monitoring capabilities. Improve their detection and reporting methods, or simply install new monitoring capabilities
- Restore the data from backups
- Restore the services and processes in use
- Continuously monitor the system
- Restore the confidence of the members of the organization’s communities of interest
- Conduct an after-action review
*
Recovery
The recovery process involves:
- Identify the vulnerabilities that allowed the incident to occur and spread and resolve them.
- Address the safeguards that failed to stop or limit the incident, or were missing from the system in the first place. Install, replace or upgrade them.
- Evaluate monitoring capabilities. Improve their detection and reporting methods, or simply install new monitoring capabilities.
- Restore the data from backups.
- Restore the services and processes in use.
- Continuously monitor the system.
- Restore the confidence of the members of the organization’s communities of interest.
- Conduct an after-action review.
Automated Response
- New systems can respond to incidents autonomously
- Trap and trace uses a combination of resources to detect intrusion then trace back to source
- Trapping may involve honeypots or honeynets
- Entrapment is luring an individual into committing a crime to get a conviction
- Enticement is legal and ethical, while entrapment is not
*
Automated Response
While traditional systems were configured to detect incidences, and then notify the human administrator, new systems can respond to the incident threat autonomously.
These systems, referred to as trap and trace, use a combination of resources to detect an intrusion, and then to trace incidents back to their sources.
Unfortunately, some less scrupulous administrators might even be tempted to back hack or hack into a hacker’s system to find out as much as possible about the hacker.
The problem is that the hacker may actually move into and out of a number of organizations’ systems and by tracking the hacker, administrators may wander through other organizations’ systems.
Automated Response
The trap portion frequently involves the use of honeypots or honeynets.
Honeypots are computer servers configured to resemble production systems. If a hacker stumbles into the system, alarms are set off, and the administrator notified.
Honeynets, consist of networks or subnets of systems that operate similarly.
Enticement is the process of attracting attention to a system by placing tantalizing bits of information in key locations.
Entrapment is the action of luring an individual into committing a crime to get a conviction.
Enticement is legal and ethical, while entrapment is not.
Computer Incident Response Suite
- Tool suite designed to aid corporate and government computer specialists deal with potential computer risks associated with accidents, malicious code, criminal acts, and corporate security abuses
- This software suite includes:
- CopyQM
- CRCMD5
- Diskscrub
- DiskSig
- Net Threat Analyzer
Eradication
- Removal of the cause of the incident
- eradicating any viruses, bogus files, etc.
- Affected systems examined for evidence
- involves complete review; may be time-consuming
Incident Recovery
- The process of:
- bringing system back to a known good state
- installing patches/fixes for vulnerability exploited
- restoring information integrity and availability
- Must set priorities to know what is most important to protect
Incident Recovery
- Repair vulnerability
- Improve safeguard
- Update detection
- Restore data
- Restore services
- Monitor for additional signs of attack
- Restoration of Confidence
Follow-Up
- What went right? What went wrong with regard to incident response?
- What policies/procedures should be changed/updated?
- New products purchased?
- New personnel hired?
Case Studies
- Data recovery
- On-Site acquisition
- Electronic risk control
- Electronic document discovery
- Password recovery
- Litigation support
- Expert witness testimony
Case Study
Data Recovery
- Our Client, a renowned trading company, suffered a sudden, devastating power outage that caused their server to cease functioning
- The company took the hard-drive to a local computer repair person that was unable to read the corrupt drive
- At this point, the company contacted you to recover the information
- What actions will you take?