Srs common architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

SRS Common Architecture PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

SRS Common Architecture. Bob Balzer Neil Goldman Dave Wile Teknowledge Corp. Prevention. Proactive Prevention. Reactive Prevention. Self-Regeneration. Sensor. Recovery. Health Monitoring. Repair. Diagnosis. Inner Regenerative Layer: Repair (and prevent) unblocked attacks.

Download Presentation

SRS Common Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Srs common architecture

SRS Common Architecture

Bob Balzer

Neil Goldman

Dave Wile

Teknowledge Corp.


Srs integration architecture

Prevention

Proactive Prevention

Reactive Prevention

Self-Regeneration

Sensor

Recovery

Health Monitoring

Repair

Diagnosis

  • Inner Regenerative Layer: Repair (and prevent) unblocked attacks

  • Defense In Depth

    • Outer Prevention Layer: Block most attacks

SRS Integration Architecture

Component Diagnosis, Attack Recognition,

Malicious Intent Determiner

Architecture Diffferencer, Harm Detector

Corruption Extent Determiner, Reconstitution Planner

Software Dynamic Translation, Generated Network Filter, Dynamic Method Dispatch

Memory Layout Diversity, Network Filter, Scalable Redundant Storage, Robust Scalable Comm.


Technical goals

Technical Goals

  • Include as many SRS program elements as possible

  • Minimal intrusion into existing tools, primarily

    • by announcing system status incrementally

    • And dynamically responding to other tools’ results

  • Integrate capabilities for seamless interoperation

  • Stimulate the production of new capabilities to further integration goals


Project abbreviations

Project Abbreviations

  • AWDRAT: MIT: Shrobe and Teknowledge:Balzer

  • Cortex: Honeywell: Musliner

  • Daikon: MIT: Ernst and Rinard

  • Dawson: Global Infotek: Just

  • JHU: Johns Hopkins U.: Amir and Purdue U.: Nita-Rotaru

  • MBE (model-based executive): MIT: Williams and Sullivan

  • PMOP: Teknowledge: Balzer and MIT: Shrobe

  • SensorNet: Telcordia: Van Den Berg and Rutgers: Rajagopalan

  • Strata (Genesis): UVA: Knight, Davidson, Evans, Nguyen-Tuong and CMU: Wang


Shared system architecture

SRS

Component

AWDRAT

Cortex

MBE

JHU

Choose

response

Strata

Dawson

PMOP

SensorNet

Daikon

Effect

response

Shared System Architecture

Announce and analyze

system status


Technical approach

Technical Approach

  • Parallel monitoring and analysis by SRS components of a single target system

  • Components communicate via a global blackboard

  • Blackboard organized by a shared ontology for describing system and heartbeat states

  • Subscriptions provide access to others’ sensors, analysis, and response choice


Srs organizational architecture

Pervasive

Self-Regeneration

PMOP

SensorNet

Cortex

AWDRAT

Dawson

Genesys

Learning&Repair

SRS Organizational Architecture


Overview of potential scenarios

Setup

Install Learning Harness (Cortex, Daikon, MBE, PMOP)

Determine Method / Class Equivalents (PMOP, Strata)

Install Wrappers and Obfuscate DLLs (AWDRAT, Dawson, PMOP)

Detect

Data Error (Daikon)

Attack Indicator (Dawson)

Program Error (AWDRAT, Cortex, Dawson, JHU, MBE, Strata)

Heartbeat

(Cortex)

Operator Induced Error (PMOP, SensorNet)

Analyze

Collateral Damage Assessment (AWDRAT, Daikon, JHU, MBE)

Trust and Risk (AWDRAT, Cortex, MBE, PMOP, SensorNet)

Assess Learning Data (Cortex, Daikon, MBE, PMOP)

Propose Repair

Program Error: Execute a component in the virtual machine (Strata)

Select from method alternatives & regenerate from scratch (AWDRAT, Dawson, MBE)

Select from method alternatives & backtrack (JHU)

Operator Induced Error:

Automated surrogate or backup operator

Omit the affected component

Data Error:

Data Repair (Daikon)

Restore Data / DB (Cortex)

Overview of Potential Scenarios


Scenarios continued

Make Repair

Data Error:

Data Repair (Daikon)

