1. Success status, page 1 Collaborative learning for security and repair in application communities MIT & Determina AC PI meeting July 10, 2007 Milestones and measures of success

2. Success status, page 2 Milestones – Oct 2006 Learning for Windows executables Port Daikon to work on executables rather than source code New infrastructure Requires debug information in the executable Utilizes debug information to determine variables and their names

3. Success status, page 3 Milestones – Jan 2007 Distributed learning Partition learning throughout the community Communicate learning results to central location Much smaller than raw trace data Does not require storing trace data Centrally combine learning results Identical results to learning over all data in one big run Each client still learns over whole program (or same parts of it)

4. Success status, page 4 Milestones – Apr 2007 Learning on stripped Windows executables No need for debug information New notion of values to learn over: “binary variables” Expressions that are used in the binary (the executable) Solves many problems with lack of debug information Since they are used, they are guaranteed to be meaningful No need to track initialization No need to track array lengths No need for other tricks to prevent core dump or behavior change Yields variables at every point of program execution Includes within loops, etc. Not just procedure entry and exit Reduces false positives Compare only the variables that are used Slightly less expressive Fewer comparisons Mitigate by using values from previous basic blocks

5. Success status, page 5 Milestones – Apr 2007 Manual implementation of the repair algorithm Testing on a real program to illustrate capabilities All phases exist, but not all automted

6. Success status, page 6 Milestones – Jul 2007 Automation of learning and protection process Learning (infers invariants) Same status as in previous milestones Monitoring (detects attacks) Integration of first detector: Memory Firewall Detector Deployment of monitoring and of repairs Uses Determina Management Console Localization (determines which invariants are violated) Logs results of evaluating previously learned invariants Results collected by central management console Protection (repairs violated properties) Distribute and evaluate multiple repairs Not yet implemented for all learned invariants Currently limited to a selected part of the program Improves performance

7. Success status, page 7 Milestones – Oct 2007 Learning over entire program Scale up infrastructure Different community members learn about different parts of program Enrich variables over which learning occurs Support invariants over variables on the call stack Additional repairs Support new types of invariants Add new repairs for existing invariants

8. Success status, page 8 Milestones – Nov 2007 Red Team exercise

9. Success status, page 9 Milestones – Apr 2008 Add new detector: Crash detector (Previous detector: Determina Memory Firewall) Problem: many applications are written expecting to crash Application catches the crash and restarts part of itself We must distinguish between “expected” and “unexpected” crashes

10. Success status, page 10 Milestones – Jul 2008 Add new detector: data structure consistency checker (Previous detectors: Memory Firewall, crashes) Flags violation of learned properties as a potential attack Problems: Higher false positive rate –Due to incomplete learning: not enough executions to learn over Difficult to know whether repairs make things better –Due to incomplete learning: unlearned properties Experimentally evaluate whether this works

11. Success status, page 11 Milestones – Oct 2008 Support Microsoft executables Highly optimized Code for one function scattered around program Uses unexpected instructions and code conventions Parts are coded in assembly to optimize speed/space Without source code, debugging our system is difficult

12. Success status, page 12 Milestones – Dec 2008 Productize Determina offers additional product to DoD and other customers Seamlessly integrated with suite of security and reliability offerings Improves availability of large installations Detects and mitigates attacks before a human has had time to do so Buys time for human intervention (or eliminates it)

13. Success status, page 13 Phase 1 measures of success Automated learning and repair Effective against attacks Low overhead

14. Success status, page 14 Automated learning and repair Instrument community Learn over different parts of the program Combine results Detect attacks Disribute fixes Evaluate fixes Distribute best fixes Works on stripped Windows executables We suggest an open source program for evaluation Eases task of the Red Team Eases our development effort No source code is used duing the evaluation

15. Success status, page 15 Effective detection and repair Detect 95% of code injection attacks These inject external code into the application and execute it Not: downloading bad executable, Word file, etc. Not: application errors (e.g., function return wrong value) Recover from 60% of these attacks After learning from a number of attacks Number of attacks (and amount of learning) depends on confidence required

16. Success status, page 16 Low overhead Protection mode overhead of less than 200% Not noticeable for I/O-bound programs Use extra CPUs on chip Better performance in Phase 2 Determina infrastructure adds about 5% overhead Measure overhead in steady state Startup instrumentation costs are higher Learning must take place over several months We will develop an automated system for simulating user actions to facilitate learning

17. Success status, page 17 Phase 2 measures of success Support additional attack detectors Crash detector Data structure consistency checker Detect 50% of attacks and errors that damage the information representation of the program Recover from 30% of the detected attacks Overhead during monitoring and learning of less than 150% (steady-state) System works on a reasonable subset of the standard Microsoft programs (including Office and Windows)

18. Success status, page 18 Measures of success Code injection attacks only (insert code into application & execute it) Downloading bad executable, Word file, etc. is not code injection One program (we Firefox only, one version (we will choose version 1.0 or something similar), no plugins 20 occurences of each unique attacks (identical), to achieve repair Learning phase takes place in advance of red team Only input that is batch oriented (html, jpeg, gif etc), no forms, no user interactions of any sort (so we can automate learning). HTML files can include javascript code. Doesn't cover downloading bad executable, word file, etc. (these aren't really code injection attacks)