MoD Accessibility and Trust: Challenges, Goals and a Success Story

1. MoD Accessibility and Trust:Challenges, Goals anda Success Story Dr Jane Jensen Deputy Head Identity & Privilege Management CIO Information Strategy & Policy 30 September 2009

2. AGENDA • Challenges facing the MoD • Strategic Goals • Enabling Capabilities • Federated Approach • A success story

3. MoD Challenges • Enable collaboration and information sharing with Partners (Allies, Other Government Departments and Industry) • Trusted access to MOD services by Partners • MOD access to external Partner services • Enable a more agile and flexible workforce • Work anywhere, easily, at the user’s convenience • Access to online services by MOD “orphans” • Protect business and personal information • Deliver higher value for money • Shared services • Increased productivity • Reduced support costs

4. Identity and Access Management – Strategic Goals • Provide a federated Identity Management service • Provide common services for attribute-based authentication and authorisation • Establish federation agreements with Partners • Exploit services to realise operational, business and financial benefits

5. Enabling Capabilities • A number of ongoing MOD programmes will provide enabling capabilities to support delivery of the goals: • Defence Multi-Application Smart Card (DMASC) • Defence Public Key Infrastructure (DPKI) • Transglobal Secure collaboration Program (TSCP)

6. Defence Multi-Application Smart Card (DMASC) • Common access card will provide ID, physical access to sites and electronic access to MOD information systems incorporating: • Photograph, service, rank, name, expiry date • Legic chip for physical access • Contact chip containing three assemblies: • EMV - used for Internet access to MOD HR services • PKI - storage of digital certificates • Common PIN policy • Bar code – for possible use in operational location tracking • Unique serial number • Security features 6

7. Defence Public Key Infrastructure (DPKI) • DPKI service will issue certificates to identify an entity (person, role or device) named in the certificate and state what the certificate (and corresponding public key) can be used for • Such uses could include: • Authentication of users to applications and infrastructure • Message signing and/or encryption • Signing and/or encryption of electronic forms, files or contracts • Authentication of infrastructure devices and services such as Routers, Web Servers, Firewalls, VPNs and Directories • Support for auditing and accountability 7

8. TSCP See: www.TSCP.org for more details TSCP is a cooperative forum in which Aerospace and Defence (A&D) companies and government agencies work together to establish and maintain an open standards-based framework for federated collaboration and information sharing UK MOD is founder member 8

9. TSCP - background TSCP A&D Participation Includes: Industry GSA - Government Services Administration US Department Of Defense (DoD) Government UK Ministry Of Defence NL Ministry Of Defense TSCP Government Participation • The Transglobal Secure Collaboration Program (TSCP) • established in 2002 – TSCP is the only government-industry partnership of its kind founded to specifically address and mitigate the risks of compliance, complexity and costs inherent in Programs requiring large-scale, collaborative IT capabilities and • address Aerospace & Defense’s (A&D) • security issues that span national • boundaries. TSCP Governance Board • TSCP members represent a sizable • consumer community. • TSCP members combine their need • for standards-based solutions with their • buying power to influence vendors to • address TSCP identity and security • requirements. • Example: Microsoft, now working with TSCP, is addressing an authentication gap in their product in an upcoming release. Individual companies had not been successful in obtaining this change TSCP Support Team TSCP Provides a Unique ‘Industry / Government’ Working Together Forum 9 9

10. Federated Approach - Layers Authentication Gateway and Connectivity Authorisation Applications Who are they? Are they allowed in? What are they allowed to do? The services and applications Intranet Browsing, HR Systems, MoD apps, Collaborative apps Logon Password or smartcard Audit Access control Audit Policy control 10

11. Identity and Access Management - User Types • Internal users: • MoD or Partner user on MOD system • External users on RLI*: • MoD or Partner user on non-MOD system connected to RLI • External users not on RLI • MOD “Orphans” • Partners on non-MoD system without RLI link • Non-users: • The rest of the world, including the bad guys who must be kept out * RLI – MOD RESTRICTED LAN Interconnect network

12. Federated Approach – Incremental Delivery • Small steps to the full Federated Collaboration environment to: • Achieve early benefits • Exploit services as they become available • Manage risks • Progressively add services: • User Authentication: • Accept tokens from Trusted Partners • Provide MoD Authentication Service • Authorisation: • Use claims (trusted user attributes) to control access

