IDS DEPLOYMENT
1
CHARACTERISTICS OF A GOOD
INTRUSION DETECTION SYSTEM
1.
2.
3.
4.
5.
6.
7.
8.
It must run continually without human supervision. The system
must be reliable enough to allow it to run in the background of the
system being observed. However, it should not be a "black box".
That is, its internal workings should be examinable from outside.
It must be fault tolerant in the sense that it must survive a
system crash and not have its knowledge-base rebuilt at restart.
On a similar note to above, it must resist subversion. The system
can monitor itself to ensure that it has not been subverted.
It must impose minimal overhead on the system. A system that
slows a computer to a crawl will simply not be used.
It must observe deviations from normal behavior.
It must be easily tailored to the system in question. Every system
has a different usage pattern, and the defense mechanism should
adapt easily to these patterns.
It must cope with changing system behavior over time as new
applications are being added. The system profile will change over
time, and the IDS must be able to adapt.
Finally, it must be difficult to fool.
2
DETECTION METHODS

Attack signatures


E.g. virus/malware
Anomaly detection

Look for things that is out of the ordinary
Stateful protocol analysis
 Integrity checking
 Hybrid


Pros and cons
3
©2009 KRvW

Stateful protocol analysis


E.g. If a terminal A, after receiving ACK, sends out
SYN-ACK => A is running a port service, i.e. it is a
server, even though it is only a desktop/laptop. Is it
authorized? (somebody might be running a server on
my laptop!)
Integrity Checkers

