Re: Intrusion Detection Systems

From: George B. Magklaras (
Date: 05/01/02

Date: Wed, 01 May 2002 15:06:11 +0100
From: "George B. Magklaras" <>

Walter Roberson wrote:

> In article <>,
> George B. Magklaras <> wrote:
> :After all, if you want to go down the cheap route due to budget
> :constraints (at your own risk!!!) you at least put SNORT in your
> :infrastructure. It costs nothing and it is certainly useful!
> I would argue with your final statement there. SNORT does not install
> itself, so at the very minimum it "costs" the installation labour.
> IDS's cannot read your mind about what are acceptable transactions and
> what are not, so SNORT also has configuration costs. The reviews I've
> read of IDS systems indicate that *every* IDS suffers from false
> positives and false negatives -- so use of SNORT has costs associated
> with investigating the false positives, and it has risk-costs
> associated with overtrusting it and so not noticing the packets it
> falsely declares acceptable.

I have never said that SNORT install itself.No software (that I know of)
does :-) !The misunderstanding here was caused by the fact that I should
say 'it has zero purchase cost' as opposed to 'It costs nothing..'. In
addition, I have also commented on the level of system admin skills.
What I was trying to say was : "If you have a skilled sys admin team and
a restricted budget, it would be more appropriate to utilise your admins
and set up a basic IDS to safeguard your infrastructure rather than not
having an IDS at all. At the end of the day, you are paying them to
administer your system and part of the sys admin's job (in my view) is
to address security issues. If you take a proprietary solution, you
still have to pay money to purchase it and you would still have to pay
your admins to use it.

In summary, you have 3 possible scenarios:
- 1)You have no IDS at all and you need to pay your admins salaries.
- 2)You have a basic open source IDS (zero purchase cost) + admin
salaries + IDS host hardware expense? + independent penetration testing
- 3)You have a cost of purchase (expensive/proprietary IDS) + admin
salaries.+ IDS host hardware expense? + independent penetration testing

In any case and with a RESTRICTED BUDGET I believe that you are far
better off with the second choice, given that a good sys admin SHOULD be
able to always address those issues. (By the way, if you bother to
deploy an IDS, you should bother getting an independent opinion about
its capabilities by hiring a professional penetration tester).

> Is the IDS to protect against internal intrusions or against external
> intrusions? If against internal, then if you have a switched network,
> there can be non-trivial costs in arranging so that *all* the traffic
> is seen by the IDS. Switches will usually only span to a port, not to a
> VLAN, and in order to preserve the VLAN information properly [e.g., if
> one wants to watch out for attempts to hop VLANs], one might need one
> span port per vlan. One then has to securely transport that
> information to the IDS, through a parallel infrastructure that is
> faster than the aggregate traffic rate through the valid switch ports
> [otherwise IDS-relevant data might get dropped when the ports are
> busy.] This is certainly not going to be free to configure, even if one
> happens to have had all the equipment donated.

In theory, you could end up having to talk to a Gigabit Ethernet switch,
at which point the near-real time performance of an Network IDS is
seriously degraded anyway. As far as Fast Ethernet is concerned, I have
tested SNORT at 90% saturation on a CISCO CATALYST switch 'all-traffic'
LAN port. It was still giving me good detection results (dropped on
average 300/5939993003 packets per snapshot and detected 32/40 simulated
  attacks I launched against it (half of them were payload related and
required stateful info). That's pretty good for a tool that costed me
nothing to purchase, and yes it did worth the time and the effort to sit
down and try to optimise it as a sys-admin.

> If the IDS is to protect against external intrusions, then essentially
> what it is monitoring for is A) the possibility that the firewall has
> been compromised; and B) the possibility that the firewall has been
> configured incorrectly. But firewalls get reconfigured as new needs
> develop and as old dataflows go out of service, and the IDS's notion of
> what is allowed and what is alarming has to be updated at the same time
> as the firewall {or else you are back in the false-negative/
> false-positive territory again.} That has definite labour costs. One
> must configure the IDS separately from the firewall: if one uses a
> common control file to generate the configurations for both, then any
> slip in the common control file would leave *both* systems open and you
> might as well not have the IDS then. Even if one has two distinct
> control files and the configuration structure works very differently
> between the firewall and the IDS, a mental lapse in determining what
> needs to be changed for one of the two can all too easily be carried
> over to the other. (People tend to make the same mistakes even when
> writing in different programming languages: misread something once and
> you might well misread it again the next time.)

Yeap, I can see the overhead that you mention, but that is the point of
having Software Revision Control Procedure, as part of your technical
management practice. When you update the configs or the software
versions of business critical systems, you should have a team that will
review those changes, stating expected risks/faults/ and indicating the
way the changes should be rolled out. Whether you are using an
IDS/Firewall/DBMS/ or any server/client host that is irrelevant. This
management feature should always be there and if you bather to do it for
other computer systems, you might as well apply it to your security
infrastructure components.If your firewall rules change, then there is
nothing to stop you from changing your IDS signatures to address those
changes. Mental lapses always occur in every aspect of the professional
IT field, and that's what makes the profession and all its stimulating

> Even when there are no license costs, one should think hard
> about what one wants out of the IDS, about the extent to which that
> particular IDS can deliver those goals, and about the amount of labour
> that one can afford in maintaining the IDS.

I would agree to a certain extent that ID Systems represent a relatively
new technology with many teething problems. In short, they can only
detect what they know about (much like single anti-virus products) if
they use signature-based methods, and yes they do create a alot of false
positives (and negatives) when they employ anomaly detection. But still,
I view them as a valuable complement of a security infrastructure,
simply because they increase your chances of detecting something. They
do not degrade them.

Relevant Pages

  • Re: Intrusion Detection Systems
    ... SNORT does not install ... so at the very minimum it "costs" the installation labour. ... read of IDS systems indicate that *every* IDS suffers from false ... what it is monitoring for is A) the possibility that the firewall has ...
  • Re: Intrusion Detection Systems
    ... SNORT does not install ... so at the very minimum it "costs" the installation labour. ... > read of IDS systems indicate that *every* IDS suffers from false ... > what it is monitoring for is A) the possibility that the firewall has ...
  • RE: "Free" IDS
    ... For a small office or a single person, those indirect costs are negligible. ... Cisco has a nasty habit of giving away their IDS when you buy enough switches and such, and ManHunt will probably follow suit with ISS especially since Symantec is eager to get into that market. ... > Anitian is committed to both commercial and open source ... > implement open-source solutions to ensure maximum ...
  • Re: Unique ID?
    ... which duplicate "unique" ids exists and it costs a lot of timely afford ...
  • RE: Thinking about Security rules...
    ... > Subject: Re: Thinking about Security rules... ... >>rules for the IDS. ... by which you attack. ... firewalls in series isn't nearly as nice as a stateful firewall coupled ...