Daniel,
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
hours.
- 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
resources.
- 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
rationalization.
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
(deterrence).
Cheers,
Maarten
--
Maarten Van Horenbeeck, GCIA <maarten@daemon.be>
http://www.daemon.be/maarten
--------------------------------------------------------------------------
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 http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to
learn more.
--------------------------------------------------------------------------
