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

Network Issues

• Systems must be written from the ground up to scale on large, diverse, multihomed networks

• Choke-point type NIDS, depending on observing at the border router, are insufficient

Network Issues

• Some research tools, such as Emerald, are specifically engineered with this in mind

• Operating systems are not written to be secure. IDS are increasingly being deployed to “band-aid” this situation

• IDS tools do not communicate with each other. Proprietary formats and the competitive market prevent system from sharing data and hence leveraging larger and more complete ID views of the network

Network Issues

• Switched networks deny IDS a complete view of the network. Port mirroring is often not able to keep up with the high volume switched traffic

• Even simple encryption such as SSL can stifle an IDS. If a web server is simply mirrored to SSL, server vulnerability signatures will be ineffective since the IDS cannot read the packets

The Human League

• Lack of trust, cooperation in a competitive environment prevents optimal leveraging of information

• Competitors ought to share vulnerabilities in industry-standard software, but often do not, even when they may ultimately stand to benefit from such cooperation

The Human League• IDS only present finalized analysis, but showing

incomplete analysis to humans might be very useful. People are “very good at pattern matching” Countered by desire to use less-skilled employees with an IDS

• ID systems are good at spotting attacks, but cannot determine goals or motives, which may be useful in capturing attackers or preventing future attacks

• No standardized taxonomy is used, so determining what a system is saying is itself a task. Clarity and precision are needed to optimize human-computer interaction, and would also aid in cross-platform IDS communication

Future Changes• The community, particularly commercial segments,

can move very quickly once decisions are made. IDS will become more sophisticated very rapidly if there is demand for superior products

• Preemption: the speed of attacks as well as the damage they cause makes it desirable to act to prevent an attack before it completes. This includes detecting early warning signs and preventing reconnaissance

• Attack scenarios which can be generically be detected should be more common

Future Changes

• IDS should be able to take automated action, such as enhanced packet filtering or black-holing, as appropriate, without human intervention

• Of course, currently, the authors don’t trust IDS enough to actually let it take action given the current state of the art. This is one area that shows a great deal of potential, and tools designed to stop limited activity such as portscans are already successfully deployed

Future Changes• IDS are not very sophisticated at providing

useful information for a complete post-mortem of an attack.– Provide limited audit trails, and are almost never

useful in recovering lost data or even determining what may have been done.

– Tripwire is notable in its utility in this area

Future Changes• IDS still do not keep up with high loads,

especially as will occur with Flash Events or DoS attacks. – Even worse at countering attackers intentionally

draining IDS resources. – A DoS on the ID system can render the system

largely ineffective. – Distributed systems help to counter this threat

Future Changes• IDS do not easily detect unknown attacks. Signature

systems tend to be completely ineffective at unknown vectors, while analysis systems fare better. Analysis systems tend not to detect new classes of attacks, or stealth attacks, so a stealthy attack on an unknown vector is likely to go completely undetected

• IDS signatures do not keep up with the malware community. Toolkits mean exploits are available long before ID signatures. Without signatures, signature systems become largely useless, unless they have good logs from which a human can construct a new signature. At present, this is generally not the case

Future Changes• IDS are not easily evaluated. Some sort of standard

benchmarks would be useful, but are not present because there is actually commercial incentive not to develop these benchmarks. – A third party like Consumer Affairs or United Laboratories

would be a tremendous asset to the community

• Bizarre traffic patterns can often be false alarms. While on testbed networks such unusual traffic as hundreds of FIN packets will only occur under a simulated attack, downright strange things can occur on large widely deployed networks

Data Analysis

• ID systems generally lack sophisticated data analysis tools, especially interactive tools to help a human further analyze events

• Data is not sufficiently aggregated: If a million SYN packets are flooded in, it is of course not necessary to record every packet in its entirety. Counting sources by netblock is often sufficient, and only a random sampling of full packets need be saved

Data Analysis

• Data is not sufficiently categorized: anomalies should be easily grouped and regrouped by time, network location, type, duration, etc to make trends more obvious

• ID systems do not attempt to preserve forensic-class evidence: systems should save data streams associated with suspicious events for some period of time; such tracebacks can be highly valuable to the FBI or other forensic specialists. This would be the equivalent of a surveillance camera

Advanced Research

• Better-learning IDS, through neural nets or heuristic (Bayesian) learning could help to identify unknown attacks

• Genetic algorithms

• Data fusion: more complex analysis and better data aggregation

• State transition: NetSTAT uses this model

Don’t you want me, baby?

• Why not secure the network?

Motives

• There are many reasons why you might be attacked

Do what I say…

Advice on IDS deployment and research for the community

Practical IDS Deployment

• A properly deployed IDS requires management to support the technical staff in deploying a sound solution

• The IDS should be deployed as part of a consistent defense-in-depth strategy

Practical IDS Deployment

• The IDS should not be expected to perform “miracles” or any other tasks outside of the scope presented here

• ID systems should not be seen as a replacement for competent and consistent staffing

• Outsourcing will become commonplace. It is important to find a contractor the organization can trust, as IDS sometimes carry highly sensitive information

Recommendations

• Users– Be aware of organizational issues that will

impact IDS use and deployment– Use a layered “defense in depth” approach to

asset protection– Make a full assessment of your needs before

selecting an IDS. Consider the larger context of your security policy when doing so

Recommendations

• Administrators and Operators– Maximize performance by: Installing application-

specific IDS around key or vulnerable applications. Limit false positives, as they will eventually impact your response times. Turn off unneeded scans and signatures ie if you do not run windows on that subnet, there is no need to monitor for a netbios exploit

– Analyze your data, respond using clearly laid out procedures. Develop response procedures in advance. Do not fly by the seat of your pants. Keep extensive audit trails

Recommendations• Vendors

– Model the IDS community after the antivirus community. Share information, make updates straightforward and automatic, and make your software flexible

– Encourage development and testing of signatures in a wider environment. Provide users the resources to conduct further testing when needed

– Provide fine-grained evaluations of your product, and of the efficacy of individual signatures. Indicate which are prone to more false positives

Recommendations

– Make it easy for humans to be involved in the process, do not overautomate at the expense of accuracy or reliability

– Use more complex data manipulation, and aggregate data more efficiently. Be prepared for more distributed stealth attacks

– Provide superior forensic capability– Enhance application-layer scanning for malicious

malcode– Work more closely with the research community

Recommendations• Research

– Extended IDS testing– Reduction of false alarm rates– Provide target-oriented taxonomies for attacks– Develop methods to detect and counter attacks on

the ID system– Develop enhanced methods for human-IDS

interaction. Consider in particular more abstraction-oriented interfaces

– Coordinate more with the vendor community