IMHO, we are discussion 1/2 the puzzle:

Anomaly detection should include anomaly according to established rules (one
of which could be RFC or some other standard, such as ASN.1 using BER/PER
encoding etc.), but should also include any observed event that that defies
any known behavior or definition (thus anomalous). This is different from
trend analysis because trend analysis is based on *known* events and is
based over a period of time.

Signature analysis, speaks to pattern matching of known attacks. Anomaly
detection simply point to something that may indicate an event that is of
interest to the analyst, not necessarily directly created to detect a
specifically known attack. Though, ALL types of a detection are arguably
signature based (it's all pattern matching in a way).

These are 2 of the 4 main types of intrusion detection, the other 2 being
exception and trend. Exception based systems alarm when an event that
breaks a set rule, like a policy, is observed. Trend based systems alarm
when an event represents a variant in a defined trend, that is
activity/behavior over a period of time.

It is not the point that one is better than the other, all have pro's and
con's, if all four are not being performed, something will be missed.

My $.02,

Patrick Reidy
Veritect

-----Original Message-----
From: Ron Gula [mailto:rgulaenterasys.com]
Sent: Tuesday, March 05, 2002 9:46 PM
To: focus-idssecurityfocus.com
Subject: Re: Signature vs. Protocol Analysis

I really don't like the terms 'signature' vs. 'protocol anomaly'
forms of NIDS. For the most part, when I hear folks from NFR and
ISS (Network ICE) talk about protocol anomalies, to me this
seems more like an "RFC compliance" engine. For example, check
out OneSecure's web site, and they tell you exactly which RFCs
they've implemented to do 'anomaly' detection on. Finding when
field xyz is to long is extremely useful for a zero detect. On
the other hand, there are a host of NIDS that check for port
scans and TCP checksums and call those 'anomalies' as well.

I think the signature debate also gets cloudy when you consider
that Dragon and Snort have sigs for things like the "PASS"
command for FTP followed by an unusually long string which
could be a buffer overflow or a DOS. Although the 'full' RFC
analysis is not implemented, the core functionality can be
replicated with a handful of signatures.

My concern with the RFC analysis approach of a protocol is
that vendors and open source developers may implement the
protocol incorrectly. Consider all the crazy varieties of
UNICODE stuff that is floating around, or more recently, the
various SNMP implementations that are present.

Ron Gula
dragon.enterasys.com
Enterasys Networks

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]