Softpanorama Bulletin
Vol 16, No. 03 (July, 2004)

Architectural Issues of Intrusion Detection Infrastructure in Large Enterprises

Dr. Nikolai Bezroukov
(version 0.9)

Introduction

NIDS and their problems

• Programmability of NIDS

The problem of false positives

Webliography

The most serious problem in intrusion detection is the problem of distinguishing very weak useful signal in massive noise as well as related problem of data assessment: the need to correlate, evaluate and verify all this mass of junk events (sometimes called alerts ;-) that various IDS are generating. This is a difficult problem that is not solved well by most organizations so most IDS in "rich" network are of limited usefulness.

This problem of false positives is especially acute in Network IDS( NIDS). That's why many NIDS deployments actually have the status of "innocent fraud" to borrow the catch phrase used by famous economist John Kenneth Galbraith in the title of his last book "The Economics of Innocent Fraud".

In Gartner report "Hype Cycle for Information Security, 2003" published on 30 May 2003 Richard Stiennon, who was at this time, a VP of Research (6 years Gartner veteran at the time of publication) courageously stated that "king is naked" in just one short paragraph:

"Intrusion detection systems are a market failure. Vendors are now hyping intrusion prevention systems, which also have stalled. The functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic blocking, as well as antivirus activities."

To be useful intrusion detection requires multi-level approach with different layers able to communicate using some kind of common protocol may be on the base of typical EMS system (for example Tivoli).

Introduction

Formally IDSs fall into two main groups: host-based and network-based:

• A network IDS (NIDS) uses network cards in promiscuous mode, sniffing all packets on one of many network segments. For this purpose either a particular port of switch is mirrored or taps are used. This is the most popular and probably the least useful class of IDS that due to craziness and marketing orientation of mainstream IT media became the politically correct thing to do in any large organization. Actually NIDS have several orders of magnitude less return on investment then log analyzers ( see below ). That means that IBM by-and-large lost its 1.3 billion dollars by buying ISS in 2006. Producing a log integration solution using Tivoli TEC from firewalls routers and defended hosts would save IBM customers a lot of money and produce dramatically improve the return on investment. I think IBM brass would be better off spending those money in best former TYCO CEO Dennis Kozlowski style with wild orgies somewhere around Cypress or other Greek island :-). At least this way money would be really wasted in style ;-).

  A typical NIDS deployment consists of one or more sensors and a central server with usually WEB based console. Central server aggregates data feeds from multiple sensors and additionally can include scanner (like NMAP) for mapping hosts and eliminating obvious false positives. On more advanced level it report events to event management system like Tivoli that can additionally eliminate those events that do not correlated with host logs or host integrity checkers. The later usually look for key system files and detect all instances when they have been altered.

  A network IDS with two sensors (one before and the second after the firewall) can be used for firewall rules debugging and maintenance. Network IDS generally can be subdivided into the following subcategories:
  

  • Signature detection systems work in a similar way to virus scanners, trying to match network patterns with their database of "attack signatures." Snort is classic example of such IDS and it suffers from all the typical warts of this class of the product. Commercial products are usually far worse and instead of "innocent fraud" are close as close to real as your can get with, probably, deceptive advertisement being the most probable charge that can stick.

    In a very few situations they may provide minimal additional level of protection (simple network with just few protocol used and intelligent specialists responsible for configuration). For example attempt to use TFTP outside of limited list of network devices is a very suspicious activity that should raise some flags independently whether this port is blocked by external and VPN firewalls of not (it generally should be blocked).

    In a typical enterprise deployment with stock signatures the level of protection from known attacks (or more correctly from attacks with signatures similar or identical to already known) is marginal as they suffer from the problem of false positives to such extent that that all alerts are completely ignored in a couple of week or month after the initial deployment. People just get sick of "security spam" (aka "mail alerts"). After that the devices happily circulate air and can be replaced by a fan with some savings both in initial cost and consumed electricity :-).
    

  • Anomaly detection systems try to integrate "attack signatures" into a larger semantic blocks using some statistical, heuristic (usually network topology based heuristics are used) approaches. A typical example is scanning a large block of IP addresses belonging to an organization with nmap or similar tools. Snort is capable to detect some attacks bases of statistical anomaly detection but postprocessing of Snort alerts is a much better approach. In case of statistical approach you can get some impression of the set of IP addresses that tend to send strange packets to your network. That's useful information and it should be regularly collected and analyzed. It also can be easily collected on sensors that monitor huge amounts of traffic (for example external traffic flowing to the organization) and thus provide very few other useful information (due to mentioned above problem of "security spam").
    
