• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Five IDS mistakes people make

Five IDS mistakes people make



The article covers the typical mistakes organizations make while deploying an IDS.

The article covers the typical mistakes organizations make while deploying an IDS.



Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.lmodules.com 1



Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Five IDS mistakes people make Five IDS mistakes people make Document Transcript

    • Five IDS mistakes people make
      Anton Chuvakin, Ph.D., GCIA, GCIH
      WRITTEN: 2003
      Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around.
      The article covers the typical mistakes organizations make while deploying an IDS.
      The network intrusion detection systems are in the process of becoming
      a standard information security safeguard. Together with firewalls and
      vulnerability scanners, intrusion detection is one of the pillars of
      modern computer security. While the IDS field is still in motion,
      several classes of products have formed. Most IDS products loosely
      fall into network IDS (NIDS) and host IDS (HIDS).
      Network IDS usually monitors the entire subnet for network attacks
      against machines connected to it, using a database of attack
      signatures or a set of algorithms to detect anomalies in network
      traffic (or both). Alerting and attacks analysis might be handled by a
      different machine that collects the information from several sensors,
      possibly correlating IDS alers with other data.
      It appears that stateful and protocol-aware signature-based network
      IDS is still the most widely deployed type of intrusion
      detection. Simplified management and the availability of inexpensive
      NIDS appliances together with dominance of network-based attacks are
      believed to be the primary reasons for that.
      In this brief article we will review several importnat mistakes
      companies make while planning and deploying the IDS systems. In
      addition to the obvious mistake (0th, I guess :-)) of not evaluating
      and deploying the IDS technolgy at all, the issues we cover often
      decrease or even eliminate the added value the companies might
      otherwise derive from running an intrusion detection systems.
      1. Since we already covered the trivial case of " not using an IDS" ,
      the first mistake we discuss is using it without giving it an ability
      to see all the network traffic. In other words, deploying the network
      IDS without sufficient infrastructure planning. Network IDS might be
      deployed on the network choke point (such as right inside or outside
      the firewall), on the appropriate internal network segment or in the
      DMZ to see important traffic. For the shared Ethernet-based networks
      IDS will see all the network traffic within the Ethernet collision
      domain or subnet and also destined to and from the subnet, but no
      more. For the switched networks, there are several IDS deployment
      scenarios which utilize special switch capabilities such as port
      mirroring or spanning. Additionally, one might procure an IDS
      integrated with a switch, such as Cisco IDS blade.
      2. The second mistake occurs when the IDS is deployed appropriately,
      but nobody is looking at the alerts it generates. This one is actually
      much more common than it seems. It is well-known that IDS is a
      " detection" technology, and it never promised to be a
      " shoot-and-forget" means of thwarting attacks. While in some cases,
      the organization might get away with dropping the firewall in place
      and configuring the policy, such deployment scenario never works for
      the intrusion detection. If IDS alerts are reviewed only after a
      successful compromise, the system turns into an overpriced incident
      response helper tool - clearly not what the technology designers had
      in mind. It still helps, but isn't it better to learn about the attack
      from the IDS rather then from angry customers? Being the form of
      monitoring and network audit technology, IDS still (and likley always
      will, unless its intelligence improves by orders of magnitude)
      requires a skilled personnel to run.
      3. Network IDS is deployed, " sees" all the traffic and there is a
      moderately intelligent somebody reviewing the alert stream. No more
      mistakes? Far from it! What is a response policy for each event type?
      Does the person viewing the alerts know what is the best course of
      action needed for each event (if any)? How to tell normal events from
      anomalous and malicious? What events are typically " false positives"
      (alerts being triggered on benign activity) and " false alarms" (alerts
      being triggered on attacks that cannot harm the target systems) in the
      protected environment? How to gather the required context information
      to answer the above? Unless the above questions are answered in
      advance by means of a response process, it is likely that no
      intelligent action is being taken based on IDS alerts - a big mistake
      by itself.
      4. All the previous pitfalls are avoided and the NIDS is humming along
      nicely. However, the staff monitoring the IDS starts to get flooded
      with alerts. They know what to do for each alert, but how quickly they
      can take action after receiving the 10,000th alert on a given day?
      Unfortunately, current network IDS systems have to be tuned for the
      environment. While the detailed guide for IDS tuning is beyond the
      scope of this article, two general approaches are commonly used. One
      approach is to enable all possible IDS rules and spend several days
      flooded with alerts, analyzing them and reducing the rule set
      accordingly. This route is more appropriate for internal network IDS
      deployment. Another solution is to reduce the ruleset to only watch
      the " risky" services. This works better in a highly secure DMZ setup
      where all machines are carefully audited and hardened.
      5. The last mistake is simply not accepting the inherent limitations
      of network IDS technology. While anomaly-based IDS systems might
      potentially detect an unknown attack, most signature based IDS will
      miss a new exploit if there is no rule written for it. IDS systems
      have to be frequently updated with vendor signature updates. Even if
      updates are applied on a timely schedule, the exploits which are
      unknown to the IDS vendor will likely not be caught by the
      signature-based system. Attackers may also try to blind or evade the
      NIDS using many tools available for download as well as,
      undoubtefully, a large collection of non-public tools. There is a
      constant battle between the IDS developers and those wishing to escape
      detection. IDS are becoming more sophisticated and able to see through
      the old evasion methods, but new approaches are created by
      attackers. Those deploying the network IDS technology should be aware
      of its limitations and practice " defense-in -depth" by deploying
      multiple and diverse security solutions.
      This is an updated author bio, added to the paper at the time of reposting in 2009.
      Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books " Security Warrior" and " PCI Compliance" and a contributor to " Know Your Enemy II" , " Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry.
      In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups.
      Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.