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 wellsecured, 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 1990 s, but most tools were student projects that were dropped when research was completed • Three main research systems in use today – EMERALD – Net. STAT – 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 userassigned, 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
Net. STAT • Began at UCSB in the early 90 s • 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
Net. STAT • 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
Net. STAT • 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 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, Do. S, 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 realtime 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 “bandaid” 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 blackholing, 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 Do. S attacks. – Even worse at countering attackers intentionally draining IDS resources. – A Do. S 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 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 forensicclass 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: Net. STAT 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 applicationspecific 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
Скачать презентацию Intrusion Detection Advances Problems and all the politics
342c52f0b55c28cd38ac4cd92becd72b.ppt