Central Sponsor for Information Assurance

e-Government framework for Information Assurance

Draft 5.1, December 2006

List of abbreviations

ALARM Association of Local Authority Risk Managers
BS Baseline Standard
CA Certification Authority
CAPS CESG Assisted Products Scheme
CC Common Criteria
CCT Mark CSIA Claims Tested Mark
CIFAS Credit Industry Fraud Avoidance System
CIRT Computer Incident Response Team
CLAS CESG Listed Advisor Scheme
CNI Critical National Infrastructure
CO (SPD) Cabinet Office (Security Policy Division)
CRL Certificate Revocation List
CSIA Central Sponsor for Information Assurance
DLA Disability Living Al owance
DoS Denial of Service
DPA Data Protection Act
DTI Department of Trade and Industry
DWP Department for Work and Pensions
EDRMS Electronic Document and Record Management System
EID European Identity Management (Programme)
EIF European Interoperability Framework
ENISA European Network and IS Agency
FCO Foreign and Commonwealth Office
GSi Government Secure Intranet
HMG IS1 HMG Infosec Standard No.1: (Part 1: risk assessment, Part 2: risk treatment)
HMG IS2 HMG Infosec Standard No. 2: risk management and accreditation
HO Home Office
HTTP(s) Hypertext Transfer Protocol (secure)
IA Information Assurance
IAPC Information Assurance Policy Committee
IDABC Interoperable Delivery of European e-Government Services to public Administrators, Businesses and Citizens
ILx Impact Level x
IPR Intel ectual Property Rights
IPS Identity and Passport Service
IS Information System
ISM Interconnection Security Measures
ISO International Organisation for Standardisation
ITSEC IT Security Evaluation and Certification Scheme
MPS Manual of Protective Security
NINO National Insurance Number
NISCC National Infrastructure Security Coordination Centre
NIST (American) National Institute of Standards and Technology
OGC Office of Government Commerce
OGD Other Government Department
PDCA Plan-Do-Check-Act
PIN Personal Identification Number
PKI Public Key Infrastructure
RA Registration Authority
RMADS Risk Management and Accreditation Document Set
SIRO Senior Information Risk Owner
SLA Service Level Agreement
SRO Senior Responsible Owner
SSL Secure Sockets Layer
S/MIME Secure / Multipurpose Internet Mail Extensions
SyOps Security Operating Procedures
TCP/IP Transmission Control Protocol / Internet Protocol
TLS Transport Layer Security
ToE Target of Evaluation
TTP Trusted Third Party
UPS Uninterruptible Power Supply
VbV Verified by Visa
VPN Virtual Private Network

[Note: in the CommentonThis html version most of the 20-odd Tables have been
removed. To see the tables in their original context see
http://www.cabinetoffice.gov.uk/csia/documents/pdf/consultation/ia_framework.pd
f Footnotes simply appear in their original positions in the text]

1 Introduction

1.1 Purpose

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

1.1.2 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 overal public perception of central and local government;

• promote trust between service providers and enable the advantages that information-sharing and rationalisation of effort wil 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.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 authorities4 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.2 The DPA and the eight data protection principles that underpin it are summarised at Section 4.3. 3 See Annex B for a further discussion of relevant legislation. 4 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).

