Incident Handling

Incident Handling Dr. David Dampier

What is an incident? • According to the NIST Computer Security Incident Handling Guide, a computer security incident is: • ”a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” • Essentially, an incident is anything outside of common-practice or policy-compliant use.

Examples of Incidents • Inappropriate usage: • A user views illegal material on corporate computers • User threatens another person through corporate e-mail • Unauthorized access: • Attacker runs an exploit to gain access on a corporate system • User obtains rights to an administrative account without proper authorization

Need for Incident Response • With the reliance on computers in modern companies, incidents are becoming more commonplace • It is not a question of IF your company will have an incident, but WHEN... • As computer security incidents can commonly cause high losses due to downtime and PR concerns, Incident Handling is a very solid investment

Incident Response Benefits • Systematic response to incidents so appropriate steps can be taken in timely fashion • Helping personnel to recover quickly (less downtime)‏ • Minimizing loss or theft of information • Being able to learn from each incident, and apply those lessons • Properly dealing with legal issues that may arise due to incidents

More Than Just Technical • There are many more aspects to incident handling than just technical • Legal issues • Public Relations issues • Human Resources issues • Operations issues • ...etc...

Outside Parties Involved • ISP • Telecomm Providers • Affected External Parties • Owners of Attacking Address • Media • Law Enforcement • Software Vendors • ....etc...

IR Life-Cycle

Preparation • Preparation is one of, if not the, most important step in the Incident Handling life cycle • For two reasons: • IH is time-critical: organizations have to be ready • Preparation, in many cases, equals prevention • As with everything else, failing to plan is planning to fail

Detection and Analysis • This phase of the process is when the incident handler: • Detects that an incident is occurring / has occurred • Analyzes the incident to determine scope, source, effectiveness, etc. • Formally documents the incident for future analysis and removal • Prioritizes incident based on resources affected and potential effect • Notifies appropriate personnel

Containment, Eradication, Recovery • In this phase, the handler will: • Determine which containment strategy to use based on the type of attack • Properly gather, handle, and store evidence related to the incident • Attempt to identify the attacker, obtaining as much information as possible • Eradicate the source of the incident, and recover any affected systems

Post-Incident Activity • In this phase, the handler will: • Discuss with team / affected personnel to review the actions taken during the incident to determine what is working and what isn't • Review collected incident information against historical incident information to try to learn as much as possible • Retain and store data about incident, should it become necessary to present it to other bodies

Detection and Analysis • Generally the most difficult and stressful phase of the IH process • Includes the following: • Detect signs • Categories • Precursors • Indications • Analysis • Documentation • Prioritization • Notification

Detect Signs • The most difficult part of the process • This is due to 3 factors: • Detection through different means, levels of detail, and fidelity • High volume of potential signs • Deep, specialized technical knowledge and extensive experience are necessary • Signs fall into 2 categories: • Indications • Precursors

Detect Signs (cont.)‏ • Indication: • A sign that an incident may have occurred or may be occurring • Too many types to extensively list • Examples: • IDS alerts about buffer overflow • Web server crashes • Filenames with suspicious characters • Anti-virus software alerts an infected host • Unusual deviation from typical network traffic flows

Detect Signs (cont.)‏ • Precursor: • A sign that an incident may occur in the future • IH version of “early warning signs” • Examples: • Log entries showing signs of vulnerability scanners • New applicable exploit • Hacktivist threat

Detect Signs (cont.)‏ • Sources of Precursors and Indications • Software Alerts • IDS • Antivirus software • File integrity checking • Third-party monitoring • Logs • Operating system, service, and application • Network device • Honeypots

Detect Signs (cont.)‏ • Publicly available information • Information on new vulnerabilities and exploits • Information on incidents at other organizations • People • People within your organization • People outside your organization

Detect Signs (cont.)‏ • Incident Categories: • Denial of Service: • Prevents or impairs authorized use by exhausting resources • Malicious Code: • Virus, worm, Trojan horse, etc. • Unauthorized Access: • Logical or physical access without permission

