Intrusion Detection by wangnianwu


									 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
• 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
• Attacks can have multiple victims or attackers
Intrusion Detection Systems

  Detecting attacks and preventing
              Goals of IDS
• Answer the questions:
  – What happened?
  – Who was affected? Who was the attacker?
  – How are they affected? How did the intrusion
  – 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.
• 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.
• 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
        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
• 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
Where are we now?

Extant Intrusion Detection
             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
  – NetSTAT
  – Bro
• Event Monitoring Enabling Responses to
  Anomalous Live Disturbances
• Research began in 1983
• Uses both signature and anomaly detection
• 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
   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
   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
• 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
• Functions as a state machine moving
  towards “compromised” state
• Began life as host-based system
• 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
• 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
• 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
• 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
  – Secure: Preventing IDS compromise substantially
    enhances the IDS’s ability to maintain a secure
• 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 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
• 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
          Government OTS IDS
• Government has substantially tighter
  requirements. Not driven by liability or profit
• 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
            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
• Management making technical deployment
• Technical staff may be forced into premature
  decisions, tendency to simply agree instead of
• Developing effective IDS provides little benefit from
  the “big picture” until an attack has already
• 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
• 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
  – 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
• Firewall policy confirmation: a NIDS may detect
  packets the firewall should have, but did not,
• Version/Patchlevel checking: If a machine is not
  patched, the NIDS may detect this fact and alert
• Could be deployed to specific services or
  subnets if load is excessive
• Commercial systems are very closed,
  don’t provide packet dumps or signature
• 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
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
Source of
           New Technologies
• Sophisticated technologies carry new risks
  – Counter-IDS tools such as Anti-sniff
  – Encrypted messaging: IDS cannot scan packet
  – 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
• Choke-point type NIDS, depending on
  observing at the border router, are
            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
• 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
• 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?
• 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
• 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
• 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
  – 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
• 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
– 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
– Work more closely with the research community
• 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

To top