ids d eployment 1. c haracteristics of a g ood i ntrusion d etection s ystem 1.it must run...

1

IDS DEPLOYMENT

2

CHARACTERISTICS OF A GOOD INTRUSION DETECTION SYSTEM1. 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.

3

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

4

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?

5

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 ratemms©

6

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

mms©

7

ANOMALY DETECTION

Anomaly-based (Statistical-based) Activity monitoring Has the ability to detect new attacks Higher false positive rate

mms©

8

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”?

©2009 KRvW

9

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

©2009 KRvW

10

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)

mms©

11

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

12

IDS ARCHITECTURES – SIMPLE

Simple net and sensor

Completely detectable

Stand-alone

©2009 KRvW

Snort

13

IDS ARCHITECTURES – SINGLE TAP

Simple sensor with network tap

Single net interface Relatively

inexpensive Not detectable Stand-alone

©2009 KRvW

Snort

14

IDS ARCHITECTURES –TAP WITH MGMT

Dedicated management network Snort administration Monitoring Maintenance

Separates security traffic

Optimizes performance

Management

©2009 KRvW

Snort

Production

15

IDS ARCHITECTURES –IN-LINE

In-line deployment Similar to a firewall

layout Generally deployed

behind firewall Separate

management net Allows for IPS

functions

Management

©2009 KRvW

Snort

Production External

Production Internal

16

IDS DEPLOYMENT METHODOLOGY

www.loud-fat-bloke.co.uk

17

IDS DEPLOYMENT METHODOLOGY

www.loud-fat-bloke.co.uk

18

IDS DEPLOYMENT METHODOLOGY

www.loud-fat-bloke.co.uk

19

SELECTION

www.loud-fat-bloke.co.uk

20

SELECTION

www.loud-fat-bloke.co.uk

21

DEPLOYMENT

www.loud-fat-bloke.co.uk

22

DEPLOYMENT

www.loud-fat-bloke.co.uk

23

DEPLOYMENT

www.loud-fat-bloke.co.uk

24

STEP 1: PLANNING SENSOR POSITION AND ASSIGNING POSITIONAL RISK

www.loud-fat-bloke.co.uk

25

IDS SENSORS IN A TYPICAL CORPORATE NETWORK

www.loud-fat-bloke.co.uk

26

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

27

www.loud-fat-bloke.co.uk

28

STEP 2: ESTABLISH MONITORING POLICY AND ATTACK GRAVITY

www.loud-fat-bloke.co.uk

29

This process is expanded below:

www.loud-fat-bloke.co.uk

30

DEPLOYMENT

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

34

STEP 3: REACTION

www.loud-fat-bloke.co.uk

35

www.loud-fat-bloke.co.uk

36

HOST DETECTORS

www.loud-fat-bloke.co.uk

37

APPLICATION INTERFACE

www.loud-fat-bloke.co.uk

38

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

www.loud-fat-bloke.co.uk

39

CONSOLE AND LOG MANAGEMENT

www.loud-fat-bloke.co.uk

40

www.loud-fat-bloke.co.uk

41

INCIDENT RESPONSE & CRISIS MNGMT

www.loud-fat-bloke.co.uk

42

TEST

www.loud-fat-bloke.co.uk

43

TEST

www.loud-fat-bloke.co.uk

44

HIDS DEPLOYMENT

45

NIDS DEPLOYMENT

46

EXERCISES:

Discuss the pros and cons of the followings: Signature vs. anomaly detection

NIDS vs. HIDS

Signature-based detection

Anomaly-based detection

Pros

Cons

NIDS HIDS

Pros

Cons

47

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.

48

EXERCISE: Based on network diagram given, where should the IDS sensors be

located? Explain briefly the reasons on the placement of these sensors.

`

Externally accessible hosts – servers (web, email, external DNS, web proxy and so on.

Internet Router

Internet

Firewall

Internal Network -servers, workstations and so on.