You are on page 1of 48

IDS DEPLOYMENT

1
CHARACTERISTICS OF A GOOD
INTRUSION DETECTION SYSTEM
1. 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.
2. It must be fault tolerant in the sense that it must survive a
system crash and not have its knowledge-base rebuilt at restart.
3. On a similar note to above, it must resist subversion. The system
can monitor itself to ensure that it has not been subverted.
4. It must impose minimal overhead on the system. A system that
slows a computer to a crawl will simply not be used.
5. It must observe deviations from normal behavior.
6. 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.
7. 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.
8. 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

©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
5
 Low false positive rate
mms©
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

mms©
PROS AND CONS
Signature Anomaly
 Accurate for known  Theoretically accurate for
attacks novel attacks
 Negative validation model  What is “normal”?
 Can stem outbreaks
easily?
 Analysis and response
time critical
 Maintenance of signatures

©2009 KRvW
PROS AND CONS
NIDS HIDS
 No load on business  “Footprint” on servers
processing  Put loads on business –
 Eroding in effectiveness needs to be installed on
 SSL/TLS and SSH PCs
 If NIDS is placed in  Closer to problem
front of SSL, then NIDS  Partially immune to
can’t see beyond the encryption
encryption data
 Subject to application
 Lacking business context reporting
 If NIDS can detect attacks
meant for Windows, but the
web server/computers are
running Solaris => no use
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 11

©2009 KRvW
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 Snort

 Not detectable

 Stand-alone

13

©2009 KRvW
IDS ARCHITECTURES –TAP WITH MGMT
Management
 Dedicated
management network
 Snort administration
 Monitoring Snort

 Maintenance

 Separates security
traffic
 Optimizes
Production
performance

14

©2009 KRvW
IDS ARCHITECTURES –IN-LINE
Management
 In-line deployment
 Similar to a firewall
layout
 Generally deployed Production
behind firewall Internal
 Separate management
net
 Allows for IPS Snort

functions

Production External
15

©2009 KRvW
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. 26

www.loud-fat-bloke.co.uk
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 Anomaly-based
detection 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.

You might also like