Restore Compromised DB (Cortex)

Program Error:

Execute a component in the virtual machine (Strata)

Select from method alternatives & regenerate from scratch (AWDRAT, Dawson, MBE)

Select from method alternatives & backtrack (JHU)

Operator Induced Error:

Prevent bad effects (PMOP, SensorNet)

Ignore or encapsulate the error (New Work)

Choose Repair

(New Work to choose among additional proposed repairs)

Scenarios Continued


Blackboard organization

Blackboard Organization

Blackboard layers correspond to scenario layers

  • S (setup)

  • D (detect)

  • A (analyze)

  • PR (propose repair)

  • CR (choose repair)

  • MR (make repair


Messages passed

Messages Passed

  • Setup and Status SRS Agents

    • S:Environment attribute or input A has value V

    • S:Program mode for Sys is M

    • S:System components for Sys are { ci }

    • S:Variants for CID are { ci }

      • S:Variant generator for CID is SRSAgent [ mode, CID]

    • S:Checkpoint Sys in D

    • S:GUI checkpoint E in D

  • Detection SRS Agents

    • D:Program Sys had fault F at L in ci [where L is contained in Sys](Fault is supertype of DataError, OperatorInducedError, ProgramError)

    • D:Missed heartbeat Sys at time T fault F

    • D:Attack of Sys indicator I for CID at L in ci

  • Analysis SRS Agents

    • A:Program Sys has vulnerability V at L { to risk R }

    • A:Program Sys has collateral damage V at L

    • A:Component ci would incur risk R with certainty P

    • A:End of Positive {or Negative} learning example trial for Sys


Messages passed1

Messages Passed

  • Propose Repair, Choose Repair & Make Repair SRS Agents – Same messages used in each layer for different purposes:

    • Detectors and analyzers populate PR layer with these assertions (see following Messages).

    • Choose Repair agent asserts these same facts into CR, triggering repair.

    • Effectors assert these facts into MR to indicate repair completion.

  • Messages

    • [layer] :Replay component ci from checkpoint D in history H

    • [layer] :Substitute ci in Sys at L [used for Data repair, database substitution, and program regeneration]

    • [layer] :Remove component ci in Sys at L

    • [layer] :Revert Sys to checkpoint D in history H


Ontology for blackboard

Ontology for Blackboard

  • All blackboard objects part of ontologically described database

  • Historical and Metadata – facts as objects

    • May need special assertions

    • And special queries


Ontology demo

OntologyDemo


Blackboard design issues

Blackboard Design Issues

  • System representation

    • Identity

    • Versions (especially with learning)

    • Historical data

    • Specific types

      • Programs

      • GUI actions

      • States

      • Environment

      • Control Modes

  • Conflict resolution

  • Control resolution

    • Metadata

    • Layered blackboard

    • Agent relationships

  • Activities and Results to be communicated among SRS agents


Traditional conflict resolution solutions

Traditional Conflict Resolution Solutions

  • “First” rule by some criterion

  • Highest “priority” rule

  • Most “specific” rule

  • Rule that refers to the element most “recently” added

  • New rule

  • Arbitrary

  • All rules in parallel

  • Compartmentalized knowledge


Race conditions

Race Conditions

  • Blackboards lose their elegance when agents cannot freely access them, e.g. when agents don’t know whether to wait for more information to arrive.

    • E.g. Good: agents A and B both analyze message M and report their results independently

    • E.g. Bad: agents A, B, and C all analyze message M but B and C need A to have “passed” message M before they can work

    • Bad solution: B waits for A to “bless” M or “fail M” before proceeding

  • Good solution: when A can respond to M in a blackboard layer not examined by B and C, subsequently asserting M into a blackboard layer that both B and C look at.

  • If they’re all in the same layer, a possible solution is lattice-based access within a layer:

    • Register B and C as higher in the layer’s lattice relating all agents’ access

    • When a message M arrives that A is interested in, it is sent to A first.

    • If A reasserts M, both B and C can act on it. Otherwise, it has been “consumed” and must be removed from the blackboard.

    • Multiple, simultaneous messages: prefer complex message groups to simpler ones.

  • Use to introduce fault analyzers and repairchoice between layers.

B

C

A


  • Login