• Host-based systems are installed on the server or desktop and can monitor not only network traffic but also key files, events and logs. They have lower level of false positives then NIDS. We can distinguish:
  
  • Kernel based subsystems the control (and can restrict) usage of resources by running processes like SELinux and, especially, AppArmor - a very elegant but severely underutilized concept of making umask per process/per directory feature. .
  • Solaris Zones and similar light-weight virtualization solutions that isolate one application from others.
  • RBAC (see Solaris RBAC) and similar role based mechanisms
  • Firewall-based HIDS  combine intrusion detection and packet filtering. It can be TCP/IP only like Xinetd and TCP Wrappers or packet firewall like Linux iptables.  In any case firewalls has higher returns on investment the NIDS. See firewalls
     
  • Integrity checkers Tripwire is good example of  traditional integrity checker. It has its strong point and weakness that are discussed on a separate page.  Generally Tripwire is too primitive and is not a good choice for HIDS.
     
  • Log analyzers -- this type of HIDS have the highest level of useful signal to noise ration and deserve more attention and investment that other types. See special page (Log analyzers ) devoted to this kind of IDS (although they are mostly used not for IDS but for regular troubleshooting.
     
  • Honeypots - this over-hyped concept is essentially an instance of OS (usually virtual partition) with a combination of IDS installed or a regular network sensor with an additional services on vulnerable ports configured as honeypot ports (honeyport :-). As they do not have their own useful incoming traffic and traffic coming to honeypots is suspicious. That helps to detect attacks that scan subnets  for specific vulnerabilities. Any new internal activity means break-in as such boxes do not perform any other useful function (or such a function is faked).  One extremely positive thing about honeypot is that it can be very cheap (a desktop computer with Linux and some IDS software suffice) and have lower noise to useful signal ration then traditional network IDS. Most non-broadcast type of network traffic directed toward them is anomalous from the point of view of normal network functioning as this is a passive device that just listening to the traffic and normally nobody should try to connect to it or scan it.  Actually some types of intrusion detection are simpler and more reliably performed on honeypots  (port scanning attempts, etc). Here is the definition from http://www.honeypots.net/

    Honeypots are closely monitored network decoys serving several purposes: they can distract adversaries from more valuable machines on a network, they can provide early warning about new attack and exploitation trends and they allow in-depth examination of adversaries during and after exploitation of a honeypot.

NIDS and their problems

Classification notwithstanding when people are talking about IDS they usually mean NIDS. The latter operate at a Internet layer of TCP/IP protocol stack. And that means pretty low level -- level of fragmented datagrams. NIDS are trying to infer attacks against the network from traffic patterns as well as the content of the data stream (this involved attempts defragment datagrams as well as to reconstruct higher level protocols, for example HTTP).

Most NIDS are close relatives of virus scanners and are implemented as scanner of traffic with some (limited) reconstruction of higher level protocols. They share the same major problem. among them:

• High number of false positives;
• High dependence of result on the quality of signature database and frequency of signature database updates
• Low quality of many signatures due to attempt to detect event on higher protocols on transport level of IP protocols
• Architectural weakness of the design, sloppy coding, obscure mini-languages and/or interfaces, etc).

