1 / 65

Survey on Runtime Monitoring based on Formal Specification

Survey on Runtime Monitoring based on Formal Specification. WPE-II Presentation By Usa Sammapun Oct 28, 2005. Software Programs. Car. ATM. Heart Device. Aircraft. Safe Programs ??. Safe Programs. Verification. Security. all-leg-down !walk. leg2-up, leg3-up walk & !fall.

reid
Download Presentation

Survey on Runtime Monitoring based on Formal Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Survey on Runtime Monitoringbased on Formal Specification WPE-II Presentation By Usa Sammapun Oct 28, 2005

  2. Software Programs Car ATM Heart Device Aircraft

  3. Safe Programs ??

  4. Safe Programs Verification Security

  5. all-leg-down !walk leg2-up, leg3-up walk & !fall leg1-up, leg4-up walk & !fall leg1-up, leg2-up walk & fall Program Development Model walk and not fall Requirement class AIBO { Leg leg1,leg2,leg3,leg4; main() { leg1 = new Leg(1); leg2 = new Leg(2); leg3 = new Leg(3); leg4 = new Leg(4); } } class Leg { void walk() { } void stop() { } } Implementation

  6. Program Safety Techniques Goal: Ensuring that implementation satisfies requirement Model Model Checking Model Carrying Code Requirement Model Carrying Code Runtime Monitoring Implementation

  7. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Discussion • Conclusion

  8. leg1 leg2 leg3 leg4 Programs Instrumentation Runtime Monitoring Formal Specification class AIBO { Leg leg1,leg2,leg3,leg4; main() { leg1 = new Leg(1); send(checker,leg1); leg2 = new Leg(2); send(checker,leg2); leg3 = new Leg(3); send(checker,leg3); leg4 = new Leg(4); send(checker,leg4); } } class Leg { void walk() { send(checker,walk); } void stop() { send(checker,stop); } } Monitor Satisfied Trace Extraction Not Satisfied Feedback

  9. Runtime Monitoring • Formal specification language • Based on Mathematics • Logics, Automata, Calculi • Instrumentation • Manual & Automatic • Bytecode & Sourcecode • Specification Evaluation Process • Transform spec language into a checking automaton • Takes a trace as an input • Returns result: Satisfied, Not Satisfied • Direct algorithm • Takes both spec language and a trace as inputs • Returns result: Satisfied, Not Satisfied • Feedback • Optional • Fixed or user-defined

  10. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

  11. Temporal Assertions using AspectJ (SB’05) • Specification Language: LTL • Spec Evaluation Process: Alternating Automata • Instrumentation: • Automatic: AspectJ • Bytecode • Feedback: AspectJ

  12. SB’05 Language • LTL – Linear Temporal Logic • Reason about time-dependent truth value • Classical: 1 < 2 • Temporal: it’s raining • Syntax • f :: = p | ¬ f | f1∧f2 | f1 νf2 | ○f | ◊f | □f | f1Uf2 | f1Rf2 Proposition Next Eventually Always Until Release

  13. f2 f f2 f1 f f f2 f2 f1 f2 f2 f1 f f2 f f2 f1 f2 f2 f f f1 f f2 LTL ○f -- Next ◊f -- Eventually  fν○(◊f) □f – Always (Global)  f∧○(□f) f1U f2 -- Until  f2ν(f1∧○(f1Uf2)) f1R f2 -- Release  f2∧(f1ν○(f1Rf2))

  14. true f f f true f true f f true f f false f f f LTL • ◊f = true Uf • □f = false Rf • Concise Syntax • f :: = p | ¬ f | f1∧f2 | f1 νf2 | Xf | f1Uf2 | f1Rf2

  15. SB’05 Spec Evaluating Process • Translate LTL formulae to Alternating Automata • Use Alternating Automata to check a trace • Alternating Finite Automata (AFA) • Generalization of Non-deterministic Finite Automata (NFA) • NFA – existential automaton • -automaton • A combination of both

  16. AFA s5 s5 • On input a : T(s1, a) = {s2, s5, s8, s9} • NFA: Accept • - automata: Reject • AFA: Depends e s6 s2 s2 a e s7 s1 s1 s3 s3 a e s8 s8 e s4 s4 a s9 s9 s10 • AFA = (S, S, s0, T, F) • The only difference from NFA is the transition function • TNFA(s1, a) = {s2, s5, s8, s9} = s2 νs5ν s8 νs9 • TAFA(s1,a) = (s2 νs5) ∧ (s8 νs9) • Choose to go to {s5, s9}, then accept • TAFA(s1,a) = s2 ∧ (s5ν s8 νs9) • Reject, no matter what you choose

  17. AFA • Formally, AFA = (S, S, s0, T, F) • T: S x S B+(S) • B+(S) is a set of positive Boolean formulae over S • Positive Boolean Formulae: Boolean formulae built from elements in S using ∧ and ν • We say a set S’ satisfies a positive Boolean formula f in B+(S) if the truth assignment assigns true to S’ and false to S-S’ • For example, • the set S’ = {s5, s9} satisfies the formula f = (s2 ν s5) ∧ (s8 ν s9) • the set S’ = {s2, s5} does not satisfy f

  18. AFA • A runr’ of NFA is linear because you only choose one path • A runr of AFA is a tree • For disjunction, you choose one path • For conjunction, you have to take all paths • A runr of AFA on a finite word w = a1, a2, …, an is a finite tree such that • if s is a node in the tree r and T(s, ai) = f, where f is positive Boolean formula • then s has k children for some k ≤ |S|, and {s1, s2, …, sk} satisfies f • Transition therefore determines what are possible next states • TAFA(s1,a) = (s2 νs5) ∧ (s8 νs9) • Possible states are {s2,s8}, {s2, s9}, {s5,s8}, {s5,s9} • E.g., you can’t go to state {s2,s5} • AFA accepts a run r if all leaves of a run r are final states s1 s5 s9

  19. Translation: LTL  AFA • Translating an LTL formula fto an AFA Af • Af accepts, then f satisfies • Af rejects, then f doesn’t satisfy • Af= (S, S, s0, T, F) • S = a set of propositions in f • S = all sub-formulae of fand true, false • s0 = original formula f • F = all formulae in S of the form (f1R f2) and true • T  next slide

  20. Translation: LTL  AFA • States: Formulae, sub-formulae, true, false • Transition: T(state, input) = state • T(p, Prop) = true if p Prop • T(p, Prop) = false if p Prop • T(¬p, Prop) = true if p Prop • T(¬p, Prop) = false if p Prop • T(true, Prop) = true • T(false, Prop) = false • T(f1νf2, Prop) = T(f1 ,Prop) ν T(f2 ,Prop) • T(f1∧f2, Prop) = T(f1 ,Prop) ∧ T(f2 ,Prop) • T(Xf, Prop) = f • T(f1Uf2, Prop) = T(f2, Prop) ν(T(f1, Prop) ∧ (f1Uf2)) • T(f1Rf2, Prop) = T(f2, Prop) ∧(T(f1, Prop) ν(f1Rf2))

  21. SB’05 Evaluation Summary • Given an LTL formula and an execution trace (set of propositions) • LTL f is translated into AFA Af • Af checks an execution trace • At anytime, if transit to the state • true, satisfied • false, falsified • At the end of the trace, • If at final state, satisfied • Otherwise, falsified

  22. Head Leg void look() void move() void stop() void kick() void move() void stop() SB’05 Instrumentation / Feedback: AspectJ • At move and stop, create a log file or calculate safe location • AspectJ helps you modularize by writing once: specify • Where to do operations • What kind of operations • Pointcut  Advice Aspect

  23. requiresInit() shall not be called unless init() has been called prior (!call(requiresInit())) U (call(init()) AspectJ • LTL formulae are transformed into an aspect • Pointcut as propositions • Advice: AFA takes transitions and checks a trace

  24. AspectJ aspect InitPolicy { pointcut p1(): call(requiresInit()); pointcut p2(): call(init()); int p1 = 1; int p2 = 2; Formula state = Until( Not(p1), p2); Set<int> currentPropositions = new Set<int>(); after(): p1() { currentPropositions.add(p1); } after(): p2() { currentPropositions.add(p2); } after(): p1() || p2() { state = state.AFAtransition(currentPropositions); if (state.equals(Formula.True)) { // report the formula as satisfied } else if (state.equals(Formula.False)) { // report the formula as falsified } currentPropositions.clear(); // reset proposition vector } } pointcut declaration advice

  25. Overall Architecture – Instrumentation Specification p1 U p2... Compiler AspectJ aspect F1 {... AFAtransition Weaving Instrumented Java bytecode if(!p1) notify{... CodeGen

  26. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

  27. EAGLE • Specification Language: Eagle • Specification Evaluation: Direct algorithm • Instrumentation: - • Feedback: - • Motivated by the need for small, general, but powerful framework for specifying languages for runtime monitoring • Eagle can be used to specify LTL, Metric Temporal Logic (MTL), Regular expression, limited form of Context Free language

  28. Eagle Language • Illustrated by an example LTL Next ○ is built-in syntax maxAlways(Form F) = F ∧○Always(F) minEventually(Form F) = F ν○Eventually(F) minUntil(Form F1, Form F2) = F2ν (F1 ∧○Until(F1, F2)) monM1 = Always(x > 0 Eventually(y > 0)) Evaluate to true at the end of the trace Rules Evaluate to false at the end of the trace Properties

  29. Syntax • R :: = {max | min} N(T1 x1, …, Tn xn) = F • F :: = expression | true | false | ¬F | F1∧F2 | F1ν F2 | F1 F2 | ○F | N(F1, …, Fn) | xi • M ::= mon N = F • S ::= R* M*

  30. Metric Temporal Logic (MTL) • Temporal logic parameterized by some clock(s) • Ex. ◊[t1,t2]f • Means that f must hold true sometime when a clock value is between t1 and t2 • Eagle Rule minEventAbs(Form F, float t1, float t2) = (F ∧ t1 ≤ clock ∧ clock ≤ t2) ν ((clock < t1 ν( ¬F ∧clock ≤ t2)) ∧○EventAbs(F,t1,t2))

  31. Eagle Spec Evaluation Process • At every state, the runtime monitor evaluates formulae, and generates a new set of formulae to hold in the next state • By using eval function • eval: F x state  F • Its result is a new set of formulae to hold in the next state • eval(true, s) = true • eval(false, s) = false • eval(exp, s) = value of exp in s • eval(¬F, s) = ¬eval(F, s) • eval(F1op F2, s) = eval(F1, s) op eval(F2, s) where op is ∧ ,ν ,  • eval(○F, s) = F • eval(N(F,P), s) = eval(B[f  F, p  P], s) if {max | min} N(Form f,T p) = B

  32. Eagle Evaluation Summary • A list of monitored properties • At any time during the trace • The runtime monitor evaluate formulae, and generate a new set of formulae to hold in the next state • If any formula is evaluated to true, that formula is removed from the monitoring list • If any monitor is evaluated to false, a violation is issued • Remaining formulae will be checked at the next state • At the end of the trace • Remaining max rule  evaluate to true • Remaining min rule  evaluate to false

  33. Eagle Instrumentation/Feedback • No instrumentation & Feedback • Need a third-party program to supply an execution trace

  34. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

  35. Edit Automata • A slightly different goal, but similar technique • Goal: run untrusted code without harming our machine • Specification Language & Spec Evaluating Process: • Security Policies is defined in terms of Edit Automata • Edit Automata is a monitor running in parallel with the untrusted program • It monitors the untrusted program and enforces security policies • Instrumentation: • Manual, sourcecode • Feedback: • Feedback (enforcement) is integrated into the language

  36. Enforcing Policy in Edit Automata • List of monitored actions or operations • Specify what to do when an application is about to invoke a monitored action • When it recognizes a dangerous action, it may • halt the application • suppress (skip) the operation but allow the application to continue • insert (perform) some computation on behalf of the application

  37. Edit Automata app’s requested action executed action: allowed, inserted

  38. Example: Atomicity • Program: Apple Market-Client • Policy: Atomicity Apple Market

  39. 3 Works on Edit Automata • Edit automaton is a high-level concept for evaluating process with feedback • Analogous to Alternating Automata in SB’05 • Policy Calculus is a language based on the edit automaton concept • Analogous to LTL in SB’05, ex. ¬p1Up2 • Polymer is a prototype language based on Policy Calculus for monitoring Java programs • Analogous to Until( Not(p1), p2);

  40. Policy Calculus • Policy: Memory quota fun mpol(quota:int). { actions: malloc(); policy: next  case * of malloc(n)  if (quota > n) then ok; run (mpol (quota-n)) else halt end } List of actions Policy

  41. Polymer • Policy: Limit # of opened files and its path policy limitWriter(int maxopen) = actions = { java.io.FileWriter(String path); java.io.FileWriter.close(); } state = { int cur = 0; } policy = { aswitch { case java.io.FileWriter(String path) : if (cur >= maxopen) suppress; if (path.startsWith(``\tmp'')) { cur++; ok; } else { emit(System.err.println(``Can't open.'')); suppress; } case java.io.FileWriter.close() : cur--; } } List of actions Variables Policy

  42. Polymer Instrumentation • Method Warpper • All calls (actions) to monitored methods are redirected to the runtime monitor • The runtime monitor then evaluates the action • If ok, the original method call is made and returned • If suppress, it throws a SuppressionException • Program must handle the exception • If insert, it executes inserted operation • If halt, it terminates the program

  43. Outline • Overview of runtime monitoring • Runtime Verification • Temporal Assertions using AspectJ [Stolz,Bodden05] • Eagle [Barringer et al. 04] • Security • Edit Automata [Bauer et al. 03] • Eagle for Intrusion Detection [Naldurg et al. 2004] • Comparison and Analysis • Conclusion

  44. Intrusion Detection using EAGLE • Intrusion Detection • Anomaly-based • Define normal behaviors • Any behavior deviates from normal behaviors is an intrusion • Signature-based • Define patterns of bad behaviors or attacks • Anything fits the patterns is an intrusion • Naldurg et al. use Eagle • Signature-based Intrusion Detection • Use Eagle to specify attack patterns

  45. DoS Attack • Create DoS attack by sending a forged “ping” message with a victim’s IP address as a sender to a broadcast IP address • Large number of response can cause DoS • Eagle • maxAttack() = (type = “ping”) ∧ isBroadcast(ip) • monDoSSafety = Always(¬ Attack())

  46. Summary

  47. Language • Expressiveness • SB’05 LTL Eagle • Edit Automata DFA Eagle • Abstraction Level • Implementation: SB’05 (pointcut), Edit Automata (Java method call) • Specific particular programming language • Design: Eagle (variable) • General and for any programming language

  48. Spec Evaluation Process • Execution time depends on specification language • More expressive, higher complexity • For each input, for a formula f of size m (m subformulae) • Edit Automata: O(m) • DFA • SB05: ≈ O(2m) • Number of states in the AFA Af is O( m ) • SB05 translates AFA (which is essentially NFA) into DFA • Translating NFA into DFA exponentially blows up the number of DFA states • Eagle: • LTL: ≈ O(2m) • Transforming an LTL f to another LTL f’ to hold in the next state • At most 2m possibilities to combine m subformulae in a conjunction or disjunction for f’ • General: (with data-values) depends on both • the size of the formula.. At least W(2m) • the length of the trace

  49. Why Checking LTL is ≈ O(2m) • Checking Past-LTL is O(m) • Look at history • Can say satisfied, or not satisfied • Deterministic • Checking Future-LTL is ≈ O(2m) • Waiting for future trace • Cannot say now whether satisfied, or not satisfied • Need to keep track of what we have seen and what we are waiting for • Non-deterministic

  50. Why Eagle general checking time depends on length of trace • Ex. “whenever at some point x > 0, then eventually y = x". • Eagle: • minR(int k) = Eventually(y = k) • monM = Always (x > 0 R(x)) • After x becomes > 0 and keeps changing its value, e.g., • s0 = {x = 0, y = 0} • s1 = {x = 1, y = 0} • s2 = {x = 2, y = 0} • s3 = {x = 3, y = 0} • s4 = {x = 4, y = 0} • s5 = {x = 5, y = 0} • s6 = {x = 6, y = 2} • At s6, the result of the eval function (what need to hold next state) becomes • Eventually(y=1) /\ Eventually(y=3) /\ Eventually(y=4) /\ Eventually(y=5) /\ Eventually(y=6) /\ Always(x>0 R(x))

More Related