1. 1Maita Final, Dec. 5, 2002 -- **Not for distribution** Adaptive Knowledge-Based Monitoring for Information Assurance Peter Szolovits (psz@mit.edu), MIT LCS Howard Shrobe (hes@ai.mit.edu), MIT AI Labpsz@mit.eduhes@ai.mit.edu William J. Long, Glenn S. Burke, Mike McGeachie, Delin Shen, Ying Zhang, Steve Bull, Joe Hastings, MIT Isaac S. Kohane, Marco Ramoni, The Children’s Hospital, Boston Jon Doyle, North Carolina State University Adaptive Knowledge-Based Monitoring

2. 2Maita Final, Dec. 5, 2002 -- **Not for distribution** Impact Rapid reconfiguration enables adaptation to evolving threats "inside the loop" Dynamically and intelligently targeted monitors give commanders the information they need Rational response decisions ensure optimal, flexible, and robust defenses Trust models enable operations despite compromises to critical computing bases Common language and repository for IA&S knowledge strengthens defensive efforts Adaptive Knowledge-Based Monitoring Jon Doyle & Peter Szolovits http://www.medg.lcs.mit.edu/projects/maita Monitoring Processes Task Processes

3. 3Maita Final, Dec. 5, 2002 -- **Not for distribution** Domain Background Defense against information attacks requires broad and deep understanding of: –Mission –Systems used to accomplish it –Ability to operate with diminished resources Trade-offs among competing objectives –Threats –Capabilities of adversary –Experience

4. 4Maita Final, Dec. 5, 2002 -- **Not for distribution** Our Aims/Cyber Panel Provide situational awareness to commanders “Inside the loop” monitor construction/adaptation –Timely concerns –Empirical –Simplify CC of monitoring Guidance for automatic trust management –Self-monitoring, resource allocation Common description language(s) and library(ies)

5. 5Maita Final, Dec. 5, 2002 -- **Not for distribution** Potential Contributions Conceptual –Advance role of probabilistic, decision analytic, preference-based dynamic reasoning –Develop new methods for adaptive knowledge-based monitoring –Learning of new monitoring methods –Expressive languages for description of domain, tasks, attacks, monitoring strategies, etc. Artifactual –Maita system as a testbed to foster and test above ideas

6. 6Maita Final, Dec. 5, 2002 -- **Not for distribution** Our Overall Approach Knowledge-Based Monitoring Contextual Awareness Reusable monitoring methods Diagnostic methods to identify underlying problems Preference and utility-based specification of tactics

7. 7Maita Final, Dec. 5, 2002 -- **Not for distribution** Monitoring Processes Task Processes Infocon Bravo Danger Safe Monitoring Knowledge & Library Monitoring Management Executive Monitor Control Panels System Health Monitor

8. 8Maita Final, Dec. 5, 2002 -- **Not for distribution** Maita Monitors Maita is based on a general-purpose distributed system archtecture whose primitive (and composed) components are monitors –Control inputs via specialized HTTP server –Set of input terminals; a monitor with no inputs is a data source, often “wrapping” a lower-level system resource. –Set of output terminals; a monitor with no outputs is a display or alerting service

9. 9Maita Final, Dec. 5, 2002 -- **Not for distribution** Other Maita Components MOM (Monitor of Monitors) Human/Computer Interface –Control Panels –General-purpose display Boot server – starts monitors on its machine

10. 10Maita Final, Dec. 5, 2002 -- **Not for distribution** Outline Incremental Progress since Charleston PI meeting (Not here: –Preference compilation –Markov analysis of system call traces –Multi-stream data segmentation –Efficient trend matching) Maita Vulnerability Analysis Lessons Learned

11. 11Maita Final, Dec. 5, 2002 -- **Not for distribution** Progress since PI Meeting Making Maita implementation more –Complete Run on Windows as well as Unix platforms Ability for monitoring processes to save checkpoint data in MoM –Robust Restart capabilities from various kinds of system, communication, … failure More thorough self-monitoring Status: progress, but still not completed*

12. 12Maita Final, Dec. 5, 2002 -- **Not for distribution** Progress since PI Meeting More sources of monitoring data –System log (ftp, sendmail, imapd) –Auth log (logins, ipmon, popper) –Daemon log (ftp details, stunnel, telnet, …) –Sendmail volume, relaying –Disk utilization –Backup sizes –CPU load –Lincoln Labs TCPDUMP Additional filters & detectors, with HCI, using –Configurable parameters –Temporal sequencing

13. 13Maita Final, Dec. 5, 2002 -- **Not for distribution** Routinely monitoring

14. 14Maita Final, Dec. 5, 2002 -- **Not for distribution** Control Panel showing various monitors

