AWDRAT: Architectural-Differencing, Wrappers, Diagnosis,
Recovery, Adaptive Software and Trust Management
Howie Shrobe: MIT CSAIL
Bob Balzer: Teknowledge
AWDRAT: What are we trying to do?
Recovery and Regeneration
Adaptive Software
Attack Plan Recognition
Attack Plan
Other Sensors: Intrusion Detectors
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencing
System ModelsWrapper Synthesizer
Application Software
Wrapper
• Applications that continue to render useful services even after successful attack.
• Particularly for legacy information systems
The “On One Foot” Story• We use an Adaptive Software that selects one of several
possible methods based on expected net benefit• The code is annotated by Wrapper Generators• We run code in parallel with a model• Wrappers send events to Architectural Differencing• Deviations between model predictions and observations from
the wrappers are symptoms• 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
Outline
• Review of AWDRAT– Emphasis on major changes to the system
• Red Team• Other Experimentation
– Detection, Diagnosis, Correction
– Modeling
• Next Steps• New Directions
AWDRATRecovery and Regeneration
Adaptive (Decision Theoretic) Method
Selection
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
Wrappers Make The System Transparent
• Methods are executed as raw code (particularly when it’s legacy system)
• How do we know what’s going on?• Wrappers inserted in good places
– Architectural model tells us what those are• All Action Performed Methods (for Swing)
• Key Data Structure Manipulators
• Wrappers intercept events• Wrappers squirrel away important information
safely
JavaWrap
• Facility to insert Wrappers around Java code without changing the source code
• Depends on JVMTI to rewrite byte-code at class loading time.
• Three types of Wrappers:– Tracers: Like LISP trace facility, prints customizable entry and
exit information – Monitors: Get control both before and after real method– Transformers: Get control before and after, controls whether real
method is invoked and with what arguments, controls what value is returned.
– Transformers are used to implement dynamic dispatch
• Specified at start up with XML spec: <METHOD signature= "(Ljava/lang/String;Z)V"
monitor= “tek.mafMed.Mediators.ConstructMission” />
• SafeFamily wrappers watch all application accesses to OS resources (files, registry keys, IPs, and so on)
• SafeFamily wrapper can detect, prevent or contain accesses to critical resources
JBI Client(in Java)
JVM
WIN32 APISafeFamilysensors
Javawrappers
SafeFamily Wrappers
Role in AWDRAT
• Attempts to access, or modify, critical resources indicates the system has been corrupted or hijacked, and should be reconstituted.
• Attempts to open communications ports at inappropriate times indicate system has been hijacked
• Execution in unprotected memory indicates memory hijack
• Rule violations are forwarded to the Diagnostic Controller for further action
The Execution Monitor Generator
• Originally we hand coded:– The JavaWrap specification
– The Wrapper Methods
– Architectural Differencer
• This was tedious, time consuming and error prone• Solution: Monitor Generator
System Model Wrappers
Wrapper Spec
Execution Monitor
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
Example Model(define-ensemble maf-create-events :entry-events ((create-action-performed entry (the-model))) :exit-events ((mission-builder-submit exit (the-model))) :allowable-events ((set-initial-info exit)) :inputs (the-model) :outputs (the-model) :components ((get-next-cmd :type maf-get-next-cmd :models (normal))
(get-event-info :type maf-get-event-info :models (normal compromised)) …. ) :dataflows ((the-model maf-create-events the-model join-exit-exit … ) :controlflows ((after more-events?-exit before join-exit-exit)
(after takeoff?-get-additional-info before get-leg) … )
:splits ((more-events? maf-more-events? (cmd) (build-event exit)) …) :joins ((join-events (the-model) (take-off non-take-off)) … ) :resources ((code-files loadable-files (normal .8) (hacked .2))) :resource-mappings ((get-event-info code-files) …) :vulnerabilities ((code-files loads-code)))
Generating Plumbing
• For every event in the model– Generate an entry in the JavaWrap Specification
– Generate a Java Wrapping method that creates an entry event, calls the main method, then generates an exit event
– Certain wrapping cliché’s (startup method, imposed dispatch, specified by single keyword)
• 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.
AWDRAT
Recovery and Regeneration
Adaptive Method Selection
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architecture level Execution Monitor
System Model
Application Software
JavaWrappers
Model Compiler
Wrapper Synthesizer
Monitor Synthesizer
System DLL’s
SafeFamily Wrappers
Event Stream
Execution Discrepancies
Failure LocalizationCompromiseDescriptions
• Architectural monitoring• Wrapper synthesis• Diagnosis• Recovery and regeneration• Adaptive method selection• Trust modeling
AWDRAT Monitoring Implementation
Original Java Program
Method
Data Model
Method
Method
Java Mediators
Wrapper
Wrapper
Wrapper
Duplicated Data Model
Lisp Mediators
Application Scripting
Reconstitution
Application Tracking
Execution Monitor
Integrity Checks
Wrapper
Wrapper
Wrapper
Event Stream
Method Selection
AWDRATRecovery and Regeneration
Adaptive (Decision Theoretic) Method
Selection
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
RealOutput
SimulatedOutput
Real Environment (Implementation)
Simulated Environment (Model)
in
in'
out
out'
List ofConflicts
Translator
in out
SimulatedComponent
RealComponent
Reflection
Differencer
Architectural Differencing
The Execution Monitor• Hierarchical Task Network
– Pre, Post conditions
– Entry, Exit, Allowable Events
– Data Flow, Control Flow, Splits and Joins
• AWDRAT 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
Monitor Algorithm• Initially all modules are inactive• When system starts up it creates a startup event for the top level module
– Top level module is put into its running state
• When a module enters running state– Instantiate its sub-network, propagate input data along data flows and control along
control flow links.
• When a data arrives at input port– Check if all data available– if so enter ready state– Check preconditions, signal if check fails
• When an event arrives:– Check if this is initiating event of a module in ready state, if so change state to
running, capture input data in event and apply to input ports– Check if it’s a terminating event of a running module, if so change state to completed,
capture output data in event and apply to output ports, check post-conditions, signal if check fails
– Check if it’s an allowable event of a module in running state, if so capture data in event and apply to output ports
– Otherwise signal an unclaimed event error
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
Example Behavior Model
(defbehavior-model (maf-add-event-to-model normal) :inputs (the-event the-model) :outputs (the-model event-number) :prerequisites ([dscs ?the-event event good]
[dscs ?the-model mission-builder good]) :post-conditions ([dscs ?the-model mission-builder good] [add-to-map (events ?the-model)?event-number ?the-event
?before-maf-add-event-to-model]))
AWDRATRecovery and Regeneration
Adaptive (Decision Theoretic) Method
Selection
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
Dependency Maintenance• Architectural Differencing actively checks those
prerequisite, post-conditions and other constraints in the plan that are easily observable.
• The Diagnostic executive 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 an check succeeds, that condition is justified as a premise
• If an check fails, diagnosis is initiated.
Delay:2,4
Diagnosis with Fault Models• In addition to modeling the normal behavior of each
component, we provide models of known abnormal behaviors.– A “Leak Model” covers unknown failures.– These alternative behavioral models are called computational
modes.
• The diagnostic task is to find an assignment of a mode to each computational step such that the behavior predicted by the models associated with those modes is consistent with the observations.– A set of assignments consistent with observations is a
diagnosis; there may be several diagnoses.– A set of assignments at variance with observations is a
conflict.
Modeling Underlying Resources• The misbehavior of the software component may actually be due
to a compromise of resources used in that computation.• We extend the modeling framework showing the dependence of
computations on the resources– Each resource has models of its state of compromise (I.e. its modes)– The modes of the resources are linked to the modes of the computation
by conditional probabilities– E.g. if a computation resides on a node which hosts a parasitic process,
then the computation is likely to be slowed down.
Normal:Highjacked:
Uses Resource
Normal: Probability 90%
Hacked: Probability 10%
Component 1
Has modelsHas models
Conditional probability = .2
Conditional probability = .3
Image-1
Host1 Reads Image File
Has-Vulnerability
Overflow-AttackEnables
Image-File
Resource-type
CausesNormal
HighJacked Execution
.5
.7
Adding Attack Models• An Attack Model specifies the set of attacks that are
believed to be possible in the environment– Each resource has a set of vulnerabilities
– Vulnerabilities enable attacks on that resource
– Computational Vulnerability Analysis of the actual configuration can determine the possible attack model
• Given a vulnerability and an attack that can exploit the vulnerability it is possible that the attack compromised the resource with the vulnerability– This is a conditional probability
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
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.
AWDRATRecovery and Regeneration
Adaptive (Decision Theoretic) Method
Selection
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
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
AWDRATRecovery and Regeneration
Adaptive Software
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
AbstractService
ServiceQualityParameters
User’sUtility
Function
The binding of parameters has a value to the user
Resource1,1
Resource1,2
Resource1,j
Each method requires different resources
The system selects the method which maximizes net benefit
User requests A
service with certain parameters
ResourceCost
Function
The resourcesUsed by the methodHave a cost
Net benefit
Each method binds the settings of The control parameters in a different way
Method1
Method2
Methodn
Each service can beProvided by several
Methods
A system adapts by having many methods for each service
Method Selection• Given a service name and a utility function,
method selection uses a prolog-like query language to:– Find relevant methods– Find resources meeting that method’s constraints– Bind the service qualities
• For each successful query it:– Calculates the resource cost– Calculates the utility of the service parameters– Calculates net benefit
• Selects method that maximizes net benefit
Extension to Hierarchical Planning
• Utility function returns max and min utility, by iterating over all combinations of unbound parameters
• A method can require sub-services– Sub-service parameters unified with top-level
parameters
• Depth first search:– Resources (and cost) accumulates
– More parameters bound -> Max utility descreases
– Net utility descreases
• Branch-and-bound: If current utility < Max so far, then back-track
Decision Making with Compromises
• M is a method, the vector R is an assignment of specific resources to M
• Each resource Ri in R can be in one of several specific modes
• A “resource state” RS is an assignment of a specific mode Ri,j to each resource Ri in R
• The Trust Model (via diagnosis) assigns a probability to each resource state
• Given a method M and a resource state RS we can calculate the vector of service qualities SQ(M, RS) that will be delivered.
• The Utility function U assigns a numeric value to a vector of service qualities SQ consistent with the requestor’s preferences
Successful Execution
• Each method M has a set of preconditions Prei(M) that are necessary for M to execute successfully.
• Some preconditions may not be directly observable, particularly at diagnosis and recovery time. Instead diagnosis assigns a probability to each of these and to their conjunction P(Prei(M)).
• The expected benefit EBsuccess of successful execution is the expected benefit conditioned by this probability:
€
EBsuccess(M,Ri) ≡ P(∧PRE j (M)) • EB(M,Ri)
Failing Execution
• If the preconditions of M don’t hold, then the method will fail.
• The failure can be assigned a cost FailCost(M)– This is ideally calculated by using a simulation model
of the organzation (necessary for insider threat).
– But it can be provided by table lookup
• The expected cost of failure is this cost weighted by the probability that the method will fail due to the preconditions not being satisfied.
€
ECFail(M) ≡ (1− P(∧PRE j (M)) • FailCost(M)
Expected Net Cost Benefit
• The total expected benefit is the difference between the expected benefit of success and the expected cost of failure.
• TotalEB(M,Ri) = EBsuccess(M,Ri) - ECfail(M)
• Each vector of resources Ri has a cost RC(Ri)
• The Expected Cost Benefit is the difference between Total Expected Benefit and the cost of the resources:
• ECB(M, Ri) = TotalEB(M, Ri) - RC(Ri)
Optimal Resource Assignment
• The system should select that method and set of resources that maximize the Expected Cost Benefit difference
€
Selected(M i,R j ) ≡ argmax(i, j)ECB(M i,R j )
AWDRATRecovery and Regeneration
Adaptive (Decision Theoretic) Method
Selection
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
MAF-CAF Current Recovery
• During execution we’ve captured the execution history and the intended state of the data structures
• We’ve also updated the trust model based on diagnosis of the last failure
• Recovery can then be accomplished by restarting, replaying the startup history (login, queries,…)
• Recovery continues by setting up the data structures to the intended state
• Method selection is driven by updated trust estimates– Including choice of code resources, class path, etc.
All Images TrustedNative Method Selected
Create Initial Mission Data
Create Leg
Add Leg to Plan
Save PlanPublish
Plan
Execution Proceeds This Far,No Discrepancies
Plan
Events
Legs
E1 E2
Sorties
Mvmts
L1 L2 S1 M1 M2
Backup Plan
Events
Legs
E1 E2
Sorties
Mvmts
L1 L2 S1 M1 M2
Initial Situation
Execution Proceeds This Far,Data Structures Corrupted
Backup Plan
Events
Legs
E1 E2
Sorties
Mvmts
L1 L2 S1 M1 M2
Plan
Events
Legs
E1 E2
Sorties
Mvmts
L1 S1 M1 M2
Create Initial Mission Data
Create Leg
Add Leg to Plan
Save PlanPublish
Plan
The Takeover
Backup Plan
Events Legs
E1 E2
Sorties Mvmts
L1 L2 S1 M1 M2
AWDRAT
Controller
Dump out good version of mission plan
Update Trust Model
Trust Model
VeryLikelyCorrupted
The Recovery
Backup Plan
Events Legs
E1 E2
Sorties Mvmts
L1 L2 S1 M1 M2
Trust Model
VeryLikelyCorrupted
Regenerate Mission-Plan
Update Trust Model
Load-Image
Service
JAVA Method
Native Method
Suspect Image,Java Method Wins
Trusted Image,Native Method Wins
• Avoid Unsafe Methods• Avoid Corrupted Code
Resources by using backup copies
Complete Operation and Continue past the attack
Regeneration Through Adaptation
Experimentation
And
Red-Team Exercise
AWDRAT Goals in Protecting MAF
• The data structures maintained by the application should accurately reflect user requests:– Each field of each data structure should be what the GUI requested
– No other fields should be present
– All the fields requested by the GUI should be present
• The application should not be able to open a port to any application other than to the JBI servers with which it must communicate (i.e. the JBOSS server).
• The application should not be able to open a port to a foreign host
• The application should not be able to write files except to the specified directories that constitute its temporary storage areas.
Blue View of Red Team Exercise
• Red-Team provided valuable “system-wide” analysis
• Red and Blue did not spend nearly enough time reaching common understanding– Focus of Our research
– Difficulty of testing client application
– Difficulty of testing Java application (few standard exploits)
• Blue didn’t stage test system far enough in advance– Configuration errors, system crash 2 days before test
– Several things that should have worked failed due to simple bugs
• Red-team was not prepared to test what mattered to us– On the fly, collaborative, ad hoc inserting of bad code
• Definition of success wasn’t always clear
• Red-Team provided valuable long term suggestions
Experimental Methodology
• Modification of class files. – Hand insert attack code into a Java source file, compile and place
the class file into the appropriate directory on the Java Classpath.
• Random attacks. – The AWDRAT controller launches a parasitic thread on startup.
This thread waits for a random delay and then attempts to violate one of the constraints. Which type of violation (and in the case of data integrity which field of which data structure) is chosen randomly.
• Wrapped methods. – A wrapped method is used as a place from which to launch a
simulated attack; for example, by wrapping the “loadImage” method, one can simulate an attack payload that is carried by a corrupted image file
MAF API Levels
Mission Builder
Events HT
Legs HT
Sorties HT
Movements HT
Mission Data Hashtable Hashjtable
Event
Hashtable
Event
Hashtable
Type TO Time 2005 Loc FRTP
Type L Time 2005 Loc LOCZ
….
MAF API
Lower API
Experimental ResultsAttack Type Number
of Attempts
Detected Diagnosed Corrected
Hand Placed 24 20 20 11 Data MAF API 10 6 6 6 Data lower API 5 5 5 5 Port Opening 3 3 3 NA File Write 3 3 3 NA Application Launch 3 3 3 NA Random 26 25 25 9 Data MAF API 6 5 5 1 Data lower API 8 8 8 8 Port Opening 5 5 5 NA File Write 4 4 4 NA Application Launch 3 3 3 NA Wrapped 9 9 9 9 File Write 3 3 3 3 Port Opening 3 3 3 3 Application Launch 3 3 3 3
Diagnosis includes identification of where the failure ocurred, the nature of the failure (bad event, corrupted data) and whether code-files vs. data files are likely candidates.
Modeling Experiment 1• Re-implemented AWDRAT framework after last
PI meeting– At least 1 intent was to simplify building of model
• Used knowledge gained in prior experience to inform model development
• Modeled more of MAF system at much finer grain• Included code files as resources• About 1 week of effort intermixed with debugging
underlying infrastructure– 448 lines, could be shorter
– 39 events
– 23 “hooked events”
Modeling Experiment 2
• Took a modest sized sub-system of Intelligent Room software– Distributed Java-based system
– Server for device switchboard
– Decent documentation available
• Sketched coarse-grained architectural model • Coded up first cut model• Total Time:
– 1 summer intern week
– 2 master student weeks
– Both starting from dead start on AWDRAT and MAF
What improvements are possible
• Coordination between SafeFamily and Execution Monitor– SafeFamily Wrappers are but not context sensitive
– It’s allowed to write to directory xyz
– But only at specific points of the program
– SafeFamily should block, tell Execution Monitor which can either initiate diagnosis or return and allow the action
• Develop more primitives to simplify behavior modeling
• Use in both server and client of larger application– Application to less safe implementation language
• Hardening AWDRAT infrastructure– Execution monitor in separate process
– Safe and reliable communication between the two
– Use redundant storage for backup data
Finer Grained Recovery
• Currently we always recover by restarting• Could recover by dynamic reloading of code
(class) files in running application– Modularize code resources into loadable chunks
– Perhaps JAR file level
– Rebuild data structures after code reload
• Need to know whether to switch code-file resources– Fingerprint code files
• Need finer grained modeling of dependencies between execution and code resources
Use of Wrappers for Exploratory Modeling
• Building an understanding of the application is the first step of modeling
• Use wrappers to gather data for machine (and/or human) learning.
• Main approach is observational, explanation-based generalization– Method wrappers collect control and data flow
– Multiple runs inform generalization
– DLL wrappers (SafeFamily) detect “dangerous” actions
– Method wrappers (JavaWrap) provides the context
• Statistical techniques characterize non-functional properties
Significant ImprovementsRecovery and Regeneration
Adaptive (Decision Theoretic) Method
Selection
Attack Plan Recognition
Attack Plan
Other Sensors: Intrusion Detectors
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencer
System ModelsWrapper Synthesizer
Application Software
Wrapper
Broadening Detection and Diagnosis
StatisticalProfile
StructuralModel/Pattern
Match
Discrepancy
AnomalyDetector
StatisticalRecognizer
PlanRecognition
Model-BasedDiagnosis
Good
Bad
Planning and Counter Planning• AWDRAT currently reasons backward from
misbehavior to compromise, to attack• Use planning technology to generate attack plans
– We have already done some of this– Planning “as if we were the Red Team”– Non-linear, temporally extended plans– Plan recognition technology generates recognizer that
projects forward from tell-tales of attack to probability of compromise and misbehavior
• Game-theoretic counter planning– Adaptive method selection
• Limited horizon expected value mini-max
– Insertion of counter measures (e.g. taste-tester, honey-pots, increased run-time variability, contained execution)
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 Policy
Parameters
Input to
Scheduler
control by
Modification-action
Scheduler Policy
Parameters
Counter Planning to Attack
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Change Password
BlockSSh
EncapsulateWrites
PatchImage
Library
Use of Wrappers as Sensors
• Current sensors are imprecise and uninformative– Network based sensors don’t observe effect on host
– Host based sensors are typically profile based
• Pervasive use of wrappers in core host software• Using such wrappers we can follow development
of an attack through the host(s) processes– Models (even coarse grained) can identify when
OS/DLL’s are take off-course
• Need to reason about where to place them– Normal program flow
– Attacker plan flow
– Cost-benefit
Machine LearningSymbolic Machine Learning
Observational Explanation-based learning
Plan generalization
StatisticalProfile
StructuralModel/Pattern
Match
Discrepancy
AnomalyDetector
StatisticalRecognizer
PlanRecognition
Model-BasedDiagnosis
Good
Bad
Statistical Machine Learning
unsupervised
supervised
• Approach is observational, explanation-based generalization• Single-shot, and few example learning• Relies on extensive knowledge base and reasoning capabilities• Observing program traces leads to AWDRAT system model• Planning and counter-planning leads to attack plan recognition
• Sensitivity to attacker delays and lack of delays
AWDRAT:
Recovery and Regeneration
Adaptive Software
Attack Plan Recognition
Attack Plan
Other Sensors: Intrusion Detectors
Trust Model: Behavior
Compromises Attacks
Diagnosis
Architectural Differencing
System ModelsWrapper Synthesizer
Application Software
Wrapper
• Self Monitoring is important and feasible– Even coarse grain monitoring provides information
• Diagnosis can provide useful Trust Information– Even with coarse grained modeling
• Trust Information can Inform Adaptive Choice
• Adaptive Choice can avoid compromised resources
• Wrappers can provide visibility and control for legacy applications– Without (extensive) rewriting in our experience.