DAME Dependability and Security Study Presenters Howard Chivers / Martyn Fletcher University of York

DAME Dependability and Security Study

Presenters Howard Chivers / Martyn Fletcher

University of York

http://www.escience-grid.org.uk/index.htm

http://www.epsrc.ac.uk/website/Index.aspx

Distributed Aircraft Maintenance Environment - DAME

Contents

• Introduction• Analysis Approach: Dependability and Security

– Security– Dependability– Joint working

• Experience– System Context– Asset Analysis

• What Next: Deployment Clustering• Summary

Introduction


Dame Project Aims

• Develop a Grid-enabled diagnostic system• Demonstrate this on the Rolls-Royce AeroEngine

diagnostics problem– A Diagnostic Grid– Grid management tools for unstructured data– An practical application demonstrator

• Develop the understanding and Business Case needed for industrial deployment:– Grid middleware and application/services layer integration – Scalability and Deployment options– Security and Dependability issues


Purpose of the Study

• Provide analysis to enable ultimate deployment of DAME in engine domain.

• Provide analysis as basis for deployment in other domains.

• Contribute to Grid community research in dependability and security.


Why do stakeholders care?

• The DAME workflow automates a collaboration between multiple stakeholders, each has their own business perspective and interests.

• The Data is high volume – to be cost effective it must be possible to physically distribute the data and its processing.


Dependability Goals

Key goals include:

• Confidentiality of key industrial properties.– The most critical items are algorithms

• Restricting access to stakeholders’ operational performance data.

• The Integrity of data used to make diagnostic decisions.• Provenance of diagnostic decisions made using the system.

The system is advisory, so safety is not a major goal. Reliabilityand Availability are concerns, but have lower significance.


Analysis Approach:Dependability & Security


Dependability and Security

• Attributes:– Reliability– Safety– Maintainability– Security (Confidentiality, Integrity, Availability)

• Attributes have varying significance in different systems.


Security (Risk) Analysis

• Focus on risk to the overall business process• Process

– Define system context:• Boundary / actors / assets / external assumptions.

– Analyse assets:• Identify impact / threat for each.

– Attackers perspective.– Vulnerabilities.

• Identify likelihood.

• From matrix, identify unacceptable deployment risks, example:– High impact and high likelihood need to be reduced.


Security (Risk) Analysis

–

threats

Likelihood

Impact

SystemBoundary

Actors Assets

ExternalAssumptions

System Context

AssetAnalysisAttackers’

Perspective

Vulnerabilities L M H

H

M

L

x

o


Dependability Analysis

• High level analysis for complex systems developed at York is rooted in the need for safety cases of layered systems.

Distributed Middleware Infrastructure

Distributed Hardware Infrastructure

Service 0 Service N

Distributed services

Component under

analysis

Analysis Interface


High level Analysis of a Complex System

• Focuses on infrastructure. • Approach at York (based on FMEA – Failure Modes

an Effects Analysis + SHARD - Software Hazard Analysis and Resolution in Design):– Define high level functions at specified interface.– Apply guidewords (omission, commission etc.) – undesirable

situations.– Cause.– Effect.– Derived requirements - to prevent / mitigate.

• Satisfy derived requirements to provide dependability.



No. Grid Service High Level Function Example failure

1 Provision of secure and timely data flow. Network saturated/blocked.

2 Controlled access to grid processing (factory services).

One node of grid doesn’t work

3 Provision of secure algorithm and data storage and memory management

Whilst data is stored or manipulated it gets corrupted e.g. by another grid application.

4 Provision of consistent execution state and information on that state (provenance).

Different versions of same algorithm running on nodes.

5 Provision of HM and failure management Does not inform that estimated time won’t be reached

6 Secure and timely access to accurate registry data.

False information held in registry



• Analysis process:– SHARD like analysis of component – in this case grid

middleware + infrastructure

• Uses guidewords, for example:– Omission.– Commission.– Early.– Late.– Value (detectable/undetectable).



1. Provision of secure and timely data flow.

