Investigation and Evaluation of Systems for Generating Automatic Alerts Using Honeynet Data

Download Report

Transcript Investigation and Evaluation of Systems for Generating Automatic Alerts Using Honeynet Data

Investigation and Evaluation of
Systems for Generating Automatic
Alerts Using Honeynet Data
Master’s Thesis Seminar Presentation 9.8.2005
Esko Harjama
Contents
Background
 Problem statement & Methodology
 Introduction
 Alerting issues
 Automatic Isolation Function
 Evaluation
 Prototyping
 Results & Conclusions

2
9.8.2005
Background

Supervisors



Instructor


3
Prof. Jörg Ott (Netlab),
Prof. Guillame Urvoy-Keller (Eurecom)
M.Sc. Idar Kvernevik (F-Secure Oyj)
Carried out as a project for F-Secure
9.8.2005
Problem Statement




Honeynets gather information on illicit network traffic and
attacks against Honeynet computers
These attacks need to be recognized and investigated
Since 24/7 system monitoring is not practical, an effective
alerting system is required to complement monitoring
processes
The problem is




4
How to implement alerting
Where to deploy it
What information and rules should be used to decide when
to trigger alerting
Is there need to isolate the computer in addition to alerting
and in what cases
9.8.2005
Methodologies used

Literature study



Evaluation


Evaluation of the pre-selected tools based
on criteria
Prototyping


5
IDS, Honeypot and alerting background
Investigation of existing tools and methods
for alerting
Prototyping the selected solution in the
reference environment
Analysis of the results
9.8.2005
Introduction:
Intrusion Detection Systems, Honeypots


6
IDS
 Monitors network traffic and reports on specified
behavior
 IDS process: capture, analysis, classification, report,
reaction
 Example: Snort, a popular open-source IDS based on
pattern-matching
Honeypot
 Computers placed in the network to ”lure” attackers
 Networks of Honeypots form ”Honeynets”
 Offer information on specific attacks and statistics
 Example project: Honeynet.org alliance
9.8.2005
Alerting issues







7
Alert response processes
Push/Pull ideology
False positives/negatives
Alerting approaches
 Log file vs. database monitoring
Information sources
 Snort alerts, gateway syslog/iptables logs, upstream
end-user data, remote Honeynets
Alerting tools
 Snort tools; reporting, configuration, ”alerting”
 Log-monitoring applications
Alerting methods
 Log, email, SMS, etc
9.8.2005
Automatic Isolation Function



8
Reasoning
 Prevents further attacks from the compromised
computer against 3rd parties
 Prevent the attacker from erasing any attack methods
and details from the computer
 Prevent undesired actions inside the Honeynet
Conditions for isolation
 Trend increase in the number of attacks/packets
 Specific, defined attack behavior
Possible points of isolation
 Gateway
 Host
9.8.2005
Reference Honeynet Setup
9
9.8.2005
Evaluation results
Configurability
Response time
Maintenance
Performance
Sensitivity
Price
Total Score
Scoring Weight
1,0
0,9
0,7
0,3
0,6
0,6
0,5
-
Aanval
3
2
3
3
3
3
2
12,4
BASE
1
1
1
3
3
2
3
8,0
Logsurfer
3
2
3
2
3
3
3
12,6
MIDAS
2
2
3
2
2
3
3
11,0
Pig Sentry
2
2
3
2
3
1
3
10,4
SAM
2
1
2
2
1
2
3
8,2
Sguil
2
1
2
2
2
1
3
8,2
SEC
2
3
3
3
3
3
3
12,8
10
and stability
Features
Product
9.8.2005
Selected tool: Simple Event
Correlator (SEC)





11
Selected because of flexibility in configuration,
features suit our needs well, lack of GUI is the only
downside.
SEC is a perl program for log-monitoring, run from
the shell
Flexible rule structure based on regular expressions
Complemented with PigSentry for new alert and
trend increase monitoring
Output can be piped also to log, email and SMS
9.8.2005
Prototyping


At the moment, SEC and PigSentry have been
running in the reference setup for a couple of
weeks, monitoring Snort and Pigsentry logs
Alerts on:





12
Snort high priority alerts
New alerts and trend increases (Pigsentry)
Especially trend increases are useful
Special alert conditions can also be added
Looks like alerting requires thresholding in all cases,
in case of a compromise, alerts quickly escalate and
create lots of alerts
9.8.2005
Results & Conclusions (so far)





13
The selected method works for alerting purposes and
is pretty flexible for using all kind of data and different
output methods
Definition of the monitoring processes and the
conditions for triggering alert conditions are
problematic
External alerting features are useful in the Honeynet
setup, but the tuning of the alerting rules is important
Isolation function depends also on the definition of thr
triggering conditions, needs more investigation.
More information on the Honeynet events is needed to
better configure the set of rules  test period ongoing
9.8.2005
Questions ?
14
9.8.2005