All-in all network IDSs are probably the most over-hyped and the least useful category of IDS. The return on investment on a typical signature based NIDS appliance in case of using generic signatures ("classic ISS appliances value proposition") is asymptotically close to zero.

For some unknown to me reason the whole industry became pretty rotten selling mostly hype and FUD. Still I need to admit that FUD sells well. The total size of the world market for network IDS is probably several hundred millions dollars and this market niche is occupied by a lot of snake oil salesmen:

Synergy Research Group reported that the worldwide network security market spending continued to be over the $1 billion in the fourth quarter of 2005, in all segments -- hybrid solutions (firewall/VPN, appliances, and hybrid software solutions), Intrusion Detection/Prevention Systems (IDS/IPS), and SSL VPN.

IDS/IPS sales increased seven percent for the quarter and were up 30 percent over 2004. Read article here.

Most money spent on IDS can be spent with much greater return on investment on host based detection and first of all on log analysis (which provides almost immediate return on investment), host based detection including integrity checking, ESM software as well as on improving rules in existing or installing additional firewalls. actually spending money of firewalls is more efficient then spending money on IDS and that fact was noted by Gartner in 2003.

In Gartner report "Hype Cycle for Information Security, 2003" published on 30 May 2003 Richard Stiennon, who was at this time, a VP of Research (6 years Gartner veteran at the time of publication) courageously stated that "king is naked" in just one short paragraph:

"Intrusion detection systems are a market failure. Vendors are now hyping intrusion prevention systems, which also have stalled. The functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic blocking, as well as antivirus activities."

Here is the relevant part of the report.

Succumbing to vendor hype in the security management area can have expensive consequences. Enterprises should assess their security needs and evaluate the relative maturity of a security technology before adopting it.

... ... ...

4.6 Intrusion Detection Systems

Definition: Software running on a host or a network sensor that identifies malicious activity and creates an alert.

Time to Plateau/Adoption Speed: Obsolete before Plateau.

Justification for Hype Cycle Position/Adoption Speed: Intrusion detection systems are a market failure. Vendors are now hyping intrusion prevention systems, which also have stalled. The functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic blocking, as well as antivirus activities.

Business Impact Areas: Security and network management.

Selected Vendors: Cisco, Enterasys Networks, Entercept, Internet Security Systems, Symantec and Tripwire.

Analysis by Richard Stiennon

And this analysis withstood the test of the time, despite the fact the Gartner changed its position to please influential subscribers. While NIDS are far from being completely useless paying money for them is a kind of spending that only large companies, and, especially, only powerful players in financial industry can afford. Still they are politically correct thing and if deployed with some thinking can provide some useful signal.

But that also means that network IDS area is a natural area where open source software is more competitive then any commercial software. Simplifying we can even state that the fact of acquisition of commercial IDS by any organization can be a sign or weak or incompetent management ( although reality is more complex and sometimes such an acquisition is just a reaction on pressures outside IT like compliances-related pressures; moreover some implementations were done under the premises of "loss leader" mentality under the motto "let those jerks who want it have this sucker" ).

Actually an organization that is spending money on NIDS without first creating a solid foundation implementing log analysis and deploying ESM commits what is called "innocent fraud" ;-). It does not matter what traffic you detect if you do not understand what exactly happening on your servers/workstations and view your traffic as an unstructured stream, a pond out of which IDS magically fish alerts.

In reality as most time IDS is crying wolf so often, that few useful alerts that they generate are buried in the noise. Also "real time" that is selling point of IDS does not really matter: most organization have no possibility to react promptly on alerts even if we assume that there are (very rare) cases when NIDS pick up useful signal instead on noise. And that means that hybrid appliances that provide also "blackbox/flight recorder" type of capabilities like Niksun appliances are more promising that ISS appliances that for some reason dominate the commercial segment. Sourcefire appliances are better then ISS as they are tunable but they lack "blackbox/flight recorder" capabilities

