tiara upper software levels

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

Upload: paiva

Post on 17-Jan-2016

32 views

Category:

Documents


0 download

DESCRIPTION

Tiara Upper Software Levels. Object System Meta Object Protocol Non-Bypassable Wrappers Value dependency tracking Execution Monitoring Access Control. Application Substrate: Application Data Management. Data Accountability: Provenance Tracking. Application Middleware. Plan Level: - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Tiara Upper Software Levels

Tiara Upper Software Levels

Object System

Meta Object Protocol

Non-Bypassable Wrappers

Value dependency tracking

Execution Monitoring

Access Control

Page 2: Tiara Upper Software Levels

Software Layers

Hardware:Security Tags Processing

Object Abstraction:Structured Memory,

Method Dispatch

Operating System:Hardware Management,Hardware Level Policy

Meta-Object Level:Wrapper Management

Access Control:Policy Enforcement S

ystem S

oftware

Plan Level:Self Monitoring and Recovery

Data Accountability:Provenance Tracking

Application Substrate:Application Data Management

Application

Middlew

are

We are here

Page 3: Tiara Upper Software Levels

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

Page 4: Tiara Upper Software Levels

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

Page 5: Tiara Upper Software Levels

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

Page 6: Tiara Upper Software Levels

Tiara Software Level

Object System

Meta Object Protocol

Non-Bypassable Wrappers

Page 7: Tiara Upper Software Levels

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

Page 8: Tiara Upper Software Levels

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

Page 9: Tiara Upper Software Levels

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

Page 10: Tiara Upper Software Levels

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

Page 11: Tiara Upper Software Levels

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

Object-1

Class-1

Standard Class

Function-1

Standard Generic Function

Method-1

Standard Method

Page 12: Tiara Upper Software Levels

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

Page 13: Tiara Upper Software Levels

Tiara AIF Software Level

Access Control

Execution Monitoring

Value Provenance Tracking

Page 14: Tiara Upper Software Levels

AIF* Method Combination

• Multiple layers of wrappers– Access control– Execution monitoring– Information flow tracing– Application wrappers

ApplicationCode

Application Tracking

Integrity Checks

Event Stream

* AIF = Accountable Information Flow

Access Control

Execution MonitoringValue Flow Tracking

Page 15: Tiara Upper Software Levels

Tiara Software Level

Access Control

Execution Monitoring

Value Provenance Tracking

Page 16: Tiara Upper Software Levels

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.

Page 17: Tiara Upper Software Levels

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

Page 18: Tiara Upper Software Levels

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)

Page 19: Tiara Upper Software Levels

Example Trace

*principal* = *ME*

(frob 'a 'b ) ->Around Before Frobing A B Before Frobbing A B Frobbing A B After Frobbing A BAround After Frobing A B(A B)

(frob 1 2) ->Around Before Frobing 1 2 Before Frobbing 1 2 Frobbing 1 2 After Frobbing 1 2Around 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 2Around After Frobing 1 2(1 2)

(frob 'a 'b) -> Error:ACCESS VIOLATIONPRINCIPAL *YOU* ATTEMPTED TO FROBA andB

Page 20: Tiara Upper Software Levels

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)

Principal

Inner-admin

*admin*

Application Principal

Bad Principal

Good Principal

Baddie Goodie-1 Goodie-2

Page 21: Tiara Upper Software Levels

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

Principal

Inner-admin

*admin*

Application Principal

Bad Principal

Good Principal

Baddie Goodie-1 Goodie-2

Page 22: Tiara Upper Software Levels

Use of Class Structure

Principal

Admin Domain

GeneralAdmin

DomainAdmin

User

DomainUser

Anybody in the domain can perform this operation (but not general admins)

Domain users can do this operation but domain-specific admins can’t

Any admin can perform this operation

Use of multiple permitting and denying methods for a single operation can form more complex policies

Page 23: Tiara Upper Software Levels

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

Page 24: Tiara Upper Software Levels

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

Page 25: Tiara Upper Software Levels

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]

Page 26: Tiara Upper Software Levels

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

Page 27: Tiara Upper Software Levels

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”?

Page 28: Tiara Upper Software Levels

FrobGF

AIFGF

Method-1

AIFMethod

StandardGF

Add Method

Gf

Add-method:Class: AIF-GF

Class: AIF-Method

StandardMethod

Add-method: Equals Add-Method GFClass: Standard-Method

This wrapper controls who can change these methods

This wrapper controls who can change these methods

Wrapper Controls Who can Frob

This wrapper controls who can change these methods

Page 29: Tiara Upper Software Levels

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

Page 30: Tiara Upper Software Levels

Tiara Software Level

Access Control

Execution Monitoring

Value Provenance Tracking

Page 31: Tiara Upper Software Levels

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

Page 32: Tiara Upper Software Levels

RealOutput

SimulatedOutput

Real Environment (Implementation)

Simulated Environment (Model)

in

in'

out

out'

List ofConflicts