Check (vital files for unauthorized change

Compare against previous snapshots
Assumptions?
 Effective strategy?

4
SIGNATURE BASED

Based on a set of signatures and rules:
Find and log suspicious activity
 Generate alerts


Intruders have signatures like computer viruses

Can be detected using software
Analyst must find data packets that contain any
known intrusion-related signatures or anomalies
related to Internet protocols
 Signature-based (misuse detection)

Pattern matching
 Cannot detect new attacks
 Low false positive rate

mms©
5
ANOMALY DETECTION
Depends on packet anomalies present in protocol
header parts
 In some cases these methods procure better
results compared to signature-based IDS
 Usually IDS

captures data from the network,
 applies its rules to that data or detects anomalies in
it


Snort is primarily a rule-based IDS, however,
input plug-ins are present to detect anomalies in
protocol headers
6
mms©
ANOMALY DETECTION

Anomaly-based (Statistical-based)
Activity monitoring
 Has the ability to detect new attacks
 Higher false positive rate

7
mms©
PROS AND CONS
Signature




Accurate for known
attacks
Negative validation model
Can stem outbreaks
easily?
 Analysis and response
time critical
Maintenance of signatures
Anomaly


Theoretically accurate for
novel attacks
What is “normal”?
8
©2009 KRvW
PROS AND CONS
NIDS



No load on business
processing
Eroding in effectiveness
 SSL/TLS and SSH
 If NIDS is placed in
front of SSL, then NIDS
can’t see beyond the
encryption data
Lacking business context

If NIDS can detect attacks
meant for Windows, but the
web server/computers are
running Solaris => no use
HIDS
 “Footprint” on servers
Put loads on business –
needs to be installed on
PCs
Closer to problem
Partially immune to
encryption
Subject to application
reporting




9
©2009 KRvW
IDS DEPLOYMENT

Network-based
Inspect network traffic
 Monitor user activity (packet data)


Host-based
Inspect local network activity
 OS audit functionality
 Monitor user activity (function calls)

10
mms©
IDS DEPLOYMENT ARCHITECTURES




Simple
Single tap
Tap with management net
In-line
Separation of data

Keep IDS management traffic separate
Performance
 Security




Completely separate IDS net
Network interfaces are cheap
Although this still costs more, it’s considered a best
practice
©2009 KRvW
11
IDS ARCHITECTURES – SIMPLE
Simple net and sensor
 Completely detectable
 Stand-alone

Snort
12
©2009 KRvW
IDS ARCHITECTURES – SINGLE TAP
Simple sensor with
network tap
 Single net interface
 Relatively inexpensive
 Not detectable
 Stand-alone

Snort
13
©2009 KRvW
IDS ARCHITECTURES –TAP WITH MGMT

Dedicated
management network
Snort administration
 Monitoring
 Maintenance
Management

Separates security
traffic
 Optimizes
performance
Snort

Production
14
©2009 KRvW
IDS ARCHITECTURES –IN-LINE
Management
In-line deployment
 Similar to a firewall
layout


Generally deployed
behind firewall
Separate management
net
 Allows for IPS
functions
Production
Internal

Snort
Production External
©2009 KRvW
15
IDS DEPLOYMENT METHODOLOGY
16
www.loud-fat-bloke.co.uk
IDS DEPLOYMENT METHODOLOGY
17
www.loud-fat-bloke.co.uk
IDS DEPLOYMENT METHODOLOGY
18
www.loud-fat-bloke.co.uk
SELECTION
19
www.loud-fat-bloke.co.uk
SELECTION
20
www.loud-fat-bloke.co.uk
DEPLOYMENT
21
www.loud-fat-bloke.co.uk
DEPLOYMENT
22
www.loud-fat-bloke.co.uk
DEPLOYMENT
23
www.loud-fat-bloke.co.uk
STEP 1: PLANNING SENSOR POSITION AND
ASSIGNING POSITIONAL RISK
24
www.loud-fat-bloke.co.uk
IDS SENSORS
IN A TYPICAL
CORPORATE NETWORK
25
www.loud-fat-bloke.co.uk



Sensor 2 – this is the ideal position for a sensor.
The network segment it is on contains servers that
require protection (reason 1). However, the DMZ is
traditionally considered as an intermediate
stepping-stone to the main network –
correspondingly, a sensor could be justly positioned
for pre-emptive reasons (reason 2).
Sensor 3 – is justified by reason 1 entirely.
Sensor 1 – is justified by reason 2 and probably
provides no more security functionality than the
firewall logging and alerting functions already
provide.
www.loud-fat-bloke.co.uk
26
27
www.loud-fat-bloke.co.uk
STEP 2: ESTABLISH MONITORING POLICY
AND ATTACK GRAVITY
28
www.loud-fat-bloke.co.uk

This process is expanded below:
29
www.loud-fat-bloke.co.uk
DEPLOYMENT
30
www.loud-fat-bloke.co.uk
31
www.loud-fat-bloke.co.uk
32
www.loud-fat-bloke.co.uk
33
www.loud-fat-bloke.co.uk
STEP 3: REACTION
34
www.loud-fat-bloke.co.uk
35
www.loud-fat-bloke.co.uk
HOST DETECTORS
36
www.loud-fat-bloke.co.uk
APPLICATION INTERFACE
37
www.loud-fat-bloke.co.uk
INFORMATION MANAGEMENT

This stage is usually very short but is often
forgotten. It deals with:
Where is the info delivered
 What form the info is
 What time frame it is delivered in
 What form it is retained in

38
www.loud-fat-bloke.co.uk
CONSOLE AND LOG MANAGEMENT
39
www.loud-fat-bloke.co.uk
40
www.loud-fat-bloke.co.uk
INCIDENT RESPONSE & CRISIS MNGMT
41
www.loud-fat-bloke.co.uk
TEST
42
www.loud-fat-bloke.co.uk
TEST
43
www.loud-fat-bloke.co.uk
HIDS DEPLOYMENT
44
NIDS DEPLOYMENT
45
EXERCISES:

Discuss the pros and cons of the followings:

Signature vs. anomaly detection
Signature-based
detection
Anomaly-based
detection
Pros
Cons

NIDS vs. HIDS
NIDS
HIDS
Pros
Cons
46
DISCUSS:

Explain the table below (using
the diagram given), i.e. the
meaning of each gravity level
(L,M,H) for each sensor, and
each network event.
47
EXERCISE:

Based on network diagram given, where should the IDS sensors be
located? Explain briefly the reasons on the placement of these sensors.
Internet
Internet Router
Externally accessible hosts –
servers (web, email, external
DNS, web proxy and so on.
Firewall
`
48
Internal Network -servers,
workstations and so on.