On Understanding Normal Protocol Behaviour to Detect the Abnormal - PowerPoint PPT Presentation

On Understanding Normal Protocol Behaviour to Detect the Abnormal P. Smith, D. Hutchison, M. Banfield, and H. Leopold Computing Department Lancaster University { p.smith, dh } @comp.lancs.ac.uk Telekom Austria AG { mark.banfield, helmut.leopold } @telekom.at

Paul Smith Prognets 2006 Workshop Resilient Networking (Resilinets) Initiative • Participants – Kansas University – James P.G. Sterbenz – Lancaster University – David Hutchison – Telekom Austria – Simula Labs • Aim to provide a usable network service in light of challenges to normal operation – unusual but legitimate traffic loads ( e.g., flash crowds) – highly mobility of nodes and sub-networks – attacks against the network hardware, software, or protocol infrastructure – . . . 1

Paul Smith Prognets 2006 Workshop Resilinets Strategy • D 2 R 3 1. Defence – Build systems that are resistant to attacks and adverse events 2. Detect – Resilient network should be context-aware and automatically detect challenging events 3. Remediate – Adapt in order to mitigate the effects of a challenging event (graceful degradation of service) 4. Recover – Autonomically self-organise and self-repair to a state of normal operation 5. Refine – Learn from past D 2 R 3 cycles and employ better strategies 2

Paul Smith Prognets 2006 Workshop Our Thesis Alone, a functional specification of a network protocol is insufficient when designing and parameterising systems that combat a range of network attacks – a non-functional specification (of normal protocol behaviour) is also necessary. 3

Paul Smith Prognets 2006 Workshop Motivation • Current intrusion detection systems – Perform protocol checking against a functional specification – Can limit protocol message rates • Protocols can exhibit abnormal behaviour because of an attack, yet still behave according to their functional specification • Advanced attackers can learn thresholds and operate below them 4

Paul Smith Prognets 2006 Workshop Case Study: Controlling Anomalous ARP Behaviour 100 80 Percentage of Requests Dropped 60 University Campus 40 Gateway Router 20 0 1e-05 1e-04 0.001 0.01 0.1 1 10 100 1000 10000 100000 Maximum Instantaneous Request Rate (requests/second) 5

✘ ✏ ✞ ✏ ☞ ✙ ✥ ✘ ✣ ✘ ✏ ✙ ✙ ✏ ✘ ✏ ✙ ✏ ✘ ✙ ✏ ✏ ✁ ✙ ✘ ✏ ✁ ✘ ✩ ✞ ✏ ✁ ✘ ✩ ✙ Paul Smith Prognets 2006 Workshop Viewpoints, Views, and Features ✚ ✮ ✍ ✖ ✌ ✍ ✎ ✑ ✍ ✒ ✦ ✍ ✖ � ✂ ✄ ☎ ✆ ✝ ✯ ✍ ✛ ✖ ✰ ✒ ✓ ✔ ✍ ✌ ★ ✓ � ✂ ✄ ✟ ✕ ✖ ✗ ✍ ✚ ✛ ✑ ✜ ✚ ✍ ✎ ✍ ✢ ✍ ✤ ✪ ✫ ✫ ✍ ✬ ✬ ✤ ✑ ✖ ✦ ✤ ✧ ✠ ✂ ✡ ☛ ✂ ✟ ✱ ✗ ✬ ✤ ✍ ✬ ✬ ✌ ✬ ✭ ✗ ✖ ✤ ✕ ★ ✍ An example set of viewpoints, views, and features for the ARP protocol 6

Paul Smith Prognets 2006 Workshop Uses for Operational Specifications • Smart stacks – End-systems perform protocol message checking – Can we determine if a protocol message is good or bad? • Intrusion detection systems – Specification could be used as input to an IDS that does normal behaviour checking – Could be based on a programmable edge router ( e.g., LARA++) 7

Paul Smith Prognets 2006 Workshop Issues • Stealth attacks – Can systems developed as we are proposing catch stealth attacks? – Higher fidelity specifications give stealth attacks less room to manoeuvre – Potential trade-off between fidelity of specification and false positives • What are the useful protocols, viewpoints, views, and features? – Potential for over specification, and where to stop specifying • What are the side effects of detecting attacks in this way? – Consequences of false positives on a mitigation system – Confidence thresholds 8

Paul Smith Prognets 2006 Workshop Conclusions • To build systems that detect advanced network attacks, a specification of normal protocol behaviour is essential • Example applications – Smart stacks – Intrusion detection systems More information: http://www.comp.lancs.ac.uk/resilinets 9