1. DAME Dependability and Security Study: Progress Report Howard Chivers University of York Practical Security for e-Science Projects 25 November 2003

2. This talk presents my personal perspective, not the considered view of the project or any of its partners. But credit and thanks must go to busy developers and industrial partners who have been consistently helpful and generous with their time, and to Martyn Fletcher who is the primary author for study deliverables.

3. Contents DAME Introduction DAME Introduction The Method: Dependability and Security The Method: Dependability and Security Stage One: System Context Stage One: System Context Stage Two: Asset Analysis Stage Two: Asset Analysis Summary Summary

4. DAME Engine flight data Airline office Maintenance Centre European data center London Airport New York Airport American data center Grid

5. Project Aims Develop a Grid-enabled diagnostic system Develop a Grid-enabled diagnostic system Demonstrate this on the Rolls-Royce AeroEngine diagnostics problem 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 needed for industrial deployment: Develop the understanding needed for industrial deployment: –Grid middleware and application/services layer integration –Scalability and Deployment options –Security and Dependability issues

6. Challenges Support on-line diagnostic workflow in real time Support on-line diagnostic workflow in real time Deal with the data from 1000’s engines in operation Deal with the data from 1000’s engines in operation Prove distributed pattern matching methodology Prove distributed pattern matching methodology Address customer concerns about grids, including scalability & security Address customer concerns about grids, including scalability & security Demonstrate the business case for the technology Demonstrate the business case for the technology

7. Why use a grid? Implementing a distributed, integrated, workflow has considerable potential customer value Implementing a distributed, integrated, workflow has considerable potential customer value The workflow requires collaboration between multiple stakeholders The workflow requires collaboration between multiple stakeholders An integrated business process is needed to provide evidence for any diagnosis, and traceability to subsequent action An integrated business process is needed to provide evidence for any diagnosis, and traceability to subsequent action The data is high volume, and is distributed between stakeholders’ sites (eg maintenance, factory, airports) The data is high volume, and is distributed between stakeholders’ sites (eg maintenance, factory, airports) The variable computing load makes resource sharing attractive for some processes The variable computing load makes resource sharing attractive for some processes

8. DAME – Project Partners Universities: Universities: –University of York –University of Sheffield –University of Oxford –University of Leeds Industrial: Industrial: –Rolls-Royce Aeroengines –Data Systems and Solutions –Cybula Infrastructure: - White Rose Grid - National e-Science Support Centre

9. Developers

10. Analysis Approach: Dependability & Security

11. Purpose of the Study Provide analysis to enable ultimate deployment of DAME in engine domain. Provide analysis to enable ultimate deployment of DAME in engine domain. Provide analysis as basis for deployment in other domains. Provide analysis as basis for deployment in other domains. Contribute to Grid community research in dependability and security. Contribute to Grid community research in dependability and security.

12. Dependability and Security Attributes: Attributes: –Reliability –Safety –Maintainability –Security (Confidentiality, Integrity, Availability) Attributes have varying significance in different systems. Attributes have varying significance in different systems.

13. Security (Risk) Analysis Focus on risk to the overall business process Focus on risk to the overall business process Process (see previous talk by Jonathan Moffett) Process (see previous talk by Jonathan Moffett) –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: From matrix, identify unacceptable deployment risks, example: –High impact and high likelihood need to be reduced.

14. Security (Risk) Analysis

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

16. High level Analysis of a Complex System Focuses on infrastructure. Focuses on infrastructure. Approach at York (based on FMEA – Failure Modes an Effects Analysis + SHARD - Software Hazard Analysis and Resolution in Design): 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. Satisfy derived requirements to provide dependability.

17. Choice of method Approaches have complementary strengths Approaches have complementary strengths In combination: In combination: –Use security risk analysis to establish whole-system issues –Use ‘high level analysis’ to deal with non-security attributes, and provide infrastructure vulnerabilities into the main risk analysis –Combined study minimises project cost and customer involvement Take advantage of other sources of vulnerability information Take advantage of other sources of vulnerability information