• 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 tScheme6 (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 general y 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 guidance on the steps that they should take to protect their machines from online threats. Basic measures that al home users and organisations should take to protect their computers are set out at http://www.getsafeonline.org.

footnote 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. 6 Further information on tScheme may be found at http://www.tscheme.org. 7 This includes CESG Listed Advisor Scheme (CLAS) consultants and other consultants employed to support the development and/or accreditation of e-Government services, as wel as advisory bodies such as the Association of Local Area Risk Managers (ALARM) which provide support for development and accreditation activities.

Internal-facing information systems

1.2.7 Assurance of internal-facing8 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.

1.3 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 1.3.3 New e-Government services shal 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.

1.3.5 For legacy services, the policy and guidance as set out within this document wil be adopted wherever practicable.

1.3.6 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 wil be adopted from that point onwards.

footnote 8: Internal-facing systems will include, for example, information systems that support interdepartmental interactions and those for use by public-sector workers. 9 Version 6.0 of this document wil be the first issue version of the document following public consultation.

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 wil make more use of these services where possible.

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

1.4.3 Any third-party providing trust services support to e-Government transactions should normal y be approved under a scheme recognised by the UK Government such as tScheme, or equivalent.

Third-party service delivery

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 wil be required to provide services to the same standards as government itself would. Government wil in turn accept transaction data from those delivery channels, who wil certify that they have carried out the transaction to the agreed standard.

1.5 Ownership and maintenance

1.5.1 This draft of the IA policy and guidance for e-Government services (Draft 5.1) has undergone a significant revision fol owing broad stakeholder consultation. This document wil 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 wil be reviewed on an annual basis.

1.6 Glossary

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

1.7 Availability of further support and advice

1.7.1 In the first instance, any queries relating to the policy and guidance provided within this document should be directed to the CSIA at:

• CSIA, Cabinet Office, 22 Whitehal , 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 Whitehal , 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:

<li>CESG Customer Support Office, Hubble Road, Cheltenham, GL51 0EX. Email: enquiries@cesg.gsi.gov.uk 1.7.4 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. 1.7.5 Further information on the Association of Local Authority Risk Managers (ALARM) may be obtained from their web site, http://www.alarm-uk.com.

1.8 Document overview

1.8.1 The layout of this document is as fol ows:

• 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 overal 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 il ustrates 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;

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

2 How to use this document

2.1 Introduction General

2.1.1 This document forms part of the overal risk management process to be adopted throughout the project lifecycle of an e-Government service.

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

2.1.3 The overal approach to risk management and accreditation is summarised and discussed at Section 3 of this document.

Context

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.

2.1.6 The policy and guidance that is set out within this document fol ows 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 wil ease the route to ISO 27001 compliance.

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 wil 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 wil 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 fol owing 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.

Footnotes 11 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. 12

HMG Infosec Standard Number 1 Part 1 (Risk Assessment), Draft 1.0 of Issue 3.0, June 2006, NOT PROTECTIVELY MARKED. 13 HMG Infosec Standard Number 1 Part 2 (Risk Treatment), Draft 1.0 of Issue 3.0, June 2006, NOT PROTECTIVELY MARKED. 14 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. 15 Supporting RESTRICTED through to TOP-SECRET information. 16 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 17 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 intel igence services.

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 wil help to inform the development of the service, mitigating risks and potential y reducing development costs. 2.2.2 The e-Government IA risk assessment method consists of the fol owing steps as il ustrated 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 The tool also includes some discussion of enrolment and proof of status. 19 For example, to reduce the value of some of the impact levels. 20 For example, introducing physical, procedural or personnel measures in place of some countermeasures.

• 5. agree and document risk management decisions; this might impact on the required countermeasures.

[Figure 1 deleted]

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 wil 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 non-repudiation, evidence of receipt and trusted commitment services;

• the individuals that wil 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.

• 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, pre-requisites for each connection, balance-of-responsibility for management, etc; - the likely attack groups and what compromise paths they might exploit; - the transactions that wil support the col ection, 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 wil 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 [Table 1 deleted]

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 wil , in general, attract a different impact level.

2.2.8 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 wil attract an impact level for each service characteristic as set out at Table 1, information assets themselves wil only attract impact levels for confidentiality, integrity and availability.

2.2.9 Considerations during the assignment of impact levels are as fol ows:

• 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 value24 the transactions and information assets that support a service;

• some transactions or information assets wil attract impact levels in excess of IL3 for one or more service characteristics, so that the ful HMG Impact Table25 must be consulted; in these cases, HMG IS1 should be applied to determine appropriate countermeasures in addition to those in this document;

• al ocation of impact levels wil require consideration of al direct and indirect consequences laid out in the definition of the levels, al ocating the highest of these to the transaction; it is unlikely that al of the definitions in the Impact Table wil be relevant for each service characteristic;

footnote 23 The use of the term "enrolment" as defined here should not be confused with the HO / IPS definition, which relates specifical y to biometrics. 24 Readers should note that value, as defined here, does not necessarily refer to monetary value. 25 This is to be produced by CSIA as a stand-alone document.

2.2.10 After assigning impact levels for a particular transaction within a service, the service provider wil 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 al 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 minimum countermeasures specified by HMG IS1, which include:

• 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 wil 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 al 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;

• informing clients of any specific instructions relating to the issue of credentials (especial y 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 wil depend on specific requirements of the transaction (eg in support of a requirement for non-
repudiation, 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 overal 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 Al 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;

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

26 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. 27 The level of detail required within the RMADS wil depend on the impact of the service. For example, for an e-Government service whose service characteristics are mostly IL1, an outline RMADS would general y be sufficient. However, for an e-
Government service whose service characteristics are mostly IL3, a greater level of detail would general y be required to support the implementation and management of IA for the service.

2.2.18 Prior to rol -out of an e-Government service, the service provider must consider how the required level of IA wil 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.

2.2.19 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 wil require regular scheduled reviews and change-management. Changes to the RMADS should be agreed and endorsed by al stakeholders and should be reflected by training as appropriate.

3 Risk management and accreditation

3.1 General

3.1.1 This section sets out the approach to risk management and accreditation to be adopted in support of e-Government service provision.

3.1.2 The HMG IS228 approach to risk management has been adopted. This approach is broadly aligned with ISO and OGC guidance on risk management. Adherence wil help an organisation to demonstrate compliance with the ISO 27000 series of documents, and ease the route to ISO 27001 compliance.

3.1.3 It is anticipated that this document wil 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.

3.1.4 The overal 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.

[Fig 2 deleted]

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

3.2 Risk ownership General

3.2.1 Overal 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.

3.2.3 For e-Government services that are delivered by or on behalf of central government organisations, the SIRO wil 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.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.

3.2.5 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

3.2.6 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 pitfal s 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.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.

footnote 29 The role of the pan-government accreditor is due for review over the next year.

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.

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

3.2.12 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 wil 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.13 It may be necessary to require clients to instal standard commercial security products as a pre-requisite to accessing some e-Government services.30 However, any requirement for a client to instal 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).

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

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.

3.2.16 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 general y, a delegate would be authorised to perform some wel -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).

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

3.3.2 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 al those involved in IA risk management;

• IA awareness and training;

<li>IA incident reporting and recovery operations;

• compliance with appropriate standards, policies and laws.

footnote 31 The level of detail required within the RMADS wil depend on the impact of the service. For example, for an e-Government service whose service characteristics are mostly IL1, an outline RMADS would general y be sufficient. However, for an e-Government service whose service characteristics are mostly IL3, a greater level of detail would general y be required to support the implementation and management of IA for the service.

Risk assessment and treatment

3.3.3 Having fol owed 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 wil need to refer to MPS.

3.3.5 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;

• 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 al times, that maintenance staff are not al owed 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. 32 This option must be treated with caution. Even if responsibility for limiting risk is transferred to outside the organisation, the risk wil stil rest wherever the business impacts are actual y felt. 33 SC clearance as a minimum would be preferable for central government users with access to sensitive information. 34 It may also be prudent to ensure clearance of government users who support lower-impact services, especial y those with Confidentiality IL2, Integrity IL2 and/or Availability IL2.

3.4 Service delivery Project and asset management

3.4.1 IA and risk management is a through-life process, as il ustrated 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.

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

footnote 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. 36 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.

[Fig. 3 deleted]

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.

3.4.4 Outsourcing contracts, or elements of contracts, for the development, procurement, provision and maintenance of services can be complex. This is 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).

