IDS mailing list archives
Method to the Madness: Anomaly & Signature Redux
From: Pete Lindstrom <petelind () spiresecurity com>
Date: 6 Feb 2003 19:05:29 -0000
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
Current thread:
- Method to the Madness: Anomaly & Signature Redux Pete Lindstrom (Feb 06)