Principles of Incident Response and Disaster Recovery

Principles of Incident Response and Disaster Recovery Chapter 4 Incident Response: Detection and Decision Making

Objectives • Understand the elements necessary to detect incidents that pose risk to the organization • Know the components of an intrusion detection system • Become familiar with the processes used in making decisions surrounding incident detection and escalation Principles of Incident Response and Disaster Recovery

Introduction • Incident classification: process of evaluating circumstances around organizational events to identify incident candidates • Incident candidates: events that are possible incidents • After an actual incident is properly identified, the IR team executes the corresponding procedures from the IR plan Principles of Incident Response and Disaster Recovery

Detecting Incidents • Three broad categories of incident indicators: • Possible • Probable • Definite • Categorization expedites the decision-making process of incident classification, and allows the proper IR plan to be activated as early as possible Principles of Incident Response and Disaster Recovery

Possible Indicators of an Incident • 4 types of incident candidates considered to be possible actual incidents: • Presence of unfamiliar files • Presence or execution of unknown programs or processes • Unusual consumption of computing resources • Unusual system crashes Principles of Incident Response and Disaster Recovery

Probable Indicators of an Incident • 4 types of incident candidates considered to be probable actual incidents: • Activities at unexpected times • Presence of new accounts • Reported attacks • Notification from an intrusion detection system (IDS) Principles of Incident Response and Disaster Recovery

Definite Indicators • 5 types of incident candidates that are definite indicators of an actual incident: • Use of dormant accounts • Changes to logs • Presence of hacker tools • Notifications by partner or peer • Notification by hacker Principles of Incident Response and Disaster Recovery

Definite Indicators (continued) • General types of events that indicate an actual incident is underway: • Loss of availability of information or systems • Loss of integrity of data • Loss of confidentiality (leaks or disclosures) • Violation of policy • Violation of law Principles of Incident Response and Disaster Recovery

Identifying Real Incidents • Nonevents: false positive incident candidates • The vast majority of incident candidates are false positives • Must develop a process to collect and evaluate incident candidates • Noise: legitimate activities wrongly reported as incident candidates • Ongoing user training is required to reduce noise • Ratio of false positive events to actual events needs to be kept to a manageable level Principles of Incident Response and Disaster Recovery

Identifying Real Incidents (continued) • Several possible causes of noise: • Placement: source of the incident candidate • Policy: network administrators may use tools that may appear to be attack tools • Awareness: employees may not be aware of policy that restricts use of certain tools • Must carefully analyze all incident candidates to tune the data collection process to filter out noise without ignoring possible actual incidents • False negative: occurs when an incident that deserves attention is not reported Principles of Incident Response and Disaster Recovery

Identifying Real Incidents (continued) • Tuning process must include: • Adjusting for true noise • Adjusting for false negatives • Handling routine changes, such as newer technologies Principles of Incident Response and Disaster Recovery

Intrusion Detection Systems • Intrusion detection system (IDS): • A network burglar alarm • Used to determine if the network is being used in ways that are out of compliance with the organization’s policy • Intrusion: • An attempt to gain unauthorized entry into a system or network • An attempt to disrupt the normal operations of a system or network Principles of Incident Response and Disaster Recovery

Intrusion Detection Systems (continued) • Alert or alarm: • An indication that a system has been attacked or continues to be attacked • May be audible signals, email messages, pager notifications, pop-up windows, or log entries • False attack stimulus: an event that triggers alarms and causes a false positive • False negative: failure of an IDS to react to an actual attack; most grievous type of failure Principles of Incident Response and Disaster Recovery

Intrusion Detection Systems (continued) • False positive: • An alarm or alert when no attack occurred • Tends to make users insensitive to alarms • Noise: • Ongoing activity from alarm events that are accurate and noteworthy but not necessarily significant as potentially successful attacks • Unsuccessful attacks are the most common source of noise Principles of Incident Response and Disaster Recovery

Intrusion Detection Systems (continued) • Site policy: rules and configuration guidelines for IDSs in the organization • Site policy awareness: an IDS’s ability to dynamically modify its site policies in reaction or response to environmental activity • True attack stimulus: an event that triggers alarms and causes an IDS to react as if a real attack is in progress • Confidence value: a value associated with an IDS’s ability to detect and identify an attack correctly Principles of Incident Response and Disaster Recovery

