Tiara Upper Software Levels

1. Tiara Upper Software Levels Object System Meta Object Protocol Non-Bypassable Wrappers Value dependency tracking Execution Monitoring Access Control

2. Application Substrate: Application Data Management Data Accountability: Provenance Tracking Application Middleware Plan Level: Self Monitoring and Recovery Access Control: Policy Enforcement Meta-Object Level: Wrapper Management Operating System: Hardware Management, Hardware Level Policy System Software Object Abstraction: Structured Memory, Method Dispatch Software Layers We are here Hardware: Security Tags Processing

3. Motivation • Hardware and system software provide fine-grained protection • Instruction by instruction • Word by word • The macroscopic level of method invocation is a necessary and complementary level • Access control • Data provenance tracking • Execution monitoring: assertions, data & control flow • Hardware provides guarantees of the inviolability of the upper level software • Making key locations and procedures inaccessible to user level code

4. Goals • Flexible access control within a dynamic environment • Expressive, compact and simple language for rules • Prevent unintended information and control flows • Maintenance of data provenance • Keep track of how application data was computed and of the dependencies between data items • Trace back, propagation of trust levels • Guarantee that execution corresponds to intended behavior and to diagnoses discrepancies • Architectural system model: abstract model of intended flows • Execution monitor compares to actual execution and diagnoses differences

5. Approach • Use Common-Lisp object system as experimental vehicle • Preserve most of its features • Extend and embed richer system using meta-object protocol • Add security meta-data as part of the protocol • Principals • Compartments • Embed a non-bypassable Accountable Information Flow (AIF) facility • Method level access control • Value flow tracing between and through methods • Execution monitoring of flows and assertions between methods

6. Tiara Software Level Object System Meta Object Protocol Non-Bypassable Wrappers

7. Class Lattice • Classes form a lattice • Each class has multiple immediate superclass • Superclass is the transitive closure of immediate-superclass relation • Inheritance • Each class inherits from all of its superclasses

8. Multi-method Dispatch • All procedures are implemented by methods on object classes • Multi-method dispatch enables selection of the effective method based on the types of all of the arguments • Applicable methods are the set of most specific method whose formal parameters are super-types of the types of the actual parameters • Applicable methods are combined to form the effective method • Wrappers, before, after, primary method • Multi-method dispatch subsumes all object-oriented models

9. Wrapper Methods • There are different categories of methods • Primary • Before & after • Wrapper • The effective method is combination of all applicable methods • All wrappers are called first • Control if and with what arguments primary is called • Then all before methods • Then the most specific primary • Then all after methods • Wrappers get control after internal methods return • New method combinations and method roles can be defined using the Meta Object Protocol

10. Examples (defmethod t1 ((i integer)) (format t "~% Integer ~d" i)) (defmethod t1 ((i number)) (format t "~% number ~d" i)) (defmethod t1 :around ((i integer)) (format t "~%Integer around") (call-next-method)) (defmethod t1 :around ((i number)) (format t "~%Number around") (call-next-method)) (t1 1.0) -> Number around Number 1.0 (t1 1) -> Integer around Number around Integer 1

11. Meta Object Protocol (MOP) • Everything is an instance of some class • Classes, functions, and methods are instances of meta-classes • Meta-class are part of class lattice • Methods on meta-classes control how the basic operations of the object system work • Add method, delete method, method dispatch, method combination Standard Class Standard Generic Function Class-1 Standard Method Function-1 Method-1 Object-1

12. Building an AIF System • We create new meta-classes, method dispatches, and method combinations • AIF method dispatch: • Dispatches on data-types of arguments as usual • Also dispatches on compartments of arguments • Also dispatches on additional Principal argument • Principal encodes the role & privileges of the user-agent on whose behalf the thread runs • AIF method combination and wrapper methods • Access control: prevent primary methods from running by signaling a violation. • Signaling events to execution monitor • Special method compilation for data provenance tracking

13. Tiara AIF Software Level Access Control Execution Monitoring Value Provenance Tracking

14. Application Tracking Event Stream Integrity Checks AIF* Method Combination * AIF = Accountable Information Flow • Multiple layers of wrappers • Access control • Execution monitoring • Information flow tracing • Application wrappers Access Control Application Code Value Flow Tracking Execution Monitoring

15. Tiara Software Level Access Control Execution Monitoring Value Provenance Tracking