3.4.6 NISCC good practice guidance on outsourcing37 provides an outline discussion of these issues.

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

3.5.2 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 ful 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.

3.5.3 Accreditor involvement is required at al 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.

3.5.4 Where formal accreditation is required, this is an essential prerequisite to the fol owing activities, supported by evaluation and testing as appropriate:

• 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. 37 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.

Evaluation / testing

3.5.5 It is expected that government wil 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.

3.5.6 Use of IT security products and services that have been formal y 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.

3.5.7 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 wil 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 in some cases and Confidentiality IL3 services should be subject to formal accreditation (and an ISO 27001 audit where relevant). [Table 2 deleted] 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 fol owing a major patch (Windows XP SP2 is a good example of such a patch). 39 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.

4 Service provision environment

4.1 General

4.1.1 This section il ustrates 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.

4.2 Service provision environment Service provision model

4.2.1 Figure 4 presents a generic model for the e-Government service provision environment. The e-Government service wil typical y manage a combination of information that is electronical y 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

[Figure 4 deleted]

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 represent information that is available electronical y to clients with different levels of authorisation40 or entitlement.41

4.2.3 The "government user information space" in the figure refers to information that is made available electronical y to government users. This may or may not include some or al 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.

4.2.4 It is envisaged that the Government Gateway wil 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 wil be responsible for the management and protection of some or al of the identity registration, enrolment and authentication details that are required to support some e-Government services.

4.2.5 There may potential y 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 al ow, 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 tunnel ing 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.

footnote 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. 41 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 wel -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.

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:

• foreign intelligence services with political, commercial or other motives;

• terrorists seeking to misuse or disrupt government resources. 4.2.11 Service providers wil 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 control ers 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 lawful y;

• 2. obtained and processed only for one or more specified and lawful purposes, and shal 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;

<li>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 commercial y 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;

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

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

4.3.3 Where personal data are processed on behalf of a data control er by a third-party, 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.

5 Identity registration

5.1 Overview

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

5.1.2 Identity registration typicaly 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 bil as evidence of recent activity at the address that they have given.

5.2 Identity registration process

5.2.1 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. 44 Authentication of the service is discussed further at Section 7. [Figure 5 deleted]

5.3 Impact level for identity registration

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

5.3.2 Services where a client may remain anonymous or where a client may register using a pseudonym wil attract Registration IL0, even if a high level of assurance is required for authentication of a client with a given pseudonym.45

5.3.3 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 wil thus be at least as high as the impact level for any proof-of-entitlement 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.

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

[Table 3 deleted] 5.3.4 Integrity46 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.

[Table 4 deleted]

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 wil 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 high-
  value information such as biometric information that is captured for 46 The IS1 definition of integrity, which we have adopted for this document, includes the requirement for non-repudiation of transactions and communications. 47 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. 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 Threats

5.4.1 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. 5.4.2 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. 5.4.3 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. 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. 49 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. 50 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.

5.5 General requirements

Registration evidence requirements 5.5.1 There wil 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.

5.5.2 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 client51 and the e-Government service.52

Informing the client

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 wil 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 electronical y, both the client and the e-Government service must be authenticated to an appropriate level of assurance to protect this information. Alternatively, some or al 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.

