Adaptive Knowledge-Based Monitoring for Information Assurance

1. Adaptive Knowledge-Based Monitoring Adaptive Knowledge-Based Monitoring for Information Assurance Peter Szolovits (psz@mit.edu), MIT LCSHoward Shrobe (hes@ai.mit.edu), MIT AI Lab 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, BostonJon Doyle, North Carolina State University

2. 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

3. 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)

4. 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

5. 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

6. Other Maita Components • MOM (Monitor of Monitors) • Human/Computer Interface • Control Panels • General-purpose display • Boot server – starts monitors on its machine

7. 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

8. 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*

9. 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

10. Routinely monitoring

11. Control Panel showing various monitors

12. Sendmail/relaying & trend lines

13. Backup sizes

14. FTP activity

15. FTP analysis

16. SNORT

17. RLA RLA RLA ESA ESA ESA ESA ESA FTP Transshipment Trend Template • ESA = external site activity average • RLA = resource load activity average Start of abnormal probing Saturation of host capacity Leveling off of unusual Transfer destinations Start of unusual transfers Cessation of abnormal probing

18. Recognizing: passwordscan(IP) -> ftp uploads(IP) -> excess diskuse 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

19. 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)

20. Computational Vulnerability Analysis • Grounding the attack model in systematic analysis • Ontology of: • System Properties • System Types • System Structure • Control and Dependencies

21. Generating Attack ModelsThrough 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

22. File System Modeling System Structure files Part-of resources Operating System Access Controller Hardware controls Logon Controller User Set Processor Part-of Part-of Input-to Job Admitter Memory Device Controllers controls Scheduler Work Load controls Input-to Devices Device Drivers Scheduler Policy Resides-In controls

23. Modeling the topology Machine name: sleepy OS Type: Windows-NT Server Suite: IIS….. User Authentication Pool: Dwarfs… Switch: subnet restrictions. …. Switch: subnet restrictions. …. Router: Enclave restrictions. …. Topology tells you: who can share (and sniff) which packets who can affect what types of connections to whom

24. 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

25. 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 IIS Web Server Is vulnerable to Takes control of Buffer-Overflow Attack Buffer-Overflow Attack

26. Scheduler Policy Parameters Modification- action 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 Scheduler Input to control by Scheduler Policy Parameters

27. Control- action User Job Admitter 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 Job-Admitter Component-of control by User Job Admitter

28. 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 Scheduler Input-of control by Workload Controls Job Admitter Workload Controls Controls Job Admitter Attack.

29. User Workload Component Workload Modify Attack. 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 Scheduler Input-of controlled by Workload Component User Workload

30. 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

31. Doc Life Router Access pool The AI Lab Topology (partial) Netchex Router Netchex Filters out Telnet. Server Switch 8th-Floor-1 8th-Floor-2 7th-Floor-1 Sakharov Wilson Lisp Access Pool Dwarf Access Pool Server Access Pool Truman Dopey Kenmore Sleepy Maytag Quincy-Adams General Access Pool Sneezy Creepy Crawler Jefferson

32. Control- action Typical User Process 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 Typical User File Required for Read To Read User Read Capability Typical User Process Possesses Capability User Read Capability

33. Logon as Typical User User Process 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 Typical User File Required for Read To Read User Read Capability Typical User Posseses Capability Launches User Read Capability

34. 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.

35. 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

36. 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

37. 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

38. 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

39. 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.

40. Affecting Data Privacy (1)

41. Affecting Data Privacy (2)

42. Affecting Data Privacy (3)

43. Affecting Performance (1)

44. Affecting Performance (2)

45. Attack Models and Monitoring Trust Model: Trustworthiness Compromises Attacks

46. 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

47. 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

48. 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

49. 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

50. 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