15. 15Maita Final, Dec. 5, 2002 -- **Not for distribution** Sendmail/relaying & trend lines

16. 16Maita Final, Dec. 5, 2002 -- **Not for distribution** Backup sizes

17. 17Maita Final, Dec. 5, 2002 -- **Not for distribution** FTP activity

18. 18Maita Final, Dec. 5, 2002 -- **Not for distribution** FTP analysis

19. 19Maita Final, Dec. 5, 2002 -- **Not for distribution** SNORT

20. 20Maita Final, Dec. 5, 2002 -- **Not for distribution** FTP Transshipment Trend Template ESA = external site activity average RLA = resource load activity average ESA RLA Start of abnormal probing Cessation of abnormal probing Start of unusual transfersSaturation of host capacity Leveling off of unusual Transfer destinations

21. 21Maita Final, Dec. 5, 2002 -- **Not for distribution** Events recognized by ftp-monitor as preconditions and as events Parameters that must match for precondition to enable event Label to put on resulting event Recognizing: passwordscan(IP) -> ftp uploads(IP) -> excess diskuse

22. 22Maita Final, Dec. 5, 2002 -- **Not for distribution** Work in Progress Writing “Completion” of Maita code to distributable state Web site summarizing project accomplishments and distributing results Student research –Preferences for student interest matching, collaboration, and retrieval of focused information –Real-time machine learning from intensive care unit data –Markov analysis of system call patterns as another basis for detecting anomalies Planning for future use: –mMesh proposal (distributed health records, system monitoring) –ARMS (IXO) proposal on secure ship computing environment infrastructure –Potential industrial collaborations (under discussion)

23. 23Maita Final, Dec. 5, 2002 -- **Not for distribution** Computational Vulnerability Analysis Grounding the attack model in systematic analysis Ontology of: –System Properties –System Types –System Structure –Control and Dependencies

24. 24Maita Final, Dec. 5, 2002 -- **Not for distribution** Generating Attack Models Through Vulnerability Analysis The problem: Where does the attack model and its links to behavioral modes come from? –So far, by hand crafting Vulnerability Analysis supplants this by a systematic analysis: –Forming an ontology of how computer systems are structured –Building models of the environment Network topology: nodes, routers, switches, filter, firewalls System types: hardware, operating systems Server and user suites: Which servers and users run where –Analyzing how properties depend on resources –Analyzing the vulnerabilities of the resources

25. 25Maita Final, Dec. 5, 2002 -- **Not for distribution** Modeling System Structure Hardware Processor Memory Device Controllers Devices controls Part-of Operating System Logon Controller Scheduler Device Drivers Part-of Job Admitter Resides-In controls User Set Work Load File System Access Controller resources controls files Part-of Input-to controls Scheduler Policy

26. 26Maita Final, Dec. 5, 2002 -- **Not for distribution** Modeling the topology Machine name: sleepy OS Type: Windows-NT Server Suite: IIS….. User Authentication Pool: Dwarfs… Router: Enclave restrictions. …. Topology tells you: who can share (and sniff) which packets who can affect what types of connections to whom Switch: subnet restrictions. …. Switch: subnet restrictions. ….

27. 27Maita Final, Dec. 5, 2002 -- **Not for distribution** The Key Notion is Dependency Start with the desirable properties of systems: –Reliable performance –Privacy of communications –Integrity and/or privacy of data Analyze which system components impact those properties –Performance - scheduler –Privacy - access-controller Rule 1: To affect a desirable property control a component that contributes to the delivery of that property

28. 28Maita Final, Dec. 5, 2002 -- **Not for distribution** Controlling components (1) One way to gain control of a component is to directly exploit a known vulnerability –One way to control a Microsoft IIS web server is to use a buffer overflow attack on it. IIS Web Server Process Buffer-Overflow Attack Takes control of IIS Web Server Buffer-Overflow Attack Is vulnerable to

29. 29Maita Final, Dec. 5, 2002 -- **Not for distribution** Controlling components (2) Another way to control a component is to find an input to the component and then find a way to modify the input –Modify the scheduler policy parameters Scheduler Policy Parameters Input to Scheduler control by Modification- action Scheduler Policy Parameters

30. 30Maita Final, Dec. 5, 2002 -- **Not for distribution** Controlling components (3) Another way to control a component is to find one of its sub-components and then to find a way to gain control of the sub-component Job-Admitter User Job Admitter Component-of Job-Admitter control by Control- action User Job Admitter

31. 31Maita Final, Dec. 5, 2002 -- **Not for distribution** Modifying Inputs (1) One way to modify an input is to find a component which controls the input and then to find a way to gain control component Scheduler Workload Input-of Scheduler control by Job AdmitterWorkload Job Admitter Controls Attack. Controls