5.5.6 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 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. 51 For example, by ensuring that information posted to clients is sent to the correct address. 52 For example, by ensuring that the client is not provided with benefits for which they are no longer entitled.

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.

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

5.5.9 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 wil 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 escalation must require different evidence to that provided during the client's initial identity registration.56

footnote 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). 54 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. 55 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 enrol ed.

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 forensical y examine use of the e-Government service as necessary.

5.6 Registration countermeasures

5.6.1 The levels of assurance required to support identity registration are as fol ows:

• 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 al owing 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 bil s, 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.

5.6.3 Details of the specific items that constitute reputable evidence and trustworthy sources may be found within the HMG minimum requirements documents for the verification of the identity of individuals58 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.

56 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 wil a requirement to make available the record of what evidence was used. This wil not necessarily require the evidence itself to be exchanged. 57 This is to protect against fraudulent access to someone else's personal data.

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/. 59

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/. 60 Enquiries relating to the risk management tool should be directed to CSIA via the contact provided at Section 1.7.

[Table 5 deleted]

Footnotes: 61 In some cases, the client might be encouraged to provide some details (name, etc) to support establishing a persistent pseudonym. This would general y not be mandatory and these details would not be checked. 62 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. 63 If the registration authority holds its own detailed records, validation against these records may count as one of the required trustworthy sources. 64 For face-to-face registration at Registration IL2, any two of the fol owing, 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. 65 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. 66 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.

[Table 6 deleted]

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. 68 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. 69 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. 70 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. 71 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. 72 The face-to-face registration requirements for validating an organisation's representative at Registration IL3 are equivalent to the remote registration requirements.

6 Client enrolment to a service

6.1 Overview

6.1.1 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 enrol ed 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.

6.1.2 Successful enrolment of a client wil 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.

6.1.3 A client must enrol at or before first use of a service and may only use those services for which they are enrol ed. Evidence requirements for enrolment wil depend on the details of the service to be used and must be set in conjunction with relying parties. 6.1.4 Enrolment for a service might be carried out at the same time as identity registration73 or might be conducted after identity registration.74

6.2 Enrolment process

6.2.1 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 enrol ed 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 enrol ed 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 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.

footnote 73 For example, if a client registers and enrols directly for a specific e-Government service. 74 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. [Fig 6 deleted]

6.3 Impact level for enrolment

6.3.1 Enrolment for an e-Government service attracts an impact level which is based on the highest impact of al owing 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 6.3.2 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 real-
  world 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;

• whether an escalation in the assurance of a client's real-world identity is required to support enrolment;76 75 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. 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.

6.3.4 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. 6.3.5 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.

6.4 Threats

6.4.1 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. 6.4.2 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 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. their entitlement.77 This information wil 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 electronical y, both the client and the e-Government service

must be authenticated to an appropriate level of assurance to protect this information. Alternatively, some or al 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. 6.5.3 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 continual y 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 col ateral 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.

footnotes: 77 For example, a client might be required to provide details of their income to support an application for tax credits. 78 Mechanisms should be put into place to al ow 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 wil be require wil 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).

6.5.5 To eliminate duplication of effort, the client may wish to submit enrolment information once and al ow it to be shared by al 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 wil 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. 6.5.8 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;

• a delegate acting in a personal capacity on behalf of a relative might only enrol once, but fol owing a different process to regular clients (reflecting, for example, differing evidence requirements, levels of persistence, etc).

79 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. 80 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. 81 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 wil to notify some service providers of the death and to settle financial accounts with others. 82 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. 83 For a delegate acting on behalf of a recently deceased family member, the enrolment process may wel require the delegate to provide, for example, proof of probate.

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 exceptions84 or an additional level of risk may have to be accepted by the service provider.85

6.5.10 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 general y, a delegate would be authorised to perform some wel -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.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, al 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 forensical y examine use of the e-Government service as necessary.

6.6 Enrolment countermeasures

6.6.1 The levels of assurance required to support enrolment are as fol ows:

• Enrolment IL0 services are freely available to al 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 For example, using traditional channels. 85 For example, accepting that some delegates wil subvert the identity registration and enrolment process by using the electronic identity of the client they represent.

6.6.2 In many cases, the information furnished to support client identity registration wil be sufficient proof-of-entitlement for a service. Where additional

proof-of-entitlement is required, the procedures to support this should be commensurate with those for identity registration at an equivalent impact level.

6.6.3 The information requirements to support enrolment wil vary on a service-
by-service 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.

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

7 Authentication and client access

7.1 Overview

7.1.1 Authentication is the process by which a credential and col ateral information are presented and verified, to establish a claim to a valid electronic identity. An electronic identity to support authentication by a client would typical y be provided during the identity registration and/or enrolment process.

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

7.1.3 The level of assurance that is supported by an electronic identity relates directly to the strength of the credential and of its col ateral information.86

7.2 Authentication process

7.2.1 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 typical y 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. 86 For example, the intrinsic strength of a cryptographic key wil depend on the key length and the algorithm used, and on the complexity of any pin, password or passphrase that protects it. [Fig 7 deleted]

7.3 Impact level for authentication

7.3.1 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. 7.3.2 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

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 al owing 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, fol owing 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 equal y able to compromise other such services, so that the "security through diversity" argument no longer holds.

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.

7.4 Threats

7.4.1 There are a number of threats relating to the authentication process. These threats mainly relate to the vulnerability of client credentials and col ateral information in transit and in use within potential y 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.2 Protection of high-value credentials, such as biometric information, is a particular issue for service providers which must be careful y considered before making a decision to use these, as discussed at Section 5.3.

7.5 General requirements Issue of credentials

7.5.1 An authentication credential wil , 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

7.5.2 For most electronic transactions, government wil accept credentials provided, or partial y provided, by accredited third parties that register the identity of clients and issue them with credentials and supporting information. 88 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.

Protection of credentials from theft and unauthorised use

7.5.3 As a general rule, a credential should support the minimum of information that is necessary for it to function in an accessible form.

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

7.5.5 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 col ateral information such as a PIN, password or other user verification mechanism which is delivered separately.89

7.5.6 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 label ing individual transactions and use of workflow management tools. Use of transaction label ing and management tools is particularly important where there is a requirement for non-repudiation or evidence of receipt to support formal or informal obligations.

7.5.8 Clients should be informed of, and encouraged to adopt best practice in protecting their systems91 and any specialist requirements for specific services, and should be made aware of the risks of using unsecured or public access systems. Clients should also be informed of any measures to be taken before, during and after a client session.92

89 Further information on the complexity requirements for credentials and col ateral information may be found within the fol owing 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 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. 91 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.

Protection of transactions against impersonation and interception

7.5.9 For authentication at Authentication IL1 or above, it wil general y 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 al 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 wil typical y 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 col ateral information and what the process is for revoking and replacing these (eg how the replacement wil 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 automatical y 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 wil adopt the guidance given and that some client machines wil have been compromised. 93 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.

Accounting and audit

7.5.14 Accounting logs and audit information should be recorded, supported by appropriate audit procedures to track and forensical y 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.

7.6 Authentication countermeasures

7.6.1 The levels of assurance required to support authentication are as fol ows:

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

[Table 7 deleted]

94 For example, use of SSL/TLS with 128/256-bit key or out-of-band distribution of part or al of credential. 95 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. 96 For example, to enable personalisation of a service. 97 For example, use of a username and password or digital certificate. 98 For example, use of a digital certificate. 99 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. 100 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. 101 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. 102 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. 103 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

8 Confidentiality

8.1 Overview

8.1.1 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;

• ancil ary 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 wil be used and shared, for instance warning individuals sending information into an HMG domain that their communications may be monitored, recorded and retained.

8.2 Impact level for confidentiality

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

8.2.2 Al ocation 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 Intel ectual Property Rights (IPR) issues might also require consideration.

8.2.3 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). 104 For example, systems management information and information on the performance and uptake of e-
Government services. 105 This includes information provided to support registration and enrolment as well

as information provided during use of the service. 106 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.4 A smal 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 wil 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).

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

8.3 Use of protective markings and descriptors

8.3.1 Information that attracts an impact level for confidentiality may be label ed using the PRIVATE descriptor, in the format: [PRIVATE], [Level n], [optional].108 n is the impact level for confidentiality and the optional field al ows for a description of the type of information.109 Information that is assessed as requiring Level 0 wil not normal y attract the PRIVATE descriptor.

8.3.2 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 information110 and for this reason it may not be appropriate to explicitly label this information as RESTRICTED.

8.4 Threats

Data-stores 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;

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

107 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. 108 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 internal y 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. 109 For example, medical information concerning an individual might be marked as PRIVATE, Level 3, MEDICAL. 110 See the discussion on clients at Section 3.2.

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.

8.5 General requirements

8.5.1 Appropriate physical and procedural measures must be in place as elements of a multi-layer approach to confidentiality, as discussed at Section 3.3.

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

8.5.3 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 enrol ed and authenticated.

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

8.6 Confidentiality IL0 countermeasures General

8.6.1 At Confidentiality IL0 no explicit protection is needed, though care should stil 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.

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 sil 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 Adoption of normal good system practice for implementing and managing network connections must be applied to prevent electronic attack.

8.6.6 There are no specific requirements for detection of electronic attack, although checking of information-stores against regular backups is recommended.

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

8.7 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 general y acceptable to use the in-built security features of commercial products, configured correctly, but without enhancement.

8.7.2 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 wil require enhanced measures to protect the real-world identity of clients.111 111 For example, services to support reporting of fraud or criminal activities

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.

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

8.7.6 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 al ow access to information assets are revoked when a client is disenrol ed113 from a service. The appropriate Security Operating Procedures (SyOps) should be recorded in the RMADS.

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

8.7.8 Encryption of data in storage and transit might be required for certain niche areas.114

Effective accounting and audit

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: al government user applications capable of processing imported material shal 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.

