Intrusion Detection

Intrusion Detection Advances, Problems, and all the politics that lie between Laurence Berland CS 395 Prof Yan Chen

Why do we need protection? • Cyberattacks still on rise • Threat of cyber-terrorism, more coordinated • Even sensitive installations not well-secured, regular breakins • Change in demographic: attacks require less sophisticated attackers.

Incidents Increasing

What is an attack? • Perspective matters • Victim: intrusion of loss or consequence • Attacker: achieved specific goals • Generally, if the victim has been affected, we say he has been attacked • Intrusion: successful attack • Even attacker-unsuccessful attempts may be intrusion. (ie Machine crashed)

Breakdown of an Intrusion • Intrusion begins when intruder takes steps to fulfill objectives • A flaw or weakness must be exploited, either by hand or with a precrafted tool • Flaws include social engineering: human processes can weaken security/integrity • Intrusion ends when attacker succeeds or gives up. • Attacks can have multiple victims or attackers

Intrusion Detection Systems Detecting attacks and preventing intrusions

Goals of IDS • Answer the questions: • What happened? • Who was affected? Who was the attacker? • How are they affected? How did the intrusion occur? • Where and when did the intrusion originate? • Why were we attacked? • ID aims to positively identify all attacks and negatively identify all non-attacks

Parts of an ID system • Sensors: Collect data. Include logs, system calls, network packets, etc • Analyzers: Receive sensor input and determine whether or not an attack has occurred. • User interface: Could be a graph, a remote page, or a management console. Imparts knowledge from analyzers • Honeypots, telescopes: systems designed to be attacked or probed to enhance the IDS

ID System Hierarchy • Application: Studies app behavior, generally through logs • Host: Studies host behavior, primarily through OS hooks and logs • Network: Monitors network traffic, possibly also host and app information passed up • Infrastructure: Aggregates many (generally network) monitors to get a bigger picture view of the situation

Analysis Models:Signature vs Anomaly • Knowledge: • A signature system (SS): must have a complete database of possible attacks, • An anomaly system (AS): must have a complete understanding of the system’s normal state

Analysis Models:Signature vs Anomaly • Configuration: • SS: must be kept up to date, but is otherwise largely preconfigured. • AS: however, needs to be trained in what is and isn’t anomalous behavior, which can take substantially more sophistication.

…cont • Reporting: • SS: simply report signature matches, and possibly include what matched the signature. • AS: include much more information, as they are statistics based. Some non-attack anomalies (like network outages) might also be noted.

…cont • Accuracy: • SS: tend to produce more false-negative responses. Signatures must be specific enough, and regularly updated • AS: produce more false-positive results. Must have a sufficiently complete view of nominal operations.

The trouble with IDS • ID systems generally promise more than they can deliver • ID systems are themselves vulnerable, and can be used to make things worse if an attacker is clever • Proprietary systems do not easily cooperate • ID systems leak information

IDS are hard to evaluate • Much like top-tier network peers, IDS systems tend to be closed and secretive • Vendors have little to gain from truly open evaluation, and instead rely on un- or undersubstantiated marketing claims

IDS are hard to evaluate • IDS maintenance is complicated, and is often overlooked • Staffing is critical. Most sophisticated attacks, and most actual captures of the attacker, stem from manual monitoring and forensics by qualified individuals

Defense in Depth • ID systems function best as part of a deep defense strategy including authentication, identification, firewalls, and other security technologies.

Where are we now? Extant Intrusion Detection Systems

State of IDS • IDS has been a topic of research since 1980 or so • The field is immature, similar to early years of automotive industry • There are research products, commercial products, and even some “abandoned” public domain products • Transition from host- to network-based systems as computing has changed focus

Research Products • Research exploded in the 1990s, but most tools were student projects that were dropped when research was completed • Three main research systems in use today • EMERALD • NetSTAT • Bro

Emerald • Event Monitoring Enabling Responses to Anomalous Live Disturbances • Research began in 1983 • Uses both signature and anomaly detection

Emerald • Origins in IDES: host based • Emerald is a full network-focused system that fuses information from multiple network points using a combination of methods • Designed for hard-to-monitor loose networks • Emerald imposes a hierarchy on the network and aggregates information based on user-assigned, independently administered “domains”

Emerald: Divide and Conquer • Three levels of monitoring: • Service monitors: local level • Domain monitors: monitor independent “domains” • Enterprise monitors: the “big picture” • Cross-level communication channels are established to share useful information amongst any monitor that might gain by doing so

Emerald: Divide and Conquer • Different monitors for different attacks: worms would show up at the enterprise level, while a targeted attack to break into a database would show up on the service monitor for that service • Manages “profiles” to select systems to be monitored and types of alerts to trigger • Configuration can be very complicated. Still very much a work in progress

NetSTAT • Began at UCSB in the early 90s • State transition-based: certain action sequences indicate malicious behavior • Audit-trail analyzer abstracts audit information, making it more portable and understandable • Functions as a state machine moving towards “compromised” state • Began life as host-based system

NetSTAT • Uses an inference engine, which determines likelihood of violations and notifies “decision engine” for possible action • State-machine can identify attacks before they succeed, allowing preventative action • States fork as multiple actions move away from a single state; any fork can reach a “compromised” state and set off an appropriate alert

NetSTAT • Each of these state machines is deployed across the network. They communicate in a decentralized manner. Individual probes may subscribe to event streams to see related activity at other probes. • A stand-alone analyzer manages and initiates probes and aggregates information using its own analyzer engine • The analyzer engine uses a network “fact base” along with a “scenario base” to determine which vulnerabilities exist, and then communicates with the manager to deploy appropriate probes to mitigate the threat