16. Access Control • Security policies are expressed using multi-method wrappers • Principal: Who is acting and in what role • Operation: What is being done • Operands: To what objects • Policies are expressed compactly using the class lattice • Reduces the number of policies required • Current implementation only dispatches on classes (not compartments) • Each wrapper corresponds to an entry in the access control matrix • If there are no relevant positive wrappers then a violation is signaled • Each relevant wrapper can also perform computations and conditionally signal a violation.

17. Rules for :Permitter Methods • Methods occur in most specific first order • Body of method can conduct an arbitrary computation and then returns a value • Body should return :violation or NIL or T • :violation means the operation isn’t permitted • NIL means the method doesn’t offer an opinion • T means the operation is definitely permitted • If nobody permits an operation it’s a violation • Methods are selected based on types and compartments of all arguments • Class inheritance is involved for all arguments • Class structure of principals is involved on the principal argument • Unqualified argument matches all types and compartments • Implication: there need not be a “root” principal with unlimited rights to do anything

18. Example The principal *me* can frob anything But, nobody else can frob anything unless specifically permitted: (defmethod frob :permitter ((principal (eql *me*)) a b) t) (defmethod frob :permitter ((principal t) a b) :violation) Any principal can frob integers: (defmethod frob :permitter ((principal t) (a integer) (b integer)) t)

19. Example Trace *principal* = *ME* (frob 'a 'b ) -> Around Before Frobing A B Before Frobbing A B Frobbing A B After Frobbing A B Around After Frobing A B (A B) (frob 1 2) -> Around Before Frobing 1 2 Before Frobbing 1 2 Frobbing 1 2 After Frobbing 1 2 Around After Frobing 1 2 (1 2) *principal* = *YOU* (frob 1 2) -> Around Before Frobing 1 2 Before Frobbing 1 2 Frobbing 1 2 After Frobbing 1 2 Around After Frobing 1 2 (1 2) (frob 'a 'b) -> Error: ACCESS VIOLATION PRINCIPAL *YOU* ATTEMPTED TO FROB A and B

20. Principal Application Principal Inner-admin Bad Principal Good Principal *admin* Baddie Goodie-1 Goodie-2 Code and Principal Structure (def-aif-method bob :permitter ((principal (eql *admin*)) (x t) (y t)) :violation) (def-aif-method bob :permitter ((principal good-principals) (x number) (y number)) t) (def-aif-method bob :permitter ((principal bad-principals) (x integer) (y integer)) :violation)

21. Principal Application Principal Inner-admin Bad Principal Good Principal *admin* Baddie Goodie-1 Goodie-2 Execution Traces =>(set-principal *admin*) =>(bob 3 4) Error: Access violation: Generic Function BOB Args: #<Principal Admin>, 3, 4 => (set-principal Goodie-2) =>(bob 12 11) Noticing Bob before 12 11 … In primary … #<Boxed-value 35> =>(set-principal* *BADDIE*) =>(bob 21 23) Error: Access violation: Generic Function BOB Args: #<Principal Baddie>, 21, 23

22. Use of Class Structure Principal Domain Admin User Domain User General Admin Domain Admin Any admin can perform this operation Anybody in the domain can perform this operation (but not general admins) Domain users can do this operation but domain-specific admins can’t Use of multiple permitting and denying methods for a single operation can form more complex policies

23. Access Control on Code Changes • We’re in a dynamic environment where code can be changed at runtime. • How do we prevent an attacker from changing our application methods? • Add-method & remove-method are MOP generic functions • We impose :permitter methods that only allow specified principals to use these generic functions to add or remove methods from our application’s generic functions. • This can be done for specific generic-functions or for whole classes of generic-functions • This secures our application level code and access control methods

24. Example of Change Protection (def-aif-method method-change :permitter ((principal aif-internal-admin-principal) (generic-function aif-internal-generic-function) (method standard-method) change-type) t) (def-aif-method method-change :permitter ((principal t) (generic-function aif-standard-generic-function) (method standard-method) change-type) :violation) (def-aif-generic carol (a b) :generic-function-class aif-internal-generic-function :permitter (good-principals t))

25. Example of Change protection (set-principal *goodie-1*) (def-aif-method carol :raw (a b) (+ a b)) Error: #<Principal Goodie-1> is attempting to add a method to generic function CAROL with qualifier :RAW and specializers #<BUILT-IN-CLASS T>, #<BUILT-IN-CLASS T>, #<BUILT-IN-CLASS T> [condition type: ILLEGAL-CHANGE-METHOD]

