Integrity Through Mediated Interfaces

PI Meeting August 19, 2002

Bob Balzer, Marcelo TallisTeknowledge

<balzer,mtallis>@teknowledge.comLegend: Turquoise Changes from Feb. 02 PI meeting

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

• PowerPoint and Word

• Wrap Program– Detect access of integrity marked data & decode it

M

M

M

M

Mediation Cocoon

Environment = Operating System External Programs

Program

ChangeMonitor

– Monitor User Interface to detect change actions• Translate GUI actions into application specific modifications

Technical Approach

– 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

MS Word Data Integrity Technical Approach To Attribution

• Time Lever shows document development– User selects range of interest– Move Forwards through Operations Log– Move Backwards through Undo Stack

Operations Log

Completed (except for integration of generic mechanisms from PowerPoint Data Integrity)

GUI Monitortied to

change history

Data Integrity Current Status

• MS Word Data Integrity– Completed

• MS PowerPoint Data Integrity– Generic Data Integrity Architecture

• Shape creation/deletion• Shape move/resize/recolor/rotate• Connector attachment/detachment• Group/ungroup

• Problems (requiring unique development)– Single Process Debug/Demo Architecture– Typed Text (different low-level implementation)– Dangling Connectors (incomplete COM model)Demo

Data IntegrityFuture Plans

• Complete Coverage of PowerPoint Operations• Integrate generic mechanisms from PowerPoint

Integrity Manager back into Word• Deploy Word and PowerPoint Integrity

Managers

SafeEmail Attachments

M

M

M M

WrapperSafetyRulesk

AttachmentHandler

Spawn

• Wrapper encapsulateseach spawned process

SafeEmail Attachments

M

M

M M

WrapperSafetyRulesj

AttachmentHandler

• Each opened attachment spawns new process

SpawnSafeEmail Attachments

M

M

M M

WrapperSafetyRulesi

Attachment

Attachment

EmailClient

Safe EmailAttachments

Deployment• Bundled with ADF as OPX Hardened Client• MARFORPAC Usability Test 2/02• FBE-Juliet Red Team Experiment 8/02

Deployment/Red-Team Results• MARFORPAC Usability Test (2/02)

– No field usage problems (no attacks)– Assessed as unmaintainable

• Not configurable by Marine Sysadmins• Alerts not understandable by Marine personnel

• Hardened Client II Red-Team Experiment (5/02)– Test new ByPass Protection mechanism

• All attacks on or to disable ByPass Protector failed• Attack on unprotected wrapper data succeeded

– This vulnerability disclosed to Red-Team prior to experiment• FBE-Juliet Red-Team Experiment (8/02)

– Test SafeEmail against malicious attachments• All attacks on SafeEmail failed

– SafeEmail field portable to OfficeXP

New rule system & GUI Autonomic responses

Response

Demo

SafeEmail Plans• Integration with Enterprise Wrappers

– Offboard Policy Manager– Offboard Alert Dissemination– Dynamic Policies

• Pilot Deployments– Within Military and Federal Government

• Development of Contained Execution Compartments– No persistent effects from opening email attachments– Only new document versions from editors

• Integration with autonomic attack detector (SBIR)• Hardening & Independent Assessment (OPX)• Broader Coverage (all user processes) (OPX)