I think a lot of this goes to the level of maturity an
organization has. If they are the wild west with no idea
what is on their network, it's hard to figure out what
is expected behavior and then look for deviations from this.
On the other hand, if exact details of who should be talking
to who are known, exceptions to this can find intruders and
folks behaving poorly.
This is one of the main reasons Tenable is in both the
vulnerability and security event management businesses as I
feel they are completely tied at the hip.
If folks want to read more on this type of approach, they
should check out Tenable's "Network Security Implications
of 'Visible Ops'" paper at:
http://www.tenablesecurity.com/whitepapers/compliance.shtml
This discusses how SIM, VA, passive monitoring, .etc can
help
move an organization from an un-managed to managed state.
Tactically, an organization using all of Tenable's products
can monitor which assets communicate with each other and
easily
write TASL scripts to look for activity outside of those
ranges.
These relations can come from passive sniffing, netflow and
log analysis.
For example, our NeVO sensor can sniff traffic to/from your
DMZ
and find the SSH, SNMP, .etc command channels. This info can
be
used to edit one of our exisitng TASL scripts to modify it
to
alert if an SSH connection occurs outside of the expected
behavior.
Ron Gula, CTO
Tenable Network Security
----- Original Message -----
From: Anton Chuvakin <anton@chuvakin.org>
To: Ron Gula <rgula@tenablesecurity.com>
Cc: focus-ids@securityfocus.com
Subject: Re: on TASL correlation rules
Date: Fri, 23 Dec 2005 17:03:13 -0500
Ron and all,
In general though, the issue we've found while writing
these types of rules is that whatever the algorithm,
there is always a trade off between being exact and
being general. That is *exactly* the discussion I wanted
to start! Thanks for picking it up. When one provides
canned correlation rules (such as your TASL scripts), this
question comes up in full force. And, unlike NIDS rules,
where people expect them to work pretty much out of the
box (I think its a dirty little secret that much fewer
customers customize NIDS rules than the NIDS vendors
think...), this one gets real subjective real quick. And
this is where the site-specific rules or scripts come in.
Site-specific rules can get much more interesting. For
example, writing a rule that can alert on any "SSH login
failure" not coming from the SOC is very simple, but you
have to know about the DNS server, the SOC and the trust
relationship between them before hand. This is one of my
favorite examples: its an extremely simple and just as
useful custom rule ("if SSH not from SOC, alert") but an
impossible default vendor -provided rule. The main
question is: how many people will go and create it? Will
the "NIDS disease" (mentioned above) hit it as well and
thus devalue the correlation software?
Best,
--
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
http://www.chuvakin.org
http://www.securitywarrior.com
----------------------------------------------------------
-------------- Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to
http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
----------------------------------------------------------
--------------
------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------
