Re: IPS, alternative solutions

From: Maarten Van Horenbeeck (
Date: 09/22/04

  • Next message: Mike Frantzen: "Re: IPS, alternative solutions"
    Date: Wed, 22 Sep 2004 08:38:58 +0000 (GMT)


    I have the impression that some of the alternatives to IPS you mentioned
    are actually part of the IPS technology arena. A strict definition of what
    intrusion prevention systems comprise does not exist, and as such the name
    in itself also applies to e.g. firewalls. There is a large market theatre
    in which different types of IPS technologies are currently being deployed,
    with varying degrees of succes. Parts of the market have matured (network
    firewall solutions), while some are still considered "difficult"
    implementations (in-line protocol decoding and blocking/active response
    --which most people consider IPS).

    Some of the well known alternatives:

    - Intrusion Detection with human response
    In large networks, an often deployed technology at this time is
    implementation of intrusion detection technology (both host- and network
    based) in combination with 24hr response. Events are flagged by security
    engineers in real time, tickets are created and followed up as soon as
    possible by the necessary incident response personnel. Detection of
    events, in such case, is often outsourced to a service provider, so that
    the organization can focus on responding to the threats reported.

    This is a very effective framework due to the fact that it can be used to
    trigger on both known (network IDS), and unknown (network anomaly
    detection, host IDS) attacks. Physical security principles dictate that
    not all attacks can be prevented in each specific situation. What is
    important, is that we detect when an attack takes place, and have the
    necessary capability to respond and eliminate the threat at hand. This is
    the main reason that even though bank doors have advanced locks, they
    still have systems which detect when the door opens outside of business

    - Host based exploit prevention (e.g. address space randomization,
    non-executable pages)
    While the thought given to designing these solutions is often intense,
    they still tend to be easy to implement -- provided only a limited number
    of applications needs to be supported on them. Due to the fact that
    most of them change the reference monitor used to screen events, they do
    tend to decrease overall performance of a system. Logging is often
    non-existant or difficult to centralize, and most of the software
    solutions in this field have had a troubled youth (the initial version of
    stack protection on Windows 2003 was defeated fairly quickly, as well as
    many others). This type of software is usually very helpful in stopping
    stock exploits, but may not be as secure against an attacker with enough

    - Application Firewalls (e.g. DMZ/Shield, Interdo, Appshield)
    One of my personal preferences. While I must admit that I work for a
    company which develops one of these solutions, application level filters
    have always been an effective method to scrub inbound traffic. When
    correctly configured, these tools can truly limit traffic for backend
    servers to those sessions which do not contain malicious content, or at
    least malicious content which will not affect those servers. Main issue
    here is that configuration requires in-depth knowledge of the protocols
    affected. When knowledge is lacking in this perspective, configuration
    will be less than ideal. As such, this type of technology should
    inherently be deployed in combination with a professional audit of the
    policies. For most protocols and applications, these solutions are
    scalable, as they can be combined with other load balancing solutions
    (e.g. content switches for HTTP, round-robin DNS for SMTP).

    - Host based Firewalls
    As most operating systems have built in packet filtering tools, these
    should actually be part of hardening methodologies for servers. However,
    they do not block any application level attacks, and deployment for client
    machines could prove difficult. Centralized policy management is a
    requirement, but not always feasible due to different LAN locations and
    differing connection patterns between hosts. This type of protection
    tends to scale really well on well-structured networks. Networks with
    large amounts of legacy operating systems are not commonly considered
    suitable implementation beds without some prior review and

    There is no one solution which meets all needs, and depending on the
    assets you are trying to protect, any or none of the above combinations
    may be sufficient. I do believe it is at all times important to make sure
    that each of the prevention, detection and response bases are covered. In
    order to protect our infrastructure, we initially need to prevent people
    from getting in (using IPS: firewalls for network border controls,
    application firewalls for application level screening). We also need to
    identify people who are trying to get in (usually solved with a
    combination of host- and network IDS). Last, but not least, we need to
    respond to any incidents which may still occur (incident response). IPS
    has its place in the incident lifecycle, but it should not be seen as a
    one-size-fits-all solution, if your assets are truly important to you.

    To compare this to physical security: We need a good lock on our car to
    keep thieves out. We also need an alarm to tell us somebody is trying to
    get in, and we do pay taxes to have police available who can catch the car
    thieves and prevent similar thefts from occuring in the future


    Maarten Van Horenbeeck, GCIA <>
    Test Your IDS
    Is your IDS deployed correctly?
    Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
    Go to to learn more.

  • Next message: Mike Frantzen: "Re: IPS, alternative solutions"