DAME Dependability and Security Study

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

• Introduction
• Analysis Approach Dependability and Security
• Security
• Dependability
• Joint working
• Experience
• System Context
• Asset Analysis
• What Next Deployment Clustering
• Summary

3
Introduction
4
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

5
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.

6
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.

7
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. Reliability and Availability are concerns,
but have lower significance.
8
Analysis ApproachDependability Security
9
Dependability and Security

• Attributes
• Reliability
• Safety
• Maintainability
• Security (Confidentiality, Integrity,
  Availability)
• Attributes have varying significance in different
  systems.

10
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.

11
Security (Risk) Analysis
12
Dependability Analysis

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

13
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.

14
High level Analysis of a Complex System
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 doesnt 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 wont be reached
6 Secure and timely access to accurate registry data. False information held in registry
15
High level Analysis of a Complex System

• Analysis process
• SHARD like analysis of component in this case
  grid middleware infrastructure
• Uses guidewords, for example
• Omission.
• Commission.
• Early.
• Late.
• Value (detectable/undetectable).

16
High level Analysis of a Complex System
1. Provision of secure and timely data flow. 1. Provision of secure and timely data flow. 1. Provision of secure and timely data flow. 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.
17
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

18
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.

19
Experience System Context
20
Context
Needs to be extended to accommodate arbitrary
deployment
21
Initial System View
22
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?

23
Actors System Context
24
Service Assets
25
Data Assets
26
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?

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

28
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.

29
Experience Asset Analysis
30
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.

31
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

32
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. Reliability and Availability are concerns,
but have lower significance.
33
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.

34
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.

35
What Next Deployment Contacts
36
System Data flow between services (Fragment)
AURA_Search
Pattern_Matcher
AURA_Encoded_data
Z_Mod_Result
Time_Series_Fragment
AURA_G (Train)
Z_Mod_Viewer
XTO_Assessor
Time_Series_Data
Feature_Result
Extractor_G
XTO_G
Z_Mod
Engine_Data_Record
Performance Data
Engine_Data_Store
37
Deployment groups services and related data
38
Deployment container contracts
e.g. Engine data confidentiality Service
integrity (management access) Authentication
users of feature results
39
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

40
Summary
41
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.

42
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.

43
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.

44
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.