32. 32Maita Final, Dec. 5, 2002 -- **Not for distribution** Modifying Inputs (2) One way to modify an input is to find a component of the input and then to find a way to modify the component Scheduler Workload Input-of Scheduler controlled by User Workload Component User Workload Workload Component Attack. Modify

33. 33Maita Final, Dec. 5, 2002 -- **Not for distribution** Access Rights Each object specifies a set of capabilities required for each operation on that object –Capabilities are organized in an DAG –This generalizes the access mechanisms of all OS’s. Each actor (user or process) possesses certain capabilities. An actor can perform an action on an object only if it possesses a capability at least as strong as that required for the operation –This is a generalization of the access mechanisms in all current OS’s. An access pool is a set of machines that shares resources, password & access right descriptions

34. 34Maita Final, Dec. 5, 2002 -- **Not for distribution** Netchex The AI Lab Topology (partial) Router Netchex Filters out Telnet. Server Switch 8th- Floor-1 8th- Floor-2 7th- Floor-1 Router Access pool Life Kenmore Maytag Server Access Pool Doc Dopey Sleepy Dwarf Access Pool Sneezy Sakharov Truman Quincy- Adams Lisp Access Pool Jefferson Wilson Creepy Crawler General Access Pool

35. 35Maita Final, Dec. 5, 2002 -- **Not for distribution** Obtaining Access (1) One way to gain access to an operation on an object is to find a process with an adequate capability and take control of the process Typical User File User Read Capability Required for Read Typical User File To Read Control- action Typical User Process Typical User Process User Read Capability Possesses Capability

36. 36Maita Final, Dec. 5, 2002 -- **Not for distribution** Obtaining Access (2) Another way to gain access to an operation on an object is to find a user with an adequate capability and find a way to log in as that user and launch a process with the user’s capabilities Typical User File User Read Capability Required for Read Typical User File To Read Logon as Typical User User Process Typical User User Read Capability Posseses Capability Launches

37. 37Maita Final, Dec. 5, 2002 -- **Not for distribution** Logging On Logging on requires obtaining knowledge of a password To gain knowledge of a password –Guess it, using guessing attacks –Sniff it By placing a parasitic virus on the user’s machine By monitoring network traffic –Change it By hacking the password file, for example.

38. 38Maita Final, Dec. 5, 2002 -- **Not for distribution** Monitoring and Changing Network Traffic Network are broken down into subnet segments Segments are connected by Routers –Routers can monitor traffic on any connected segment Each segment may be: – Shared media Coaxial ethernet Wireless ethernet Any connected computer can monitor traffic –Switched media 10 (100, 1000) base-T Only the switch (or reflected ports) can monitor Traffic Switches and Routers are computers –They can be controlled –But they may be members of special access pools To gain knowledge of some information, gain the ability to monitor network traffic

39. 39Maita Final, Dec. 5, 2002 -- **Not for distribution** Residences Components reside in several places –Main memory –Boot files –Paging Files They migrate between residences –Through local peripheral controllers –Through networks To modify/observe a component find a residence of the component and modify/observe it in the residence To modify/observe a component find a migration path and modify/observe it during the transmission

40. 40Maita Final, Dec. 5, 2002 -- **Not for distribution** Formats and Transformations Components live in several different formats –Source code –Compiled binary code –Linked executable images Processes transform one format into another –Compilation –Linking To modify a component change an upstream format and cause the transformations to happen To modify a component gain control of the processes that perform the transformations

41. 41Maita Final, Dec. 5, 2002 -- **Not for distribution** Modification during Transmission To control traffic on a network segment launch a “man in the middle attack” –Get control of a machine, redirect traffic to it To observe network traffic get control of a switch/router and a user machine and then reflect traffic to the user machine To modify network traffic launch an “inserted packet” attack. –Get control of a machine –Send a packet from the controlled machine with the correct serial number but wrong data before the sender sends the real packet

42. 42Maita Final, Dec. 5, 2002 -- **Not for distribution** An Example Affecting reliable performance: –Control the scheduler - The scheduler is a component that impacts performance –By modifying the scheduler’s policy parameters The policy parameters are inputs to the scheduler –By gaining root access The policy parameters require root access for writing –By using a buffer overflow attack on the web-server The web-server process possesses root capabilities The web-server process is vulnerable to a buffer-overflow attack. For this attack to impact performance, all the actions must succeed –Each has an a priori probability based on its inherent difficulty and current evidence suggesting that it occurred.

43. 43Maita Final, Dec. 5, 2002 -- **Not for distribution** Affecting Data Privacy (1)