A good introduction to NIDS can be found at NIST Draft Special Publication 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems (Adobe PDF (2,333 KB) Zipped PDF (1,844 KB) )

A typical network IDS (NIDS) uses network card(s) in promiscuous mode, sniffing all packets on each network segment the server is connected to. Installations usually consists of several sensors and a central console to aggregate and analyze data (for example Snort can be used as a sensor and Acid as central console). NIDS can be classified into several types:

• A pure IDS just watch the traffic. This is the most common type NIDS today and the least harmful. May be that's why they are the most widespread :-). Usefulness strongly depends of placement and tuning. If pure NIDS is listening to large and complex network segment, then typically the useful signal is so buried in noise that the most NIDS are constantly "crying wolf" (producing so called 'security spam" stream of mail alerts) and after short honeymoon after the installation are completely ignored; so their value is totally symbolic: organization have it as a politically correct part of infrastructure so that (often semi-ignorant) vice president of IS can report to absolutely ignorant corporate board about the major success in securing the corporate network. Usefulness strongly depends on the subtype deployed. There are three major subtypes:
  • Signature-based NIDS. Those depends on signatures to detect vulnerabilities. This is typical approach used in rulebase for ISS and Snort (Snort can be used in different ways too) and all IDS most IDS appliances.
  • Policy/traffic rules violation detection. This is closer to imitation of firewall without actual firewall. Like in firewalls the rulebase can be quite elaborate with proper segmentation of IP space. As such they are more useful that plain-vanilla signature-based NIDS but combined approach might also work. This approach sometimes is called policy deviation approach. These policy deviations include detection of unauthorized network services, applications running on unusual ports and logs from network sessions denied by firewalls.
  • Statistically based anomaly detectors. Here abrupt changes in traffic patterns signify the problem.
  • More generic behavior based (including statistically based) anomaly detectors. That usually presuppose using expert system like Tivoli Enterprise Console (TEC) for processing of the stream of the alerts and possibly correlating it with other streams. Often what vendors sell as anomalies detection NIDS is nothing more then adding to signature based core some heuristic methods similar to those used in antivirus scanners. These heuristic methods might be still highly effective for detection of port scans, distributed network probes, new forms of buffer overflows and denial of service attacks.
    
• A blocking IDS or intrusion prevention system (IPS) as it is often called combines a host IDS with an ability to modify firewall rules (or worse it acts as ad-hoc firewall itself). This is the most dangerous type as it's possible to use this capabilities for denial of service attacks. If return on the investment on pure NIDS is marginal, then the return on investment on IPS is usually negative. There are many flavors of IPS, making this type of IDS hard to define. Commercial offerings (for example from ISS) are especially problematic and can do a lot of damage...
  
• A host-based NIDS that is usually integrated with host firewall (or at least they should). Theoretically those has higher return on investment then general network NIDS as rules can be highly specific and tuned to the services that are actually available on a particular computer (typically desktop). For example firewall can block TFTP port while NIDS can detect and report all traffic to this port (useful for detecting some network worms that used RPC holes and TFTP delivery to propagate). Reporting can be local or centralized. They can be integrated with HIDS especially with log monitors. In case of presence of both networking IDS and host based IDS (that can communicate with each other) on the same server such an architecture would be called a hybrid IDS.

  At the same time like local firewalls they represent a danger to the networking stack of the computer they supposedly protect.

The second important classification of NIDS is the placement:

