ids d eployment 1. c haracteristics of a g ood i ntrusion d etection s ystem 1.it must run...
Post on 19-Dec-2015
215 Views
Preview:
TRANSCRIPT
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.
top related