criticism of snort in articles that I can not remember being explained or rebutted on this list. Device Discovery slash manually configuring snort.

["Jacob, Raymond A Jr" <raymond.jacob () navy mil>]

Firstly, I appologize in advance if this issue has been discussed and I
missed it in
corespondence or I just need to RTFM.

I have seen reviews of IDS products with snort and they all mention that
snort
requires to much manual configuration and tuning. At first, I thought
there
is a reason why you never see "Intrusion Detection for Dummies" in the
book store
because in order to do network intrusion detection right you need to
know about
network security so Dummies need not apply.
I think most of the people on the list know how to read an ip packet and
acid gives you enough of an idea to know someone is trying to hack into
your network.

Then after reading these reviews and all of them saying to me the say
thing, I had to ask
myself what are these criticisms really saying. What I understand them
to say is
that snort can not tell me what to worry about in my trusted network and
DMZ.

    Before one can effectively monitor a network for intrusion, 
one must be able to eliminate false positives from known devices.
At this time as far as I know this process is done manually. However,
there are tools
such as cheops or nmap which can determine what hosts are running
webservers, 
or pop mail servers, or ftp servers... in your trusted network or DMZ.
Information about services running on particular hosts could not only be
used
to filter events but to raise an alert when the IDS recognizes an attack
signature
destined for a host with that service running.
The question is: why can not nmap or cheops be used to automatically
configure
HTTP_Servers(?) or create rules and alerts in snort for hosts in the DMZ
and Trusted Networks
with well known services?

When there is a problem and server or workstation is running netbios, I
ping the ip address and
use nbtstat to find the name of the computer. If nbtscan could be used
to identify computers 
in order to provide limited windows name resolution to the ACID names
table, furthermore the ACID(MySQL) server
could run winbind to populate a machine, user, group table in the ACID
names table.One could argue 
that DNS will replace WINS one day. I don't know if that day will come
soon.
The questions here are:
1. If ntbscan does not use a broadcast mechanism and netbios-dgm(135) is
allowed
to travel within the trusted network, why can't it be create an
/etc/hosts file
to provide name resolution in snort?
2. If winbind is run on the ACID(MySQL) server will resolving Windows
User names
put such a burden on the ACID(MySQL) server that it can not receive
information from
snort?


ACID has a great schema however the tool is very limiting and does not
provide information to me
in a useable format. I must generate a text file and run a perl or sed
script to generate a report
to get useful information.
For example, I would like to look at the information
in three ways: First, I liked to determine the total number of alerts
with dest. port 80 from source network with a class
C network mask. Second I would list by source ip address and network
destination address(i.e. And ip
address with class mask or just convert to string and replace last octet
with 0.) the number of alerts.
Third, when the total number of alerts for a particular alert was over
80, I would try to resolve the ip address
into a name. ACID does not provide this ability as far as I know. 
The question here is (I will admit that talk is cheap and I don't know
the amount of effort involved)
that there is a need for a daily, weekly, monthly,..,long term trending
IDS management station for professional network
security analysts. Will acid evolve into this tool? 
Conversely, at the low end and for wide deployments where there are no
professional network security analysts. 
One needs what I call a trained monkey IDS alert station with christmas
tree lights. Basically this consists of a table with cells or a tree
with branches
that turns green, yellow, and red depending on the
serverity and number of network events. The user clicks on a light, a
description of the event pops up
with the source address, the port, and destination network. I don't know
what type of ids alert
tool -i.e. professional or trained monkey- should be included in snort.
I will tell you that  there are many
organizations that bought earlier versions of ISS and figured it is a
GUI so we don't need a qualified
person to run it. ISS was basically brain dead back then - i.e. no
packet dumps- so you either went
brain dead trying to run it or just ignored it.

Lastly and although this was not mentioned in the reviews, there is a
big push to combine alerts/denials from all network
security devices i.e. routers, firewalls, and IDS's. Meaning that at
some point in time logsnorter may have to
become part of the basic snort package.



In conclusion, it is my opinion that commercial customers want no
brainer solutions because either
they don't have or can not afford professional network security
analysts. This is the customer
the trade magazine and journals are writing for. This means that I hope
snort becomes
an network detection system composed of an engine, management console,
and alert station
to insulate the untrained security analyst while providing the tools
that the
professional analyst needs to be productive.
However, until snort becomes a no brainer the reviews will continue to
portray snort as the 
cinderella of IDS's. The problem with bad press is that some managers
don't know enough
to objectively decide on what solution is best for the organization and
proprietary vendors
in their sales pitch will say that snort is too difficult to configure
and
our product won an A+ from .... magazine. I appologize for this
distracting email. I just
get the sense that everyone is so wrapped in the technology that we
forget that everyone
is not like the users on snort-users. That is why no one asked the
question why snort is
always reviewed with a negative spin, i.e. Snort it is great, but...

Respectfully,
Raymond
PS: These thoughts are my own definitely not my employers.