44. 44Maita Final, Dec. 5, 2002 -- **Not for distribution** Affecting Data Privacy (2)

45. 45Maita Final, Dec. 5, 2002 -- **Not for distribution** Affecting Data Privacy (3)

46. 46Maita Final, Dec. 5, 2002 -- **Not for distribution** Affecting Performance (1)

47. 47Maita Final, Dec. 5, 2002 -- **Not for distribution** Affecting Performance (2)

48. 48Maita Final, Dec. 5, 2002 -- **Not for distribution** Trust Model: Trustworthiness Compromises Attacks Attack Models and Monitoring

49. 49Maita Final, Dec. 5, 2002 -- **Not for distribution** Using Attack Scenarios This information is captured in an object-oriented Knowledge Representation and a rule-base system that reasons about it. The inference process develops multi-stage attack scenarios The scenarios can be transformed into trend templates for plan recognition purposes The scenarios can be transformed into Bayesian network fragment for diagnostic purposes The model can be used to audit an environment for possible cascaded vulnerabilities

50. 50Maita Final, Dec. 5, 2002 -- **Not for distribution** Technical Validation Conceptual adequacy of –Descriptive languages –Monitoring methods –Learning approaches Performance of artifacts –Ability to recognize events of interest to human sysadmins –Resource utilization

51. 51Maita Final, Dec. 5, 2002 -- **Not for distribution** Schedule (and Future Milestones) End-to-end data feed, analysis and display –Accomplished New, more efficient Trend Template matcher as monitor component –Partly Accomplished Maita system –Robust “complete” implementation (almost) –Demonstration on local data sources (accomplished) –Validation against sysadmins (not done) Preference  utility function compiler –Complete, numerous applications under way Analyses, refinements and papers

52. 52Maita Final, Dec. 5, 2002 -- **Not for distribution** Transition Potentially transferable results: –Monitoring architecture –Languages of descriptions –Monitoring methods –Diagnostic methods –Learning of trend templates –Compilation of utilities –Visualizations Plans and Interest –Preference compiler Teknowledge interest Harvard/MIT HST program interest matching “Red Book” –Maita monitors NLM proposal for distributed clinical data sharing Potential commercial collaboration/transfer

53. 53Maita Final, Dec. 5, 2002 -- **Not for distribution** Lessons Recognize as large systems problem –Distributed, secure, authenticated, dynamic, self- monitoring computing infrastructure Design and implement for robustness, generality Collaborate with others Recognize as large knowledge-based system problem –Need lots of knowledge –Systematic representation –Basic inference system as substrate

54. 54Maita Final, Dec. 5, 2002 -- **Not for distribution** More Lessons Recognize as large HCI problem The total problem is unsolvable –Focus on limited goals –Collaborate with others Need good data for development and “formative” evaluation

55. 55Maita Final, Dec. 5, 2002 -- **Not for distribution** Recent Publications 1.McGeachie, Michael, “Efficient Utility Functions for Ceteris Paribus Preferences”, AAAI 2002. 2.Shrobe, Howard, “Computational Vulnerability Analysis for Information Survivability”, AAAI 2002. 3.Long, William, Doyle, Jon, Burke, Glenn, and Szolovits, Peter, Detection of Intrusion across Multiple Sensors, submitted. 4.McGeachie, Michael and Doyle, Jon, “Utility Functions for Ceteris Paribus Preferences”, submitted. 5.Steven Bull, “Diagnostic Process Monitoring with Temporally Uncertain Models,” MIT EECS SM Thesis, May 2002. 6.Jon Doyle, Isaac Kohane, William Long, Howard Shrobe, and Peter Szolovits, "Agile Monitoring for Cyber Defense", Second DARPA Information Survivability Conference and Exposition (DISCEX-II), Anaheim, California, June 12-14, 2001. 7.Jon Doyle, Isaac Kohane, William Long, Howard Shrobe, and Peter Szolovits, "Event recognition beyond signature and anomaly", Second IEEE-SMC Information Assurance Workshop, West Point, New York, June 5-6, 2001. http://medg.lcs.mit.edu/projects/maita/

56. 56Maita Final, Dec. 5, 2002 -- **Not for distribution** Financial Status (12/5/2002) Total funds received = $1,987,403 Total funds expended = all* Remaining = $295,720 Depletion: ~9/30/2002 Total funding = $1,987,403 Total contract = $2,487,144 * possible return of disability

57. 57Maita Final, Dec. 5, 2002 -- **Not for distribution** Current personnel Peter Szolovits Howie Shrobe Bill Long Glenn Burke Students: Delin Shen, Ying Zhang, Joe Hastings Fern DiOliveira Children’s Hospital: Isaac Kohane, Marco Ramoni