• Import restrictions: the import of information objects from another domain should be limited to information object types reasonably required to meet business needs; al 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.

footnote 112 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. 113 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. 114 For example, encryption of password files 115 For example, client identifier, time of service access, transaction used, success or failure of transaction

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.

• Control ed closedown: a control ed 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 al incidents of electronic attacks and determine whether any additional electronic or procedural countermeasures should be put in place.

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 assured116 commercial cryptographic products to provide access control is appropriate for some purposes is required at this level.

8.8.2 An independent IT health check should be considered for al 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.3 The fol owing measures must be in place, over and above those for Confidentiality IL1, to protect the confidentiality of information in storage, use and transit.

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

8.8.5 Commercial operating system access controls must be employed for administrator access to systems.

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

8.8.7 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.8.8 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.

8.8.9 Information at Confidentiality IL2 should be processed on a system to which only authorised government users have physical access and should be password protected.

116 Cryptographic products to protect information at Confidentiality IL2 must be assured using the CCT Mark or an equivalent scheme, to EAL2 or above.

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 wil usual y 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 wil be similar to those for Confidentiality IL1, but accounting logs must be protected at a level appropriate for Confidentiality IL2 and more regular auditing wil be required.

Service protection

8.8.13 Prevention of electronic attack on e-Government services should be provided by:

• User application configuration: al government user applications capable of processing imported material shal 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; al 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. Al import requests shal 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 control ed 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 al 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 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.

• Control ed closedown: a control ed 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 al 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.

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

8.9.2 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 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 al 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.

8.9.5 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. 8.9.6 Processes handling information that attracts Confidentiality IL3 should be tested to check for any inadvertent data leakage.

8.9.7 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 wil usual y 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 Relevant client-related information should be recorded for each transaction.118

8.9.9 Capabilities to carry out display and detailed data-mining and analysis of the accounting records must be provided. 117 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 protectively-
marked material, Issue 1.0, January 2001. 118 For example, client identifier, time of service access, transaction used, success or failure of transaction, current transaction status.

Service protection

8.9.10 Prevention of electronic attack on e-Government services should be provided at this level by:

• User application configuration: al user applications capable of processing imported material shal 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; al 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. Al import requests shal 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 control ed 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 al 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 system-
  provided 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).

<li>Incident recovery procedures: there should be detailed incident recovery operating procedures to be fol owed in the event of an attack, based on the incident response plan.

• Control ed closedown: a control ed 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 al 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.

9 Integrity

9.1 Overview

9.1.1 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 al parties to rely on that information to support transactions where required; this includes evidence to support informal,119 formal or legal y 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 ancil ary 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.

9.2

Impact level for integrity 9.2.1 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 legal y binding commitments121, 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.

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. 120 For example, systems management information and information on the performance and uptake of e-Government services. 121 Similar considerations apply for less formal commitments.

9.2.2 The impact level for integrity is calculated using the HMG Impact Level table provided at Annex D.

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

9.2.4 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 left-hand table within Table 4 at Section 6 and also extends to enrolment.

9.2.5 When al ocating 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 service122 might have a disproportionate effect on the public perception of e-Government services as a whole.

9.3 Threats

9.3.1 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 non-
repudiation of contractual y binding transactions, evidence of receipt and trusted commitment services.

9.4 General requirements

General 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 al 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.

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 wil function as stated by the Vendor.

9.4.3 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 wil be

correctly received. This covers both erroneous information and information inadvertently or maliciously altered during storage, processing or transit.

Non-repudiation

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. Equal y service providers might wish to be assured that government cannot repudiate its part in a transaction either.

9.4.5 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 label ing 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.

9.4.6 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 wil 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.7 Clients and other users (including service providers) of the services must be able to demonstrate that transactions submitted have actual y 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.

Trusted commitment service

9.4.8 Authorised clients of e-Government services must be confident that (for example) their authorities for payment wil be properly control ed and are not vulnerable to fraudulent use of their means of payment, subject to the clients keeping relevant credentials or other personal information secure.

9.5 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. 9.5.2 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 No measures for non-repudiation are required at this level.

9.5.4 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, optional y, a transaction reference number, might be used to support this.

9.5.5 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 Existing service mechanisms are used to provide simple assurance that an object has been received by the recipient.125

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

124 For example, document format errors or incomplete web pages 125 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.

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.

9.6.2 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.3 Effective non-repudiation at Integrity IL1 is unlikely to be achievable. Measures that may be applied are essential y 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.

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

9.6.5 It is important that expert guidance be sought when setting up non-
repudiation schemes, as the additional trust achieved is often il usory unless the scheme is careful y 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.

9.6.6 Appropriate accounting log files should be kept, showing transaction times and records of system operation.

Evidence of receipt 9.6.7 Evidence of receipt would typical y be achieved at this

level by returning evidence of possession of the message to the originator under a non-repudiation 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.

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.

9.7.2 A transaction or a digest of the transaction, signed using an appropriately strong credential, must be used to provide evidence of integrity.127