18. Observations The security risk method provides a useful overall framework. The security risk method provides a useful overall framework... but in many projects a wider set of attributes will be needed... but in many projects a wider set of attributes will be needed. Using both forms of analysis explicitly deals with the flexible deployment of applications envisaged in the grid. 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 applications and infrastructure are mature enough to allow dependability analysis... but it remains to be seen if the interface requirements between applications and infrastructure are mature enough to allow dependability analysis.

19. Stage One: System Context

20. Context

21. System Context System Context document (DAME/York/TR/03.007) 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: Purpose: –Provides a concise reference – allows stakeholders to agree on a description of the system. –Identifies Assets: Services and Data ».. but not hardware?

22. Actors & System Context

23. Service Assets

24. Data Assets

25. Service & Data co-deployment CBRAnalyser SDMRecord CBRResult CBRRuleSet AURAResult Get Maintenance Data Produces Uses

26. Context: Method Business Use-Cases & initial Service diagram derived from design documents Business Use-Cases & initial Service diagram derived from design documents Aim for a Deployment-neutral description Aim for a Deployment-neutral description Checks: 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: 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: Result: –24 Data Types and 14 Services. –Contrast with »‘Initial brainstorm’ meeting: 4 data types & 4 services »Previous slide (9): 3 data types & 13 services (2 different!)

28. Observations Methodological analysis is necessary. Methodological analysis is necessary. Need to be flexible about representations & models to align with project methods. Need to be flexible about representations & models to align with project methods. Control: 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 ‘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. The system is ‘virtual’ – need to be explicit about the management needed.

29. Stage Two: Asset Analysis

30. Asset Analysis Just Started. Just Started. Generated pro-forma of assets and generic concerns. Generated pro-forma of assets and generic concerns. Reviewed with Industrial Partners: Reviewed with Industrial Partners: –Reviewed system context document. –Preliminary assets analysis - assigned concerns and impacts to: »Data assets »Service assets Need to document and confirm results with project and industrial partners. Need to document and confirm results with project and industrial partners.

31. Process Keyword list to prompt discussion on each asset: 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. Only about half these categories used, and not all for every asset. Impact rating: L/M/H in business terms: Impact rating: L/M/H in business terms: –L: significant cost –M: impact on company bottom line –H: long term impact on company bottom line

32. Typical Concerns Confidentiality of key industrial properties. Confidentiality of key industrial properties. –The most critical, at present, are algorithms Integrity of data used to make business decisions. Integrity of data used to make business decisions. Provenance of critical decisions made using the system. Provenance of critical decisions made using the system.

33. Observations New system requirements will probably emerge from this study: 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 decisions (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. 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’. 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. 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. Linking impact (L/M/H) to business criteria helps prevent ‘drift’ of assessments.

35. Summary

36. Documents Produced Discussion / working documents: Discussion / working documents: –DAME Initial Dependability Assessment - AME/York/TR/03.001. From meeting with industrial partners on 17 th 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: System Context Document - DAME/York/TR/03.007.

37. Future Work Complete System Context document and asset analysis. Complete System Context document and asset analysis. Assess vulnerabilities, including the use of high level analysis function and dependability key word analysis. Assess vulnerabilities, including the use of high level analysis function and dependability key word analysis. Produce likelihood - impact matrix. Produce likelihood - impact matrix. Target unacceptable risks. Target unacceptable risks. Identify deployment constraints & requirements Identify deployment constraints & requirements Identify mitigation mechanisms e.g., encryption, access controls, replication, etc. Identify mitigation mechanisms e.g., encryption, access controls, replication, etc.

38. Final Observations Security risk analysis is best carried out as an integrated part of the system design: 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.

39. Final Observations (2) The grid nature of the problem introduces new challenges: DAME is a ‘virtual system’ 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. Appropriate security is essential before systems of this sort can be exploited commercially.