RE: Firewall Activity analysis

From: Matthew F. Caldwell (mattc@guarded.net)
Date: 12/12/02

  • Next message: Rob Shein: "RE: Crossover Error Rate (WAS "Intrusion Prevention")"
    Date: Wed, 11 Dec 2002 22:57:03 -0500
    From: "Matthew F. Caldwell" <mattc@guarded.net>
    To: "Anton A. Chuvakin" <anton@chuvakin.org>, <focus-ids@securityfocus.com>
    

    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
    


    Relevant Pages

    • RE: False Positives with IntruVert
      ... right on defense for IPS that I have seen. ... Subject: False Positives with IntruVert ... There are clearly attacks that will 100% not false positive. ...
      (Focus-IDS)
    • RE: False Positives with IntruVert
      ... Subject: False Positives with IntruVert ... a different statement than IPS is not functional or not worth time or money. ... prevent attacks, ... profiled the attacks (signature or anomaly or combination of both)) has ...
      (Focus-IDS)
    • RE: False Positives with IntruVert
      ... product but to put into perspective the CURRENT value of IPS. ... There are clearly attacks that will 100% not false positive. ... have all been burned with false positives and I am sure that is where the ... Subject: False Positives with IntruVert ...
      (Focus-IDS)
    • RE: Network hardware IPS
      ... Assunto: RE: Network hardware IPS ... > are going to catch novel or semi-novel attacks using very specific rules ... > produce more false positives than we can handle, ... being "attacked" on something you have no vulnerability against (i.e. you ...
      (Focus-IDS)
    • RE: Specification-based Anomaly Detection
      ... >Or highly polimorph attacks, yes. ... >defines a listening application, so we can profile ... What about apps that all tunnel over a single port? ... >actionable anomaly detection result. ...
      (Focus-IDS)