Detect Signs (cont.)‏ • Incident Categories (cont.)‏ • Inappropriate Usage: • Violates acceptable use policies • Multiple Component: • One incident encompassing one or more incidents

Detect Signs (cont.)‏ • Multiple Category Incidents: • Should be categorized by transmission mechanism • Example: • Virus creates backdoor • Handle as malicious code, since the virus was the transmission mechanism

Incident Analysis • Would be easy if all precursors were indications • But they are not • User-provided indications are often incorrect • IDS commonly throw many false positives • STILL, must evaluate every indication as if it is legitimate

Incident Analysis • Even if indication is accurate • Doesn't necessarily mean anything is going on • Assume it is an incident until proven otherwise • May be necessary to communicate with other personnel • Indicator may be an issue, just not a security issue • Example: • Web server that is down due to non-malicious cause

Sources of Indications/Precursors • Network and Host-Based IDS • IDS products are designed to identify suspicious events • Record valuable information about incidents as they occur • Often produce false-positives • Analysts must manually validate IDS alerts to determine threat

Sources of Indications/Precursors • Antivirus Software • Detects malicious code and sends alerts to affected host and centralized antivirus console • Only effective as long as virus signature database is kept up-to-date • Should be employed in at least two-levels • Network perimeter (e.g., firewalls, mail servers)‏ • Host level (e.g., workstations, file servers, client software)‏

Sources of Indications/Precursors • File integrity checking software • Incidents may often change important files • File integrity software uses hashing to determine any file changes • Regularly hashing important or critical files can determine any unauthorized changes to systems • These changes can be indicators of incident!

Sources of Indications/Precursors • Third-party monitoring service • Services exist to monitor public critical business assets • They check specified systems (e.g., DNS, mail, and Web servers) every x minutes • Should the services or systems not respond, the service can alert specified personnel to respond

Sources of Indications/Precursors • Operating system • Logs from the operating system can give valuable information regarding incidents • Which accounts were accessed, times, and methods of access are commonly recorded • A baseline level of logging should be performed on all systems • More critical systems should a greater amount of logging

Sources of Indications/Precursors • Network devices • Logs from network devices are not typically used as primary indications/precursors to an incident • However, they can supply corroborating evidence to the nature of an incident • Monitoring of information handled by network devices can also give valuable information regarding attack trends

Sources of Indications/Precursors • Information on new vulnerabilites/exploits • Keeping up with new vulnerabilities and exploits is critical as an incident handler! • Several organizations monitor the newest vulnerabilities as they are found...don't completely rely on automated software patching! • US-CERThttp://www.us-cert.gov/federal/ • CIAChttp://www.ciac.org/ciac/index.html • Bugtraqhttp://www.securityfocus.com/archive/1

Sources of Indications/Precursors • People • Front line users of every system in the company • From common users to sys admins • Educating company personnel to report significant issues can yield very useful results • Make reporting of issues as easy as possible • This method may also yield false-positives, but the payback can be tremendous when an incident occurs

Incident Analysis (cont.)‏ • Remember, skilled attackers cover their tracks • It is likely that there may be no precursors or indications until after the incident has occurred • Unskilled attackers are being able to be as quiet as skilled attackers with the tools being released • Detection may be the most difficult task in the IH process in many cases.

Incident Analysis (cont.)‏ • Incident handlers are responsible for: • Analysing ambiguous, contradictory, and incomplete symptoms... • ...over many different systems... • ...in many different locations... • ...to determine if anything has happened... • ...how it happened... • ...how to fix it... • ...and how to ensure it doesn't happen again

Incident Analysis (cont.)‏ • The team is the handler's salvation: • The best remedy against the obstacles mentioned is a highly experienced and proficient team • Must be able to analyze precursors and indications quickly, effectively, and efficiently • Must be able to determine scope of issue, and respond appropriately • An ill-trained team will result in very costly mistakes

Incident Analysis (cont.)‏ • Remember, skilled attackers cover their tracks • It is likely that there may be no precursors or indications until after the incident has occurred • Unskilled attackers are being able to be as quiet as skilled attackers with the tools being released • Detection may be the most difficult task in the IH process in many cases.