Guideword Causes Effect Derived Requirements

Omission –

Data not sent from application to application/copy on another node.

Network saturated/blocked (Denial of Service?).

Registry has no information on receiver.

Registry has incorrect information on receiver (or has been tampered with).

Receiver is no longer running.

No data arrives at far end receiver may be blocked from continuing execution.

Replicate network path.

Receiver may use date stamp on data.

Registry returns error when there is no receiver.

Registry is protected from third party alteration.


Choice of method

• Approaches have complementary strengths• In combination:

– Use security risk analysis to establish whole-system issues– Use ‘high level analysis’ to identify infrastructure

vulnerabilities in the context of the main risk analysis– Combined study minimises project cost and demands on

customer time

• Take advantage of other sources of vulnerability information – particularly for security


Observations

• The security system risk analysis method provides a useful overall framework

• … but it must include the wider set of dependability attributes.

• Using both forms of analysis explicitly deals with the flexible deployment of applications envisaged in the grid.

• ... but it remains to be seen if the interface requirements between Grid applications and infrastructure are mature enough to allow dependability analysis.


Experience: System Context


Context

–

threats

Likelihood

Impact

SystemBoundary

Actors Assets

ExternalAssumptions

System Context

AssetAnalysisAttackers’

Perspective

Vulnerabilities L M H

H

M

L

x

o

Needs to be extended to accommodate arbitrary deployment


Initial System View

Leeds

Grid Middleware Services

Sheffield

Modeling & Decision Support

DAME WRGSign-on Portal

SDMDatabase

CBRAnalysis-GEngineModel-G

GT3 ServiceCBR advisor

GT3 ServiceBD25 Enginemodel wrappedas Grid Service

XTO-G

GT3 ServiceXTO plug-ins via a GridService

DataVisualiser

GT3 ServiceJchart Viewer forviewing XTO output

Workflow

Browser basedworkflow tool.Compliant withResource Broker

Resource BrokerGT2 ServiceSchedule workflowtasks on WRGresource

Oxford

Engine Data Store

Engine DataDatabase

York

Data Mining Services

AURA-GAURA-GDatabase

DataStore-GGT3 ServiceSimulates arrival &storage of QUOTEdata

Zmod Viewer

GT3 ServiceBrowser based dataviewer for zmod files

GT3 ServiceZmod datasearch facility

Collaboration tools

GT3 ServiceToolset for multiusercollaboration

WRGGT3/2

WRGGT3/2

WRGGT3/2

WRGGT3/2

DAME workbench

SecurityGT3 SecurityServiceProxy-Management

DAME GUI

GT3 ServiceBrowser based GUIto DAME services


System Context

• System Context document (DAME/York/TR/03.007)

– Business process.– System boundary.– Actors (primary and supporting).– Assets (service and data).– Service interactions.– External assumptions.

• Purpose:– Provides a concise reference – allows stakeholders to

agree on a description of the system.– Identifies Assets: Services and Data

• .. but not hardware?


Actors & System Context

UploadEngineData

Information / request for advice

MaintenanceEngineer (ME)

Domain Expert (DE)- engine expert

DAMEDiagnosis

PerformMinor Repair

Investigate using tools

ProvideDiagnosis

/ Prognosis/ Advice

Remove engine anddispatch for major overhaul

Return overhauledengine to service

Request advicefrom MA

Update EngineRecord

GroundSupportSystem

DowloadEngineData

LocalDiagnosis

Distributed AircraftMaintenance Environment (DAME)

- Miscellaneous Providers.

Engine Data Center (EDC) - DS&S

Service Data Manager (SDM) including Workscope Generator- RR

Maintenance Analyst (MA)- maintenance expert

Investigate usingtoolsUpdate Engine

RecordProvide

Diagnosis/ Prognosis

/ Advice

Airline / Maintenance Contractor(at Airport)

Engine MaintenanceRepair and Overhaul

(MRO) Facility(RR / Contractor)

Remote / DistributedTools and Services

EngineManufacturer

(RR)

Data Center(DS&S)