Translator

in out

SimulatedComponent

RealComponent

Reflection

Differencer

Architectural Differencing

Page 33: Tiara Upper Software Levels

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

Page 34: Tiara Upper Software Levels

The Execution Monitor Generator

System Model

Wrappers

Execution Monitor

Event Stream

Code

Conditions &JustificationsBackup Data

Alerts

Synthesize

Page 35: Tiara Upper Software Levels

Get event info

Get Next Cmd

Get Leg

Get Events

cmd

Get MovementGet Sortie

event

Add Event

Mission Plan

Add Additional Info

MissionPlan

Mission Plan

MissionPlan

Take Off?

Y N

Mission Plan

Mission Plan

Get Events

More Events?

Y N

Each component can be annotated with:

• Entry Events• Exit Events• Allowable Events

Control Flow

Data Flow

Page 36: Tiara Upper Software Levels

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.

Page 37: Tiara Upper Software Levels

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

Page 38: Tiara Upper Software Levels

Get event info

Get Next Cmd

Get Leg

Get Events

cmd

Get MovementGet Sortie

event

Add Event

Mission Plan

Add Additional Info

MissionPlan

Mission Plan

MissionPlan

Take Off?

Y N

Mission Plan

Mission Plan

Get Events

More Events?

Y N

Each component can be annotated with:

• Entry Events• Exit Events• Allowable Events

Control Flow

Data Flow

Page 39: Tiara Upper Software Levels

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

Page 40: Tiara Upper Software Levels

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.

Page 41: Tiara Upper Software Levels

Step1

Normal

Mode

Post-Condition1

PreconditionsStep1

Post-Condition2

PreconditionsStep2

Step1

Abnormal

Mode1

PreconditionsStep3

Checked, Pinned at P = 1

Host1

Normal

Mode

Host1

HighJacked

P = .9

P = .8

“Logical or”probability table

“Logical and”probability table

“Logical and”probability table

Checked, Pinned at P = 1

Step1

Bayesian Dependency Diagram

Bad Image

File Attack

P = .7

Bogus Condition

Page 42: Tiara Upper Software Levels

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.

Page 43: Tiara Upper Software Levels

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.

Page 44: Tiara Upper Software Levels

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

TrustModel

Application

ExecutableCode

AWDRAT

Monitors

AWDRAT

DiagnosticService

Application

ExecutableCode

AWDRAT

DecisionTheoreticChoice

AWDRAT

DecisionTheoreticChoice

TrustModel

Page 45: Tiara Upper Software Levels

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

Page 46: Tiara Upper Software Levels

Tiara Software Level

Access Control

Execution Monitoring

Value Provenance Tracking

Page 47: Tiara Upper Software Levels

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.

Page 48: Tiara Upper Software Levels

Basic Structures

Value Computation Inputs

3 +

2 xx

1 yy

A Premise

B Premise

3 was computed by: Adding 2 and 1 2 was the xx field of Object A 3 was the yy field of Object B

Page 49: Tiara Upper Software Levels

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 +

X foo

Baz

3

X

Y

Y Baz

Page 50: Tiara Upper Software Levels

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:1. Regions dealing with special AIF methods that expect

and produce boxed data2. 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

Page 51: Tiara Upper Software Levels

Example

BAR is a normal function

