Introduction IDS

Writing about the future is a risky venture. More than likely, one will end up wrong, or worse yet - so far off
that memories of the forecast bring waves of embarrassment. There is, however, the slightest chance of
success; lucky for me then that the task at hand, a discussion of the future of Intrusion etection !ystems
"I!#, is a bit easier to model.
I!, much like the security industry itself, has grown rapidly over the past few years. These tools have
become essential security components - as valuable to many organi$ations as a firewall. %owever, as in any
environment, things change. &etworks and crackers are evolving fast, demanding that security tools keep up.
Intrusion etection !ystems face several daunting, but e'citing challenges in the future and are sure to
remain one of our best weapons in the arena of network security.
Past and Present
(n Intrusion etection !ystem monitors machines or networks for anomalies, attempted breaches,
compromises and general misuse. )or many, myself included, the term I! immediately con*ures up images
of network-based tools like !nort, !hadow or any one of a myriad of commercial packages. It+s interesting to
note then, that the earliest forms of I! can be traced back over ,- years. These initial programs focused on
discovering security incidents via recurring reviews of system audit logs and accounting files - much like
modern log analy$ers such as !watch. These programs evolved over time, incorporating real-time log
monitoring and more elaborate system checks, and are now referred to as %ost-.ased Intrusion etection
!ystems "%I!#. More recently, we have witnessed the rise of the &etwork-.ased Intrusion etection
!ystem "&I!#. These applications began as packet sniffers that ran captured data against a set of rules or
filters, flagging those that appeared to be malicious in nature. Today, &I! signatures are created and
released /uickly in response to new e'ploits, serving as one of our best defenses. Many of us *uggle
elaborate rule-sets to catch the latest, greatest attacks as well as the classics. Which brings us to present day.
Problems for the Modern IDS
Most network managers can attest to the rapid rise of the switched environment. 0nce an e'pensive
alternative to the ubi/uitous hub, switches now dominate both the commercial and home networking
markets. (nd who+s complaining1 !witches offer better performance in most situations and protect against
packet sniffers by sending traffic only to intended ports. %ubs, on the other hand, simply copy all
information to every available port. !ince &I! are packet sniffers at their core, the switched network
creates a definite problem. There are countermeasures, but they bring additional comple'ity and costs. %igh-
end switches incorporate management and configuration consoles that include port mirroring and spanning
options, copying all data sent to a range of ports to one designated as the mirror. The I! would then be
connected to the special port. In theory, this works great, but the reality is a bit more harsh. ( network with
heavy traffic will /uickly bog down the switch itself. 2ven worse, the I! will miss packets if the mirrored
traffic is higher than the amount allowed by the designated port. 3ompanies such as !homiti !ystems
provide e'cellent hardware solutions, network taps, which solve the full-duple' problems but raise the setup
cost.
( big reason many networks operate in a switched environment can be attributed to the performance
benefits. This speed increase is necessary due to the overall increase in traffic volume that most
organi$ations are e'periencing. 0bviously, there are limitations to how much traffic can be handled by an
I!. These performance claims are often some of the strongest selling points for commercial products, some
of which can handle gigabit levels. %owever, with more traffic comes the bane of I! - false positives.
(nyone with Intrusion etection e'perience has waded through alerts and logs, and analy$ed the flagged
traffic, only to discover that a si$eable percentage was harmless. The corollary risk of this is that the admin
will skim log files so /uickly, thanks to numerous false alarms, that they miss the real threats. (nd how do
we reduce these nuisances1 !ome narrow their filters via precise tuning, while others e'pand the rule-set to
ignore the offenders. What a cycle - more traffic brings an increase in false alarms, but more rules hurt
performance. Moreover, specific filters miss subtle variations of old attacks , while generic rules increase
mistakes. It+s enough to make a security guru scream4
5
I! performance issues are common complaints. We all have false positive horror stories. Thankfully, speed
is continually enhanced by vendors and open source developers, as are false positives. I!! 6eal!ecure 7.- is
hoping to eliminate false positives altogether, saving organi$ations time and money. %owever, a more
serious problem threatens the very e'istence of &I! - encryption.
%ow many of you couldn+t live without !!%1 Me too. The dream of universally encrypted traffic is rapidly
approaching. I8v9 and large wireless networks spell trouble for the payload analysis used by most &I!.
The signatures many of us depend on won+t help much if they can+t be matched against any data. !o what
does this mean1 Well for one, no more false positives4 .ut should we *ust forget about the concept of
Intrusion etection1 0f course not, lets look at how future products will tackle all of these challenges.
Immediate Future
:et+s address the two ;easy< problems first, switched networks and traffic increases. I have no doubt that
I! vendors "commercial and open source# and hardware will keep pace with network traffic increases. The
top performing packages will come at a steep price, as will the hardware they re/uire, but the organi$ations
that demand such results can usually afford it. (s we discussed earlier, there are already some workarounds
for &I! in a switched environment. I also look forward to more applications such as %ogwash "based on
!nort#, an in-line ;packet scrubber<. ( device like this could sit invisibly between two networks and monitor
all traffic e'changed, regardless of switches or hubs, while remaining immune to attack attempts. The future
is off to a bright start.
( more challenging problem being addressed right now is analysis and correlation. &o matter how good the
I! analyst, we are only human. (buse such as slow port scans are difficult to detect, especially on large
networks. 8ro*ects such as !pice and !pade are working to make it easier. (cting as anomaly detectors, they
e'amine strange packets and look to group them using sophisticated statistical analysis. Tools like these aid
the I analyst by pulling out ;needles in the haystack< and bringing them to our attention. It+s much easier
to discover and categori$e patterns when you have all the relevant data in front of you, without the noise that
generally follows. )urthermore, applications similar to these will be used to fine tune filters and rules in
order to reduce false positives, over time providing a kind of I! feedback system, based on administrator
input and response.
Long Term
While attending an I! wish list discussion at the .altimore !(&! conference, I noticed that one topic
dominated the conversation= correlation. It+s no coincidence then that it+s the ultimate theme of this article=
the future of I! lies in data correlation. The I! of tomorrow will produce results by e'amining input from
several different sources. I believe the notion of &I! and %I! will disappear, leaving us with a group of
distributed components performing specific tasks. I+ll e'plain *ust what each of these components needs to
do in order for this model to succeed.
The concept of %I! plays an important role in this scenario. 2ncrypted traffic demands that we shift packet
analysis, an important part of I, to the host. It is difficult to find another solution. There is however, a
distinct advantage gained by using this method of analysis. The signatures can be tailored to one host, as
opposed to the heterogeneous mi' of Microsoft, >ni' and application specific rules in place on most &I!.
Moreover, a recurring scan could /uickly monitor which services and programs run on a machine, allowing
for an even more precise rule-set. !o, instead of a sensor capturing all traffic on a network, the client
machines will monitor their own traffic. Many of us are already doing simple network analysis on personal
machines. I run Tiny 8ersonal )irewall on Windows machines, and !nort or !hadow on >ni' bo'es. .ut the
client machines need to do more - tasks similar to those that current %I! perform. (pplications such as the
:I! pro*ect, provide kernel and 0! specific modifications which can monitor logs, administrative actions,
system accounting and data integrity in real-time. >nfortunately, the results stored by such programs are
usually only reviewed by an administrator when a user+s machine has been compromised. In the future, this
won+t have to be the case, as clients will automatically report data to centrali$ed monitoring stations. :et+s
look at how this will make security administrators+ *obs easier.
(t the center of this new I! model lies a familiar concept - the management station. This bo', similar to
current &I! consoles in a multi-sensor environment, will analy$e flagged traffic reported by the distributed
,
client machines. .ut now, this I! ;server< is dedicated to analysis and correlation - no longer is it re/uired
to capture and filter data for diverse environments. This machine+s sole purpose is to present a security
manager with the most pertinent information culled from the individual hosts. (dditionally, each client+s 0!
monitoring results will be reported and analy$ed. In this fashion, we could have an incident or intrusion
;snapshot<.
Imagine the scenario - an administrator is paged from the console. %e or she /uickly gets access to the
machine only to learn that ?oe+s computer in the accounting office has sent an alert - several of his system
files have been modified. The console also presents the administrator with summaries and graphs of recent
traffic reported by ?oe+s %I!, as well as those on the accounting network. (n attacker has scanned the
entire network looking for susceptible machines, found one with ?oe and e'ploited the hole in an outdated
%TT8 server that was left running. 2ven worse, ?oe+s machine has reported a lot of outgoing traffic directed
at one particular e'ternal machine. The console+s analysis has labeled this anomalous behavior as a potential
o! attack. &ow our administrator has a concise report of what happened - e'ploit scan and successful
attack, why it happened - outdated %TT8 server, and the results - corrupted system files and malicious out-
bound traffic. I don+t know about you, but that could sure save me some time. 0ur administrator can /uickly
review the client configurations which are readily available at the console, thanks to the recurring scans
taking place, learn that no other machines have the vulnerable server in place and proceed to cleaning up
?oe+s machine.
The future of I! looks promising, if the above model can emerge. .ut how it can be done1 %ost machines
need to constantly look for behavior "network or system# that is designated as malicious or strange.
Malicious events may be discovered using pattern matching on system logs and network traffic. !ince the
patterns are recogni$able actions or triggers, albeit evil ones, they can be found by reviewing the data and
comparing it to known signatures. This type of setup e'ists today in virtually every firewall and I! - traffic
analysis based on distinct patterns. We *ust need to e'pand the process to analy$e system events as well;
several individual programs that do this are available. (bnormal events are easy to detect, but difficult to
understand.
The way to solve this challenge lies in statistical analysis and predictive artificial intelligence performed on
strange data sets. The management console, having received these abnormal event notifications from many
clients, needs to concentrate on possible relationships, relevance and correlation. It needs to determine the
likely triggers for such infre/uent events. Moreover, the console will need to communicate with multiple
pieces of the network architecture= firewalls, routers, switches and even different I systems. In the future,
an I! protocol or reporting format will be a re/uirement= routers could relay !&M8 traps and network
statistics, firewalls could transfer failed packets for analysis and different I systems could e'change
findings. The possibilities are endless, leaving us with the definitive network monitor, manager and security
package, thanks to the pooled efforts of each individual component.
Conclusion
I have no doubt that the I! is here to stay, although future systems will undoubtedly take a different form
than our modern day versions. The ideas presented here, while optimistic, are attainable. The mathematical
and (I "artificial intelligence# concepts re/uired for success are already being developed, tested and
improved upon. !6I has a great start with the &I2! and 2M26(: pro*ects, using a distributed model
similar to what is outlined above. I!! is developing products that will scan networks for vulnerabilities and
modify the I! filters based on the results. :ancope+s !tealthWatch uses a ;flow-based architecture,< which
can recogni$e abnormal behavior. !everal other features outlined above are being incorporated into
upcoming products, all of which will improve with time and research.
>ltimately, I think that future I! will merge all of the independent network components and tools which
e'ist today, into a complete and cooperative system, dedicated to keeping networks stable. There will be
many distributed elements performing specific *obs, each passing the results onto a higher level for
correlation and analysis. (s always, the ultimate authority will be our own *udgment.
@
NEED OF IDS
B !oel Snder
While threat management continues to be a top priority, it is more important than ever for cash-strapped
security professionals to fully understand the functionality of intrusion defense tools in order to make good
purchasing decisions.
Intrusion defense systems "I!# and intrusion prevention systems "I8!# are a particularly confusing area
because the products are so similar, the vendors are all the same, and even the acronyms are hard to tell
apart. WeAll e'plain the capabilities of each and how to decide whether you need one or both technologies.
DIFFE"ENTI#TIN$ IDS #ND IPS
(n I8! is not the same as an I!. %owever, the technology that you use to detect security problems in an
I! is very similar to the technology that you use to prevent security problems in an I8!.
ItAs important to start out with the understanding that I! and I8! are very, very different tools. 2ven though
they have a common base, they fit into the network in different places, have different functions, and solve
different problems.
(n I8! is best compared to a firewall. In a typical enterprise firewall, youAll have some number of rules=
maybe a hundred, maybe a thousand. Most of those rules are BpassB rules= Ballow the traffic through.B Thus,
the firewall gets a packet off the wire and starts through its rules, looking for a rule that says Ballow this
packet through.B If it gets to the end of the list and thereAs no rule saying Ballow this packet through,B then
thereAs a final BdenyB rule= Bdrop everything else.B Thus, in the absence of a reason to pass the traffic the
firewall drops it.
(nd I8! is like that, but inside out= it has rules, maybe hundreds, maybe thousands. Most of those rules are
BdenyB rules= Bblock this known security problem.B When a packet shows up at the I8!, the I8! looks
through its rule list from top to bottom, looking for some reason to drop the packet. (t the end of the list,
though, is an implicit BpassB rule= Ballow this packet through.B Thus, in the absence of a reason to drop the
traffic, the I8! passes it through.
)irewalls and I8!es are control devices. They sit inline between two networks and control the traffic going
through them. This means that the I8! is in the policy side of your security house. ItAs going to implement or
enforce a particular policy on what traffic is not allowed through.
The obvious affinity of firewalls and I8!es from a topological point of view has led us to the world of >TM,
where an I8! is incorporated into the firewall. >TMs let you have both security services "blocking security
threats, allowing known good traffic# into a single device. WeAll talk about the ultimate in compression of
I8! and firewall, the >TM ">nified Threat Management# firewall later.
The main reason to have an I8! is to block known attacks across a network. When there is a time window
between when an e'ploit is announced and you have the time or opportunity to patch your systems, an I8! is
an e'cellent way to /uickly block known attacks, especially those using a common or well-known e'ploit
tool.
0f course, I8!es can provide other services. (s product vendors search to differentiate themselves, I8!es
have become rate limiting tools "which is also helpful in enial of !ervice mitigation#, policy enforcement
tools, data leak protection tools, and behavior anomaly detection tools. In every case, though, the key
function of the I8! is a control function.
%&#T DO IDSES DO'
If an I8! is a control tool, then an I! is a visibility tool. Intrusion etection !ystems sit off to the side of
the network, monitoring traffic at many different points, and provide visibility into the security posture of
C
the network. ( good analogy is to compare an I! with a protocol analy$er. ( protocol analy$er is a tool
that a network engineer uses to look deep into the network and see what is happening, in sometimes
e'cruciating detail. (n I! is a Bprotocol analy$erB for the security engineer. The I! looks deep into the
network and sees what is happening from the security point of view.
In the hands of a security analyst, the I! becomes a window into the network. The information provided by
the I! will help the security and network management teams uncover, as a start=
!ecurity policy violations, such as systems or users who are running applications against policy
Infections, such as viruses or Tro*an horses that have partial or full control of internal systems, using
them to spread infection and attack other systems
Information leakage, such as running spyware and key loggers, as well as accidental information
leakage by valid users
3onfiguration errors, such as applications or systems with incorrect security settings or performance-
killing network misconfiguration, as well as misconfigured firewalls where the rule set does not
match policy
>nauthori$ed clients and servers including network-threatening server applications such as %38 or
&! service, along with unauthori$ed applications such as network scanning tools or unsecured
remote desktop.
This increased visibility into the security posture of the network is what characteri$es an I!, and which
differentiates the visibility function of an I! from the control function of an I8!.
0f course, since both I! and I8! have the word BintrusionB as the beginning of their acronym, you may be
wondering why I havenAt mentioned BintrusionB as part of the function of either I! or I8!. 8artly thatAs
because the word BintrusionB is so vague that itAs difficult to know what an intrusion is. 3ertainly, someone
actively trying to break into a network is an intruder. .ut is a virus-infected 83 an Bintrusion1B Is someone
performing network reconnaissance an intruderD or merely someone doing research1 (nd if a malicious
actor is in the network legitimately -- for e'ample, a rogue employee -- are their legitimate and illegitimate
actions intrusions or something else1
The more important reason for leaving BintrusionB out of the description for both I! and I8! is that they
arenAt very good at catching true intruders. (n I8! will block known attacks very well, but most of those
attacks are either network reconnaissance or automated scans, looking or other systems to infect -- hardly
BintrusionsB in the classic sense of the word. The best Intrusion 8revention !ystem in this case is the firewall,
which doesnAt let inappropriate traffic into the network in the first place.
ItAs the misuse of the word BintrusionB in referring to these visibility and control technologies which has
caused such confusion and misguided e'pectations in staff at enterprises that have deployed either I! or
I8!.
Ees, an I! will detect true intrusions. Ees, an I8! will block true intrusions. .ut these products do much
more than that -- they provide greater control and greater visibility, which is where their real value is.
SO %&IC& DO I B()'
If all products were either an I! or an I8!, then the answer to the /uestion of Bwhich should I buyB would
be easy= buy an I! if you want visibility, and buy an I8! if you want control. .ut I8! and I! vendors
donAt make it easy for us, because they have developed and released hybrid products which combine I!
visibility on top of I8! control.
)or most enterprises, especially ones who donAt have an I8! or an I! already, the right answer is Bbuy an
I8!.B ( visibility tool only brings you value if you have time to look at what itAs telling you. With tight
budgets and overstressed staff, the kind of senior security engineer it takes to really get value out of an I!
is in short supply. .uying a product that no one is going to look at isnAt going to do you much good. Without
F
regular and disciplined use of the visibility aspects of an I!, the only real effect youAll see is in increased
power bills.
This doesnAt mean that an I8! is a Bset it and forget itB kind of device. To get value out of an I8!, you must
tune it to match your own network and application and system mi'. If you donAt, youAll either have a high
rate of false positives, which can interrupt legitimate traffic, or youAll miss a lot of attacks, in which case the
I8! is not bringing you very much value. (n I8! that never has a false positive is probably not doing a good
*ob at protecting your network.
%owever, you will get value out of an I8! without a large time investment in managing and tuning it, and
analy$ing what itAs telling you about your network. ThatAs because the I8! will be there, providing additional
defenses, and helping to protect you against common errors. !ince most security problems are the result of
human error rather than targeted attacks, the I8! is an outstanding way to bring a defense-in-depth strategy
to network security.
Most I8! vendors, because of their I! heritage, sell products which actually combine both I8! and I!
functions. They have the powerful malware and attack recognition engine needed to identify and block
attacks, but they also have additional rules and tools designed to enhance network visibility.
(s youAre considering I8!, I!, or combination products, remember to focus on your primary re/uirement.
If you are looking for additional control, the most important part of the picture is the I8! detection engine.
I8!es need the ability to /uickly detect and block attacks, at very high speeds and without degrading
network performance, throughput, or latency.
If youAre looking for visibility, network forensics, and analysis capabilities, the most important part of the
picture is the I! management console. Eou have to be able to navigate through the information provided
by the I! in a /uick and natural way to gain network and security visibility. While the detection engine is
important, itAs not nearly as important as the management system. Without an effective way of e'tracting
information from the I! -- and this is as much your training as it is the management console you install --
you wonAt see much value from an I!.
9