[logs] Signatures

mjr@private

[I updated the subject: line]

Stephen P. Berry wrote:
>Well, part of this is obviously the heavily-entrenched `signature'
>mentality which characterises the (vast) majority of system monitoring/log
>analysis/intrusion detection/antivirus/spam handling products today.
>Let us imagine that I have just ranted for several paragraphs about this.

:)

Let me point out that:
a) you're right
b) signatures have their place

"Signatures" have become a marketing buzz-word for "bad thing you don't
want in a security product" to the point where vendors are bending over
backwards to claim that their systems are "signatureless" for some very
limited definition of the term "signature."  Most of them are, in fact, signature
based anyhow.

A "signature' is a matching rule attached to a identifying diagnosis.
        Thus:   IF ( strlen(username) > 100 ) THEN PRINT ("user name too long!\n");
                port 25: /^DEBUG/ -> "SMTP Wiz attack"
                if more than 20 RSTs come from a machine warn("scanning activity?")

I saw one "signatureless" security product that counts the number of ARP requests
from a given host that are not fulfilled and, if the number goes higher than a set
value, concludes that scanning is taking place. That's not signatureless. The
signature is:
        IF ( bad ARPs > X ) THEN PRINT ("scanning from $src")

Anyhow, if you accept my definition of "signature" (it is admittedly broad) then
you'll notice that it's ONLY through a signature that you can get ANY KIND of
fixed diagnosis about the significance or type of event that took place. That
is incredibly useful!!

True signatureless systems generate results like: "the ratio of SYN to FIN
packets is 2 standard deviations from the norm for this time of the day."
They leave it entirely up to you to figure out the significance. By the way,
one could maybe even argue that knowing that there IS significance to
the relationship of SYN:FIN packets might be a form of signature. If, in the
example above, the system said:
        IF ( SYN : FIN > X ) THEN PRINT ("possible SYN flood in progress")
that's a signature.

Let's not be quick to dismiss signatures!! They're the only tool we have
for encoding knowledge into our security systems.

That's 1/2 of the problem!! The OTHER 1/2 the problem is how to encode
ignorance (anti-knowledge) into our security systems!!!!!!!

Nobody has tried this, yet. But what it someone tried to do "artificial ignorance"
in an IDS: model what everything that's OK looks like and alert whenever
traffic occurs that doesn't fire an "ignore this" signature. Note to readers; I
hereby disclose this as prior art so if some idiot patents the idea, we can
all point to this posting. ;)

>Pause for thought:  how many monitoring widgets (system monitors, log
>monitors, IDSes, or whatever) allow you to enunciate a risk analysis or
>threat model in their configuration?  My contention:  if you can't
>enunciate such a thing, then the concept of `anomaly' is almost certainly
>poorly defined.

You're 100% correct. This is where the industry is sloooooooowly heading.
What you're describing is 'just' "default deny" writ large. Know your policy
and alert to deviations from it. This concept is ancient in security and has
been long-considered to be "too expensive" or "too hard" etc.

Here's a theory:
        - It's reaching the stage where the costs are going to flip-flop
        so that it'll actually be CHEAPER to know what's good than
        to look for what's bad. This is thanks to the huge proliferation
        of hack-ware.

>My point:  either you tell a widget what is Known Bad (with the assumption
>that everything else is Good---or at least Acceptable) or you tell a widget
>what is Known Good (with the assumption that everything else is Bad).

Right! 100% on the money!

Put another way: it's easier to know who your friends are, than to keep
track of all your enemies IF and ONLY IF you have fewer friends than
enemies. ;)

mjr. 

_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis