Intrusion Detection

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 ModelsSignature 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 systems normal state

11
Analysis ModelsSignature 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
  isnt 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 cant keep up is useless
• Secure Preventing IDS compromise substantially
  enhances the IDSs 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 doesnt
• 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 dont 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, dont 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

51
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

52
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

53
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

54
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

55
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

56
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

57
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 dont 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

58
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

59
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

60
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

61
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

62
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

63
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

64
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

65
Dont you want me, baby?

• Why not secure the network?

66
Motives

• There are many reasons why you might be attacked

67
Do what I say

• Advice on IDS deployment and research for the
  community

68
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

69
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

70
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

71
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

72
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

73
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

74
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