31 December 2013 CIPHER Study Stage An Enterprise Architecture Approach to Options Analysis in Large Acquisition Programmes

2 31 December 2013 INTRODUCTION Mr E. Fintan HANBURY – Thales CIPHER Team - Capability Director

3 31 December 2013 Programme Overview The Programme – CIPHER Assessment Phase The Thales CIPHER team (Thales, BT, Fujitsu) is one of two consortium conducting a competitive assessment of a full range of Options for delivery commencing in 2010 CIPHER is not just a technology project - the Options being assessed include varying degrees of business change, outsourcing, service-orientation and potential paradigm shifts in the technology used for information assurance The CIPHER Programme, encompasses 3 Projects MODs Future Crypto Programme (FCP) MODs Interoperable Electronic Key Distribution Project (IKED) CESGs Security Management Infrastructure (SMI) project

4 31 December 2013 Security Classification Some aspects of the CIPHER Programme are classified up to TOP SECRET (STRAP) This presentation is limited to UNCLASSIFIED material and therefore there may be areas of interest that cannot be covered and questions that cannot be answered

5 31 December 2013 Scope of CIPHER CIPHER Single Statement of User Need (SSUN): A capability that provides a management infrastructure for all grades of devices to meet the needs of UK MOD and wider government, and high grade cryptographic devices for UK MOD to meet the communication, confidentiality, availability, interoperability and data integrity needs of UK MOD for NEC, Defence Business and Operations This means CIPHER must provide: All High Grade cryptographic services for UK MoD IA Service levels to meet the needs of the UK MoD for Defence Business & Operations A pan-Government Security Management Infrastructure that will allow future IA components (e.g. firewalls, cryptographic functions and authentication services) to be initialised, configured, updated, and managed in a trusted & secure way

6 31 December 2013 INTRODUCTION Mr Mike DUFFY – Thales CIPHER Team – Methods & Tools Manager

7 31 December 2013 Thales View of CIPHER. VISION: A single information assured architecture MISSION: To deliver assurance to a secure and coherent information infrastructure at minimum whole-life cost while maintaining continuity of service to other CIPHER stakeholders

8 31 December 2013 An Integrated Reference Model of Information Assurance IA comprises Components of Capability IA Capability is more than just technical products assembled according to System Engineering principles. It is about a Life-cycle that continuously integrates all Enterprise Components to match levels of assurance to the value of the information being protected No distinction between High-grade and Baseline IA as both levels encompass all IA Components of Capability. Only difference is the relative mix of Service and Enterprise Components to achieve the required level of Assurance

9 31 December 2013 The Starting Point - The Options Space to be explored Phase A – Defines and Assesses 12 Options Phase B – Defines 4 Refined Options ( Rank + Blend + Distil) Phase C – Assesses 4 Refined Options

10 31 December 2013 Dealing with Complexity Given the complexity and multi-disciplinary nature of defining, assessing and comparing diverse options requires an innovative but structured approach to Options Assessment The Thales Concept of Analysis employs: Reference Models covering all aspects of IA to ensure consistency between Options Enterprise Architecture to help structure and analyse Options using: MODAF rules for developing EA products to represent Options TOGAF to provide robust EA development environment Soft Systems Methodology to provide Conceptual Frameworks to aid understanding of the problem space COEIA based approach to determine Cost-Benefit ranking of Options and to support CIPHER Main Gate Business Case

11 31 December 2013 Reference Models to Define, Tune & Assess Options

12 31 December 2013 A Generic Enterprise Capability Reference Model

13 31 December 2013 Use of MODAF Views in CIPHER Assessment Phase Phase A avoids solutioneering by generating logical Views of Options Phase C to produce Views required for Delivery & Through-Life Support

