1 / 74

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

gella
Télécharger la présentation

Intrusion Detection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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.

  3. Incidents Increasing

  4. 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)

  5. 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

  6. Intrusion Detection Systems Detecting attacks and preventing intrusions

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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.

  12. …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.

  13. …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.

  14. 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

  15. 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

  16. 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

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

  18. Where are we now? Extant Intrusion Detection Systems

  19. 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

  20. 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

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

  22. 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”

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

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

  37. 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

  38. 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

  39. 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

  40. 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

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

  42. 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

  43. 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

  44. 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

  45. 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

  46. 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

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

  48. 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

  49. Source of Attacks

  50. 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

More Related