Bro • Research tool with broad goals being developed at Lawrence Livermore NL. Bro has several advanced design goals: • High-load monitoring: many systems drop potentially valuable packets when load gets too high • Real-time notification: worm attacks, DoS, etc, require very fast reaction times • Separating policy from mechanisms: cleaner, clearer implementation, easier to enact policy • Extensibility: New and different attack techniques are being constantly developed, an IDS that can’t keep up is useless • Secure: Preventing IDS compromise substantially enhances the IDS’s ability to maintain a secure environment

Bro • Three-level hierarchy: • Network level: libpcap is used to filter unwanted packets and pass the rest up to the next level. This rejects many packets that are uninteresting with minimal processing overhead • Event level: Performs sanity and integrity checks, then events are generated and placed on a queue to the next layer • Policy level: A “policy script interpreter” reads events off the queue and evaluates them. It records statistics, generates new events, and logging real-time alerts

Bro • Bro is limited to finger, ftp, portmapper and telnet, but is highly extensible • Extending bro is “easy” according to the author, but appears to have a high learning curve

Commercial Tools • Commercial offerings tend to be more “complete” but less sophisticated than research tools • Commercial tools use simple hierarchies, generally mimicking a backup network or power supply notification network • Commercial tools are much easier to deploy and configure, making them possibly more useful despite their shortcomings

Public Domain Offerings • Unsupported offshoots of commercial ventures. Many are being removed by the commercial owners for various reasons • Tend to require a high level of user sophistication to implement. • Tripwire: a file-system integrity checker, which can be helpful in noting both attacks and post-mortem analysis (ie root kit removal). • Available for free, but the free version is old and the commercial version appears to be far more sophisticated

Government OTS IDS • Government has substantially tighter requirements. Not driven by liability or profit concerns • Cyber-terrorism risk means government is at high risk of coordinated sophisticated attacks far exceeding attacks on commercial sites

Government OTS IDS • Sophisticated attacks on commercial sites are also possible, and may represent “soft targets” for terrorists, especially if the goal is to cause economic disruption (9/11 economic losses were far more damaging than loss of life to US at large) • Government needs to determine the intentions and origins of attacks, not merely detect and prevent them • Commercial vendors have no incentive to develop objective standards to evaluate their systems

GOTS cont… • GOTS systems display a high level of sophistication and aggregation, but are very complicated to set up and generally not available to the public • Mature sensor network written for many platforms in languages ranging from bourne shell to assembly

Does anyone actually care? Real-world IDS deployment, limitations, and issues

What do people think IDS does? • Increase integrity • Analyze logs and other obfuscated sources. Make sense of it all • Automate vulnerability detection, reduce staff load • Allow non-experts to manage the system • Assist in setting security policy • Trace users through the system • Recognize attacks, alert appropriate individuals • Perform OS audits

What do they do? • Not what people think • Current view of IDS is somewhat idealized. IDS “could” do these things, but it doesn’t • Most intrusions spotted by other methods

Growth of IDS deployment • ID systems are becoming all but standard in some industries • Seen as a time-saving measure, biggest impediment to improving security is generally “lack of time” • Growth is perhaps too rapid, users are incompletely evaluating the benefits (and limits) of ID systems

The Bandwagon Effect • Look to others for guidance • “Best practice” approach; deployment prevents shareholder liability. Only need to do as well as competitors • Management making technical deployment decisions • Technical staff may be forced into premature decisions, tendency to simply agree instead of argue • Developing effective IDS provides little benefit from the “big picture” until an attack has already occurred. • Most claims by vendors unsubstantiated, most user perceptions inaccurate and unfounded

Testing IDS • Simple test environment: full mirroring of DMZ traffic to ID system

Test environment drawbacks • Drops packets under high load: mirrored port not high-bandwidth enough • Not scalable. If the network layout were more complex, a single location would not suffice • Does not test distributed aspects of NIDS • Host-based IDS not deployed on servers due to resource that would require

Observations on IDS • Most systems required both a secure and insecure interface for installation • Open to attacks on IDS to bypass firewall, Network Access control, etc • Fix: read only on insecure side • Drawbacks: cannot use automated response tools • Allen et al think this is okay, but only because they don’t trust IDS

Observations on IDS …cont • Installation is much simpler with commercial software. This seems in line with commercial vs “free” software at large. More managed user experience • Configuration was generally obtuse and hard to use, even with commercial graphical interfaces. Sophistication, such as category grouping, is lacking

Benefits of IDS • IDS can provide some unintended secondary benefits • Firewall policy confirmation: a NIDS may detect packets the firewall should have, but did not, stop • Version/Patchlevel checking: If a machine is not patched, the NIDS may detect this fact and alert operators • Could be deployed to specific services or subnets if load is excessive

Shortcomings • Commercial systems are very closed, don’t provide packet dumps or signature algorithms • Desire to outdo competitors often means products are released prematurely • Closed nature prevents true forensic analysis, logs may be incomplete • Products are simply not mature at this time, this may change but not quickly

The IDS of tomorrow, next week Directions of IDS systems, further complications, changes in attacks

The future of IDS • Attackers are becoming rapidly more sophisticated, far outpacing IDS • IDS need to be more proactive, detect warning signs such as probes, penetration testing, target list compilation • Systems and network software has become incredibly complex, and with that complexity has come a general decrease in security • Application vulnerabilities translate to attacks very rapidly due to toolkits, signatures must keep up

Source of Attacks

New Technologies • Sophisticated technologies carry new risks • Counter-IDS tools such as Anti-sniff • Encrypted messaging: IDS cannot scan packet contents • IDS systems become primary targets. They are trusted, and so can provide added access. Taking them out early reduces detection risk • Modems and wireless networks provide backdoors into secure networks • Mobile malcode such as email worms penetrate at the application layer. Most IDS do not scan this deeply, although that is likely to change

Intrusion Detection