9.7.3 The signature must be verified by the recipient of the transaction.

9.7.4 Modifications or errors in the signed object, whether accidental or deliberate, wil cause verification of the signature to fail.

Non-repudiation

9.7.5 A transaction or a digest of the transaction, signed by the originator, must be used to provide evidence of origin.

9.7.6 The signature must be verified by the recipient of the transaction, or by a third party.

9.7.7 Ownership of any public keys must be verified by a recognised entity, which may be the recipient or some other party.

9.7.8 Appropriate accounting log files must be kept, showing transaction times and records of system operation.

9.7.9 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-of-
receipt 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. 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 wil general y 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.

9.8.4 In addition, products and systems must provide appropriate protection for private keys and use standardised formats and protocols. 9.8.5 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.6 Evidence of receipt would typical y 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 manual y or automatical y. 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.

10 Availability

10.1 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 Impact level for availability

10.2.1 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 smal 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 wil 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 al owing 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 wil 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 al owing 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 al ocating 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. 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 wil deliberately or accidental y compromise these services;

• that data-stores wil be subject to unforeseen failure, physical attack or natural disasters.

10.4 General requirements

10.4.1 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 al 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 wil 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 wil be required.

Information availability

10.5.2 No special measures need be taken to ensure data backup or continuity of service fol owing an interruption to service. Business continuity must stil , however, be considered. 10.5.3 In particular, no special measures need to be taken to recover partial y 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 wil vary depending on the service to be provided, but indicative availability requirements would general y be expected 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.

10.6.3 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 wil not be necessary.

10.6.4 Battery backup must be provided to al ow `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.

10.6.6 A failure impact analysis must be carried out and recorded for al information and communication system components. This must be reviewed in the event of significant configuration changes.

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 fol owing an interruption to service. In particular, no special measures need to be taken to recover partial y completed transactions, except for those that affect the integrity of existing information. 10.6.9 Information back up must fol ow commercial best practice and enable restoration of al relevant information to within one week of the current date. Commercial best practice must be fol owed with a ful weekly backup and daily incremental backups. The restoration process should be documented in the business continuity plan and tested regularly. 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 external y provided services must be set to meet the availability requirements for transactions and information items. Uptime requirements wil vary depending on the service to be provided, but indicative availability requirements would general y 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.

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

10.7.3 Uninterruptible Power Supplies (UPS) must be used to al ow `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 ful inventory of al hardware and software and a network diagram showing al approved connections must be maintained. 10.7.6 Failure impact analysis must be carried out and recorded for al information and communications components. This must be reviewed in the event of significant configuration changes. No upgrades wil 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 partial y 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 partial y completed transactions except for those that affect the integrity of existing information.

10.7.10 Information back up must enable restoration of al relevant information to within one day of the current data. Commercial best practice must be fol owed with a ful 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 overal 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 external y

provided services must be set to meet the availability requirements for transactions and information assets. Uptime requirements wil vary depending on the service to be provided, but indicative availability requirements for the service would general y 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

