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.