Documentation • Documentation during analysis is KEY! • Proper documentation records the nature and effects of the incident • Proper documentation is great naturally-corroborating evidence • Proper documentation ensures the right things are being done, by the right people, at the right time • Later we will discuss how useful and important documentation is

Incident Notification • Once an incident has been analyzed, the handling team needs to notify appropriate personnel • Cooperation with other departments can be critical! Some typical personnel to notify: • CIO • Security officer • Other incident handling teams • System owner/admin • HR, Public affairs, or Legal as necessary

Containment, Eradication & Recovery • Containment, Eradication, and Recovery encompass the third phase of the Incident Response Life Cycle • Containment • What to do when discovering an incident? • Eradication • How do we stop the incident? • Recovery • How do we recover from the incident?

Containment • Planning is essential to properly and effectively containing an incident • Containment Strategies • Plans for how an incident will be contained • A “Standard Operating Procedure” for specific incident categories • Assists with the primary aspect of containment • Decision-Making is KEY! • Decisions are easier when plans have been made

Containment (cont.)‏ • Containment Strategies vary based on the category of the incident. • E-mail based virus vs. network-based Denial of Service • Highly recommended to plan for every category contingency • Will review some strategies later • Criteria must be documented clearly

Containment (cont.)‏ • Some criteria for planning a Containment Strategy include: • Potential damage to and theft of resources • Need for evidence preservation • Service availability • Time and Resources needed to implement • Effectiveness • Duration of solution (e.g., times for emergency plan, temporary plan, and permanent solution)‏

Containment (cont.)‏ • “Watch and Learn” • As discussed earlier, some organizations may want to delay containment • This is usually to gain additional evidence • Risky!! • The attacker could be doing more harm • The attacker could be attacking other systems • The attacker could be creating other points of entry (backdoors)‏ • Only possible under certain conditions

Containment (cont.)‏ • Necessities for “Watch and Learn”: • Strategy must be cleared with Legal • Strategy must be cleared with Management • The incident response team must be VERY experienced • Must have the ability to intercede at any moment • Must be able to accurately monitor the attacker's movements through the system • RARELY worth the risk!!!

Containment (cont.)‏ • Some attacks may cause more damage when contained • Intruder may have “failsafes” should their attack be stopped • Never assume that removing access = removing damage potential • Containment is just the beginning of specific incident handling • Incident contained...but what now?

Evidence • THE THREE A's • Acquirethe evidence without altering or damaging the original • Authenticatethat the acquired evidence is the same as the originally seized data • Analyzethe evidence without modifying it

Evidence (cont.)‏ • Evidence can be for legal or private purposes • Legal • Bound for legal proceedings • Ex: Illegal documents or images • Private • Used for resolving the incident internally • Ex: User information of employee that obtained unauthorized access • Not all Private evidence can be used as Legal, but all Legal evidence can be used as Private!

Evidence (cont.)‏ • Acquisition of evidence is done through Gathering and Handling • Gathering • Collecting all viable and relevant evidence possible • Everything is potentially important • Not having enough evidence will not give a full picture of incident • Handling • Ensuring evidence collected remains viable and holds up to contestation • Evidence that is viewed as tainted can't be effectively used for either Legal OR Private use

Evidence (cont.)‏ • Gathering: • As much information as possible should be gathered regarding the incident • Unless gathering the evidence puts resources at risk • Ex: “Watch and Learn” • Collecting evidence presents some challenges • Initial snapshots of the systems in question are useful • Handlers, Admins, and others may inadvertently change data that corrupt later snapshots

Evidence (cont.)‏ • Sometimes it is useful to capture volatile information • Network connections • Memory contents • Processes • User logons • There are risks! • Any actions performed on a live system can potentially alter the state of the system

Evidence (cont.)‏ • Executing commands on a live system is risky! • Displaying contents of directory can alter last access times • Some commands may have been altered or replaced • To avoid this: • Use pre-made commands and libraries on write-once media (Floppy, CD, etc.)‏ • Use write-blockers to prevent hard drive writes

Incident Handling