Much has been asked about what is the future of Intrusion Detection Systems
(IDS) as a technology. These questions have come from executives as well as
from tech boards such as www.whitehats.com.
The purpose of this paper is to explain how IDS are going to function in the
This assignment will consist of five areas:
Before we jump into the Future of IDS we need to back up and start with an
overview of TCP/IP to lay some foundational understanding. We then will briefly
cover why even have an IDS, give some brief history of IDS, and current day
functionality/challenges of IDS. The final portion will cover how problems of
today’s IDS will be met in the future. IDS.
Overview of TCP/IP communications
Before covering what I believe to be coming in the near future of IDS one
will need to have some understanding of how the TCP/IP suit of protocols operate
to have a appreciation/understand how the future IDS will be enhanced from what
IDS are today. Lets have a quick review of how the TCP/IP suite of protocols
The Protocols we will cover are TCP, UDP, and ICMP.
TCP is a protocol that works at layer 4 in the OSI model and handles host-to-host
communication. TCP is a reliable protocol due to its connection-oriented method
of communication via sequence numbers.
There are multiple flags that are set to help the TCP protocol function. These
- Syn --------1st packet sent to Synchronize (start communication) with another
- Ack---------used to acknowledge what data has been received by a host
- Push-------Tells a host to push data from the buffers up the TCP stack
- Urgent----- indicates which data is important and takes priority over other
- Reset------used to immediately terminate a communication session
- Fin----------used to gracefully end communication session
- ECN--------used to notify host of congestion
To open a TCP connection between two hosts a “3 way handshake”
must take place.
1. It starts with Host A sending a Syn packet to host B.
2. Host B responds sending its own Syn packet along with an Ack to acknowledge
host A’s Syn
3. Host A responds to Host B’s Syn with a Ack
At this point we have a full duplex session set up. The hosts will exchange
information until its time for each host to end the session.
The same process will be done to close a session except this time Fin packets
will be used to end the session instead of SYN packets (which are used to start
1. It starts with Host A sending a FIN packet to host B.
2. Host B responds sending an Ack acknowledge host A’s Fin (closing that
direction of the communication session
3. When Host B is finished it will send its Fin packet to Host A
4. Host A will respond with an Ack to Host B’s Fin packet thus fully closing
A session can be immediately terminated by sending a reset packet. A reset
packet does not require an ACK to close the session.
These protocols generally work together. Neither UDP nor ICMP is connection
oriented meaning they can’t verify if the data they send ever arrives
at its destination. They are the “send and pray” protocols. UDP
operates at Layer 4 and ICMP is considered to operate at layer 3 in the OSI
model. The advantage of UDP has over TCP is that UDP is quicker.
ICMP is used to help alert of error conditions. Such alerts include
- Host unreachable messages
- Port unreachable messages
- Protocol unreachable messages
- Net unreachable messages
- Admin prohibited messages
- Echo and echo reply (ping)
This is just a simple basic summary of how these protocols work.
For a more information on the TCP/IP suite of protocols The TCP/IP Illustrated
by Dr. Richard Stevens is considered by many to be the best reference available.
Why have an IDS? Isn’t
a firewall enough?
“No one can hack our network…we have a firewall”
-an uninformed system administrator
“Why have an Intrusion Detection System?…we have a firewall”
That is a common first question response that management ask when proposed with
the idea of implementing an IDS. Some system administrators may tell you “We
are totally secured. We have a firewall and we don’t allow anything into
our network unless we send it out first”. To briefly answer these valid
questions lets start with a brief overview of what a firewall does and does
not do, and what IDS does and does not do. Then we will wrap up with how the
IDS and firewall are both needed to help secure a network.
Firewalls are made to stop unnecessary network traffic into or out of your network.
Packet filtering firewalls typically will scan a packet for layer 3 and layer
4 protocol information. A typical packet filtering firewall blocks everything
by default. It is only after you apply rules that “punch holes”
(combination of IP address, protocol such as TCP/UDP, and port number) into
the firewall is how you allow traffic into or out of your network. There aren’t
very much dynamic defensive abilities to most firewalls. The traffic approaching
the firewall either matches up to applied rule and is allowed through or the
traffic is stopped. Borrowing a similar example from Robert Graham (Security
Think of a firewall as a Fence around your network with strategically placed
gates. If traffic is coming to your network, as long as it comes in at a position
that has a gate, ( a gate being a combination of IP address, Protocol, and port
number) the traffic will pass through the firewall. Conversely if the traffic
goes to a position on the fence/firewall where there is no gate the traffic
will be blocked. Now what happens if malicious traffic goes through a gate?
It has essentially bypassed your defense and worst yet it will not be listed
in the firewall logs either so now we don’t even know that the event has
In contrast to firewalls, IDS will scan all packets at layer 3 and 4 as well
as the application level protocols (most IDS can tell if the traffic is http,
DNS, SMB etc) looking for back door Trojans, denial of service attacks (DOS),
worms, buffer overflow attacks and detect scans against the network etc. IDS
can be compared to a surveillance camera on the network in that it gives visibility
to all traffic coming over the wires. IDS have a predefined rule list (also
known as signatures or filters) Rules of an IDS have very specific parameters
that are set up, when a packet matches those parameters the IDS will alarm.
These parameters include IP address, port number, transport protocols (TCP/UDP),
application protocols, and content (also known as payload). What happens if
malicious traffic such as packets containing a NOOP sled passes through one
of the holes that are “punched” into the firewall? The firewall
will simply check to see if the IP address/port number/transport protocol matches
up to any allowed rules to determine if the traffic will pass through. In this
example the network traffic matches the “allowed in” rule on the
firewall and is allowed to pass through. The IDS will scan the same traffic
and detect a known malicious signature (the NOOP sled) in the content portion
of the packet and will alert (notice we said alert and not necessarily stop
the malicious traffic).
A simple example of this is you have a hole punched into your firewall to allow
connections to an FTP server but someone attempts to download the passwd file
from the ftp server. The firewall recognizes traffic to the FTP server as ok
and doesn’t block it. The IDS however will see this happening and will
alarm. IDS can essentially can help you learn about vulnerabilities of the network
as well as give us more visibility as to what is coming in and out of the network.
With only a firewall there are major problems when it comes to securing the
- There was an attack that the firewall did not block? How long before the
attack is discovered if ever? How will one ever be able to trace it back to
the attacker? Typically Firewalls are set up to log network traffic that was
denied access so there would be no record of the event.
- There was an internal attack behind the firewall? The internal disgruntled/bored
employee who thinks its fun to hack into corporate resources would go undetected
by the firewall
- A worm infects a machine on the inside of the network and is being used
to attack other hosts on our network or attack other external networks? For
example a webserver infected with Nimda could be attacking business partners,
internal networks, or random targets on the web, a firewall would not detect
the initial traffic that infected the webserver (assuming port 80 is open
on the firewall) nor would it recognize the attack traffic heading out of
- The firewall did not detect a slow and stealth recon scan? How would you
ever be able to do some preventive action? Ex. Renaming a server, changing
its IP with that of a honey pot etc.
- Attacks that come in on ports that are intentional left open? Such as port
80 for web traffic. It would go undetected by the firewall (most companies
have port 80 open so they can access the internet).
To conclude is IDS worth having? It all boils down to risk. How much risk is
the company willing to take. We have briefly covered how attacks can happen
even with a firewall. If a company has information and assets that are vital
to the company’s ability to function then the answer is yes. Having IDS
provides much greater visibility to detect signs of an attack and compromised
hosts. We still need a firewall to block traffic before it enters our network
but, we also need an IDS to make sure the traffic that does gets past the firewall
will be monitored.
A look at IDS: Past and
“Why should we upgrade we haven’t been hacked yet?”
IDS are a fairly new technology that is still in its growing stages. IDS have
already taken some major steps forward in a few short years in regards to capability
PAST: The first IDS were very limited in their functionality
and flexibility. In the earlier days some IDS vendors did not allow users to
write their own rules/signatures! Some vendors would not even allow their customers
to view the rule list that came with the IDS. To say the least if a user can’t
write their own rules or see the rules that are used for alarms generated, the
user is stuck trying to read a book in a dark room. Under such circumstances
customizing a rule set based on one’s network is totally out of the question.
They would be overwhelmed by false positives! A false positive is when an alert
is triggered for traffic that is allowed (think of a false alarm). IDS work
by doing signature matching. Signature matching is when you identify a specific
signature unique to an attack/virus/worm etc. When the packets are scanned by
the IDS if t a matching signature is found in the IDS rule list, the IDS will
alert. Older IDS were also stateless i.e. The ids would run each packet through
the IDS rule engine on a per packet standalone basis thus there was no way for
the IDS to maintain a TCP session or IP fragmentation session. The problem with
stateless filtering was that it allowed hackers who fragmented their attacks
to go undetected. Fragmented traffic has been used to create Denial Of Service
(DOS) attacks on Routers, firewalls, and workstations. Fragmented traffic has
been used to hide recon scans. Insertion and evasion attacks could easily bypass
a stateless IDS.
A quick summary of insertion and evasion attacks is changing the traffic flow
to purposely dodge the signature of the IDS sensor. Making the traffic so that
it appears one way at the sensor (not matching the signature in the IDS rule
list) but looks another way at the end destination. Borrowing an example taught
by SANS would be to write a script that would telnet to a server and login with
a logon of root but if we know that the IDS will alert on a “root”
logon we will trigger an alert on the IDS so we set the program to send each
character to the word root across individually but we also inject something
else say the letter H so when the script runs the sensor will see the signature
rooHt…which will not match the signature of “root”. But to
make sure we that “H” in “rooHt” doesn’t get to
the server (cause the logon is root not rooHt) there are a number of ways to
accomplish this. One way is to have the packet carrying the “H”
to have a TTL (time to live) that will expire immediately after it passes the
sensor (which requires knowing the hop counts from the server it was logging
into and where the sensor is) or an easier way would be to purposely corrupt
the tcp checksum of the packet carrying the “H”. In essence the
sensor would read “rooHt” but once all the packets arrived at the
server the server would discard the packet carrying the “H” due
to the bad TCP checksum so the logon would only receive the letters “r”
“o” ”o” “t” equaling “root”.
Thus going undetected by the IDS. This paper will not go into the details of
different attacks that employ insertion and evasion attacks but a good source
of information is a paper written by Thomas H. Ptacek and Timothy N. Newshamcan
found at http://www.snort.org/docs/idspaper/
IDS of past also did not have the ability to decode the protocol to see if
the signature of a rule was needed to be scanned or not. An example is if you
do not use the FTP command “put” but, you build a signature to alert
when the “put” command is found. Without protocol decoding anytime
the letters “put” showed up in anything from an email to a document,
the alert would go off thus creating false positives. With protocol decoders
the IDS knows to only apply the rule for “put” when the protocol
Signature matching is the type of NIDS that is mostly deployed but there is
another “style” known as anomaly-based intrusion detection. Anomaly-based
intrusion detection works on finding abnormal activity on the network but the
problem starts with what is normal and what isn’t normal. A good tool
for this type of intrusion detection is “Shadow” which was created
by Stephen Northcutt and his team in the Navy. It can be found at http://www.nswc.navy.mil/ISSEC/CID/
This paper will focus on signature matching “style” of intrusion
IDS sensors in the past could not sustain high speed traffic volume thus they
would drop packets when the traffic load was to large…packets that could
contain backdoor attacks or even the DOS attack that could be used to increase
the bandwidth beyond the sensors ability to detect. Tools have been created
to purposely set off IDS alerts to basically overwhelm the IDS and create a
smokescreen of false positives. An example is Snot and Stick.
Large networks with multiple connections to the internet faced a major challenge
of being able to correlate information that was gathered over multiple sensors
to try to turn the information into a useful data ex. It was difficult to detect
slow stealth scans that would come through multiple sensors (especially if the
analyst had to switch back and forth between screens looking at the alerts).
PRESENT: Currently today some of the major issues of the past
have been resolved.
Users are allowed to write there own rules list to customized to their own network
even with commercial IDS such as NFR’s (Network Flight Recorder) IDS.
An example of customizing a rule list is if the user doesn’t run IIS servers
they would not write filters to detect the Nimda worm (the Nimda worm only effected
IIS webservers) or in the case of commercial IDS where the rules are already
written for the user or the analyst would simply not have the IIS rules loaded
in the sensor to detect. Users are able to specify filters with great detail
today. Filters can be set on IP, port, source/destination, protocol, TCP flag
combinations, and content strings. For faster IDS performance some IDS will
allow the user to specify where to begin looking for a string or how far to
look for the string. For example, searching for the content beginning at the
5th byte in the application payload and searching the next 15 bytes would end
on byte 20 in the payload). Other features are an option known as “tagging”.
Tagging allows IDS admin to specify that if a certain detect is found, that
the IDS would record that connection either by specifying a time length…ex.
30 seconds, 2 mins or by the life of the connection. Tagging can also be set
to grab a certain amount of packets after the detection is made.
Stateful inspection is also available on many IDS that now allow IDS admin
to apply filters that “maintain state”. This allows IDS to keep
track of a TCP session or fragmented traffic in its memory buffers prior to
applying a filter. For example fragmented traffic would be reassembled in the
IDS memory buffers (sometimes referred to as preprocessors). Upon completion
of the assembled fragmented traffic would it be run through the IDS filters.
Most IDS can decode by protocol (recall example above about the “put”
command for FTP) thus allowing for more refined filters (based on protocol)
as well as many IDS today can decode Unicode/url encoding. Unicode is a universal
number assigning to characters no matter the language, platform, and program.
An example of Unicode is: http://www.sans.org
is the same as http://www.%73%61%6e%73.org/
The IDS that decode Unicode would recognize that both URL’s are the same…IDS
that do not support Unicode would not alert on the signature that it has Unicode.
Unicode can be used in URL’s (possibly for directory transversal) as well
as in commands such as cmd.exe is also %63%6d%64%2e%65%78%65
Sensors today are able to handle much larger volumes of traffic. For example
Snort has been able to keep with 150mbps speed and not drop packets (When considering
the speed of traffic that an IDS can keep up it with must be taken with a grain
of salt. Snap length (how much of each packet to capture off the wire) and number
of rules has a major impact on the IDS performance). Load balancers are also
available today from a company called Toplayer. A load balancer can take large
streams of traffic and use a round robin approach to feeding the information
down to multiple sensors (so you have multiple sensors processing the traffic
of a single connection) ex. If the load balancer feeds into 8 separate sensors
that are capable of 100mbps each you can essentially process 800mbps without
dropping any packets (which answers one of the Gartner reports concerns about
IDS’s being able to keep up with large volumes of traffic). Networks that
use multiple sensors usually have all sensors report back to a management console
and the management console helps to compile all of the detects into a usable
readable format. For example the ability to compile all similar alerts together
on 1 screen makes it much easier to detect stealth recon scans, correlate DDOS
and correlate events from different parts of the network.
With all the progress that IDS have made over the last few years, it still has
some major challenges.
Challenges and Limitations
“No need to investigate that alert…it happens all the
-an over worked intrusion detection analyst
False positives are one of the biggest problems when working with IDS a well-known
fact as stated in the recent Gartner report on IDS. Please see URL http://www3.gartner.com/5_about/press_releases/pr11june2003c.jsp.
False positives dull the ambition of an analyst by overwhelming them with alerts
that turn out to not be alerts after all. False positives can come from not
having specific enough filters or the filters may be set fairly well but that
the attacks may go to subnets or devices where vulnerable systems do not exist.
An example of this would be if you saw syn packets (syn packets will be explain
better later on) being sent to multiple hosts on the 10.10.10.0 /24 subnet on
port 135 (RPC service for Microsoft operating systems). Lets assume you have
both Solaris and Windows operating systems on your subnet but, the only PCs
on that particular subnet that received the syn packets had the Solaris operating
system on the PCs thus the potential attack is not nearly as critical had there
been Windows operating systems on those PCs. The analyst would have to see the
alert and would have to investigate all the operating systems on all the hosts
that received the syn packets destined for port 135 to verify if this traffic
could potentially exploit vulnerability. To do so would require the analyst
to have a solid knowledge of the network itself (which is very difficult to
do in mid-large size networks) or the analyst will have to perform a lot of
legwork. Sounds like fun doesn’t it? It might be in the very beginning
but even the most dedicated analyst will quickly begin to grow numb to these
alerts that could be in the 1000’s per day. The problem gets compounded
if the network is constantly changing as many networks today are.
Today we are unable to integrate router logs, system logs and firewall logs,
host based IDS alerts with alerts from an IDS. Analyst have to flip from device
logs to device logs to correlate scans and alerts or even worse have to contact
the firewall administrator and contact the system administrator to get the logs
which would consume even more time.
A major challenge with IDS today is being able to set up and query the database
information to find relevant data. Companies with large Networks accumulate
large amounts of data. Filtering through large amounts of data quickly is a
challenge. Most companies have their IDS record all of their data to large databases
for keeping. Having that database cost money especially with the likes of an
Oracle database and having to hire a DBA to maintain them. It would much easier
if there was a device that came with as part of the IDS that would be easy to
setup and use. The storage device needs to be secure and be able to respond
to queries quickly.
The last main challenge is having a skilled IDS analyst. It seems that most
security professionals who are in charge of the IDS are also responsible for
setting up the IDS and maintaining it. This process usually consists of installing
and tweaking the IDS software and rule list, which can become quite complex.
Setting up a database for the IDS to alert to as well as create scripts and
queries to be able to get intelligent data from the database is also not a very
easy task (gets even more complex if the analyst has to write scripts that can
try to import other alert formats into the same database such as syslog alerts,
router logs etc. Monitoring and evaluating the alerts forces, the analyst to
stay on top of all the newest attacks, worms, virus and network changes on the
internal network (to keep rule list accurate). The IDS analyst needs to be skilled
with many different OS's. The analyst is also usually on (or is) the incident
response team. This can become overwhelming on the IDS analyst.
The Future of IDS
“In God we trust….all others we monitor”
- United States Navy
How are IDS going to change in the Future? I don’t have a special crystal
ball to read from and since Ms. Cleo is out of business we will have to rely
on the directions we see IDS vendors moving toward such as ISS http://documents.iss.net/gartner_response.pdf.
The strong source for the information that is covered in this upcoming section
comes from Marty Rosech the CEO of Sourcefire (an IDS vendor) and the creator
of the open source IDS Snort. Sourcefire held a conference on the future of
IDS at which Mr. Rosech was the keynote speaker.
Vendors today have heard the cries of security professionals challenges with
IDS and are taking action. Vendors (such as Sourcefire and ISS) today are working
to make the future IDS, firewalls, and routers to be able to interoperate with
each other. Having firewall and router functionality incorporated with the IDS
will provide extreme flexibility to secure a network. Getting all devices to
send logs to a database that can incorporate the formats into one that is viewable
to the IDS management console will greatly aid in correlating alerts.
With IDS, router, and firewall capabilities being integrated (possibly all on
the save device) users can have a firewall that will be able to dynamically
adjust its rule set or a router that can change its routes based on traffic
that the IDS sensor detects. The responsiveness will be specified in the IDS
filters. This will provide true wire speed detection and prevention. A firewall
will have the abilities to drop the connections that the IDS would detect, that
normally would be allowed through the firewall. An example of this is networks
that have port 80 open in the firewall for users to connect to the internet
but the firewall is not smart enough to see if the traffic coming to port 80
is the Code Red worm or not. The IDS is smart enough. When the IDS see the traffic
coming into port 80 with the Code Red signature the IDS will inform the firewall
to block such traffic. The interoperability of IDS and routers can move in to
the realms of Quality of Service (QOS) as well as changes in the routing table.
With routers being able to interoperate with IDS we can have the router change
where traffic is routed based on what the IDS detects. One may simply have the
router route the malicious traffic to a black hole (a dead IP address) or make
better use of malicious traffic by sending it to a honeypot or honeynet. Honeypots
are either a PC or a software program that simulates what the Hacker would see
given the commands that he enters. Honeypots can be used to help learn more
about hacker techniques and motives. Honeynets is a small network of honeypots
and is used for the same purpose as honeypots but more at the network level.
To touch upon the importance of achieving wire speeds that comes from having
the IDS, firewall, and router all in one device is that it will allow us to
stop the traffic before it gets to where its going thus resolving the problem
that current IDS have that try to use responsiveness to alerts such as Snort’s
Flex response. What Snort’s Flex response does is allow the user to specify
in his filter a particular action that it would like Snort to perform to knock
down a connection. There are two ways to knock down the connections one for
each protocol TCP or UDP
For TCP connections to be torn down by sending a reset packet to either the
source host, destination host, or both. For UDP connections to be torn down
Snort can send a different ICMP messages such as ICMP NET unreachable, ICMP
HOST unreachable, and ICMP PORT unreachable. Snort can send any combination
or all three types of ICMP messages. Note that these ICMP messages will always
be directed at the Source host of the filter that triggered the alert. Even
though IDS such as snort have the capabilities to tear down a connection, it
does not always work because the IDS are in a race to send the reset packets
before the destination host responds back to the source. A hacker could very
easily set up his firewall to block the Reset and ICMP packets that the IDS
would send in trying to knockdown the connection (if they something like flex
response was being used). With wire speed the malicious traffic will not even
get to the destination or it can be blocked or rerouted thus greatly reducing
the ability of a hacker to cause damage.
Databases will end up being part of the management console. The main reason
is to simplify IDS by not having to have 3rd party hardware and software thus
reducing the cost associated with the total IDS solution. We have already seen
where Sourcefire (IDS vendor) has already done so. Their management console
can perform a query through 1 million entries and pull 7 responses in 1 second.
Which is the rapid responsiveness that intrusion analyst want and need. The
database will also need to be able to take logs from other devices (even from
independent vendors….easier said than done but we are talking about the
future here. ?) such as application, firewall, system, router, and IDS logs
(both network based and host based) and be able to “normalize” the
input date into a format that can be queried for useful output.
NETWORK DISCOVER VIA PASSIVE OS FINGERPRINTING:
What is passive operating system (OS) fingerprinting? Describing the details
of passive OS fingerprinting is beyond the scope of this paper but we can give
a quick summary of OS fingerprinting. Each OS has by default unique characteristics
to how it communicates and functions. The characteristics that vary from OS
to OS are Time to Live (TTL), the initial TCP window size, Max Segment Size
(MSS), and even the Type of Service (TOS) options may be used to identify OS.
A good research paper on passive fingerprinting based on a options field of
a SYN packet was done by Toby Miller and can read at http://www.incidents.org/papers/OSfingerprinting.php
IDS can monitor the traffic that it sees and can “discover” what
the operating system is and keep a dynamic “mapping” of the internal
network. So what does this have to do with making life easier and better for
the intrusion analyst? It is the key to greatly reducing one of the biggest
problems in intrusion detection…false positives. How can passive OS fingerprinting
help to reduce false positives? By the IDS knowing what each host is on the
network it can decipher if the malicious traffic is destined for a potentially
vulnerably OS. Lets go back to our earlier scenario.
You saw syn packets being sent to the 10.10.10.0 /24 subnet on port 135
(RPC service that runs on Microsoft operating systems). Lets assume you have
both Solaris and Windows operating systems on your subnet but, the only PCs
on that particular subnet that received the syn packets had the Solaris operating
system on the PCs thus the attack is not nearly as critical had there been Windows
operating systems on those PCs. The analyst would have to see the alert and
would have to investigate all the operating systems on all the PCs that received
the syn packets destined for port 135 to verify if this traffic could potentially
exploit a vulnerability.
How would this scenario report differently if passive OS fingerprinting were
implemented? The IDS would have known that the OS at the destination of the
inbound syn packets going to port 135 were Solaris operating systems that don’t
run the vulnerable RPC service on port 135 that does run on Microsoft operating
systems. Depending on the security policy the IDS could simple either simple
ignore the suspicious traffic or still alert but only alert at a low priority
for instance a priority 4 on a Scale of 1-5 (5 being low 1 being highest).
Now if the same scenario were to happen but the syn packets went to hosts that
had the Microsoft OS that run the RPC service on port 135 (NT,win98/95/2000)
then the IDS would alert with a priority level 2 given the serious nature of
the traffic. Now when the intrusion analyst looks at the alerts he will immediately
know which alerts are serious and which alerts are false positives. Less critical
alerts would greatly reduce the amount of false positives that an analyst would
have to review and investigate. As the analyst is reviewing the alert for this
scenario since it is a priority 2 alert he knows that a serious event has occurred.
After the analyst has seen the alert describing syn packets was sent to the
RPC service (port 135) on Windows machines running the daemon he can simply
check the router logs (from the same management console) and see that the router
simply routed the traffic to the appropriate honeypot to which the analyst will
review and share his findings with the Honeypot project team.
Brief word on Host based IDS. The focus of this paper was
on future of Network based IDS (NIDS) but we should at least mention briefly
how Host based IDS may change in the future. Stephen Northcutt (Director of
Training for Sans Institute) mentioned in the book (Network Intrusion Detection
co-authored with Judy Novak) that he believed that the Anti-virus companies
should take a serious look at implementing host based IDS and gave his reasons
for his belief. As of today Anti-virus companies haven’t made any movement
to implement it into their software. I personally believe that it will not happen
anytime soon. The reason is that as Network based IDS develop as spoken about
in the proceeding pages that those developments will increase the security enough
that network based IDS will remain the focus of the industry. I just don’t
foresee the market pushing the anti-virus companies hard enough to take on the
endeavors of host based IDS.
So are host based IDS going to be a thing of the past? Absolutely not. Host
based IDS play a very important part in the overall picture of security. It
is very hard for Network IDS to detect new attacks (if you don’t have
a signature for a unknown attack how can you set a rule to catch it?) but a
host based IDS can have better chances to detect the unknown attack. Though
usually it will be after the attack has happen. Host based IDS can detect if
files have been changed or altered ( a popular product is TripWire that accomplish
this by creating MD5 checksums on files) or if people log in after odd hours,
people try to access information that they don’t have rights to, monitor
system resources for anomalies…these are just a few examples of all the
different ways to set up rules to watch for abnormal behavior on host based
IDS. Entercept is sort of a “next generation” host based IDS in
that it sits between the user and the OS and will know what commands can be
executed even inside the program while it is running. Host based IDS have the
ability to log alerts in different formats including syslog and snmp so in the
future look to see host based IDS alerts going to the same database that the
NIDS, firewalls, router alert logs go to.
CONCLUSION: In comparing how the IDS of today function compared
to the future is drastic. Given the Scenarios described above, the IDS analyst
would have to spend great amounts of time going through all alerts investigating
and researching the host to see if it is vulnerable or not (whether the host
is a Microsoft OS vs. Solaris in this instance) to discover if the alert is
an event of interest (EOI) or was the alert a false positive. In future IDS
the analyst will (most of the time) know immediately what alerts are false positives
and which alerts are true EOI.
Large networks will have the most to gain with the IDS of the future. Security
personal at the larger networks wont have to spend as much time investigating
all the false positives and will be able to make changes in the network without
having to rewrite large portions of the rule set because of the passive OS fingerprinting.
For example if a company has a few users who roam around the campus and plug
into the network at different places (especially in DHCP environments) the IDS
will detect them (via passive OS fingerprinting) and will update its mapping
of the network. With IDS, firewalls, and routers all now operating together
as one unit (at wire speeds once all devices are on the same appliance) the
possibility of malicious traffic getting to the destination will be greatly
reduced thus providing greater security.
So what will be the drawbacks? Properly configuring and customizing an IDS
has never been an easy task and with the added functionality that is coming
the challenge will be even more intense (hopefully this will keep up the salaries
for IDS engineers) The IDS of the future will require more hardware power than
IDS today but as technology keeps rapidly advancing this should be able to be
overcome without making the price too outrageous for a complete perimeter defense
solution. There will need to be serious forethought into how to react to alerts…its
not a good idea to block traffic from a IP address of a business partner or
customer that a hacker could have used to spoof an attack. Discretion will be
The benefits fully outweigh the drawbacks. Learning how to handle and implement
all of the new functionality of the future IDS should be one heck of a learning
experience for security professionals but, that is the fun part.
Ptacek, Thomas Newsham, Timothy “Insertion, Evasion, and Denial of service:
Eluding Network Intrusion Detection”
Miller, Toby “passive OS fingerprinting: details and techniques”
ISS “Gartner Claims IDS is Dead and Validates ISS’ Strategy”
Northcutt, Stephen and Novak, Judy Network Intrusion Detection (3rd edition)
Cothers, Tim Implementing Intrusion Detection Systems: A Hands-On Guide
for Securing the Network Wiley 2003
Marty Rosech: CEO of Sourcefire, Seminar on the Future of IDS
Washington DC 4/30/2003
George Bakos: Senior security expert at Dartmouth College, SANS instructor
for intrusion detection. Baltimore Conference April 2003
Cohen, Fred “50 ways to defeat your IDS”
ISS (Internet Security Systems) “The evolution of intrustion detection
technology Aug 29, 2001
Graham, Robert “Network Intrusion Detection Systems”
Sourcefire “Real-Time Network Awareness” June 2003