Request advicefrom DE

Update EngineRecords

Information / requestfor advice

Update Engine Records

PerformInspections


Service Assets

-EncodedZmodDataFeature

AURA-G

CBRAnalysis-G

EngineModel-G

SDM-G

EngineDataStore-G

XTO-G

QUOTE / GSS

Portal-CollaborationEnvironment

-ClusterData

DataBaseMiner-G

EngineDataCenter

1

1

1

1

gets SDM Record from

1..*

1

gets EDR from

1

1

gets EDR from

1

1

gets SDM Records from

1

1

gets EDR from

1

1

extracts orders using

1

1

diagnoses fault using

1

1

searches for clusters using

1

1

visualises engine data using

WorkflowManager

Chart-G

CBRWorkflowAdvisor-G

*

1

stores Engine Data Record in

1

1

stores / retrieves DAME results, annotations, etc.

11..*

seaches for patterns using

The EDC contains variousindependent tools andfacilities - only theEngineDataStore isshown here.

1

1

models engine using

11

gets extracted orders

* *

ZModViewer-G

Encoder-G

1 *

*

1

*

1

gets EDR from

1

1

getsWorkflowAdvice

*

1

ArrivalNotification

RoleDatabase

MyProxy

1

1

1

1


Data Assets

EngineFlight SDMRecordFlightEventAirframe

EngineDataRecordQUOTEFeatureResult

WorkflowRecord

EngineModelResult

AURAResult

ZmodViewerResult

ChartResultCBRResultXTOFeatureResult

AURAEncodedData

SuggestedWorkflow

Annotations

TrackedOrder

CBRRuleSet WorkFlowRuleSet

Case

RoleUser

UserRole

EncodedData

1**1*1

11

1

1

1

1

0..110..1

** *

1

1

1

*

1

*1

0..*

1 *

1

*

1

0..1

10..11

0..1

1

*

1

0..1

1

0..1

1

0..1

1

0..1

*

*

*

1

*

1

1

1 *

*1

1

11

WorkflowRule0..1

*

0..1

1

0..1

1

UserView

1

1..3

*

1

0..*

1

distinguishedName

deadlinestatususerStatus[3]

processPerfomance

inputParamSet


Context: Method

• Business Use-Cases & initial Service diagram derived from design documents

• Aim for a Deployment-neutral description• Checks:

– Build & check data and service models from the interactions specified in the use-cases.

– Is the data required by each service consistent with the data model?

– Do members of the project, and its customers, think this represents their system?


Context: Method (2)

• Control granularity:– Services at deployment granularity.– Data, sufficient to distinguish between different use or

origin.– Assets must be meaningful to customers to allow a

discussion of threat & impact.

• Result:– 24 Data Types and 14 Services.– Contrast with

• ‘Initial brainstorm’ meeting: 4 data types & 4 services • Initial system view (slide 21): 3 data types &

13 services (2 different!)


Observations

• Methodological analysis is necessary.– Existing system documentation is strong on services but weak on

data

• Need to be flexible about representations & models to align with project methods.

• Control: – Granularity– Avoid mechanisms, keep to requirements

• The ‘grid’ nature may make it difficult to establish hardware assets - may be a problem or blessing, but needs to be recognised.

• The system is ‘virtual’ – need to be explicit about the management needed.


Experience: Asset Analysis


Asset Analysis

• Generated pro-forma of assets and generic concerns.• Reviewed with Industrial / Academic Partners:

– Reviewed system context document.

– Preliminary assets analysis - assigned concerns and impacts to: • Data assets• Service asset

• Stakeholder concerns also used to elicit system security goals.– Allows the separation of goal concerns and ‘derived’ requirements.

• Review of Asset Threat model and Security Goals now complete.


Process

• Keyword list to prompt discussion on each asset: – execution, confidentiality, integrity, availability, privacy,

completeness,provenance, non-repudiation…

• Only about half these categories used, and not all for every asset.

• Impact rating: L/M/H in business terms:– 0: not rated – too low to be significant– L: significant cost– M: impact on company bottom line– H: long term impact on company bottom line


