e-Government framework for Information Assurance

Central Sponsor for Information Assurance e-Government framework for Information Assurance Draft 5.1, December 2006 e-Government framework for Information Assurance Draft 5.1 Page 1 Document history Version Version 1.0 Version 2.0 Date of issue March 2000 November 2001 Reason for issue First issue Revised issue to reflect minor changes in the security framework documents. A variant version (Version 3.0) was issued with the 2001 version of MPS, including a revision to the threats. Revised issue to take into account comments received from public consultation and to resolve inconsistencies between V2.0 and V3.0. Revised issue for public consultation, following broad stakeholder consultation and a refresh of previous e-Government security policy and guidance. Authority CITU Office of the e-Envoy Version 4.0 September 2002 Office of the e-Envoy Draft 5.1 December 2006 CSIA This document replaces the policy and guidance on security as set out in the e-Government strategy framework document, security, Version 4.0, September 2002. This document also replaces the following e-Government strategy framework documents which support the overarching security document: • • • • • • • registration and authentication, Version 3.0, September 2002; assurance, Version 2.0, September 2002; business services, Version 2.0, September 2002; trust services, Version 3.0, September 2002; confidentiality, Version 3.0, September 2002; network defence, Version 2.0, September 2002; security architecture, Version 2.0, September 2002. Page 2 Document history This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 3 Contents Document history .....................................................................................1 Contents ....................................................................................................3 List of abbreviations ................................................................................7 1 Introduction .........................................................................................9 1.1 Purpose......................................................................................9 1.2 Scope .........................................................................................9 1.3 Transitional arrangements .......................................................11 1.4 Third-party participation ...........................................................12 1.5 Ownership and maintenance ...................................................12 1.6 Glossary ...................................................................................12 1.7 Availability of further support and advice .................................12 1.8 Document overview..................................................................13 2 How to use this document ...............................................................15 2.1 Introduction ..............................................................................15 2.2 Risk assessment method .........................................................17 3 Risk management and accreditation...............................................25 3.1 General ....................................................................................25 3.2 Risk ownership.........................................................................26 3.3 IA policy....................................................................................28 3.4 Service delivery........................................................................30 3.5 Compliance ..............................................................................32 4 Service provision environment .......................................................35 4.1 General ....................................................................................35 4.2 Service provision environment .................................................35 4.3 Data protection.........................................................................38 5 Identity registration ..........................................................................41 5.1 Overview ..................................................................................41 5.2 Identity registration process .....................................................41 5.3 Impact level for identity registration..........................................42 5.4 Threats .....................................................................................44 5.5 General requirements ..............................................................45 5.6 Registration countermeasures .................................................47 6 Client enrolment to a service ...........................................................51 6.1 Overview ..................................................................................51 6.2 Enrolment process ...................................................................51 Page 4 Contents 6.3 6.4 6.5 6.6 Impact level for enrolment ....................................................... 52 Threats .................................................................................... 53 General requirements.............................................................. 53 Enrolment countermeasures ................................................... 56 7 Authentication and client access.................................................... 59 7.1 Overview.................................................................................. 59 7.2 Authentication process ............................................................ 59 7.3 Impact level for authentication................................................. 60 7.4 Threats .................................................................................... 61 7.5 General requirements.............................................................. 61 7.6 Authentication countermeasures ............................................. 64 8 Confidentiality .................................................................................. 67 8.1 Overview.................................................................................. 67 8.2 Impact level for confidentiality ................................................. 67 8.3 Use of protective markings and descriptors ............................ 68 8.4 Threats .................................................................................... 68 8.5 General requirements.............................................................. 69 8.6 Confidentiality IL0 countermeasures ....................................... 69 8.7 Confidentiality IL1 countermeasures ....................................... 70 8.8 Confidentiality IL2 countermeasures ....................................... 73 8.9 Confidentiality IL3 countermeasures ....................................... 75 9 Integrity ............................................................................................. 79 9.1 Overview.................................................................................. 79 9.2 Impact level for integrity........................................................... 79 9.3 Threats .................................................................................... 80 9.4 General requirements.............................................................. 80 9.5 Integrity IL0 countermeasures ................................................. 82 9.6 Integrity IL1 countermeasures ................................................. 83 9.7 Integrity IL2 countermeasures ................................................. 84 9.8 Integrity IL3 countermeasures ................................................. 84 10 Availability ........................................................................................ 87 10.1 Overview.................................................................................. 87 10.2 Impact level for availability....................................................... 87 10.3 Threats .................................................................................... 87 10.4 General requirements.............................................................. 88 10.5 Availability IL0 countermeasures............................................. 88 10.6 Availability IL1 countermeasures............................................. 88 10.7 Availability IL2 countermeasures............................................. 90 10.8 Availability IL3 countermeasures............................................. 91 e-Government framework for Information Assurance Draft 5.1 Page 5 11 Worked examples .............................................................................95 11.1 General ....................................................................................95 11.2 Hypothetical pseudonymous medical screening service......................................................................................95 11.3 Hypothetical tax return service...............................................101 11.4 Hypothetical disabled parking permit service.........................109 A Glossary...........................................................................................117 A.1 General ..................................................................................117 A.2 Glossary .................................................................................117 B Related policy and guidance .........................................................133 B.1 Identity management..............................................................133 B.2 UK government guidance for IA .............................................133 B.3 International guidance for IA ..................................................133 B.4 Relevant legislation ................................................................135 C Service provision levels .................................................................137 D HMG Impact Table...........................................................................139 D.1 Impact level definitions...........................................................139 D.2 Impact Table extracts.............................................................139 E Identity registration examples .......................................................143 E.1 General ..................................................................................143 E.2 Registration IL1 examples......................................................143 E.3 Registration IL2 examples......................................................144 E.4 Registration IL3 examples......................................................145 Page 6 Contents This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 7 List of abbreviations ALARM BS CA CAPS CC CCT Mark CIFAS CIRT CLAS CNI CO (SPD) CRL CSIA DLA DoS DPA DTI DWP EDRMS EID EIF ENISA FCO GSi HMG IS1 HMG IS2 HO HTTP(s) IA IAPC IDABC ILx IPR Association of Local Authority Risk Managers Baseline Standard Certification Authority CESG Assisted Products Scheme Common Criteria CSIA Claims Tested Mark Credit Industry Fraud Avoidance System Computer Incident Response Team CESG Listed Advisor Scheme Critical National Infrastructure Cabinet Office (Security Policy Division) Certificate Revocation List Central Sponsor for Information Assurance Disability Living Allowance Denial of Service Data Protection Act Department of Trade and Industry Department for Work and Pensions Electronic Document and Record Management System European Identity Management (Programme) European Interoperability Framework European Network and IS Agency Foreign and Commonwealth Office Government Secure Intranet HMG Infosec Standard No.1: (Part 1: risk assessment, Part 2: risk treatment) HMG Infosec Standard No. 2: risk management and accreditation Home Office Hypertext Transfer Protocol (secure) Information Assurance Information Assurance Policy Committee Interoperable Delivery of European e-Government Services to public Administrators, Businesses and Citizens Impact Level x Intellectual Property Rights Page 8 List of abbreviations IPS IS ISM ISO ITSEC MPS NINO NISCC NIST OGC OGD PDCA PIN PKI RA RMADS SIRO SLA SRO SSL S/MIME SyOps TCP/IP TLS ToE TTP UPS VbV VPN Identity and Passport Service Information System Interconnection Security Measures International Organisation for Standardisation IT Security Evaluation and Certification Scheme Manual of Protective Security National Insurance Number National Infrastructure Security Coordination Centre (American) National Institute of Standards and Technology Office of Government Commerce Other Government Department Plan-Do-Check-Act Personal Identification Number Public Key Infrastructure Registration Authority Risk Management and Accreditation Document Set Senior Information Risk Owner Service Level Agreement Senior Responsible Owner Secure Sockets Layer Secure / Multipurpose Internet Mail Extensions Security Operating Procedures Transmission Control Protocol / Internet Protocol Transport Layer Security Target of Evaluation Trusted Third Party Uninterruptible Power Supply Verified by Visa Virtual Private Network e-Government framework for Information Assurance Draft 5.1 Page 9 1 1.1 1.1.1 Introduction Purpose This document provides an Information Assurance (IA) policy and guidance framework for e-Government services, 1 setting out a method to assure the confidentiality, integrity and availability of information assets and to ensure the correct working of an e-Government service. Special consideration is given to the identity registration, enrolment and authentication processes which underpin access control by clients. Use of this document and application of the policy and guidance that it contains will: • enable an appropriate level of IA, supporting reliability and efficiency and promoting public confidence in e-Government services, with a corresponding positive impact in the overall public perception of central and local government; • promote trust between service providers and enable the advantages that information-sharing and rationalisation of effort will deliver; • protect the private information of citizens and organisations, easing the path to compliance with the Data Protection Act (DPA) 2 and other relevant legal instruments. 3 1.1.2 1.2 Scope General 1.2.1 The scope of this document covers the IA aspects of the development, procurement, provision and maintenance of e-Government services, and of electronic transactions between government and its clients that are enabled using these services. Use of this guidance across government 1.2.2 This document covers e-Government service provision by, or on behalf of: • central government departments and their supporting agencies; • non-departmental public sector bodies; • local authorities 4 and other public sector bodies; 1 An e-Government service is a service that is provided by government or agents of government, to members of the public, delegates or voluntary sector organisations, which is supported by transactions via an electronic delivery channel such as the internet. The DPA and the eight data protection principles that underpin it are summarised at Section 4.3. See Annex B for a further discussion of relevant legislation. This includes local authorities at a number of levels including county councils, borough and district councils and other local government organisations such as Local Education Authorities (LEAs). 2 3 4 Page 10 Introduction • security authorities charged with assessing the suitability of offered solutions for e-Government service provision and accreditation of these solutions for operational use. 1.2.3 Use of this guidance is not mandatory, but lack of consistency with other e-Government services would contradict the principles of Transformational Government, which promotes a shared-services approach to delivery of coordinated services. Failure to apply the best practice measures set out herein would weigh heavily against a service provider in the event of an inquiry. Use by third parties in support of e-Government service provision 1.2.4 This document should be used by those who support e-Government service provision, such as: • suppliers and service providers who provide and/or operate e-Government services or who provide equipment in support of e-Government services; • bodies responsible for the proper audit and control of public assets and information; 5 • trust service providers such as Registration Authorities (RAs) and providers of independent regulatory/approvals schemes such as tScheme 6 (or equivalent) who approve trust services for e-Government services; • external advisors who provide support for the development and accreditation of e-Government services. 7 Offline service provision 1.2.5 Those charged with the development of offline methods of government service provision to the public (such as telephone and postal applications) may wish to use this document in an advisory capacity, in conjunction with other relevant advice and guidance. For example, this document might be useful to support identification of the required level of assurance for offline processes, and to help determine an appropriate set of countermeasures. Clients 1.2.6 It is not generally possible to assure client machines and networks, and ensuring awareness and best practice by clients of e-Government services is not straightforward. Clients should be provided with or directed to suitable 5 This might include, for example, the Electoral Commission as the independent regulatory body responsible for overseeing some aspects of the accreditation for the Department for Constitutional Affairs (DCA) e-Voting initiative. Further information on tScheme may be found at http://www.tscheme.org. This includes CESG Listed Advisor Scheme (CLAS) consultants and other consultants employed to support the development and/or accreditation of e-Government services, as well as advisory bodies such as the Association of Local Area Risk Managers (ALARM) which provide support for development and accreditation activities. 6 7 e-Government framework for Information Assurance Draft 5.1 Page 11 guidance on the steps that they should take to protect their machines from online threats. Basic measures that all home users and organisations should take to protect their computers are set out at http://www.getsafeonline.org. Internal-facing information systems 1.2.7 Assurance of internal-facing 8 government information systems is beyond the scope of this document. The reader is referred to the policy and guidance set out within MPS where applicable. Service providers for internal-facing systems may use this document in addition to MPS as best practice guidance. It should be noted that under these circumstances MPS takes precedence. Contact details for those wishing to request a copy of MPS are provided at Section 1.7 of this document. Transitional arrangements General 1.3.1 The policy and guidance that is set out within this document represents a significant revision of the previous e-Government security framework. The transitional arrangements to be adopted are set out below. New e-Government services 1.3.2 New services are defined here as those services where the relevant projects or programmes are initiated after the date of publication of Version 6.0 of this document. 9 New e-Government services shall be developed in accordance with the policy and guidance that is set out within this document, with immediate effect. Legacy e-Government services 1.3.4 Legacy services are defined here as those services where the relevant projects or programmes were initiated before the date of publication of Version 6.0 of this document. For legacy services, the policy and guidance as set out within this document will be adopted wherever practicable. Where service design and specification have already been implemented in accordance with the September 2002 e-Government security framework documents, it is not necessary to reassess these services until they are upgraded or the accreditation environment changes. The current version of the guidance will be adopted from that point onwards. 1.3 1.3.3 1.3.5 1.3.6 8 9 Internal-facing systems will include, for example, information systems that support interdepartmental interactions and those for use by public-sector workers. Version 6.0 of this document will be the first issue version of the document following public consultation. Page 12 Introduction 1.4 Third-party participation Provision of trust services by third parties 1.4.1 Government continues to encourage the provision of trust services by a variety of bodies, including local authorities and the private sector, and will make more use of these services where possible. Government recognises the continuing importance of the tScheme, and equivalent initiatives, for accreditation of trust service providers and the need to maintain a close working relationship to agree detailed standards for trust services for government transactions. Any third-party providing trust services support to e-Government transactions should normally be approved under a scheme recognised by the UK Government such as tScheme, or equivalent. Third-party service delivery 1.4.2 1.4.3 1.4.4 Government makes clear its intention to work in partnership with local authorities, the voluntary sector, and with third-party delivery channels such as the Post Office and private sector companies. Where third-party service providers are conducting transactions on the government’s behalf, they will be required to provide services to the same standards as government itself would. Government will in turn accept transaction data from those delivery channels, who will certify that they have carried out the transaction to the agreed standard. Ownership and maintenance This draft of the IA policy and guidance for e-Government services (Draft 5.1) has undergone a significant revision following broad stakeholder consultation. This document will be subject to a 3 month public consultation and revised in line with comments received before being raised to issue Version 6.0. Thereafter, this document will be reviewed on an annual basis. Glossary This document includes a detailed glossary, which defines the terms used. The approach we have taken has been, where possible, to avoid the use of contentious terms and to align with the terminology set out by related guidance. Terms that are defined within the glossary are hyperlinked on their first use within the main body of this document. Availability of further support and advice In the first instance, any queries relating to the policy and guidance provided within this document should be directed to the CSIA at: 1.5 1.5.1 1.6 1.6.1 1.7 1.7.1 e-Government framework for Information Assurance Draft 5.1 Page 13 • CSIA, Cabinet Office, 22 Whitehall, London. SW1A 2WH. Email: csia@cabinet-office.x.gsi.gov.uk 1.7.2 Documentation requests for MPS and other supporting documentation, should be addressed to the Cabinet Office (Security Policy Division) (CO (SPD)) at: • CO (SPD), Cabinet Office, 22 Whitehall, London. SW1A 2WH. Email: security.division@cabinet-office.x.gsi.gov.uk 1.7.3 Queries and comments on HMG IS1, HMG IS2 and other CESG guidance should be addressed to CESG at: • CESG Customer Support Office, Hubble Road, Cheltenham, GL51 0EX. Email: enquiries@cesg.gsi.gov.uk 1.7.4 1.7.5 A list of CESG Listed Advisor Scheme (CLAS) consultants is maintained on the CESG web-site, http://www.cesg.gov.uk/site/clas/index.cfm. Further information on the Association of Local Authority Risk Managers (ALARM) may be obtained from their web site, http://www.alarm-uk.com. Document overview The layout of this document is as follows: • Section 2 provides an overview of how to use this document and sets out the five-step methodology that has been adopted; • Section 3 describes the overall approach to risk management and accreditation that should be adopted by those responsible for IA aspects of e-Government service provision, and how the concepts of risk ownership, IA policy, service delivery and compliance checking apply to e-Government services; • Section 4 illustrates the service provision environment and context for e-Government services, setting out the boundaries of the service provision environment, the requirements to protect the service, attack groups and compromise paths, and data protection obligations; • Sections 5-10 discuss each of the service characteristics as defined by this guidance, covering identity registration, enrolment, authentication, confidentiality, integrity and availability; considerations for each of these include estimation of impact levels, the general process, threats and baseline countermeasures that are required and specific countermeasures for a particular level of required assurance; • Section 11 provides worked examples demonstrating the application of the policy and guidance that is set out within this document; • Annex A provides a comprehensive glossary defining the terms used within this document; the approach taken in this guidance has been, where possible, to avoid the use of contentious terms and to align with the terminology set out by related guidance; 1.8 1.8.1 Page 14 Introduction • Annex B contains information on other relevant policy and guidance; • Annex C is a reference to the definitions of the four service provision levels as defined by earlier versions of the e-Government security framework documentation; • Annex D sets out the HMG Impact Table definitions; these are to be used to estimate the impact levels for e-Government service characteristics; • Annex E presents some examples of acceptable remote and online evidence for the identity registration of an individual. e-Government framework for Information Assurance Draft 5.1 Page 15 2 2.1 How to use this document Introduction General 2.1.1 2.1.2 This document forms part of the overall risk management process to be adopted throughout the project lifecycle of an e-Government service. This section introduces the method to be employed for risk assessment and risk treatment, and demonstrates how this method should be applied. The context for the guidance and relevant risk management concepts are also introduced, and the relationship between this document and other government guidance on risk management and IA is discussed. The overall approach to risk management and accreditation is summarised and discussed at Section 3 of this document. Context 2.1.3 2.1.4 e-Government service providers have a requirement to ensure that: • where necessary, a client is who they claim to be, they are eligible for a service they receive, and they are entitled to transact with e-Government services either on their own behalf or on behalf of another; • the confidentiality of the information stored and handled by e-Government services, and any information exchanged between e-Government services, is appropriately protected; • the integrity of the information stored and handled by e-Government services, and the ability to make binding commitments based on this information, is appropriately protected; 10 • e-Government services are available to the communities that they serve, and the service provision domain is protected against electronic attack (both malicious and non-malicious) and non-malicious failure. Relationship with other IA policy and guidance Manual of Protective Security 2.1.5 This document forms part of the wider documentation set that supports the Manual of Protective Security (MPS) and has the status of a stand-alone supplement to the MPS. 10 This requirement also applies in less formal situations where failure to meet informal obligations may incur some cost or inconvenience. Page 16 How to use this document HMG Infosec Standard Number 2 2.1.6 The policy and guidance that is set out within this document follows the risk management approach prescribed by HMG Infosec Standard Number 2 (HMG IS2). 11 This approach to risk management is broadly aligned with ISO and OGC guidance, and adherence will ease the route to ISO 27001 compliance. HMG Infosec Standard Number 1 2.1.7 HMG Infosec Standard Number 1 (HMG IS1) 12,13,14 provides a risk assessment method that focuses on support for information in the high assurance domain. 15 The HMG IS1 method, however, is not designed to support e-Government service provision: • HMG IS1 provides inadequate resolution across the relatively low assurance requirements of most e-Government services; 16 • the range of likely attack groups will tend to be more limited; 17 • HMG IS1 is not client-centric and does not consider the management of client identities or obligations to protect the information of clients under the DPA, the Human Rights Act, and other legal instruments; a related issue is the protection of clients’ information and service provision as a whole in an environment where client machines will be protected to a range of different levels. 2.1.8 The IA policy and guidance provided herein is designed to support the provision of e-Government services and protection of the information assets that are managed by these services. There remains, however, a particular requirement to apply HMG IS1 in addition to this guidance in the following circumstances: • to protect services with a broader range of attack groups and/or IA requirements that are above and beyond those considered here; • where relevant, for the protection of back-end systems. 11 12 13 14 15 16 HMG Infosec Standard Number 2: risk management and accreditation of information systems, dated July 2005. This document may be downloaded from the NISCC web-site, http://www.niscc.gov.uk. HMG Infosec Standard Number 1 Part 1 (Risk Assessment), Draft 1.0 of Issue 3.0, June 2006, NOT PROTECTIVELY MARKED. HMG Infosec Standard Number 1 Part 2 (Risk Treatment), Draft 1.0 of Issue 3.0, June 2006, NOT PROTECTIVELY MARKED. HMG IS1 is currently undergoing a comprehensive review. The new draft documentation replaces the traditional impact-based central government approach to IA with a threat-based approach. Supporting RESTRICTED through to TOP-SECRET information. Ie requirements to support the confidentiality of information assets will typically be at-or-below RESTRICTED, with similar requirements for the integrity and availability of services and information assets For example, with the exception of some central government services and elements of the CNI, many e-Government services are unlikely to be particular targets for terrorists or foreign intelligence services. 17 e-Government framework for Information Assurance Draft 5.1 Page 17 CSIA identity risk management tool 2.1.9 A CSIA e-Government identity risk management tool is under development, to support a standardised approach to identity risk management by supporting the identification of impact levels for registration and authentication, 18 and the countermeasures to be applied. Enquiries relating to this tool should be directed to CSIA via the contact provided at Section 1.7. Infosec manuals and memoranda 2.1.10 In addition to HMG IS2, e-Government services with increased IA requirements may need to implement HMG IS1 directly, along with some of the technical countermeasures that are set out within the Infosec Manuals and Memoranda. National Infrastructure Security Coordination Centre guidance 2.1.11 A range of guidance on the implementation of technical countermeasures to address specific risks is provided by the National Infrastructure Security Coordination Centre (NISCC), and can be found on the NISCC website, http://www.niscc.gov.uk. This guidance is particularly aimed at protecting elements of the Critical National Infrastructure (CNI), but much of the guidance provided represents industry-wide best practice. 2.2 Risk assessment method General 2.2.1 Risk assessment should be conducted at an initial stage in the development lifecycle for e-Government services and developed to an increasing level of detail as service development progresses. Where possible, the Accreditor should be involved early on and throughout the service lifecycle; early feedback will help to inform the development of the service, mitigating risks and potentially reducing development costs. The e-Government IA risk assessment method consists of the following steps as illustrated at Figure 1: 1. define the service in business terms; 2. determine impact levels for each service characteristic; this might require redefinition of some elements of the service; 19 3. apply standard minimum countermeasures; 4. apply service-specific countermeasures; this might require redefinition of some elements of the service; 20 18 19 20 2.2.2 The tool also includes some discussion of enrolment and proof of status. For example, to reduce the value of some of the impact levels. For example, introducing countermeasures. physical, procedural or personnel measures in place of some Page 18 How to use this document 5. agree and document risk management decisions; this might impact on the required countermeasures. RISK ASSESSMENT STEP 1 Define the service STEP 2 Determine impact levels for each service characteristic RISK TREATMENT STEP 3 Apply standard minimum countermeasures STEP 4 Apply transaction-specific countermeasures STEP 5 Agree, document and implement risk management decisions Figure 1: IA risk assessment method for e-Government service provision 2.2.3 The risk assessment method is described below. Section 11 provides worked examples to demonstrate how this method should be applied. STEP 1: define the service 2.2.4 In order to determine IA risks and requirements, there is a requirement to first define the e-Government service in business terms. This might require consideration of, for example: • the client requirements from the service and the range of functions that will need to be performed in support of this service; • the service requirements from the client. This might, for example, include the need to establish a client’s identity, and requirements for nonrepudiation, evidence of receipt and trusted commitment services; • the individuals that will be responsible for the service and its information assets, including the Senior Responsible Owner (SRO), the Senior Information Risk Owner (SIRO) and other responsible individuals; 21 21 Risk ownership is discussed further at Section 3.2. e-Government framework for Information Assurance Draft 5.1 Page 19 • definition of the service provision environment, considering: − − − − the information assets in the system; the assumptions that can be made about the service; the boundaries of the service; the external connections and other third-party interaction required; this includes consideration of information exchange requirements, prerequisites for each connection, balance-of-responsibility for management, etc; the likely attack groups and what compromise paths they might exploit; the transactions that will support the collection, processing, exchange, storage and disposal of information; the delivery mechanisms required to support different elements of the service (eg internet, telephone, text, post, etc) and the access mechanisms that will be employed (eg government gateway); service delivery and the potential for outsourcing elements of service provision. − − − − 2.2.5 A generic service provision model, likely attack groups and potential compromise paths are discussed at Section 4 of this document. STEP 2: determine impact levels for each service characteristic 2.2.6 Six service characteristics are defined for e-Government services, covering confidentiality, integrity, availability, identity registration, enrolment and client authentication. 22 These are listed at Table 1. Sections 5-10 provide a more detailed definition of each of these service characteristics. 22 In principle, identity registration, enrolment and client authentication are aspects of confidentiality, integrity and availability. In practice, these three service characteristics are of specific relevance for e-Government service provision and merit separate discussion. Page 20 How to use this document Service characteristic Identity registration Description the level of confidence in a client’s asserted real-world identity (cases of anonymity or pseudonymous registration of identity are allowed) the level of confidence in the eligibility of a registered client to sign up for and receive an e-Government service the level of confidence in an electronic identity presented to a service provider or to a client by means of a credential the impact of unauthorised observation and disclosure of private information the correctness of information and the ability of clients and government users to act on that information the accessibility of information stores and the ability of clients to transact with government users via an e-Government service Relevant section of document Section 5 Enrolment 23 Section 6 Client authentication Section 7 Confidentiality Integrity Section 8 Section 9 Availability Section 10 Table 1: service characteristics 2.2.7 For each transaction to be conducted, an impact level should be assigned for each of the six service characteristics defined above. Each service characteristic will, in general, attract a different impact level. The distinction between information assets and transactions must be noted. Identity registration, enrolment and authentication are mechanisms which support the transactions by which information assets are managed, rather than the information assets themselves. As such, although each transaction will attract an impact level for each service characteristic as set out at Table 1, information assets themselves will only attract impact levels for confidentiality, integrity and availability. Considerations during the assignment of impact levels are as follows: • four impact levels are defined, ranging from Impact Level 0 (IL0) to Impact Level 3 (IL3); these impact levels are defined by the HMG Impact Table, which is reproduced in part at Annex D of this document and provides a means by which to value 24 the transactions and information assets that support a service; • some transactions or information assets will attract impact levels in excess of IL3 for one or more service characteristics, so that the full HMG Impact Table 25 must be consulted; in these cases, HMG IS1 should be applied to 2.2.8 2.2.9 23 24 25 The use of the term “enrolment” as defined here should not be confused with the HO / IPS definition, which relates specifically to biometrics. Readers should note that value, as defined here, does not necessarily refer to monetary value. This is to be produced by CSIA as a stand-alone document. e-Government framework for Information Assurance Draft 5.1 Page 21 determine appropriate countermeasures in addition to those in this document; • allocation of impact levels will require consideration of all direct and indirect consequences laid out in the definition of the levels, allocating the highest of these to the transaction; it is unlikely that all of the definitions in the Impact Table will be relevant for each service characteristic; 2.2.10 After assigning impact levels for a particular transaction within a service, the service provider will need to determine how to deliver the functionality of the service. It might be most appropriate to assign a set of impact levels for each transaction, and to register, enrol and/or authenticate clients at different levels of assurance depending on the range of transactions that they wish to perform. Alternatively, it might be most convenient to define a single set of impact levels for all transactions within the entire service. STEP 3: apply standard minimum countermeasures 2.2.11 This document defines a standard set of minimum countermeasures to be implemented by all e-Government services in support of each of registration, enrolment, authentication, confidentiality, integrity and availability. These countermeasures are set out in the relevant sections of the document (Section 6 to Section 10 respectively). 2.2.12 Service providers should also implement the standard countermeasures specified by HMG IS1, which include: minimum • undertaking risk management and accreditation in accordance with HMG IS2, and set out in part at Section 3 of this document; • producing system operating procedures; • producing a patching policy (to define how and when operating system service packs and security patches will be applied); • using anti-virus software; • implementing MPS for protectively marked material; • all e-Government services wishing to comply with the ISO 27000 series should implement the controls listed in the ISO 17799 Code of Practice. 2.2.13 In addition, government has a responsibility to provide support for clients, which, as a minimum should include: • directing clients to suitable guidance on the steps that they should take to protect their computer from online threats and of the risks of using unsecured machines; basic measures that all home users and organisations should take to protect their computers are set out at http://www.getsafeonline.org; • informing clients of their general responsibilities to protect any logon credentials that they are issued with and of the potential implications of disclosure; Page 22 How to use this document • informing clients of any specific instructions relating to the issue of credentials (especially tokens or other devices); these may, for example, be accountable and/or have special handling instructions which must be notified to the client. STEP 4: apply transaction-specific countermeasures 2.2.14 This document defines the level of countermeasures that are required, 26 depending on the identified impacts for each of registration, enrolment, authentication, confidentiality, integrity and availability. Some of these are determined by the identified impact level and others will depend on specific requirements of the transaction (eg in support of a requirement for nonrepudiation, evidence of receipt or trusted commitment services). 2.2.15 The choice of countermeasures must be considered in terms of risk to the service as a whole, cost of implementation, practicality and overall business benefit. The SIRO may choose not to implement some transaction-specific countermeasures where it is determined that these cannot be adequately supported but there is an overwhelming business need for the service. 2.2.16 In these cases, the countermeasures that are not met and the reasoning behind this must be clearly documented in the Risk Management and Accreditation Document Set (RMADS) for the service. 27 Residual risks should be mitigated, where possible, through the application of appropriate procedural, physical and personnel measures. Important factors in determining the appropriate risk level include the the residual risk that the risk owner is prepared to accept, and prerequisite requirements for any envisaged onward connections. Support and advice from technical experts is essential to properly inform risk-balance decisions. STEP 5: agree, document and implement risk management decisions 2.2.17 All decisions related to risk assessment and risk management must be clearly documented in a RMADS. This should include: • an asset register detailing information assets and their impact levels; • a comprehensive list of transactions and their impact levels; • a prioritised risk register, supported by a risk treatment plan; • details of through-life management for IA and the IA review process; • details of the acceptance processes for clients and government users; 26 27 Details of the precise countermeasures to be applied must be determined on a service-by-service basis at an appropriate level of detail, as determined by this guidance. The level of detail required within the RMADS will depend on the impact of the service. For example, for an e-Government service whose service characteristics are mostly IL1, an outline RMADS would generally be sufficient. However, for an e-Government service whose service characteristics are mostly IL3, a greater level of detail would generally be required to support the implementation and management of IA for the service. e-Government framework for Information Assurance Draft 5.1 Page 23 • a map of external connections and information-flow requirements; • a list of countermeasures that have been implemented and any exceptions made; • procedures to ensure secure decommissioning and transfer or disposal of information assets. 2.2.18 Prior to roll-out of an e-Government service, the service provider must consider how the required level of IA will be delivered. This might include developing a clearly documented policy on what compromises and losses are and are not acceptable (these might not necessarily be limited to financial losses), how to monitor such losses and what exception-handling procedures should be used to respond to compromise, minimise loss, and improve the service. This may include the development and implementation of a liability model. Considerations might include, for example, ensuring that third-parties are subject to contractual bindings and are incentivised through transferral or sharing of risk where possible. Measures for audit and accounting, and any other activities that may be reasonably employed to monitor, record and analyse incidences of compromise or potential compromise must be put into place. Measures to protect the service and its information assets must be supported by continual regular review of IA procedures and appropriate mechanisms for exceptional review of IA procedures in the event of urgent unforeseen circumstances. As such, the RMADS should be treated as a “living” document and will require regular scheduled reviews and change-management. Changes to the RMADS should be agreed and endorsed by all stakeholders and should be reflected by training as appropriate. 2.2.19 Page 24 How to use this document This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 25 3 3.1 3.1.1 3.1.2 Risk management and accreditation General This section sets out the approach to risk management and accreditation to be adopted in support of e-Government service provision. The HMG IS2 28 approach to risk management has been adopted. This approach is broadly aligned with ISO and OGC guidance on risk management. Adherence will help an organisation to demonstrate compliance with the ISO 27000 series of documents, and ease the route to ISO 27001 compliance. It is anticipated that this document will be used in conjunction with HMG IS2. As such, we have not repeated the guidance contained in HMG IS2, but concentrate on how to tailor this approach to support e-Government service delivery. The overall risk management approach is set out at Figure 2. This approach is built around four main topics covering risk ownership, IA policy, service delivery and compliance checking. Risk ownership Information risk ownership (management) Information risk ownership (users) 3.1.3 3.1.4 IA policy Risk assessment Risk treatment Security management Service delivery IA aspects of project management IA aspects of asset management Third-party interactions Compliance checking Accreditation Evaluation/Testing Inspection/Auditing Figure 2: risk management functions 28 HMG Infosec Standard Number 2: risk management and accreditation of information systems, dated July 2005. This document may be downloaded from the NISCC web-site, http://www.niscc.gov.uk. Page 26 Risk management and accreditation 3.2 Risk ownership General 3.2.1 Overall responsibility for the protection of information assets that are supported by an e-Government service lies with the SIRO for that service. This does not diminish the individual responsibilities of users of a service and those responsible for managing that service. A number of key roles are set out below. Senior Information Risk Owner 3.2.2 The SIRO is an individual identified within each department as being responsible for information risks and for influencing the board in managing these risks properly. For e-Government services that are delivered by or on behalf of central government organisations, the SIRO will be a senior business manager, who works in conjunction with the service provider (who may or may not belong to the same organisation) and the Accreditor to select, implement and assure security measures for the service. This model represents best practice for those developing e-Government services. Accreditor 3.2.3 3.2.4 An accreditor is the individual responsible for conducting the formal assessment of an information system or a set of capabilities and for advising the SIRO on the risks to information assets. Responsibility for accreditation of services within a department rests with the departmental accreditor. Responsibility for accrediting services which span several departments rests with the pan-government accreditor. 29 The primary responsibility of the SIRO is to deliver a service which has an appropriate level of capability to support clients’ needs, whereas the Accreditor has to be aware of the potential IA pitfalls which a service might encounter and ensure that these have been addressed to an appropriate level of assurance. Maintaining the correct balance of the tension that tends to result between the SIRO and the Accreditor is essential to obtain the optimum risk balance for the service. Service provider 3.2.5 3.2.6 3.2.7 A service provider is an organisation responsible for the provision of a specific e-Government service. The service provider might merely operate the service using its own or government-owned equipment, or it might design and develop the service. 29 The role of the pan-government accreditor is due for review over the next year. e-Government framework for Information Assurance Draft 5.1 Page 27 3.2.8 The service provider must ensure that the service and relevant systems are compliant with the e-government security framework, as required by the SIRO and in conjunction with the Accreditor. Government users 3.2.9 A government user in this context denotes a person or process that interacts with an e-Government service (in any capacity) from within the e-Government service provision boundary; this includes third parties involved in the provision of e-Government services. Appropriate measures must be put into place (training, awareness, etc) to ensure that government users are familiar with corporate security and IA policies, and to ensure that they have read and understood the security policies and guidance specific to the service. Clients 3.2.10 3.2.11 The term client is used here to denote a person or organisation, a delegate of a person or organisation, or an element of another service seeking to carry out a transaction using an e-Government service. Clients are responsible for protecting information on their own computers and networks, and for their end of any transactions undertaken with government. Ensuring awareness and best practice by clients of e-Government services is not straightforward. Different clients will use a range of different hardware and software platforms, with a wide range of different (and evolving) configurations. In addition, some client systems may have been compromised by malicious individuals, so that there is a requirement for appropriate measures to be in place to protect the e-Government service and to support users in protecting their own systems. 3.2.12 3.2.13 It may be necessary to require clients to install standard commercial security products as a pre-requisite to accessing some e-Government services. 30 However, any requirement for a client to install custom software to access e-Government services should be avoided. 3.2.14 Appropriate measures must be in place within the e-Government service provision boundary to protect a client’s information on their behalf. It should be noted, however, that a client might be prepared to accept a higher level of residual risk than the service provider regarding their information, or may have a different assessment of the impact that compromise of that information might have. This should not prevent the service provider from providing clients with information that is held about them. For example, assignment of Confidentiality IL3 to a client’s medical records should not prevent the e-Government service provider from enabling access to this information (even if this requires the use of out-of-band methods). 30 For example, ensuring that the client upgrades to a web browser with an up-to-date version of the Secure Sockets Layer (SSL) protocol prior to use of the service. Page 28 Risk management and accreditation Delegates 3.2.15 A delegate (also referred to as a proxy) is an intermediary that has been authorised to conduct a specified set or range of transactions on behalf of an e-Government client. This might include, for example, an accountant or other professional acting on behalf of a specified person or organisation, a legal guardian, or a person acting under a power of attorney on behalf of a relative or patient. In some cases a delegate would be entitled to perform any transaction offered by a service for the client on whose behalf they act. More generally, a delegate would be authorised to perform some well-defined subset of the activities that the client they represent is able to perform (for example, an accountant might be authorised to complete a client’s tax returns, but might not be authorised to change that client’s address details). IA policy General 3.3.1 Responsibility for the management and implementation of an organisation’s security and IA specific policies should be assigned to specific personnel, with the appropriate level of knowledge and expertise. The IA policy relating to an e-Government service should be documented in an RMADS, 31 as set out in HMG IS2, covering: • how IA supports the business requirements; • physical, procedural and personnel measures; • exception-handling procedures; • advice within the organisation to all those involved in IA risk management; • IA awareness and training; • IA incident reporting and recovery operations; • compliance with appropriate standards, policies and laws. 3.2.16 3.3 3.3.2 31 The level of detail required within the RMADS will depend on the impact of the service. For example, for an e-Government service whose service characteristics are mostly IL1, an outline RMADS would generally be sufficient. However, for an e-Government service whose service characteristics are mostly IL3, a greater level of detail would generally be required to support the implementation and management of IA for the service. e-Government framework for Information Assurance Draft 5.1 Page 29 Risk assessment and treatment 3.3.3 Having followed the method set out within this document for assessing risks, there are a number of options available when considering how to manage those risks. The IA risk management process adopted involves determining whether to: • mitigate, by introducing countermeasures to reduce the likelihood and impact of the risk • avoid, by considering alternative means by which the business objective is to be achieved or by considering the business impact of reducing the functionality of the service or not providing the service; • transfer, by considering methods for transferring responsibility; 32 • accept a higher level of risk to the service and to the information assets that it supports in cases where there is a demonstrable overwhelming business benefit associated with the provision of the service. Security management 3.3.4 Appropriate physical and procedural measures must be in place as elements of a multi-layer approach to IA. Detailed guidance on the implementation of physical and procedural measures is beyond the scope of this document. ISO 17799:2005 provides a discussion on the implementation of physical and procedural measures to ensure and maintain confidentiality. e-Government service providers with a requirement to handle protectively marked information will need to refer to MPS. Physical and procedural measures should include: • clearing government users to an appropriate level; government users supporting services with Confidentiality IL3 must be cleared to at least BS, 33 and it is strongly recommended that government users with access to Integrity IL3 and Availability IL3 services are cleared to an equivalent level; 34 • setting clearly-defined physical security perimeters and assessing the strength of these perimeters; • putting appropriate measures into place to manage access points, putting appropriate physical authentication mechanisms in place to ensure that the strength of these are commensurate with the perimeter they support and putting appropriate processes into place to audit access; 3.3.5 32 33 34 This option must be treated with caution. Even if responsibility for limiting risk is transferred to outside the organisation, the risk will still rest wherever the business impacts are actually felt. SC clearance as a minimum would be preferable for central government users with access to sensitive information. It may also be prudent to ensure clearance of government users who support lower-impact services, especially those with Confidentiality IL2, Integrity IL2 and/or Availability IL2. Page 30 Risk management and accreditation • securing offices, rooms and facilities (subject to health & safety regulations), supported by appropriate procedures and training for staff (for example to ensure that sensitive areas are locked out of office hours, that unauthorised staff are escorted at all times, that maintenance staff are not allowed unconstrained access to sensitive areas, etc); • ensuring the security of equipment (including mobile equipment) against loss, damage, theft or other compromise and making sure that appropriate measures are in place to support secure decommissioning of physical assets on which information assets or other sensitive material is stored. 3.4 Service delivery Project and asset management 3.4.1 IA and risk management is a through-life process, as illustrated within the OGC Gateway model at Figure 3. An outline RMADS is developed during early planning and feasibility studies, developed to additional levels of detail up until the delivery of the service. Risk management during the in-service lifetime is a continual process of review, revision, monitoring and improvement. Risks should be reassessed and the RMADS reviewed on a continual basis to support changes in the service environment, 35 threat environment, 36 major upgrades, deployments, etc. 3.4.2 35 A change in the service environment might involve the introduction of a disruptive new technology, or a step change in the evolution of an existing technology, which introduces new opportunities for service provision and associated threats. A change in the threat environment might involve the identification of a newly-identified threat actor or vulnerability. A step change in the service environment would also be likely to present a change in the threat environment. 36 e-Government framework for Information Assurance Draft 5.1 Page 31 Stage 0: early planning and feasibility Identify dependencies Identify applicable laws and statutes Identify the basic IA requirements Assess the impact of IA issues on the business requirements OGC Gateway 0 - strategic assessment Initial RMADS, covering Description of business requirement and constraints Corporate IA policy and other policies as appropriate Notes identifying relevant laws, directives and standards Notes identifying interconnections, flows and relationships with other assets Notes identifying relevant stakeholders Stage 1: scope and risk assessment Scope the IA requirement Review the initial IA requirement, dependencies and applicable legislation Identify the individual components of the requirement Conduct a vulnerability assessment OGC Gateway 1 - business justification RMADS, including: Additional detail on Stage 0 outputs Additional information, as available, on business options and preferences Stage 2: IA requirement definition Review basic information already collated and further develop in readiness for ITT Review and revise IA risks Further develop the risk management plan OGC Gateway 2 - procurement strategy RMADS, including: Additional detail on Stage 1 outputs Business change management plan or similar Draft Invitations To Tender (ITTs) or other proposals as appropriate Stage 3: options assessment and selection Evaluate proposals against the IA requirement Check contract for IA deliverables Ensure funding provision for in-house deliverables Revise and agree the risk management plan OGC Gateway 3 - investment decision RMADS, including: Additional detail on Stage 2 outputs Business or operational requirement, asset register, change management plans Tender proposals / system development specifications Stage 4: accreditation in development & acceptance Main stakeholder involvement and cooperation Gain assurance by appropriate verification and validation Monitor development to address problems as they arise OGC Gateway 4 - readiness for service RMADS, including additional detail on Stage 3 outputs Project, development & IA specific progress reports Results of verification and testing activities Changes and change control information Stage 5: performance and resource review Review effectiveness in accordance with IA requirement Establish any problems and confirm adequate resources Review the IA requirement Make recommendations OGC Gateway 5 - benefits review RMADS, including additional detail on Stage 4 outputs Information as available on asset performance, including audit and inspection records, asset management and user feedback Stage 6: in-service risk management & accreditation Implement processes for continuing IA risk management & accreditation Implement corporate governance processes Practice secure asset management Secure asset use Verification, validation and response Maintain the RMADS Post-implementation reviews RMADS, including revisions as necessary to support different instantiations and deployments of the service Additional information on a continual basis, as appropriate, on business requirements, any proposed changes and results and reports from verification and validation activities Asset management information and user feedback Stage 7: secure decommissioning & disposal Ensure secure decommissioning, transfer or disposal Prepare a formal record of decommissioning Address requirements for information transfer, archive & access Cancel or transfer licenses Notify interfaces and interconnections Secure decommissioning compliance certificate Closure Corporate security policies, relevant laws, statutory regulations and other appropriate policies and standards Confirmation of user requirements for information availability Confirmation of notification to interfaces RMADS Figure 3: risk management and accreditation through the project lifecycle Interaction with third-parties 3.4.3 Outsourcing and use of commercial technologies can bring significant benefits to service providers, including reduced time-to-market and exploitation of new technologies, increased agility and flexibility and the reduction in overheads such as development overheads. Outsourcing contracts, or elements of contracts, for the development, procurement, provision and maintenance of services can be complex. This is 3.4.4 Page 32 Risk management and accreditation particularly true for large public-sector projects, as witnessed by a number of recent high-profile security failures. Outsourcing raises a range of issues for IA which must be mitigated through the development of suitable procedures supported by appropriate contractual mechanisms. 3.4.5 Basic considerations for IA of outsourced contracts cover the procedures that must be put into place for risk assessment and security requirements capture, supporting measures for security reporting and assurance by the supplier and establishing right of audit (which may require negotiating IPR issues). NISCC good practice guidance on outsourcing 37 provides an outline discussion of these issues. Compliance Accreditation 3.5.1 Accreditation is the formal assessment of an information system or a set of capabilities against the IA requirements of the information assets of that information system or capability set. The accreditation process provides evidence that an appropriate set of measures are in place to ensure an acceptable level of risk for the confidentiality, integrity and availability of information assets that are stored and handled within the accreditation boundary. The impact levels for a compromise of the confidentiality, integrity and availability of information assets are determined by the SIRO. For e-Government services, impact levels for a compromise of the identity registration, enrolment and authentication processes that support the service must also be determined. The impact levels should be determined in consultation with the Accreditor, supported by a full risk assessment to set out the business impacts of compromise. Important factors in determining the countermeasures that must be in place and the level of residual risk to accept for information assets include the residual risk that the risk owner is prepared to accept, and any prerequisite requirements for envisaged onward connections. Accreditor involvement is required at all stages of the project lifecycle. The Accreditor should be involved to support the decision to proceed through each of the gateways from GatewayTM 1 through GatewayTM 5. Accreditor involvement as early as GatewayTM 0, and throughout the development process, is strongly encouraged to enable early identification and mitigation of risks to the confidentiality, integrity and availability of information assets. Where formal accreditation is required, this is an essential prerequisite to the following activities, supported by evaluation and testing as appropriate: Outsourcing good practice guide: security governance framework for IT managed service provision, dated 2 August 2006. This document may be downloaded from the NISCC web-site, http://www.niscc.gov.uk. 3.4.6 3.5 3.5.2 3.5.3 3.5.4 37 e-Government framework for Information Assurance Draft 5.1 Page 33 • use of pilots handling live data or live information feeds; • approval-to-operate for a system or set of capabilities; • changes to capabilities or supporting infrastructure, or to their use; 38 • discovery of new vulnerabilities, or changes to known vulnerabilities or likely threat scenarios. Evaluation / testing 3.5.5 It is expected that government will make use of normal commercial technologies and techniques wherever possible, subject to compatibility with these guidelines, and ensure that services are accessible from as wide a range of client platforms as possible. Use of IT security products and services that have been formally certified under the CSIA Claims Tested (CCT) Mark scheme, the CESG Assisted Products Scheme (CAPS) or other assurance schemes such as the UK Information Technology Security Evaluation and Certification (ITSEC) scheme and Common Criteria (CC) is encouraged, to support trust in e-Government service delivery. Table 2 sets out government best practice for assuring the confidentiality of information systems. The focus of this table is on protecting the confidentiality of information assets, but several of the measures suggested will also support the integrity of information assets and the availability of the service: 39 • at IL0, commercial best practice is recommended, supported by an internal audit to test compliance; baseline countermeasures to be applied in support of e-Government services are set out at Sections 5-10 of this document; • at IL1, product, service and system assurance equivalent to EAL 1 should be used, supported by approval by the Accreditor and an ISO 27001 audit where relevant; • at IL2, product, service and system assurance equivalent to EAL 1/2 should be used, supported by approval by the Accreditor and an ISO 27001 audit where relevant; • at IL3, product assurance to CC 2/3, service assurance under the Future Assurance Model and use of Low Tailored Assurance for system assurance should be used; a CHECK audit of the service may be required 3.5.6 3.5.7 38 Routine activities such as antivirus updates or security and bug patches are not expected to fall into this category, and should be documented within the supporting documentation for accreditation. However, a decision to reaccredit might be required following a major patch (Windows XP SP2 is a good example of such a patch). Calculated at the high-water mark of the impact levels attracted to confidentiality, integrity and availability. For example, a service attracting Confidentiality IL0, Integrity IL0 and Availability IL1 should consider the best-practice process at IL1. 39 Page 34 Risk management and accreditation in some cases and Confidentiality IL3 services should be subject to formal accreditation (and an ISO 27001 audit where relevant). Conf. impact level IL0 IL1 Product Assurance Commercial best practice CCT Mark (EAL 1) CCT Mark (EAL 1/2) CC 2/3 Service Assurance Commercial best practice CCT Mark (EAL 1) CCT Mark (EAL 1/2) Future Assurance Model System Assurance Commercial best practice CCT Mark (EAL 1) CCT Mark (EAL 1/2) Low Tailored Assurance System configuration test Commercial best practice Commercial best practice Commercial best practice Commercial best practice / CHECK Compliance Process Internal audit Informal accreditation (+ ISO 27001) Informal accreditation (+ ISO 27001) Formal accreditation (+ ISO 27001) IL2 IL3 Table 2: best-practice process for assuring the confidentiality of information assets e-Government framework for Information Assurance Draft 5.1 Page 35 4 4.1 4.1.1 Service provision environment General This section illustrates a typical service provision environment and context for e-Government services. This section considers the boundaries of the service provision environment, the requirements to protect the service, attack groups and compromise paths, and data protection obligations. Service provision environment Service provision model 4.2 4.2.1 Figure 4 presents a generic model for the e-Government service provision environment. The e-Government service will typically manage a combination of information that is electronically accessible by clients, and information that is accessible to government users only. In addition, an intermediary such as the Government Gateway might be used to manage interactions between the e-Government service domain and the client. E-Government service Government user information space Client information space Trusted third-parties Government Gateway Trusted third-parties Service provision boundary Internet Client Trusted third-parties Figure 4: a representative e-Government service provision environment 4.2.2 The “client information space” in the figure refers to information that is made available to clients. In practice, this information may be subdivided to Page 36 Service provision environment represent information that is available electronically to clients with different levels of authorisation 40 or entitlement. 41 4.2.3 The “government user information space” in the figure refers to information that is made available electronically to government users. This may or may not include some or all client information. The information within this space might attract a higher set of impact levels and require a greater level of protection than the information that is made available to clients. In practice, there may be a number of such information spaces, representing information that is available to government users with different roles. It is envisaged that the Government Gateway will be used by many e-Government services as an intermediary between the e-Government service domain and the client, enabling consistency in interactions with clients and reducing the service development overhead. It is expected that the Government Gateway will be responsible for the management and protection of some or all of the identity registration, enrolment and authentication details that are required to support some e-Government services. There may potentially be requirements for an e-Government service to interact with trusted third parties via a number of channels, including: • direct interaction between e-Government services where system architectures allow, for example to support the exchange of sensitive information about the client (subject to DPA constraints) or to verify client identity or entitlement; • indirect communication via “portal” services such as the Government Gateway or government networks such as the GSi, particularly in support of pan-departmental client transactions such as promulgating a client’s personal details; • information exchange with clients and trusted third parties across the internet, for example tunnelling using a Virtual Private Network (VPN) or via web hosting. 4.2.6 Those elements of the e-Government service environment that are managed by elements of government are encompassed within the service provision boundary. The accreditation boundary encloses a subset of the service provision boundary. 4.2.4 4.2.5 40 For example, an e-Government service that provides read-only access to information by clients might be judged to have Integrity IL0. If read-write access to the same information is judged to have a greater impact level for integrity, then clients may be required to undergo a more rigorous identity registration process to support this additional capability. A client that is registered for a service might be able to perform a range of functions. That client might allow a delegate to perform a well-defined subset of those functions. For example, a client who is registered for online tax returns might be able to submit their annual tax return or change their address details. An accountant who is delegated to act on their behalf might only be permitted to submit tax returns. 41 e-Government framework for Information Assurance Draft 5.1 Page 37 Protecting the service 4.2.7 Considering Figure 4, there is a requirement to protect: • information in transit from clients to the e-Government service and vice-versa; this requirement is not limited to information transferred from the client machine via online channels, but also includes information transmitted via offline (eg post) or other electronic channels (eg SMS message) that might impact on the e-Government service; • the e-Government service and other elements within the service provision boundary such as the Government Gateway and any connected machines and other infrastructure; this includes a requirement for secure erasure and disposal of information that has been stored and handled by or on behalf of the e-Government service when it is no longer required; • information exchange, including information exchanged between e-Government services and information in transit between an e-Government service and a Trusted Third Party (TTP) such as an Other Government Department (OGD) or RA; this includes a requirement to ensure that client consent is obtained before promulgating information for use beyond the purpose for which it was supplied. 4.2.8 Service providers also have a duty of care to aid clients in the protection of their electronic identity and of information that relates to the e-Government service that is stored on their machines or provided using these machines. Attack groups 4.2.9 General types of attack group to be considered include, for example: • individual fraudsters and organised criminal groups who might, for example create false identities, misappropriate genuine real-world identities or simply misuse their own real-world identity in order to try to claim benefits for which they are not entitled • journalists, private investigators, inquisitive individuals and others who might, for example, be in search of a news story, be gathering evidence to be used against a client or simply be curious to know some private detail about their neighbour; • commercial competitors of e-Government clients who might, for example, seek to gain a competitive advantage by eliciting private information such as financial details; • hackers who might, for example, be testing their abilities, trying to impress their peer group, cause mischief, or be in the pay of a more malicious threat actor; 4.2.10 Other non-standard attack groups might also need to be considered by e-Government service providers, particularly for those services relating to elements of the CNI: Page 38 Service provision environment • foreign intelligence services with political, commercial or other motives; • terrorists seeking to misuse or disrupt government resources. 4.2.11 Service providers will also need to consider attack groups acting from within the e-Government service provision boundary, such as government whistleblowers and other disgruntled government employees, employees of service providers who may not have been subject to the same vetting procedures as government employees, maintenance staff and cleaners, etc. These attack groups are considered elsewhere and are beyond the scope of this guidance. Compromise paths 4.2.12 General compromise paths to be considered might include, for example: • access control attacks, such as leveraging improperly assigned or retained user privileges, or attacks on credentials and supporting information through theft, cracking, guessing, forging, cloning, interception, observation, social engineering, etc. • network attacks which might, for example, employ viruses, worms or Trojans, network or transport layer attacks, application layer attacks such as browser or operating system vulnerabilities, denial of service attacks, etc • passive interception attacks such as interception of unencrypted network traffic; • accidental compromise by authorised users, such as user error in entering, amending, moving, exchanging or deleting information; • deliberate compromise by authorised users such as deletion, falsification or misappropriation of information. 4.3 Data protection Data protection principles 4.3.1 Data controllers must comply with the eight data protection principles under the DPA. These may be summarised as requiring that personal data must be: 1. processed fairly and lawfully; 2. obtained and processed only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes; 3. adequate, relevant and not excessive; 4. accurate and, where necessary, kept up to date; 5. held for no longer than is necessary for the required purpose or purposes; 6. processed in accordance with the rights of data subjects; e-Government framework for Information Assurance Draft 5.1 Page 39 7. supported by appropriate technical and organisational measures against the unauthorised or unlawful processing of personal data and against accidental loss, destruction or damage; 8. not transferred to a country or territory outside the European Economic Area, unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subject in relation to the processing of personal data. Protection of e-Government services 4.3.2 A number of specific data protection points arise for the mutual obligations of government and those it deals with, relating to the use of e-Government services. In particular: • service provision should operate on a principle of maximum anonymity consistent with necessary functionality; • it should be clear to the client why information (for example identity registration and enrolment information) is being requested; • information that has been provided by a client should not be used for secondary purposes without first obtaining prior and informed consent from the client; 42 • personal or commercially sensitive information must be released only against reliably verified authority; • where there is a requirement for information exchange, only that information which is relevant should be passed on; 43 • it may be necessary to retain information, such as identity registration information, for a reasonable period for reasons of accountability, audit, etc; these requirements must be balanced against the requirements of the DPA; • services and benefits should be provided only to those entitled to receive them; • the criteria for access and entitlement to particular services should be communicated clearly to clients; • clients must be protected, where possible, against misuse of their authority; • government organisations, and those that they deal with, must be bound by declarations they have made and instructions they have given; 42 There may also be a requirement In exceptional circumstances to release information to government agents without informing the client, for example in support of police activities, or in the interests of national security. For example, where a trust service provider registers a client on behalf of one or more relying parties, that trust service provider must pass on to each of the relying parties only that information which is relevant. 43 Page 40 Service provision environment • adequate procedures must be in place to prevent unauthorised disclosure of personal data; this requires an appropriate level of assurance for identity registration, enrolment and authentication supported by measures to protect information stores and information in transit. 4.3.3 Where personal data are processed on behalf of a data controller by a thirdparty, the activities of the data processor must be governed by a written contract. In addition to a written contract, providers of identity registration services to government must comply with any applicable data protection and retention policy. e-Government framework for Information Assurance Draft 5.1 Page 41 5 5.1 5.1.1 Identity registration Overview Identity registration is the process by which a client registers a pseudonym, or registers their real-world identity to a desired level of assurance. This may include presentation of evidence by the client as proof of their real-world identity, and checks to ensure that the evidence provided is authentic, valid and belongs to the client. The real-world identity of a client need only be established if this is essential to support the service(s) to be provided. Identity registration typically involves provision of several forms of evidence to support different elements of a client’s real-world identity. For example, a client might be required to provide a copy of their passport to confirm their name, date of birth, etc and might also be required to provide a recent bank statement or utility bill as evidence of recent activity at the address that they have given. Identity registration process Identity registration to support access to e-Government services may proceed directly through a government service, or via a trusted third-party such as the Government Gateway. Figure 5 presents a typical example of the identity registration process. This process involves: • a request by a client to register either their real-world identity or a pseudonym; • authentication of the e-Government service at a level of assurance that is appropriate to protect the identity registration information provided by the client; 44 • presentation by the client of any evidence requested by the service as proof of their real-world identity; • verification by the service provider of the real-world identity asserted by the client, by checking that the evidence provided is authentic, valid and belongs to the client. 5.1.2 5.2 5.2.1 44 Authentication of the service is discussed further at Section 7. Page 42 Identity registration CLIENT INTENTION TO USE SERVICE The client identifies the desired e-Government service GOVERNMENT SERVICE AUTHENTICATION SERVICE VERIFICATION Check of credentials presented by the service to verify the identity of the service PRESENTATION OF SERVICE CREDENTIALS Presentation of credentials (for example an electronic signature) to the client to authenticate the service IDENTITY CHECKING PRESENTATION OF EVIDENCE OF IDENTITY Presentation of evidence (on- or off-line) of real-world identity by the client IDENTITY VERIFICATION Checking and confirmation of the real-world identity of the client ACCOUNT ACTIVATION Receipt of electronic identity and activation of account by the client PROVISION OF ACCOUNT Provision of a client account, this could include an electronic identity. The type of credential issued as part of the electronic identity will be determined by the IL attracted to client authentication Figure 5: a typical example of the identity registration process 5.3 5.3.1 Impact level for identity registration Identity registration attracts an impact level which is based on the highest impact of a compromise of a client’s real-world identity. This might include impacts due to inaccuracy, duplication, improper assignment and/or misappropriation of a client’s identity registration information. The impact level for identity registration is calculated using the HMG Impact Level table presented at Annex D. Services where a client may remain anonymous or where a client may register using a pseudonym will attract Registration IL0, even if a high level of assurance is required for authentication of a client with a given pseudonym. 45 Identity registration is pre-requisite to enrolment for many e-Government services. Enrolment of a client requires the service provider to know whether the client requesting the service is permitted to represent the real-world identity that has been asserted. The impact level for the client’s real-world identity will thus be at least as high as the impact level for any proof-ofentitlement submitted to support enrolment. The correlation between identity registration and enrolment is set out at Table 3. Enrolment is discussed in more detail at Section 6. 5.3.2 5.3.3 45 This would be the case, for example, where a client registers for a pseudonymous health-screening programme. Such a service might well attract Registration IL0 and Authentication IL3. e-Government framework for Information Assurance Draft 5.1 Page 43 Enrolment impact level IL3 IL2 IL1 IL0 IL0 IL1 IL2 IL3 Identity registration impact level Table 3: relationship between identity registration and enrolment 5.3.4 Integrity 46 depends on the ability of the e-Government service to protect the information assets that are entrusted to it, and also on the correctness of the information provided. For cases where the impact level for integrity is determined by a requirement for non-repudiation, the impact level for identity registration must be at least as high as that for integrity. 47 The mapping between identity registration and integrity is set out at Table 4. Integrity is discussed in more detail at Section 8.1. IL3 IL2 IL1 IL0 IL0 IL1 IL2 IL3 Integrity impact level (general) IL3 IL2 IL1 IL0 IL0 IL1 IL2 IL3 Integrity impact (non-repudiation) Identity registration impact level Identity registration impact level Table 4: relationship between identity registration and integrity for: (left) where non-repudiation dominates and (right) for the general case 5.3.5 Information that is provided by a client during the identity registration process has a value. This introduces a number of considerations for the identity registration process: • the measures that are in place to authenticate the e-Government service to the client during the submission of identity registration information must be commensurate with this value; further measures must be in place to protect the information once within the service provision boundary; • in general, the more confidence required in a client’s real-world identity, the higher the value of the identity registration information that the client will need to provide and the stronger the measures that must be in place to authenticate the service during the identity registration process; • protection of identity registration information is a particular issue for highvalue information such as biometric information that is captured for 46 47 The IS1 definition of integrity, which we have adopted for this document, includes the requirement for non-repudiation of transactions and communications. For example, if a service enables a range of transactions at Integrity IL1 based on a requirement for non-repudiation, that client must be registered at Registration IL1 or higher before being allowed to enrol. Page 44 Identity registration checking against a national database; 48 careful consideration of the options to protect such information or reduce the impact of compromise would need to be considered in such cases; 49 applying measures for protection of high-value identifiers is likely to be prohibitively expensive and difficult to implement in most cases. 5.4 5.4.1 Threats Potential clients might attempt to register using a fictitious real-world identity, try to misappropriate a genuine real-world identity, or register false details either deliberately or by accident. These threats may be countered by examining original documents to an appropriate level of scrutiny, checking the details given against population or organisation registers or requiring that a trustworthy person or organisation confirm the information given. There may also be technology-specific risks, which should be addressed through the application of relevant technical guidance. Appropriate measures must be in place to: • ensure that clients are made aware of any identity registration information that is or might be stored or archived on client machines and how to manage this information; 50 • authenticate the client to the service provider at an appropriate level of assurance for the identity registration information being provided by the client; • authenticate the service provider to the client at an appropriate level of assurance for the identity registration information being provided by the client; • protect identity registration information in transit and within the e-Government service. 5.4.2 5.4.3 48 Widespread misappropriation of biometric information would negate the value of such a database. Potential misuse of this information, for example to support fraudulent activities by a criminal organisation, might lead the practitioner to assign a confidentiality impact level for this information that exceeds Confidentiality IL3. For the biometrics example, an example solution would be to securely process the biometric using a hash function to present an identifier with significantly fewer degrees of freedom, but which remains unique to an individual client insofar as the biometric itself can be considered unique. For example, cookies might be used to store identity registration information, to enable the registration process to be paused. In this example, the client should be made aware of this, of the risks of using insecure machines (eg in an internet café) and of how to expunge this information following registration. 49 50 e-Government framework for Information Assurance Draft 5.1 Page 45 5.5 General requirements Registration evidence requirements 5.5.1 There will be some services where anonymity or pseudonymous registration of identity is acceptable (or sometimes even necessary). As a rule, compliance with the DPA requires e-Government service provision to operate on the principle of requesting the minimum information that is sufficient to enable conduct of the required transaction or transactions. Beyond the initial registration of a client’s identity, there is a continual requirement to ensure that the client’s identity registration information is amended as necessary, to reflect any change in their circumstances. This is required to protect both the client 51 and the e-Government service. 52 Informing the client 5.5.2 5.5.3 Clients should be informed, at and/or before the point of identity registration, of any further intended use of their identity registration information. This may require careful consideration of what services or types of services for which the client will need to enrol. Provision and maintenance of an electronic identity 5.5.4 Successful identity registration of a client might include provision of an account and/or electronic identity for that client. If elements of a client’s electronic identity are to be delivered electronically, both the client and the e-Government service must be authenticated to an appropriate level of assurance to protect this information. Alternatively, some or all of this information may be delivered to the client via out-of-band channels to an independently verified address, telephone number, etc. Authentication is discussed further at Section 7. Trust relationships for identity registration 5.5.5 An e-Government service might act as its own identity registration authority, or rely on a third-party to manage identity registration. There are a number of mechanisms by which identity registration may be achieved, the most popular of these mechanisms are discussed below. The simplest relationship between a client and an identity registration authority is two-party registration. An example of two-party registration would be where a client registers directly with an e-Government service provider to use a specific service or range of services delivered by the same service provider, but would not be put to any further use. Two-party registration benefits from simplicity of implementation, but may lead to an unnecessary For example, by ensuring that information posted to clients is sent to the correct address. For example, by ensuring that the client is not provided with benefits for which they are no longer entitled. 5.5.6 51 52 Page 46 Identity registration financial burden where a high level of assurance in the client’s real-world identity is required. For e-Government services, there is the additional disadvantage that this approach may lead to a lack of consistency between e-Government services and goes against the concept of joined-up government. 5.5.7 Three-party registration involves a client registering their identity with an identity registration authority which validates the client’s real-world identity to a number of e-Government service providers. 53 Examples of three-party registrations include initial registration for the government gateway or registration with the proposed IPS identity database. In such cases some of the liability for ensuring the client’s real-world identity would be transferred from the service-provider to the identity registration authority. Many-party registration involves a client registering their identity with one of several registration authorities, which validates the client’s real-world identity to the required level of assurance. Having registered with one registration authority, the client’s registration would be accepted to an appropriate level of assurance by a federation of other registration authorities without needing to register again with each of them. Many-party registration relies on the use of consistent or equivalent methods across the federation of registration authorities for the assessment and treatment of risk. Trust might be mediated by a third-party trust service approval scheme such as tScheme or equivalent, or enabled through bilateral or multilateral agreements between e-Government service providers. 54 The balance-of-liability within such a model would require consideration. Use of three-party or many-party registration is preferred over two-party registration for e-Government service provision, to promote ease of accessibility, consistency of service and economies of scale as discussed above. Escalation of assurance in a client’s real-world identity 5.5.10 There will sometimes be a requirement to increase the level of assurance in the real-world identity of a client who has already registered. 55 Any such 5.5.8 5.5.9 53 A broader definition of three-party registration would involve use of the registration authority to allow clients to identify each other to a required level of assurance, in support of peer-to-peer transactions (the e-Bay model of identity registration). For example, if a service provider has registered a client at Registration IL2, and an appropriate set of measures has been put into place to maintain that identity registration information, other service providers with Registration IL2 assurance requirements and below should be able to assert the client’s identity without needing to gather further identity registration information themselves. This would be subject to establishing a mutually agreeable trust relationship, and to explicit and informed consent by the client. This might be required, for example, if a client withes to enrol for additional services or requires access to more sensitive functionality within a service for which they are already enrolled. 54 55 e-Government framework for Information Assurance Draft 5.1 Page 47 escalation must require different evidence to that provided during the client’s initial identity registration. 56 Accounting and audit 5.5.11 At Registration IL1 and above, client registration must be treated as an accountable event. Accounting logs and audit information should be recorded, supported by appropriate audit procedures to track and forensically examine use of the e-Government service as necessary. 5.6 5.6.1 Registration countermeasures The levels of assurance required to support identity registration are as follows: • at Registration IL0 the e-Government service does not require any confidence that the client is who they claim to be; • at Registration IL1 the e-Government service wishes to ensure that, on the balance of probabilities, the client is who they claim to be; • at Registration IL2 the e-Government service requires substantial assurance that the individual is who they claim to be; • at Registration IL3 the e-Government service wishes to verify the client’s identity beyond reasonable doubt; at Registration IL3, the case for allowing remote identity registration or online identity registration must be presented on a service-by-service basis, agreed by the SIRO and thoroughly documented in the RMADS; in particular, the Information Commissioner has advised that remote or online identity registration should not be used for individuals where this identity registration could permit access to personal information that could then be manipulated. 57 5.6.2 Table 5 and Table 6 provide an overview of the requirements for remote or online identity registration of an individual and of an organisation respectively, in comparison with the requirements for face-to-face identity registration. Any identity registration procedures that are employed by service providers must be commensurate with the procedures set out at Table 5 and Table 6. Caution must be exercised when identifying appropriate remote or online registration procedures. For example, use of online bills, remittance advice and the like must not be construed as constituting acceptable evidence of the client’s address or activity in the community; such evidence is trivial to forge. Details of the specific items that constitute reputable evidence and trustworthy sources may be found within the HMG minimum requirements documents for This introduces a requirement to record what evidence was used during the initial registration process. Where a trust model is in place between registration authorities and one registration authority might be required to provide an escalation in the level of assurance provided by another registration authority, there will a requirement to make available the record of what evidence was used. This will not necessarily require the evidence itself to be exchanged. This is to protect against fraudulent access to someone else’s personal data. 5.6.3 56 57 Page 48 Identity registration the verification of the identity of individuals 58 and organisations. 59 These documents also include a further discussion of acceptable countermeasures for the registration of individuals and organisations. In the event of any disagreement, the evidence requirements set out at Table 5 and Table 6 of this document take precedence over the HMG minimum requirements documents. 5.6.4 Annex E presents some examples of acceptable remote and online evidence for the identity registration of an individual. Further support for identifying the levels of countermeasures to be applied for identity registration and authentication, and for identifying acceptable evidence to support identity registration and authentication, are provided by the CSIA risk management tool. 60 58 HMG’s minimum requirements for the verification of the identity of individuals, Version 2.0, January 2003. This document may be downloaded from the Cabinet Office web-site, http://www.cabinetoffice.gov.uk/. HMG’s minimum requirements for the verification of the identity of organisations, Version 2.0, January 2003. This document may be downloaded from the Cabinet Office web-site, http://www.cabinetoffice.gov.uk/. Enquiries relating to the risk management tool should be directed to CSIA via the contact provided at Section 1.7. 59 60 e-Government framework for Information Assurance Draft 5.1 Page 49 Registration IL0 No personal statement is required. 61 Registration IL1 A personal statement including: • the client’s full name, place and date of birth and current permanent address; • a declaration that the information given is true and correct. Registration IL2 A personal statement including: • the client’s full name, place and date of birth and current permanent address; • a declaration that the information given is true and correct; • additional detail on the client’s identity, as required to support corroboration. Registration IL3 A personal statement including: • the client’s full name, place and date of birth and current permanent address; • a declaration that the information given is true and correct; • additional detail on the client’s identity, as required to support corroboration. Supporting evidence must include all 66 of the following: • highly reputable evidence of the client’s identity. • at least two pieces of evidence of activity in the community and corroboration of information asserted in the client’s personal statement (this may require checking with a nominated referee). • at least two pieces of thirdparty corroboration from different trustworthy sources.63 No supporting evidence is required. Supporting evidence must include any 62 one of the following: • two pieces of reputable evidence of the client’s identity and address. • reputable evidence of the client’s identity and corroboration of the client’s identity and address from a trustworthy source. 63 • two corroborations of the client’s identity and address from different trustworthy sources.63 Supporting evidence must include either 64 of the following: • reputable evidence of the client’s identity, evidence of the registrants address and activity in the community, reputable documentary evidence or corroboration from a trustworthy source63 and one further independent piece of evidence from the above list. • highly 65 reputable evidence of the client’s identity and two or three corroborations of the client’s identity and address from different trustworthy sources.63 Table 5: overview of requirements for remote or online registration of an individual 61 In some cases, the client might be encouraged to provide some details (name, etc) to support establishing a persistent pseudonym. This would generally not be mandatory and these details would not be checked. For face-to-face registration, one piece of reputable evidence of the client’s identity or corroboration from a trustworthy source, in addition to the client’s signed personal statement, would be sufficient. If the registration authority holds its own detailed records, validation against these records may count as one of the required trustworthy sources. For face-to-face registration at Registration IL2, any two of the following, in addition to the client’s signed personal statement, would be sufficient: 1 piece of reputable evidence of the client’s identity; 1 piece of evidence of the client’s address; 1 piece of activity in the community or third-party corroboration. For face-to-face registration, this should contain the client's signature and photograph. For remote or online registration, this should be a passport, other National Identity document, or other document which provides an equivalent or higher level of assurance of a client’s identity. For face-to-face registration at Registration IL3, in addition to the client’s signed personal statement and additional details, one piece of reputable evidence of the client’s identity, 1 piece of evidence of the client’s address; 1 piece of activity in the community or third-party corroboration and one further piece of evidence from the above would be required. 62 63 64 65 66 Page 50 Identity registration Registration IL0 No supporting evidence for registration of the organisation is required Registration IL1 Evidence requirements for the organisation must include any one 67 of the following: • evidence of public registration (preferred). • two pieces of reputable evidence of trade or operational membership or of dealings with government. • reputable evidence of trade or operational membership or of dealings with government, and third-party corroboration from a trustworthy source. Registration IL2 Evidence requirements for the organisation must include any one 68 of the following: • evidence of public registration (preferred). • 2 pieces of reputable evidence of trade or operational membership or of dealings with government, and third-party corroboration from a trustworthy source. Registration IL3 Evidence requirements for the organisation must include both 69 of the following: • evidence of public registration. • reputable evidence of trade or operational membership or of dealings with government, or third-party corroboration from a trustworthy source. No supporting evidence for validation of the company’s representative is required Evidence requirements for the company’s representative must include three 70 of the following: • evidence of identity. • evidence of affiliation with the organisation. • evidence of authority to act for the organisation. • back-contact with the registrant organisation. Evidence requirements for the company’s representative must include all 71 of the following: • evidence of identity. • evidence of affiliation with the organisation. • evidence of authority to act for the organisation. • back-contact with the registrant organisation. Evidence requirements for the company’s representative must include all 72 of the following: • two pieces of evidence of identity. • evidence of affiliation with the organisation. • evidence of authority to act for the organisation. • back-contact with the registrant organisation. Table 6: overview of requirements for remote or online registration of an organisation. 67 Face-to-face registration by a representative at Registration IL1 would require any one of: evidence of public registration (preferred); one piece of reputable evidence of trade or operational membership or of dealings with government; or one piece of third-party corroboration from a trustworthy source. Face-to-face registration by a representative at Registration IL2 would require any one of: evidence of public registration (preferred); two pieces of reputable evidence of trade or operational membership or of dealings with government; or one piece of reputable evidence of trade or operational membership or of dealings with government and one piece of third-party corroboration from a trustworthy source. Face-to-face registration by a representative at Registration IL3 would require evidence of public registration and one-or-more pieces of reputable evidence of trade or operational membership or of dealings with government. For face-to-face registration at Registration IL1, the organisation’s representative would be required to provide one piece of evidence of identity, one piece of evidence of affiliation with the organisation and one piece of evidence of authority to act of the organisation. For face-to-face registration at Registration IL2, the organisation’s representative would be required to provide one piece of evidence of identity, one piece of evidence of affiliation with the organisation and one piece of evidence of authority to act of the organisation. The face-to-face registration requirements for validating an organisation’s representative at Registration IL3 are equivalent to the remote registration requirements. 68 69 70 71 72 e-Government framework for Information Assurance Draft 5.1 Page 51 6 6.1 6.1.1 Client enrolment to a service Overview Enrolment is the process by which a client is enabled access to a specific e-Government service. Enrolment is concerned with establishing the entitlement of a client to receive an e-Government service (eg whether that client is eligible for tax credits). Identity registration, by comparison, is concerned solely with verifying the identity of a client. Before being enrolled a client might first register their real-world identity to an appropriate level of assurance, or a pseudonym, with the service provider or a trusted third-party. Successful enrolment of a client will include provision of an account for that client. Enrolment might also include provision of an electronic identity for that client or might make use of an electronic identity that was issued during the identity registration process. In some cases, use of an existing electronic identity might require this to be extended. The strength of any authentication credential provided during enrolment must be commensurate with the impact level attracted to client authentication. A client must enrol at or before first use of a service and may only use those services for which they are enrolled. Evidence requirements for enrolment will depend on the details of the service to be used and must be set in conjunction with relying parties. Enrolment for a service might be carried out at the same time as identity registration 73 or might be conducted after identity registration. 74 Enrolment process Enrolment might proceed directly through the government service or indirectly via a trusted third party. Figure 6 presents a typical example of the enrolment process. This process involves: • a request by a client to be enrolled in the desired service or range of services; • authentication of the e-Government service at a level of assurance that is appropriate to protect the enrolment information provided by the client; • if a client has not previously been enrolled in a service, registration of the client’s real-world identity may be required; • a check of the entitlement of a client to have access to that service, or range of services. This may require presentation of proof of status by the 6.1.2 6.1.3 6.1.4 6.2 6.2.1 73 74 For example, if a client registers and enrols directly for a specific e-Government service. For example if a client registers with the Government Gateway and then enrols for a number of different e-Government services, at different times, as the need arises. Page 52 Client enrolment to a service client relevant to the service in question. This evidence must be verified by the service to prove its authenticity and validity; • an account and an electronic identity are provided to a client, which is activated by a client. The account is recorded by government as having authority to engage in the relevant transactions. CLIENT APPLICATION Client applies to be enrolled in a service GOVERNMENT IDENTITY CONFIRMATION Client provides confirmation to the service that they are the same client that registered the real-world identity they are claiming IDENTITY VALIDATION Validation of the information provided by a client who has previously registered their identity (eg by the client confirming receipt of email or postal letter) ENTITLEMENT Check of the eligibility of a client to enrol in the desired service. This may require a client to present further evidence specific to the service, and the subsequent verification of its authenticity by governent ACCOUNT ACTIVATION Receipt of electronic identity and activation of account by the client PROVISION OF ACCOUNT Provision of a client account, this could include an electronic identity. The type of credential issued as part of the electronic identity will be determined by the IL attracted to client authentication Figure 6: a typical example of the enrolment to a service 6.3 6.3.1 Impact level for enrolment Enrolment for an e-Government service attracts an impact level which is based on the highest impact of allowing a client access to services to which they are not entitled, or of denying a client access to services to which they are entitled. The impact level for enrolment is calculated using the HMG Impact Level table presented at Annex D. 75 For cases where a real-world identity is required, enrolment of a client requires the service provider to know: • whether the real-world identity registered is eligible to receive the service requested; this may require the provision of additional service-specific supporting information; • whether the client requesting the service is permitted to represent the realworld identity that has been asserted; this requires the level of assurance in the client’s real-world identity to be at least as high as the level or assurance required to support enrolment; for example, if a client wishes to enrol for a range of services with Enrolment IL1 and Enrolment IL2, that client must first be registered at Registration IL2 or higher. The correlation between identity registration and enrolment is set out at Table 3 in Section 5; 75 6.3.2 For example, if compromising a client’s enrolment information is likely to cause minor financial loss to any party then this would attract Enrolment IL2. e-Government framework for Information Assurance Draft 5.1 Page 53 • whether an escalation in the assurance of a client’s real-world identity is required to support enrolment; 76 6.3.3 Some clients might wish to enrol to perform only some of the transactions that are offered by an e-Government service (eg to support a lower level of identity registration and enrolment). If an e-Government service is to enable such a facility, appropriate access control measures and compartmentalisation of services and information must be put into place. Delegate accounts might attract a higher or lower impact level than standard client accounts to reflect, for example, a requirement to manage many client accounts or access to a more limited range of transactions. The enrolment evidence requirements for delegates should reflect this. The information that is provided by the client during the enrolment process must be assigned a value, and protected in a manner that is commensurate with this value (see the discussion at paragraph 5.3.5). This may require authentication of the service provider during submission of this information. Threats Clients and other individuals who have registered their identity, stolen somebody else’s identity or subverted the registration process might attempt to enrol for services that they are not entitled to. This might involve the provision of a false proof of status, either deliberately or by accident. These threats might be countered by, for example, examining original documents to an appropriate level of scrutiny, checking the details given against other government back-end system databases, or requiring that a trustworthy person or organisation confirm the information given. Appropriate measures must be in place to: • ensure that clients are made aware of any enrolment information that is stored on client machines and how to manage this information; • authenticate the service provider to an appropriate level of assurance for the enrolment information being provided; • protect enrolment information in transit and within the e-Government service. 6.5 General requirements Evidence of entitlement 6.5.1 Enrolment for a specific service might require the client to provide proof of status, over-and-above that provided during identity registration, to establish 6.3.4 6.3.5 6.4 6.4.1 6.4.2 76 A discussion of escalating the level of assurance in a client’s real-world identity is provided at Section 5. A discussion of how to protect such information during submission is provided at Section 7. Page 54 Client enrolment to a service their entitlement. 77 This information will not necessarily correspond to an escalation of existing identity registration information. Evidence provided by a client during enrolment as proof of status should: • be service specific; • be mandated by the service provider as a necessary precursor to service delivery; • not be concerned with proof of identity; • represent the minimum additional information that is necessary to confirm entitlement; • not have already been demonstrated as part of the identity registration process; • not be part of (or derived from) the set of credentials issued at the time of identity registration. Provision and maintenance of an electronic identity 6.5.2 Successful enrolment of a client might include provision of an account and/or electronic identity for that client. If elements of a client’s electronic identity are to be delivered electronically, both the client and the e-Government service must be authenticated to an appropriate level of assurance to protect this information. Alternatively, some or all of this information may be delivered to the client via out-of-band channels to an independently verified address, telephone number, etc. Authentication is discussed further at Section 7. Changes in a client’s status or identity registration information might affect their entitlement to receive an e-Government service. Identity registration and enrolment information must be continually updated. 78 In the event that a client is no longer eligible to receive a service or no longer wishes to receive that service, appropriate procedures must be in place to manage disenrolment, along with revocation of credentials and collateral information. Trust relationships for enrolment 6.5.4 A client who wishes to enrol for several e-Government services might, in some cases, be required to submit the same (or similar) information, in addition to their registration information, to support each enrolment. 6.5.3 77 78 For example, a client might be required to provide details of their income to support an application for tax credits. Mechanisms should be put into place to allow clients to update registration and enrolment information (address, telephone number, eligibility for the service etc) as-and-when this changes, and encouraged to use these mechanisms. For many services, it is useful to require clients to re-enrol or refresh their enrolment at regular intervals, obliging clients to update their enrolment and/or registration information. The frequency and dates at which re-enrolment or refresh of enrolment information will be require will vary depending on the service (for example, it might be useful to refresh client enrolment for tax credits at the beginning or end of each financial year). e-Government framework for Information Assurance Draft 5.1 Page 55 6.5.5 To eliminate duplication of effort, the client may wish to submit enrolment information once and allow it to be shared by all of the relevant service providers: 79 • where a three-party or many-party registration process is in place, enrolment might be managed as an extension of the registration process; • where mutual trust exists between two or more service providers, one service provider might take prior enrolment of a client with another of the trusted service providers as being in itself sufficient proof-of-entitlement to support enrolment. 6.5.6 Rather than require a client to submit evidence of entitlement to an e-Government service, it may be preferable to obtain this evidence directly from another (government or third-party) source. 80 In such cases, the service provider would need to provide sufficient assurance to the party supplying the information that the confidentiality of the information disclosed will be protected appropriately. Delegate accounts 6.5.7 Any potential requirements to support delegate accounts, 81 whereby a client is given delegated authority to undertake actions on behalf of another client, 82 must be considered as part of the service development process. This might require both the delegate and the client they support to register their identities before or at the time of enrolment. Delegate accounts may require a different enrolment process from standard client accounts: 83 • a delegate acting in a professional capacity (as an accountant, for example) might be required to undergo a primary enrolment as a delegate, and then be linked to relevant client accounts, with an appropriate level of privilege; 6.5.8 79 80 It is good practice to inform the client of any potential further use for their information in advance of submission, and in some cases explicit prior consent will be required. This would particularly be the case where (a) the service provider requires a high level of confidence in the authenticity of the information provided or (b) the submission of sensitive information is required to establish a client’s entitlement, which might be difficult to protect in transit from the client to the service provider but would be easier to protect across a secure delivery channel between service providers. A typical example would be the requirement of a client to settle the accounts of a recently deceased family member. This would require the executor or administrator of the will to notify some service providers of the death and to settle financial accounts with others. Delegate accounts might be set up, for example, to establish and use a power of attorney or to give a group of individuals “signing” responsibility for performing specific transactions such as accountancy functions. For a delegate acting on behalf of a recently deceased family member, the enrolment process may well require the delegate to provide, for example, proof of probate. 81 82 83 Page 56 Client enrolment to a service • a delegate acting in a personal capacity on behalf of a relative might only enrol once, but following a different process to regular clients (reflecting, for example, differing evidence requirements, levels of persistence, etc). 6.5.9 If a requirement to support delegate accounts is not explicitly met by an e-Government service, alternative offline mechanisms must be provided to handle such exceptions 84 or an additional level of risk may have to be accepted by the service provider. 85 In some cases a delegate would be entitled to perform any transaction offered by a service for the client on whose behalf they act. More generally, a delegate would be authorised to perform some well-defined subset of the activities that the client they represent is able to perform (for example, an accountant might be authorised to complete a client’s tax returns, but might not be authorised to change that client’s address details). 6.5.10 6.5.11 A particular issue that must be considered during service design is whether it is necessary to identify a specific individual carrying out an e-business transaction on behalf of an organisation. The actual approach depends on the underlying business process being supported. For example, it might be appropriate for a purchase order to be placed by an identified organisation, with the identity of the individual being managed by the organisation. Similarly, for many transactions with central or local government, all that is of concern to the citizen is that a transaction is with an identified organisation. Accounting and audit 6.5.12 At Enrolment IL1 and above, client enrolment must be treated as an accountable event. Accounting logs and audit information should be recorded, supported by appropriate audit procedures to track and forensically examine use of the e-Government service as necessary. 6.6 6.6.1 Enrolment countermeasures The levels of assurance required to support enrolment are as follows: • Enrolment IL0 services are freely available to all and require no proof of entitlement; • Enrolment IL1 services require assurance that, on the balance of probabilities, the client is eligible to receive the service offered; • Enrolment IL2 services require substantial assurance that the client is eligible to receive the service offered; • Enrolment IL3 services require the client’s entitlement to be confirmed beyond reasonable doubt. 84 85 For example, using traditional channels. For example, accepting that some delegates will subvert the identity registration and enrolment process by using the electronic identity of the client they represent. e-Government framework for Information Assurance Draft 5.1 Page 57 6.6.2 In many cases, the information furnished to support client identity registration will be sufficient proof-of-entitlement for a service. Where additional proof-ofentitlement is required, the procedures to support this should be commensurate with those for identity registration at an equivalent impact level. The information requirements to support enrolment will vary on a service-byservice basis. Generic information requirements for enrolment of a company’s representative in support of a company’s representative are provided at Table 6 in Section 5. In contrast to Registration IL3, which is difficult to manage using online processes, Enrolment information at Enrolment IL3 and higher levels of assurance may be easily communicated across secure channels, subject to establishing appropriate trust relationship and putting appropriate measures into place to support obligations under the DPA. 6.6.3 6.6.4 Page 58 Client enrolment to a service This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 59 7 7.1 7.1.1 Authentication and client access Overview Authentication is the process by which a credential and collateral information are presented and verified, to establish a claim to a valid electronic identity. An electronic identity to support authentication by a client would typically be provided during the identity registration and/or enrolment process. For services where no authentication is required, prior identity registration and enrolment need not take place. For other services, identity registration and issue of an electronic identity are pre-requisite to authentication and use of an e-Government service. The level of assurance that is supported by an electronic identity relates directly to the strength of the credential and of its collateral information. 86 Authentication process Figure 7 presents the authentication process for a typical client session. It also demonstrates where additional client authentication (for example to obtain authorisation to carry out specific transactions) may be required. This process typically involves: • presentation of a credential to the client by the e-Government service, and checking of that credential by the client (or by a trusted third-party on behalf of the client) to verify the electronic identity of the service; • presentation of a credential to the e-Government service, and checking of that credential by the e-Government service (or by a trusted third-party on behalf of the service) to verify the client’s electronic identity. 7.1.2 7.1.3 7.2 7.2.1 86 For example, the intrinsic strength of a cryptographic key will depend on the key length and the algorithm used, and on the complexity of any pin, password or passphrase that protects it. Page 60 Authentication and client access CLIENT SESSION INITIATION Client initiates a session with the desired service GOVERNMENT SERVICE AUTHENTICATION SERVICE VERIFICATION Check of credentials presented by the service to verify the identity of the service PRESENTATION OF SERVICE CREDENTIALS Presentation of credentials by the service, for example, an electronic signature, to the client CLIENT AUTHENTICATION PRESENTATION OF CLIENT CREDENTIALS Presentation of credential and supporting information, for example, a user name and PIN, by the client CLIENT VERIFICATION Check of the credential provided by the client against a database to verify the electronic identity and it’s validity LOG ON Service confirms the successful access of a client to the desired service ACCESS OR ACTIVITY REQUEST Client requests authorisation for access or to carry out an activity AUTHORISATION Authorisation for requested access or activity or request for further authentication TRANSACTION OR COMMUNICATION SESSION TERMINATION Client or service logs off, and the session is terminated Figure 7: a typical example of an e-Government client session 7.3 7.3.1 Impact level for authentication Client authentication attracts an impact level which is based on the highest impact of compromise of a client’s electronic identity. The impact level for client authentication is calculated using the HMG Impact Level table presented at Annex D. A client may wish to perform a transaction within an e-Government service which percolates through to other e-Government services (for example, performing a universal change-of-address). This transaction would attract an impact level equal to that of the highest impact of changing the relevant information for any of the services involved. 87 Previous e-Government guidance recommended that pan-service activities should attract a higher impact level than single-service activities, noting the accumulated impact of allowing unauthorised changes to propagate. However, adherence to minimum standards and the drive to support client convenience and trust have led to a more homogeneous information environment, where registration requirements for different services are supported by evidence requirements that are closely related or even the same. Similarly, the implementation of HMG minimum standards has resulted in services whose service provision boundaries have similar levels of resilience for a given impact level. Further, following the IS1 risk assessment method, by far the most significant source of risk to government information systems is due to external threat actors. In this case, then, there are strong arguments that a threat actor who compromises one (properly implemented) e-Government service is equally able to compromise other such services, so that the “security through diversity” argument no longer holds. 7.3.2 87 e-Government framework for Information Assurance Draft 5.1 Page 61 7.3.3 Promulgation of information across e-Government services as the result of a transaction would require informed and explicit consent on the part of the client, and is reliant on appropriate trust agreements being in place. The impact level for authentication of the initiating service must be commensurate with the impact level for integrity. Threats There are a number of threats relating to the authentication process. These threats mainly relate to the vulnerability of client credentials and collateral information in transit and in use within potentially insecure environments. Examples include: • misappropriation of elements of a client’s electronic identity through theft, interception, cloning, forgery, cracking, network sniffing, keystroke loggers, physical observation of client machines, social engineering, etc; • deliberate misuse of service procedures (eg conduct of a Denial of Service (DoS) attack through misuse of the client lockout feature); • use of a credential for unintended purposes; • use of a credential after a substantive change in circumstances; • fraudulent use of a credential; • undue withdrawal of a credential; • bypassing the use of credentials. 7.4 7.4.1 7.4.2 Protection of high-value credentials, such as biometric information, is a particular issue for service providers which must be carefully considered before making a decision to use these, as discussed at Section 5.3. General requirements Issue of credentials 7.5 7.5.1 An authentication credential will, in general, correspond to a single real-world identity. However, a real-world identity may possess a number of electronic identities. It may be useful in some cases to re-use an authentication credential for several different purposes. This is particularly the case for high value credentials such as an Authentication IL3 token. For some such uses it may be necessary to conceal or break the link between the electronic identity and the client’s real-world identity. 88 For most electronic transactions, government will accept credentials provided, or partially provided, by accredited third parties that register the identity of clients and issue them with credentials and supporting information. For example, if a client has registered their identity at Registration IL3 to receive an Authentication IL3 token and then wishes to use that token to support an application for a pseudonymous medical screening programme with Registration IL0 and Authentication IL3. 7.5.2 88 Page 62 Authentication and client access Protection of credentials from theft and unauthorised use 7.5.3 7.5.4 As a general rule, a credential should support the minimum of information that is necessary for it to function in an accessible form. Where physical theft of a credential is a potential issue, measures should be in place to require this credential to be delivered using an appropriately secure electronic channel, delivered using an appropriate postal or courier service, or issued in person to the registered client. Where physical theft, electronic theft or unauthorised use of a credential are potential issues, measures should be in place to ensure that this credential is only usable in conjunction with collateral information such as a PIN, password or other user verification mechanism which is delivered separately. 89 Clients should be made aware of (and agree to) any obligations to protect electronic identities and shared secrets used for authentication. 90 These obligations (contractual or otherwise) must be supported by informing clients of how to protect their electronic identities. Authentication 7.5.7 An appropriate level of assurance of the electronic identities of both service and client is required to enable effective authentication of each transaction. In some cases this may require labelling individual transactions and use of workflow management tools. Use of transaction labelling and management tools is particularly important where there is a requirement for non-repudiation or evidence of receipt to support formal or informal obligations. Clients should be informed of, and encouraged to adopt best practice in protecting their systems 91 and any specialist requirements for specific services, and should be made aware of the risks of using unsecured or public 7.5.5 7.5.6 7.5.8 89 Further information on the complexity requirements for credentials and collateral information may be found within the following documents: CESG Infosec Memorandum Number 24, passwords, tokens and biometrics used in combination for identification and authentication of users of government IT systems, Issue 2.1, August 2004. CESG Infosec Memorandum Number 26, passwords for identification and authentication, Issue 2.1, June 2004. CESG Infosec Memorandum Number 27, assessment of the contribution of tokens to multi-factor identification and authentication systems CESG Infosec Memorandum Number 28, performance and assurance standards for biometric systems contributing to multi-element identification and authentication, Issue 1.0, January 2005. 90 91 A list of what these obligations are, supported by a tick-box attached to a statement that the client confirms having read and agreed to the list of obligations, would be sufficient in most cases. For example use of a firewall and antivirus software, employing a patching policy (eg using windows update or similar), using up-to-date browser software, making use of publicly available guidance that is aimed at citizens, etc. e-Government framework for Information Assurance Draft 5.1 Page 63 access systems. Clients should also be informed of any measures to be taken before, during and after a client session. 92 Protection of transactions against impersonation and interception 7.5.9 For authentication at Authentication IL1 or above, it will generally be necessary to secure information exchanges between a client and the e-Government service to protect against man-in-the-middle and other impersonation attacks. 93 Protection might be applied for all of the transactions within a client session, or only for some of these transactions at a level that is tailored to the value of the transaction. This will typically require the use of electronic signing for transactions whose impact level for integrity is Integrity IL1 or above, and/or use of cryptography for transactions at Confidentiality IL1 or above. Normal commercial technologies and techniques should be employed wherever possible to support this requirement. Protection of service against bypass of client credentials 7.5.10 Appropriate measures must be in place to ensure that the e-Government service is suitably robust against the bypass of client credentials. These measures are discussed at Sections 0, 8.1 and 10. Service management of electronic identities 7.5.11 Clear procedures for disenrolment of clients must be in place and supported by clear guidelines for clients of how to disenrol and what the process is for disenrolment. 7.5.12 Clients should be informed of exception-handling procedures that are in place, such how to report theft loss or suspected compromise of credentials and/or collateral information and what the process is for revoking and replacing these (eg how the replacement will be sent and over what timescale). These procedures should be easily accessible to clients, who should be encouraged to use them if necessary. 7.5.13 For some e-Government services, it may be useful to restrict elements of an electronic identity, for example by issuing credentials with a fixed lifespan or automatically revoking or disabling the authorisation of an electronic identity after a defined period of disuse. In some cases it may be useful to establish client usage patterns and disable the authorisation of an electronic identity if usage deviates significantly from this profile. 92 Despite informing clients of best practice other measures, the measures that are in place to protect e-Government services must be designed on the assumption that not all clients will adopt the guidance given and that some client machines will have been compromised. This might, for example, involve use of SSL/TLS and registering the service provider’s public key with a trusted third-party certification authority such as Verisign. 93 Page 64 Authentication and client access Accounting and audit 7.5.14 Accounting logs and audit information should be recorded, supported by appropriate audit procedures to track and forensically examine use of the e-Government service as necessary. This should cover not only transactions between clients and the e-Government service, but should also cover transactions involving government users. Authentication countermeasures The levels of assurance required to support authentication are as follows: • Authentication IL0 has no requirement for any degree of trust in the client’s electronic identity; • Authentication IL1 requires a moderate degree of trust in the client’s electronic identity; • Authentication IL2 requires a substantial degree of trust in the client’s electronic identity; • Authentication IL3 services require the client’s electronic identity to be confirmed beyond reasonable doubt. 7.6.2 Table 7 sets out the specific requirements to support authentication at Authentication IL0 through Authentication IL3. 7.6 7.6.1 e-Government framework for Information Assurance Draft 5.1 Page 65 Authentication IL0 Distribution of client credentials Client authentication Service authentication Prevention of unauthorised access using client credentials Protection against reproduction of client credentials Protection against bypass of client credentials 103 No requirements Might use informal electronic ID. 96 No requirements Authentication IL1 Commercial best practice 94 Basic electronic ID 97 Commercial best practice94 Resistance to theft and unauthorised access using commonly available tools 100 Not possible to recreate elements of a client’s electronic ID using the issuing mechanism itself Implementation in accordance with commercial best practice Authentication IL2 Commercial best practice94 Strong electronic ID 98 Commercial best practice94 Client-side security requirements should be easily achievable by a competent but nonexpert client 101 Reproduction of elements of a client’s electronic ID must require specific attacker technology Implementation compliant with applicable regulatory standards Authentication IL3 Out-of-band distribution of part/all of electronic ID 95 Use of suitably assured 99 products Use of suitably assured99 products Protection of credentials must not be reliant on the client 102 Reproduction of elements of a client’s electronic ID must require manufacturer level technology Implementation subject to successful independent assessment No requirements No requirements No requirements Table 7: authentication countermeasures 94 95 96 97 98 99 For example, use of SSL/TLS with 128/256-bit key or out-of-band distribution of part or all of credential. For example, out-of-band distribution or use of a suitably encrypted digital certificate with out-of-band distribution of a password (eg by post, telephone or text) via suitably assured contact details. For example, to enable personalisation of a service. For example, use of a username and password or digital certificate. For example, use of a digital certificate. CAPS-approved products would be required to protect Authentication IL3 material and are recommended. Where this is not possible and an overwhelming business benefit can be demonstrated, use of commercial best practice equivalent to Authentication IL2 may be accepted in conjunction with limited lifespan authentication tokens and thorough Confidentiality/Integrity IL3 Accounting and Audit measures. This measure is deprecated, owing to the significant degradation of the security provided and is only acceptable where no reasonable alternative procedure is available. For example, ensuring that client information is not transmitted en bloc in clear. This might involve asking the client to provide only a subset of a shared secret such as a password or using dynamic information relating to a recent transaction. Other threats to be protected against should include, as a minimum, Trojans, disk scavenging, keystroke loggers and network sniffing. For example, a credential such as a digital certificate might be protected by a PIN, password or other access control mechanism, and measures should be in place to encourage protection of client machines and networks against malware. For example, a credential might be stored on a token and not exposed to the client machine. Alternatively, on presentation of a credential to a central authentication server, an out-of-band method such as text messaging may be used to transmit a unique one-time password to the client which can then be used to initiate the session. A variation on this theme would be to issue the client with a password generator; this approach is currently favoured by banks and other financial institutions. Requirements for assurance of product, service and system assurance, configuration testing (commercial best practice, penetration testing, etc) and the compliance process are set out at Table 2. 100 101 102 103 Page 66 Authentication and client access This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 67 8 8.1 8.1.1 Confidentiality Overview Confidentiality covers the measures that are required to prevent the unauthorised observation and disclosure of information that is stored and handled by e-Government services. Measures must be in place to protect: • provision of information by clients or government users; • information in transit between a client system and an e-Government service; • information stored by an e-Government services and information that is exchanged between e-Government services; • ancillary information generated as a consequence of e-Government service provision; 104 • disposal and erasure of information. 8.1.2 Clients should be informed of how the information they provide will be used and shared, for instance warning individuals sending information into an HMG domain that their communications may be monitored, recorded and retained. Impact level for confidentiality Confidentiality attracts an impact level which is based on the impact of compromising an individual client’s information, 105 or compromise of an information store. The impact level for confidentiality is calculated using the HMG Impact Table presented at Annex D. Allocation of an impact level for confidentiality must explicitly consider statutory requirements relating to protecting the confidentiality of personal information and communications under the DPA, the Human Rights Act and other legal instruments, and the consequences that a breach of confidentiality might have. 106 Potential Intellectual Property Rights (IPR) issues might also require consideration. The impact of compromising an information store might be greater than the impact of compromising an individual client’s information, due to aggregation of data or prolonged exposure to threats whilst in storage. This may require protection under a more stringent regime (ie may require information stores to be treated as if they were assigned to a higher impact level). For example, systems management information and information on the performance and uptake of e-Government services. This includes information provided to support registration and enrolment as well as information provided during use of the service. This might include prosecution, damage to reputation and other impacts; for example, the Information Commissioner has the power to order the cessation of processing of personal data. 8.2 8.2.1 8.2.2 8.2.3 104 105 106 Page 68 Confidentiality 8.2.4 A small subset of clients with uncommon circumstances may attract a different impact level for confidentiality from the standard clients around whom the service risks and impacts have been determined. 107 There will be similar considerations for integrity and availability. Such exceptions should be identified as part of the service development process and appropriate measures should be put into place to manage such exceptions (offline methods, separate service provision, provision of higher-assurance tokens to high-risk clients, etc). If an e-Government service enables a client to access information that is provided by a third-party, rather than information that is provided directly by the client themselves, then the level of assurance for identity registration for the receiving service must be at least as high as the level of assurance required for the confidentiality of the information provided by the third party. Use of protective markings and descriptors Information that attracts an impact level for confidentiality may be labelled using the PRIVATE descriptor, in the format: [PRIVATE], [Level n], [optional]. 108 n is the impact level for confidentiality and the optional field allows for a description of the type of information. 109 Information that is assessed as requiring Level 0 will not normally attract the PRIVATE descriptor. Within the protectively marked domain, information within the service provision boundary that attracts Confidentiality IL3 should be treated in a manner that is commensurate with RESTRICTED; this information should, however, not be unreasonably withheld from the client that originated the information 110 and for this reason it may not be appropriate to explicitly label this information as RESTRICTED. Threats Data-stores 8.2.5 8.3 8.3.1 8.3.2 8.4 8.4.1 The general threats to the confidentiality of e-Government data-stores are: • that attack groups from outside the service provision boundary may gain access to e-Government services for which they are not authorised; 107 108 For example, the medical details of a celebrity might be of particular interest to the national press, and any resulting publicity from such a disclosure might be embarrassing or cause significant distress. Take-up of the PRIVATE descriptor has been low across central government organisations. Many central government organisations tend to protect e-Government service information assets internally at a level commensurate with RESTRICTED information assets, as this fits in with their existing business practices. The PRIVATE descriptor has found more widespread use across local government, and across other wider public sector organisations which are not bound to the protective marking scheme. For example, medical information concerning an individual might be marked as PRIVATE, Level 3, MEDICAL. See the discussion on clients at Section 3.2. 109 110 e-Government framework for Information Assurance Draft 5.1 Page 69 • that authorised clients of e-Government services may access information that they are not authorised to see; • that attack groups may gain access to back-end systems. 8.4.2 Many of the threats to the confidentiality of data-stores may be countered through suitably assured authentication and access control mechanisms, supported by physical and procedural measures. Information in transit 8.4.3 The general threats to the confidentiality of information in transit include inadvertent disclosure, misdirection and interception of electronic communications. Many of these threats may be countered using suitable authentication and encryption mechanisms. General requirements Appropriate physical and procedural measures must be in place as elements of a multi-layer approach to confidentiality, as discussed at Section 3.3. Access to any registration and enrolment information, and to elements relating to a client’s electronic identity that are stored within an e-Government service data-store, must be protected in line with the measures as set out at Sections 5-7. For Confidentiality IL1 and above, access controls must be implemented, in line with the requirements set out at Section 7, to ensure that a user can access only those elements of a service for which they are enrolled and authenticated. Access controls should be accounted for and regularly audited to keep track of client access to information assets, supported by appropriate measures to address any identified compromise. The integrity and availability of the accounting logs themselves must be protected to a level of assurance which is, as a minimum, commensurate with the confidentiality of the information assets that they support. Confidentiality IL0 countermeasures General 8.6.1 At Confidentiality IL0 no explicit protection is needed, though care should still be taken to adopt good system practice. Access control and user access management 8.6.2 No access control mechanisms are required, although informal access controls may be implemented. 8.5 8.5.1 8.5.2 8.5.3 8.5.4 8.6 Page 70 Confidentiality Confidentiality of information in storage, use and transit 8.6.3 No explicit protection of information in transit and information stores is needed, although care should sill be taken to adopt good system practice. Any personal details submitted by a client must be properly protected in accordance with the DPA. Effective accounting and audit 8.6.4 No specific accounting and audit functionality is required. Service protection 8.6.5 8.6.6 8.6.7 Adoption of normal good system practice for implementing and managing network connections must be applied to prevent electronic attack. There are no specific requirements for detection of electronic attack, although checking of information-stores against regular backups is recommended. Measures in place to react to electronic attack must include an assessment should be made of whether any damage, including loss of data integrity, has occurred, and recovery of information-stores from the last known good backup. The system should be restarted, as far as possible any damaged data should be reloaded and external connections restarted. Confidentiality IL1 countermeasures General 8.7.1 At Confidentiality IL1 attention must be paid to correct system operation and the use of basic access control. It is generally acceptable to use the in-built security features of commercial products, configured correctly, but without enhancement. Information displayed on a screen or printed out should be afforded an equivalent level of protection using physical and procedural security measures. Confidentiality of information in storage, use and transit 8.7.3 Information within the service provision domain must be handled responsibly and securely. Personal details submitted by a client must be properly protected in accordance with the DPA. Some e-Government services will require enhanced measures to protect the real-world identity of clients. 111 8.7 8.7.2 111 For example, services to support reporting of fraud or criminal activities e-Government framework for Information Assurance Draft 5.1 Page 71 8.7.4 Appropriate measures must be in place to protect the confidentiality of information in transit between the client and the e-Government service. 112 Appropriate protection is also required to protect information exchanges between e-Government services. In order to handle information assets effectively, service providers must ensure that there is a permanent binding between transaction material and the security information that represents its confidentiality impact level, regardless of the extent to which this information is split up for processing. Appropriate measures must be in place to ensure secure erasure and disposal of information assets once these are no longer required, and to ensure that credentials which allow access to information assets are revoked when a client is disenrolled 113 from a service. The appropriate Security Operating Procedures (SyOps) should be recorded in the RMADS. The confidentiality of information assets might be compromised through faulty hardware and software components. Use of components which have been assured through the CCT Mark, CAPS, or a similar scheme should be preferred during system design, to give confidence to system designers that the Vendor’s security functionality claims have been validated. Encryption of data in storage and transit might be required for certain niche areas. 114 Effective accounting and audit 8.7.5 8.7.6 8.7.7 8.7.8 8.7.9 Basic client-related information should be recorded. 115 8.7.10 The capability to carry out basic display and analysis of the accounting records should be provided. Service protection 8.7.11 Prevention of electronic attack on e-Government services should be provided by: • User application configuration: all government user applications capable of processing imported material shall be configured to do so safely. For instance, word processing and spreadsheet applications should preferably prevent automatic macro execution without prior user permission or a detection strategy should be in place. 112 113 This might include, for example, the use of SSL/TLS to encrypt a session, supported by appropriately assured credentials for both the client and the e-Government service. Disenrolment might occur, for example, because the client no longer wishes to receive an e-Government service or is no longer eligible for that service, and would typically be accompanied by sending a confirmation to the client. For example, encryption of password files For example, client identifier, time of service access, transaction used, success or failure of transaction 114 115 Page 72 Confidentiality • Import restrictions: the import of information objects from another domain should be limited to information object types reasonably required to meet business needs; all imported objects should be screened for recognisable structures such as virus signatures. An anti-virus strategy with timely updates should be implemented, subjecting imported information objects to content analysis. • User empowerment: the export of information objects from one domain to another should be limited to information object types reasonably required to meet business needs. • Detection of electronic attack on e-Government services should be provided at this level by: • System monitoring: standard system-provided activity monitors should be regularly examined to ascertain whether there is any suspicious activity or pattern of activities that might indicate an electronic attack is being conducted. At this level, consideration should be given to the use of host and/or network based intrusion detection systems. • Reviewing accounting logs: standard system-provided accounting logs should be reviewed by appointed security personnel for the system to ascertain whether there is any activity or pattern of activities that might indicate an electronic attack has occurred. 8.7.12 Reaction to electronic attack on e-Government services should be provided at this level by: • Incident response plan: an incident response plan, incorporating actions that may range from immediate restoration of service to partial restoration or suspension of service, should be documented and subjected to regular testing and review. • Controlled closedown: a controlled connection closedown process should be available, maintaining the provision of essential business services as far as possible. • Impact assessment: an assessment should be made of whether any damage, including loss of data integrity, has occurred and a recovery action plan drawn up. • Recovery: the system should be restarted; as far as possible any damaged data should be reloaded and external connections restarted. 8.7.13 Appointed security personnel for the system should examine all incidents of electronic attacks and determine whether any additional electronic or procedural countermeasures should be put in place. e-Government framework for Information Assurance Draft 5.1 Page 73 8.8 Confidentiality IL2 countermeasures General 8.8.1 At Confidentiality IL2 auditable system operation and the use of stringent access control are required. The use of suitably assured 116 commercial cryptographic products to provide access control is appropriate for some purposes is required at this level. An independent IT health check should be considered for all systems hosting e-Government services. Information displayed on a screen or printed out should be afforded an equivalent level of protection using physical and procedural security measures. Confidentiality of information in storage, use and transit 8.8.2 8.8.3 The following measures must be in place, over and above those for Confidentiality IL1, to protect the confidentiality of information in storage, use and transit. Government users who have access to personal client information must be subject to at least as stringent requirements as clients. The information accessible to system administrators must be the minimum necessary to meet the business needs. Commercial operating system access controls must be employed for administrator access to systems. Archived data must be stored such that only authorised and nominated individuals (in accordance with Data Protection law) have the right to access the data. Strong access controls are required for access to bulk archive data. This may be achieved by physical or electronic access controls. Encryption of archives may permit the strong bulk data access control requirements to be reduced to a more tractable key management task. Data stored in a live environment (eg. on a database) must be protected by strong access control. Encryption mechanisms present within the commercial operating system and database products may offer benefits but must be used only after their value has been established. Information at Confidentiality IL2 should be processed on a system to which only authorised government users have physical access and should be password protected. 8.8.4 8.8.5 8.8.6 8.8.7 8.8.8 8.8.9 116 Cryptographic products to protect information at Confidentiality IL2 must be assured using the CCT Mark or an equivalent scheme, to EAL2 or above. Page 74 Confidentiality 8.8.10 Processes handling information at Confidentiality IL2 should be routinely penetration tested to check for any inadvertent data leakage. 8.8.11 The required protection for data in transit depends upon the nature of the communications path. For services provided over open networks, such as the Internet, some form of commercial encryption is appropriate. In the case of web-based services, HTTPS will usually be the most convenient protocol, owing to its inclusion in commercial web browsers. S/MIME is currently the standard for secure email. Effective accounting and audit 8.8.12 Measures to support accounting and audit will be similar to those for Confidentiality IL1, but accounting logs must be protected at a level appropriate for Confidentiality IL2 and more regular auditing will be required. Service protection 8.8.13 Prevention of electronic attack on e-Government services should be provided by: • User application configuration: all government user applications capable of processing imported material shall be configured to do so safely. For instance, word processing and spreadsheet applications should preferably prevent automatic macro execution without prior government user permission or a detection strategy should be in place. • Import restrictions: a business case and risk assessment should be provided for each information type to be imported; all imported objects should be screened for recognisable structures such as virus signatures. An anti-virus strategy with timely updates should be implemented, subjecting imported information objects to content analysis. All import requests shall be recorded to meet specified audit requirements enabling trend analysis to be performed. Website access should be granted explicitly subject to a business case, and limited to known and ‘trusted’ sites. Active web content should be removed on import or executed in a controlled safe space. E-mail attachments should be limited to permitted types. • User empowerment: a business case and risk assessment should be provided for each information type to be exported. • Export restrictions: government users must be made aware of all items selected for export, as hidden information might be included (such as deleted text in a word processor file). 8.8.14 Detection of electronic attack on e-Government services should be provided at this level by: • Intrusion detection: host and/or network based intrusion detection systems should be used, in addition to the monitoring of standard system-provided activity monitors, to ascertain whether there is any suspicious activity or e-Government framework for Information Assurance Draft 5.1 Page 75 pattern of activities that might indicate an electronic attack is being conducted. • Reviewing accounting logs: standard system-provided accounting logs should be reviewed by appointed security personnel for the system, to ascertain whether there is any activity or pattern of activities that might indicate an electronic attack has occurred. At this level, consideration should be given to the use of automated audit tools. 8.8.15 Reaction to electronic attack on e-Government services should be provided at this level by: • Incident response plan: an incident response plan, incorporating actions that may range from immediate restoration of service to partial restoration or suspension of service, should be documented and subjected to regular testing and review. • Controlled closedown: a controlled connection closedown process should be available, maintaining the provision of essential business services as far as possible. • Impact assessment: for each electronic attack identified, an assessment should be made of whether any damage, including loss of data integrity, has occurred and, if necessary, a specific recovery action plan drawn up in line with the guidance in the incident response plan. • Recovery: the system should be restored; as far as possible any damaged data should be reloaded and external connections restarted. 8.8.16 Appointed security personnel for the system should examine all incidents of electronic attacks and determine whether any additional electronic or procedural countermeasures, including changes to the incident response plan, should be put in place. Confidentiality IL3 countermeasures General 8.9.1 At Confidentiality IL3 auditable system operation and the use of stringent access control is required. Use of cryptography to provide access control is anticipated at this impact level, as discussed at Section 7. An independent IT health check is required at Confidentiality IL3. Information displayed on a screen or printed out should be afforded an equivalent level of protection using physical and procedural security measures. Confidentiality of information in storage, use and transit 8.9.3 There is a strong requirement for protection of data via access control: • Providers and system administrators of e-Government services who have access to personal client information should be subject to at least as 8.9 8.9.2 Page 76 Confidentiality stringent requirements as clients. The information accessible to system administrators should be the minimum necessary to meet the business needs. • Consideration should be given to ensuring that all government users of systems processing or handling information at Confidentiality IL3 should be subject to a Basic Check security clearance. • Commercial operating system access controls should be employed for administrator access to systems. • Archived data should be stored such that only authorised and nominated individuals (in accordance with Data Protection law) have the right to access the data. • Strong access controls are required for access to bulk archive data. This may be achieved by physical or electronic access controls. Encryption of archives may permit the strong bulk data access control requirements to be reduced to a more tractable key management task. 8.9.4 Data stored in a live environment (eg on a database) should be protected by strong access control. Encryption mechanisms present within the commercial operating system and database products may offer benefits but should be used only after their value has been established. Information that attracts Confidentiality IL3 should only be processed on a system to which authorised government users have physical access and should be password protected. Processes handling information that attracts Confidentiality IL3 should be tested to check for any inadvertent data leakage. The required protection for data in transit depends upon the nature of the communications path. For services provided over open networks, such as the Internet, some form of commercial encryption is appropriate. In the case of web-based services, HTTPS will usually be the most convenient protocol, owing to its inclusion in commercial web browsers. S/MIME is currently the standard for secure email. The details of how these protocols are implemented must be considered by the service provider. 117 Effective accounting and audit 8.9.8 8.9.9 Relevant client-related information should be recorded for each transaction. 118 Capabilities to carry out display and detailed data-mining and analysis of the accounting records must be provided. A discussion of the proper implementation of HTTPS and S/MIME is provided within CESG Infosec Manual T, passwords, transport layer protocol – implementation recommendations for HMG protectivelymarked material, Issue 1.0, January 2001. For example, client identifier, time of service access, transaction used, success or failure of transaction, current transaction status. 8.9.5 8.9.6 8.9.7 117 118 e-Government framework for Information Assurance Draft 5.1 Page 77 Service protection 8.9.10 Prevention of electronic attack on e-Government services should be provided at this level by: • User application configuration: all user applications capable of processing imported material shall be configured to do so safely. For instance, word processing and spreadsheet applications should preferably prevent automatic macro execution without prior government user permission or a detection strategy should be in place. • Import restrictions: a business case and risk assessment should be provided for each information type to be imported; all imported objects should be screened for recognisable structures such as virus signatures. An anti-virus strategy with timely updates incorporating anti-virus products (the use of two products should be considered) should be implemented, subjecting imported information objects to content analysis. All import requests shall be recorded to meet specified audit requirements enabling trend analysis to be performed. Website access should be granted explicitly subject to a business case, and limited to known and ‘trusted’ sites. Active web content should be removed on import or executed in a controlled safe space. E-mail attachments should be limited to permitted types. • User empowerment: a business case and risk assessment should be provided for each information type to be exported. • Export restrictions: government users must be made aware of all items selected for export, as hidden information might be included (such as deleted or original text in a word processor file). 8.9.11 Detection of electronic attack on e-Government services should be provided at this level by: • Intrusion detection: host and/or network based intrusion detection systems should be used, in addition to the monitoring of standard system-provided activity monitors, to ascertain whether there is any suspicious activity or pattern of activities that might indicate an electronic attack is being conducted. • Reviewing accounting logs: automated audit tools should be used by appointed security personnel for the system to examine standard systemprovided accounting logs to ascertain whether there is any activity or pattern of activities that might indicate an electronic attack has occurred. 8.9.12 Reaction to electronic attack on e-Government services should be provided at this level by: • Incident response plan: an incident response plan, incorporating actions that may range from immediate restoration of service to partial restoration or suspension of service, should be documented and subjected to regular testing and review. There should be a properly trained Computer Incident Response Team (CIRT). Page 78 Confidentiality • Incident recovery procedures: there should be detailed incident recovery operating procedures to be followed in the event of an attack, based on the incident response plan. • Controlled closedown: a controlled connection closedown process should be available, maintaining the provision of essential business services as far as possible. • Impact assessment: for each electronic attack identified, an assessment should be made of whether any malicious damage, including loss of data integrity, has occurred and, if necessary, a specific recovery action plan drawn up in line with the guidance in the incident recovery procedures. • Recovery: the system should be restored; as far as possible any damaged data should be reloaded and external connections restarted. 8.9.13 Appointed security personnel for the system should examine all incidents of electronic attacks and determine whether any additional electronic or procedural countermeasures, including changes to the incident response plan and/or incident recovery procedures, should be put in place. e-Government framework for Information Assurance Draft 5.1 Page 79 9 9.1 9.1.1 Integrity Overview Integrity covers ensuring and maintaining the accuracy of information that is stored and handled by e-Government services. Measures must be in place to ensure: • the accuracy of information provided by clients or government users and the ability of all parties to rely on that information to support transactions where required; this includes evidence to support informal, 119 formal or legally binding agreements between parties; • protection of information provided by clients or government users; • protection of information in transit between a client system and an e-Government service; • protection of information stored by an e-Government services and information that is exchanged between e-Government services; • protection of ancillary information generated as a consequence of electronic service provision. 120 9.1.2 Integrity depends upon protection of the e-Government service provision domain as a whole against external attack, and on the use of robust and reliable business service applications and infrastructure. Impact level for integrity Integrity attracts an impact level which is based on the impact of • compromising the accuracy of an information store or of an individual client’s information; • not having sufficient confidence in the integrity of information to support legally binding commitments 121 , including: • • • commitments made by government to the client; commitments made by the client to government; ensuring an appropriate level of proof to support trust service transactions. 9.2 9.2.1 119 “Informal” agreements may include, for example, email correspondence where one party promises to conduct an activity. Although this might not constitute a formal or binding agreement, non-repudiation of such discussions may be useful in the case of a dispute. For example, systems management information and information on the performance and uptake of e-Government services. Similar considerations apply for less formal commitments. 120 121 Page 80 Integrity 9.2.2 9.2.3 The impact level for integrity is calculated using the HMG Impact Level table provided at Annex D. There is a reasonable overlap between the countermeasures that support integrity and those that support confidentiality, in that effective access control and exception handling mechanisms are required. As a result of the requirement for effective access control, a transaction that requires a high level of assurance for integrity is likely to require an equivalent or higher level of client authentication. If an e-Government service provides clients with benefits based on the information they have provided, then the impact levels for identity registration and enrolment must be at least as high as that for integrity. The mapping between identity registration and integrity for such cases is set out at the lefthand table within Table 4 at Section 6 and also extends to enrolment. When allocating an impact level for integrity, service providers must consider the effect of inadvertent disclosure of sensitive information on the public perception of security and reliability for e-Government services. Similarly, a malicious attack on the integrity of a seemingly low value service 122 might have a disproportionate effect on the public perception of e-Government services as a whole. Threats There is significant overlap between the general threats to the confidentiality of information assets (as discussed at Section 8.4) and the threats to the integrity of those assets. Threats that are specific to integrity relate to nonrepudiation of contractually binding transactions, evidence of receipt and trusted commitment services. General requirements General 9.2.4 9.2.5 9.3 9.3.1 9.4 9.4.1 There is a degree of overlap between the countermeasures that support confidentiality and those that support the integrity of services and their information assets. Physical and procedural measures, access control and user access management, effective accounting and audit and service protection measures must all be in place. The countermeasures that are required for these aspects of e-Government services, to support integrity at a given level of assurance, must be commensurate with the countermeasures implemented to support confidentiality at an equivalent level of assurance, as discussed at Section 8. 122 For example, defacing a government web site or altering the content of publicly available government information. e-Government framework for Information Assurance Draft 5.1 Page 81 9.4.2 Similarly, use of components which have been assured through the CCT Mark, CAPS, or a similar scheme should be preferred during system design, to give confidence that these will function as stated by the Vendor. Clients and other users of e-Government services must be confident in the correctness, completeness, and authority of information and advice received in an e-Government service transaction and that anything they submit will be correctly received. This covers both erroneous information and information inadvertently or maliciously altered during storage, processing or transit. Non-repudiation 9.4.3 9.4.4 There must be a sufficient level of assurance that transactions enacted by a client can only have been carried out by the rightful holder of an electronic identity. This frustrates attempted denial of responsibility for fraudulent use. Moreover, clients need to be assured that the service providers cannot repudiate the service provider’s part of a transaction. Equally service providers might wish to be assured that government cannot repudiate its part in a transaction either. Threats to the non-repudiation of binding transactions may be met by appropriate levels of evidence requirements for identity registration, enrolment and authentication, supported by appropriately assured labelling and management of transactions. This may include a requirement to retain archive data. There is a requirement to establish what information should be retained and for how long. Any responsibility on the client for retention of evidence must be clearly communicated. Where evidence is required to be retained securely for an extended period, consideration must be given to the natural degradation of encryption technology over time. A transaction may be comprised of several elements, involving more than one department or process. 123 Measures to support non-repudiation might be required at a number of points for such a transaction. Such measures would enable the relevant parties to determine who originated the transaction, whether the transaction received matches the transaction sent, and whether the transaction was accepted by the recipient. For such cases, service providers will need to determine not only what measures are required, but also at what points and how to coordinate them. Non-repudiation may also be required for other communications between e-Government services and trusted third-parties that are necessary to provide an end-to-end service. Evidence of receipt 9.4.5 9.4.6 9.4.7 Clients and other users (including service providers) of the services must be able to demonstrate that transactions submitted have actually completed and that they cannot be falsely accused of failure to submit required returns or deny receipt of information. 123 For example, a change of address request that spans multiple e-Government services. Page 82 Integrity Trusted commitment service 9.4.8 Authorised clients of e-Government services must be confident that (for example) their authorities for payment will be properly controlled and are not vulnerable to fraudulent use of their means of payment, subject to the clients keeping relevant credentials or other personal information secure. Integrity IL0 countermeasures Integrity of information 9.5.1 Physical and procedural measures, access control, user access management, accounting and audit and service protection measures in line with those required to support Confidentiality IL0 must be in place. Existing protocols should be used to provide simple protection for data in transit. It should be possible to determine where modification has occurred. 124 Non-repudiation 9.5.3 9.5.4 No measures for non-repudiation are required at this level. If simple assurance that a transaction or an object originated from a purported source is desired, the electronic and/or real-world identity of the originator and, optionally, a transaction reference number, might be used to support this. No additional mechanisms over and above the normal service elements are required. For example, email identified as originating from user@dept.gsi.gov.uk may be assumed to originate from "user"; for web services, the page presented by http://www.dept.gov.uk/ may be assumed to originate from that department. Evidence of receipt 9.5.6 9.5.7 Existing service mechanisms are used to provide simple assurance that an object has been received by the recipient. 125 No additional mechanisms over and above the normal service elements of the system are provided. For example, an email reply stating that a transaction has been received or the display of a web page acknowledging a request is sufficient. 9.5 9.5.2 9.5.5 124 125 For example, document format errors or incomplete web pages The measures here only give evidence that the transaction has been received by the recipients communications equipment or electronic address. If evidence is required that a specified real-world identity has received the transaction, a higher level of trust should be used for which the receipt is bound to the recipient identity. e-Government framework for Information Assurance Draft 5.1 Page 83 9.6 Integrity IL1 countermeasures Integrity of information 9.6.1 Physical and procedural measures, access control, user access management, accounting and audit and service protection measures in line with those required to support Confidentiality IL1 must be in place. Use of message integrity features and checksums within standard communications protocols provide adequate protection against accidental corruption of a message. If greater assurance in the message integrity is required, informal mechanisms involving passwords and PINs may be adopted. Non-repudiation 9.6.2 9.6.3 Effective non-repudiation at Integrity IL1 is unlikely to be achievable. Measures that may be applied are essentially as for Integrity IL0, with some review of the system configuration to ensure that the standard services and protocols are not obviously vulnerable to attack. Additional degrees of trust may be achievable by the use of informal technical measures such as the agreement of passwords via out-of-band routes. 126 These passwords may then be used with simple encryption or signing tools to demonstrate possession of the password to correspondents. Another simple technique to reduce the scope for later repudiation is to provide the client at intervals with a list of transactions to date. It is important that expert guidance be sought when setting up non-repudiation schemes, as the additional trust achieved is often illusory unless the scheme is carefully constructed. Such schemes are rarely foolproof, it is therefore important that the limits of such schemes are understood and accepted by parties to the transaction. However, these methods may support a useful extra degree of trust in specific cases and provide the client with greater confidence. Appropriate accounting log files should be kept, showing transaction times and records of system operation. Evidence of receipt 9.6.4 9.6.5 9.6.6 9.6.7 Evidence of receipt would typically be achieved at this level by returning evidence of possession of the message to the originator under a nonrepudiation service. Close attention to system configuration possibly supported by informal mechanisms may be used to achieve this in line with the Integrity IL1 non-repudiation approach. 126 For example, printed correspondence. Page 84 Integrity 9.7 Integrity IL2 countermeasures Integrity of information 9.7.1 Physical and procedural measures, access control, user access management, accounting and audit and service protection measures in line with those required to support Confidentiality IL2 must be in place. A transaction or a digest of the transaction, signed using an appropriately strong credential, must be used to provide evidence of integrity. 127 The signature must be verified by the recipient of the transaction. Modifications or errors in the signed object, whether accidental or deliberate, will cause verification of the signature to fail. Non-repudiation 9.7.2 9.7.3 9.7.4 9.7.5 9.7.6 9.7.7 9.7.8 9.7.9 A transaction or a digest of the transaction, signed by the originator, must be used to provide evidence of origin. The signature must be verified by the recipient of the transaction, or by a third party. Ownership of any public keys must be verified by a recognised entity, which may be the recipient or some other party. Appropriate accounting log files must be kept, showing transaction times and records of system operation. At this level, it may be appropriate to include a means for providing a record of the transaction as seen by the client. Evidence of receipt 9.7.10 Trusted commitment services require that the commitment information provided be protected with an appropriate level of non-repudiation, proof-ofreceipt and integrity. 9.8 Integrity IL3 countermeasures Integrity of information 9.8.1 Physical and procedural measures, access control, user access management, accounting and audit and service protection measures in line with those required to support Confidentiality IL3 must be in place. 127 See the discussion on Authentication at Section 7. e-Government framework for Information Assurance Draft 5.1 Page 85 9.8.2 The measures to protect the integrity of information at Integrity IL3 are similar to those for Integrity IL2 except that a stronger credential will generally be required. 128 Non-repudiation 9.8.3 The measures to support non-repudiation at Integrity IL3 are similar to those for Integrity IL2, with the mechanism used to identify ownership of the public key provided by approved mechanisms. In addition, products and systems must provide appropriate protection for private keys and use standardised formats and protocols. Appropriate accounting log files must be kept, showing transaction times and records of system operation. At this level, it may be appropriate to include a means for providing a record of the transaction as seen by the client. Evidence of receipt 9.8.4 9.8.5 9.8.6 Evidence of receipt would typically be achieved at this level by a response demonstrating receipt returned to the transaction originator: • The returned response must be protected by an integrity service and a non-repudiation service. • The response may be generated manually or automatically. 9.8.7 Evidence of receipt may be provided by a system that can provide a combination of a Integrity IL3 non-repudiation and Integrity IL3 integrity services. 128 See the discussion on Authentication at Section 7. Page 86 Integrity This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 87 10 10.1 Availability Overview 10.1.1 Availability covers the measures that are required to ensure that clients can access e-Government services and transact with those services as required. This involves protection of data-stores and putting appropriate business continuity plans in place to protect online service provision and to provide offline alternatives in the event of failure. 10.2 10.2.1 Impact level for availability Availability attracts an impact level which is based on the impact of an authorised client not being able to transact with an e-Government service. The impact level for availability is calculated using the HMG Impact Level table presented at Annex D. 10.2.2 A small subset of clients with uncommon circumstances may attract a different impact level for availability from the standard clients around whom the service risks and impacts have been determined. 129 There will be similar considerations for confidentiality and integrity. Such exceptions should be identified as part of the service development process and appropriate measures should be put into place to manage such exceptions. 10.2.3 The implications of e-Government service failure may vary depending on factors such as the time of year. For example, outage of an application allowing electronic submission of tax returns is likely to be much more of a problem in the week before the tax return filing deadline than at other times in the year. Such services will attract a disproportionately high impact level for availability. This may be mitigated by having a business continuity plan which makes provision for such eventualities (for example, by enabling alternative offline means of service provision and allowing a relaxation of deadlines in the event that the service fails at an inopportune time). If such a plan were in place, then the availability impact level would be reduced accordingly. 10.2.4 When allocating an impact level for availability, service providers must consider the effect of non-malicious service failure on the public perception of security and reliability in e-Government services. 10.3 Threats 10.3.1 The general threats to the availability of e-Government data-stores and information in transit are: • that unauthorised attackers from outside the service provision boundary may disrupt e-Government services by bypassing boundary protection 129 For example, identity and address details of “at risk” groups who may be in need of emergency medical care. Page 88 Availability measures, attacking connected systems, attacking the internet or other relevant information environment, misusing security measures, information overload attacks, etc; • that authorised clients of e-Government services will deliberately or accidentally compromise these services; • that data-stores will be subject to unforeseen failure, physical attack or natural disasters. 10.4 10.4.1 General requirements There is a degree of overlap between the countermeasures that support confidentiality and those that support the availability of services and their information assets. Physical and procedural measures, access control and user access management, effective accounting and audit and service protection measures must all be in place. The countermeasures that are required for these aspects of e-Government services, to support availability at a given level of assurance, must be commensurate with the countermeasures implemented to support confidentiality at an equivalent level of assurance. 10.4.2 Similarly, use of components which have been assured through the CCT Mark, CAPS, or a similar scheme should be preferred during system design, to give confidence that these will function as stated by the Vendor. 10.5 Availability IL0 countermeasures Service availability 10.5.1 Normal good system practice must be adopted in respect of designing, implementing and managing the service. It is likely that no explicit availability measures will be required. Information availability 10.5.2 No special measures need be taken to ensure data backup or continuity of service following an interruption to service. Business continuity must still, however, be considered. 10.5.3 In particular, no special measures need to be taken to recover partially completed transactions, other than for those that affect the integrity of existing information. 10.6 Availability IL1 countermeasures Service availability 10.6.1 Availability for the service must be compatible with the assessment of the business need. Uptime requirements will vary depending on the service to be provided, but indicative availability requirements would generally be expected e-Government framework for Information Assurance Draft 5.1 Page 89 to be better than 99% uptime with no unplanned service break of more than 20 minutes and no more than 1 unplanned service break in any 24 hour period. 10.6.2 Careful consideration must be given to sizing of the communications and information systems so as not to compromise availability. The sizing must be based on realistic estimates of demand for the service. Alternative communications plans that can be switched in within the timescale appropriate to the business need must be available. It is likely that immediate failover will not be necessary. 10.6.3 10.6.4 Battery backup must be provided to allow ‘soft’ failure with power recovery achievable within the timescale appropriate to the business need. 10.6.5 A configuration management plan and processes covering the service must be designed and implemented. Configuration changes must be approved by the service manager before implementation. Software must only be introduced with the approval of the service manager. A failure impact analysis must be carried out and recorded for all information and communication system components. This must be reviewed in the event of significant configuration changes. 10.6.6 10.6.7 A business continuity plan must be in place and subject to regular rehearsal and review. The plan must address: management roles and responsibilities for business continuity; recovery procedures and audit trail; security specific recovery actions. Information availability 10.6.8 No special measures need be taken to ensure data backup or continuity of service following an interruption to service. In particular, no special measures need to be taken to recover partially completed transactions, except for those that affect the integrity of existing information. Information back up must follow commercial best practice and enable restoration of all relevant information to within one week of the current date. Commercial best practice must be followed with a full weekly backup and daily incremental backups. The restoration process should be documented in the business continuity plan and tested regularly. 10.6.9 10.6.10 A process must be available to provide access for a client to his/her client account in the event of loss of a password. Page 90 Availability 10.7 Availability IL2 countermeasures Service availability 10.7.1 Availability for the business service to be provided must be compatible with the assessment of the business need. Current good commercial architecture must be implemented. 130 Service Level Agreements (SLAs) for externally provided services must be set to meet the availability requirements for transactions and information items. Uptime requirements will vary depending on the service to be provided, but indicative availability requirements would generally be expected to be of order 99.5% uptime with no unplanned service break of more than 15 minutes and no more than 1 unplanned service break in any 24 hour period. Particular consideration must be given to the availability requirements for accounting logs. Careful consideration must be given to sizing of the communications and information systems so as not to compromise availability. The sizing must be based on realistic estimates of demand for the e-Government service. 10.7.2 10.7.3 Uninterruptible Power Supplies (UPS) must be used to allow ‘soft’ failure. Power recovery must be achievable within the timescale appropriate to the business need at Availability IL2. 10.7.4 Alternative communications paths that can be switched in within the timescale appropriate to the business need at Availability IL2 must be available. At this level consideration must be given to the use of alternative communications paths with immediate failover. 10.7.5 A configuration management plan and processes covering the communications and information systems providing the service must be designed and implemented. Operational and security configuration must be checked for compliance with documentation, supplemented by a penetration test in accordance with commercial best practice. Configuration changes must be approved by the service manager before implementation and must be subject to secure audit (technical or procedural). Software must only be introduced with the approval of the service manager and a full inventory of all hardware and software and a network diagram showing all approved connections must be maintained. 10.7.6 Failure impact analysis must be carried out and recorded for all information and communications components. This must be reviewed in the event of significant configuration changes. No upgrades will be permitted without prior offline testing and assessment. 10.7.7 A commercial best practice self-test process must be in place. 130 For example, use of multi-tier, high redundancy architectures (eg redundant processor configurations, mirrored disks, RAID arrays etc) and geographical distribution. e-Government framework for Information Assurance Draft 5.1 Page 91 10.7.8 A business continuity plan must be in place and subject to regular rehearsal and review. The plan must address: management roles and responsibilities for business continuity; recovery procedures and audit trail; security specific recovery actions. Information availability 10.7.9 It is required to identify partially complete transactions that might have failed in the event of non-malicious failure and to inform the parties involved accordingly. However, no special measures need be taken to recover partially completed transactions except for those that affect the integrity of existing information. 10.7.10 Information back up must enable restoration of all relevant information to within one day of the current data. Commercial best practice must be followed with a full weekly backup and daily incremental backups, preferably supported by a continual backup process. The backup must be compared against the original before the backup media is stored offsite. The restoration process must be documented in the business continuity plan and tested regularly. 10.7.11 Baseline level cryptographic checksums or secure software isolation for system software, configuration data and storage facilities must be provided. A secure self-test process must be undertaken regularly using these facilities. 10.7.12 A process must be available to provide access for a client to his/her client account in the event of loss of a password or access token. 10.8 Availability IL3 countermeasures Service availability 10.8.1 The availability of the overall business service and individual transactions must be compatible with the assessment of the business need. Current good commercial practice architecture design must be used. 131 SLAs for externally provided services must be set to meet the availability requirements for transactions and information assets. Uptime requirements will vary depending on the service to be provided, but indicative availability requirements for the service would generally be expected to be of order 99.9% uptime with no unplanned service break of more than 5 minutes and no more than 1 unplanned service break in any 48 hour period. Particular consideration must be given to the availability requirements for accounting logs. 10.8.2 Careful consideration must be given to sizing of the communications and information systems so as not to compromise availability. The sizing must be based on realistic estimates of demand for the e-Government service. 131 For example, use of multi-tier, high redundancy architectures (eg redundant processor configurations, mirrored disks, RAID arrays etc) and geographical distribution Page 92 Availability 10.8.3 UPS must be used to allow ‘soft’ failure. Power recovery must be achievable within the timescale appropriate to the business need at Availability IL3. 10.8.4 Alternative communications paths that can be switched in within the timescale appropriate to the business need at Availability IL3 must be available. It is anticipated that at this level alternative communications paths with immediate failover will be required. 10.8.5 A configuration management plan and processes covering the communications and information systems providing the service must be designed and implemented. Operational and security configuration must be checked for compliance with documentation, supplemented by a CHECK process. Configuration changes must be approved by the service manager before implementation and must be subject to secure audit (technical or procedural). Software must only be introduced with the approval of the service manager and a full inventory of all hardware and software and a network diagram showing all approved connections must be maintained. 10.8.6 Failure impact analysis must be carried out and recorded for all information and communications components. This must be reviewed in the event of significant configuration changes. No upgrades will be permitted without prior offline testing and assessment. 10.8.7 A commercial best practice self-test process should be in place. 10.8.8 A business continuity plan should be in place and subject to regular review. The business continuity plan should be subject to regular rehearsal. The plan should address: management roles and responsibilities for business continuity; recovery procedures and audit trail, covering the system, communications and transactions; security specific recovery actions. Information availability 10.8.9 It is required to identify and recover partially complete transactions that might have failed in the event of non-malicious failure and to inform the parties involved accordingly. 10.8.10 Information back up must enable restoration of all relevant information to within one day of the current data, and preferably more regularly than this. Commercial best practice must be followed with a full weekly backup and daily incremental backups, preferably supported by a continual backup process. The backup must be compared against the original before the backup media is stored offsite. The restoration process must be documented in the business continuity plan and tested regularly. 10.8.11 Baseline level cryptographic checksums or secure software isolation for system software, configuration data and storage facilities must be provided. A secure self-test process must be undertaken regularly using these facilities. e-Government framework for Information Assurance Draft 5.1 Page 93 10.8.12 A process must be available to provide access for a client to his/her client account in the event of loss of an access token. Page 94 Availability This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 95 11 11.1 11.1.1 Worked examples General This section provides some worked examples to demonstrate the application of the method set out within this document. These services are purely hypothetical and are not intended to bear any relation to specific real-world services in current operation. 11.1.2 The worked examples have been deliberately simplified and presented at an overview level of detail to aid clarity. 11.2 Hypothetical pseudonymous medical screening service STEP 1: define the service Purpose 11.2.1 A pseudonymous medical screening service 132 allowing clients to register for health screening, and receive their test results, electronically. Client requirements 11.2.2 The high-level actions that a client may wish to conduct in support of this service may include the following: • find out information about the service electronically; • book an appointment electronically; • be contacted electronically to obtain the test results; 11.2.3 Other features that a client might require include the following: • be able to obtain the service under a pseudonym, and not reveal any details of their real-world identity to the service; • have confidence that they are receiving the correct test results; • have their test results kept confidential. Service requirements 11.2.4 The high-level requirements for the service are as follows: • no level of assurance is required in the clients real-world identity; • the eligibility of a client does not need to be established, as the service is freely available; 132 This example assumes that the service is screening for non-life-threatening diseases. Page 96 Worked examples • a persistent electronic identity for the client is required, which provides a substantial degree of assurance to the e-Government service that it is the same client returning; • evidence that the client actually communications (if they did so). Service provision environment Service provision environment Information assets Description • client pseudonyms and linked electronic identities; • test results linked to an electronic identity; • history details, for example, date of test, doctor consulted etc. Assumptions • identity registration, booking appointments, notification of further appointments and receiving negative results will be carried out electronically; • the service is not a drop-in service, a client must book an appointment for the medical screening; • a client will be enrolled for the service at the same time as identity registration; • medical tests and receiving positive test results will be carried out faceto-face; • analysis of samples will be carried out within the service provision boundary; • test data, electronic identities and test results will be stored locally; • there is a requirement to archive test results. Preferred delivery mechanisms • advice, information and booking facilities available via the internet; • electronic identity registration of a client’s pseudonym; • electronic delivery of authentication credentials; • face-to-face delivery of any samples required from the client; • face-to-face delivery of positive test results to the client; • electronic delivery of negative test results to the client; • telephone help desk to provide advice and support to the client. External connections and other third party interactions • an external connection to the internet is required to interact with clients, for example, to allow them to view information about the service, to book appointments, to send clients test results; • no other external connections are required as the service will not proceed through the Government Gateway, and testing and analysis will be completed in-house. Electronic transactions • The electronic transactions likely to be performed within this service can be split into three distinct groups: - Set A: client providing information to the service (eg confirmation of an appointment); - Set B: the service providing information to a client (eg details of an appointment); - Set C: the service providing test results to a client. received and has read any Table 8: description of the service provision environment e-Government framework for Information Assurance Draft 5.1 Page 97 Pseudonymous medical testing Government user information space Client information space Service provision boundary Internet Client Figure 8: pseudonymous medical testing service provision environment 11.2.5 The major attack groups and compromise paths that pose a threat to this service, and the compromise paths that could be exploited, are assessed to be accidental and deliberate compromise by authorised users, and access control and network attacks by private investigators and inquisitive organisations/individuals. It is considered unlikely that foreign intelligence services or terrorists pose a threat to this service. The attack groups and compromise paths identified here are within the remit of the standard groups identified at Section 4 of this document; therefore there is no requirement to apply HMG IS1 in addition to this guidance. STEP 2: define impact levels for each service characteristic 11.2.7 11.2.8 Impact levels 133 must be assigned to each relevant service characteristic for each transaction a service supports, 134 and for the information that it stores. Table 9 sets out the impact levels for each of the transactions representing information exchange between clients and the e-Government service. 135 Transactions attract impact levels for each of identity registration, enrolment, client authentication, confidentiality, integrity and availability. Three groups of transactions have been identified for this service: • Set A: provision of information by a client to the government service; 11.2.6 133 134 135 Defined by the HMG Impact Table, and reproduced in part at Annex D of this document. As defined in the description of the service provision environment at Table 8. The relevant definition within the HMG Impact Table is referred to in each instance (for example, definition C1: public services, risk to life and safety). Page 98 Worked examples • Set B: provision of information from the government service to a client; • Set C: provision of test results from the government service to a client. Impact level Service Characteristic Set A 0 Set B 0 Set C 0 Highest impact • No assurance is required in a client’s real-world identity for any of the transactions; therefore there would be no impact from compromise. • No evidence of status is required for any of the transactions, as this service is freely available to all. • Transaction set A requires a client’s electronic identity to be established to a moderate degree of trust, as compromise may impact the provision of a service for a client (C2). Client authentication 1 0 2 • Transaction set C requires a substantial degree of trust in the client’s electronic identity, as passing of test results to the wrong client could cause an individual citizen short-term distress (C6). 136 • As a client’s test results are only linked to a pseudonym, and not their real-world identity, there would be no impact from compromise of the confidentiality of transaction information. 137 • Compromise of the integrity of a transaction in Set A (eg false confirmation of an appointment by a client) may cause disruption or compromise to the service which could pose a risk to health (C9), and is likely to cause minor financial loss to the service (C5). Integrity 2 2 2 • Set B: compromise of the integrity of a transaction (eg a client being given incorrect details of an appointment) may reduce an individual citizen’s perception of that service (C3). • Compromise of the integrity of a transaction in Set C (eg a client receiving a false test result) could cause an individual citizen short-term distress (C6). • A client not being able to send information to the service, or the service being able to send information to the client (including test results) may at most cause minor inconvenience to a client/service (C3), as alternative delivery channels would be available. 138 Identity registration Enrolment 0 0 0 Confidentiality 0 0 0 Availability 0 0 0 Table 9: impact levels for transactions 136 It should be noted that if this service provided a facility to screen for life-threatening diseases, IL3 would have to be assigned to integrity, as compromise could result in a risk to a client’s personal safety. This would also be the case for client authentication. Confidentiality IL0 is assigned based on the assumption that the test results will be delivered directly to the client rather than being published more broadly (eg on a website), in which instance a client should be notified to allow them to give further consideration to the pseudonym they provide. Alternative delivery channels could include: a helpline where test results can be accessed upon divulgence of an appropriate part of a client’s electronic credential; or setting a time-limit within which to electronically receive test results, after which time a client should pick their results up face-to-face. 137 138 e-Government framework for Information Assurance Draft 5.1 Page 99 11.2.9 Table 10 sets out the impact levels for compromise of information stored within the service provision domain.135 Information assets attract impact levels for confidentiality, integrity and availability only. Identity registration, enrolment and authentication are mechanisms which support the transactions by which information assets are managed, rather than the information assets themselves, so do not need to be considered here. Impact level Highest impact • There would be little impact from compromise of the confidentiality of an individual client’s information as this cannot be linked to their real-world identity. However, compromise of information from a large number of clients could cause embarrassment to the service (definition C7). • Compromise of the integrity of information held within the government system could cause an individual citizen shortterm distress (definition C6). • It is likely that if information was not available to be communicated to the client (by any delivery channel), this would cause short-term distress to an individual (definition C6). Service Characteristic Confidentiality 1 Integrity 2 Availability 2 Table 10: impact levels for information assets 11.2.10 Table 11 displays the range of impact levels which have been assigned to each service characteristic both for transactions and for the information assets. Range of impact levels assigned Service characteristic Information assets 1 2 2 Transactions Set A 0 0 1 0 2 0 Set B 0 0 0 0 2 0 Set C 0 0 2 0 2 0 0 0 2 1 2 2 Final impact level Identity registration Enrolment Client authentication Confidentiality Integrity Availability Table 11: the final impact levels for each service characteristic 11.2.11 In this example, it is considered to be appropriate to protect the information to the high-water mark of both of the impact levels attracted to the transactions and of the information assets, and to define a single set of impact levels within the entire service. Page 100 Worked examples STEP 3: apply standard minimum countermeasures 11.2.12 The standard minimum countermeasures and considerations set out at Section 2 (Step 3), and those set out in support of each of the service characteristic (Sections 5-10), should be implemented. 11.2.13 Although both identity registration and enrolment attract IL0 for this service, particular consideration must be given to management of the distribution of electronic credentials to clients which will be determined by the impact level attracted to client authentication. STEP 4: apply transaction-specific countermeasures 11.2.14 The specific countermeasures to be put in place for this service are dependant on the impacts identified for each service characteristic at Step 2. In this example, the countermeasures are service-specific as opposed to transaction-specific because a single set of impact levels were defined for the entire service. 11.2.15 The countermeasures required at the range of impact levels calculated for each service characteristic are outlined at Sections 5-10. The actual choice of countermeasures needs to be considered in terms of risk to the service as a whole, cost of implementation, practicality and overall business benefit. 11.2.16 For this service, specific consideration must be given to the requirements evidence of receipt within the countermeasures for integrity (IL2). One workable solution in this case would be to manage evidence-of-receipt as a back-end function, requiring the client to log on to the service to receive their results, and treating access of these results as an accountable event. STEP 5: agree, document and implement risk management decisions 11.2.17 The procedures to be implemented includes, for example: • clearly documenting risk management and risk assessment decisions in the RMADS, which will be updated as required; • a regular IA review (a six-monthly or annual review cycle would probably be appropriate in this case) throughout the lifetime of the service, and as required in exceptional circumstances; • documenting policy on what compromises and losses are acceptable (eg no client should receive inaccurate test results through a loss of integrity of the IS). e-Government framework for Information Assurance Draft 5.1 Page 101 11.3 Hypothetical tax return service STEP 1: define the service Purpose 11.3.1 A service allowing an individual citizen to file a personal self-assessment tax return electronically. Client requirements 11.3.2 The high-level actions that a client might wish to conduct in support of this service include the following: • electronically access information about completing a tax return, for example, the information that is required and the telephone number of a help desk; • complete and submit their tax form electronically in more than one sitting if required; • be able to access an online account detailing payment history and any outstanding balances. 11.3.3 Other features that a client might require include the following: • delegate another person or organisation, for example an accountant, to complete and submit a tax return on their behalf; • have any information provided kept confidential; • have the integrity of the information they submit preserved; • reveal only the identity information necessary to complete the transaction; • be electronically notified of any tax owed to/by them; • be provided with an acknowledgement that their form has been received; • be able to file a tax return whenever is convenient for them; • have their tax worked out automatically as they complete the form, so that they know what they owe or are owed straight away; • be provided with an acknowledgement that any tax paid by them is received by the service. Service requirements 11.3.4 The high-level requirements for the service include: • a substantial level of assurance in the client’s real-world identity (eg name, residency); Page 102 Worked examples • a low level of assurance that a client is eligible to receive the service, as it is freely available to all citizens who pay tax in the UK; 139 • a client to have a persistent electronic identity, of which it can have substantial level of assurance that it is the same client returning; • the details required to calculate their tax (eg details of a client’s employment, income, bank accounts, savings and investments) to be provided by a client as part of the service; • acknowledgement that any tax paid by the service is received by the client; • maintenance of up-to-date personal details by the client. Service provision environment Tax return Government user information space Client information space Government Gateway Service provision boundary Internet Client Figure 9: hypothetical tax return service provision environment 139 It should be noted that this service is not limited to UK nationals. e-Government framework for Information Assurance Draft 5.1 Page 103 Service provision environment Information assets Description • history details (eg records of payments); • details of a client’s real-world identity linked to an electronic identity; • details of a client’s income and capital gains for the current and previous years, linked to a real-world identity. Assumptions • identity registration and enrolment will be conducted by the Government Gateway on behalf of the service provider; • there is an annual deadline for filing a tax return; • clients who have previously registered their identity with the Government Gateway would not be required to register their identity again, only to enrol for this service; • the Government Gateway will provide a client with an electronic identity, which, once enrolled for this service, a client can use to gain access to their personal account; • a client will not be required to give any additional information (above that given to register their identity) to enrol for the service, however, a client will be required to activate their account; • in many instances use of this service, or an equivalent service using alternative delivery channels, will be mandatory for UK taxpayers; • the service will calculate a client’s tax automatically as they complete the electronic form. Preferred delivery mechanisms • identity registration and enrolment via the Government Gateway; • completion and submission of a tax return form via the internet; • electronic payment/receipt of funds if desired by the client. External connections and other third party interactions • interaction with the Government Gateway; • an external connection to the internet is required to interact with clients; • internal connections within the department may be necessary if required information (eg amount of tax paid by PAYE) is stored within another system. Interoperability between departmental systems, and any potential DPA requirements may need to be considered. Transactions • The electronic transactions likely to be performed within this service can be split into distinct groups: - Set A: client providing information to government (eg information contained within online tax form); - Set B: government providing information to client (eg acknowledgement of receipt of completed form); - Set C: electronic transfer of money from the service to a client; - Set D: electronic transfer of money from a client to the service. Table 12: description of the service provision environment 11.3.5 The major attack groups that pose a threat to this service, and compromise paths that could be exploited, are assessed to be individual fraudsters, organised criminal groups and hackers. 11.3.6 Individual fraudsters and organised criminal groups are most likely to exploit the service for their own gain, for example by misappropriating genuine realworld identities or simply misusing their own real-world identity to claim back Page 104 Worked examples tax which they are not entitled to receive. Hackers, however, are most likely to be testing their abilities or cause disruption to the service by utilising network attacks and access control attacks. 11.3.7 It is considered unlikely that foreign intelligence services or terrorists pose a threat to this service. However, consideration must be given to the amount and type of information directly connected to the service; in aggregation particular information may be attractive to these attack groups. The attack groups and compromise paths identified here are within the remit of the standard groups identified at Section 4 of this document; therefore there is no requirement to apply HMG IS1 in addition to this guidance. STEP 2: define impact levels for each service characteristic 11.3.9 Impact levels 140 must be assigned to each relevant service characteristic for each transaction a service supports, 141 and for the information that it stores. 11.3.8 11.3.10 Table 13 sets out the impact levels for each of the transactions representing information exchange between clients and the e-Government service. 142 Transactions attract impact levels for each of identity registration, enrolment, client authentication, confidentiality, integrity and availability. Four groups of transactions have been identified for this service: − − − − Set A: provision of information by a client to the government service; Set B: provision of information from the government service to a client; Set C: transfer of money from the government service to a client; Set D: transfer of money from a client to the government service. 140 141 142 Defined by the HMG Impact Table, and reproduced in part at Annex D of this document. As defined in the description of the service provision environment at Table 12. The relevant definition within the HMG Impact Table is referred to in each instance (for example, definition C1: public services, risk to life and safety). e-Government framework for Information Assurance Draft 5.1 Page 105 Service Characteristic Impact level Set A Set B Set C Set D Highest impact • Set A and Set C: compromise of a client’s real-world identity information could cause a moderate financial loss (C5) to the client (eg up to £1000 for an individual, or up to £10,000 for a larger business or organisation) and would likely cause distress to an individual citizen (C6). 143 • No evidence of entitlement is required for any of the transactions, therefore there is no impact from compromise. • Set A: compromise of a client’s electronic identity may cause short-term distress to a citizen (C6) and could be perceived to cause loss of reputation for an individual citizen or the service (C7). • Sets A and B: compromise of the confidentiality of information provided by and to a client (eg their tax return, or their tax calculation) could cause short-term distress to a citizen (C6) and could be perceived to cause loss of reputation for an individual citizen or the service (C7). • Sets C and D: compromise of the confidentiality of the details of payment exchanged between the service and client and details of a client’s bank account or credit card could cause a moderate financial loss (C5) to the client. • Sets A and B: compromise of the integrity of information exchanged between the service and a client would impact on the provision of the service to many citizens (C2) and would reduce the perception of the service by many citizens (C3). • Sets C and D: compromise of the integrity of the payments made between the service and a client would be likely to cause a moderate financial loss to the client or organisation, and a loss to the public sector of up to £10,000 before the problem was identified. • Sets A and B: compromise of the availability of the service to a client (particularly around deadlines for submission), and compromise of the availability of information sent from government to client (eg calculation of tax) could impact on the provision of the service for many citizens (C2) and likely result in undermined confidence in the service provider generally (C3). • Sets C and D: compromise of the availability to transfer money electronically between the service and a client may cause inconvenience to a citizen (C3). Performing these transactions electronically is just one convenient method of transferring money between a client and the service, and other methods of transfer would be available (eg posting a cheque or online banking). Identity registration 2 0 2 0 Enrolment 0 0 0 0 Client authentication 2 0 0 0 Confidentiality 2 2 2 2 Integrity 2 2 2 2 Availability 3 3 1 1 Table 13: impact levels for transactions 143 This is assumed to be the general case, although there will be exceptions where a client’s tax return is greater than the values stated here. Page 106 Worked examples 11.3.11 Table 14 sets out the impact levels for compromise of information stored within the service provision domain.142 Information assets attract impact levels for confidentiality, integrity and availability only. Identity registration, enrolment and authentication are mechanisms which support the transactions by which information assets are managed, rather than the information assets themselves, so do not need to be considered here. Service Characteristic Impact level Highest impact • Compromise of the confidentiality of information stored within the service provision domain could cause prolonged distress to an individual citizen, or short-term distress to many citizens (C6) due to the aggregation of information. • Compromise of the integrity of information assets could impact on the provision of the service to many citizens (C2), and reduce the perception of the service by many citizens (C3). • Compromise of the availability of information assets may cause embarrassment to government and result in undermined confidence in the service provider generally (C3). Confidentiality 3 Integrity 2 Availability 3 Table 14: impact levels for information assets 11.3.12 Table 15 displays the range of impact levels which have been assigned to each service characteristic both for transactions and for the information assets. Impact levels for information assets 3 2 3 Range of impact levels assigned Transactions Set A 2 0 2 2 2 3 Set B 0 0 0 2 2 3 Set C 2 0 0 2 2 1 Set D 0 0 0 2 2 1 Impact levels for transactions 2 0 2 2 2 3 Service characteristic Identity registration Enrolment Client authentication Confidentiality Integrity Availability Table 15: the final impact levels for each service characteristic 11.3.13 The aggregation of information within the service provision domain results in a requirement for more stringent mechanisms to protect the confidentiality of the information assets than is required to protect the confidentiality of information in transit between a client and the e-Government service. e-Government framework for Information Assurance Draft 5.1 Page 107 11.3.14 In this case it is not considered appropriate to assign one set of impact levels for the entire service, as this would rest in high costs for implementing countermeasures at Confidentiality IL3, and may inhibit the functioning of the service. Therefore, one set of impact levels are assigned for the transactions, and another set for the information assets. STEP 3: apply standard minimum countermeasures 11.3.15 The standard minimum countermeasures and considerations set out at Section 2 (Step 3), and those set out in support of each of the service characteristic (Sections 5-10), should be implemented. 11.3.16 Although this service attracts Enrolment IL0, particular consideration must be given to the balance of responsibilities between this service and the Government Gateway. This is particularly applicable to the management of the distribution of electronic credentials to clients which will be determined by the impact level attracted to client authentication. STEP 4: apply transaction-specific countermeasures 11.3.17 The specific countermeasures to be put in place for this service are dependant on the impacts identified at Step 2. In this example, the countermeasures required to protect information in transit are set by the highwater mark of the impact levels attracted to transaction sets A-D. The countermeasures required 11.3.18 In this example, the countermeasures are specific to the transactions as a whole, and to the information assets (which require more stringent countermeasures to protect the confidentiality of the information). 11.3.19 The countermeasures required at the range of impact levels calculated for each service characteristic are outlined at Sections 5-10. The actual choice of countermeasures needs to be considered in terms of risk to the service as a whole, cost of implementation, practicality and overall business benefit. 11.3.20 It may not practical for the service to implement the countermeasures required at Availability IL3 (for both the information assets and the transactions). In such instances, a risk-balance-decision could been taken to reduce Availability IL3 to Availability IL2, for example by introducing a caveat stating that if the electronic service is not available, the deadline will be extended as necessary so that a tax return can be completed by other channels (eg postal). Page 108 Worked examples 11.3.21 When applying countermeasures, particular consideration must be given to: • whether or not the Government Gateway meets the requirements of the service for identity registration, enrolment and authentication (the Government Gateway issues a client’s electronic credentials). The Government Gateway is a Registration IL2 and Authentication IL2 service, so in this example it meets the requirements of the service; • the management of information exchange between the Government Gateway and the service relating to a client’s personal information (eg ensuring that details of a client’s address are kept current); • the requirements for both non-repudiation and evidence of receipt. For example, some of the non-repudiation requirements could be met by allowing a client to view a record of their transactions with the e-Government service on once they have authenticated themselves to the service. STEP 5: agree, document and implement risk management decisions 11.3.22 All risk management and risk assessment decisions should be clearly documented in the RMADS (particularly the decision to implement availability IL2 countermeasures instead of IL3). This service should undergo regular IA reviews throughout its lifetime, and as required in exceptional circumstances, with the RMADS being updated in-line with the reviews. 11.3.23 Examples of other procedures to be implemented include documenting policy on what compromises and losses are acceptable, for example, the acceptable downtime of this service should be clearly set out, with particular consideration being given to times when the deadline for submission of tax returns is imminent. e-Government framework for Information Assurance Draft 5.1 Page 109 11.4 Hypothetical disabled parking permit service STEP 1: define the service Purpose 11.4.1 This service allows clients with disabilities to apply electronically to their local government authority for a parking permit. 144 Client requirements 11.4.2 The high-level actions that a client may wish to conduct in support of this service may include the following: • apply for a parking permit electronically, or delegate another person to apply for the parking permit in their name; • have their eligibility to receive a parking permit established electronically, with as little requirement as possible to provide evidence off-line; • renew their permit electronically; • be able to update their personal information as required. 11.4.3 Other features that a client might require include the following: • being able to use their parking permit as either a driver or a passenger; • have their eligibility established correctly; • reveal only the minimum identity information required to obtain this service; • have any personal information stored or transmitted kept confidential. Service requirements 11.4.4 The high-level requirements for the service are as follows: • a substantial level of assurance in the client’s real-world identity (eg proof of name, residency, age and photographic identification); • delegates are required to state their relationship to the client, and their entitlement to act as the client’s delegate (this may require the service to contact a client to verify their entitlement); • when applicable, appropriate assurance that a client has given authorisation to a delegate to apply for a permit on the client’s behalf; • a high level of assurance in the client’s eligibility to receive this service (eg proof of any disability or disability allowances received, provision of doctor’s details and consent to contact); 144 A parking permit in this example is defined as a national arrangement of on-street parking concessions enabling people with disabilities to park close to their destination. Page 110 Worked examples • the ability to link the apparent originator of an electronic transaction with a real-world identity; • a persistent electronic identity to be established, of which the e-Government service can have a substantial degree of assurance that it is the same client returning. Service provision environment Service provision environment Information assets Description • client real-world identity information linked to an electronic identity; • details of a client’s eligibility to receive a parking permit linked to a realworld identity, this may include detail of a client’s disability, confirmation that evidence such as certificates have been approved, and details of any disability allowance a client receives; • details of the validity of a parking permit should they receive one (eg expiry date), linked to an electronic identity; • history details, for example, record of when a client has applied for a permit, and any transactions with government; Assumptions • the service is free at the point of application; • clients in receipt of the higher rate of Disability Living Allowance (DLA) from the Department for Work and Pensions (DWP) have automatic eligibility for a parking permit. Clients not in receipt of the higher rate of disability allowance must undergo discretionary qualification based on a series of questions; • a parking permit is linked to a client and not a vehicle; a client may use the parking permit either as a passenger or a driver; • parking permits will be able to be used anywhere in the country; • identity registration will proceed in conjunction with enrolment; • a parking permit is valid for 2 years, at which point it should be renewed by the client. Preferred delivery mechanisms • identity registration and enrolment carried out locally (ie not Government Gateway) by the electronic completion and submission of an application form by the client; • electronic renewal of expired parking permits; • advice, information electronically; and registration/enrolment form available • postal delivery of client photographs to service; • postal delivery of parking permit to client; • telephone helpdesk; • electronic gathering of checks of eligibility by government users where possible. Alternative mechanisms acceptable include telephone or faceto-face. Table 16-1: description of the service provision environment e-Government framework for Information Assurance Draft 5.1 Page 111 Service provision environment External connections and other third party interactions Description • an external connection to the internet is required to interact with clients; • connections to other government departments to provide proof of status information (if proof of status is determined electronically). • The electronic transactions likely to be performed within this service can be split into two distinct groups: 145 - Set A: client providing information to the government (eg submission of electronic enrolment form); - Set B: government providing information to client (eg status of application details). 146 Electronic transactions Table 16-2: description of the service provision environment Disabled parking permits Government user information space Client information space Trusted third-parties Service provision boundary Internet Client Figure 10: hypothetical disabled parking permit service provision environment 11.4.5 The major threat posed to this service is assessed to be deliberate compromise by individual fraudsters and organised criminal groups who might create false identities, or misappropriate genuine real-world identities to claim a parking permit that they are not entitled to. Organised criminal groups may sell have a motivation to sell on parking permits on for profit. 11.4.6 An additional channel that may also be exploited is citizens applying fraudulently for the higher rate of DLA from the DWP as this allows automatic qualification for a disabled parking permit. It should be noted that this may particularly be the case in inner city areas where parking is at a premium, 145 It should be noted that the definition of a transaction within this guidance includes only those exchanges between a client and an e-Government service. For exchanges between the e-Government service and trusted third parties, for example with the DWP to confirm that a client receives the highest rate of DLA, the amount of trust placed in the third party should be assessed. Establishing trust in third parties may be aided by use of a trust service approval scheme. This does not include provision of the actual parking permit to a client which would be sent by post to the client’s home address. 146 Page 112 Worked examples although as it is a national scheme, the threat should be considered in all areas. 11.4.7 It is considered unlikely that foreign intelligence services or terrorists pose a threat to this service. The attack groups and compromise paths identified here are within the remit of the standard groups identified at Section 4 of this document; therefore there is no requirement to apply HMG IS1 in addition to this guidance. STEP 2: define impact levels for each service characteristic 11.4.8 11.4.9 Impact levels 147 must be assigned to each relevant service characteristic for each transaction a service supports, 148 and for the information that it stores. Table 17 sets out the impact levels for each of the transactions representing information exchange between clients and the e-Government service. 149 Transactions attract impact levels for each of identity registration, enrolment, client authentication, confidentiality, integrity and availability. Two groups of transactions have been identified for this service: • Set A: provision of information by a client to the government service; • Set B: provision of the information from the government service to a client; Service Characteristic Impact level Set A Set B Highest impact • Set A requires a moderate degree of assurance of a client’s real-world identity, as this will form the basis of whether a client is eligible to receive this service. Compromise of a client’s identity registration information would be likely to reduce the perception of the service by many citizens (C3) and could result in short-term distress to a citizen if someone else applied for a permit in their name (C6). • Set A requires a client’s entitlement for a service to be established to a substantial degree of trust, as compromise of a client’s enrolment information, for example fraudulently claiming a disability, may have an impact on public finances of up to £10,000 (C4). • Set A requires a substantial degree of trust in the client’s electronic identity, because a client will be allowed to update their personal information and apply for a renewal of their permit after authenticating themselves, and compromise of a client’s electronic identity may cause short-term distress to an individual citizen (C6). Identity registration 2 0 Enrolment 2 0 Client authentication 2 0 Table 17-1: the impact levels for transactions 147 148 149 Defined by the HMG Impact Table, and reproduced in part at Annex D of this document. As defined in the description of the service provision environment at Table 16. The relevant definition within the HMG Impact Table is referred to in each instance (for example, definition C1: public services, risk to life and safety). e-Government framework for Information Assurance Draft 5.1 Page 113 Service Characteristic Impact level Set A Set B Highest impact • Set A: compromise of the confidentiality of transaction information, such as information on a client’s disabilities or allowances, may cause short-term distress to an individual citizen (C6), and may be perceived to cause lose of reputation for an individual citizen (C7). • Set B: compromise of the confidentiality of transaction information sent from the government to a client is likely to have only a minimal impact. • Set A: compromise of the integrity of transaction information, for example a client’s identity information, is likely to reduce an individual’s perception of that service (C3), is likely to cause short-term distress to an individual (C6) and may have an impact on public finances (of up to £10,000) if many citizens are falsely issued with parking permits as a result. 150 • Set B: if the integrity of (government to client) transaction information is compromised, it may impact the provision of the service to an individual citizen (C2), for example not receiving notification that a permit is due for renewal. • Set A: a client not being able to send information to the government may at most cause minor inconvenience to a client/service (C3), as alternative delivery channels (eg postal) would be available; • Set B: compromise of the availability of transactions from government to a client, for example requests for further evidence as proof of status, may affect the provision of the service for a single citizen (C2). Confidentiality 2 0 Integrity 2 1 Availability 0 1 Table 17-2: the impact levels for transactions 11.4.10 Table 18 sets out the impact levels for compromise of information stored within the service provision domain.149 Information assets attract impact levels for confidentiality, integrity and availability only. Identity registration, enrolment and authentication are mechanisms which support the transactions by which information assets are managed, rather than the information assets themselves, so do not need to be considered here. 150 It should be noted that if a client is automatically eligible for a parking permit because they are eligible for the highest rate of DLA from the DWP, the impact level for integrity will only be as high as the integrity of the information received from the DWP. Page 114 Worked examples Service Characteristic Impact level Highest impact • Compromise of the confidentiality of an individual client’s information is likely to cause short-term distress to an individual citizen (C6), and may be perceived to cause lose of reputation for an individual citizen (C7). • Compromise of the integrity of information held within the government system could cause an individual citizen shortterm distress (definition C6), and result in loss of reputation of the service (C7). • If information is not available to be communicated for short periods, it may cause minor inconvenience to an individual citizen (C3) and is likely to cause embarrassment to the service (C7). Confidentiality 2 Integrity 2 Availability 1 Table 18: impact levels for information assets 11.4.11 Table 19 displays the range of impact levels which have been assigned to each service characteristic for both transactions and for information assets. Range of impact levels assigned Service characteristic Information assets 2 2 1 Transactions Set A 2 2 2 2 2 0 Set B 0 0 0 0 1 1 2 2 2 2 2 1 Final impact level Identity registration Enrolment Client authentication Confidentiality Integrity Availability Table 19: the final impact levels for each service characteristic 11.4.12 In this example, to achieve optimum functionality of the service, it is considered to be appropriate to protect the information (both in transit and within the service provision domain) to the high-water mark, and to define a single set of impact levels within the entire service. STEP 3: apply standard minimum countermeasures 11.4.13 The standard minimum countermeasures and considerations set out at Section 2 (Step 3), and those set out in support of each of the service characteristic (Sections 5-10), should be implemented. 11.4.14 It should be noted that although the electronic transactions within this service have little requirement for evidence of receipt, postal delivery of the permits to e-Government framework for Information Assurance Draft 5.1 Page 115 a client will have a requirement for evidence of receipt to ensure that the permit has not been misappropriated in transit. STEP 4: apply transaction-specific countermeasures 11.4.15 The specific countermeasures to be put in place for this service are dependant on the impacts identified for each service characteristic at Step 2. In this example, the countermeasures are service-specific as opposed to transaction-specific, because a single set of impact levels were defined for the entire service. 11.4.16 The countermeasures required at the range of impact levels calculated for each service characteristic are outlined at Sections 5-10. The actual choice of countermeasures needs to be considered in terms of risk to the service as a whole, cost of implementation, practicality and overall business benefit. 11.4.17 Of particular consideration for this service is the requirement to conduct as much of the service electronically as is practicable. This particularly applies to the provision of evidence for identity registration and enrolment: • Examples of acceptable remote and online evidence at this impact level for registration are provided at Annex E. For example, this service could make use of the IPS passport checking service (provided a client held a valid passport), or identity verification services for the identity registration of a client. • Automatic enrolment requires a client to receive the highest rate of DLA from the DWP. A client could provide evidence of this allowance by post; any other methods (remote or online) must be commensurate with this. Online verification could be carried out in liaison with the DWP by communicating the relevant data across secure channels, subject to establishing appropriate trust relationship and putting appropriate measures into place to support obligations under the DPA. • Discretionary enrolment requires a client to provide a variety of evidence to support their claim for a parking permit. Evidence can be presented faceto-face at one-stop-shops; any other methods (remote or online) must be commensurate with this. For example, this could be achieved by communicating data between departments (subject to obligations under the DPA), checking databases or telephone/email communication by government users. 11.4.18 Particular consideration should also be given for the management of delegate accounts, and the requirements for providing evidence of a delegate’s entitlement to act on a client’s behalf. STEP 5: agree, document and implement risk management decisions 11.4.19 All risk management and risk assessment decisions should be clearly documented in the RMADS at a basic level of detail. Particular consideration should be given to management of the trust relationship with the DWP. Page 116 Worked examples 11.4.20 Other procedures to be implemented include conducting regular IA reviews (an annual review cycle would probably be appropriate in this case) throughout the lifetime of the service, and as required in exceptional circumstances. The RMADS should be updated in-line with any reviews. e-Government framework for Information Assurance Draft 5.1 Page 117 A A.1 A.1.1 Glossary General Differences in the use of IA terminology can lead to incorrect and/or inconsistent interpretation and implementation of IA policy and guidance. This in turn can lead to a lack of mutual trust between organisations and other problems with interoperability and joint working. This glossary defines the terms used within this document. The approach taken has been, where possible, to avoid the use of contentious terms and to align with the terminology set out by the following relevant references: • HMG definitions as set out within HMG Infosec Standard No. 2 (HMG IS2) 151 , which defines the risk management and accreditation process; • Home Office (HO) definitions as set out within the Identity and Passport Service (IPS) Identity Management Practitioners’ Guide; the IPS glossary is regarded to be the definitive set of definitions covering identity management within government. • HM Treasury (HMT) definitions as set out within the HMT Orange Book, 152 which sets out the current position of HMT on risk management and is aligned with Office of Government Commerce (OGC) guidance; A.1.2 A.2 Glossary Access controls A.2.1 An access control is a measure to ensure that elements of a service may only be accessed by suitably authorised users and to ensure that transactions may only be conducted by suitably authorised clients. Access token A.2.2 An access token is a (physical) medium that contains a credential. This might be, for example, a smartcard that contains a digital certificate or biometric information. Account activation A.2.3 Activation of a client account will often be required to confirm that the address (postal or electronic) the client account and electronic identity have been sent to can be linked to the identity of the client. For example, this might be 151 152 HMG Infosec Standard Number 2: risk management and accreditation of information systems, dated July 2005. This document may be downloaded from the NISCC web-site, http://www.niscc.gov.uk. The Orange Book: management of risk – principles and concepts, dated October 2004. This document may be downloaded from the HMT web-site, http://www.hm-treasury.gov.uk. Page 118 Glossary achieved by the e-Government service sending a client an email which is subsequently acknowledged by the client. Accreditation A.2.4 Accreditation is the formal assessment of an information system or a set of capabilities 153 against the IA requirements of the information assets of that information system or capability set. The accreditation process provides evidence that an appropriate set of measures are in place to ensure an acceptable level of risk for the confidentiality, integrity and availability of information assets that are stored and handled within the accreditation boundary. The impact levels for a compromise of the confidentiality, integrity and availability of information assets are determined by the SIRO. For e-Government services, impact levels for a compromise of the identity registration, enrolment and authentication processes that support the service must also be determined. The impact levels should be determined in consultation with the Accreditor, supported by a full risk assessment to set out the business impacts of compromise. Important factors in determining the countermeasures that must be in place and the level of residual risk to accept for information assets include the residual risk that the risk owner is prepared to accept, and any prerequisite requirements for envisaged onward connections. 154 Accreditation boundary A.2.7 The accreditation boundary represents the boundary between the elements of an e-Government service that the SRO is responsible for and those things over which the SRO has no direct control. The accreditation boundary often corresponds to the boundary that is defined by an information system or a set of capabilities. There will frequently be connections that cross the accreditation boundary, such as a network connection between a system being accredited and the Internet. Accreditor A.2.8 An accreditor is the individual responsible for conducting the formal assessment of an information system or a set of capabilities and for advising the SIRO on the risks to information assets. A.2.5 A.2.6 153 Such a capability-set might be hosted on a stand-alone infrastructure, on a common infrastructure within an organisation, or on a pan-organisational infrastructure. It is anticipated that the latter two of these options will become increasingly prevalent across government, as part of the shift towards improved interoperability and joint working and to allow economies of scale to be realised. Baseline IA requirements to connect to a specific external system or network such as Government Secure Intranet (GSi) would be set out within the Code of Connection for that system or network. Baseline IA requirements for connection to a different capability set that is hosted on a common infrastructure would be set out within the Interconnection Security Measures (ISM) for that capability set. 154 e-Government framework for Information Assurance Draft 5.1 Page 119 Anonymous client A.2.9 An anonymous client is one who does not reveal their real-world identity nor establish a persistent electronic identity prior to authorising a specific transaction. A.2.10 See the definition of pseudonymous client for comparison. Attack group A.2.11 An attack group is a group of one or more potential attackers (also known as threat actors), who may be either unauthorised or authorised users of a service. A.2.12 Within the risk assessment method that is adopted here, attack groups are defined in terms of the information assets that they are authorised to access, their capability and their motivation. Authentication A.2.13 Authentication is the process by which a credential and collateral information are presented and verified, to establish a claim to a valid electronic identity. An electronic identity to support authentication by a client would typically be provided during the identity registration and/or enrolment process. A.2.14 See also service authentication and client authentication. Authorisation A.2.15 Authorisation is the process of determining which activities and access are permitted to a client. Within a session, a client may request authorisation to carry out further activities, which may require further authentication of the client to the service. Availability A.2.16 Availability is defined as the ability for authorised users to access and use information assets and services when required. A.2.17 The risk assessment method that is adopted here defines information assets in terms of the value of their confidentiality, integrity and availability. Back-office system A.2.18 A back-office system is the computer system within a government department, agency, local or regional authority or other service provider, which completes a requested service based on data provided. Page 120 Glossary Business impact of compromise A.2.19 The business impact of compromise is the measure of the damage that would be caused by compromise of the confidentiality, integrity and availability of the information assets within a service. A.2.20 The risk assessment method that is adopted here measures the business impact of compromise on a four-point scale of impact levels, from Impact Level 0 (IL0) through to Impact Level 3 (IL3). CAPS A.2.21 The CESG Assisted Products Scheme (CAPS) 155 supports the commercial development of cryptographic products for Government requirements. It is aimed at supporting those applications where commercial-grade cryptography is required in a government environment. Assessments of those products submitted to the scheme are carried out by CESG in house, and result in a fitfor-government use certificate being awarded if successful. CCT Mark A.2.22 The CSIA Claims Tested (CCT) 156 Mark scheme is a Government sponsored assurance scheme which, through accredited independent testing, provides the public sector with confidence in the claims made by Vendors about the functionality of their information security products and services. A.2.23 The scheme provides a basic level of assurance (equivalent to EAL1) to these products and services, and will give confidence to purchasers that the Vendor’s security functionality claims have been validated. A.2.24 The scheme is aimed primarily at those products and services which may be purchased by central government and the wider public sector, particularly the NHS, Education, Local Authorities and Criminal Justice. Challenge-response A.2.25 Challenge-response is the mechanism that is typically used to test whether the recipient of the challenge can be authenticated for a particular service. CHECK A.2.26 The CESG IT health check service (CHECK) was developed to enhance the availability and quality for the IT health check service that are provided to government service providers across central government departments, wider public sector organisations and elements of the Critical National Infrastructure (CNI), in line with HMG policy. 155 156 Further details about the CESG Assisted Products Scheme can be found at http://www.cesg.gov.uk. Further details about the CSIA Claims Tested Mark scheme can be found at the Cabinet Office web-site, http://www.cabinetoffice.gov.uk/. e-Government framework for Information Assurance Draft 5.1 Page 121 Client A.2.27 The term client is used here to denote a person or organisation, a delegate of a person or organisation, or an element of another service seeking to carry out a transaction using an e-Government service. Client authentication A.2.28 Client authentication is the process and collateral information, which e-Government service to verify the entitlement of the client to receive requested. by which a client presents a credential is checked by or on behalf of an electronic identity of the client and the the service or conduct the transaction A.2.29 See also authentication and service authentication. Common criteria A.2.30 The Common Criteria 157 (CC) are the outcome of efforts to develop criteria for the evaluation of IT security that are widely useful within the international community. It is an alignment and development of a number of existing European, US and Canadian criteria (ITSEC, TCSEC and CTCPEC respectively). It is a contribution to the development of an international standard 158 , and opens the way to worldwide mutual recognition of evaluation results. A.2.31 The Common Criteria present requirements for the IT security of a product or system under the distinct categories of functional requirements and assurance requirements. The CC functional requirements define the desired security behaviour, and the assurance requirements are the basis for gaining confidence that the claimed security measures are effective and implemented correctly. A.2.32 While it is not precluded that e-Government systems undergo a CC evaluation, this may not be suited to a dynamic environment with fast changing systems and products. However, system implementers may wish to use previously evaluated products within their systems. These products will have been submitted by their developers to an independent security assessor for evaluation against a particular Target of Evaluation (ToE). The extent to which the ToE covers how the product is to be used in any particular system should always be borne in mind. Compromise path A.2.33 A compromise path is the means by which an attack group could compromise the confidentiality, integrity or availability of an information asset. Examples 157 158 Further details of the Common Criteria and those products already evaluated can be found on the CESG web-site, http://www.cesg.gov.uk/. The Common Criteria have been adopted as an International Standard (ISO IS 15408). Page 122 Glossary include network attacks, access control attacks and passive interception attacks. The definition used within this document also includes accidental and deliberate compromise by authorised users as compromise paths. Concern A.2.34 A concern represents the mapping between an attack group and a business (sub-)domain, for example covering “compromise of (sub-)domain y by attack group x”. A.2.35 For each concern, a separate risk level is identified for each of the confidentiality, integrity and availability of the information assets within the relevant (sub-)domain and for each identified compromise path. Confidentiality A.2.36 Confidentiality is defined as the ability to ensure that information is only accessed by or disclosed to authorised users. A.2.37 The risk assessment method that is adopted here defines information assets in terms of the value of their confidentiality, integrity and availability. Credential A.2.38 A credential is a set of information which is employed to establish an electronic identity as part of the authentication process. A credential may be associated with collateral information supporting a client’s right to possess that credential (such as a PIN or private signing key). Credential issuer A.2.39 A credential issuer issues, manages and revokes credentials. 159 Credential revocation list A.2.40 A credential revocation list is a list of credentials that have been withdrawn prior to their normal expiry date. 160 Delegate A.2.41 A delegate (also referred to as a proxy) is an intermediary that has been authorised to conduct a specified set or range of transactions on behalf of an e-Government client. This might include, for example, an accountant or other professional acting on behalf of a specified person or organisation, a legal guardian, or a person acting under a power of attorney on behalf of a relative or patient. 159 160 One example of a credential issuer is a certification authority, which issues, manages and revokes digital certificates at the request of an RA. One example of a credential revocation list is a certificate revocation list. e-Government framework for Information Assurance Draft 5.1 Page 123 A.2.42 In some cases a delegate would be entitled to perform any transaction offered by a service for the client on whose behalf they act. More generally, a delegate would be authorised to perform some well-defined subset of the activities that the client they represent is able to perform (for example, an accountant might be authorised to complete a client’s tax returns, but might not be authorised to change that client’s address details). Deterrence A.2.43 Deterrence is the concept that the likelihood of an attack can be reduced if the attack group fears punishment, or some other negative consequence, if detected. Directgov A.2.44 As a brand, Directgov refers to the provision of government services by electronic means. The service provider could be, for example, a central government department, a government agency, a local authority or a private sector organisation acting on behalf of local or central government. A.2.45 The Directgov portal provides access to Directgov services, bringing together a wide range of public service information and services online. Disenrolment A.2.46 Disenrolment is the process by which a client’s right to a particular service is removed. e-Government service A.2.47 An e-Government service is a service that is provided by government or agents of government, to members of the public, delegates or voluntary sector organisations, which is supported by transactions via an electronic delivery channel such as the internet. A.2.48 This loose definition covers a very wide range of applications, including: • passive web services that allow information retrieval from a departmental web site, or from multiple departmental assets (eg information on business travel overseas from the Foreign and Commonwealth Office (FCO) and Department of Trade and Industry (DTI)); • interactive services that enable information exchange with an individual government department (eg applying for a grant or licence) or with multiple government departments (eg notification and receipt of confirmation of a change of address); • private correspondence with Government officials where some level of trust (traceability and accountability) is required of the information exchanged and in the electronic media of communication; Page 124 Glossary • complex multi-function services that enable both passive and interactive interaction with multiple departmental assets. For example citizens might access ‘joined–up’ services via a single web portal that logs their query, and identifies and notifies the relevant government departments via e-mail. Electronic identity A.2.49 An electronic identity is a set of information that uniquely identifies a client to an electronic service or vice versa. An electronic identity will necessarily correspond to one or more real-world identities (for example, a person or an organisation, a representative of a person or organisation, a service or a process), but the real-world identity need only be revealed if it is necessary for the transaction. A.2.50 The electronic identity of a client would typically be comprised of some or all of the following: • something that the client knows, such as a username and/or a password; • something that the client has, such as a digital certificate, biometric or other token; • elements that tie the client’s electronic identity to their real-world identity, such as a National Insurance Number (NINO), passport number, NHS number or other identifier. Enrolment A.2.51 Enrolment is the process by which a client is enabled access to a specific e-Government service. Enrolment is concerned with establishing the entitlement of a client to receive an e-Government service (eg whether that client is eligible for tax credits). Identity registration, by comparison, is concerned solely with verifying the identity of a client. Before being enrolled a client might first register their real-world identity to an appropriate level of assurance, or a pseudonym, with the service provider or a trusted third-party. A.2.52 Successful enrolment of a client will include provision of an account for that client. Enrolment might also include provision of an electronic identity for that client or might make use of an electronic identity that was issued during the identity registration process. In some cases, use of an existing electronic identity might require this to be extended. 161 The strength of any authentication credential provided during enrolment must be commensurate with the impact level attracted to client authentication. A.2.53 A client must enrol at or before first use of a service and may only use those services for which they are enrolled. Evidence requirements for enrolment will depend on the details of the service to be used and must be set in conjunction with relying parties. 161 For example, by adding collateral information to support that electronic identity. e-Government framework for Information Assurance Draft 5.1 Page 125 Entitlement A.2.54 Entitlement is the process of establishing a citizen’s right to a service for which they are trying to enrol. Evidence of receipt A.2.55 Evidence of receipt is the evidence provided by an e-Government service that the intended recipient of an electronic communication or second party to a transaction actually received the communication (if they did so). Fast track A.2.56 The Fast Track Assessment Service 162 was developed to address the enduser requirement for significant improvements in the flexibility and efficiency of the current evaluation process. The formal Infosec evaluation process under the UK IT Security Evaluation and Certification Scheme (ITSEC) was designed to incorporate a number of highly desirable features, including internationally recognised certificates of evaluation to objective standards, repeatability and independent oversight. However, it has been recognised that not all the features associated with formal evaluations are necessary to meet the assurance requirements of sponsors in all cases. A.2.57 The Fast Track Assessment Service defines a less formal evaluation process that aims to achieve very significant cost and time savings compared to the most formal evaluations, and be sufficiently widely applicable to be a genuinely useful addition to the range of assurance options available. A.2.58 In cases where it is felt that some assurance about a particular product is required but there is no formally evaluated equivalent available, then the Fast Track process should be considered. FIPS-140 A.2.59 The US Federal Information Processing Standard 140-2 163 (FIPS PUB 140-2) provides a framework for the evaluation of cryptographic modules for use in processing US unclassified material. A.2.60 The standard was developed by US government and industry and identified requirements for four security levels of cryptographic modules to provide for a wide spectrum of data sensitivity, and a diversity of application environments. A.2.61 While the security requirements in the standard are intended to maintain the security of a cryptographic module, conformance to the standard does not guarantee that a particular module is secure. Similarly, the use of a 162 163 Further details about the Fast Track Assessment process can be found at the CESG web-site, http://www.cesg.gov.uk. Further details about FIPS PUB 140-2 can be found at the NIST web-site, http://www.nist.gov. Page 126 Glossary cryptographic module that conforms to this standard in an overall system does not guarantee the security of the overall system. A.2.62 If it is not practicable or appropriate for a CAPS evaluated product to be used, then a FIPS-140 product, that provides the relevant level of security, may be considered. NIST, the owners of the standard, license a number of laboratories to provide conformance testing to the standard. Government gateway A.2.63 The government gateway is a specific example of an access system. It is a hub linking portals and external back-office systems to government backoffice systems. Amongst other things, the gateway provides common security services, including identity registration and authentication of clients. Once a client has been authenticated, the government gateway forwards information between the client and appropriate government back-office systems. It coordinates transactions on government back-office systems on behalf of the client to support ‘joined-up’ government services. The government gateway also provides a secure messaging facility to allow government departments to communicate with the client. The linkage between a portal and a government back-office system may be asynchronous, or synchronous. Government user A.2.64 A government user in this context denotes a person or process that interacts with an e-Government service (in any capacity) from within the e-Government service provision boundary; this includes third parties involved in the provision of e-Government services. Identity registration A.2.65 Identity registration is the process by which a client registers a pseudonym, or registers their real-world identity to a desired level of assurance. This may include presentation of evidence by the client as proof of their real-world identity, 164 and checks to ensure that the evidence provided is authentic, valid and belongs to the client. The real-world identity of a client need only be established if this is essential to support the service(s) to be provided. A.2.66 Successful identity registration of a client might include provision of an account and/or electronic identity for that client. Identity verification A.2.67 Identity verification is the process of checking a client’s claimed real-world identity to a desired level of assurance, by checking the evidence provided is authentic, valid and belongs to the client. 164 For example, a driver’s license or passport number. e-Government framework for Information Assurance Draft 5.1 Page 127 Impact Levels A.2.68 The business impact of compromise is measured here on a four-point scale of impact, where Impact Level 0 (IL0) represents a negligible impact of compromise and Impact Level 3 (IL3) represents a significant impact of compromise. Depending on the range of clients to be supported by a service and their differing service requirements and corresponding needs for identity registration, enrolment and authentication, a service may consist of several compartments, with each compartment supporting information assets with a different set of impact levels. Information asset A.2.69 An information asset is any collection of information, or any capability to process and use that information, which is considered to have value to an organisation, its business operations and its continuity. Information Assurance A.2.70 Information Assurance (IA) is the confidence that e-Government services will protect the information they handle and will function as they need to, when they need to, under the control of legitimate users. Integrity A.2.71 Integrity is defined as the accuracy, correctness and completeness of an information asset. This requires confidence that the contents of a communication or transaction as received by the recipient is the same as the communication sent by the originator and could not have been modified, either deliberately or accidentally, en route to the recipient. The definition of integrity that is adopted here also encompasses non-repudiation. A.2.72 The risk assessment method that is adopted here defines information assets in terms of the value of their confidentiality, integrity and availability. Network defence services A.2.73 Network defence services are the technical means by which the threats associated with connecting services electronically may be countered. In the current context, this refers primarily to ensuring that the e-Government service is adequately protected against outside malicious electronic attack (and inadvertent attack might have the same effects) intended to: • undermine continued provision of a service; and/or • affect adversely the integrity of services or information provided; and/or • use the information resources of e-Government in the commission of serious crime; and/or • otherwise cause damage to government, systems or clients. Page 128 Glossary Non-repudiation A.2.74 Non-repudiation is the ability to link the apparent originator of an electronic transaction or communication with a real-world identity, such that the originator cannot subsequently deny responsibility for that transaction or communication. A.2.75 Non-repudiation encompasses accountability (ie the extent to which the issuer of an instruction can be held to account for that instruction), providence (ie the extent to which users who are in receipt of information can act on that information) and evidence of receipt. Some elements of non-repudiation, particularly accountability and evidence of receipt, may need to be supported by services such as record management and time-stamping in some cases. A.2.76 In the risk assessment method that is adopted here, non-repudiation is treated as a component of integrity. Online identity registration A.2.77 Online identity registration is a subset of remote identity registration which involves the presentation and verification of evidence of a client’s electronic identity by purely electronic means. Out-of-band A.2.78 Out-of-band transactions occur via a communications channel other than the normal means of communication with a service. For e-Government services, this refers to communication via a channel other than the internet. Post, telephone and SMS are all examples of out-of-band communications channels in this context. Provisioning A.2.79 Provisioning is the process of providing a client with accounts, the appropriate credentials and supporting information to access those accounts, all rights associated with those accounts, and all of the resources necessary to manage those accounts. Pseudonymous client A.2.80 A pseudonymous client is one who reveals only a pseudonym prior to authentication for a specific service. A pseudonymous client establishes a persistent electronic identity which can be recognised for repeat transactions but does not reveal their real-world identity. A.2.81 See the definition of anonymous client for comparison. Public sector body A.2.82 The term public sector body as used here has the meaning ascribed to it by Regulation 3 of the Freedom of Information Act. A few examples of public e-Government framework for Information Assurance Draft 5.1 Page 129 sector bodies are government departments, local authorities, police authorities and NHS organisations, schools, colleges and universities, the police, the House of Commons and the House of Lords, the Northern Ireland Assembly, the National Assembly for Wales. Real-world identity A.2.83 A real-world identity is a set of attributes (eg name, date of birth, national insurance number), which uniquely discriminates between clients. An entity can possess only one real-world identity (eg a person or an organisation). However, a single real-world identity may be used in conjunction with different roles and/or support several electronic identities. Depending on the transaction, a client may be required to reveal their real-world identity or may be permitted to use a pseudonym or remain anonymous. Receipt A.2.84 A receipt provides evidence for a party in a transaction that can be used at a later date to confirm that a specific element of the transaction has been completed. Registration authority A.2.85 A Registration Authority (RA) is an organisation that verifies evidence both that a real-world identity exists and that a client is entitled to use or represent that real-world identity. Remote identity registration A.2.86 Remote registration of a client’s identity involves presentation and verification of that identity via electronic delivery mechanisms, or offline mechanisms such as telephone or post. Relying party A.2.87 A relying party trusts a credential to associate an electronic identity with a client. The relying party is often the organisation that is responsible for carrying out the e-Government service, and hence relies upon a credential as part of authorising a client. A.2.88 Clients may also be relying parties if they rely on a government-issued credential to assure themselves that they are really dealing with the government. Risk A.2.89 A risk is the potential that a given threat will exploit a compromise path to compromise one or more information assets. If there is no business impact of compromise, or no likelihood of the risk being realised, there is no risk. Page 130 Glossary Risk assessment A.2.90 A risk assessment is an assessment of threats to, impact on and vulnerabilities of information and information processes and the likelihood of their occurrence. Roles A.2.91 A client may assume one or more roles in their interaction with government. For example, a person may simultaneously be both an employee and an employer. Similarly, government users may assume a number of roles in their interaction with e-Government services. Senior Information Risk Owner A.2.92 The SIRO is an individual identified within each department as being responsible for information risks and for influencing the board in managing these risks properly. Service authentication A.2.93 Service authentication is the process by which an e-Government service presents a credential and collateral information to a client (eg an electronic signature) which is checked by or on behalf of the client to verify 165 the electronic identity of the service. A.2.94 See also authentication and client authentication. Service provider A.2.95 A service provider is an organisation responsible for the provision of a specific e-Government service. The service provider might merely operate the service using its own or government-owned equipment, or it might design and develop the service. A.2.96 The service provider must ensure that the service and relevant systems are compliant with the e-government security framework, as required by the SIRO and in conjunction with the Accreditor. Threat A.2.97 A threat is the level of danger posed to an information asset by an attack group, based on the capability and motivation of that attack group to attack the information asset (and modified by any deterrence and opportunity considerations as appropriate). If there is no threat to an information asset, there is no risk to that asset. 165 Verification of a service might be achieved by a client using a third-party certification authority such as Verisign. e-Government framework for Information Assurance Draft 5.1 Page 131 Transaction A.2.98 A transaction is an exchange between two parties. The term transaction is used specifically here to represent an exchange between a client and an e-Government service. Trust service approval schemes A.2.99 Trust service approval schemes provide assurance by developing sets of criteria against which trust service providers can independently be assessed for each of the trust services they wish to provide for clients. Trust service approval is an essential element in providing a level of assurance to individuals and companies using or relying upon e-government transactions. A.2.100 The tScheme is one example of an independent, industry-led, trust service approval scheme. Trust services A.2.101 Trust services are the means by which e-Government users (whether government users or clients) can make commitments (binding 166 or less formal) electronically, and if necessary, furnish the technical evidence to resolve any dispute. In the context of this guidance, trust services must ensure that: • transactions are repudiation); demonstrably traceable to the originator (non- • transactions are demonstrably traceable to the recipient (evidence of receipt); • commitments made using e-government services are not liable to fraud or theft (trusted commitment service); • information received from or passed via the e-Government services is not altered or otherwise subverted (integrity). Trust service providers A.2.102 Trust service providers are those organisations that provide the means to ensure confidence in e-Government services, such as Registration Authorities (RAs), credential issuers and Certification Authorities (CAs). Trusted commitment service A.2.103 Trusted commitment service is ensuring that authorised clients of e-Government services are confident that e-government services are not liable to theft or fraud. 166 A binding commitment is typically one where parties to the transaction are fulfilling statutory obligation or there is a requirement to commit resources. Page 132 Glossary User A.2.104 The definition of user that is employed here includes both clients and government users. Verification A.2.105 Verification is the process of confirming that someone (or something) is who (or what) they claim to be. Vulnerability A.2.106 A vulnerability is a feature of a system which, if exploited by an attacker, would enable the attacker to breach security. e-Government framework for Information Assurance Draft 5.1 Page 133 B B.1 B.1.1 Related policy and guidance Identity management The CSIA is the body responsible for the provision of guidance on IA across government. However, the Home Office (HO), via the Identity and Passport Service (IPS), is the lead department within government for identity registration and management. The IPS is developing both strategic guidance on identity management 167 and also documentation to support IA practitioners. 168 Where possible, this guidance has been developed in line with extant IPS thinking. Close ties between CSIA and IPS will be maintained to ensure that the e-Government policy and guidance and IPS guidance remain aligned. The European Identity Management (EID) Programme will support a coherent approach to identity management across Europe and aims to ease the exchange of identity information as required between European government organisations (for example, to manage the movement of individuals across Europe to live and work, provision of medical treatment abroad, etc). The EID programme is aligned with the IPS approach to identity management. UK government guidance for IA The MPS represents the minimum requirement for security management for all central government departments and other organisations bound by the MPS. The MPS and its supporting documents are aligned with the International Organisation for Standardisation (ISO) 27000 series of standards, so that adherence with MPS will ease the route to ISO 27001 certification. HMG IS2, HMG IS1 and the Infosec Manuals and Memoranda support MPS by detailing the minimum requirements for IA, risk management and risk assessment across all organisations bound by the MPS. HMG IS2 is aligned with Office of Government Commerce (OGC) guidance on risk management. International guidance for IA ISO 27000 series B.1.2 B.2 B.2.1 B.2.2 B.3 B.3.1 The ISO 27000 series of documents provide a set of international standards for the management of information security, which have been widely adopted across Europe and the Commonwealth. These documents represent commercial best practice for information security and include: Cross-government identity management strategy (innovation and effectivenes), Mireille Levy. This document is currently at Draft Version 0.14, dated 2 Oct 2006. IPS identity management practitioners guide, Martina Rydman and John Hughes. This document is currently at Draft Version 0.8, dated 1 Apr 2006. 167 168 Page 134 Related policy and guidance • ISO 27000 – technical vocabulary for IA; 169 • ISO 27001:2005 – information technology, security techniques, information security management systems – requirements; 170 • ISO 27002 – information technology, security techniques, code of practice for information security management; 171 • ISO 27003 – information technology, security techniques, implementation guidance; 172 • ISO 27004 – information technology, security techniques, information security management metrics and measurement; 173 • ISO 27005 – management; 174 information technology, security techniques, risk National Institute of Standards and Technology B.3.2 The American National Institute of Standards and Technology (NIST) has adopted a similar approach to the UK Government for e-Government service provision. 175 Levels 1-4 as defined by NIST map broadly onto ILs 0-3 as defined here. Similarly, the Australian e-Authentication Framework has adopted four impact levels which map broadly onto ILs 0-3. The models for e-Government service provision adopted by the Canadian and New Zealand governments are based on open standards and ISO guidance. European Interoperability Framework B.3.3 The European Interoperability Framework (EIF) is a pan-European initiative to improve communication between European member states and support the delivery of pan-European e-Government services to businesses, citizens and their delegates. The high-level framework of the EIF 176 provides 17 recommendations to support EU interoperability, based around the principles of: • accessibility of services; • development of multilingual web-sites; • consideration of security and privacy, promoting a PKI-based approach; 169 170 171 172 173 174 175 176 B.3.4 This document is currently in development. This document is the replacement for BS7799 Part 2. This document is due to be released in 2007 as a replacement for ISO 17799:2005, which in turn replaces BS7799 Part 1. This document is currently in development. This document is currently in development. This document will be the replacement for BS7799 Part 3. Further details can be found at the NIST web-site, http://www.nist.gov. European Interoperability Framework for pan-European e-Government services, Version 1.0, and other information on the EIF may be found at the Interoperable Delivery of European e-Government Services to public Administrators, Businesses and Citizens (IDABC) web-site, http://ec.europa.eu/idabc. e-Government framework for Information Assurance Draft 5.1 Page 135 • subsidiarity; • use of open standards and open-source software wherever possible; • use of interoperable middleware; • use of common standards such as TCP/IP, HTTP, S/MIME, etc. B.3.5 The EIF highlights a number of key interoperability areas for member states, including public services for citizens and for businesses. European Network and Information Security Agency B.3.6 European Network and IS Agency (ENISA) 177 is set up to provide advice, analysis, awareness-raising and promotion of risk management methods and maintains a directory of relevant bodies for European member states. The work of the ENISA is currently at an initial stage of development. Future iterations of this document will need to be cognisant of ENISA initiatives. Relevant legislation The principal pieces of legislation that are likely to inform the IA requirements for e-Government service implementations include and are not limited to: • the Human Rights Act and the underlying European Convention on Human Rights set out everyone’s right to privacy in their correspondence; • the Data Protection Act 178 sets requirements for the proper handling and protection of personal information held within information processing systems; • the Electronic Communications Act sets the requirements for electronic signatures and their equivalence to conventional signatures; • the Regulation of Investigatory Powers Act makes it an offence to intercept communication on any public or private network; case and time limited exemptions may be granted subject to warrant; • the Terrorism Act makes it an offence to take actions which are designed seriously to interfere with or seriously to disrupt an electronic system; • the Wireless Telegraphy Act controls the monitoring of wireless telegraphy; • the Police and Criminal Evidence Act defines conditions under which law enforcement may obtain and use evidence; • the Computer Misuse Act makes attempted of actual penetration or subversion of computer systems a criminal act; B.3.7 B.4 B.4.1 177 178 Further details can be found at http://www.enisa.eu.int. The DPA and the eight data protection principles that underpin it are summarised at Section 4.3. Page 136 Related policy and guidance • the Public Records Act lays down requirements for the proper care and preservation of documentary records of government activities; • the Official Secrets Act lays down requirements for the proper control of government information; • the Freedom of Information Act lays down the citizen’s rights of access to government held information. e-Government framework for Information Assurance Draft 5.1 Page 137 C C.1.1 Service provision levels The previous e-Government security framework documentation defined a set of four service provision levels, layered according to the severity of consequences that they might arise. These are set out in Table 20. These service provision levels have subsequently been adopted and adapted by central government, and correspond roughly to the definitions as set out in the HMG Impact Level table, as reproduced in part at Annex D. Appropriate e-Government Transactions No private information content. Minimal damage might arise from: • • • • • failure to keep any commitments made; misappropriation of real-world identity; misappropriation of electronic identity (or no electronic identity is asserted); non-malicious failure; malicious electronic attack. Severity of Consequences minimal inconvenience to any party; no risk to any party’s personal safety; Level 0 minimal financial loss to any party; no damage to any party’s standing or reputation; no distress being caused to any party; no assistance in the commission of or hindrance to the detection of serious crime. minor inconvenience to any party; no risk to any party’s personal safety; Level 1 no release of personally or commercially sensitive data to third parties; minor financial loss to any party; minor damage to any party’s standing or reputation; minor distress being caused to any party; no assistance in the commission of or hindrance to the detection of serious crime. significant (moderate) inconvenience to any party; no risk to any party’s personal safety; Level 2 significant (moderate) financial loss to any party; significant (moderate) damage to any party’s standing or reputation; significant (moderate) distress being caused to any party; assistance in the commission of or hindrance to the detection of serious crime. The information exchanged is client specific but the impact of public exposure would be a minor resource or nuisance on one or more involved parties. Minor damage might arise from: • • • • • failure to keep any commitments made; misappropriation of real-world identity; misappropriation of electronic identity; non-malicious failure; malicious electronic attack. Involving private information that could be regarded as sensitive. Significant damage might arise from: • • • • • failure to keep any commitments made; 179 misappropriation of real-world identity; misappropriation of electronic identity; non-malicious failure; malicious electronic attack. 179 This level would cover transactions of an official nature in which failure to complete the transaction may be interpreted as a statutory infringement that may incur a penalty, or which may have a significant impact on a third-party. Page 138 Service provision levels Severity of Consequences substantial (significant) inconvenience to any party; risk to any party’s personal safety; the release of personally or commercially sensitive data to third parties; Level 3 substantial (significant) financial loss to any party; substantial (significant) damage to any party’s standing or reputation; substantial (significant) distress being caused to any party; assistance in the commission of or hindrance to the detection of serious crime. Appropriate e-Government Transactions Involving private information that could be regarded as very sensitive. Substantial damage might arise from: • • • • • failure to keep any commitments made; 180 misappropriation of real-world identity; misappropriation of electronic identity; non-malicious failure; malicious electronic attack. Table 20: summary of previous service provision levels 180 This level would cover transactions of an official nature in which failure to complete the transaction might have a substantial financial impact (which might not be recoverable), or impact on the health or safety of installations or individuals. e-Government framework for Information Assurance Draft 5.1 Page 139 D D.1 D.1.1 HMG Impact Table Impact level definitions The table that is spread across the following two pages sets out the HMG Impact Table definitions for IL0 through IL3, reproducing the segments of the Impact Table that are relevant to e-Government service provision. These definitions replace the set of four service provision levels as defined by the previous e-Government security framework. The impact levels that are assigned for e-Government services following these definitions are expected to correspond roughly (but not exactly) with the original definitions (as reproduced at Annex C). The service characteristics for most e-Government services should be subject to an impact level between IL0 and IL3. Where IA requirements exceed these definitions, the full impact level table covers up to IL6 and is set out within HMG IS1. The impact level depends on the context of the parties likely to be affected. A significant financial loss to an individual might, for example, be a minor matter to a large company. This is reflected by the definitions in the Impact Table. Impact Table extracts See overleaf. D.1.2 D.1.3 D.2 D.2.1 Page 140 HMG Impact Table Area A) Public safety and law Sub-category A1) Impact on life and safety A2) Impact on provision of emergency services A3) Impact on crime fighting Impact Level 0 - minimal N/A N/A Impact Level 1 - minor N/A Disruption to emergency service activities that requires reprioritisation at the local (e.g. police station) level to meet expected levels of service. N/A N/A A4) Impact on judicial proceedings N/A N/A B) Trade, Economics and the Public Finances B1) Impact on public finances Minimal impact (e.g. cost of sundries) N/A Cause a loss to Public Sector of up to £1000 B2) Impact on UK trade and commerce N/A C1) Risk to life and safety C2) Impact on the provision of the service (independent of risks to life and safety) C3) Inconvenience and impact on public confidence in public services C4) Impact on public finances C5) Impact on non-public finances C) Public Services N/A N/A N/A Likely to affect a single citizen May cause minor inconvenience to an individual citizen N/A Likely to have no impact or minimal impact (e.g. cost of sundries) N/A N/A N/A Likely to reduce an individual citizen's perception of that service (e.g. a compromise leading to the cancellation of a hospital appointment) Likely to cause loss to the Public sector of up to £1000 Likely to cause minor financial loss to any party (e.g. loss of <£100 for an individual or sole trader, loss of <£1000 for a larger business or organisation) N/A Likely to cause embarrassment to an individual citizen or organisation N/A C6) Distress to the public C7) Damage to standing or reputation C8) Locally provisioned services with an impact on the personal safety of citizens (e.g. sheltered accommodation) C9) Locally provisioned services with an impact on the health of citizens C10) Locally provisioned services with no impact on health or safety of citizens C11) Locally provisioned services in support of the Civil Contingencies Act D1) Communications D2) Power D3) Finance D4) Transport D5) Water and Sewage D6) Food and Consumables N/A Minimal impact Minimal impact Disruption, compromise or flawed working of a local service which could pose a risk to health Cancellation of services to a small number (up to 10) of citizens (e.g. closure of a library or other facility) Isolated or minor incident to which a Local Authority is not able to react within a few days which affects a small number of citizens Local loss of telecoms for a few hours Local outages causing disruption for up to 12hours Minimal impact Minor disruption of key local transport systems for up to 12 hours Breakdown of local water supplies and/or sewage service for more than a day Local disruption to the distribution of some essential goods, raw materials, medicines and/or food for up to a week Minor and short term (up to 1 month) environmental damage/contamination to a local area D) Critical National Infrastructure (CNI) Minimal impact Minimal impact Minimal impact Minimal impact Minimal impact Minimal impact D7) Hazards Minimal impact e-Government framework for Information Assurance Draft 5.1 Page 141 Impact Level 2 - moderate N/A Disruption to emergency service activities that requires reprioritisation at the area or divisional level to meet expected levels of service. Hinder the detection of low-level crime (i.e. crime not defined in legislation as "serious crime") Minor failure in local Magistrates courts Impact Level 3 - significant Risk to an individual’s personal safety or liberty Disruption to emergency service activities that requires reprioritisation at the county or organisational level to meet expected levels of service. Impede the investigation of, or facilitate the commission of low-level crime (i.e. crime not defined in legislation as "serious crime"), or hinder the detection of serious crime. Cause a low-level criminal prosecution to collapse; cause a conviction for a low-level criminal offence to be declared unsafe or referred for appeal. Cause a loss to HMG/Public Sector of up to £1 million Cause a loss to Public Sector of up to £10,000 Undermine the financial viability of a number of UK SMEs Undermine the financial viability of a minor UK-based or UK-owned organisation Likely to risk any party's personal safety Likely to require active management at the county or authority level to meet expected levels of service. Likely to result in undermined confidence in the service provider generally (e.g. public failures at a hospital leading to noticeable lower public confidence in that hospital) Likely to cause a loss to HMG/ Public sector of up to £1 million Likely to cause significant financial loss to any party (e.g. loss of up to £10,000 for an individual or sole trader, loss of up to £100,000 for a larger business or organisation). Likely to cause prolonged distress for an individual citizen, or short-term distress for many citizens Likely to cause loss of reputation for many citizens or organisations Risk to any party's personal safety (e.g. the compromise of the address of a victim of abuse now in sheltered housing, where it is assessed that there is a moderate risk of further abuse if such information became known to the original perpetrator) Authority-wide disruption, compromise or flawed working of services which could pose an increased risk to health (e.g. spread of disease) Cancellation of multiple services to a number (up to 1000) of citizens leading to financial losses (up to £10,000) Significant incident to which a Local Authority is not able to react within 24hours which affects a large number of citizens/local businesses - e.g. significant flooding, fire, contamination or explosion. Local loss of telecoms for up to 24 hours Loss of power in a region causing distribution for up to 24 hours Major loss of a Leading Financial company of £millions Major disruption of key local transport systems for up to 24 hours Breakdown of local water supplies and/or sewage service or prolonged drought (up to 1 months) Regional disruption to the distribution of some essential goods, raw materials and medicines and/or widespread disruption of food for up to a week Major and short term (up to 12 months) environmental damage/contamination to a local area N/A Likely to affect many citizens Likely to reduce the perception of that service by many citizens (e.g. compromise leading to an outpatient clinic closing for a day, with cancellation of multiple appointments) Likely to cause a loss to the Public sector of up to £10,000 Likely to cause moderate financial loss to any party (e.g. loss of up to £1000 for an individual or sole trader, loss of up to £10000 for a larger business or organisation) Likely to cause short-term distress to an individual citizen Likely to cause loss of reputation for an individual citizen or organisation Risk to any party's personal safety (e.g. the compromise of the address of a victim of abuse now in sheltered housing, where it is assessed that there is a low risk of further abuse if such information became known to the original perpetrator) Disruption, compromise or flawed working of local services which could pose an increased risk to health (e.g. spread of disease) Cancellation of services to a number (up to 100) of citizens (e.g. closure of a library or other facility) Isolated or minor incident to which a Local Authority is not able to react within a few days which affects a number of citizens/local businesses Local loss of telecoms for up to 12 hours Local outage causing distribution for up to 24 hours Embarrassment to a Financial Company leading to minor loss of confidence Minor disruption of key local transport systems for up to 24 hours Breakdown of local water supplies and/or sewage service for more than a week Local disruption to the distribution of some essential goods, raw materials, medicines and/or disruption of food for up to a month Minor and short term (up to 6 months) environmental damage/contamination to a local area Page 142 HMG Impact Table This page is intentionally blank e-Government framework for Information Assurance Draft 5.1 Page 143 E E.1 E.1.1 Identity registration examples General This annex presents some examples of acceptable remote and online evidence for the identity registration of an individual. Details of the specific documents that may be accepted as suitable items of evidence, and a further discussion of acceptable countermeasures for the registration of individuals and organisations, may be found within the HMG minimum requirements documents for the verification of the identity of individuals 181 and organisations. 182 Registration IL1 examples Registration IL1 remote identity registration examples E.2 E.2.1 For remote identity registration of an individual at Registration IL1, a personal statement as per face-to-face identity registration must be provided. A sufficient level of assurance that the identity asserted corresponds to a realworld identity, and that the application was made by the client whose identity is asserted, might be obtained via any one of the following procedures: • independent verification of the client’s address (eg using a credit reference agency or national identity register) and direct mailing of identity registration information to the client at that address, followed by written acknowledgement (eg a signed receipt) by the client that they have received this information; • telephone contact with the client prior to completing the identity registration on an independently verified home or business number, utilising a minimum of two pieces of personal identity security information that have previously been provided during the setup process; • internet sign-on following verification procedures where the customer uses security codes, tokens and/or other passwords which have been set up during the identity registration process and provided by out-of-band means (eg mail or secure delivery) to the named individual at an independently verified address; • an initial payment by cheque drawn on a personal account in the client’s name at a UK or EU bank or building society. 181 HMG’s minimum requirements for the verification of the identity of individuals, Version 2.0, January 2003. This document may be downloaded from the Cabinet Office web-site, http://www.cabinetoffice.gov.uk/. HMG’s minimum requirements for the verification of the identity of organisations, Version 2.0, January 2003. This document may be downloaded from the Cabinet Office web-site, http://www.cabinetoffice.gov.uk/. 182 Page 144 Identity registration examples Registration IL1 online identity registration examples E.2.2 For online identity registration of an individual at Registration IL1, a personal statement as per face-to-face identity registration must be provided. A sufficient level of assurance that the identity asserted corresponds to a realworld identity, and that the application was made by the client whose identity is asserted, might be obtained via any one of the following procedures: • use of the Verified by VisaTM (VbV) or MasterCard SecureCodeTM services; where an individual presents a valid and current card and associated preregistered password, this is considered to be sufficient to demonstrate that the card was sent to a valid address by a bank, and that the client’s identity was validated by the issuing bank at the time that the VbV or SecureCode password was set up; this is taken as providing reliable thirdparty corroboration; • use of the identity verification services of a Credit Industry Fraud Avoidance System (CIFAS) Participating Agency 183 to provide evidence of real-world identity and of activity in the community, where the parameters of the identity checking process have been previously agreed with the Agency as meeting the evidence requirements at this level (ie any combination of two from: one piece of evidence of identity; one piece of evidence of activity in the community; one piece of third-party corroboration); • an initial payment by debit card or credit card drawn on a personal account in the client’s name at a UK or EU bank or building society; this method of confirmation may be extended to e-Government services where no payment is required by withdrawal of a nominal sum which is immediately refunded. E.3 Registration IL2 examples Registration IL2 remote identity registration examples E.3.1 For remote identity registration of an individual at Registration IL2, a personal statement as per face-to-face identity registration must be provided. A sufficient level of assurance that the identity asserted corresponds to a realworld identity, and that the application was made by the client whose identity is asserted can be obtained via any one of the following procedures: • provision of at least two pieces of evidence to demonstrate evidence of identity (eg passport and birth certificate), plus two separate documents demonstrating activity in the community (eg a recent bank statement and council tax invoice); one or two pieces of documentary evidence may be replaced by third-party corroboration; provision of at least two pieces of third-party corroboration from separate independent sources; these must be organisations registered with, regulated and inspected by a statutory British public body and which can • 183 Such as Equifax, Experian or Callcredit. e-Government framework for Information Assurance Draft 5.1 Page 145 corroborate details about the client that are unlikely to be known to other persons; exceptionally, corroboration from only one third-party may be sought, in cases where the registration authority is able to check elements of the client’s statement against its own or published records, and that third-party has access to a number of sources of information which will be known only to the client and those sources; also, the third-party must be able to corroborate a number of pieces of information concerning the client that is unlikely to be available to potential imposters. Registration IL2 online identity registration example E.3.2 For online identity registration of an individual at Registration IL2, a personal statement as per face-to-face identity registration must be provided. A sufficient level of assurance that the identity asserted corresponds to a realworld identity, and that the application was made by the client whose identity is asserted, would require both of the following to be provided: • submission of passport information and use of the Identity and Passport Service (IPS) passport checking service to confirm the identity of the passport holder and that the passport is valid and has not been reported stolen; • use of the identity verification services of a CIFAS Participating Agency to provide evidence of real-world identity and of activity in the community, where the parameters of the identity checking process have been previously agreed with the Agency as meeting the evidence requirements at this level (ie one piece of evidence of identity, two pieces of evidence of activity in the community and two pieces of third-party corroboration). E.4 Registration IL3 examples Registration IL3 remote identity registration examples E.4.1 Remote identity registration must only be undertaken at Registration IL3 if more than one piece of documentary evidence of both identity and activity in the community can be provided, plus third-party corroboration from more than one source. Further information should always be sought in the case of any doubt or inconsistency. Remote identity registration without submission of documentary evidence may only be used if strong corroboration of identity can be obtained from several (at least four) different trustworthy sources already known to the RA, and which can corroborate evidence that realistically can only be known to the client and the corroborator. In these situations, advice should be sought from the Information Commissioner. Registration IL3 online identity registration example E.4.3 To date, no suitably assured processes have been identified to enable a client to register their identity online without remote interaction at Registration IL3. E.4.2 Page 146 Identity registration examples However, it is expected that cross-checking against the proposed IPS identity register will enable e-Government service providers to obtain sufficient assurance of a client’s real-world identity to Registration IL3 and above. In the interim, where an overwhelming business benefit can be demonstrated, the procedures set out for Registration IL2 may be used in conjunction with thorough (Confidentiality/Integrity IL3) Accounting and Audit measures. This interim measure is strongly deprecated, owing to the significant degradation of the security provided, and is only acceptable while no alternative procedure is available. If this interim measure is used, a timescale for migration to a more acceptable method must be explicitly specified in the RMADS.