• Internet-facing NIDS. Most IDS are located on ingress to network (internet connection) either before or after the firewall. In large organization such NIDS usually are overwhelmed by the complexity of the traffic and cannot produce anything but a stream of expensive "security spam" -- email alerts that for years are ignored by personnel (most times this is hidden -- hypocrisy and political correctness rules, but sometimes it's pretty open attitude). This IDS-generated spam is probably the most expensive spam in existence. Still because this is a politically correct thing to have few have courage to dismantle them.
• Site-based NIDS. In a large organization site is an important logical unit of network structure and the whole network is composed on multiple interconnected sites. While to understand the whole traffic is very difficult, to understand the traffic on ingress of the site (site router) is easier and often more productive.
• Special purpose NIDS. Those are speculated on listening on certain types of traffic. One common implementation is VPN NIDS that are listening just to VPN traffic.

Organizations rarely have the resources to investigate every "security" event. Instead, they must attempt to identify and address the top issues, using the tools they've been given. This is practically impossible if an IDS is listening to a large traffic stream with many different types of servers and protocols. In this case security personnel, if any, are being forced to practice triage: tackle the highest-impact problems first and move on from there. Eventually it is replaced with even more simple approach: ignore them all ;-). Of course much depends on how well signatures are tuned to particular network infrastructure. therefore another classification can be based on the type of signature used:

• Generic signature based. In this case like in virus scanners signatures are usually supplied by the vendor using some form of paid subscription. The usefulness of such NIDS is usually quite low. This is exacerbated by attempt of IDS vendors to prove their usefulness by trying duplicate functionality of antivirus mail gateway. Architecturally this is pretty funny attempts, but they are pretty successful as vendors always can find enough lemmings to sell their wires by speculating on virus-related FUD.
• Custom signature based NIDS. Those are more useful and usually can provide some level of useful signal. They are also more expensive as maintaining custom signature set requires high qualification.

Even is case when you limit traffic to specific segment of the internal network (for example local sites in national or international corporation, which is probably the best NISD deployment strategy) the effectiveness of network IDS is low but definitely above zero. That can be marginally useful in this restricted environment. Moreover that might have value for network troubleshooting (especially if they also configured to act as a blackbox recorder for traffic; the latter can be easily done using TCPdump as the first stage and processing TCPdump results with Snort (say, each quarter of an hour)and then reprocessing alerts with Perl scripts. Snort stage is optional and Perl can be used directly as was done in Shadow. Please not that all those talks about real time detection are 99% is a pure security FUD. Nothing can be done in most large organizations in less then an hour ;-)

That's why many large enterprise customers (especially those who still staff that have some clue, despite all efforts spend on outsourcing) started to defect commercial IDS vendors approximately in 2003. See my IDS Whitepaper for details. In order to preserve their business (and revenue stream) IDS vendors started to hype intrusion prevention systems as the next generation of IDS. But IPS is a very questionable idea that mixes the role of firewall with the role of IDS sensor. It's not surprising that it backfired many times for early (and/or too enthusiastic) adopters (beta addicts).

It is very symptomatic and proves the point about "innocent fraud" that intrusion prevention usually is advertised on the base of its ability to detect mail viruses, network worms threats and Spyware. For any specialist it is evident that mail viruses actually should be detected on mail gateway and it is benign idiotism to try to detect then on the packet filter level. Still idiotism might be key to commercial success and most IDS vendors pay a lot of attention to the rules or signatures that provide positive PR and that automatically drives that into virus/worms detection wonderland. There are two very important points here:

• The detection of a SMTP viruses/worms should be done on higher level of protocols (it's an extremely questionable idea to use packet filter like snort for detecting email viruses -- kind of network security Lysenkoism ;-). If a particular virus/worm is propagating by mail, the detection (and blocking) should be done on mail gateway, not in IP packets analyzers. But NIDS vendors needs to survive that this is the most lucrative from PR standpoint area so the results are evident: any technical logic is bypassed by marketing. If an organization attempts to detect SMTP viruses using packet filter like snort it is usually sign on complete lack on architectural vision (as well as networking skills) of personnel or advanced stage of outsourcing. Buyers of ISS managed services automatically qualify for this litmus test ;-)
  
• A new successful network worm typically requires new signatures and commercial IDS vendors are typically very bad (always late) in this area. That actually not completely true as two recent network worms used the same TFTP based propagation but generally copycat attempts fail. New global worm propagation usually happens when the worm author manages to find a new propagation vector.

May be things eventually improve, but right now I do not see how commercial IDS can justify the return on investment and NIDS looks like a perfect area for open source solutions. In this sense please consider this page a pretty naive (missing organizational dynamic and power grab issues in large organizations) attempt to counter "innocent fraud" to borrow the catch phrase used by famous economist John Kenneth Galbraith in the title of his last book "The Economics of Innocent Fraud".

Programmability of NIDS

Important criteria for NIDS is also the level of programmability:

• Ad-hoc approach were NIDS use some language that started from humble beginning and evolved during the evolution of a particular implementation. Snort is a good example of this category.
  
• Scripting language based approach. Some networking IDSs are based of using a scripting languages as the main traffic analysis engine and that's presents a considerable advantage. The early example of this approach was Shadow. As I mentioned above speed of processing packet is not an issue. Most NISD can happily do complex processing offline after the initial binary dumps of traffic were created by TCPdump or similar tools.

  Attempts to use NIDS "inline" lead to classic "premature optimization" problem and are generally detrimental to quality of NIDS as they dictate some ad-hoc solutions.

  "Black box" approach where traffic is first written on the disk and then analyzed is the only right approach if you really want to detect a useful signal in a typical amount of network noise. Here Snort managed to improve from its early days and the current version of Snort supports Perl-style regular expressions. But still using in in-line created the problem of overloading the engine and loss of packets. Using Snort offline you can create as complex set of rules as you wish. And hopefully, in rare cases of combination of really high network qualification and knowledge of particular infrastructure, you can substantially (anything that raises the value from infinitely small values in substantial :-) improves the ability to pickup useful signal.

It's rather difficult to place NISM in segments with large traffic. Mirroring port on the switches work in simple cases, but in complex cases where there are multiple virtual LANs that will not work as usually only one port can be mirrored. Also mirroring increase the load on the switch. Taps are additional component and are somewhat risky on high traffic segments unless they are designed to channel all the traffic in case of failure. Logically network IDS belongs to firewall and some commercial firewalls have rudimentary IDS functionality. Also personal firewall with NIDS component might be even be more attractive for most consumers as they provide some insight on what is happening. They also can be useful for troubleshooting. Their major market is small business and probably people connected by DSL or cable who fear that their home computers may be invaded by crackers.

Among open source network Intrusion Detection Systems (IDS) Snort is the most well developed and powerful solution. It covered in a separate page. But along with network-based intrusion detection, one probably should pay more attention to host-based IDS that uses log analysis and integrity checking. One should never put all eggs into one basket. The most popular integrity checker is Tripwire, but it's somewhat too primitive for the intrusion detection. See Softpanorama Integrity Checkers

The problem is that useful signal about probes on actual intrusions is usually buried under mountains of data and wrong signal may drive you in a wrong direction. A typical way to cope with information overload from network IDS is to rely more on the aggregation of data (for example, detect scans not single probes) and "anomaly detection" (imitate firewall detector or use statistical criteria for traffic aggregation). Misuse detection is more costly and more problematic that anomaly detection approach with the notable exception of honeypots. It might be beneficial to use a hybrid tools that combine honeypots and NIDS. Just as a sophisticated home security system might comprise both external cameras and sensors and internal monitoring equipment to watch for suspicious activity both outside and within the house - so should an intrusion detection system.

You may not know it, but a surprisingly large number of IDS vendors have license provisions that can prohibit you from communicating information about the quality and usability of their security software. Some vendors have used these software license provisions to file or threaten lawsuits to silence users who criticized software quality in places such as Web sites, Usenet newsgroups, user group bulletin boards, and the technical support boards maintained by software vendors themselves. Here open source has a definite advantage, because it may be not the best but at least it is open, has a reasonable quality (for example Snort is very competitive with most popular commercial solutions) or at least it is the cheapest alternative among several equally bad choices ;-).

IDS often (and wrongly) are considered to be the key component for the enterprise-level security. Often that is achieved by buying fashionable but mainly useless outsourced IDS services. Generally this idea has a questionable value proposition because of the level of false positives and problems with the internal infrastructure (often stupid misconfigurations on WEB server level, inability to apply patches in a timely manner, etc.) that far outweigh and IDS-inspired capabilities. If you are buying IDS, the good staring point is to ask to show what attacks they recently detected and negotiate one to six month trial before you pay the money ("try before you buy").

The problem of false positives

The problem of false positives for IDS is a very important problem that is rarely discussed on a sound technological level. I don't think there is a 'best' IDS. But here are some considerations:

• Quality of custom signatures and the procedure for their update. Any signature-based NIDS is as good as the signature database and here we have the major problem: generic signatures while marginally useful on low traffic deployment (site routers) does not provide much interesting information. The most interesting information you can get from custom signatures, that reflect the specifics of the network architecture for a particular organization as well as implicit restrictions on the traffic that exist in the sensing point. Without constant work on custom signatures usual installation of Snort generates some interest for a month or so and then becomes completely neglected like home exercise equipment.

  The same is even more true for the commercial IDS (people who install Snort on a gegular Unix/Linux boxes are usually more technically savvy that people who buy IDS appliances).

  While capabilities of the current NIDS are more or less OK (Snort 2.5 is one example) generic signature database is usually completely detached from the reality of your network traffic and without careful tuning cannot produce useful signals with deafening amount of noise (false positives). Also the number of rules in the database that is often stressed in marketing does not mean much: 10 000 outdated rules does not buy you anything but additional false positives. 100 current rules can do much better job.
  

• The capabilities of the box (sensor). Under heavy load most "real-time" NIDS systems that have complex signature databases will perform radically differently on, say, a 1.6Ghz Pentium with 256M of RAM (desktop used for a sensor) compared to a 3.2Ghz dual CPU machine with 4G of RAM. May be 3.2Ghz and 4G of RAM is overkill (of course it depends on the configuration), but with current prices it is still a cheap entry level server that costs 25% of the cost of IDS appliance.

  Generally you need to ensure that the sensor does not drop packets under heavy load. But actually the best way to ensure this is to write the stream into a file using TCPdump and then analyze it with snort, forward alert to Acid/Base analyze alerts with Perl, Tivoli or other suitable for events integration and correlation tools.
  

• Level of packet analysis. Packet capture rates don't mean much unless you also take into account what the product can do with packets after it's captured them. That's why it's important to separate packet capture from packet analysis and do packet analysis in some batches (let's say 15 min). How much analysis does the IDS actually do and can it recreate the session? This is a really interesting area. For example Snort is usually configured with plug-ins that do decrementing and IP reassembly into valid streams that can be then replayed.
  
• Database used for the storage of packets. What you can do with data written on the disk depends on whether you store it in database of in text (or raw binary) format. Storing all "suspicious" packets in the database along with alerts is useful and can provide more user friendly front ends, but generally everything that can be done with database can be done without it only slower. You essentially trade speed for disk space.
  
• Integration with ESM. For example if an organization uses Tivoli it should be some Tivoli integration at least for critical NIDS alerts. That can be done via TEC log adapter or other mechanism but it needs to be done.

You probably got the idea at this point: the IQ of the network/security administrators and the ability to adapt the solution to this organization is of primary importance in the IDS area, more important then in, say, virus protection (where precooked signatures sets rules despite being a huge overkill). That's why open source solution and commercial solution that permit signature tuning are vastly superior to alternatives. From this point of view ISS simply does not stand a change to compete.

All-in-all the architecture and the level of customarization of the rulebase are more important then the capabilities of the NIDS.

Dr. Nikolai Bezroukov

Webliography

• SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)
• Evaluation of Intrusion Detection Systems
• Unix Host and Network Security Tools
• NIST Special Publication on Intrusion Detection Systems
• DARPA's Scalable Network Monitoring program

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: August, 20, 2019