1. Using decision trees to improve signature-based intrusion detection
Yaxuan Qi
FIT NSLab
Dec 15, 2005

2. Outline Main Idea Decision Tree Construction Decision Tree Traversing
String Matching in a Sub-ruleset
Experiments
Discussion

3. Main Idea Rule Clustering using Decision Tree
Reduce the number of rules that need to be compared
Based on rules, not the experiences or statistics
Using a variant of the ID3 algorithm
Example:

4. Decision Tree Construction
We have AC, BM…, Why still need a decision tree?
Parallel algorithms may consume EXCESSIVE memory
BM requires EXPENSIVE multi-string matches.
Rule clusters in Snort (by dIP & dPort):
It is still too large, so simple clustering is not enough…

5. Decision Tree Construction
Building The Decision Tree
Feature selection

6. Decision Tree Construction
Building The Decision Tree:
Entropy Computation:
Maximum number of Rules in S
Entropy of rule set S
The probability of a rule to be triggered.
If Smax=n and pi=1/n
If Smax=n and pi=1/n

7. Decision Tree Construction
Building The Decision Tree:
The ID3 algorithm: To maximize the Information Gain
Information Gain of feature F on set S
Number of rules with an identical value v for feature F
The set of different values of feature F
Number of rules in S

8. Decision Tree Construction
Building The Decision Tree
Rules with wildcard

9. Decision Tree Traversing
Feature Comparison
Range matching: using binary search.
E.g. if dPort=21, then we go through: (1) 21<25 ; (2) 21<23; (3) 0<=21<=22. This takes O(logN) time.

10. Decision Tree Traversing
Feature Comparison
Finding correct successor node: by pointer array 1 2 3 4 5 7 6 8 9 10 11 12 p1
E.g. if dPort=21, we must first load p1, then can we know where is node2. This takes O(1) time.

11. String Matching in a Sub-ruleset
Algorithm Selection: AC, BM or others?
The number of rules in a sub-ruleset might ranges from 1 to several hundreds (no experiment result in this paper).
BM is efficient for small number of rules;
AC is efficient for rules with a common, identical prefix.
This paper adopts Fisk-Varghese approach which delivers good performance for medium sized strong sets (containing a few up to a few dozens elements)

12. Experiments Snort vs. Snort NG: processing time comparison
X-axis: test traffics of 10 different days, ranging from 216MB to 838MB.
Y-axis: processing time (seconds). Snort NG is 5~103% faster than Snort.

13. Experiments Snort vs. Snort NG: processing time comparison
X-axis: number of rules, ranging from 150 to Using the traffic of the first day.
Y-axis: processing time (seconds).
Better with more rules??

14. What happened around here??
Experiments
Snort NG: memory consumption
X-axis: number of rules, ranging from 150 to Using the traffic of the first day.
Y-axis: memory used by Snort NG (KByte).
What happened around here??

15. Experiments Summary: Platform: P4 1.8G
System: RedHat Linux kernel;
Code: Snort (for Snort NG); Snort 2.0 (for Snort)
Traffic data: 1999 DARPA intrusion detection evaluation traffics (MIT Lincoln Labs data sets).
Rule transformation: 1581 to 2398 with different topologies (as needed for MIT/LL data).
Average performance improvement: 40.3%
Preprocessing time: <12 seconds

16. Discussion Critics from WUSTL: Critics from NSLab?
Focus on the header, why not the content?
Why not HiCuts?
The usefulness of the information gain techniques?
Do not plot Snort memory consumption
Critics from NSLab?
Binary search in a tree node, is it efficient?
What’s the exact worst-case: tree depth, leaf-node size
Packet Classification rules vs. Snort rules …

17. THANKS