26. Non Bypassable Access Control • We’re in a dynamic language where methods can be added and removed at run-time • We just showed mechanisms that keep an attacker from changing the methods that implement our application • We also need to prevent an attacker from removing, adding, or changing the :permitter methods that implement our access controls on using and changing methods • Note than any such change would require the use of Add-method or Remove-method to remove change methods implementing the application’s generic-functions

27. Closing the Loop • What prevents somebody from removing the :permitter wrappers on add-method or remove-method? • Thereby un-securing our application level controls • We impose wrappers that prevent adding or removing methods to the Add-method and Remove-method generic functions. • This means our application level controls can’t be removed • What prevents an attacker from removing or changing these “meta-wrappers”?

28. AIF GF Standard Method AIF Method Standard GF Add Method Gf Add-method: Class: AIF-GF Class: AIF-Method Frob GF Method-1 Wrapper Controls Who can Frob This wrapper controls who can change these methods This wrapper controls who can change these methods This wrapper controls who can change these methods Add-method: Equals Add-Method GF Class: Standard-Method

29. Status and Next Steps • Accomplished • Created type lattice for compartments and principals • Created new AIF method combination with :permitter methods • Modified the MOP to provide hidden argument for principal • Demonstrated this on existing application code • Next steps • Extend method dispatch to consider both class and compartment for each argument • Apply this design of system software as well

30. Tiara Software Level Access Control Execution Monitoring Value Provenance Tracking

31. Event Noticing Wrappers Make The Application System Accountable to an Architectural Model • Application methods are executed as raw code • How do we know what’s going on and whether it’s what we wanted to go on? • Wrappers inserted in good places • Architectural model tells us what those are • Wrappers intercept events • Entry and exit from methods • Events are sent to an execution monitor • Monitor “squirrels away” backup information

32. Architectural Differencing Real Environment (Implementation) in out Real Component List of Conflicts Reflection Translator Real in out Output Differencer out' in' Simulated Simulated Output Component Simulated Environment (Model)

33. Execution Monitoring • The code is annotated by wrappers • These are synthesized by a wrapper generator • We run code in parallel with a model • Wrappers send event stream to architectural differencing • Deviations between model predictions and observations from the wrappers are “symptoms” of misbehavior • Diagnosis infers possible compromises of the underlying resources and updates a trust model • Recovery is effected by restoring corrupted data resources and picking new method in light of the updated trust model

34. The Execution Monitor Generator Wrappers Code Synthesize System Model Event Stream Execution Monitor Conditions & Justifications Backup Data Alerts

35. Mission Plan Get Events Get Next Cmd cmd More Events? Y N Take Off? Get event info Y N event Add Event Mission Plan Get Movement Get Leg Get Sortie Add Additional Info Mission Plan Mission Plan Get Events Mission Plan Mission Plan • Each component can be annotated with: • Entry Events • Exit Events • Allowable Events Control Flow Data Flow

36. Generating Execution Monitor • For every event in the model • Generate wrapping method (def-aif-method xxx :noticer (args) (notice-event xxx entry args) (call-next-method) (notice-event xxx exit returns)) • For every data flow generate a trigger to move the data (similar for control flow) • For every component generate a forward chaining rule that triggers when all inputs are present and checks the prerequisite conditions • For every component generate a forward chaining rule that triggers on completion and asserts the post-conditions.

37. The Execution Monitor • Hierarchical Task Network • Data Flow, Control Flow, Splits and Joins • Pre, Post conditions • Entry, Exit, Allowable Events • TIARA Generates • Plumbing to pick up the events and create event stream • State Machine corresponding to task network, receives event stream, checks for validity • Module States: • Inactive (data not available, preconditions not satisfied) • Ready (data available) • Running (initiating event seen) • Completed (terminating event seen) • An unclaimed event initiates diagnosis

38. Mission Plan Get Events Get Next Cmd cmd More Events? Y N Take Off? Get event info Y N event Add Event Mission Plan Get Movement Get Leg Get Sortie Add Additional Info Mission Plan Mission Plan Get Events Mission Plan Mission Plan • Each component can be annotated with: • Entry Events • Exit Events • Allowable Events Control Flow Data Flow