Intrusion Detection Systems (continued) • Alarm filtering: process of classifying the attack alerts to distinguish false positives from actual attacks • Alarm clustering: a consolidation of almost identical alarms into a single higher-level alarm • Alarm compaction: alarm clustering based on frequency, similarity in attack signatures or targets, or other similarities Principles of Incident Response and Disaster Recovery

Why Use an IDS? • Compelling reasons to use an IDS: • Prevent problem behaviors by increasing the perceived risk of discovery and punishment • Detect attacks and security violations that are not prevented by other security measures • Detect and deal with preambles to attacks (network probes and other doorknob-rattling activities) • Document the existing threat to an organization • Act as quality control for security design and administration • Provide intrusion data to improve diagnosis and recovery Principles of Incident Response and Disaster Recovery

Why Use an IDS? (continued) • Most attacks begin with an organized and thorough probing of an organization’s network and defenses • Doorknob rattling: probing for the initial estimate of the defensive state of networks and systems • Footprinting: gathering information about network activities and assets • Fingerprinting: scanning for active systems and services offered by those systems • IDS may allow administrators extra time to prepare for an attack Principles of Incident Response and Disaster Recovery

Why Use an IDS? (continued) • Data collected by an IDS can be used to document threats faced by an organization and justify the cost of security technology • IDS can also be justified using the concept of Defense in Depth, to help identify emergent or residual flaws in current security and network architecture • IDS also provides data for post attack reviews and forensic information Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement • IDSs operate as network-based, host-based, or application-based systems • Network-based systems focus on protecting network information assets • Host-based versions focus on protecting the server or host’s information assets • Application-based model works on one or more hosts that support a single application Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) • Network-based IDS (NIDS): • Monitors traffic on a segment of a network • Looks for patterns within network traffic that indicate an intrusion event is underway • Can detect many more types of attacks than a host-based IDS, but is more complex to configure and maintain • Switched port analysis (SPAN): a monitoring port on a hub, switch, or other key networking device that may be used by a NIDS Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) • Signature matching: • Process of comparing measured activity to known signatures to determine if an attack is underway • Protocol stack verification: • Deals with IP, TCP, UDP protocols • Looks for malformed data packets • Application protocol verification: • Deals with higher order protocols (HTTP, FTP, Telnet) • Looks for unexpected packet behavior or improper use Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) • DNS cache poisoning: • Use of valid packets to exploit poorly configured DNS servers to inject false information • Higher-order traffic examination can reduce throughput Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) • Host-based IDS (HIDS): • Resides on a particular computer or server • Monitors activity only on that host • Also called system integrity verifiers • Monitors the status of key system files, system configuration databases (registry, .ini, .cfg, .dat files) • Sounds an alarm when file attributes change, new files are created, or existing files are deleted • Can also monitor system logs • HIDS relies on the classification of files into various categories Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) • Managed HIDS can monitor multiple computers simultaneously • Each HIDS reports to a master console system • Files are usually categorized into these levels: • Critical system components: system registry and folders containing key OS elements • Support components: device drivers and other relatively important files • User data Principles of Incident Response and Disaster Recovery

Classification of IDS by Network Placement (continued) • Application-based IDS (AppIDS): monitors an application for abnormal events such as: • Users exceeding their authorization • Invalid file executions • Problems in the normal interaction between users, the applications, and the data • AppIDS can view encrypted data • A blended approach using NIDS, HIDS, and AppIDS may be best Principles of Incident Response and Disaster Recovery

Classification of IDS by Detection Approach • Signature-based IDS (or knowledge-based IDS): • Examines data traffic for patterns that match known signatures of attack patterns • Must be continually updated as new attack strategies are identified • Methods are similar to antivirus software • Signatures include time considerations: how frequently an attack pattern is expected • Is vulnerable to slowly timed attacks Principles of Incident Response and Disaster Recovery

Classification of IDS by Detection Approach (continued) • Statistical anomaly-based IDS (stat IDS)or behavior-based IDS: • Collects statistical summaries by observing traffic known to be normal to establish a baseline • Clipping level: • Level at which the IDS triggers an alert • Occurs when the periodically sampled network activity is outside the baseline parameters • Stat IDS can detect new types of attacks but requires more overhead Principles of Incident Response and Disaster Recovery