13. Federated Approach (1 of 5) Boundary RLI Services 7 Non-MoD RLI Intranet non-Restricted 2 Intranet non-Restricted Users from claims-aware systems White list checker AUDIT 4 Claims / Tokens HTTPGateway Service Users from non-claims systems 1 Intranet Restricted sites 3 6 Logon ServiceUsername / password Access and Policy control point • Federation requires a token • From claims aware system • Or from Logon service • If requesting access to white list, passed through to controlled set of sites • If a different access is requested, Access policyis checked (does claim include “MoD User”) • Access to other sites may be granted • ALL accesses can be audited 5 HR Apps 6 AUTHENTICATION AUTHORISATION ACCESS

14. Federated Approach (2 of 5) Boundary RLI Services Non-MoD RLI Intranet non-Restricted Intranet non-Restricted Users from claims-aware systems White list checker AUDIT Claims / Tokens HTTPGateway Service Users from non-claims systems Intranet Restricted sites Logon ServiceUsername / password Access and Policy control point HR Apps • Can now use Access and Policycontrol point to grant or deny access, e.g. • Non-MOD user: to some Restricted sites • MoD user: Not to all sites • NOTE: BLUE arrows are added

15. 1 – MoD User wanting HR environment 2 - Authenticates to Gov Gateway 3 – Federated access provided (given valid claim from 2-factor card) 4 - to (REDACTED) HR Apps 5 – or other sites. Federated Approach (3 of 5) Boundary RLI Services % Non-MoD RLI Intranet non-Restricted Intranet non-Restricted Users from claims-aware systems White list checker AUDIT Claims / Tokens HTTP Gateway Service Users from non-claims systems 5 Intranet Restricted sites 3 5 Logon ServiceUsername / password Access and Policy control point HR Apps 4 MOD Usersfrom outside RLI 2 Gov Gatewayauthentication 1

16. 1 – Access policy for collaboration says “redirect to CWE” 2 – If claim matches user of CWE 3 – Allowed through 4 – Many CWE users will be from outside RLI either with claims, or needing to login Federated Approach (4 of 5) Boundary RLI Services Non-MoD RLI Intranet non-Restricted Intranet non-Restricted Users from claims-aware systems White list checker AUDIT Claims / Tokens HTTP Gateway Service Users from non-claims systems Intranet Restricted sites 1 Logon ServiceUsername / password Non-MOD Users from outside RLI Access and Policy control point 4 HR Apps MOD Usersfrom outside RLI Gov Gatewayauthentication CWE CollaborationService Collaboration apps 2 3

17. Federated Approach (5 of 5) IndustryApplications Boundary RLI Services MoD Users with claims Non-MoD RLI Intranet non-Restricted Intranet non-Restricted Users from claims-aware systems White list checker AUDIT Claims / Tokens HTTP Gateway Service Users from non-claims systems Intranet Restricted sites Logon ServiceUsername / password Non-MOD Users from outside RLI Access and Policy control point HR Apps MOD Usersfrom outside RLI Gov Gatewayauthentication CWE CollaborationService Collaboration apps

18. Trusted external access to MoD Services Industry Integration IntegrateIASS Control access Claims and Tokens • Full Claims and Federated Identity Environment • Allow access to Industry applications Gateway replacement • Provide tokens from other IdPs • IASS expansion / CWE • Allow access from Internet • Use claims to control access • Build policy to protect data • Accept tokens/claims • Logon as a service • Gateway on another box • White list access • Username / password ?2009 2010 2011 2012 2013?

19. Internet Access Shared Service (IASS):A Success story • Implemented to enable MOD “orphans” to access online HR services • Requirements: • Only access and display certain information (sensitive HR data to be redacted) • Look like normal application (simple user training) • No changes to original applications (cost saving) • Leave no trace on the client device (no download) • 2-Factor authentication (e.g. Smart card, without a PC attached reader) • Authenticate at Government Gateway

20. Security requirement – security in depth

21. IASS – Access and Authorisation RLI GSI http://mod.uk HR Apps HR Apps Government Gateway IAG IAG 1 3 DECS 4 RLI Access Internet Access 2 AD Front End Portal RLI ISA 5 Connectivity Protected Network - ISA 6

22. Thank You • Challenges facing the MoD • Similar to many other organisations • Emphasis on Security • Goals: Coherent Approach to • Federated Identity • Attribute based authentication • Enabling Capabilities • Secure authentication – Smart cards • Secure use of certificates for attributes – PKI • Secure collaboration standards - TSCP • A success story • Short term, reachable steps • Helps to demonstrate the strategy is working