RE: Firewall Activity analysis

["Matthew F. Caldwell" <mattc () guarded net>]

Anton, 

         I agree with you on the fact that simple rules can create a
nasty level of false positives.  Depending on the complexity of the
rules engine, it can provide a reduction in work load for the security
analyst aka a REAL ROI - Time (money) X Incident. For example if you see
the multitude of attack signatures that indicate Nimda from an IDS, and
then you have a rule that identifies that as NIMDA. Again depending on
the complexity of the rule, you no longer have to review the logs to
determine if it was Nimba. If the host that was infected was located
internally you could use the rule to issue some remediation (wither
automated or manual). 

        Packet payload, anomaly detection is in its infancy, yet it is
steadily progressing along with anomaly detection at the higher level.
With both adding value, even in the infancy. NIDS provides high rates of
false positives this is true however that level of false positive can be
measured (rate of false positives/actual events) and thusly can have
impact to system that does Risk or Threat Modeling. 

        Your point about the attacks not being in the logs files is
correct (for the top 20% of uberhackers) IF you're only using a NIDS
(and maybe HIDS). My point is that the correlation/anomaly detection
system would catch most of the 20% if the logs that the system was
receiving where adequate. For example, any new attacks that the attacker
tried on the web server would be in the access.log, any deletion of
those logs might show up in AIDE, and finally if they crashed the apache
server, the error.log might show something out of the ordinary
(anomaly). 

I'm going to try to address the issue Matt Harris was talking about as
well. What you need to do is create rules for the known not unknown.
Leave the unknown to the anomaly detection. Also, wouldn't say disaster,
because, it would in essence be doing its job letting you know someone
was accessing the information on the regular web server directly instead
of securely. Additionally you would want to re-establish a baseline at
that point. 

Matt

-----Original Message-----
From: Anton A. Chuvakin [mailto:anton () chuvakin org] 
Sent: Wednesday, December 11, 2002 3:58 PM
To: focus-ids () securityfocus com
Cc: Anton Chuvakin
Subject: RE: Firewall Activity analysis
Importance: High

All,

> discovering new attacks/attackers. Anomaly detection via statistical
> analysis would be an effective method for discovering these new
attacks.
Well, isn't it one of those things that is mentioned much more often
that
it is implemented? Many people say its a good idea to have a full-blown
anomaly detection running on log data and even more people agree with
those saying that :-) However, anomaly detection is kinda lacking even
for
the packet-level stuff (which is more rigid in format than system logs).
Many discussions on Tina Bird log-analysis list happen around this very
topic - and there doesn't seem to be any meaningful bottom line [yet].

And the dangerous thing about jumping in and implementing some simple
rules (such as "connection failed -> conn successful"), might create a
nice little (well, BIG actually!) "false-positive machine" and NIDS
systems already provide plenty of that.

Discovering new attacks via statistical anomalies sounds prmising, but
what is the evidence to suggest that those new attacks will be in the
log
files in the first place?
(see, e.g. http://www.immunitysec.com/dailydave/9.24.2002.html)

Best,
-- 
  Anton A. Chuvakin, Ph.D., GCIA
     http://www.chuvakin.org
   http://www.info-secure.org