Classification of IDS by Detection Approach (continued) • Log file monitor: • Reviews the log files generated by servers, network devices, and other IDSs • Looks for patterns across many systems that may indicate attacks • Requires considerable resources Principles of Incident Response and Disaster Recovery

Intrusion Prevention Systems • Intrusion prevention systems (IPS): • A more reactive approach • Based on ability to respond to known methods of attacks and ability to create adaptive responses to previously unknown attacks • Biggest challenge is the tuning of the automated responses to avoid extreme measures with false positives yet still provide protection against attacks Principles of Incident Response and Disaster Recovery

Automated Response • Traditional systems were configured to detect incidents and provide notification • New systems can respond autonomously based on preconfigured options • Trap and trace systems: detect an intrusion and trace the intrusion back to its source • Caution is advised: • Do not become a hacker by trying to trace a hacker and employing vigilante justice Principles of Incident Response and Disaster Recovery

Automated Response (continued) • Honeypot: • Computer server configured to resemble a production system • Closely monitored network decoy used to distract adversaries, provide warnings about new attack and exploitation trends, and allow in-depth examination of adversaries during and after exploitation • Honeytoken: • Bogus file or information placed in a database • If accessed, it indicates unwanted activity Principles of Incident Response and Disaster Recovery

Automated Response (continued) • Honeynet (or honeypot farm): • Provides an entire network of real systems, applications, and services for attackers to interact with • Any inbound activity is most likely a scan, probe, or attack • Any outbound activity indicates that a system has been compromised Principles of Incident Response and Disaster Recovery

Automated Response (continued) • Legal Issues with honeypots and honeynets: • Know the difference between enticement (legal) and entrapment (not legal) • Ensure that anyone connecting to the honeypot or honeynet does not inadvertently place information into the environment (4th Amendment issue) • Electronic Communications Protection Act: prohibits recording of wire- or cable-based communications unless an exception applies • Pen Register, Trap and Trace Devices statute: general prohibition of real-time monitoring of traffic data relating to communications Principles of Incident Response and Disaster Recovery

Automated Response (continued) • Wasp trap syndrome: by using a honeypot or honeynet, you may attract more potential attackers • Legal aspects associated with tracking individuals back through the systems of others have yet to be resolved • Must consider the implications of an attack coming from a compromised system and the legality of a counterattack Principles of Incident Response and Disaster Recovery

Incident Decision Making • US-CERT general approach to narrowing the list of incident candidates and detecting true incidents: • Collect incident candidates using well-documented procedures • Investigate the candidates using systems and methods at your disposal • If other than an authorized activity, immediately initiate intrusion response procedures Principles of Incident Response and Disaster Recovery

Incident Decision Making (continued) Principles of Incident Response and Disaster Recovery

Collection of Data to Aid in Detecting Incidents Principles of Incident Response and Disaster Recovery

Collection of Data to Aid in Detecting Incidents (continued) Principles of Incident Response and Disaster Recovery

Collection of Data to Aid in Detecting Incidents (continued) • Routine collection of data can assist in the understanding of what the normal and routine operations look like Principles of Incident Response and Disaster Recovery

Collection of Data to Aid in Detecting Incidents (continued) • Manage logging and other data collection mechanisms: • Be prepared for a large amount of data • Rotate logs on a schedule • Archive logs • Encrypt logs to prevent unwanted disclosure • Dispose of logs securely • Detect compromised software and quarantine it • Use software verification Principles of Incident Response and Disaster Recovery

Collection of Data to Aid in Detecting Incidents (continued) • Constantly monitor networks for signs of intrusion: • Notify users that monitoring is being done • Review and investigate alert notifications • Review and investigate network error reports • Review network performance statistics and investigate anything that appears anomalous • Identify any unexpected, unusual, or suspicious network traffic and its possible implications • For remote monitoring, ensure that the connection is secure Principles of Incident Response and Disaster Recovery

Collection of Data to Aid in Detecting Incidents (continued) • Watch systems for unexpected behavior: • Notify users that monitoring is being done • Review and investigate system-specific alert notifications • Review and investigate system error reports • Review system performance statistics and investigate anything that appears anomalous • Identify any unexpected, unusual, or suspicious process behavior and its possible implications • Periodically execute vulnerability scanning tools • For remote monitoring, ensure that the connection is secure Principles of Incident Response and Disaster Recovery

Principles of Incident Response and Disaster Recovery