Method to the Madness: Anomaly & Signature Redux

[Pete Lindstrom <petelind () spiresecurity com>]

It is no surprise that the words "anomaly" and "signature" get used in 
very different ways - they are very vague words, and sound pretty cool. I 
have spoken with many vendors in the Threat Management space and it 
usually takes half of the briefing for me to get an understanding of what 
they do (of course, that is probably more my fault than their's).

I have tried to identify companies in the past by the basic idea of 
signatures, protocol anomaly, traffic anomaly, etc... but people have a 
tendency of changing the words they use for the stuff that is out of 
favor (signatures) and latching onto the new stuff. Nowadays, multimethod 
detection is in vogue ("we do it all").

I have come to the conclusion that we need something more granular than 
sig/anom just to be able to compare and contrast solutions in this 
constantly growing space. My idea is to identify the techniques a 
solution uses and map it to the information being looked at. I call it 
the method (technique) to the madness (information) matrix. No matrix 
here, but I've included the elements for review. I would love feedback 
particularly if I am unclear or missing something (I have my own 
reservations about some of this).

The goal is to create a chart that is granular enough and specific enough 
to allow someone to identify similarities and differences among products 
and product categories, and properly evaluate tools and solutions.

MADNESS (What we look at):

[typical network stuff]
Single Packet -
 Layer 2 header
 Layer 3 header 
 Layer 4 header
 Packet payload
Reassembled Packets/objects
Sessions
Traffic flow

[host-based stuff]
Ports
RPC/COM/DCOM Activity
Kernel Activity
File System Activity
Registry Activity
(other system state information?)

[specific apps that have created their own demand for security]
Email messages
Web pages
Active code

[more on a meta level, perhaps]
Activity Logs
Vulnerability Logs
Security Event Logs

METHOD (how we look at it):

Pattern Matching/String Search
RFC Compliance Match
 Reference Implementation Match
Policy/Rule Compliance (company or app defined)
Protocol/App Command Match
Lexical Analysis
Statistical Analysis (a whole bucket here - any ideas how to 
subcategorize?)
Trend Analysis (could be stats)
Correlation (Source, Destination, Attack Type, ...)

I think it is also useful to classify this information based on whether 
the overall approach is a 'whitelist' approach, i.e. it sets policies and 
flags or blocks anything that doesn't follow the policy; or a 'blacklist' 
approach that attempts to identify specific things that can go wrong and 
flag or block those events.

I am still working on fleshing this out so your feedback is welcome.

regards,

Pete
Spire Security
www.spiresecurity.com
petelind () spiresecurity com