Typical Requirements

Key goals include:

• Confidentiality of key industrial properties.– The most critical items are algorithms

• Restricting access to stakeholders’ operational performance data.

• The Integrity of data used to make diagnostic decisions.• Provenance of diagnostic decisions made using the system.

The system is advisory, so safety is not a major goal. Reliabilityand Availability are concerns, but have lower significance.


Observations

• New system requirements will probably emerge from this study:– Finer grain control of users within roles– The need for provenance for data items as well as

workflows– The possible separation of different types of raw data to

facilitate grid processing– The need to audit services in the (virtual) system

• Need to be careful about responsibilities when data or services are shared with other systems– e.g. long term data integrity for some data items is important, but outside DAME.


Observations

• The customers have real security concerns – this is not a system where all parts will be allowed to ‘run anywhere’. – security analysis informs deployment options

• Keywords (e.g. integrity’) are very broad – need to record the actual concern in each case.

• Linking impact (L/M/H) to business criteria helps prevent ‘drift’ of assessments.

What Next: Deployment Contacts


System Data flow between services (Fragment)

Engine_Data_Record:

Extractor_G

Time_Series_Data

AURA_Search

AURA_G (Train)

AURA_Encoded_data

Z_Mod_Viewer

Z_Mod_Result

XTO_G

Engine_Data_Store

Performance Data

Z_Mod

Time_Series_Fragment

Pattern_Matcher

XTO_Assessor

Feature_Result


Deployment groups services and related data

Engine_Data_Record:

Extractor_G

Time_Series_Data

AURA_Search

AURA_G (Train)

AURA_Encoded_data

Z_Mod_Viewer

Z_Mod_Result

XTO_G

Engine_Data_Store

Performance Data

Z_Mod


Pattern_Matcher

XTO_Assessor

Feature_Result


Deployment container contracts

Engine_Data_Record:

Extractor_G

Time_Series_Data

AURA_Search

AURA_G (Train)

AURA_Encoded_data

Z_Mod_Viewer

Z_Mod_Result

XTO_G

Engine_Data_Store

Performance Data

Z_Mod


Pattern_Matcher

XTO_Assessor

Feature_Result

e.g.:

Engine data: confidentiality

Service integrity (management access…)

Authentication: users of feature results


Deployment Conclusions

• Provides the link between the high level system design, users security goals, and actual deployed software.

• Will specify requirements on ‘locations’– Test deployment architecture for feasibility– Decomposes the distributed system for subsequent

vulnerability analysis


Summary


Documents Produced

• Discussion / working documents:– DAME Initial Dependability Assessment -

AME/York/TR/03.001. From meeting with industrial partners on 17th March 2003.

– Analysis of the Grid – Phillipa Conmy – Security Risk Brief – Howard Chivers– Options for Merging Dependability and Security Analysis -

Howard Chivers. This includes a neutral terminology.– DAME Dependability and Security: Asset Analysis pro-

forma.• DAME Dependability and Security: System Context

Document - DAME/York/TR/03.007.• DAME Dependability and Security: Asset Analysis

Document - DAME/York/TR/04.001.


Future Work

• Sign off System Context, Asset Analysis and attacker profiles.• Identify deployment constraints & requirements• Identify & document security trade-offs at the system design

and deployment level.• Document lessons learned – where the existing design needs

to be revisited from the security perspective.

• Vulnerability analysis etc (risk matrix, mitigation)– As far as can be applied in a generic way – the target of

deployment is not the present system.


Final Observations

• Security risk analysis is best carried out as an integrated part of the system design:– The context can be part of the standard system

documentation– Deployment and other design tradeoffs can be made early– The security analysis will highlight requirements that might

otherwise be missed.


Final Observations (2)

• The grid nature of the problem introduces new challenges: DAME is a ‘virtual system’– Mapping to hardware is deferred– Requirements for administration of the ‘virtual’ system, as

well as individual resources

• Appropriate security is essential before systems of this sort can be exploited commercially.