14 31 December 2013 Soft Systems Methodology – Conceptual Enterprise Model SSM uses a Generic Enterprise Reference Model and a set of Root Definitions (i.e. Statements of Purpose) as the basis for developing a Conceptual Activity Model of WHAT an Enterprise should be doing Thales regards SSM Root Definition = MODAF StV-1 (Enterprise Vision)

15 31 December 2013 CIPHER Phase A - Sources of Thales Generated EA Views EA View View NameSource of EA View AV-1Overview Thales IA Blueprint – Eco System View (strategic depiction of the IA environment) StV-1Enterprise Vision Statement of Purpose (SSM Root Definition) StV-4Capability Dependencies Sub-system relationships (4 x SSM Conceptual Models) Interaction Model relationship of 4 x Conceptual Models OV-2Operational Node Relationship Sub-systems within 4 x SSM Conceptual Models Analysis of CIPHER Interaction Model OV-5Operational Activity Model Activities within 4 x SSM Conceptual Models Activities logically derived by SME analysis using Thales Reference Models (4 in number) OV-6cOperational Event Trace Sub-system dependencies with 4 x SSM Conceptual Models Analysis of Authorities Interaction Model

16 31 December 2013 AV-1 – Overview and Summary Information MODAF (v1.2): AV-1 is usually a structured text that should provide executive-level summary information including assumptions, constraints, and limitations that may affect any architecture-based work programme. The Eco System View: AV-1 should also provide a depiction of the IA environment Thales believes is best achieved by including a structured model of that environment

17 31 December 2013 AV-1: Thales IA Blueprint – Pan Government Eco System

18 31 December 2013 Eco System provides for Dynamic Communities of Interest

19 31 December 2013 StV-1 – Enterprise Vision MODAF (v1.2): The purpose of an StV-1 is to provide a strategic context for the capabilities described in the Architecture. It also provides a high-level scope for the Architecture which is more general than the scenario-based scope defined in OV-1. SSM Root Definition: A structured, Enterprise-level statement of purpose that contains the following explicit components: Customer or beneficiary of Enterprise endeavour Actors who undertake processes within the Enterprise Transformation – the Enterprises primary input/output process Perceptions of purpose likely to shape the Enterprise Owner – the wider system decision-maker (or Chief Exec) Environmental factors likely to constrain the Enterprise

20 31 December 2013 StV-4 – Capability Dependencies MODAF (V1.2) – The purpose of StV-4 is to describe the dependencies between planned capabilities and defines logical groupings of capabilities (Capability Clusters) SSM Enterprise Model (conceptual) - comprises a set of interdependent sub-systems where each sub-system: Is made up of a group of interdependent activities Represents a component of Enterprise Capability Has a boundary determined by control system theory

21 31 December 2013 IA Sector Enterprise Dependency Model (StV-4) StV-4 = SSM derived Model presented at sub-system level Activity aspect within sub-systems provides basis for OV-5 Views Sub-systems also form basis for MODAF enterprise nodes (OV-2) There are currently 5 of these Reference Models: IA Authority IA Sector (producer) IA Delivery Defence (User) OGD (Generic User)

22 31 December 2013 CIPHER Interdependency Model The following 4 x Conceptual Activity Models support the analysis of a version of the MODs CIPHER Interdependency Model: IA Sector IA Delivery MOD Generic Government Department (OGD)

23 31 December 2013 Benefits identified in using an EA based approach Identifies relationships between business, information, system and technical aspects of various Options Supports URD (WHAT) analysis and SRD (HOW) development Supports Impact Analysis of IA driven Business Transformation Encourages diverse Stakeholder engagement at all stages Enables rapid WHAT-IF re-scoping of programme boundaries Better understanding of dependencies and environmental constraints Supports a structured and disciplined analysis environment Facilitates coherency & consistency across design and analysis activities Multi-disciplinary communication channel within the team Initiates development of a referencable Through-Life repository Provides an audit trail and supports configuration management BUT…. EA and Reference Models are only tools to support design and analysis – they are NOT a substitute for expertise