Motivation for IDS Developing absolutely secure systems is - PDF document

Motivation for IDS � Developing absolutely secure systems is Intrusion Detection (IDS) not possible � Most existing systems have security flaws � Abuses by privileged insiders are possible Simone Fischer-Hübner � Not all kinds of intrusions are known � Quick detection of intrusions can help to identify intruders and limit damage � IDS serves as a deterrent Intrusion Detection (IDS) – Basic concepts Sensors - Network based IDS IDS: Software and/or hardware systems monitoring a system, � Capturing and analysing network packets analysing it for signs of security intrusions and eventually triggering response � Placed at various points in a network � Behind the external firewall (Location 1) Intrusion Detecion � Outside the external (Analysis) Audit Data Response firewall (Location 2) Network (Alarm/Actions) packets Misuse Anomaly � On major network Detection Detection backbones (Location 3) Monitoring via sensors (located on the hosts or on the � On critical subnets network) (Location 4) Misuse Statistical Siganture Profiles Database Sensors – Distributed Intrusion Detecion Host based IDS – Architecture Example (centralised) � Information is collected within an individual computer or application � Installed on critical hosts � Audit data are collected on OS level (system logs) and/or application level 1

Distributed Intrusion Detection – Anomaly Detection Issues � A distributed intrusion detection system may � Based on the hypothesis that intrusions can be detected by monitoring a system for abnormal patterns of system need to deal with different audit record usage formats � I DES (Intrusion Detection Expert System) developed by � One or more nodes in the network will serve D.Denning at SRI/International in 1986 as collection and analysis points for the data, which must be securely transmitted to them � Usually rule-based pattern matching system which � Architecture can be: includes � centralized (single point of analysis, easier but � Statistical profiles for representing the behavior of subjects with respect to objects bottleneck) or � Rules matching new audit records against profiles, acquire/update � decentralized (multiple centers that must be profiles, detect anonalous behavior coordinated) Examples for anomalies for IDES Anomaly Detection – intrusions: Audit Records � Attempted break-ins: Generated by the target system, translated into standard format, transmitted to abnormally high rate of password failure the IDES system for analysis � � Masquerading, successful break-ins Audit record structure: different login time, location or connection type, � ( subject, action, object, exception-condition, resource-usage, time-stamp ) different accesses to data, execution of programs � � Penetration by legitimate users: Decomposition of activities involving multiple objects to single-object actions: login at unusual times, e.g.: COPY GAME.EXE to <LIBRARY>GAME.EXE issued by Smith is aborted, � route data to remote printers not normally used, because he does not have write-permission to <LIBRARY> � execution of different programs, more protection violations, � access to commands/files not normally permitted to him/her Audit Records: � � Viruses: (Smith, execute, <Library>COPY.EXE, 0, CPU=0002, 1105821678) (Smith, read, <Smith>GAME.EXE, 0, RECORDS=0, 1105821679) infected program needs more memory, disk space, CPU-time, I/O- � activities, (Smith, write, <Library>GAME.EXE, write-viol, Records=0, 1105821679) it modifies other executable code not normally done by it, � increase in the frequency of executable files rewritten in the infected � system IDES Anomaly Detecion – IDES Anomaly Detection – Statistical Profiles (II) Statistical Profiles (I) Statistical Model: � Profiles characterize the behaviour of a subject with respect to an object in Given a metric for a random variable x and n observations x 1 ,...,x n . � � terms of a statistical metric and model The statistical model shall determine whether a new observation x n+1 is � abnormal with respect to the previous observations. Metric: � Random variable x representing a quantitative measure accumulated over � Operational Model: � a period (period: fixed or time between 2 events) Abnormality is detected by comparing a new observation of x against fixed � limits, e.g. limitation of number of password failures during a short period. Examples of types of metrics: Event counter: � Mean and Standard Deviation Model: � x is the number of audit records satisfying some property occurring during a period, � A new observation of x is defined to be abnormal, if it falls outside a e.g. number of logins during one hour, number of execution failures during one � confidence interval: session mean + d * stdev (the probability of a value falling outside this interval I nterval timer: � is at most 1/d2). x is the length of time between two related events, e.g. time length between � successive logins into one account sum = x 1 + x 2 + ....+ x n 2 +....+ x n Resource measure: � sumsquares = x 1 2 x is the quantity of resources consumed by some action during a period, e.g. � mean = sum / n number of pages printed per day stdev = √ ¯ (sumsquares / (n-1) - mean 2 ) 2

Anomaly Detection – IDES Example Profile Examples of Metric/Model Combinations in Structure Profiles Login Frequency (event counter, mean/ standard deviation model) Profile structure: (name, Location Frequency (event counter, mean/ standard deviation model) subject-pattern, Session Output (resource measure, mean/ standard deviation model) action-pattern, object-pattern, Password Fails (event counter, operational model) exception-pattern, resource-usage-pattern, Execution Frequency (event counter, mean/standard deviation model) period, metric, Execution Denied (event counter, operational model) statistical-model, Read-, Write,- Delete-Frequency (event counter, mean/standard value, deviation model) threshold) Read-, Write, Delete-Fails (event counter, operational model) Example of patterns: File Resource Exhaustion (event counter, operational model) Subject patterns: ´Smith´, * → user Object patterns: ´<Library>*´ , IN(GAME.EXE,EDITOR.EXE) IDES Anomaly Detection – Anomaly Detection – Pattern Matching Rules Pros & Cons + + - - Rule-Structure: Condition --> Action-Body � Requires sophisticated Audit Record Rules: � Can detected an attack Condition: A new audit record matches a profile mathematical analysis without previous which is time intensive Body: update of the profile, checking for anomalous behaviour, knowledge about it (generation of an anomaly record, if an abnormality is � Produces a large number detected) � Can deliver the base for of false alarms signature generation � Requires extensive Periodic Activity Update Rules: training sets for the Condition: The system clock implies a period of length p system completes, the period component of a profile is p Body: update of the matching profile, � Vulnerable to attacks checking for anomalous behavior, based on slow change of (generation of an anomaly record, if a behavior abnormality is detected) � Affects privacy of users Misuse Detection- Example: Buffer overflow attack Analysis – Misuse detection signatures � System activities are scanned for attack signatures, � An exec system call audit records for a buffer i.e. patterns of network traffic or activities in log files overflow has the following pattern: indicating malicious behavior � The exec call concerns a setuid program, i.e. the � Examples: effective user id and the real user id fields are � patterns of bits in an IP packet indicating a buffer overflow different � certain types of TCP SYN packets indicating a SYN flooding � The argument passed to the exec call is relatively attack long, making the length of the entrire audit record � Sequence of action typical for computer viruses significantly exceed the length al almost all normal � Majority of commercial-based IDS products are based setuid exec call on misuse detection � Buffer overflow atatcks typcially produce exec audit records � SNORT is a popular open-source Network Misuse with a length > 500 bytes. Only 0.15 % of normal exec audit detection based IDS tool (www.snort.org) records are longer than 400 bytes. � The exec argument contain opcode in the range of ascii control characters 3