Cyber Security Expo
Future of IDS by Joe Bowling on 28/10/03


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 The purpose of this paper is to explain how IDS are going to function in the future.

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 function.

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 flags are
- Syn --------1st packet sent to Synchronize (start communication) with another host
- 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 data
- 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 a session)

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 the session

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 consultant) 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 happened.

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 network.

What if……

  • 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 network.
  • 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 Present

“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 and usability.

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

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 is FTP

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
This paper will focus on signature matching “style” of intrusion detection

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: is the same as
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 in Unicode.

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 of IDS

“No need to investigate that alert…it happens all the time”
-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 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 /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 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.

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
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 /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 needed.

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

Rate this article

All images, content & text (unless other ownership applies) are © copyrighted 2000 -  , All rights reserved. Comments are property of the respective posters.