10.8.3 UPS must be used to al ow `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 wil 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 ful inventory of al hardware and software and a network diagram showing al approved connections must be maintained.

10.8.6 Failure impact analysis must be carried out and recorded for al information and communications components. This must be reviewed in the event of significant configuration changes. No upgrades wil 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 partial y 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 al relevant information to within one day of the current data, and preferably more regularly than this. Commercial best practice must be fol owed with a ful 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.

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.

11 Worked examples

11.1 General

11.1.1 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 service132 al owing clients to register for health screening, and receive their test results, electronical y. Client requirements

11.2.2 The high-level actions that a client may wish to conduct in support of this service may include the fol owing:

• find out information about the service electronical y;

• book an appointment electronical y;

• be contacted electronical y to obtain the test results; 11.2.3 Other features that a client might require include the fol owing:

• 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 fol ows:

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

• 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 actual y received and has read any communications (if they did so). [Table 8 and Fig 8 deleted] 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. 11.2.6 It is considered unlikely that foreign intel igence 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 Impact levels133 must be assigned to each relevant service characteristic for each transaction a service supports,134 and for the information that it stores.

11.2.8 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;

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

[Table 9 deleted]

133 Defined by the HMG Impact Table, and reproduced in part at Annex D of this document. 134 As defined in the description of the service provision environment at . Table 8135 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).

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.

[Tables 10 & 11] 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.

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 wil 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 overal 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 wil 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).

11.3 Hypothetical tax return service

STEP 1: define the service Purpose 11.3.1 A service al owing an individual citizen to file a personal self-
assessment tax return electronical y.

Client requirements 11.3.2 The high-level actions that a client might wish to conduct in support of this service include the fol owing:

• electronical y 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 electronical y 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 fol owing:

• 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 electronical y 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 automatical y as they complete the form, so that they know what they owe or are owed straight away;

<li>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);

• a low level of assurance that a client is eligible to receive the service, as it is freely available to al 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.

[Table 12 deleted]

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 real-world identities or simply misusing their own real-world identity to claim back 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 intel igence 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.

11.3.8 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 levels140 must be assigned to each relevant service characteristic for each transaction a service supports,141 and for the information that it stores.

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 Defined by the HMG Impact Table, and reproduced in part at Annex D of this document. 141 As defined in the description of the service provision environment

143 This is assumed to be the general case, although there wil be exceptions where a client's tax return is greater than the values stated here.

[Table 13 deleted] 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. [Table 14 deleted]

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.

[Table 15 deleted]

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.

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 wil 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 high-
water 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 overal 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 wil be extended as necessary so that a tax return can be completed by other channels (eg postal). 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 al owing 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 Al 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.

11.4 Hypothetical disabled parking permit service

STEP 1: define the service Purpose

11.4.1 This service al ows clients with disabilities to apply electronical y 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 fol owing:

• apply for a parking permit electronical y, or delegate another person to apply for the parking permit in their name;

• have their eligibility to receive a parking permit established electronical y, with as little requirement as possible to provide evidence off-line;

• renew their permit electronical y;

• be able to update their personal information as required.

11.4.3 Other features that a client might require include the fol owing:

• 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 fol ows:

• 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 al owances received, provision of doctor's details and consent to contact);

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

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.

[Table 16 & Fig 10 deleted]

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 sel have a motivation to sel 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 al ows 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, although as it is a national scheme, the threat should be considered in al areas.

11.4.7 It is considered unlikely that foreign intel igence 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.

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

STEP 2: define impact levels for each service characteristic

11.4.8 Impact levels147 must be assigned to each relevant service characteristic for each transaction a service supports,148 and for the information that it stores. 11.4.9 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:

<li>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; [Table 17 and 17-2 deleted]

147 Defined by the HMG Impact Table, and reproduced in part at Annex D of this document. 148 As defined

in the description of the service provision environment at . Table 16149 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).

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.

[Table 18 deleted]

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.

[Table 19 deleted]

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 a client wil 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 overal business benefit.

11.4.17 Of particular consideration for this service is the requirement to conduct as much of the service electronical y 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 al owance 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 face-to-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 Al 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.

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.

A Glossary

A.1 General A.1.1 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. A.1.2 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 fol owing 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.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 wil 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 achieved by the e-Government service sending a client an email which is subsequently acknowledged by the client. 151 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. 152 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.

Accreditation

A.2.4 Accreditation is the formal assessment of an information system or a set of capabilities153 against the IA requirements of the information assets of that information system or capability set. A.2.5 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.

A.2.6 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 ful 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 wil 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. 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 wil become increasingly prevalent across government, as part of the shift towards improved interoperability and joint working and to al ow economies of scale to be realised. 154 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. 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 col ateral information are presented and verified, to establish a claim to a valid electronic identity. An electronic identity to support authentication by a client would typical y 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.

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 fit-for-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 wil 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 Chal enge-response is the mechanism that is typical y used to test whether the recipient of the chal enge 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 Further details about the CESG Assisted Products Scheme can be found at http://www.cesg.gov.uk. 156 Further details about the CSIA Claims Tested Mark scheme can be found at the Cabinet Office web-site, http://www.cabinetoffice.gov.uk/.

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 by which a client presents a credential and col ateral information, which is checked by or on behalf of an e-Government service to verify the electronic identity of the client and the entitlement of the client to receive the service or conduct the transaction requested. A.2.29 See also authentication and service authentication.

Common criteria

A.2.30 The Common Criteria157 (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 standard158, 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 wil 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 Further details of the Common Criteria and those products already evaluated can be found on the CESG web-site, http://www.cesg.gov.uk/. 158 The Common Criteria have been adopted as an International Standard (ISO IS 15408). 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 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 col ateral 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 One example of a credential issuer is a certification authority, which issues, manages and revokes digital certificates at the request of an RA. 160 One example of a credential revocation list is a certificate revocation list.

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 general y, a delegate would be authorised to perform some wel -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 al ow 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;

• 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 wil 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 typical y be comprised of some or al of the fol owing:

• 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 enrol ed 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 wil 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 enrol ed. Evidence requirements for enrolment wil depend on the details of the service to be used and must be set in conjunction with relying parties.

161 For example, by adding col ateral information to support that electronic identity.

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 actual y received the communication (if they did so).

Fast track

A.2.56 The Fast Track Assessment Service162 was developed to address the end-user 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 international y recognised certificates of evaluation to objective standards, repeatability and

independent oversight. However, it has been recognised that not al the features associated with formal evaluations are necessary to meet the assurance requirements of sponsors in al 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 formal y evaluated equivalent available, then the Fast Track process should be considered.

FIPS-140

A.2.59 The US Federal Information Processing Standard 140-2163 (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 Further details about the Fast Track Assessment process can be found at the CESG web-site, http://www.cesg.gov.uk. 163 Further details about FIPS PUB 140-2 can be found at the NIST web-site, http://www.nist.gov. cryptographic module that conforms to this standard in an overal system does not guarantee the security of the overal 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 back-office 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 al ow 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