(DEFMETHOD TEST-AIF-METHOD ((X NUMBER) (Y NUMBER)) (LET ((#:G1000 (LIST Y X))

(Y (BOX-VALUE Y)) (X (BOX-VALUE X)))

(MAKE-BOXED-VALUE :VALUE (BAR (+ X Y)) :MNEMONIC 'TEST-AIF-METHOD

:SUPPORT (LIST* #:G1000))))

Save x & y for dependency tracking

Extract raw values so that they can be added and raw result is passed to BAR

Package and return result with dependency information

(DEF-AIF-METHOD TEST-AIF-METHOD :TRANSPARENT ((X NUMBER) (Y NUMBER))

(BAR (+ X Y)))

Page 52: Tiara Upper Software Levels

(DEFMETHOD TEST-AIF-METHOD ((X NUMBER) (Y NUMBER)) (FOO (LET ((#:G1001 (LIST Y X))

(Y (BOX-VALUE Y)) (X (BOX-VALUE X))) (MAKE-BOXED-VALUE :VALUE (+ X Y)

:MNEMONIC 'TEST-AIF-METHOD :SUPPORT (LIST* #:G1001))

)))

Example

(DEF-AIF-METHOD TEST-AIF-METHOD :TRANSPARENT ((X NUMBER) (Y NUMBER))

(FOO (+ X Y))) Foo is another AIF method

Save x & y for dependency tracking

Extract raw values so that they can be added

Package result with dependency information

Pass packaged information to FOO

Page 53: Tiara Upper Software Levels

Example

(add-as t1 t2)#<Boxed-value 3> (derivation *) The value 3 was computed in the procedure ADD-AS from: The value 1 was computed in the procedure A from: The value #<TEST1 0001> which was the input PREMISE The value 1 which was the input PREMISE The value 2 was computed in the procedure A from: The value #<TEST1 0002> which was the input PREMISE The value 2 which was the input PREMISE

(DEFMETHOD ADD-AS :TRANSPARENT ((THING1 TEST1) (THING2 TEST1)) (+ (A THING1) (+ 1 (A THING2))))

Object t1Class: test1Slot A: 1

Object t1Class: test1Slot A: 2

Page 54: Tiara Upper Software Levels

Boxed Value Dispatching

• The previous examples use type signatures involving the types of the actual values

• But the methods are actually passed instances of type “Boxed-value”

• Use the MOP to control the method for method dispatching.– We developed a new dispatching method that applies to

AIF data– Use this to dispatch as normal for unboxed values– For boxed values, dispatch on the type of the value slot– This is done only for AIF generic functions

Page 55: Tiara Upper Software Levels

Code

(defparameter *alice-global* (make-boxed-value 2))(defparameter *bob-global* (make-boxed-value 3))

(def-aif-method alice :opaque ((x number) (y number)) (setq *alice-global* (+ x y) *bob-global* (+ x y)) *alice-global*)

(def-aif-method alice :permitter (principal x y) t)

(def-aif-method bob :transparent ((x number) (y number)) (FORMAT t "~%In primary ~a ~a” x y) (+ (alice x y) x))

(def-aif-method bob :noticer ((x number) (y number)) (format t "~%Noticing Bob before ~a ~a" x y) (let ((stuff (multiple-value-list (call-next-method)))) (format t "~%Noticing Bob after ~{~a~^, ~}" stuff) (apply #'values stuff)))

Page 56: Tiara Upper Software Levels

Execution Traces=> *alice-global*#<Boxed-value 2>=> (derivation *) The value 2, which was an input provided by the user running as #<Principal Goodie-1>

=>*bob-global*#<Boxed-value 3>=> (derivation *) The value 3, which was an input provided by the user running as #<Principal Goodie-1>

=> (bob 5 6)Noticing Bob before 5 6In around number method 5 6In around method 5 6In primary #<Boxed-value 5> #<Boxed-value 6>Noticing Bob after #<Boxed-value 16>#<Boxed-value 16>

Page 57: Tiara Upper Software Levels

Execution Traces(Derivation *)

The value 16, which was computed by the principal Goodie-1 in the procedure BOB from: The value 11, which was computed by the principal Goodie-1 in the procedure ALICE from: The value 6, which was an input provided by the user running as Goodie-1 The value 5, which was an input provided by the user running as Goodie-1 The value 5, which was an input provided by the user running as Goodie-1

=>*alice-global*#<Boxed-value 11>=>(derivation *)The value 11, which was computed by the principal Goodie-1> in the procedure ALICE from: The value 6, which was an input provided by the user running as Goodie-1 The value 5, which was an input provided by the user running as Goodie-1

Page 58: Tiara Upper Software Levels

CCOAT Example

Page 59: Tiara Upper Software Levels

Trace from CCOAT

(image-threat-level #<DRAWN-IMAGE>)#<Boxed-value 5>

The value 5, which was computed by the principal Goodie-1 in the procedure IMAGE-THREAT-LEVEL from: The value #<DRAWN-IMAGE>, which was an input provided by the user running as Goodie-1 The value 5, which was computed by the principal Goodie-1 in the procedure ASSESS-THREAT from: The value #<DRAWN-IMAGE>, which was an input provided by the user running as Goodie-1 The value #<DRAWN-IMAGE, which was an input provided by the user running as Goodie-1 The value 103.947105, which was computed by the principal Goodie-1 in the procedure DISTANCE from: The value #<DRAWN-IMAGE, which was an input provided by the user running as Goodie-1 The value #<DRAWN-IMAGE, which was an input provided by the user running as Goodie-1

(define-ccoat-command (com-assesss-threat :name t :menu t) ((object-1 'drawn-image :prompt "Blue unit") (object-2 'drawn-image :prompt "Red unit")) (setf (image-threat-level object-1) (threat-level object-1 object-2)))

(def-aif-method threat-level :transparent ((p1 drawn-image) (p2 drawn-image)) (let ((distance (distance p1 p2))) (let ((threat-level (assess-threat p1 p2 distance))) threat-level)))

Page 60: Tiara Upper Software Levels

Status and Next Steps

• Status:– Full implementation except for dispatching on compartments

as well as data types– Applied to CCOAT application

• Small GUI for a DARPA seedling (~ 1000 lines of Lisp code)• Fairly typical code (not written for TIARA)• No rewriting of code needed (other than renaming defining

forms)

– Some more code analysis need for a few Lisp features

• Next steps:– Clean up the implementation– Extend to dispatch on compartments– Extend to include reliability & certainty estimates & Bayesian

propagation– Experiment with a larger prototype– Use to implement simulation of TIARA core functionality