1. IDS D EPLOYMENT 1

2. C HARACTERISTICS OF A G OOD I NTRUSION D ETECTION S YSTEM 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

3. D ETECTION M ETHODS 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 3

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

5. S IGNATURE B ASED 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 5 mms©

6. A NOMALY D ETECTION 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©

7. A NOMALY DETECTION Anomaly-based (Statistical-based) Activity monitoring Has the ability to detect new attacks Higher false positive rate 7 mms©

8. P ROS AND C ONS 8 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. P ROS AND C ONS 9 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 D EPLOYMENT 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©

11. IDS D EPLOYMENT A RCHITECTURES 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

12. IDS A RCHITECTURES – S IMPLE 12 Simple net and sensor Completely detectable Stand-alone ©2009 KRvW Snort

13. IDS A RCHITECTURES – S INGLE T AP 13 Simple sensor with network tap Single net interface Relatively inexpensive Not detectable Stand-alone ©2009 KRvW Snort

14. IDS A RCHITECTURES –T AP WITH M GMT 14 Dedicated management network Snort administration Monitoring Maintenance Separates security traffic Optimizes performance Management ©2009 KRvW Snort Production

15. IDS A RCHITECTURES –I N -L INE 15 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 D EPLOYMENT M ETHODOLOGY 16 www.loud-fat-bloke.co.uk

17. IDS D EPLOYMENT M ETHODOLOGY 17 www.loud-fat-bloke.co.uk

18. IDS D EPLOYMENT M ETHODOLOGY 18 www.loud-fat-bloke.co.uk

19. S ELECTION 19 www.loud-fat-bloke.co.uk

20. S ELECTION 20 www.loud-fat-bloke.co.uk

21. D EPLOYMENT 21 www.loud-fat-bloke.co.uk

22. D EPLOYMENT 22 www.loud-fat-bloke.co.uk

23. D EPLOYMENT 23 www.loud-fat-bloke.co.uk

24. S TEP 1: P LANNING SENSOR POSITION AND ASSIGNING POSITIONAL RISK 24 www.loud-fat-bloke.co.uk

25. IDS S ENSORS IN A T YPICAL C ORPORATE N ETWORK 25 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. 26 www.loud-fat-bloke.co.uk

27. 27 www.loud-fat-bloke.co.uk

28. S TEP 2: E STABLISH MONITORING POLICY AND ATTACK GRAVITY 28 www.loud-fat-bloke.co.uk

29. This process is expanded below: 29 www.loud-fat-bloke.co.uk

30. D EPLOYMENT 30 www.loud-fat-bloke.co.uk

31. 31 www.loud-fat-bloke.co.uk

32. 32 www.loud-fat-bloke.co.uk

33. 33 www.loud-fat-bloke.co.uk

34. S TEP 3: R EACTION 34 www.loud-fat-bloke.co.uk

35. 35 www.loud-fat-bloke.co.uk

36. H OST DETECTORS 36 www.loud-fat-bloke.co.uk

37. A PPLICATION I NTERFACE 37 www.loud-fat-bloke.co.uk

38. I NFORMATION M ANAGEMENT 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

39. C ONSOLE AND L OG M ANAGEMENT 39 www.loud-fat-bloke.co.uk

40. 40 www.loud-fat-bloke.co.uk

41. I NCIDENT R ESPONSE & C RISIS M NGMT 41 www.loud-fat-bloke.co.uk

42. T EST 42 www.loud-fat-bloke.co.uk

43. T EST 43 www.loud-fat-bloke.co.uk

44. HIDS D EPLOYMENT 44

45. NIDS D EPLOYMENT 45

46. E XERCISES : Discuss the pros and cons of the followings: Signature vs. anomaly detection NIDS vs. HIDS 46 Signature-based detection Anomaly-based detection Pros Cons NIDSHIDS Pros Cons

47. D ISCUSS : 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

48. E XERCISE : Based on network diagram given, where should the IDS sensors be located? Explain briefly the reasons on the placement of these sensors. 48