Integrity Through Mediated Interfaces PI Meeting: Feb 22-23, 2000

1. Integrity Through Mediated InterfacesPI Meeting: Feb 22-23, 2000 Bob Balzer Information Sciences Institute balzer@isi.edu Legend: Changes from previous PI meeting

2. Technical Objectives • Wrap Data with Integrity Marks • Insure its Integrity • Record its processing history • Reconstruct it from this history if it is corrupted • by program bugs • by malicious attacks • Demo these capabilities on major COTS product • Microsoft Office Suite (PowerPoint & Word only) • Also demo on a mission critical military system

3. Existing Practice • Integrity Stove-Piped on Tool-by-Tool Basis • End-to-End Integrity Not Supported • Persistent Data only Safeguarded by OS • Corruption Detection is Ad-Hoc • Corruption Repair • Based on Backups • Not Integrated with Detection This Slide Intentionally Blank

4. M Mediation Cocoon Environment = Operating System External Programs M M M Change Monitor • Wrap Program • Detect access of integrity marked data & decode it • Monitor User Interface to detect change actions • Translate GUI actions into application specific modifications Technical Approach Program • Detect update of integrity marked data • Re-encode & re-integrity mark the updated data • Repair any subsequent Corruption from History • Build on existing research infrastructure

5. M Mediation Cocoon Environment = Operating System External Programs M M Program M Change Monitor => Generic Mediators + Tool Specific mapping Two Level Architecture Major Risks and Planned Mitigation • Ability to detect application-level modifications Application Openness Spectrum: • Event-Generators: Capture as transaction history • Scripting API: Examine state to infer action • Black-Box: Mediate GUI to infer action 1. Application Independent GUI Monitor signals action types 2. Application Dependent Change Monitor • Determines Action Parameters • Logs Modification History

6. Major Risks and Planned Mitigation • Ability to detect application-level modifications Application Openness Spectrum: • Event-Generators: Capture as transaction history • Scripting API: Examine state to infer action • Black-Box: Mediate GUI to infer action => Generic Mediators + Tool Specific mapping • Ability to protect transaction history => Hide the location of the transaction history • Virtual File System wrapper • System-level Randomization Techniques • Tool-Specific Modification Trackers Expensive => Automate common portions => Provide rule-based scripting language

7. Demo Demo Accomplishments To Date • Corruption Detector (for MS Word 2000) • IDs Document Version on Save (in Document) • Records Document Cryptographic Digest on Save • Checks Document Cryptographic Digest on Load • GUI Monitor • Application Independent • Signals types of actions (e.g. buttonclick, typing) • Prototype Change Monitor for MS Word • Determines parameters for application-level action • Records transaction history (for possible Replay)

8. Accomplishments To DateOther IA Projects • IFE 2.3 ReRun:

9. ? • 14 Blue Flags established (asset targets) • 13 captured by Red-Team • 1 in dispute IFE 2.3 ReRun Experiment

10. Execution of detected modified executables IFE 2.3 ReRun Wrapper Defenses Tolerance Detection Prevention Attacks Layered Protection • Prevent modification of • Database by anyone other than DB Manager • EDI Orders by anyone other than FTP Server • Executables by anyone (during “production”) • Execution of unauthorized processes • Detect modification of • Executables by checking hidden digital signature • Tolerate modification of • Executables by reinstalling hidden saved copy

11. Demo Accomplishments To DateOther IA Projects • IFE 2.3 ReRun: only uncaptured blue flag(in dispute) • NT Security Manager • Policy specifies • which processes can run • whether executables should be integrity checked • how processes should be wrapped • All processeswrapped before execution • New AIA Project :Enterprise Wrappers (ISI/ NAI) • Goal: Network Management of Host Wrappers Common NT/Linux Interface & Infrastructure

12. Measures of Success • Widespread Deployment of Integrity Manager for MS-Office • Extensibility of Integrity Manager to other COTS products • Ease of creating Modification Trackers • Resistance to Malicious Attacks • Corruption Avoidance • Corruption Detection • Corruption Repair => Red-Team Experiment

13. Expected Major Achievements • for Integrity Marked Documents: • End-To-End Data Integrity (through multiple tools/sessions) • Modifications Monitored, Authorized, & Recorded • Authorization Control of Users, Tools, and Operations • All Changes Attributed and Time Stamped • Assured Detection of Corruption • Ability to Restore Corrupted Data • Ability to operate with COTS products • MS-Office Documents Integrity Marked • Mission Critical Military System Integrity Marked

14. Task Schedule • Dec99: Tool-Level Integrity Manager • Monitor & Authorize Tool access & updates • Jun00: Operation-Level Integrity Manager • Monitor, Authorize, & Record Modifications • Dec00: Integrity Management for MS-Office • Jun01: Corruption Repair • Dec01: Integrity Management for Mission Critical Military System • Jun02: Automated Modification Tracking

15. Key Outstanding Issues • None Yet

16. Transition of Technology • Piggyback our Technology on a widely used Target Product (MS Office) • Integrity Manager automatically invoked as needed • Make technology available for COTS products • Work with Vendors to encouragepublication of modification events

17. Needed PM Assistance • None Yet Watch this space (Summer PI meeting) Help identifying suitable mission critical military system