39. Behavior Models • Each mode (good, bad, …) of each component has a behavior model • Preconditions, Post-conditions • Generally about data-structure integrity • At a very abstract level data-structures are about: sets, sequences, mappings • Introduced simple data modeling language: • Add-to-set, Add-to-mapping, Insert-in-sequence • Delete-from-set, Delete-from-mapping, Delete-from-Sequence • Default implementation for each • Predicate to force consistency check

40. Dependency Maintenance • Execution Monitor actively checks the prerequisite, post-conditions and other constraints in the plan. • The Execution Montior builds a dependency graph between checked and inferred conditions: • Post-conditions and events within a step are justified with a link to the assumption that the step executed normally and to the prerequisites conditions. • Preconditions are justified by the causal link in the plan that connects it to a set of post-conditions of prior steps • If a condition is directly observed, that condition is justified as a premise • If an check fails, diagnosis is initiated.

41. Bayesian Dependency Diagram Host1 Normal Mode P = .8 Step1 Step1 Normal Mode Preconditions Step2 “Logical and” probability table Checked, Pinned at P = 1 Post-Condition1 Preconditions Step1 “Logical or” probability table Preconditions Step3 Post-Condition2 “Logical and” probability table Step1 Abnormal Mode1 Bogus Condition P = .9 Checked, Pinned at P = 1 Host1 HighJacked Bad Image File Attack P = .7

42. What the Bayesian Network Tells You • After adding all conflict nodes to the Bayesian network: • The posterior probabilities of the underlying resource modes tell you how likely each compromised (or healthy) mode is. • This is an aggregate estimate • These probabilities are part of the trust-model and guide resource selection in recovery and future computations. • The posterior probability of each post-condition assertion • This is an aggregate estimate • This gives us an estimate of what conditions are actually true. This also guides recovery. • The posterior probability of each possible attack • This implies possible compromises of other similar resources that have not yet been observed and that will also guide recovery.

43. Summary of Diagnosis • The result of Diagnosis is the construction of a Bayesian network coupling attacks, resource vulnerabilities, compromised states of the resources and finally the observed behavior of a computation. • This network assigns posterior probabilities to: • Assertions modeling the state of the computation • These assertions are the prerequisite and post-conditions of the various computational steps in the plan diagram • Compromised modes of the resources used by the computation • The recovery task is to find a new plan and a new set of resources that is most likely to achieve the main goal of the plan, given this updated probabilistic information about the world.

44. AWDRAT Decision Theoretic Choice AWDRAT Decision Theoretic Choice Application Executable Code Application Executable Code AWDRAT Diagnostic Service Trust Model AWDRAT Monitors Trust Model The Trust Model • The Trust Model Includes Probability for Each Resource that it is in a compromised state. • Diagnosis Updates the Trust Model • Trust Model is Read in Upon System Startup • Trust Model Guides method selection

45. Status and Next Steps • Status: • Core framework implemented and integrated with AIF framework. • Next Steps • Improve the modeling language to cover more patterns of communication and control • E.g. dispatch, functional arguments • Re-implement plumbing and execution monitor to allow parallel threads to be monitored • Apply to a realistic but small application

46. Tiara Software Level Access Control Execution Monitoring Value Provenance Tracking

47. Value Provenance Tracking • “Provenance Wrappers” imposed around computations • Values are boxed in “TMS Like Structures” • Value • Support • Certainty and other extensions • Code rewritten to track flow through methods • Output boxed in TMS structure relating outputs to inputs, computation performed, and people involved.

48. 2 1 xx yy 3 + A B Premise Premise Basic Structures Value Computation Inputs 3 was computed by: Adding 2 and 1 2 was the xx field of Object A 3 was the yy field of Object B

49. 3 + Y Baz X foo Opaque Methods • Used when the internal details of a computation aren’t worth tracking • Unpacks inputs, feed raw values to real method • Boxes up output and provides justification • Wrapper is generated 3 Baz Y X

50. Transparent Methods • Done by source to source transformation • In effect, type inference on two meta-types “boxed” and “unboxed” • Flow analysis propagates these labels • Code rewritten to ensure that computations that expect boxed values are provided with boxed values • Divide the computation tree into coherent regions: • Regions dealing with special AIF methods that expect and produce boxed data • Primitives and other non-AIF procedures • Unbox and repackage data around calls to type 2 regions • Builds dependency chains within type 1 regions using the support fields in boxed-values