Guidance

Requirements for Secure Delivery of Online Public Services - HTML version

Published 15 December 2012

Executive Summary

HMG service providers should understand that providing their services online will attract significant risk.

This document is a response to the challenge of delivering online public services and sets out an approach to determining the components needed to securely deliver public services online to individuals and businesses.

A transactional viewpoint is presented as a way of describing and reasoning about information risk. This approach takes account of the overall business function and its distributed service model.

A six step process is introduced that provides a systematic process to help inform the risk management of online public services.

The process takes into account the expectations of the key stakeholders and the risks to the service on the basis of the transactions that take place.

This generates a security profile that considers service delivery requirements and takes account of business goals and the organisations risk appetite.

The output is a security case that demonstrates that these aspects have been considered in a transparent way.

1. Introduction and Scope

Key Principles

• Aimed at those providing online public services
• Provides a means to understand what is needed to securely deliver online public services
• Takes a transactional viewpoint of services based on distributed delivery models
• Encourages an informed risk management approach whilst taking into account stakeholder expectations and concerns
• Produces a security case that transparently demonstrates that stakeholder expectations and information risk have been appropriately considered

Introduction

Requirements for Secure Delivery of Online Public Services (RSDOPS) is a response to the challenge of delivering online public services and sets out an approach to deriving, discussing, and agreeing security requirements for systems delivering public services electronically.

This Good Practice Guide (GPG) describes the scope, context, and a process for deriving security requirements for public sector systems and services.

Two supporting, but separate Annex are also provided, these are:

• Annex A, Stakeholder Expectations - presents greater detail on stakeholder expectations and concerns (reference [a])
• Annex B, Security Components - provides detailed descriptions in the form of security components that are to be used to express the system security requirements (reference [b])

Scope

This document is applicable when determining security requirements for Information and Communication Technology (ICT) systems that deliver public sector services to individuals and businesses.

Purpose

The purpose of this document is to provide HMG departments and the wider public sector with a means to understand what is needed from a security perspective to support delivery of an online public service.

The aim is not to derive exact solutions and proposals; rather it is to set the target for security and to declare the extent of the preparedness of the Service Provider to invest in security. In addition this approach is intended to provide a common vehicle for expressing, discussing and negotiating security proposals with stakeholders that supports transparency in the decision making process.

The RSDOPS approach takes a transactional view of an online service and assumes there is a distributed service model rather than the departmentally focussed client server model that is used to deliver services today.

It is concerned with ensuring security of a transaction end to end and therefore takes account of not just technical security aspects but additionally the need to ensure security of the business processes and sometimes, complex stakeholder relationships that support the provision of an online service.

Architectural approaches to online public service provision are being developed and a number of distributed service models are starting to emerge.

For the purpose of this document a transaction is defined as a transfer or exchange of value between two or more parties. This transfer may take place outside of but is supported by an online system. Providers and consumers of online services need to consider the value of online transactions. This value is dependent on the nature of the service being provided and may be in the form of service related information, financial exchanges or other exchanges of value.

Current practice is to place greater emphasis on informed information risk management. RSDOPS is not intended to replace existing physical, business or technical risk assessment methods rather it should inform and complement their use. This approach is intended to allow appropriate risk managed choices to be made by the business.

This risk managed approach encourages Information Risk Owners to develop a better understanding of the wider information risk picture and make balanced judgements that are relevant to their specific business environment.

The intended outcome of the method sets out a target profile for security that the service should strive to achieve.

2. The Six Step Process

Key Principles

• Provides a means for online Service Providers to think about and analyse the security needs of their service
• Produces a security profile that sets out the security aims for the online service

Introduction

This document introduces a six step process that allows public Service Providers to better understand what is needed from a security perspective to support delivery of an online service.

The process is not intended to be a standalone assessment, rather it is intended to inform and consume other analysis and assessment conducted as part of a service delivery programme.

The process is intended to allow public Service Providers to think about secure delivery of their service in terms of:

• What is the online service intended to do and what security challenges will it bring?
• Who will be involved in delivery and consumption of the service and what expectations and concerns do they have?
• What risks will be posed as a result of putting this service online?
• What security profile should the service seek to achieve?

The six steps are not intended to enable the organisation to arrive at an immediate solution; rather they are to open a discussion on the security problem and to develop a shared understanding of its implications.

They will assist Information Risk Owners in reaching an understanding of the information risk implications of their business decisions and satisfy themselves that the security response is proportionate, and fairly represents the concerns and expectations of the business and the customers for the service. They are intended to provide a foundation for subsequent security engineering work. They will also offer a common language to communicate and negotiate security responses.

The resultant security profile is intended to be used as a statement of security intent that can be used in subsequent stages of a project to define technical and non-technical requirements.

A security case is developed that communicates the security profile in a way that demonstrates transparently that security has been considered fairly and proportionately to address business and stakeholder needs and expectations.

The output will demonstrate business understanding and appreciation of the information risk and planned responses and will not be a catalogue of required security measures. The output will include:

a. A full description of the intended service and the environment in which it will operate;

b. Identification of the parties with an interest in the transaction and consideration of their involvement, capabilities, motivations, and responsibilities in the context of the service;

c. Descriptions of the transactions to be safeguarded including key information assets;

d. A statement of the security-related expectations of parties involved in the transaction, (as illustrated in Step 3) set out in a way that can be referred to and tested against;

e. A statement of the information risks that are relevant to the transaction, including source of threat, information assets at risk, potential harm, likelihood of damage arising, and the extent to which such damage could be sustained in the normal course of business;

f. A target security profile stating levels of the different components of security and identifying any adjustments or refinements made;

g. A security case justifying the target security profile which may be subject to independent scrutiny and challenge.

The following diagram provides an overview of the six-step process and will be expanded upon throughout the remainder of this Chapter.

Figure 1. A diagram showing the six-step process. The six steps are: Step 1: Identify & Describe the Security Challenge. Step 2: Identify Active Participants. Step 3: Identify Stakeholders Expectations and Engagement. Step 4: Identify Information Risks. Step 5: Match the Information Risks to a Profile. Step 6: Develop and Validate the Security Case.

Step 1: Identify and Describe the Security Challenge

The objective of Step 1 is to provide the initial analysis that establishes the context for developing the security case.

The service description should consist of a narrative statement, largely descriptive to present the proposed service from a business perspective. Reference should be made to any existing business plans and proposals.

The following aspects should be identified and documented as part of this step:

• All assets identified and any agreed valuation (e.g. Business Impact Levels for Confidentiality, Integrity and Availability)
• All high-level business requirements for the service
• Any high-level information security requirements for the service (e.g. if facilities are provided for credit card payments then the service will need to take account of Payment Card Industry Data Security Standard (PCI DSS))
• Any need for access to 3rd party services (e.g. payment or identity assurance services) Any high-level use cases (and mis-use cases) or other business process models
• Any proposed security relevant transactions (e.g. financial transfers or changes to sensitive account information)
• All proposed delivery approaches (e.g. project management, development and implementation methods)
• Any other relevant material that will inform the subsequent security analysis

This step should clearly identify any security challenges for the project that have been identified at this early stage (e.g. balancing the need for pragmatic, appropriate and cost effective security with customer and business needs).

Finally, any security issues and concerns that have been identified in the business case for the proposed service should be restated and amplified if necessary.

Step 2: Identify Active Participants (Including Stakeholders, Customers and Users) and any other Interested Parties

The objective of Step 2 is to identify and list the participants and other interested parties in the principal transactions and any other parties that may be called upon to support, underwrite or provide governance for those transactions, implicitly or explicitly.

Consider the service being offered end-to-end. The model shown in Figure 2 below, shows how a number of stakeholders and participants could be involved in providing and using a service. The relationships between these stakeholders and participants should be considered.

Under this model, party A (typically the individual or commercial business) transacts with party B (typically a public sector organisation or their service supplier). The intended outcome is an exchange of value between the parties. Consideration should be given to any effects posed by service failure and which stakeholder has responsibility for recovery or compensation.

Figure 2. High-level transactional model of an end-to-end online service, including intermediaries and areas to consider.

The following questions could help to identify potential participants, stakeholders and interested parties:

• Who will use the system?
• Who will deliver the system?
• Who will support the system?
• Who will manage the system?
• Who will regulate the system?

The following model provides a view of those stakeholders and participants that may be considered for an online public service. This model is indicative only and Service Providers should ensure that they clearly understand who is involved in the consumption of and delivery of their own specific service.

Figure 3. Potential stakeholders involved in the provision of an online service. The stakeholders shown are: accountable authorities, service partners, service owners, service users and service suppliers.

These example groups are further defined below:

• Service Users: the general public, individual user, or business user that may use the service. It is important to note that users may be gaining access to the service from outside of the UK and therefore subject to local (non-UK) standards, regulations and legislation
• Service Owners: those charged with delivering business capabilities, improvements and efficiencies through the provision of an online public service
• Service Suppliers: product and service suppliers who are contracted to deliver or are otherwise involved in the delivery of service. It is important to note that suppliers to the service may be outside of the UK and therefore subject to local (non-UK) standards, regulations and legislation
• Service Partners: the providers of service components that are then used by others to provide their services. It is important to note that service partners may be located outside of the UK and therefore subject to local (non-UK) standards, regulations and legislation
• Accountable Authorities: those parties identified as being responsible for the overall governance of a service and owning the responsibility for resolving any disputes or issues within a defined aspect of the service. For example, if an aspect of the service fails who will be responsible for undertaking and funding remediation or for compensating stakeholders who have experienced a loss as a result of the failure

During this step it is important to clearly understand whether there are any international considerations that need to be taken into account.

Step 3: Identify Stakeholder Expectations and Engagement

The objective of Step 3 is to identify the expectations, level of engagement, and motivations with respect to the system aims for each significant party/stakeholder. Consideration should also be given to any international aspects identified.

Expectations are essentially security requirements viewed from the stakeholder perspective and expressed in a way that emphasises their interests, expertise, and points of view. This will form the security agreement between the parties.

The primary focus is on real world users and providers of an online service and their reasonable expectations. Some stakeholder expectations may be related to the design or the implementation of an online service and may not be partially or wholly addressed by security.

Stakeholder groups could express a large and varied number of expectations and concerns. The following list provides examples of subjects that should be considered. This list is indicative and therefore should not be considered as a reference list:

Technical

• System security
• Privacy
• Proof of transaction
• Accountability of actions
• Protection against fraud
• Integrity of information and services
• Confidentiality of information
• Availability of information & services
• Contingency
• Regulatory & legal compliance

Non-technical

• Privacy
• Liability
• Protection against fraud
• Usability/Ease of use
• Customer engagement
• Dispute resolution
• Cost effectiveness
• Regulatory & legal compliance
• Timeliness of delivery and service

An explanation of stakeholder expectations, concerns and risks can be found in RSDOPS Annex A (reference [a]). Additionally, examples of stakeholder expectations and concerns are provided. These examples are categorised by stakeholder group and can be used when considering more specific expectations of stakeholder groups.

Step 4: Identify Information Risks

Delivering a public service online will attract significant levels of risk for public Service Providers. Risks can include those of fraud, loss of public confidence and information loss.

This step is intended to recast the user expectation analysis conducted in Step 3 in the form of a set of information risks that will need to be managed in order to deliver stakeholder expectations and mitigate their concerns. Information risks are usually characterised by:

• The value and significance of the information asset under consideration to stakeholders
• The potential threat sources and actors including assessment of motivation and capability that would either benefit from or conduct an attack
• The opportunity to compromise an online public service that is presented to threat sources and actors as a result of vulnerabilities that exist in systems, services and processes
• The damage that may be experienced as a consequence of a risk being realised

This document set does not mandate or recommend a specific risk management method, approach or process to be followed in order to identify the risks to be managed. It is recognised that in order to gain as complete as possible view of the risks to an online service it is likely that a number of different risk assessment approaches will need to be considered. The exception to this is where HMG Departments and Agencies are mandated to use the HMG Security Policy Framework (SPF) (reference [c]).

For example, where an online public service will make use of personal information a Privacy Impact Assessment must be carried out as mandated by the Information Commissioner Office. This will need to be taken into account to manage any privacy related risks identified.

It is therefore recommended that when completing this step Service Providers take a view of risk that includes:

• Personnel Risks: These are the risks posed to the online service by the people who use and deliver the service Requirements for Secure Delivery of Online Public Services
• Procedural Risks: These are the risks posed to the online service due to vulnerabilities in business processes and procedures that support delivery of the service
• Physical Risks: These are the risks posed to the online service due to physical locations from which services are delivered from and from where access is provided
• Technical Risks: These are the risks posed to the online service due to technical design, implementation and management of technical systems and services that deliver the online service. HMG Departments and Agencies that are mandated to use the SPF (reference [c]) must follow the relevant policy to assess technical risks to their services.

Step 5: Match the Information Risks to a Profile

The purpose of this step is to express the security requirements for the service in the form of a profile for the components of security identified in this document set. These security components are summarised in Chapter 5 with a complete description provided in Annex B (reference [b]).

The aim is not to derive exact solutions and proposals. It is to set the target for security that declares the extent of the organisation’s preparedness to invest in security, and to provide a common vehicle for expressing, discussing and negotiating security proposals.

Additionally the aim is to derive a set of security requirements for the systems and services that fairly meets the expectations of the transacting parties. The proposed security response is supported by rationale that can be used to demonstrate that the security requirements demanded of systems are a reasoned and proportionate response to the threat as well as to the expectations of the stakeholders (including customers), and that trade-offs made are documented and explicitly accepted.

There is a degree of interdependence between Security Components. For example, it may be difficult to achieve the desired level of accountability without suitably matched registration and authentication mechanisms.

This step will require the application of significant security and Information Assurance skills. The description of the levels of the individual components of security contains some guidance, but there is no standardised approach that can map the risk profile and stakeholder expectations on to a cohesive set of security requirements. Businesses have diverse budgets, capabilities, motivations, and risk tolerances and should make, and be prepared to justify, their own information risk decisions.

Irrespective of what risk assessment method is used, it is reasonable to assume that there is a direct relationship between the risks that exist to a service or a transaction and what profile for security and assurance should be aspired to. The following table demonstrates this concept and provides a view of how levels of risk identified in Step 4 could be mapped to RSDOPS levels.

Table 1 provides an indicative mapping of risk levels to security components with levels 0-3. This mapping is provided simply to demonstrate the thinking required, that as levels of risk to a service or transaction increase then what needs to be done from a security and assurance perspective increases in proportion.

	Level 0	Level 1	Level 2	Level 3
High risk				x
Medium risk			x
Low risk	x	x

Table 1 - Mapping Risk Levels to RSDOPS Levels for Security components with levels 0-3

The risk assessment methodology chosen to support this step should ensure that threat, vulnerability and service or transaction value are considered in terms of a public service being provided online using the Internet.

The mapping of risk levels to RSDOPS levels is not absolute. When determining this mapping it is important to take into account the risk the security component is intended to treat along with the risk appetite, risk tolerance and business objectives of the business or the programme involved.

It is also important to determine thresholds for risk levels and how they relate to the RSDOPS levels for security components. These thresholds are dependent on the methodology being used, e.g. for example some methods may generate high risks where Level 3 for a security component is appropriate, whereas other methods may generate a medium level risk where Level 3 for a security component is equally as appropriate.

The objective is to identify a level for a security component that demonstrates that the risks identified in Step 4 for a business, service or a transaction are being managed by a security profile that is proportionate and appropriate for the business in the context of delivering online services.

With this understanding, of how levels of risk can be used to inform the choices made with respect to RSDOPS security component levels, then a security profile for a service or an individual transaction can be determined as shown in the example in Table 2 below. Annex B (reference [b]) provides greater detail of each security component, including examples, by individual level.

Service/Transaction Description	RSDOPS Components	Example: Customer applies for payment to their online bank account
Personal Registration	End User Components	3
Corporate Registration	End User Components	N/A
Authentication	End User Components	3
Authorisation	End User Components	1
Privacy	End User Components	3
Information Access	Server Components	2
Information Availability	Server Components	2
Communications Security	Network Components	2
Network Authentication	Network Components	1
Network Protection	Network Components	2
Situational Awareness	Network Components	2
Internal Accountability	Business Logic Components	2
External Accountability	Business Logic Components	2
Organisational Assurance	Assurance Components	2
Technical Assurance	Assurance Components	2

Table 2 - Example security profile for an example online transaction

Step 6: Develop and Validate the Security Case

The final step is to build a complete security case that captures the decisions and proposals from the previous steps. Also included is the rationale that shows how the proposed response to security will mitigate the risks identified and reconcile the fair expectations of the various parties and stakeholders.

This is not the final baseline against which accreditation and certification will take place, rather it sets an aspiration target for security. Information risk should remain a live issue under continuous review throughout system procurement and operation.

The following list provides potential subjects that could be included in the security case but this should not be considered a template. The content and complexity of the security case needs to be commensurate with the needs of the business and should be developed accordingly with the agreement of IA stakeholders from within the business (e.g. the SIRO and the Accreditor).

• Overview of the service or transaction
• Description of any security challenges identified
• Summary of stakeholders, their concerns and expectations
• Summary of risk assessment activities and key findings
• Security profile recommended and supporting rationale
• Analysis of consequences of failure of specific security component

The security case can then be used to communicate to the business and stakeholders alike what security is needed to successfully deliver an online service. This can be published if appropriate to provide transparency and assurance for all stakeholders with regard to security of the online service.

3. Threats, Vulnerabilities and Impacts

Key Principles

• The threat to a HMG Online Service should be considered as anyone or any organisation that has the capability and motivation to attack a HMG online service
• When developing solutions that deliver online services care should be taken to ensure that as far as possible all vulnerabilities have been considered
• Attacks against online services can impact the service in a variety of ways. It is important to understand the impacts that would result should the service be compromised

The Threats

When considering the threats to a HMG Online Services, analysts should be aware that anyone or any organisation that has the capability and motivation to attack the service are highly likely to do so. Threats will seek to make use of lost, stolen, intercepted or hijacked identity information to gain unauthorised access to systems, information and services.

Any analysis carried out to determine the requirements for HMG Online Services should ensure that it has taken into account all potential sources of threat, e.g. from members of the public who may accidentally or deliberately seek to compromise a service through to serious and organised criminal groups who may seek to compromise the service for large scale financial gain.

Threat sources and threat actors should be considered in the context of the online service under consideration.

The Vulnerabilities

When developing solutions that deliver online services care should be taken to ensure that as far as possible all vulnerabilities have been considered. The following provides a high level view of the types of vulnerabilities that should be taken into account. This list is not exhaustive and the requirements for HMG Online Services should be continually reassessed (this may form part of a wider end-to-end service risk assessment) to ensure that it is appropriately treating existing or emerging vulnerabilities.

a. People - Users and providers of an online service are vulnerable to social engineering attacks (e.g. phishing) and are vulnerable through lack of training and awareness.

b. Physical - The physical storage of and handling of sensitive information used to support a service are vulnerable to a multitude of attacks including loss and theft. Users of an online service may, through lack of awareness, leave their personal information and, or, authentication credentials vulnerable to loss or theft. The providers of online services, through weak physical protection of ICT systems and sensitive information, leave themselves vulnerable.

c. Procedures - Poor procedures for the use and provision of online services will leave HMG and the user vulnerable to attacks on their information.

d. Technical - HMG and the user are vulnerable to technical attacks on the systems used to provide online services. Vulnerabilities exist in technical systems due to poor development, design and implementation of systems and software and through failures to keep systems and applications patched and up to date. Systems should be tested for vulnerabilities prior to ‘go live’ and on a regular basis thereafter to ensure that security measures continue to appropriately treat existing and emerging vulnerabilities. For example:

i. A poorly protected or un-patched endpoint will leave user systems vulnerable to keystroke loggers and other malicious attacks that could adversely affect systems and applications e.g. an un-patched browser could be vulnerable to man in the browser attacks;

ii. Poor or weak communication security will leave communication between the user, the identity provider and the Service Provider vulnerable to interception and man in the middle attacks;

iii. The use of weak authentication credentials will leave the user and the HMG Online System vulnerable to guessing, brute force attacks;

iv. Weak authentication of services to the user (e.g. wrong website, misdirected or spoofed website);

v. Fake or broken web certificates, Domain Name System (DNS) attacks etc.

Impacts

The impact of a compromise of a HMG Online Service on HMG and the user should be clearly understood. Public Service Providers who seek to deliver their services online should use an appropriate method to achieve this. For those mandated to do so, the relevant HMG Security Policy Framework (SPF) (reference [c]) Mandatory Requirements should be applied for assessing business impacts. For those not mandated to use the SPF, standards or guidance for assessing business impacts should be applied as specified by their business.

The following list provides a non-exhaustive indication of the types of significant impacts that should be considered if HMG online service is compromised:

a. Loss of service availability: A compromise of a HMG online service could lead to a loss of access to services for an individual or many users of the system.

b. Loss of information integrity: An attacker may seek to maliciously change information that is stored or consumed by a HMG online service.

c. Individual loss of personal data: A compromise of a HMG Online Service could lead to a loss or compromise of an individual’s personal information.

d. Individual financial loss: A compromise of a HMG Online Service could lead to a compromise of an individual’s financial information or their financial well being.

e. Significant financial loss: This can occur if a successful attack against one transaction no matter how complex or expensive to set up in itself, can be automated or repeated many times.

f. Significant loss of personal data: This can occur if an individual attack at compromising the personal data of an individual can be repeated many times, or if poor design or implementation of systems and architectures leave them vulnerable to online attacks.

g. Reputation: Any successful attack even if relatively insignificant in itself could result in a loss of customer confidence and the overall reputation of the service and all involved in its delivery.

4. The Risks

Key Principles

• Providing HMG Online Services will attract significant risk for HMG Service Providers
• Service Providers should consider the risk to HMG Online Services carefully taking into account the threats to, the vulnerabilities of and the value of the transaction or service in terms of the impact a compromise would have on HMG, Service Providers and the user

Assessing the Risk

When considering delivering a public service, public Service Providers should determine the risks associated with delivery of an online service. Risks should be considered end-to-end to take account of all systems, services, processes and transactions involved in the provision of the online service. It is intended that this assessment of risk be used to support Step 4 of the RSDOPS method as defined in Chapter 2.

This understanding of risk should then be used to decide what measures need to be taken to maintain security of the online service, accountability of actions and inform the level of assurance required for all aspects of the service end-to-end.

For those HMG Service Providers who are mandated to do so, the relevant HMG Security Policy Framework (SPF) (reference [c]) Mandatory Requirements must be applied. For those not mandated to use the SPF, risk assessment standards or guidance should be applied as specified by their business to develop an understanding of the risks associated with an online public service.

5. Summary of RSDOPS Process

Key Principle

• Provides a diagrammatic summary of the six step RSDOPS process to assist analysts

Process Summary

The following diagram is intended to provide a summary of the RSDOPS six step process and provide additional information to assist analysts. Provided are some recommended sources of input needed to complete each step and a view of the objectives of each step to assist the analyst in understanding what the output of each step should be.

Figure 4. A summary of the RSDOPS process.

6. Summary Security Components

Key Principles

• Security components are packages of security requirements that focus on a specific aspect of security
• Security component requirements and outcomes have been assigned levels 0-3
• The levels have no absolute significance in relation to components
• This summary presents component intent and desired outcome, not content

The Security Profile, which is the vehicle used to scope and agree the security response, is structured around a set of Security Components. There is some overlap between the components, and there may be additional requirements not covered by the components defined. The components can then be used for communication amongst stakeholders of the intentions of the service owner in regard of service security and negotiating the detailed requirements.

The degree of attention to be given to each component of security is captured as a set of levels, where Level 0 generally represents ‘no specific requirements’ and the higher levels represent increasingly demanding requirements. Level 0 should generally be read, as ‘no specific requirements are expressed in this guidance‘, or ’not relevant to this application’, it should not be read as ‘no attention is required to be given to this component’.

The security requirements and outcomes are broken down into levels with minimal reference to solutions. Reference to potential solutions is used to illustrate requirements but these need not constrain actual solutions unless necessary for other reasons such as interoperability.

The profile should select levels that are appropriate for the service and not necessarily favour the same numeric level for each component. The aim should be to build a comprehensive security case whilst avoiding over investment or excessive caution that might constrain the delivered solutions.

In assigning a level for a particular security component to a service, the Service Provider should consider the direct and indirect consequences of a failure in that particular component and interpret such potential failures as:

• Minor
• Significant
• Substantial

in the context of that particular scenario. For example, a significant financial loss to an individual may be of little consequence to a large company.

Service Providers should consider the assigned levels in terms of expectations of the various concerned parties, risks to the service as a whole, and cost of implementation, practicality, and overall business benefit.

A high-level summary of the security components and their levels can be found in the tables that follow.

Some boxes in the tables below have been left ‘intentionally blank’ as currently there are no pan-Government requirements. Some organisations may wish to undertake work equivalent to these particular levels to fulfil their own specific internal requirements.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: End User - Personal Registration	Personal Registration is the act of establishing the identity of an individual as a condition for issuing credentials that can be used subsequently to reaffirm that identity.	Not required: The real identity of the individual is not relevant to the service. As a courtesy, users may be offered facilities to save preferences and other material but no personal information is solicited.	Asserted: The user asserts an identity. This identity, which need not describe or imply a real identity, is not tested. Personal information solicited is not shared externally.	Tested: The user asserts a real identity and provides information to enable the claimed identity to be tested. The evidence presented needs to support the real identity and can be tested independently of the immediate presence of the subject. Evidence presented might be offered in support of civil proceedings.	Verified: The user claims a real identity and the claimed identity is subject to rigorous testing to independently verify the individual’s identity and presence. The independent evidence of identity might be cited in support of criminal proceedings.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: End User - Corporate Registration	Corporate registration is the act of establishing the legal identity of a corporate body, the identity of the user registering the business identity and evidence that the user is an authorised representative of the organisation.	Not required: The legal identity of the organisation is not relevant to the service. As a courtesy, users may be offered persistent storage to save preferences but no commercially sensitive information is solicited.	Asserted: The user asserts an identity. This identity, which need not describe or imply a real corporate identity, is not tested. Any commercially sensitive information solicited is not shared externally. The user is assumed to be entitled to act on behalf of the corporate body.	Tested: The user claims a corporate identity and provides information to enable the claimed identity to be tested. The evidence presented needs to be sufficient to confirm the legal identity of the business, the user’s real identity and the user’s claim to be a representative of the organisation. The requirement for traceable linkage to identity is not strong enough to warrant rigorous independent human review and testing of the evidence but it might be cited in support of civil proceedings.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: End User - Authentication	Authentication is the act of ensuring or checking that a user of a service or system is the owner of the identity they claim to be. This is achieved through the provision of evidence usually in the form of credentials.	Not required: No additional authentication actions are required to access the service. Implicit Authority by virtue of the access path may be inferred.	Minimal: The user is required to demonstrate possession of an authentication credential that is issued or recognised by the service. An authentication secret may be directly quoted during authentication.	Robust: The user is required to demonstrate possession of the authentication credential that is issued or recognised by the service. Robust measures are required to protect the credential during use. At this level, there is a presumption that the authorised user is generally cooperative and well intentioned and the primary threat is external. Evidence of user actions may be offered in support of civil proceedings.	Accountable: The user is required to demonstrate possession and ownership of the authentication credential. The measures should be such that uncooperative or malicious authorised users can be held to account for their activities. Evidence of user actions and presumed identity may be offered in support of criminal actions against the authorised identity.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: End User - Authorisation	Authorisation is the act of confirming that a registered user is entitled to access a service prior to permitting that access.	Implicit: There is no additional requirement to confirm that a user is entitled in order to grant the user authority to access the service. Additional courtesy registration may be offered and additional credentials issued.	Tested: The user claims entitlement to access the service and provides evidence to enable their claim to be tested. Testing is within the ‘balance of probabilities’. Additional service specific registration and credentials may be needed.	This box is intentionally blank.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: End User - Privacy	Privacy is a requirement for socially responsible handling of personal information by the system. Citizens or businesses have a reasonable expectation that measures are in place to ensure that information collected by a service is the minimum necessary to fulfil its purpose, is used only for the purposes for which it was collected, and is disposed of in a secure manner when no longer required. For further information see the Data Protection Act 1998 (reference [d]).	No Statement: Private or privacy relevant information is not collected by the system.	Implicit: No stated requirement beyond the implicit requirement for protection of private information. At this level, only information directly solicited from the user will be processed, and will be visible to them.	Explicit: The system, of necessity, collects and collates personal or sensitive information that could be directly linked to an individual or corporate body. Misuse of such information could be perceived as, or may actually be, detrimental to the well being of users.	Protected: Bulk personal data and/or sensitive information is, of necessity, collected and collated. Misuse of the collected information would present a danger to the information subjects. Bulk compromise would present a threat to the safety of the wider community.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Server Information - Access	The means by which assurance is gained that information can only be accessed by those who are authorised while it is received, stored, processed or otherwise disposed of within the service environment.	Limited: In general, none of the information handled is sensitive and is not subject to any formal access control policy.	Self Assessed Commercial: The information stored has some access limitations but no formal protective markings and the impact of disclosure is minimal.	Assessed Commercial: The information stored has access control requirements but generally attracts no protective marking, or a subset is no higher than PROTECT. Impact of disclosure is largely reputational with limited potential for individual harm. Bulk data loss or damage could have significant implications.	Assessed Government: The information stored has significant access control requirements that generally equate to PROTECT, Personally Identifiable Information, or RESTRICTED for subsets, aggregated or bulk data. Impact of unwarranted disclosure or damage is significant with scope for individual harm. Bulk or aggregated data compromise would have significant reputational and business impact.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Server Information - Availability	The means by which assurance is obtained that access to information and resources cannot be withheld in an unauthorised manner. This document does not address reliability in general; its specific focus is denial of access to resources as a result of malicious activity and the susceptibility of systems and services to such threats.	Limited: No explicit requirements for availability over and above reasonable expectations of continuing service delivery.	Commercial: Unavailability of service or information is an inconvenience to users but unlikely to cause harm. Extended down time risks reputational damage to the Service Provider.	Critical:Unavailability of the service or associated information might cause harm to the individual user. Extended down time for the service as a whole risks serious reputational damage to the Service Provider and might lead to action for compensation for harm caused.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Network - Communications Security	Means by which assurance is gained that observation or interference with information cannot occur in transit to, from, or between components of services. Typically relates to the requirement for encryption of communications links.	No specific measures: Limited requirements for communications security, typically because the information is non-sensitive or network provider measures are adequate.	Limited: Threat analysis leads to a requirement for explicit protective measures and demonstration that the threat has been addressed.	Significant: Threat analysis suggests a need for strong measures to counter the threats to the system. The threat actor capability is however not sufficiently great to warrant the use of public sector specific capabilities and assurance.	Substantial: Threat analysis suggests a need for strong measures to counter well-resourced and competent adversaries. The response may require public sector specific capabilities and assurance.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Network - Network Authentication	The means by which assurance is obtained as to the authenticity of machines involved in inter-domain connections and data exchange.	Limited: Low threat or limited opportunity for attack. In general, reliance on physical connectivity or network identifiers is sufficient.	Active: Moderate threat and opportunity for attack for which standard commodity mitigating measures, when correctly configured, are a reasonable response.	This box is intentionally blank.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Network - Network protection	The means to assure that the service is protected from an adversary with network visibility and access.	Limited: Service assessed as unlikely to be of heightened interest to attackers. No special measures beyond requirement for duty of care in the application of commonly accepted custom and practice.	Baseline: Threat of network attack assessed as low for public sector systems but still likely to attract interest as a public sector system per se.	Enhanced: An independent assessment made of the threat and vulnerabilities indicates potential heightened interest to attack community.	Significant: An independent assessment by informed public sector assessors is carried out. Privileged sources used to inform the threat assessment which indicate significant interest to well resourced attackers.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Network - Situational awareness	The practice of obtaining and maintaining awareness of the vulnerabilities of a service, incidence of attacks, and responding in a timely, coordinated and prioritised way to maintain service availability.	Limited: Service assessed as unlikely to be of heightened interest to attackers. No special measures beyond requirement for duty of care in the application of commonly accepted custom and practice.	Aware: Service assessed of being of interest to a class of adversaries but no specific threat identified.	Active awareness and response: Service assessed as being of specific interest to identified capable adversaries.	Informed awareness and coordinated response: Service assessed as being of interest to specific highly capable adversaries with evidence of ongoing activity against the service or its peers.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Business Logic - Internal accountability	Measures taken to establish the traceability and accountability of significant transaction steps and information assets managed.	Limited: There are no specific internal accountability requirements other than those required to meet commercial and legal requirements for financial accounting and asset management.	Auditable: A basic level of accountability for transactions is required but legal case against infringements would need additional evidence.	Accountable: There is a strong requirement to be able to hold those involved in a transaction accountable, possibly with legal action to seek redress.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Business Logic - External accountability	Measures taken to establish the accountable authority for, and provenance of, transfers of data to and from external sources.	Limited: There are no specific external accountability requirements; information received or transmitted will be taken at face value without special mechanisms to support traceability.	Auditable: Basic assurance as to the identity of the originator and receiver (if relevant) of the transaction is supported. Use of commercial and widely deployed measures is appropriate. Evidence of receipt of a transaction is provided by the service to the client.	Accountable: Evidence of receipt of a transaction is provided by the service to the client. When a transaction spans multiple management domains, there is a strong defensible and persistent binding between the transaction and the originator and recipient.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Assurance - Organisational assurance	Covers the review of the organisations involved in the delivery of a service to ensure that the required management, procedural, personnel and physical arrangements are in place to secure the service.	This box is intentionally blank.	Independent assessment: Independent assurance is required that those involved in the provision of the service and the locations from which they provide the service have appropriate (commercial best practice) organisational, personnel and physical controls in place.	Government approved assessment: Independent assurance is required that those involved in the provision of the service and the locations from which they provide the service have appropriate (Government best practice, see IA Maturity Model (IAMM)) organisational, personnel and physical controls in place.	This box is intentionally blank.

	Notes	Level 0	Level 1	Level 2	Level 3
Security Component: Assurance - Technical assurance	Covers the review of the service to ensure that it is designed, implemented, configured, maintained and operated in accordance with the security requirements and can be trusted to uphold the interests of the transacting parties.	This box is intentionally blank.	Independent assessment: Assurance obtained through independent assessment.	Government approved assessment: As Level 1 but assurance is obtained using a CESG approved method by a CESG approved supplier (e.g. CPA and CESG Tailored Assurance Service, CTAS).	This box is intentionally blank.

References

[a] CESG Good Practice Guide No. 43, Requirements for the Secure Delivery of Online Public Services - Annex A, Stakeholder Expectations, Issue 1.1, December 2012, Available from the CESG IA Policy Portfolio.

[b] CESG Good Practice Guide No. 43 Requirements for the Secure Delivery of Online Public Services - Annex B, Security Components, Issue 1.1, December 2012, Available from the CESG IA Policy Portfolio.

[c] HMG Security Policy Framework Tiers 1-3, (Not Protectively Marked) are available at www.cabinetoffice.gov.uk

[d] Data Protection Act, 1998, available at www.ico.gov.uk/for_organisations/data_protection.aspx

Annex A

This Annex supports CESG Good Practice Guide No. 43 (GPG 43), Requirements for Secure Delivery of Online Public Services (reference [a]).

1. Introduction

Key Principles

• Introduces a framework for analysis of stakeholder expectations, concerns and associated risks
• Supports the development of a rationale for system and security requirement choices

Introduction

This document provides supplementary guidance in the area of stakeholder expectations in support of GPG 43 (reference [a]).

A framework is introduced that allows the stakeholders identified during a RSDOPS assessment to be assigned to one of the defined stakeholder viewpoints group.

Stakeholder Expectations

The tables in Chapter 2 provide an example framework for consideration of stakeholder expectations, concerns and associated risks. These tables are designed to help demonstrate that the reasonable expectations of all those involved in a public service delivery have been appropriately captured. These can then be assessed and appropriately addressed. It is essential that user and business expectations, as well as Government requirements, are taken into account. The expectations are described by the columns:

• Expectation - Describes an expectation for security related behaviours viewed from the stakeholder perspective. There is an assumption of reasonableness, but not that the viewpoint is of someone who understands information security. This is based on the assumption that these are reasonable expectations, and the systems and services must meet them or explain the shortfalls and how they might be addressed elsewhere. For example, it is a reasonable expectation that the systems will safeguard user information but it may not be a reasonable expectation that there will never be any system compromises. However, it is a reasonable expectation that, in the event of compromise, recovery action is possible, and that users will be recompensed for any harm experienced
• Concern - Is the underlying belief, worry or unease that informs the expectation. Concerns may be valid, unjustified, or overstated, but they remain concerns that should be considered. Concerns may be based on perceptions of risk and possible harm or they may reflect wider concerns about privacy and other softer issues
• Risks - Identifies relevant information risks that could lead to stakeholder concerns being realised. These risks can then be used to inform and be taken into account in Step 4 where there is a need to conduct further risk assessment activity.

Stakeholder Expectation Descriptions

Stakeholder expectations are not intended to be prescriptive and should be referred to when developing the rationale for system and security requirement choices. For example, these stakeholder expectations should be referred to when defining the rationale for security profile choices when developing the security case in Step 6.

Whilst not intended to be exhaustive, an initial analysis would respond to the expectations explaining how they are either:

a. Addressed, that is the expectation is fair and reasonable, and that the system has addressed this concern in its design.

b. Partially addressed, that is the expectation is fair and reasonable but cannot be fully addressed within the constraints of the proposed service. The security case should make it clear where the shortfalls are, and whether the risk is accepted or dealt with external to the system.

c. Not addressed, that is the concern is reasonable but cannot be addressed directly by the system. The security case should show how such concerns are out of scope, addressed outside of the system, or make an explicit statement that such concerns are not addressed.

d. Discounted, that is the concern is not relevant or reasonable in the context of the proposed system or service, or that the associated risks are small enough to be accepted.

Viewpoint and Consideration Groups

The following stakeholder viewpoint and consideration groups are covered in Chapter 2:

a. User;

b. Service Owner;

c. Service Supplier;

d. Service Partner;

e. Accountable Authority;

f. International Considerations.

2. Stakeholder Expectations

Key Principle

• Provides example stakeholder groups and illustrates potential stakeholder expectations, concerns and associated risks

Introduction

The following sections are intended to provide examples of each stakeholder group viewpoint or consideration. A short explanation of the group is provided along with a table providing examples of various expectations, concerns and risks.

The stakeholder groups and their expectations documented in this Chapter should not be considered as fully exhaustive and businesses should consider their own stakeholder groups appropriately.

User Viewpoint

The user (general public, individual user, or business user) mainly expresses concerns over the fact that their interests and information will not be safeguarded, failures and shortcomings will not be underwritten and, in the event of dispute or malfunction, there will be a presumption of guilt on the part of the user, as well as inadequate or unfair processes for redress.

Expectation	Concern	Risks
Privacy - Online public services will not unnecessarily compromise the privacy of actual or potential users, or the general public, in respect of their personal, financial, or business information.	The public sector will collect information for which it has no business need, and no rights of access. The public sector will accumulate information that leaves the user open to identity theft, fraud, invasion of privacy, or other personal distress. Personal information will be shared without explicit permission and will be collated with other sources of information in order to draw inferences about the subject that may be counter to their interests. The public sector will not look after personal information responsibly or will use it for purposes that were not agreed to.	Deliberate or accidental breaches of confidentiality by third parties will compromise the customer’s privacy. Function creep and gradual accumulation of stored personal information presents new (and unmediated) opportunities for invasion of privacy. Analysis of large collected datasets may expose inferences about subjects that violate their reasonable expectations of privacy. Electronically delivered services will not be taken up by the public owing to their concerns about privacy.
Authenticity - Users can be assured that they are interacting with a genuine public service.	Users could be deceived by a plausible false presentation of an online public service and thereby reveal Personal Private Information (PPI) to a potential fraudster (‘Phishing’).	Personal and private information will be lost to a fraudulent operator with ensuing personal and financial consequences. The integrity and reputation of public sector services will be undermined.
Confidentiality - sensitive information will only be accessible to those with a legitimate need, and used for a legitimate purpose.	Sensitive information held by the public sector may be compromised through exposure (deliberate or otherwise) to those who have no need to see it, or to those who may be intent on causing harm. Online public services present opportunities for ‘ID Theft’.	Adversaries may exploit vulnerabilities to gain access to information without authority. Information may be accidentally or deliberately exposed to potential adversaries.
Integrity - stored personal information will not be corrupted or changed incorrectly. It will be protected in a manner that reflects its intrinsic value to the individual.	Information held by the public sector could become corrupted or destroyed with undesirable or serious consequences. Information held by the public sector could become out of date or be inaccurate.	Adversaries may deliberately alter sensitive personal information and thereby disadvantage or damage the information subject. Information may be accidentally corrupted leading to damage or disadvantage to the information subject. Users may be unjustifiably accused of damaging or fraudulent activities. The circumstances of a user may change, leading to information held becoming inaccurate.
Availability - critical services will always be available when they are needed.	Urgent service needs will not be met. Alternative service delivery opportunities will be withdrawn in favour of e-delivery without adequate accessibility, reliability and coverage. Time critical response demands, which may incur a penalty, cannot be supported by the e-systems.	Users may be disadvantaged or damaged as a consequence of their inability to access public sector services when needed owing to intentional acts by adversaries or accidental misuse of security functions by users.
Transparency - personal information is held by/supplied to the public sector for its agreed purpose only.	Once the public sector is in possession of information, it will use it for purposes that were not declared when the information was supplied or as agreed subsequently.	Users will be harmed or will perceive privacy violations through use of their information for a purpose they were not aware of, had not agreed to, or did not understand.
Identity - systems will confirm the identity of those with access to information before enacting a transaction. The strength of the identity measures will be appropriate to the value of the information, and the need for confirming true identity (as opposed to authority) when completing the transaction. Identity compromise by the public service will be admitted and repair properly supported.	Systems will have weak controls which will lay individuals open to identity fraud and malpractice. Identity controls will be applied insensitively; full identity will always have to be proved where it is not strictly necessary. Interactions will be unnecessarily intrusive leading to privacy concerns. Public authorities will offer poor support for identity repair following compromise and leave responsibility with the customer.	Adversaries will be able to impersonate legitimate users and cause damage through abusing their access rights. User privacy will be compromised through demanding full identity when not necessary for the business in hand. Users will continue to suffer the consequences of identity compromise and will not be supported in identity repair and will not be compensated.
Reliance - it is safe to act upon the displayed service outcomes.	The online public sector services may not display the true situation, e.g. monies showing as transferred may not be accessible, or information may be misleading leading to later penalty.	Users will be harmed as a consequence of taking action on incorrect or inconsistent system information or instructions.
Payment Safety - monetary transfers are correctly carried out between the correct parties and do not lay individual financial details open to exploitation.	Bank account details will be misused or not properly controlled leading to financial exposure. Erroneous transactions cannot be challenged or reversed.	Adversaries can exploit vulnerabilities in the systems to commit fraud. Fear over financial exposure and fraud will deter users from using the systems.
Accountability and Fairness - False accusations of fraud or unwarranted impositions of penalties will not be made and cannot be upheld. Any dispute will be easily and fairly resolved.	The liability model will not be fair to the individual, there will be a presumption of guilt in the event of a dispute and no evidence against which a case can be made and redress sought.	Fear over lack of transparency and fairness will deter users from using the systems. Users are unable to query transactions and resolve inconsistencies to their and the system owners’ satisfaction.
Inclusivity - The advent of electronic access to public sector services will not disadvantage those with particular personal circumstances or disabilities.	Public sector service access will be more difficult and discriminatory and alternate access routes will be withdrawn.	Users may be denied service through inability or incapability to access the electronic systems. Adversaries may harm users through exploitation of weaknesses in the fall back arrangements for the electronic systems.
Non Discoverability - search or query access to systems and data will not be accessible to an unauthorised individual or used for unauthorised purposes.	Unauthorised parties, or subverted authorised parties will gain search or unconstrained query access to large or complete datasets and will thereby be able to discover or draw inferences about vulnerable subjects.	Query access to large datasets will be misused in order to locate individuals, or identify at risk individuals (e.g. witness protection) at an impact level in excess of the individual records.

Service Owner Viewpoint

The service owner viewpoint reflects the concerns of those charged with delivering business improvements and efficiencies through an increased use of ICT, and may outline any major concerns around the security measures as to whether they are deemed to be intrusive or unaffordable. Security failures in large business systems may lead to departmental sanction and closure.

Expectation	Concern	Risks
Compliance - systems are able to comply with an acceptable interpretation of relevant legislation and policies in regard of protecting official and personal information and managing information risk.	Compliance responsibilities are unclear and not closely related to the practical value and impact of security controls. Meeting the compliance requirements is unfeasible or expensive and time consuming, and inhibits business delivery. Individuals may be held accountable for circumstances outside their control.	Information management controls will be held to be deficient through lack of clarity on roles, requirements, and responsibilities. Lack of clarity of roles and accountabilities will lead to an overly cautious interpretation of compliance requirements resulting in higher costs and/or unnecessary service limitations.
Available Measures - Suitable security measures are available on the market and widely accepted as reasonable, proportionate, and meeting the national and user interests.	The available policies, products, and knowledge, do not allow solutions to be built. Impractical and inappropriate solutions will be adopted to achieve administrative compliance.	Information risks will be improperly managed through an inability to carry out the necessary measures. Legalistic focus on compliance will result in the acquisition of inappropriate or ineffective measures.
Affordability - Security processes and measures will not place an unsustainable cost burden on departments.	Affordable products and services do not exist, and development costs of new capability are high. Assurance requirements push costs up. A sustainable Commercial Off The Shelf (COTS) market will not exist.	Information risks will be improperly managed through an inability to afford the necessary measures or through the acquisition of inappropriate measures.
Business Impact - Security measures do not impact upon the business to the extent that the desired business outcome is unachievable or unaffordable.	Policies and compliance regimes lead to unacceptable business impact. Regulatory and policy restrictions preclude the use of apparently suitable solutions.	Responding to IA regimes and processes will impact on the viability of the service offering. The proposed service is beyond the acceptable bounds of information risk.
Risk Awareness - Information risk awareness will be high and it will be possible to understand the efficacy of the risk mitigation measures and their value to the business.	There is a lot of material about managing information risk which concentrates on deriving the measures and testing their quality, but little on determining actual business harm and to what extent the measures affect it.	Untestable risk assumptions will result in the deployment of uneconomic or restrictive measures.
Assurance - the value, utility, and quality of the installed security measures can be confirmed as suitable and VFM is clear.	It is hard for public sector security authorities to get a meaningful independent confirmation of the quality, effectiveness, and appropriateness of selected measures.	Poor appreciation of security will lead to inappropriate application of assurance schemes and processes and will limit the opportunities for success.
Supply - Business services will most likely be delivered through third parties who can, and are able to, accept their part of the responsibility for information risk.	Security capability, processes and practices do not align with contracting practice for service provision. Service providers cannot accept risk transfer, or will price unrealistically.	Commercial and contractual drivers will dominate and information risks will not be properly managed.

Service Supplier Viewpoint

The Supplier viewpoint represents the interest and concerns of product and service suppliers who are contracted to deliver or who are otherwise involved in the delivery of electronic public services.

Expectation	Concern	Risks
Clarity - requirements and responsibilities for the security of supplied systems and services are clear enough, and stable enough to allow the commercial risk to be scoped and implemented.	The public sector IA policy, practices, processes and capabilities are inadequately described, opaque, and subject to change. Commercial risks in responding are unacceptably high leading to uncompetitive pricing or financial and business risk.	Misaligned expectations of service owners and suppliers with regard to security will lead to contractual difficulties.
Achievability - affordable equipment and assurance services will be available to meet contractual requirements.	It will not be possible to respond sensibly to procurements because the needs are unclear or excessive and the necessary products and services are unavailable.	Supply opportunities will be lost owing to an inability to supply against (possibly unrealistic) requirements.
Positive Risk Culture - The prevailing culture will be one of partnership in dealing with information risk, and not simply risk and cost transfer. Commercial risk associated with partnering with the customer on information risk can be priced.	The department will seek to pass information risk to the supplier when it is not appropriate to do so.	Information risk management will suffer from a lack of ownership.

Service Partner Viewpoint

The provision of electronic services in the future will likely see the widespread adoption of a Shared Service model to achieve the planned efficiencies. Under the Shared Service model, service components will be developed by a lead department and shared within a common infrastructure. The end user will see a composite and comprehensive service offering that draws on service components sourced from a number of different departments and suppliers.

Public sector organisations offering service components to be incorporated into composite end user services will reasonably expect the organisation incorporating the service component into their service offerings to behave responsibly.

Expectation	Concern	Risks
Correct Usage - The service component aggregator will access the service component within its specified parameters at all times.	The service component aggregator will not adhere to the specified interface and thereby compromise the security and/or reliability of the service component.	Out of specification use, whether intentional or otherwise, will damage the integrity and security of the service component. Other services also dependent on that service component will be compromised.
Responsible Use - The service component aggregator will operate the service component responsibly and within its intended pattern and purpose of use.	The service component aggregator will make excessive demands on the service component and/or use the results from the service component in a way that undermines the intended purpose of the service.	Misapplication of the component may damage data security or the privacy of data subjects. The reputation of the service component owner might be undermined by the effects of irresponsible usage.

Accountable Authority Viewpoint

A transaction generally leads to transfer of benefit, commitment and value across accountability boundaries. If it is possible for the transaction to be disputed, an accountable party should be identified as owning the responsibility for resolving the dispute. In a well regulated cross business transaction environment, this responsibility would be explicitly identified and the obligations defined. In practice, responsibilities are often not well defined in advance, and the dispute resolution processes appeal to existing constructs such as arbitration, negotiation, and resolution by legal process.

If user expectations for transparency and fairness are to be met, sufficient attention should be paid to identifying the accountable parties in advance, and setting out their responsibilities and obligations. These parties may be formally recognised trusted third parties such as signing and certification authorities or, in the case of authentication services, the registration authorities - or they may be less formal entities such as one or both of the parties to the transaction defining dispute resolution processes to which the other subscribes.

Responsible parties have reasonable expectations concerning system qualities and behaviours so as to quantify their risk exposure.

Expectation	Concern	Risks
Accountability - The systems will preserve accountability within their business logic.	Systems will not be able to furnish sufficient or good quality evidence, to permit responsibilities and liabilities to be properly assigned.	Third parties will be exposed to unknown or unscoped risk because the evidence is not available to properly determine and assign responsibilities.
Traceability - Business logic, and inter domain transfers will maintain records that permit transactions to be audited, analysed, and potentially reversed.	Accounting and audit information will not be available, or trustworthy enough to assign responsibility for system activities.	Third parties will be exposed to unknown or unscoped risk because the evidence is not available to properly determine responsibilities.
Credential Protection - systems will protect critical credentials from exposure, misuse, or corruption.	Systems will not provide sufficient protection to critical objects such as private keys and biometric templates leading to potential for deniability of user actions.	A claim of credential corruption or exposure will be used to deny accountable activities.
Security Mechanism Strength - critical security mechanisms will be strong enough for their intended purpose.	Cryptographic and other (such as biometric) mechanisms with finite strength will not be strong enough for the intended purpose.	Inherent weaknesses in protection mechanisms will allow accountable actions to be denied or users impersonated.

International Consideration

Identity and access to public sector services is not a uniquely national concern. It has a strong connection to border and immigration controls and the need to share personal information with, and trust the systems of, overseas Governments and other organisations.

Expectation	Concern	Risks
Interoperability - users in one jurisdiction will be able to use the service from another jurisdiction.	Systems and services developed within one jurisdiction will not be accessible or usable from other jurisdictions.	UK services cannot be extended to nationals overseas and other nationals (particularly EU) entitled to UK public sector services. Continuation of legacy systems will be expensive, discriminatory, and will bypass security measures.
Legal Clarity - Users and owners of services delivered across borders will be confident about the legality of activities and the applicable law.	Users are uncertain about the legalities in relation to cross border transactions. System owners are unable to determine the legal implications of cross border access to their systems.	Users of systems will be exposed to legal action through use of public sector systems. Public services cannot be extended to nationals overseas and other nationals (particularly EU) entitled to UK public sector services. Continuation of legacy systems will be expensive, discriminatory, and will bypass security measures.
Privacy and Safety - Users of any one nation (specifically the UK) will not be exposed to safety and privacy risks through the actions or inactions of other nations and national programmes.	Personal and private information will be exposed to, and may be misappropriated by, overseas Governments and organisations.	Public sector systems and services present a risk to national security and safety of the population when extended to other administrations. Uptake of systems will be limited and legacy services will be continued.

References

[a] CESG Good Practice Guide 43, Requirements for Secure Delivery of Online Public Services, Issue 1.1, December 2012. Available from the CESG website.

Annex B

This Annex supports CESG Good Practice Guide No. 43 (GPG 43), Requirements for Secure Delivery of Online Public Services (reference [a]). The aim of this document is to provide a structured set of security components that can be used as part of a RSDOPS (Step 5 & 6) assessment.

1. Security Components

Key Principles

• This Annex describes a set of security components that can be used to express security requirements for online services
• For each component a set of levels (with increasingly stringent requirements) has been defined that provide a framework against which security requirements for online public services can be expressed and tested for compliance
• Higher levels often compound on lower levels and the ‘values’ are not linear across all security aspects
• Security profiles should be constructed with the most appropriate levels. Levels may vary within each security case

Introduction

This Annex has been developed to be applicable to the public sector, including central Government departments and agencies, non-departmental public bodies, local Government, Service Providers to these organisations and any user of their systems.

The security components are organised into sections to cover the various areas involved in providing a secure online service.

Each security component has a number of levels. As security component levels increase then the security requirements to meet each level increases.

A security profile for an online service can be determined based on these levels and an informed understanding of business goals and information risk.

Structure

This Annex contains a description of each security component. It is divided into the following sections:

a. End User Components – those relevant to the people and businesses accessing the service;

b. Server Components – those relevant to the ICT hosting the service;

c.

d. Network Components – those relevant to the network infrastructure which is used to access the services;

e. Business Logic Components – those relevant to the software application that implements the service;

f. Assurance Components – those relevant to gaining confidence in the end-to-end security of the public sector services.

For each component a set of levels (with increasingly stringent requirements) has been defined that provide a framework against which security requirements for online public services can be expressed and tested for compliance. Higher levels often compound on lower levels and the ‘values’ are not linear across all security aspects.

Each level description provides an explanation of the level plus information on requirements, examples and provision.

A summary table of the security components, including levels and descriptions can be found in Chapter 4 of GPG 43 (reference [a]).

2. End User Components

Key Principles

• Covers people and how they interact through the ICT used with the online public service
• End users may access online public services for a variety of work related or nonwork related reasons

Introduction

End user security components are those concerning people and their relationship to the ICT. People may interact with the ICT to access services for themselves, or on their organisation’s behalf. In most (but not all) cases it is necessary to establish the authority of those individuals to access the service and the extent of the access granted.

End users may be members of the public, businesses, public sector employees or employees of the Service Providers.

End user security is considered under the following headings:

a. Personal registration;

b. Corporate registration;

c. Authorisation;

d. Authentication;

e. Privacy.

Personal Registration

Personal Registration is the act of establishing the identity of a subject as a condition for obtaining a credential that can be presented subsequently to obtain access to a service.

The requirements for confirming authority to access a specific service are described in the Authorisation requirements. Characteristics of the credentials themselves and their handling form part of the Authentication requirements.

The organisational, personnel and physical security requirements of the organisations providing the personal registration service are described in the Assurance requirements.

Four personal registration levels are defined that represent increasing levels of confidence that the social identity of the registrant has been correctly established.

In general, it is acceptable for a credential issued in support of a high registration level to be used to support a service requirement that may only require a lower level of registration. Privacy considerations will, however, need to be considered as higher levels of registration may unnecessarily expose more of the user identity details than is necessary.

Further guidance is available in the area of personal registration via CESG Good Practice Guide No. 45 (GPG 45), Validating and Verifying the Identity of an Individual in Support of HMG Online Services (reference [c]).

The following tables provide details of the Personal Registration Security Component.

Level 0 Personal Registration – Not Required	Reference
Appropriate in circumstances where the social identity (whether real or a pseudonym) of the user is not relevant to the service offered.	PR-L0-01
Services for individuals with no authentication requirements will, by implication, expect Level 0 personal registration. It should be noted that the service may still need to authenticate itself to the user.	PR-L0-02
Requirements
There are no service specific requirements for personal registration.	PR-L0-03
Examples
Likely to be provided using commercially based systems that have no national security certification using standard features of the product. Registration will typically be optional to access the service and might involve setting cookies to store user personalisation requirements. No private information needs to be stored by the service.	PR-L0-04
Provision
Likely to be provided using commercially based systems that have no national security certification using standard features of the product. Registration will typically be optional to access the service and might involve setting cookies to store user personalisation requirements. No private information needs to be stored by the service.	PR-L0-04

Table 1 - Personal Registration Security Component at Level 0

Level 1 Personal Registration – Asserted	Reference
All aspects of personal registration at Level 0 are required, plus the following additional requirements:
Appropriate in circumstances where users, in order to gain access to a service, present an asserted identity, which may imply a real-world identity but need not necessarily do so.	PR-L1-01
The nature of the credential will depend on the strength of authentication required. The distinguishing factor for a Level 1 personal registration service is that disclosure of the real identity of the user is not essential and a pseudonym may be offered.	PR-L1-02
Information provided to users through a service requiring only Level 1 registration may attract higher requirements for authentication, privacy and confidentiality. If Level 1 personal registration is associated with a higher-level authentication requirement, care should be taken that the intent of the strong authentication is not undermined by lesser requirements for registration.	PR-L1-03
Requirements
The user is required to register before access to services can be granted. The user does not however need to disclose his or her real identity at registration.	PR-L1-04
The registration service should authenticate itself to the user. The strength of the authentication required will be dependent upon the registration information collected.	PR-L1-05
The registration service should make the user aware of any information and credentials that are to be stored on the user’s machine and how to manage that information. The service should be designed to minimise risk to information transferred to the user’s environment.	PR-L1-05
The registration information should be protected in transit between the user and the registration service where this information exchange occurs outside a trusted environment (see the Network Level Security Components for guidance on the level of protection).	PR-L1-06
Users should supply, or be issued with, unique access IDs and credentials. Access IDs and credentials do not, and might not claim to, represent any actual identity. An appropriately secure process should be used for the issuance of the credential.	PR-L1-07
Users should be made aware that they do not need to disclose a real identity and that they may offer a pseudonym.	PR-L1-08
Any self evident or inferred link to a real identity has no significance and should not be exploited by the service.	PR-L1-09
Where a user provides an electronic contact point (e.g. an e-mail address), confirmation that the user is in control of that contact point should be obtained.	PR-L1-10
A suitably secure process should exist for the issue of registration credentials. These credentials should be protected while in transit and mechanisms should be in place to prevent their unauthorised use.	PR-L1-11
Users should be made aware of the legitimate uses of registration credentials. The registration credentials should indicate any limitations on their permitted usage.	PR-L1-12
A secure process should be in place to enable and encourage the timely reporting of suspected compromise of a credential.	PR-L1-13
Secure processes should exist that enable a user to maintain their registration information in response to changes in their circumstances.	PR-L1-14
Secure processes should exist that enable recovery from compromise or misappropriation of a registration credential.	PR-L1-15
Registration or revisions to registration information, including deregistration, should be treated as accountable events. Accounting logs and audit information should be retained as required.	PR-L1-16
Examples
Applicable to services where the user needs to create an account to build up, and return to, stored information but no association with a real identity is needed, or offered.	PR-L1-17
May be associated with differing levels of authentication. A strictly pseudonymous service, for example a health check, may need strong authentication that matches the importance and sensitivity of the information.	PR-L1-18
Services which are primarily a purchase such as licensing may only need Level 1 personal registration as the identity of the applicant is not, strictly, an issue, providing that payment can be completed. In the absence of anonymous electronic cash services, payment processing will, of necessity, expose a relationship with a real identity but this is an issue for registration for the payment service, not registration for the public sector service. For example, the payment service may independently verify the identity of the user and authorise payment without revealing that identity to the service.	PR-L1-19
Provision
Level 1 registration will typically be performed wholly online. Commercial standard secure communications will typically be used between the registration authority and the registrant. Extended Validation Certificates may be needed by the Service Provider, dependent upon the nature of the information to be collected by the service. Information will be provided to the user on how to verify identity from the server certificate.	PR-L1-20
As part of the service registration process, a unique identifier is created that is associated with a credential. The type of credential required will be dependent upon the level of authentication the service requires.	PR-L1-21
If payment services are called up as part of the service, then the requirements of the payment service itself should be honoured.	PR-L1-22

Table 2 - Personal Registration Security Components at Level 1

Level 2 Personal Registration - Tested	Reference
All aspects of personal registration at Level 1 are required, plus the following additional requirements:
Level 2 personal registration is appropriate in circumstances where the service needs to collect and collate information on real individuals and pseudonymous registration is not appropriate.	PR-L2-01
Level 2 personal registration is primarily applicable to circumstances where registration will be conducted online and the immediate presence of the subject cannot be assumed. Potential users will need to present evidence that supports their identity claim, but the requirement for a traceable linkage to a real identity is not strong enough to merit rigorous independent face-to-face review and testing of the evidence. The testing of the evidence presented is expected to be sufficient for it to be offered in support of civil proceedings.	PR-L2-02
Requirements Level 2 personal registration requires the user to present evidence of real identity as part of the registration process.	PR-L2-03
The risks associated with using unsecured or public access devices should be clearly articulated. The service should be designed to minimise these risks.	PR-L2-04
Users should be informed before the point of identity registration of: • The use to be made of the identity registration information they submit and of any registration checks to be performed • Their obligations and responsibilities to the service	PR-L2-05
Evidence offered should be tested using an assured process for strength and validity so that, on the balance of probabilities, the claim of the user is shown to be true. The presented evidence should be testable in order to establish to a reasonable level of confidence that the: • Claimed identity exists • Registrant is the claimed identity	PR-L2-06
Evidence that demonstrates that the claimed identity exists should establish the identity uniquely and should reference independently verifiable registers of identity. Negative information sources such as databases on deceased persons should also be consulted as part of the verification process.	PR-L2-07
Evidence that the registrant is actually the claimed identity should be tested through a challenge/response mechanism. This may involve the use of pre existing shared secrets. Alternatively a trusted independent channel to that individual (such as mailing registration codes to the verified address) may be used.	PR-L2-08
Credentials issued to applicants should be issued in a secure manner. Users should be required to safeguard these credentials and not to share the credential with others.	PR-L2-09
Evidence should be presented to authorise significant changes in information (such as external contact data) and this should be subject to the same level of testing as the initially provided information.	PR-L2-10
Processes that revoke a credential when required should exist. Such processes should ensure that any relying parties can determine whether the credential has been withdrawn.	PR-L2-11
Processes that permit identity repair in the event of identity compromise should exist.	PR-L2-12
Registration and changes to registration information should be treated as accountable events. Records should be maintained to enable retrospective independent review and validation of the evidence presented.	PR-L2-13
Examples
Level 2 personal registration is primarily applicable to those services where the service has a personal casework element and is to be delivered to a real individual entitled to receive the service, but where the nature of the service is such that the motivation for adversaries to misrepresent themselves as others, or registered users to misuse the service, is limited.	PR-L2-14
Services that are candidates for Level 2 personal registration include those where the value transfer is primarily from the individual to public body, such as tax collection, and there is limited opportunity for fraud through the creation of false identities.	PR-L2-15
Level 2 personal registration may also be applicable to some services, such as licence issue, where the value or benefit flows out from the public body to the individual if the benefit is traceable and can be subsequently withdrawn or the transaction reversed.	PR-L2-16
Provision
Provision of the basic electronic registration service will match that forLevel 1 personal registration and the same implementation quality requirements will apply.	PR-L2-17
The discriminating factor for Level 2 personal registration is the provision of evidence that can bind the claimed identity of the registrant to a real identity without the need for face-to-face verification and the subsequent testing of that evidence.	PR-L2-18
As yet there is no reliable unique personal identifier. Typically first name, last name, date of birth, gender, nationality and current address are used to uniquely identify an individual and electronic verification services are used to verify the existence of an identity.	PR-L2-19
Prior to the introduction of any such service, other electronic verification Service Providers could be used. If such a Service Provider is used, the provider should: a. Be registered with the Information Commissioner’s Office as permitted to store personal data; b. Have access to multiple, independent sources of identity information, not just electoral roll information; c. Be able to link an applicant to both current and previous circumstances using a range of positive information sources; d. Have access to negative information sources, such as databases on identity fraud and deceased persons; e. Have transparent processes providing details of the checks that are carried out, the results of the checks, and how much certainty they give on the identity of the subject; f. Allow the registration organisation to capture and store the information used to verify an identity.	PR-L2-20
Verifying a person’s claimed identity is more difficult. The preferred approach is through the use of pre-existing shared knowledge. Selection of shared knowledge needs to be made with care to ensure that the likelihood of an impostor also knowing the information is low. Other mechanisms that have been used include sending a onetime code to a known location of the claimed identity when the mailing delays can be tolerated. Risks associated with this should however be considered (e.g. shared post boxes in some residential properties) and appropriate measures put in place to manage them. Other routes can be used, such as telephone, but only if the telephone number can be independently confirmed as belonging to the claimed identity and sufficient confidence exists that the risks associated with this route can be successfully managed.	PR-L2-21
Other established electronic identities may be available to vouch for the claimed identity of the registrant and may be offered in some cases. Care should be taken to ensure that the chain of evidence is properly traceable to a strong enough foundation identity and that single points of vulnerability are not unwittingly created.	PR-L2-22

Table 3 - Personal Registration Security Components at Level 2

Level 3 Personal Registration - Verified	Reference
All aspects of personal registration at Level 2 are required, plus the following additional requirements:
Appropriate in circumstances where the service should be delivered to specific identified individuals and the nature of the service delivered is such that there is a significant risk that those individuals may seek to undermine the service, or that the service benefits may be diverted to those not entitled to receive them by impersonating entitled subjects.	PR-L3-01
The subject claims a real identity and the claimed identity is subject to rigorous testing to independently verify the claims. This testing includes rigorous review of the evidence and the demonstrable presence of the registrant. The process establishes the identity of the individual beyond reasonable doubt.	PR-L3-02
The testing of the evidence presented is expected to be sufficient for it to be offered in support of criminal proceedings or sanction. (This should not be taken to imply a requirement for evidential strength systems.)	PR-L3-03
Requirements
Requires the user to present evidence of identity as part of the registration process. The evidence offered should, as part of the process, be subject to rigorous testing that demonstrates beyond reasonable doubt that the identity claimed by the user exists and that the subject is the claimed identity and present at registration.	PR-L3-04
The subject should be informed before the point of identity registration of the use to be made of the registration information collected and of the types of checks to be performed to verify their identity. The consequences of providing fraudulent information should be explained.	PR-L3-05
The presented evidence should be testable in order to establish beyond reasonable doubt that the: a. Claimed identity exists and is current; b. Registrant is the claimed identity; c. The registrant is present and a willing subject at the registration.	PR-L3-06
The evidence presented should enable the unique identification of an individual. Any sensitivities associated with this (e.g. transgender, witness protection) should be considered and appropriate measures put in place to provide adequate security protection. The biographic footprint (contextualised information about that person) of the identity should be checked. The identity should be confirmed to be current including confirming no evidence of death/cessation of the identity, social interactions of the identity should be checked, and evidence that identity has been active should be sought. Any biographic and biometric information should be tested for duplicates.	PR-L3-07
Evidence that the applicant owns the identity might include third party corroboration of the claimant’s identity from a trusted source, the use of shared pre-existing secret knowledge, the applicant demonstrating possession of verified documents, and verification of a pre-existing biometric against the applicant.	PR-L3-08
The applicant should be seen to be an active participant in, and present at, the registration and not apparently acting under duress or otherwise acting under the control of an adversary.	PR-L3-09
It should be confirmed that the registrant is unique and has not previously registered (unless there is a valid reason for multiple registrations). This should include checking the biometric and biographic data to confirm they are unique to the current applicant. Multiple registrations may be necessary to support for example transgender, witness protection, etc. Any sensitivity associated with an individual having been allowed to register multiple times should be explicitly considered and appropriate measures put in place to protect the existence of aliases.	PR-L3-10
The registrant should be informed of the processes to be followed in the event of changes in their circumstances or following an incident such as loss or other compromise of a credential.	PR-L3-11
A secure process should exist for the issue of registration credentials. These credentials should be protected while in transit and mechanisms should be in place to prevent their use by non registrants (e.g. PINs, biometrics, etc).	PR-L3-12
Users should be made aware of the legitimate uses of the registration credentials and any limitations on their use.	PR-L3-13
Consideration should be given to the possibility that Level 3 personal registration data may be used as supporting evidence in bringing a case against the (alleged) user to seek redress for misuse of the service. If this is a possibility, then care should be taken that a proper chain of evidence is available and that record keeping and accounting is strong enough to support the case.	PR-L3-14
Credentials should be issued, and any biometric capture carried out, at the same time as identity validation to ensure that the same individual is registered on the system.	PR-L3-15
Examples
Services requiring Level 3 personal registration are primarily those where there is significant benefit available to an adversary impersonating a legitimate subject, or the enrolled subject himself is a potential source of threat. It is appropriate where a user cannot be readily traced or a transaction reversed.	PR-L3-16
Example services include border controls and other physical access control. Financial benefit payments where the payments cannot be easily traced and recalled provide another example.	PR-L3-17
Services that attract a high level of personal accountability are likely to be candidates for Level 3 personal registration particularly where legal action may be taken against potential adversaries and evidence is needed that implicates the individuals concerned.	PR-L3-18
It is likely that Level 3 personal registration will be associated with a requirement for the highest authorisation and authentication levels. It may be acceptable to use Level 3 personal registration data in support of lower authorisation and authentication requirements though doing so may compromise privacy at the lower levels.	PR-L3-19
Provision
Provision takes place largely outside the ICT. Verification and validation of the individual and their entitlements is an administrative process that involves review of independent sources of identity information to confirm that the identity exists, review of documentary evidence presented by the registrant and interview of the registrants to confirm that they are the claimed identity.	PR-L3-20
As yet there is no reliable unique personal identifier. Typically first name, last name, date of birth, gender, nationality and current address are used to uniquely identify an individual and electronic verification services are used to confirm the existence of an identity. These are used to check the biographical footprint of the identity, to establish the relationship with their parents or guardians, check there are social interactions, that there is no evidence of death or cessation of the identity and that it has recently been active.	PR-L3-21
No national public sector identity assurance service currently exists. If in the future, such a service was to be established this would offer the preferred approach to verifying an identity.	PR-L3-22
Commercial electronic verification Service Providers exist. If such a Service Provider is used, as a minimum the provider should: a. Be registered with the Information Commissioner’s Office as permitted to store personal data; b. Have access to multiple, independent sources of identity information – e.g. not just electoral roll information; c. Be able to link an applicant to both current and previous circumstances using a range of positive information sources; d. Have access to negative information sources, such as databases on identity fraud and deceased persons; e. Have transparent processes providing details of the checks that are carried out, the results of the checks, and how much certainty they give on the identity of the subject; f. Allow the registration organisation to capture the information used to verify an identity.	PR-L3-31
Verifying a person’s claimed identity is more difficult. The preferred approach is through the use of shared knowledge. Selection of pre-existing shared secret needs however to be made with care to ensure that the likelihood of an impostor knowing such information is low. Other checks that can be performed include obtaining third party confirmation of the identity, requiring the registrant to be in possession of valid documents, through the applicant’s knowledge of the personal history of the identity and through the matching of existing biometrics.	PR-L3-32
Documentary evidence that can support the validation of an identity includes the examples documented in GPG 45 (reference [c]).	PR-L3-33
Evidence of current address might include the evidence taken from the examples documented in GPG 45 (reference [c]).	PR-L3-34
Documentary evidence should be originals or certified copies. A risk-based approach is likely to be followed in verifying the identity of an applicant. The use of statements printed from the Internet is not acceptable.	PR-L3-35
It is likely that Level 3 personal registration will take place in specific facilities designated, and designed, for that purpose and will include a face-to-face interview with the applicant and collection of biometrics.	PR-L3-36
Owing to the need for demonstrable presence of the registrant, remote personal registration at Level 3 is currently not envisaged though tools and techniques to achieve this might be the subject of future development.	PR-L3-37

Table 4 - Personal Registration Security Components at Level 3

Corporate Registration

Corporate registration is the process of establishing the:

a. Identity of an organisation;

b. Identity of the individual registering the organisation;

c. Authority of the individual to undertake the registration on behalf of the organisation.

The requirements for confirming authority to access a particular service are described in the Authorisation requirements. Technical characteristics of the credentials themselves and their handling form part of the Authentication requirements. The organisational, personnel and physical security requirements of the organisations providing the corporate registration service are described in the Assurance requirements.

Three corporate registration levels are identified that represent increasing levels of confidence that the identity and authority of the registrant has been correctly established.

In general, it is acceptable for an identity credential issued in support of a high registration level to be used to support a service requirement that may only require a lower level of registration. The converse is likely to be unacceptable.

Further guidance is available in the area of corporate registration via Good Practice Guide No. 46 (GPG 46), Validating and Verifying the Identity of a business or other organisation to HMG Online Services (reference [d]).

Level 0 Corporate Registration – Not Required	Reference
As with Level 0 Personal registration, Level 0 corporate registration is appropriate where the identity of the organisation has no significance to the service offered.	CR-L0-01
Services for organisations with no authentication requirements will by implication have a Level 0 corporate registration requirement.	CR -L0-02
Requirements
At Level 0 there are no service specific requirements for corporate registration.	CR -L0-03
Examples
Level 0 corporate registration is typically applicable to information only services where nothing is known, or expected to be known, about the users.	CR -L0-04
Provision
Level 0 corporate registration is intended to apply to commercially based systems that have no national security certification and where standard features of the product are used. Registration will typically be an option to access the service and might involve setting cookies to store user personalisation requirements. No private information will be stored by the service.	CR -L0-04

Table 5 - Corporate Registration Security Components at Level 0

Level 1 Corporate Registration – Asserted	Reference
All aspects of corporate registration at Level 0 are required, plus the following additional requirements:
As with Level 1 personal registration, Level 1 corporate registration is appropriate in circumstances where users are required to register to access the service but do not need to disclose their personal identity or that of their organisation.	CR-L1-01
In order to gain access to the system, users will present a chosen identity (which may be a pseudonym) and a credential that will be used when gaining access to the service. The nature of the credential will relate to the strength of authentication required. The distinguishing factor for a Level 1 corporate registration service is that the real identity of the user or the organisation they are representing is not required and inferences about the real identity may not be exploited.	CR-L1-02
Any commercially sensitive information solicited is not linked to or shared with external bodies. Real identification information is not necessary to obtain authorisation to use the service. Information provided by the user may still need to be safeguarded. It is noted that information provided by registrants through a service requiring only Level 1 corporate registration may attract high requirements for authentication, privacy and confidentiality.	CR-L1-03
If Level 1 corporate registration is associated with a higher level of authentication requirement, care should be taken that the intent of the strong authentication is not undermined by the lesser requirements for registration.	CR-L1-04
Requirements
The user should register before being granted access to the service. The user is not required to expose his or her actual identity or the organisation that they represent.	CR-L1-05
The registration service should authenticate itself to the user by the start of the registration process. The strength of the authentication required will depend upon the registration information collected and should be in line with commercial good practice.	CR-L1-06
The registration service should make the user aware of any information and credentials that are to be stored on the user’s client machine and how to manage this information. The service should be designed to minimise the risks associated with the storage of sensitive information on the client’s machine.	CR-L1-07
The registration information should be protected in transit between the user and the registration service where this information exchange occurs outside a trusted environment (see the Network Level Security Components for guidance on the required level of protection).	CR-L1-08
Users should supply, or be issued with, unique access IDs and credentials. Access IDs and credentials need not, and may not claim to, represent any actual identity. A secure process should be used to issue any credentials.	CR-L1-09
Where a user provides an electronic contact point (e.g. E-mail address), confirmation that the registrant is in control of that contact point should be obtained.	CR-L1-10
Secure processes should exist that enable a user to maintain their registration information to account for changes in their circumstances.	CR-L1-11
Secure processes should exist for the issue of registration credentials. These credentials should be protected while in transit and mechanisms should be in place to prevent their unauthorised use.	CR-L1-12
Users should be made aware of the legitimate uses of the registration credentials and any limitations on their use.	CR-L1-13
A secure process should be in place to enable and encourage the timely reporting of suspected compromise of a credential.	CR-L1-14
Secure processes should exist that enable compromise or misappropriation of a registration credential to be handled.	CR-L1-15
Registration or revisions to registration information should be treated as accountable events. Accounting logs and audit information should be retained.	CR-L1-16
Examples
Level 1 corporate registration is applicable to services where the user is required to create an account to build up, and return to, stored information but no connection is needed, or offered, to a real identity. For example, completion of a licence application that is subsequently printed, signed and posted to the relevant organisation.	CR-L1-17
Services which are primarily a purchase for which payment provides sufficient authority for access are typical of services requiring Level 1 registration (e.g. download of documents from Companies Houses, Land registry documents, chart information available from UK Hydrographic Office). Payment processing will, of necessity, imply a linkage to a real identity but this is an issue for registration for the payment service, not registration for the public sector service.	CR-L1-18
Provision
Level 1 registration will typically be performed online. Transport Layer Security (TLS) with Enhanced Validation Certificate and with information being provided to the user on how to verify identity from the server certificate will typically be used to verify the identity of the registration service. As part of the service authorisation process a unique identifier is created that is associated with a credential. The type of credential required will be dependent upon the level of authentication the service requires.	CR-L1-19
If payment services are called up as part of the service, then the requirements of the payment service itself should be honoured.	CR-L1-20

Table 6 - Corporate Registration Security Components at Level 1

Level 2 Corporate Registration – Tested	Reference
All aspects of corporate registration at Level 1 are required, plus the following additional requirements:
Level 2 corporate registration is appropriate in circumstances where the service collects and collates information related to real organisations and pseudonymous registration is not appropriate.	CR-L2-01
Potential users will need to present evidence that supports their real identity, the identity of the organisation they represent and that they are authorised to perform the registration on behalf of that organisation.	CR-L2-02
The requirement for a traceable linkage to identity is, however, not strong enough to merit rigorous independent face-to-face review and testing of the evidence. It may however be cited in support of a civil prosecution.	CR-L2-03
Level 2 corporate registration is primarily applicable to services where registration should be conducted remotely and there is limited opportunity to test the validity and quality of the information presented.	CR-L2-04
Requirements
Level 2 corporate registration requires the user to present evidence of organisational identity, their identity and their authority to register on behalf of the organisation as part of registration for access to the service. Evidence offered should be tested for strength and validity so that, on the balance of probabilities, the claims of the registrant are shown to be true. Evidence of their identity should be verified in accordance with either Level 2 or Level 3 personal registration.	CR-L2-05
The registration service should authenticate itself to the user. The strength of the authentication required will depend upon the registration information collected and should be in line with business need.	CR-L2-06
The registration service should make the user aware of any information and credentials that are to be stored on the user’s client machine and how to manage this information. The service should be designed to minimise the risks associated with this.	CR-L2-07
Registrants should be informed at or before the point of identity registration of the intended use to be made of the identity registration information they submit and of any registration checks to be performed. The registrant should be informed of the penalty for fraudulent application.	CR-L2-08
The registration information should be protected in transit between the user and the registration service where this information exchange occurs outside a trusted environment (see the Network Level Security Components for guidance on the required level of protection).	CR-L2-09
The evidence offered should be tested using an assured process for strength and validity so that, on the balance of probabilities, the claim of the user is shown to be true. The presented evidence should be testable in order to establish to a reasonable level of confidence that the: a. Claimed organisation exists; b. Claimed user identity exists; c. Registrant is the claimed user; d. User has the authority to register on behalf of the organisation.	CR-L2-10
The identity of an organisation is the set of attributes that together uniquely identify the organisation. Within the UK there is no single official or statutory attribute or set of attributes that are used to uniquely identify organisations, nor is there an official or statutory document or other credential to demonstrate that identity. Most organisations will have a set of attributes, some or all of which uniquely identify them to a wide range of parties, including the public sector. As a minimum these attributes will include the name by which an organisation is known and the address at which it undertakes its principal activities.	CR-L2-11
Evidence that demonstrates that the claimed organisational identity exists should establish the identity uniquely and should reference independently verifiable registers. Negative information sources such as databases of dissolved companies or databases on identity fraud should be consulted as part of the verification process. The biography of the identity should be checked and evidence of recent trading should be obtained.	CR-L2-12
The evidence that the claimed identity of the user exists should satisfy the requirements of Level 2 or Level 3 personal registration. The level required will be dependent on business need.	CR-L2-13
Evidence that the registrant is actually the claimed identity and has the authority to register on behalf of the organisation should be tested through a challenge/response mechanism that can validate a trusted independent channel to a known official of the organisation concerned.	CR-L2-14
A secure process should exist for the issue of registration credentials. These credentials should be protected while in transit and mechanisms should be in place to prevent their unauthorised use.	CR-L2-15
Users should be made aware of the legitimate uses of the registration credentials. The registration credentials should contain information on any limitations on their use.	CR-L2-16
A secure process should be in place to enable and encourage the timely reporting of suspected compromise of a credential.	CR-L2-17
Processes should be in place to enable registration information to be maintained and reflect any changes in the user’s and organisation’s circumstances. Registrants should be able to review and update their information when required. The update process should be subject to the same level of testing as initial registration.	CR-L2-18
The organisation registering should be required to inform the registration authority in the case of any substantive change in circumstances, including cases where an issued credential should be revoked.	CR-L2-19
Effective processes to revoke a credential when required should exist. Such processes should ensure that any relying parties are aware of the fact that the credential has been withdrawn.	CR-L2-20
Processes that enable identity repair in the event of compromise should exist.	CR-L2-21
Registration and changes to registration information should be treated as accountable events. Records should be maintained to enable retrospective independent review and validation of the evidence presented.	CR-L2-22
Examples
Level 2 corporate registration is primarily applicable to those services where the service is delivered to a real organisation entitled to receive the service, but where the nature of the service is such that the motivation for adversaries to misrepresent themselves as others, or registered users to misuse the service, is limited.	CR-L2-23
Services that are candidates for Level 2 corporate registration include those where the value transfer is primarily from the business to the public sector, such as making PAYE or NIC, VAT and corporation tax collection, and there is limited opportunity for fraud through the creation of false identities.	CR-L2-24
Level 2 corporate registration may also be applicable to some services, such as e-procurement, where the value or benefit flows out from the public sector to the business if the benefit is traceable and can be subsequently withdrawn.	CR-L2-25
Provision
Provision of the basic electronic registration service will match that for Level 1 corporate registration and the same implementation quality requirements will apply.	CR-L2-26
The discriminating factor for Level 2 corporate registration is the provision of evidence that can bind the claimed identity to a real identity without the need for face-to-face or site visit verification.	CR-L2-27
As yet there is no single unique identifier for all organisations. Corporate organisations have certain legally required attributes, which can be regarded as defining identity. These include its: a. Registered number; b. Registered corporate name and any trading names used; c. Registered address and any separate principal trading addresses.	CR-L2-28
Certain other organisations also register with official statutory or other governing bodies (e.g. Charities, Solicitors, and Accountants). In this case, it will be the attributes by which they are known and recognised to such bodies that will be required to be validated during registration. One particular attribute, which often acts as a de facto “official” registration for most trading bodies, is the VAT registration number.	CR-L2-29
Where a public registration is required for an organisation (e.g. Limited Liability Partnership, Limited or Public Limited Company, Charity) the relevant official registration authority is consulted (e.g. Companies House, Charity Commissioner’s) to validate the organisational identity. In other cases a commercial organisation providing acceptable identity services may need to be used.	CR-L2-30
As with Level 2 personal registration, an electronic identity Service Provider should: a. Be able to link an applicant to both current and previous circumstances using a range of positive information sources; b. Have access to negative information sources, such as databases on identity fraud, closed companies, etc; c. Have transparent processes providing details of the checks that are carried out, the results of the checks, and how much certainty they give on the identity of the subject; d. Allow the capture and storage of the information used to verify an identity.	CR-L2-31
Provision of personal identification service for the registrant’s representative is the same as for Level 2 or Level 3 personal registration.	CR-L2-32
Confirmation that the user is the claimed identity and has the authority to perform the registration is more difficult. It may involve the use of shared secrets. Selection of shared secrets needs however to be made with care to ensure that the likelihood of an unauthorised person knowing the information is low. Other mechanisms include sending a onetime password to a known official of the organisation at a known address where the mailing delays can be tolerated. Risks associated with this should however be considered and appropriate measures put in place to manage them. Other routes can be used, such as telephone, but only if the telephone number can be independently verified as belonging to the claimed identity and the name of an appropriate official to contact is known. Again the risks associated with this approach should be carefully considered and appropriately managed.	CR-L2-33
Other established electronic identities may be available to vouch for the claimed identity of the registrant and may be offered in some cases. Care should be taken to ensure that the chain of evidence is properly traceable to a strong enough foundation identity and that a single point of vulnerability is not unwittingly created.	CR-L2-34

Table 7 - Corporate Registration Security Components at level 2

Level 3 Corporate Registration – Verified	Reference
All aspects of corporate registration at Level 2 are required, plus the following additional requirements:
Level 3 for corporate registration is currently under development	CR-L3-01

Table 8 - Corporate Registration Security Components at level 3

Authentication

Authentication is the last step in the process by which an authorised service user is granted access to use a service.

This section defines four authentication levels that represent the degree of confidence that the electronic identity quoted during authentication matches the registered identity for that account.

Further guidance on the use of credentials to support authentication is available in CESG Good Practice Guide No. 44 (GPG 44), Authentication Credentials in Support of HMG Online Services (reference [e]).

Level 0 Authentication – Not Required	Reference
For a Level 0 service no explicit authentication actions are required to access the service but untested session context (such as cookies) might be set. Misappropriation of this session information will have no consequence.	Authen-L0-01
Requirements
In simple cases, there are no requirements for user authentication. In restricted environments, there may be authentication requirements for access to the environment in which the service is offered (e.g. access to a corporate system), and these will be defined by the system used for access.	Authen-L0-02
If session context information is set the user should be made aware of this.	Authen-L0-03
Level 0 services should not retain information that allows the service user to be identified and should not retain details of payment instruments such as credit cards.	Authen-L0-04
Depending on the type of service offered there may be a requirement for the public sector service to authenticate itself to the user. If this is the case commercial good practice should be followed.	Authen-L0-05
Controls should be in place to prevent unauthorised users obtaining access to key system data including account identifiers and password files.	Authen-L0-06
Examples
Level 0 Authentication services are typically information only services that require no information from or about the users. Most departmental public web sites will fit into this category as they are primarily offering freely downloadable information and documents.	Authen-L0-07
Services that involve simple purchasing activities may be Level 0 if the service does not need to retain personal information about the subscriber and the requirements of any payment service are satisfied.	Authen-L0-08
Provision
No user authentication service is required. Server authentication, when required is likely to involve the use of TLS with users being encouraged to explicitly confirm the provenance and validity of the server’s certificate.	Authen-L0-09

Table 9 - Authentication Security Components at Level 0

Level 1 Authentication – Minimal	Reference
All aspects of authentication at Level 0 are required, plus the following additional requirements:
Level 1 authentication is applicable to public sector services where user authorisation is mandated but strong anti-replay measures are not justifiable. The user will typically be required to expose an authentication secret that was agreed at authorisation.	Authen-L1-01
Requirements
Level 1 authentication should not be used for services where private or commercially sensitive information will be collated and stored by the service that attracts a Privacy level of 1 or higher (see the Privacy section).	Authen-L1-02
The service should authenticate itself to the user prior to starting the user authentication session. This should be done in accordance with business need and is expected to comply with commercial good practice.	Authen-L1-03
The service should make the user aware of: a. Any information and credentials that are to be stored on the user’s client machine; b. The risk associated with the use of unsecured or public access systems and, preferably, offers an access mode that leaves no persistent information on the client device.	Authen-L1-04
Users should be informed of any special measures they need to take before, during, and after client sessions.	Authen-L1-05
As part of the authentication process, the user should demonstrate possession of an authentication credential that was issued during the authorisation process. An authentication secret may be directly quoted during authentication. Authentication secrets should, however, be protected in transit across any untrusted networks (see the Network Level Security Components for guidance on the required level of protection).	Authen-L1-06
Good password disciplines should be maintained, and the systems should be designed to enforce these disciplines. This includes processes for ensuring password quality, password protection and for the password replacement after prolonged use.	Authen-L1-07
The system should be designed to minimise or eliminate internal exposure of passwords.	Authen-L1-08
The system should be designed to minimise the threat from exhaustion, dictionary, or other automated attacks.	Authen-L1-09
Controls should be in place to prevent unauthorised access to key system data including account identifiers and password files.	Authen-L1-10
Users should be informed of the exception-handling procedures that are in place (such as suspected loss or compromise of a credential). These procedures should be easily accessible to the user.	Authen-L1-11
A secure process should exist for user account recovery (e.g. in the event of a user forgetting his/her password). This should be at least as secure as the initial authorisation process.	Authen-L1-12
Accounting logs and audit information should be recorded and supported by appropriate monitoring and accounting procedures to enable potential attacks on the system to be detected and appropriate mitigation measures taken. A chain of evidence should be maintained to enable users to be held accountable for their actions (see Accountability and Situational Awareness Security Components).	Authen-L1-13
Examples
Examples of transactions that might merit Level 1 authentication include: a. A client makes an application or initiates a transaction that will be completed on the basis of a paper form. The service that allows the user to create and populate an electronic facsimile of the paper form which will contain personal information that should be protected, but may only need Level 1 protection. b. A client participates in on-line training. There is a need for authentication such that the client is recognised by the service and connected to the appropriate place in the course or given relevant assignments and grades. c. On-line purchase of a service – where personal information is stored for the convenience of the user.	Authen-L1-14
Provision
Level 1 authentication services will typically be implemented using username/password logins with system generated or user chosen passwords. Passwords will be subject to quality checks and technical measures, such as TLS access over Hypertext Transfer Protocol Overview (HTTP), will be used to provide service authentication and to minimise the risk of password or other sensitive information capture in transit over the network.	Authen-L1-15
At Level 1, replay protection is not required, static passwords are generally sufficient. On-line password resets are likely to involve demonstration of a subset of a set of shared secrets agreed during authorisation. The subset will be different for each reset request.	Authen-L1-16
It is likely that good quality commercial password systems will suffice for Level 1.	Authen-L1-17

Table 10 - Authentication Security Components at Level 1

Level 2 Authentication – Robust	Reference
All aspects of authentication at Level 1 are required, plus the following additional requirements:
At Level 2, the user is required to demonstrate possession of unique knowledge agreed at, or items issued at, registration without disclosing anything that could be captured by an observer and replayed to falsify a transaction.	Authen-L2-01
The requirement may be met through use of a suitable token, or a challenge/response session that invites the user to demonstrate partial knowledge from a set of memorable information items where successive challenges invite the release of different subsets of the knowledge – often referred to as shared secrets.	Authen-L2-02
At this level an assumption is made that the authorised user is generally cooperative and well intentioned.	Authen-L2-03
Requirements
Measures should be in place to prevent any other impersonation attacks. Consideration of the prevention of man-in-the-middle attacks in both client to server and server to client communications will be required.	Authen-L2-04
The service should authenticate itself to the user prior to starting the authentication session. This should be done in accordance with good commercial practice.	Authen-L2-05
The service should make the user aware of: a. Any information and credentials that are to be stored on the user’s client machine; b. The risk associated with the use of unsecured or public access systems and, preferably, offering an access mode that does not leave persistent information on the client machine.	Authen-L2-06
Users should be informed of any special measures that they need to take before, during, and after client sessions.	Authen-L2-07
If a memorable information system is used: a. The knowledge space should be large enough for a chance replay attack to have a low probability of success without demanding too much of the user’s ability to recall the knowledge; b. Good disciplines should be maintained in selecting the shared secrets, and the systems should be designed to enforce these disciplines; Level 2, Remote Authentication (reference [f]). It is essential that the envisaged attacker is considered in designing such systems (e.g. family members); c. Users should be able to change the memorable information as it become stale, incorrect, or possibly compromised; d. The system should be designed to minimise or eliminate internal exposure of the shared secrets; e. The system should be designed to minimise the threat from brute force, dictionary and other automated attacks; f. Provision should be made to enforce renewal of secrets after an elapsed period of time and after frequent use.	Authen-L2-08
The memorable information approach should be considered as an interim measure pending the introduction of stronger two factor based schemes.	Authen-L2-09
If tokens are used in support of Level 2 authentication: a. They should be protected against duplication; b. Their status should be checked; c. Where theft of the token is possible, it should be ensured that the credential is only usable in conjunction with collateral information such as a password/PIN. Good password disciplines should be maintained.	Authen-L2-10
Explicit consideration of when authentication is required should be given. For example, the need to authenticate both to access the service and on initiating significant transactions should be considered.	Authen-L2-11
Users should be informed of the exception-handling procedures that are in place (such as reporting actual or suspected loss of a token). These procedures should be easily accessible to the user.	Authen-L2-12
Accounting logs and audit information should be recorded and supported with appropriate monitoring and accounting procedures. Forensic examination of the use of the service should be possible to allow potential attacks to be detected and appropriate mitigation measures to be taken. Evidence relating to suspected errant user activity should be appropriately managed to ensure that it may be cited in support of civil recovery actions. Accounting and audit requirements are defined in more detail in the Accountability and Situational Awareness Security Components.	Authen-L2-13
Examples
Level 2 authentication is appropriate for personal casework services where the customer is generally motivated to make successful use of the electronic service delivery option and the primary threat is misuse by unauthorised individuals. The majority of services that are delivered to specific individuals will require Level 2 authentication, this includes such services as tax and benefit accounts, pensions, and welfare.	Authen-L2-14
Provision
There are several technical approaches that can provide the essential additional protections needed for Level 2 over that provided by Level 1. The simplest, and lowest implementation cost, is to use a memorable information approach where the service and the user agree memorable information such as pre-placed questions or a password and, during authentication, ask a subset of the questions or for particular letters from the password using different random choices for each session. This approach has usability and security issues that make it less suitable for longer term use.	Authen-L2-15
Tokens generally provide a stronger solution providing they are protected against duplication. If unprotected tokens, such as magnetic stripe cards (that can be readily duplicated) are to be used the risks associated with this will need to be considered. Tokens that can encrypt a onetime challenge, or a rolling time based counter, are preferable but may have significant logistical and cost implications.	Authen-L2-16
Other technologies that might be suitable include sending a onetime password to the user by phone or text message. Consideration of the protection required for this password while in transit needs however to be carefully considered and there may be usability and diversity concerns that rule it out as a universal solution.	Authen-L2-17
Technology continues to advance in this area and new products should be assessed for their suitability. Use of commercial technology will be subject to a proper review, and possible evaluation, of the security.	Authen-L2-18

Table 11 - Authentication Security Components at Level 2

Level 3 Authentication – Accountable	Reference
All aspects of authentication at Level 2 are required, plus the following additional requirements:
At Level 3, service authentication is required to collect strong evidence that the individual requesting the service is actually the person registered, and is present at the time of authentication.	Authen-L3-01
Level 3 authentication is also required to support mandatory authentication of potentially unwilling subjects who may be strongly motivated to take action to cause a failure to authenticate, or to be authenticated as a different enrolled subject who may or may not have been complicit in the attempt to falsify the authentication.	Authen-L3-02
At Level 3 the authentication measures should resist unwilling or malicious authorised users, correctly categorise non-authorised subjects, and collect evidence that can hold malicious subjects to account for their actions.	Authen-L3-03
Requirements
Strong measures should be in place to prevent man-in-the-middle and other impersonation attacks including strong authentication of the service to the user. Separate consideration should be given to communications from the client to the server and from the server to the client.	Authen-L3-04
The client used to access the service should not be trusted to protect the credential unless the service is able to validate any assumptions made (e.g. the service provides secure kiosks to enable user access of the service).	Authen-L3-05
Tokens used in support of Level 3 authentication should be protected against duplication. The token should only be usable in conjunction with collateral information such as a password/PIN. Good password discipline should be maintained.	Authen-L3-06
Where threats from the user cannot be discounted the token should have tamper protection that is capable of resisting attack from a skilled attacker. Guidance on the appropriate measures should be sought from the National Technical Authority (CESG).	Authen-L3-07
Users should be made aware of, and should agree to, the measures they should take to protect the token and the consequences of not following the measures.	Authen-L3-08
Users should be informed of the exception-handling procedures that are in place (such as the suspected loss of a token) and agree to follow these procedures in a timely manner when required.	Authen-L3-09
Accounting logs and audit information should be recorded, supported by appropriate monitoring and accounting procedures to enable forensic examination of the use of the service and to allow potential attacks to be detected and appropriate mitigation measures to be taken. Consideration should be given to the possibility that audit information may be used as supporting evidence in bringing a case against the (alleged) user to seek redress for misuse of the service. If this is a possibility, then care should be taken that a proper chain of evidence is available, and record keeping and accounting is strong enough to support the case. Accounting and audit requirements are defined in more detail in the Accountability and Situational Awareness Security Components.	Authen-L3-10
If Biometric Technology is used to support Level 3 authentication, the security properties that the biometric system should possess are that: a. There should be a low probability that an enrolled user will be incorrectly identified as a different enrolled user; b. There should be a low probability that a hostile user can bring about a deliberate failure to identify; c. The system should be resistant to the use of artefacts that could be employed to authenticate an enrolled user who is not present; d. The system should have a low probability that a subject will fail to enrol correctly, either through natural body characteristics, or deliberately caused. e. The system should be usable, acceptable to its target user base, and suitable for its intended application.	Authen-L3-11
Explicit consideration of when authentication is required should be given. For example, the need to authenticate both to access the service and on initiating significant transactions should be considered.	Authen-L3-12
Examples
Level 3 authentication is applicable, e.g. to border control and law enforcement applications where the physical movement of people, or non recoverable benefit transfer, is the issue.	Authen-L3-13
Remote (unsupervised) application of Level 3 authentication will be limited by the ability to adequately assure the binding of an offered credential to a real, and present individual.	Authen-L3-14
Provision
Level 3 authentication may incorporate a degree of biometric technology to demonstrate the actual presence of the enrolled person. This is particularly relevant if the user is likely to be unwilling to verify their identity. Depending on the application, this may be configured as true authentication (substantiating a claimed identity), or identification (establishing the identity without a supporting claim). If biometric technology is to be used, reference should be made to the significant body of material that has been developed to assist in the choice and assessment of biometric technologies and products (see for example the guidance material available on the CESG website (reference [g]).	Authen-L3-15
Biometrics may not however be essential at Level 3 in circumstances where the authentication is needed primarily to support strong accountability but the threat arising from the user themselves can be discounted. In this case, a recognised signing device (e.g. Chip and Pin) may be sufficient to support the strong accountability at Level 3. Strong accounting requirements will however need to be associated with the token/signing devices.	Authen-L3-16

Table 12 - Authentication Security Components at Level 3

Authorisation

Authorisation is the process by which a registered user’s entitlement to access a particular service is confirmed and authorisation is then granted to access the service for a defined period. It includes validation of some attributes of a subject to enable their entitlement to access a service to be validated. The attributes that will require validation will be service specific as will the level of validation required. Authorisation also covers the circumstances in which a person or company acts as a proxy or agent. Their authority to do so needs to be verified.

It covers the processes required to:

a. Establish the validity of any attributes of a potential service user;

b. Confirmation that the validated attributes entitle the potential user to access the service;

c. The provision of any service specific credentials/account to enable that access;

d. Suspend, revoke or disable a credential/account as required.

The attributes that need to be presented and validated to confirm entitlement to access a particular service will be service specific.

The organisational, personnel and physical security requirements of the organisations providing the Authorisation service are described in the Assurance requirements.

The technical characteristics of the credential themselves and their handling form part of the Authentication requirements.

This section defines two Authorisation levels that represent increasing levels of validation of the attributes of a user. They involve obtaining increasing levels of confidence that a user is entitled to use the service.

For services that require checks to be performed on a claimed real identity for access to be provided, authorisation may be performed at the same time as registration. There is, however, often a preference for authorisation to be delayed until first use of the service is required by the user. If authorisation is performed after registration, the identity credential issued as part of the registration process will need to be used to support the authorisation either directly or indirectly.

Although registration initially establishes identity, the process of verifying an identity is a cumulative process. Authorisation for a particular service may offer the opportunity to gain additional assurance on the identity of the individual through a shared secret or for changes in circumstances of a user since registration to be identified. Full advantage of these opportunities should be taken. It should be noted that not all services will need or offer this opportunity.

For some business services, it may be necessary to look beyond the identity of the user to determine the controlling interest or the identity of the individuals owning or running the organisation represented by the users. Where required this should be done as part of service authorisation.

Level 0 Authorisation – Implicit	Reference
At Level 0 there is no explicit requirement to verify the entitlement of a user to access the service.	Author-L0-01
Requirements
There are no service specific requirements for authorisation.	Author-L0-02
Examples
Level 0 authorisation is typically applicable to information only services where nothing is known, or expected to be known, about the users. Visibility of the service is considered to be authority to use it.	Author-L0-03
Provision
Not applicable at this level – Authorisation by virtue of service visibility may be inferred from a prior network authentication.	Author-L0-04

Table 13 - Authorisation Security Components at Level 0

Level 1 Authorisation – Tested	Reference
All aspects of authorisation at Level 0 are required, plus the following additional requirements:
At Level 1 the entitlement of the user to access the service is tested. This may be based on evidence offered by the user themselves or, once the service has established the identity of the registrant, evidence of entitlement may be tested within the service itself.	Author-L1-01
Level 1 authorisation may be associated with Level 1, Level 2 or Level 3 Personal Registration or Level 1 or 2 Corporate Registration.	Author-L1-02
Requirements
The authorisation service should authenticate itself to the user. The strength of the authentication required will depend upon the authorisation information to be collected, what the service authorisation is for, and should be appropriate to the business need.	Author-L1-03
The authorisation service should make the user aware of any information and credentials that are to be stored on the user’s client machine and how to manage this information. The risks associated with using unsecured or public access devices should be clearly articulated. The service should be designed to minimise these risks.	Author-L1-04
The authorisation service should make the user aware of any conditions of use for the service and obtain their agreement to these terms. The user should be informed of any changes in their circumstances that they should report to the service to enable their continued entitlement to use the service to be assessed. The user should be made aware of their obligations to keep any sensitive information secret and to securely store any issued credentials.	Author-L1-05
The authorisation service should make the user aware of any measures the user should take to protect any credential issued as part of the authorisation process and obtained their agreement to these terms. The user should be made aware of the exception-handling and incident reporting processes to be followed.	Author-L1-06
The authorisation evidence requested should be the minimum required in order to confirm a user’s authorisation to use the service. Confirmation of entitlement should be based on the ‘balance of probabilities’. Where necessary, ‘Out of band’ mechanisms may be required to confirm authority/entitlement. The status of any registration credentials used as part of the authorisation process should be checked to ensure they are valid.	Author-L1-07
Authorisation information should be protected in transit between the user and the authorisation service where this information exchange occurs outside a trusted environment (see the Network Level Security Components for guidance on the level of protection).	Author-L1-08
Credentials used to access the service should be issued in a secure manner. Where tokens are used, the passwords used to protect access should be delivered separately to the token. Users of the credentials should be required to protect the privacy of the password and not to share the credential with others.	Author-L1-09
Credentials issued should normally have limited life-span and should normally be subject to suspension following a set period of inactivity. The appropriate lifetime and the period of inactivity that results in suspension will be service dependent. In some cases it may be appropriate to establish normal usage patterns and disable credentials if there are significant deviations from these patterns.	Author-L1-10
A secure process should exist for the issue of registration credentials. These credentials should be protected while in transit and mechanisms should be in place to prevent their unauthorised use.	Author-L1-11
A secure process should be in place to enable and encourage the timely reporting of suspected compromise of a credential.	Author-L1-12
Secure processes should exist that enable a user to maintain their authorisation information and account for changes in their circumstances.	Author-L1-13
Clear procedures should be in place to enable users to terminate authority to use a service and to revoke a credential.	Author-L1-14
Secure processes should be in place to enable a user to recover their authorisation credentials in the event of loss or damage.	Author-L1-15
A process should be in place to review the continued entitlement of users to be enrolled in a service and to suspend or remove users who are no longer entitled.	Author-L1-16
Authorisation or revisions to authorisation information should be treated as accountable events. Accounting logs and audit information should be recorded.	Author-L1-17
Examples
Services involving low value purchase provide examples of services for which Level 1 authorisation may be appropriate. Confirmation of payment will be sufficient evidence of entitlement to access the service. For other services presentation of the agreed credential and shared secret may provide sufficient evidence of entitlement.	Author-L1-18
Services that are candidates for Level 1 authorisation include those where the value transfer is primarily from the business to the public sector, such as making PAYE or NIC, VAT and corporation tax collection, and there is limited opportunity for fraud through false authorisation.	Author-L1-19
Level 1 authorisation may also be applicable to some services, such as e-procurement, where the value or benefit flows out from the public sector to the business if the benefit is traceable and can be subsequently withdrawn.	Author-L1-20
Provision
Level 1 authorisation will typically use standard commercial systems but will require additional testing to show that there are sufficient quality checks in place and that the system makes clear to the users the purpose and scope of authorisation.	Author-L1-21
For some services confirmation of entitlement will be based on confirmation of payment. The requirements of the payment service will need to be met in these circumstances.	Author-L1-22
For some services (e.g. some business services), the claimed authority of the user will need to be validated through out of band techniques (for example, by contacting a known official of the organisation at a known address or telephone number to confirm the role of a user).	Author-L1-23
In all cases an appropriate chain of evidence will need to be maintained to allow independent validation of the decision to enrol a user.	Author-L1-24

Table 14 - Authorisation Security Components at Level 1

Privacy

Privacy is a requirement for socially responsible handling of personal and commercially sensitive information. Individuals and businesses have a reasonable expectation that measures are in place to ensure that the information collected by a service:

a. Is the minimum necessary to fulfil its purpose;

b. Is only accessible to those with a legitimate need to know;

c. Is used only for the declared purposes for which it was collected;

d. Is maintained to ensure its continuing validity and quality;

e. Is disposed of in a secure manner when no longer required.

Assurance should be provided to the individual and the business that these expectations are being met and that information held on them can be presented to them on request.

Level 0 Privacy – No Statement	Reference
At Level 0 no private information is collected by the service.	PR-L0-01
Requirements
There are no specific Privacy requirements. A Privacy Impact Assessment (PIA) (reference [h]) may need to be performed to confirm this.	PR-L0-02
Examples
Examples of services likely to fall into this category include those that provide information only services, e.g. departmental websites offering free downloadable information which do not set cookies or devices that can be used to track the browsing history of a user.	PR-L0-03
Provision
Provision is likely to involve the use of standard features of commercially based systems. No particular Privacy Enhancing Technology need be utilised.	PR-L0-04

Table 15 - Privacy Security Components at Level 0

Level 1 Privacy – Implicit	Reference
All aspects of privacy at Level 0 are required, plus the following additional requirements:
At Level 1 the service is designed to minimise its privacy impact on prospective users. Privacy related objectives are considered alongside business goals, and privacy considerations are addressed at every stage of the service’s lifecycle (reference [h]).	PR-L1-01
Requirements
The organisation providing the service should have an overall privacy policy/information charter. This policy defines the baseline privacy risk tolerance and appetite of the organisation. This document should be made available to the public.	PR-L1-02
An effective privacy management system should be in place to safeguard the private information collected. This includes an appointed executive level representative who can be held accountable for proper management of the private information.	PR-L1-03
Privacy requirements should be considered at the outset of the project to deliver the service. The private information to be held by the service should be explicitly identified. A PIA should be performed in accordance with Information Commissioner’s Office guidance (reference [i]). The assessment should consider all components of privacy from the perspective of the individual rather than the organisation. Compliance assessment with relevant legislation (e.g. Data Protection Act) should be performed.	PR-L1-04
The privacy risks identified should be effectively managed throughout the life of the service. The privacy risks will be one factor in determining the appropriate security levels for the different security components.	PR-L1-05
A privacy policy/Privacy Impact Assessment for the service should be placed in the public domain so that potential users of the service have access to it. Some of the information within the PIA report may be subject to security or commercial sensitivities. In such cases, it may be appropriate for the detailed information to be in restricted access Appendices.	PR-L1-06
The sharing of the private information within the organisation and with external organisations should be explicitly considered and measures required to manage the risks associated with this sharing put in place. Owners should be explicitly informed of the intention to share the information and who it is intended to share the information with. Permission to share the information should be required from the owners of the private information except where explicitly provided for by law.	PR-L1-07
The user should be provided with the ability to review, correct and withdraw their private information.	PR-L1-08
The service should be able to provide a subject, on request, a report that details the information held about them. Processes should be in place to enable any changes to that information to be made in order to maintain its accuracy.	PR-L1-09
Examples
Examples of services likely to fall into Level 1, include those that offer a shopping capability, where the user is offered the facilities to store payment details to facilitate future purchases.	PR-L1-10
Provision
Provision is likely to involve the use of standard features of commercially based systems.	PR-L1-11

Table 16 - Privacy Security Components at Level 1

Level 2 Privacy – Explicit	Reference
All aspects of authorisation at Level 1 are required, plus the following additional requirements:
The system, of necessity, collects and collates private information that can be directly linked to an individual or legal entity. Misuse of the information collected could be perceived as, or could actually be, detrimental to the well being of the users.	PR-L2-01
Requirements
A senior member of staff should be identified as the Information Asset Owner. The roles of the Information Asset Owner are defined the HMG Security Policy Framework (SPF) (reference [j]).	PR-L2-02
The service should be designed to minimise its privacy impact on prospective users. Privacy related objectives should be considered alongside business goals, and privacy considerations addressed at every stage of the service lifecycle.	PR-L2-03
The organisation providing the service should have an overall privacy policy/information charter. This policy should define the baseline privacy risk tolerance and appetite of the organisation. This document should be made available to the public.	PR-L2-04
An effective documented privacy management system should be in place to safeguard the private information collected. This should include an executive level representative appointed to be held accountable for proper management of the private information.	PR-L2-05
Privacy requirements should be considered at the outset of the project to deliver the service. The private information to be held by the service should be explicitly identified. A Privacy Impact Assessment (PIA) should be performed in accordance with Information Commissioner’s Office guidance (reference [i]). The assessment should consider all aspects of privacy from the perspective of the individual rather than the organisation. The PIA should be subject to independent review and be signed off by the executive responsible for privacy.	PR-L2-06
Independent audit of compliance with the Data Protection Act and other relevant legislation should be performed.	PR-L2-07
The privacy risks identified should be managed throughout the life of the service. The process for managing these risks should be documented. (The privacy risks will be one factor in determining the appropriate security levels for the different security components.)	PR-L2-08
A privacy policy/Privacy Impact Assessment for the service should be placed in the public domain so that potential users of the service have access to it. Some of the information within the PIA report may be subject to security or commercial sensitivities. In such cases, it may be appropriate for the detailed information to be in Confidential Appendices. Explicit details of the private information collected should be published and the purpose for which the information is collected should be explicitly defined. Details of the review, retention and deletion policy should be documented.	PR-L2-09
For on-line services, the user should maintain visibility of the private information that the service has collected directly from them. The user should be provided with the ability to review, correct and delete their private information.	PR-L2-10
The service should be able to provide a subject, on request, a report that details the information held about them. Processes should be in place to enable any changes to that information to be made in order to maintain its accuracy.	PR-L2-11
The policies should be fully resourced and effectively implemented. Compliance with the policies should be subject to regular independent review. Recommendations from the reviews and the actions it is proposed to take in response to any issues raised should be published.	PR-L2-12
The sharing of the private information within the organisation and with external organisations should be explicitly considered and measures required to manage the risks associated with this sharing put in place. Explicit permission to share the information will be required from the owners of the private information.	PR-L2-13
Any anonymisation of data performed should be subject to independent review by an appropriately qualified expert to ensure that the data has been effectively anonymised and is not susceptible to inference attacks. Removal of directly identifiable elements of records (e.g. user name, data of birth and address) may not be sufficient to ensure that the data is anonymous.	PR-L2-14
Accumulation and aggregation of data should not be performed. Where bulk data is held Level 3 privacy requirements should be met.	PR-L2-15
Access to the data should be strictly controlled and limited to those with a demonstrable need to know. Access rights should be minimised in respect of the following: a. The number of records accessible. The default should be: that any member of staff has no access to protected personal information. If access is necessary, it should be to the smallest possible subset of records; b. The numbers of records viewed. The hierarchy should be no access / ability to view only aggregated data / ability to view only anonymous records / ability to view material from single identifiable records / ability to view material from many identifiable records simultaneously; c. The nature of information available. The hierarchy should be responses to defined queries (e.g. does X claim free school meals) without seeing the record / view of parts of the record itself / view of the whole record; d. The functionality, including searching, alteration, deletion, printing, downloading or transferring information.	PR-L2-16
Audit, monitoring, and accounting procedures should be in place to enable the detection of possible abuses of access rights provided to service personnel. This should allow making arrangements to log activity of data users in respect of electronically held protected personal information, and for managers to check that logging is being properly conducted, with a particular focus on those working remotely and those with higher levels of functionality. Summary records of manager activity should be shared with the relevant Information Asset Owner and be available for inspection by the Information Commissioner’s Office on request. The organisation should have a forensic readiness policy in place to maximise their ability to preserve, analyse and use evidence from the system, should it be required.	PR-L2-17
Consideration should be given to any element of the service that holds private information that is to be carried out off-shore.	PR-L2-18
For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]) standards or guidance should be applied as specified by their business.	PR-L2-19
Examples
Public sector services that fall into this category include those where users may be identified and the actions recorded. The actions themselves have little significance to others. They include for example, applying for a motor vehicle tax disk, booking a driving test or registering a vehicle with DVLA.	PR-L2-20
Care would be needed with anything that could reveal a user’s contact details and this would be seen as a serious breach of privacy even though the information itself is not particularly sensitive. Some individuals have a legitimate expectation that their location information is not made generally available.	PR-L2-21
Provision
A significant element of the required privacy controls will be implemented through personnel, physical and procedural controls. Technical controls are likely to exploit the standard security features of commercial based products (e.g. role based access controls to records).	PR-L2-22

Table 17 - Privacy Security Components at Level 2

Level 3 Privacy – Protected	Reference
All aspects of authorisation at Level 2 are required, plus the following additional requirements:
Level 3 privacy requirements are applicable for systems holding bulk private data which is, of necessity, collected and collated.	PR-L3-01
Requirements
The service should be conceived and designed to minimise its privacy impact on prospective users. Privacy-related objectives should be considered alongside business goals, and privacy considerations addressed at every stage of the service’s lifecycle. The system should be explicitly designed and implemented to counter the threat of internal staff abusing their access to the system.	PR-L3-02
The organisation providing the service should have an overall privacy policy/information charter. This policy should define the baseline privacy risk tolerance and appetite of the organisation. This document should be made available to the public.	PR-L3-03
A documented privacy management system should be in place to safeguard the private information collected. This should include appointment of an executive level representative to be held accountable for proper management of the private information.	PR-L3-04
Privacy requirements should be considered at the outset of the project to deliver the service. The private information to be held by the service should be explicitly identified. A rigorous detailed Privacy Impact Assessment (PIA) should be performed. The assessment should consider all aspects of privacy from the perspective of the individual rather than the organisation. The physical, personnel, procedural and technical controls required should be identified. Systemic issues should be explicitly addressed. The PIA should be subject to independent review and be signed off by the executive responsible for privacy.	PR-L3-05
Independent external assessment of the service compliance with the Data Protection Act and other relevant legislation should be performed.	PR-L3-06
The privacy risks identified should be effectively managed throughout the life of the service. These risks will be one factor in determining the appropriate security levels for the different security components.	PR-L3-07
A privacy policy/PIA for the service should be placed in the public domain so that potential users of the service have access to it. Some of the information within the PIA report may be subject to security or commercial sensitivities. In such cases, it may be appropriate for distribution of detailed information to be limited. Explicit details of the private information collected should be published. The purpose for which the information is collected should be explicitly defined and details of the review, retention and deletion policy should be published. The criteria for retention and deletion of data should be explicitly defined.	PR-L3-08
The policies should be fully resourced and effectively implemented. Compliance with the policies should be subject to regular independent review by an appropriate qualified external organisation. Recommendations from the reviews and the actions it is proposed to take in response to any issues raised should be published.	PR-L3-09
The sharing of the private information within the organisation and with external organisations should be explicitly considered and measures required to manage the risks associated with this sharing put in place.	PR-L3-10
Permission of the information owner should be obtained before information is released to an external organisation. Explicit confirmation that the external partners will provide the required protection to the information should also be obtained.	PR-L3-11
Granular, strong access control measures should be implemented to protect the data. Records should be marked with an access control list and a trusted mechanism used to enforce the controls defined. Access should be restricted to only those with legitimate requirement.	PR-L3-12
Access rights should be minimised in respect of each of the following: a. The number of records accessible. The default should be that any member of staff has no access to protected personal information. If access is necessary, it should be to the smallest possible subset of records; b. The numbers of records viewed. The hierarchy should be: no access / ability to view only aggregated data / ability to view only anonymous records / ability to view material from single identifiable records / ability to view material from many identifiable records simultaneously; c. The nature of information available. The hierarchy should be responses to defined queries (e.g. does X claim free school meals) without seeing the record / view of parts of the record itself / view of the whole record; d. The functionality, including searching, alteration, deletion, printing, downloading or exporting information.	PR-L3-13
Strict controls should be in place to prevent inappropriate aggregation by Service Provider staff.	PR-L3-14
Access to individual records should cause an audit trail to be produced that includes who accessed the record and the date and time of the access. An audit trail should also be kept of all deletions.	PR-L3-15
Monitoring and accounting procedures should be in place to enable the detection of possible abuses of access rights provided to service personnel. Alerting functionality should be considered for particular sensitive records. Inappropriate access should be treated as a disciplinary offence.	PR-L3-16
The service should be able to provide a subject, on request, a report that details the information held about them. Details of those with access to the record should be provided to the user on request. Processes should be in place to enable any changes to that information to be made in order to maintain its accuracy.	PR-L3-17
Any anonymisation of data performed should be subject to independent review by appropriately qualified experts to ensure that the data has been effectively anonymised and that effective measures to prevent inferences about a subject being drawn are in place (including identification of information not present in the data set). This includes reviewing any pseudonyms used to ensure that actual identities cannot be deduced. The risks associated with cross correlation of anonymised data should be carefully considered and adequately addressed. Removal of directly identifiable elements of records (e.g. user name, data of birth and address) may not offer sufficient protection.	PR-L3-18
The technical security measures in place to enforce the privacy controls should be subject to independent evaluation by appropriate technical experts.	PR-L3-19
Examples
Examples of systems that fall within this category include centralised electronic health record systems and centralised tax record systems.	PR-L3-20
Provision
Provision of services is likely to require privacy preserving top down design and implementation. Research in the design and implementation of effective systems is currently on-going and specialist security advice will be required. Implementations illustrating possible approaches to meeting the requirements include: a. The pilot implementation of the BMA Security policy for a hospital system for Hastings that was developed in 1995 reference [k]. Lessons learnt from the implementation are discussed in reference [l]. b. NHS Connecting for Health’s work on the electronic patient record. Their approach provided role based access controls. In order to access patient data a staff member should have a ‘legitimate relationship’. In addition, a patient may declare part of their records to be ‘sealed’ or ‘sealed and locked’ further restricting access. In the first case, the sealed element of the record will be available to a particular care team, the existence of the sealed elements of the record will be visible to those with a legitimate relationship to the patient. In an emergency they will be able to break the seal and see the details. In the latter case the part of the record that has been sealed and locked will only be visible to the particular care team reference [m].	PR-L3-21

Table 18 - Privacy Security Components at Level 3

3. Server Components

Key Principle

• Covers the application server security environments

Introduction

Server Security Components are those concerning application server environments. This section discusses these security components under the headings of:

a. Information Access – covering the unauthorised observation and manipulation of information. Levels defined increase with information sensitivity. Requirements, examples and provision guidance are provided.

b. Information Availability – covering the means by which assurance is obtained. Reliability aspects are not covered. These components cover server Confidentiality and Availability concerns. Integrity issues are considered within the Business Logic components. Requirements, examples and provision guidance are provided.

Information Access

Access related services address the unauthorised observation and manipulation of information that is received, stored, processed or disposed of within the server environment.

Four levels of access protection are defined that represent increasing levels of protection.

he organisational, personnel and physical security requirements of the organisations managing the servers are described in the Assurance Security Components.

Level 0 Information Access – No Specific Measures	Reference
Level 0 is appropriate where none of the information handled in the server environment has any sensitivity and is therefore not subject to any formal access control policy except that required to ensure service continuity and data integrity.	IACC-L0-01
Privacy requirements should always be met. Level 0 will not be appropriate if private information is collected by the system.	IACC-L0-02
While private information is not being collected at this level, care should still be taken in designing the service to ensure that all malicious code insertion type attacks (e.g. SQL injection, cross site scripting) vulnerabilities have been considered to limit the opportunity for an attacker to exploit the service.	IACC-L0-03
Requirements
There are no explicit requirements to provide information access protection within the server environment beyond those required to ensure service continuity and integrity. Care should still be taken to adopt good system practice.	IACC-L0-04
Examples Web services providing information to the general public may represent a service that may not require information access protection (though they may need higher levels of write access control to ensure data integrity and business continuity).	IACC-L0-05
Provision
Standard commercial products are likely to be used to provide the required services. These will be configured and operated in accordance with normal good system practice. While no formal access controls are required to meet information access requirements, it should be noted that controls will be required to ensure the Integrity and Availability of the system.	IACC-L0-06

Table 19 – Information Access Security Components at Level 0

Level 1 Information Access – Self Assessed Commercial	Reference
All aspects of information access at Level 0 are required, plus the following additional requirements:
At Level 1 the information processed and stored within the server environment will have some access limitations but will not attract a national protective marking. The impact of information disclosure is minimal. It is not appropriate where the server contributes to a service that attracts a Level 2 or 3 Privacy requirements.	IACC-L1-01
Requirements
Appropriate organisational, personnel, physical and procedural controls should be in place to ensure the secure operation of the servers within the environment. The Assurance Security Component gives more details of the requirements.	IACC-L1-02
The design, configuration and operation of the system should be subject to review to ensure its secure operation. Self-assessment is acceptable at this level. The Assurance Security Component gives more details of the requirements.	IACC-L1-03
The whole life cycle of the assets should be considered when determining the measures necessary to protect them. This includes putting appropriate measures in place to ensure their secure disposal (including the physical systems and media holding the data).	IACC-L1-04
The system should offer access controls. These access controls should be configured to minimise the information and services and that users have access to those necessary for them to perform their jobs effectively.	IACC-L1-05
User registration and authorisation requirements for the back-office staff should be at least as stringent as those for the users of the service.	IACC-L1-06
Users should be granted the minimum privileges necessary to perform their function. Privileged accounts should only be used by a user or administrator when performing functions that demand elevated privileges.	IACC-L1-07
Access to the system should be via a secure logon process. The authentication requirements detailed earlier should be satisfied.	IACC-L1-08
Access credentials issued should be unique to a particular user. Users should be instructed not to share credentials. Where shared credentials should be used to support for example, shift based working, other mechanisms should be in place to ensure activities can be traced to a specific individual.	IACC-L1-09
Processes should be in place to regularly review the list of users with access to the system to ensure that all users with current access have a current business need.	IACC-L1-10
Users should successfully authenticate themselves to the system before being able to access it. The type and strength of credential required should be determined in accordance with the guidance provided on Authentication.	IACC-L1-11
The system should be hardened in line with commercial good practice. The services running on the system should be the minimum necessary to meet the business need.	IACC-L1-12
A patch management process should be in place. This should ensure that patches to fix security vulnerabilities are tested and rapidly applied to the operational system.	IACC-L1-13
Applications and utilities available on the system should be the minimum necessary to meet the business need.	IACC-L1-14
Import and export controls should be in place. Only information object types that can be reasonably expected to be required to meet the business needs should be permitted to be imported on the system. Imports and exports should be examined to confirm compliance with the policy and to confirm that they do not contain malicious content. A defined process should be documented for handling any malicious content received.	IACC-L1-15
Server side validation of data input by services users should be performed to confirm that it conforms to expectations before being used to generate further outputs. Invalid data entry should be trapped and handled in a secure manner. Explicit consideration of malicious code insertion type attacks (e.g. SQL injection, cross site scripting) vulnerabilities should be given when designing the service.	IACC-L1-16
Backup and archive data should be stored so that only authorised users have access to it.	IACC-L1-17
The system should be designed to minimise the retention of sensitive information on untrusted client access devices.	IACC-L1-18
An incident response plan should be in place. The incident response plan should cover: a. The assessment processes to assess the impact of an incident; b. Processes required ensuring the controlled close down of elements of the system and controlled recovery processes to be followed.	IACC-L1-19
This plan should be regularly tested to maintain its effectiveness.	IACC-L1-20
Examples
Services that fall into this category are those for which the impact of disclosure of information is likely to be minimal. An example might be a service which enables a client to make an application or initiates a transaction that will be completed on the basis of a paper form. The service that allows the user to create and populate an electronic facsimile of the paper form will contain personal information that should be protected, but the information is only temporarily stored while the application is completed and is deleted on completion of the application (e.g. on-line completion of a passport application form).	IACC-L1-21
Provision
At Level 1, commercial products are likely to be used to meet the requirements. The in-built security features of these products are likely to be sufficient to meet the security needs. The products will be configured and hardened in line with commercial good practice. For example, Windows Servers will be hardened in line with Microsoft hardening guidance (reference [n]). Servers will be segregated in line with commercial good practice.	IACC-L1-22
Access rights granted to users will be the minimum necessary to perform their business function. Only a minimum number of users will be granted administrative rights.	IACC-L1-23
Standard system-provided activity monitors are likely to be used to regularly confirm that the system is operating in accordance with its expected parameters and to enable any suspicious activity or patterns of activity to be identified. Standard system-provided accounting logs will be reviewed by appointed security personnel for the system to ascertain whether there is any activity or pattern of activity that might indicate an unexpected electronic attack on the system. Account logs are likely to be reviewed at least monthly. Alerts are likely to be configured for critical events to ensure timely response.	IACC-L1-24
Standard commercial tools will be used to check that the servers are correctly configured and that known vulnerabilities have been addressed. Automated tools are likely to be used to update the systems within the server environment. Product supplier websites, GovCertUK and other security bulletin boards are likely to be actively monitored to maintain awareness of potential server vulnerabilities.	IACC-L1-25
Overall compliance with the security policy is likely to be audited at least annually.	IACC-L1-26

Table 20 – Information Access Security Components at Level 1

Level 2 Information Access – Assessed Commercial	Reference
All aspects of information access at Level 1 are required, plus the following additional requirements:
At Level 2 the information stored has access control requirements and may attract a protective marking of PROTECT (in lower risk environments). Impact of disclosure of the information is likely to be largely reputational with limited potential for individual harm. Bulk data loss may however have significant implications.	IACC-L2-01
Requirements
All Level 1 Information access requirements apply at Level 2. There are number of areas in which stronger controls are required. These are as follows:	IACC-L2-02
This document set does not mandate or recommend a specific risk management method, approach or process to be followed in order to identify the risks to be managed. It is recognised that in order to gain as complete as possible view of the risks to an online service it is likely that a number of different risk assessment approaches will need to be considered. The exception to this is where HMG Departments and Agencies are mandated to use the HMG Security Policy Framework (SPF) (reference [j]).	IACC-L2-03
Equipment should be sited or protected to reduce the risks of unauthorised access. This includes providing protection of Confidential information displayed on screens.	IACC-L2-04
Equipment, information or software should not imported or be taken outside the secure environment without prior authorisation.	IACC-L2-05
Any equipment taken outside the secure environment should be secured to account for the different risks associated with this.	IACC-L2-06
Information written to media or printed out should be afforded an appropriate level of protection using physical, procedural and/or technical measures.	IACC-L2-07
Strict controls should be in place to ensure that backup and archive material may only be accessed by authorised personnel.	IACC-L2-08
Access controls should be used to minimise information accessible to a user to the minimum necessary to enable them to effectively perform their business role.	IACC-L2-09
Data at rest or in transit should be protected by products with a CESG Commercial Products Assurance (CPA) scheme certification (reference [o]). However, Common Criteria EAL 3 products would also be suitable at this level.	IACC-L2-10
All items of equipment containing storage media should be checked to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal.	IACC-L2-11
Before any user of the server environment (e.g. system administrator, back-office staff) is allowed to access the system: i. Their identity should be verified; ii. Their business need to access the system should be confirmed; iii. They should have received appropriate training including security training; iv. They should have signed to confirm that they understand the relevant security policy and procedures and that they will abide by those procedures.	IACC-L2-12
User rights to transfer data to removable media should be carefully considered and strictly limited to ensure that this is only provided where absolutely necessary for business purposes and subject to monitoring by managers.	IACC-L2-13
Information import, export and disposal should be actively managed to minimise the information security risks. A risk assessment and business case should be produced for all import and export information types to be allowed. Import and exports resulting in high risks should not be allowed without a strong business case justifying their use to being produced. This should be signed off by the Accreditor for the service.	IACC-L2-14
Import and export controls should be in place. Imports should be scanned to confirm compliance with the import policy and to confirm that they do not contain a virus or other malicious content. Exports should be scanned to ensure that the export policy is complied with.	IACC-L2-15
Applications capable of processing imported material should be configured to do so safely. For example, word processing and spreadsheet applications should disallow automatic macro execution without prior user permission. E-mails should not lead to the automatic download of objects. Free form user input should be pre-processed to eliminate vectors for attacks such as SQL injection, XSS, etc.	IACC-L2-16
Applications used to export data should be configured to do so safely. For example, ‘hidden text’ in word processing documents should be revealed to the user or removed before export.	IACC-L2-17
Audit and accounting requirements are similar to Level 1, however, accounting logs should be afforded a higher level of protection and audits should be performed on a more regular basis. Automated analysis tools should be used to support the analysis of accounting data. Audit and accounting should meet at least the requirements of the Level 1 Situation Awareness Security Component. Audit and accounting logs should be protected to at least Information access and Internal Accountability levels 1.	IACC-L2-18
Host based intrusion detection/prevent 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 activity that might indicate an electronic attack is being conducted.	IACC-L2-19
All import requests should be recorded to meet specified audit requirements and to enable trend analysis to be performed.	IACC-L2-20
The system design and security documentation should be subject to independent review by appropriate security experts. At least Level 1 Technical and Organisational Assurance are expected (see the Assurance Security Component for more details of the requirement). Appropriate action should be taken to address any significant issues identified by these reviews.	IACC-L2-21
Prior to the service going live an independent IT security health check should be performed by appropriate experts. Once the service has gone live independent IT security health checks should be performed after any significant change in system configuration and periodically (period to be agreed with the Accreditor) to confirm that the system remains secure. At least Level 1 Technical and Organisational Assurance are expected (see the Assurance Security Component for more details of the requirements).	IACC-L2-22
Examples
Examples of services that fall into this category are those that store private information that has little significance to others but whose unintended release would be embarrassing. They include for example, applying for a motor vehicle tax disk, booking a driving test or registering a vehicle with DVLA.	IACC-L2-23
Care would be needed with anything that could reveal a users contact details as this would be seen as a serious breach of privacy, even though the information itself is not particularly sensitive.	IACC-L2-24
Provision
Provision of the services at Level 2 is similar to that at Level 1. The main areas of difference are that: a. Products providing key elements of the security enforcing functionality should have been certified using the CESG CPA certification to at least foundation grade, see CESG website guidance (reference [p]). b. For those mandated to do so, the security documentation produced is to be in accordance with SPF (reference [j]). For those not mandated to use the SPF, standards or guidance should be applied as specified by their business. c. Audit and accounting should be performed on a regular basis. Accounting logs are likely to be reviewed at least weekly. Alerts will be configured for critical events to ensure timely response. d. The configuration of the system will have been subject to independent audit by relevant security experts (e.g. CHECK (reference [p]) or CREST (reference [q] approved providers). e. Compliance reviews of the system with security policy will be performed at least annually.	IACC-L2-25

Table 21 – Information Access Security Components at Level 2

Level 3 Information Access – Assessed Government	Reference
All aspects of information access at Level 2 are required, plus the following additional requirements: At Level 3 the information stored has strong access control requirements and may attract a protective marking of PROTECT (in higher risk environments) or RESTRICTED for subsets of the data or in bulk. The impact of unwarranted access is likely to be significant with scope for individual harm. Bulk data exposure could carry significant reputational and business impact.	IACC-L3-01
Requirements
All Level 2 access control requirements apply at Level 3 as well. There are number of areas where stronger controls are required. These are as follows:	IACC-L3-02
User registration and authorisation requirements for the back-office staff will be at least as stringent as those for the users of the service.	IACC-L3-03
Segregation of duties should be implemented between those with security responsibilities and those with system administration responsibilities.	IACC-L3-04
The servers should be hardened in line with Government good practice. A risk assessment and business case should be produced for all services which it is proposed to run in the server environment.	IACC-L3-05
Import and export controls should limit imports and exports to only those information object types that can be explicitly justified. A risk assessment and business case should be produced for all import and export requirements.	IACC-L3-06
Strict controls should be in place to protect data at rest to ensure that it may only be accessed by authorised personnel. If encryption is used, a CESG approved product should be used. This should be configured and operated with its agreed security operating procedures. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), standards or guidance should be applied as specified by their business.	IACC-L3-06
Disposal of data should be performed. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF, standards or guidance should be applied as specified by their business.	IACC-L3-07
Strong accounting and auditing is required. It should be sufficient to ensure that all users can be held accountable for their actions. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), standards or guidance should be applied as specified by their business.	IACC-L3-08
Level 2 or Level 3 Situational Awareness should also have been implemented. The capability to carry out display and detailed data mining and analysis of accounting records should have been provided.	IACC-L3-09
The system design and security documentation should be subject to independent review by appropriate security experts. Level 2 Technical and Organisational Assurance is expected (see the Assurance Security Component for more details of the requirement). Appropriate action should be taken to mitigate any significant issues identified by these reviews.	IACC-L3-10
Prior to the service going live an independent IT security health check should be performed by appropriate experts. Once the service has gone live independent IT security health checks should be performed after any significant change in system configuration and periodically (period to be agreed with the Accreditor) to confirm that the system remains secure. Level 2 Technical and Organisational Assurance is expected (see the Assurance Security Component for more details of the requirements).	IACC-L3-11

Examples
Example services for which Level 3 information access is appropriate include: a. Electronic filing of income tax and Value Added Tax (VAT) returns; b. Services that give access to sensitive private information, for example a personal medical record.	IACC-L3-12
Provision
Provision of the services at Level 3 is similar to that at Level 2. The main areas of difference are as follows:	IACC-L3-13
All personnel with physical access to the system are likely to have been vetted in accordance with Baseline Personnel Security Standard (BPSS) requirements (or equivalent). Personnel with more privileged access, e.g. system administrators, are likely to have been subject to Security Check (SC) vetting.	IACC-L3-14
The location at which the servers are located is likely to be a site approved for handling protectively marked information.	IACC-L3-15
Boundary protection devices, network devices and servers will all be hardened in accordance with HMG IA good practice. The approach adopted involves disabling all services and then enabling the minimum set of services required in order to meet the business requirements.	IACC-L3-16
Network zoning is likely to be used to support data separation and support access control restrictions.	IACC-L3-17
Network based intrusion detection systems are likely to have been deployed at key nodes with the server environment. Host based intrusion detection systems are likely to have been implemented on critical servers.	IACC-L3-18
Incident response procedures will have been established. A fully resourced computer incident response team is likely to have been stood up. Incident recovery procedures, controlled close down, impact assessment and recovery procedures will be documented and regularly tested. Incidents would typically be reported to GovCertUK and the Comsec Incident Notification, Reporting and Alerting Scheme (CINRAS).	IACC-L3-19
The system design and security documentation is likely to have been subject to independent review by CESG, CESG Listed Advisor Scheme (CLAS) Consultants or CESG Tailored Assurance Scheme (CTAS) approved supplier and appropriate action taken to mitigate any significant issues identified. The service configuration is likely to be subject to regular independent health check by CESG, a CHECK approved supplier or a CTAS approved supplier, see CESG website guidance (reference [p]). This will be at least annually and after any significant system configuration change.	IACC-L3-20

Table 22 – Information Access Security Components at Level 3

Information Availability

This security component covers the means by which assurance is obtained and that access to information and resources cannot be withheld in an unauthorised manner. This section does not address reliability aspects in general, its specific focus is denial of authorised access to resources as a result of malicious activity and the susceptibility of systems and services to such threats.

The organisational, personnel and physical security requirements of the organisations managing the servers are described in the Assurance requirements.

Level 0 Information Availability – No specific Measures	Reference
No explicit specific requirements for controls to be required to block Denial of Service (DoS) attacks over and above reasonable expectations of continuing service delivery.	IAVA-L0-01
The reputational issues should be considered in the attention given to availability. Though the damage to the individual requesting the service may be minimal, the impact of failure to address susceptibility to attack may damage the credibility of the service provision.	IAVA-L0-02
Requirements
Normal good system practice should be adopted in respect of designing, implementing and managing the system. It is likely that at Level 0 no explicit availability measures are necessary.	IAVA-L0-03
No special measures need be taken to ensure data backup or continuity of service following an interruption to service. In particular, no special measures need to be taken to recover partially completed transactions, other than for those that affect the integrity of existing information.	IAVA-L0-04
Examples
Examples of transactions that might merit Level 0 availability services include: c. A client reads or downloads publicly available information from a public sector website. Unavailability of the information would cause at most minimal inconvenience to the client, who could attempt to access the information at a later date. d. A client e-mails a public sector organisation with a request for general information and expects the material to be returned via email. Failure of the service would cause the client to experience at most minimal inconvenience. The client could re-submit the request at a later date.	IAVA-L0-05
Provision
Standard commercial products are likely to be used to provide the required services. These will be configured and operated in accordance with normal good system practice.	IAVA-L0-06

Table 23 – Information Availability Security Components at Level 0

Level 1 Information Availability – Commercial	Reference
All aspects of information availability at Level 0 are required, plus the following additional requirements:
At Level 1 attention needs to be paid to hardening the servers against DoS attacks but the service criticality is not such as to justify bespoke measures or severe restrictions on service delivery.	IAVA-L1-01
Standard commercial good practice is sufficient to ensure that the system meets its Service Level Agreement (SLA). A guaranteed process exists for recovering the service in the event of a service outage.	IAVA-L1-02
Requirements
Personnel, procedural, physical and access controls that meet the requirements of the Level 1 Information Access Security Component are expected to be in place.	IAVA-L1-03
A good commercial system architecture design should be used. Fault tolerant components are likely to be used to ensure service availability (e.g. redundant processor configurations, RAID arrays, redundant power supplies) although they are not mandated.	IAVA-L1-04
The design, implementation and operation of the system should be subject to independent review. At least Level 1 Organisational Assurance and Technical Assurance are expected at this level.	IAVA-L1-05
SLA’s for externally provided services should be set to meet the availability requirements (including transaction availability).	IAVA-L1-06
Careful consideration should be given to sizing of the communications and information servers so as not to compromise availability. The sizing should be based on realistic estimates of demand for the service.	IAVA-L1-07
Alternative communications paths that can be switched in within the timescale appropriate to the business need should be available.	IAVA-L1-08
Uninterrupted Power Supply (UPS) should be provided to allow ‘soft’ failure with power recovery achievable within a timescale appropriate to the business need.	IAVA-L1-09
A configuration management plan and processes covering the communications and information systems providing the service should be designed and implemented.	IAVA-L1-10
Formal configuration and change management processes should be in place. Configuration changes should be approved by the system manager before implementation and should be subject to secure audit (technical or procedural). Software should only be introduced with the approval of the system manager and a full inventory of all hardware and software and a network diagram showing all approved connections should be maintained.	IAVA-L1-11
A failure impact analysis should be carried out and recorded for all information and communication system components. This should be reviewed in the event of significant configuration changes. No upgrades should be permitted without prior assessment.	IAVA-L1-12
A controlled connection closedown process should exist that allows essential business processes to be maintained in the presence of significant DoS attacks.	IAVA-L1-13
A process should be available to provide access in the event of loss of a password, access token or cryptographic key.	IAVA-L1-14
A business continuity plan should be in place and subject to regular review and testing. The plan should address: a. Management roles and responsibilities for business continuity; b. Recovery procedures and audit trail; c. Security specific recovery actions.	IAVA-L1-15
Backups should enable restoration of all relevant information to be recovered within a time window required by the business need. The backup and restoration process should be documented.	IAVA-L1-16
Cryptographic checksums or secure software isolation for system software, configuration data and storage facilities should be provided. The backup should be compared against the original before the backup media is stored offsite. The restoration process should be documented and tested regularly. A secure self-test process should be undertaken regularly using these facilities.	IAVA-L1-17
Commercial good practice self test processes should be in place to enable the health of the system to be validated.	IAVA-L1-18
Audit and accounting should be performed in accordance with Level 1 or higher Situational Awareness Security Component.	IAVA-L1-19
The service levels provided by the service should be regularly reviewed to confirm that the SLA’s are being met. System performance and usage should be monitored to ensure continued service availability and to enable future service needs to be anticipated.	IAVA-L1-20
Examples
Level 1 availability is likely to apply to the majority of e-Government services for which short term unavailability of service or information is an inconvenience to users; though unlikely to cause harm but where the reputation of the department might be undermined if the service is seen as vulnerable to attack.	IAVA-L1-21
Provision
Provision of the service is likely to involve the use of standard commercial products. A degree of fault tolerance will be implemented through the use of standard commercial products (e.g. server clustering, use of servers with redundant components, use of UPS, RAID, etc.). Specialist, high availability fault tolerant components are unlikely to be necessary at this level.	IAVA-L1-22
Access rights granted to users will be the minimum necessary to perform their business function. Only the minimum number of users will be granted administrative rights. Access rights will be kept under review and updated when user requirements change.	IAVA-L1-23
Import controls are likely to be based on blacklisting. Procedural controls are likely to be used to control the import of objects from media (e.g. CDs, USB). Mail and other electronic imports are likely to be screened automatically at the gateway to the system. Dangerous file types (e.g. executables) are likely to be automatically blocked or quarantined at the gateway. The list of file types to be blocked or quarantined is likely to be based on a blacklisting approach. Data that is likely to be reasonably required by the business will be allowed by default.	IAVA-L1-24
The communications across the gateway will be minimised to those that are reasonable required by the business. Filtering technology is likely to be used to remove SPAM, SPIT and SPIM. All imported and exported objects will be subject to anti-virus scanning using a commercial anti-virus product. An anti-virus strategy will be in place to ensure the timely update of anti-virus signatures.	IAVA-L1-25
Standard system provided activity monitors are likely to be used to regularly confirm that the system is operating in accordance with its expected parameters and to enable any suspicious activity or patterns of activity to be identified. In addition to automated scanning, standard system-provided accounting logs will be reviewed by appointed security personnel for the system to ascertain whether there is any activity or pattern of activity that might indicate an unexpected electronic attack on the system. Account logs are likely to be reviewed at least monthly. Alerts are likely to be configured for critical events to ensure a timely response. Accounting logs will be retained to enable a record of transaction times and record changes. Access to the logs will be controlled to minimise the risk of tamper.	IAVA-L1-26

Table 24 – Information Access Security Components at Level 1

Level 2 Information Availability – Critical	Reference
All aspects of information availability at Level 1 are required, plus the following additional requirements:
At Level 2 there is a requirement for specific attention to be paid to hardening the servers against DoS attacks, possibly at the cost of reduced provision of richer functionality in the interest of reducing the attack ‘surface’.	IAVA-L2-01
Requirements
Personnel, procedural, physical and access controls that meet the requirements of the Level 2 Information Access Security Component are expected to be in place.	IAVA-L2-02
The availability requirements should be set to be compatible with the assessment of the business need. SLA’s for externally provided services should be set to meet the availability requirements (including transaction availability).	IAVA-L2-03
A good commercial system architecture design should be used. This will have been designed to prevent, detect and tolerate some level of malicious and non-malicious attack.	IAVA-L2-04
The design, implementation and operation of the system should be subject to independent review. At least Level 2 Organisational Assurance and Technical Assurance are expected at this level.	IAVA-L2-05
The system design and security documentation should be subject to independent review by appropriate security experts. Level 2 Technical and Organisational Assurance is expected (see the Assurance Security Component for more details of the requirement). Appropriate action should be taken to mitigate any significant issues identified by these reviews.	IAVA-L2-06
Prior to the service going live an independent IT security health check should be performed by appropriate experts. Once the service has gone live independent IT security health checks should be performed after any significant change in system configuration and periodically (period to be agreed with the Accreditor) to confirm that the system remains secure. Level 2 Technical and Organisational Assurance is expected (see the Assurance Security Component for more details of the requirements).	IAVA-L2-07
Failure impact analysis should have been carried out and recorded for all information system and communication components. This should be reviewed in the event of significant configuration changes.	IAVA-L2-08
Careful consideration should be given to sizing of the communications and information systems. The sizing should be based on realistic estimates of demand.	IAVA-L2-09
User registration and authorisation requirements for the back-office staff will be at least as stringent as those for the users of the service.	IAVA-L2-10
Segregation of duties should be implemented between those with security responsibilities and those with system administration responsibilities.	IAVA-L2-11
A configuration management plan and processes covering all the elements within the server environment should be in place. Configuration changes should be approved by the system manager before implementation and should be subject to full testing before they are applied to the operational system, including security testing. Software should only be introduced with the approval of the system manager and a full inventory of all hardware and software and a network diagram showing all approved connections should be maintained. Introduction of new software should be subject to full testing (including security testing) within the test environment before being applied to the operational system.	IAVA-L2-12
A configuration management plan and processes covering all the elements within the server environment should be in place. Configuration changes should be approved by the system manager before implementation and should be subject to full testing before they are applied to the operational system, including security testing. Software should only be introduced with the approval of the system manager and a full inventory of all hardware and software and a network diagram showing all approved connections should be maintained. Introduction of new software should be subject to full testing (including security testing) within the test environment before being applied to the operational system.	IAVA-L2-13
Server environments should be configured to enforce access controls and limit exposure only to applications with a specific operational business function. Access control should be configured to ensure that user access is limited to the services for which they have a need to know. The servers should be hardened in line with Government good practice. A risk assessment and business case should be produced for all services it is proposed to run in the server environment.	IAVA-L2-14
Import controls should limit import to only those that can be explicitly justified. A risk assessment and business case should be produced for all import requirements.	IAVA-L2-15
Strong accounting and audit is required. This should be sufficient to ensure that all users can be held accountable for their actions. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [d]), standards or guidance should be applied as specified by their business.	IAVA-L2-16
Level 2 or Level 3 Situational Awareness should also have been implemented. The capability to carry out display and detailed data mining and analysis of accounting records should have been provided.	IAVA-L2-17
Back up and archive of data should be performed. This should enable restoration of all relevant information to within a period determined by the business need.	IAVA-L2-18
The backup should be compared against the original before the backup media is stored offsite. The restoration process should be documented in the business continuity plan and tested regularly.	IAVA-L2-19
Baseline level cryptographic checksums or secure software isolation for system software, configuration data and storage facilities should be provided. A secure self-test process should be undertaken regularly using these facilities.	IAVA-L2-20
Service performance and usage should be monitored to ensure it is operating within expected parameters and to enable future service requirements to be anticipated.	IAVA-L2-21
A commercial good practice self test process should be in place to enable the health of the service to be confirmed.	IAVA-L2-22
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: a. Management roles and responsibilities for business continuity; b. Recovery procedures and audit trail, covering the system, communications and transactions; c. Security specific recovery actions.	IAVA-L2-23
Examples
Examples of services that fall into this category are those for which penalties exist for late provision of data to Government, such as electronic filing of income tax returns, PAYE returns and Value Added Tax (VAT) returns.	IAVA-L2-24
Provision
Commercial good practice for a critical service is likely to be followed. The architecture for the system will have been designed to prevent, detect and tolerate some level of malicious and non-malicious attack. This could include, e.g. use of boundary protection devices, import filtering, hardened operating systems and network components. To minimise the attack ‘surface’. Multi-tier, high redundancy architectures (e.g. redundant processor configurations, mirrored disks, RAID arrays) and geographical distribution are likely to be exploited. Hot or warm stand-by systems may be needed to meet the business need. Alternative communications paths with immediate failover may also be necessary.	IAVA-L2-25

Table 25 – Information Access Security Components at Level 2

4. Network Components

Key Principle

• Covers the network security measures necessary to protect information in transit between the online public service and the user of the service

Introduction

The Network Security Components cover the measures necessary to protect information in transit between the online public service and the user of the service. Four aspects of security are considered within this area, namely:

a. Communications Security;

b. Network Authentication;

c. Network Protection;

d. Situational Awareness.

Communications Security

Communication security covers the measures by which assurance is gained that observation or modification of information cannot occur in transit to and from the servers used to host the service. It typically relates to the requirements for encryption of communication links.

The organisational, personnel and physical security requirements of the organisations managing the network are described in the Organisational Assurance Security Component.

Four levels of communications security are defined.

Level 0 Communications Security – No specific Measures	Reference
At Level 0 there are limited requirements for technical communication security measures. This could be because the information to be exchanged over the network is not sensitive. Alternatively it could be because strong physical, procedural and personnel controls are in place and provide adequate protection.	CS-L0-01
Requirements
At Level 0 there are no explicit communications security requirements.	CS-L0-02
Examples
Examples of transactions that might merit Level 0 Communications security defence include: a. A client reads or downloads publicly available information from a public sector web site. b. A client e-mails a public sector organisation with a request for general information and expects the material to be returned via e-mail. Electronic attack resulting in, for example, loss of integrity of the information might result in minimal inconvenience or loss of time to the client, but no serious consequences such as risk to safety.	CS-L0-03
Provision
At Level 0 there are limited requirements for technical communications security measures. This could be because the information is nonsensitive, the physical, procedural and personnel security measures provider by the network provider are sufficient to meet the security requirements or because the information is protected at the transaction level.	CS-L0-04

Table 26 – Communications Security Components at Level 0

Level 1 Communications Security – Limited	Reference
All aspects of communications security at Level 0 are required, plus the following additional requirements: At Level 1 the threat and vulnerability analysis leads to a requirement for explicit communication security measures to be implemented. The analysis does not however identify a requirement for strong measures that are able to resist a highly capable attacker.	CS-L1-01
Requirements
Communications across the network should be encrypted to protect their Confidentiality and Integrity.	CS-L1-02
Examples
Example of service that might attract Level 1 communications security measures include: a. A client arranges a meeting with a public sector official by e-mail. The impact of loss of Confidentiality or Integrity or other consequences of electronic attack is inconvenience and lost time, possibly minor financial loss, but no lasting impact on either party. b. A client requests medical appointments which are considered personal and need clinical Confidentiality. c. A client purchases a low cost public sector publication over the Internet. The impact of malicious electronic attack to attribute the purchase to the wrong client, or to alter the number of copies ordered, for example, would be inconvenience and possibly refunding or recovering incorrect payments.	CS-L1-03
The most significant threats to the service at this level are anticipated to come from opportunistic attackers and from threat sources with some IT knowledge and the resources to implement simple network attacks only. Most capable attackers are assumed not to be motivated to attack the service.	CS-L1-04
Provision
Provision is likely to be through the use of standard commercial products, for example, the use of TLS or IPSEC.	CS-L1-05

Table 27 – Communications Security Components at Level 1

Level 2 Communications Security – Significant	Reference
All aspects of communications security at Level 1 are required, plus the following additional requirements:
At Level 2 the threat and vulnerability analysis leads to a requirement for explicit communication security measures. The threat actors identified are assessed to have a significant capability to attack the service but are not assumed to include well resourced and capable Foreign Intelligence Services.	CS-L2-01
Requirements
Communications across the network should be encrypted to protect their Confidentiality and Integrity. The encryption product used should have been subject to independent validation to confirm its correct design, implementation and operation.	CS-L2-02
Switches, routers and other network devices should be hardened in line with Network Protection Level 2 or 3.	CS-L2-03
Examples
Examples of transactions that might merit Level 2 Communications security include: a. A client completes an income tax return online. Electronic attack might result in details of the income tax assessment being released to an unauthorised third party. b. A client undertakes a financial transaction. Electronic attack resulting in disclosure of a debit card number, for example, would be likely to cause significant distress and inconvenience to a client.	CS-L2-04
The threat analysis for these services leads to a requirement for explicit communication security measures to counter the threats identified. The threats identified are assessed to have a significant capability to attack the service but are not assessed to include well resourced and capable Foreign Intelligence Services.	CS-L2-05
Provision
Communications security is likely to be implemented through the use of commercial products that have achieved CESG CPA foundation grade certification, see CESG website guidance (reference [p]).	CS-L2-06

Table 28 – Communications Security Components at Level 2

Level 3 Communications Security – Substantial	Reference
All aspects of communications security at Level 2 are required, plus the following additional requirements:
At Level 3 the threat analysis indicates that strong measures are required to counter well resourced and competent attackers.	CS-L3-01
Requirements
Communications across the network should be encrypted to protect their Confidentiality and Integrity. The encryption product used should have been subject to CESG evaluation to confirm its correct design, implementation and operation.	CS-L3-02
Switches, routers and other network devices should be hardened in line with Network Protection Level 3.	CS-L3-03
Examples
Examples of service that might merit Level 3 communications security protection include: a. Electronic procurement services used by Defence and FCO organisations that attract a RESTRICTED protective marking; b. Electronic travel services used for booking travel for VIPs; c. The provision of threat information from Government to organisation that form part of the Critical National Infrastructure; d. The provision of information regarding the status of a criminal investigation.	CS-L3-04
At this level the threat analysis suggests the need for strong measures to counter well resourced and competent adversaries.	CS-L3-05
Provision
HMG Baseline Grade network products are used to encrypt data prior to its transfer on to the network. These products are configured and operated in accordance with the approved security operating procedures. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied.	CS-L3-06
Switches and routers are hardened in accordance with the Network Protection Level 3.	CS-L3-07

Table 29 – Communications Security Components at Level 3

Network Authentication

Network Authentication covers the means by which assurance is obtained of the authenticity of machines involved in inter domain connections and data exchanges.

Two levels of authentication have been identified.

Level 0 Network Authentication – Limited	Reference
This level covers the situation where there is a low threat or limited opportunity for attack.	NA-L0-01
Requirements
There are no explicit requirements other than those imposed by duty of care requirements.	NA-L0-02
Examples
An example of a situation in which limited authentication would be acceptable is when connecting two public sector e-mail servers that are hosted on the Government Secure Internet. In this case use of network identifiers to identify the relevant server is acceptable due to the low level of risk of spoofing on the accredited network.	NA-L0-03
Provision
The physical, procedural and personnel security measures associated with the network are sufficient to counter the threat of network spoofing. Alternatively transaction/application level security measures may be being used to protect communications, negating the requirements for network level authentication.	NA-L0-04
If network authentication is required, it will be sufficient to rely on a network identifier, such as an IP address, MAC address or URL. Spoofing of these identifiers will have been assessed as low risk for the public sector service.	NA-L0-05

Table 30 – Network Authentication Security Components at Level 0

Level 1 Network Authentication – Active	Reference
All aspects of network authentication at Level 0 are required, plus the following additional requirements:
At Level 1 threat analysis suggests that there is a reasonable risk of spoofing and that robust measures to prevent capture and misuse of the authenticator are justified.	NA-L1-01
Requirements
A two way authentication process should be followed.	NA-L1-02
A strong authentication mechanism should be used i.e. authentication should be cryptographically based and use an approved challenge response protocol. Protection against man-in-the-middle attacks should be provided.	NA-L1-03
Examples
Services that are handling private information that do not provide end-to-end application level protection will require Level 1 Network Authentication.	NA-L1-04
Provision
At Level 1 cryptographic techniques are used to authenticate the network devices. This could, for example involve the use of pre-placed symmetric keys of appropriate length. Alternatively, public key cryptography could be used, using for example TLS or IPSEC implementations. Commercial grade or CESG evaluated cryptographic products will be used as appropriate. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF, standards or guidance should be applied as specified by their business.	NA-L1-05

Table 31 – Network Authentication Security Components at Level 1

Network Protection

Network protection provides the means to assure that the service is protected from an adversary with some degree of unconstrained network access.

Four levels have been identified.

Level 0 Network Protection – No Specific Measures	Reference
At Level 0, no special measures beyond the requirement for duty of care in the application of common commercial measures are needed.	NP-L0-01
Requirements
There are no explicit requirements.	NP-L0-02
Examples
Level 0 Network protection is appropriate for transactions in which minimal damage might arise from a network attack. For example, a network service that enables publicly available information to be downloaded from a public sector site and for which the results of an attack would be minimal inconvenience to the user of the service.	NP-L0-03
Provision
At Level 0, standard commercial network services are likely to be used.	NP-L0-04

Table 32 – Network Protection Security Components at Level 0

Level 1 Network Protection – Baseline	Reference
All aspects of network protection at Level 0 are required, plus the following additional requirements:
Standard commercial good practice measures are taken to minimise network access and import and export. The controls are subject to self-assessment against the perceived threat and hence an acceptable response.	NP-L1-01
Requirements
Appropriate organisational, personnel, physical and procedural controls should be in place to ensure the secure operation of the network services. The Assurance Security Component gives more details of the requirements.	NP-L1-02
The design, configuration and operation of the system should be in accordance with good commercial practice and should be subject to review to ensure its secure operation. Self assessment is acceptable at this level. The Assurance Security Component gives more details of the requirements.	NP-L1-03
The whole life cycle of the assets should be considered when determining the measures necessary to protect them. This includes ensuring that appropriate measures are in place to ensure their secure disposal (including the physical systems and media holding the data).	NP-L1-04
Access controls should be in place to ensure that only trusted individuals with a legitimate business need have access to the network assets.	NP-L1-05
User registration and authorisation requirements for the network administration staff should be at least as stringent as those for the users of the service.	NP-L1-06
Users should be granted the minimum privileges necessary to perform their function.	NP-L1-07
Access to the system should be via a secure logon process. The authentication requirements detailed earlier should be satisfied.	NP-L1-08
Access credentials issued should, as far as possible, be unique to a particular user. Users should be instructed not to share credentials.	NP-L1-09
Processes should be in place to regularly review the list of users with access to the system to ensure that all users with current access have a current business need.	NP-L1-10
Users should successfully authenticate themselves to the system before being able to access it. The type and strength of credential required should be determined in accordance with the guidance provided on Authentication.	NP-L1-11
Network components should be hardened in line with commercial good practice. The services running on the system should be the minimum necessary to meet the business need.	NP-L1-12
System configuration should be under proper control and unauthorised entities should be prevented from accessing and modifying important configuration data such as DNS, network addressing and routing structures.	NP-L1-13
There should be an effective configuration management process and routine inspections to ensure cross domain services and interfaces are limited to those necessary to meet the connection’s business objectives.	NP-L1-14
Network import and export controls should be in place. Only information object types that can reasonably be expected to be required to meet the business needs should be allowed across the network boundary. All imported objects should be screened to confirm that they conform to the import policy and that they do not contain viruses or other malware. An anti-virus strategy will be in place to ensure the timely update of anti-virus signatures.	NP-L1-15
System responses in the event of a service being refused (or permitted) should be designed so as to prevent anyone from deducing any information that might be used to attack the system.	NP-L1-16
A patch management process should be in place. This should ensure that patches to fix security vulnerabilities are rapidly applied to the operational system.	NP-L1-17
Audit and accounting should be performed in accordance with commercial good practice. This should meet at least the requirements of the Level 1 Situational Awareness Security Component. Audit and accounting logs should be protected to at least Server - Information Access Level 1.	NP-L1-18
An incident response plan should be in place. The incident response plan should cover the assessment processes to assess the impact of an incident, processes required to ensure the controlled close down of elements of the network when required and the recovery process to be followed. Security staff should examine all incidents of electronic attack and determine whether additional countermeasures should be put in place.	NP-L1-19
Examples
Examples of services that might merit Level 1 network protection include information services for which loss of integrity or other consequence of electronic attack is inconvenience and lost time, possibly with minor financial loss, but no lasting impact on any of the parties involved in the transactions.	NP-L1-20
Provision
At Level 1 commercial products will be used to meet the requirements.	NP-L1-21
Boundary protection devices will be used to limit the types of traffic flowing into and out of the network. These devices will be configured to minimise the traffic types allowed across the boundary. Traffic traversing the boundary will be subject to content scanning to confirm that it conforms to permitted types, to ensure the removal of viruses and other malware and to eliminate unwanted mail. Web traffic filtering will be performed to prevent the browsing of inappropriate content and to remove dangerous mobile code. SPIT and SPIM filtering will be performed if necessary.	NP-L1-22
The types of traffic allowed will be based on those reasonably required by the business. A risk assessment will have been performed to inform the selection of allowable traffic. Dangerous traffic types are blocked by default.	NP-L1-23
Network zoning will have been performed to provide a basic level of data separation on the network. Voice, data and management traffic will be segregated where possible.	NP-L1-24
Network devices will have been hardened in line with commercial good practice. This will include, for example: a. Removing or disabling all services not needed; b. Enabling strong passwords on all interfaces; c. Limiting management capabilities to the minimum necessary; d. Configuring privilege levels; e. Limiting remote access as far as possible; f. Limiting local access as far as possible; g. Displaying a login banner; h. Ensuring Simple Network Management Protocol (SNMP) is configured securely; i. Ensuring anti-spoofing is configured; j. Ensuring Denial of Service attacks mitigations are configured; k. Enabling logging and Network Time Protocol (NTP).	NP-L1-25
The configuration of the devices will be subject to review. These reviews do not however, need to be performed by external independent specialists.	NP-L1-26
The accounting logs will be regularly reviewed to enable the detection of attacks on the system. Alerting on critical events will be implemented. Standard network activity monitoring tools are likely to be regularly used to confirm that the system is operating in accordance with its expected parameters and to enable any suspicious activity or patterns of behaviour to be detected.	NP-L1-27
Standard commercial tools will be used to check that network devices are correctly configured and that known vulnerabilities have been patched. Supplier websites, GovCertUK and other security bulletin boards are likely to be actively monitored to maintain awareness of current threats and vulnerabilities and the recommended actions to be taken in response to them.	NP-L1-28
Overall compliance with the security policy is likely to be audited at least annually.	NP-L1-29

Table 33 – Network Protection Security Components at Level 1

Level 2 Network Protection – Enhanced	Reference
All aspects of network protection at Level 1 are required, plus the following additional requirements:
An independent assessment is made of the threat and vulnerabilities. The response is shown to be reasonable and proportionate.	NP-L2-01
Standard commercial good practice measures are taken to minimise network access, import and export and service monitoring. Standard commercial products are used to provide protection.	NP-L2-02
Requirements
All Level 1 network protection requirements apply at Level 2 as well. There are a number of areas in which stronger controls are required.	NP-L2-03
The organisational Assurance and Technical Assurance for the network service will be at least Level 1.	NP-L2-04
This document set does not mandate or recommend a specific risk management method, approach or process to be followed in order to identify the risks to be managed. It is recognised that in order to gain as complete as possible view of the risks to an online service it is likely that a number of different risk assessment approaches will need to be considered. The exception to this is where HMG Departments and Agencies are mandated to use the HMG Security Policy Framework (SPF) (reference [j]).	NP-L2-05
Equipment should be sited or protected to reduce the risks of unauthorised access.	NP-L2-06
Before any user of the network environment (e.g. network administrator) is allowed to access the system: i. Their identity should be validated. ii. Their business need to access the system should be confirmed. iii. They should have received appropriate training including security training. They should have signed to confirm that they understand the relevant security policy and procedures and that they will conform to these procedures.	NP-L2-07
Information import and export should be actively managed to minimise the information security risks. Services through boundary protection devices are blocked by default with an explicit risk and business case being made for each allowed service.	NP-L2-08
Audit and accounting requirements are similar to Level 1, however, accounting logs will need to be afforded a higher level of protection and audits should be performed on a more regular basis. Accounting logs should be protected to at least Information access and Internal Accountability Level 1. Automated analysis tools should be used to support the analysis of accounting data.	NP-L2-09
Network based intrusion detection/prevent 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 activity that might indicate an electronic attack is being conducted. Abnormal traffic patterns are likely to be blocked by default.	NP-L2-10
Prior to the service going live an independent IT security health check should be performed by appropriate experts. Once the service has gone live independent IT security health checks should be performed after any significant change in system configuration and periodically (period to be agreed with the Accreditor) to confirm that the system remains secure. At least Level 1 Technical and Organisational Assurance are expected (see the Assurance security component for more details of the requirements).	NP-L2-11
Examples
Examples of services that might merit Level 2 network protection include: a. A client requests general or case specific information from a public sector organisation which is needed to meet some obligation to a third party and which the department has a published commitment to supply promptly. The consequences of failure to obtain the information are inconvenience or delay but are not business critical; b. A client undertakes a financial transaction. Electronic attack might result in disclosure of credit or debit card details, causing significant distress and inconvenience to the client.	NP-L2-12
Provision
Products providing key elements of the security enforcing functionality should be protected by products with a CESG Commercial Products Assurance (CPA) scheme certification (reference [o]). However, Common Criteria EAL 3 products would also be suitable at this level.	NP-L2-13
All components will be hardened in line with commercial good practice.	NP-L2-14
Service minimisation, import controls and export controls will be more rigorously enforced and actively managed.	NP-L2-15
Audit and accounting is performed on a more regular basis. Accounting logs are likely to be reviewed at least weekly. Alerts are configured for critical events to ensure a timely response.	NP-L2-16
The configuration of the system will have been subject to independent audit by relevant independent security experts.	NP-L2-17

Table 34 – Network Protection Security Components at Level 2

Level 3 Network Protection – Significant	Reference
All aspects of network protection at Level 2 are required, plus the following additional requirements:
At Level 3 there is a requirement for strong controls on network access. An independent assessment by informed Government assessors is carried out. Privileged sources are used to inform the threat assessment. The mitigating measures may include Government capabilities and services and result in restrictions on the service to minimise exposure.	NP-L3-01
Requirements
All Level 2 network protections requirements apply at Level 3 as well. There are a number of areas in which stronger controls are required. These are as follows:	NP-L3-02
User registration and authorisation requirements for the back-office staff will be at least as stringent as those for the users of the service.	NP-L3-03
Segregation of duties should be implemented between those with security responsibilities and those with system administration responsibilities.	NP-L3-04
The network components should be hardened in line with Government good practice. A risk assessment and business case should be produced for all services which it is proposed to run in the server environment.	NP-L3-05
Import and export controls should limit import and exports to only those that can be explicitly justified. A risk assessment and business case should be produced for all import and export requirements.	NP-L3-06
Strong authentication mechanisms should be used to access the network devices. Access control should be configured to ensure that network operators’ access is limited to the information for which they have a need to know.	NP-L3-07
If encryption is used, it should be subjected to CESG evaluation to confirm its correct design, implementation and operation.	NP-L3-08
Strong accounting and auditing is required. It should be sufficient to ensure that all users can be held accountable for their actions. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), standards or guidance should be applied as specified by their business.	NP-L3-09
Level 2 or Level 3 Situational Awareness should also have been implemented. The capability to carry out display and detailed data mining and analysis of accounting records should have been provided.	NP-L3-10
The system design and security documentation should be subject to independent review by appropriate security experts. Level 2 Technical and Organisational Assurance is expected (see the Assurance Security component for more details of the requirement). Appropriate action should be taken to mitigate any significant issues identified by these reviews.	NP-L3-11
Prior to the service going live an independent IT security health check should be performed by appropriate experts. Once the service has gone live independent IT security health checks should be performed after any significant change in system configuration and periodically (period to be agreed with the Accreditor) to confirm that the system remains secure. Level 2 Technical and Organisational Assurance is expected (see the Assurance security component for more details of the requirements).	NP-L3-12
Examples
Examples of transactions that might merit Level 3 network protection include: a. Transactions involving transfer of medical records. Electronic attack might result in the disclosure of client medical information to an unauthorised third party, or loss of integrity that might cause substantial distress and/or risk to the health of the client; b. Transactions involving the transfer of income tax assessment returns. Electronic attack might result in details of the income tax assessment being released to an unauthorised third party causing substantial distress; c. Transactions involving the transfer of PAYE and VAT returns. Electronic attack might result in the release of commercially sensitive and/or private information to third parties and possible substantial inconvenience and financial loss.	NP-L3-13
Provision
Provision of the services at Level 3 is similar to that at Level 2. The main areas of difference are as follows:	NP-L3-14
All personnel with physical access to the system are likely to have been vetted in accordance with Baseline Personnel Security Standard (BPSS) requirements. Personnel with more privileged access, e.g. network administrators, are likely to have been subject to Security Cleared (SC) vetting.	NP-L3-15
The location at which the active network devices are located is likely to be at sites that have been approved for handling information with a national protective marking.	NP-L3-16
Boundary protection devices, network devices and network management devices will all be hardened in accordance with Government good practice. Only those services, protocols, ports and addresses that are explicitly required will be allowed. Everything else will be denied. All unnecessary services will have been disabled.	NP-L3-17
Network zoning is likely to be used to support data separation and support access control restrictions. This includes the separation of voice, data and management traffic.	NP-L3-18
Level 2 or Level 3 Situational Awareness is likely to have been implemented. The capability to carry out display and detailed data mining and analysis of accounting records will have been provided.	NP-L3-19
If encryption is used, a HMG Baseline Grade approved product should be utilised. This should be configured, operated and managed in accordance with the relevant security operating procedures. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), cryptographic standards or guidance should be applied as specified by their business.	NP-L3-20
Network based intrusion detection/prevent 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 activity that might indicate an electronic attack is being conducted. Government attack signature information is likely to be used.	NP-L3-21
Incident response procedures will have been established. A fully resourced computer incident response team is likely to been stood up. Incident recovery procedures, controlled close down, impact assessment and recovery procedures will be documented and regularly tested. Incidents are typically reported to GovCertUK and CINRAS as required.	NP-L3-22
The system design and security documentation is likely to have been subject to independent review by CESG, CLAS Consultants or CTAS approved supplier and appropriates action taken to mitigate any significant issues identified. The service configuration is likely to be subject to regular independent health check by CESG, CHECK approved supplier or a CTAS approved supplier.	NP-L3-23

Table 35 – Network Protection Security Components at Level 3

Situational Awareness

Situational awareness provides the means of obtaining and maintaining awareness of the vulnerabilities of a service, detecting attacks and responding in a timely, coordinated and prioritised way.

Four levels have been identified.

Level 0 Situational Awareness – No Specific Measures	Reference
At Level 0 no special measures need to be taken beyond routine good practice such as keeping up with security patches and attention to firewall and other incident logs.	SA-L0-01
Requirements
No explicit requirements.	SA-L0-02
Examples
Services that might fall into this category are those that provide general information to the public and are in low threat environments. For example, standalone kiosks located in libraries that provide information on local council services.	SA-L0-03
Provision
General awareness of system vulnerabilities and threats would be obtained by monitoring supplier, GovCertUK and other sites.	SA-L0-04
Standard commercial products are likely to be used to provide the system services. Management arrangements are in place to ensure that these devices are patched as required to maintain the secure state.	SA-L0-05
Periodic review of system and other accounting logs is likely to be performed to enable potential incidents to be detected.	SA-L0-06

Table 36 – Situational Awareness Security Components at Level 0

Level 1 Situational Awareness – Aware	Reference
All aspects of situational awareness at Level 0 are required, plus the following additional requirements:
At Level 1 the service is assessed of being of interest to a class of adversaries but no specific threats have been identified. General awareness of attacks and potential vulnerabilities of the systems providing the service needs to be maintained.	SA-L1-01
Requirements
At Level 1 a management framework for the monitoring of the service and its vulnerabilities should be established. This includes assigning responsibilities for audit, incident response and reporting to individuals.	SA-L1-02
Proactive monitoring of key servers and boundary protection devices should be performed. Protective monitoring services should be appropriately resourced and integrated with business activities.	SA-L1-03
Accounting logs should be generated on servers and network protection devices. The events record should include as a minimum, all failure events, changes in configuration or security policies and the execution of privileged commands. Accounting logs should: a. Reveal a unique identification (ID), e.g. the ID of the individual or process performing a function; b. Reveal the date and time of an event or function or series of related functions; c. Identify the physical or logical address (or both) where the function took place (this could be a terminal address, boundary device port address or similar); d. Reveal the type of service being executed.	SA-L1-04
All clocks on all devices that are subject to monitoring should be synchronised.	SA-L1-05
An operational cycle should be established to enable the early detection of potential threats. This should include at least a weekly review of accounting logs.	SA-L1-06
Monitoring of relevant commercial bulletin boards should be performed to enable early identification of information of vulnerabilities and to allow timely installation of patches.	SA-L1-06
A longer term reporting cycle should also be established to review trends and enable the identification of areas requiring improvement.	SA-L1-07
A documented set of processes for incident management should exist. These should be tested to ensure their effectiveness. The procedures should cover the incident response plan, incorporating actions that may range from immediate restoration of service to partial restoration or suspension of service. A controlled closedown process should be available, maintaining the provision of essential business services as far as possible. Following an incident, an impact assessment should be made of whether any damage, including loss of data integrity, has occurred and a recovery plan drawn up. System security staff should examine all incidents of attack and determine whether any additional security controls should be put in place.	SA-L1-08
Examples
Examples of service that might merit Level 1 protection are those that provide general information to the public. Malicious attack, such as defacing of the website might cause minor embarrassment to the public sector and minor inconvenience to the users of the service.	SA-L1-09
Provision
At Level 1 responsibilities are defined and processes documented for monitoring commercial bulletin boards and supplier sites to ensure the early identification of vulnerabilities and the need to install system patches. Responsibilities for system maintenance are defined and processes documented, for patch testing and installation. Audit responsibilities are defined and audit processes are documented.	SA-L1-10
Standard commercial tools are used to meet the requirements. All servers and boundary protection devices are configured to produce accounting logs. Security events to be included in the accounting logs include: a. All failure events; b. Logon and logoff events; c. Audit events; d. The execution of all privileged commands.	SA-L1-11
For all events recorded in the accounting logs the following information as a minimum is recorded: a. The unique ID of the individual or process associated with the event; b. The date and time of the event; c. The source of the event (e.g. the physical or logical address (IP header, MAC)); d. The type service being executed (e.g. service or protocol name and number).	SA-L1-12
Regular monitoring of accounting output is performed to detect potential breaches. This is performed at least weekly. Automatic alerting on critical events is set up to ensure a timely response.	SA-L1-13
System provided activity monitoring tools are regularly used to confirm that the service is operating within acceptable bounds.	SA-L1-14
Accounting logs are archived. Retention periods are determined in accordance with legal and business requirements and are likely to be at least 3 months.	SA-L1-15
Long term trend analysis is performed. Overall policy direction is reviewed and opportunities for improvement identified. This is likely to occur at least annually.	SA-L1-16
The incident response plan has been developed in accordance with ISO 18044 (reference [r]). The plan is based on being able to perform an initial response to critical events in less than a day and commence a full investigation within 1 week. The plan is subject to at least annual testing to ensure it is effective.	SA-L1-17

Table 37 – Situational Awareness Security Components at Level 1

Level 2 Situational Awareness – Active awareness and response	Reference
All aspects of situational awareness at Level 1 are required, plus the following additional requirements:
At Level 2 the service is assessed as being of interest to specific capable adversaries. Active awareness of the security state of the service environment needs to be maintained and a central response team needs to be in place to ensure a coordinated and prioritised response to incidents. Active links to the national response centre are likely to be in place to enable early identification of new threats and vulnerabilities and responses to be taken to these.	SA-L2-01
Requirements
All the requirements at Level 1 apply at Level 2. In addition, at Level 2:	SA-L2-02
A full range of Information Assurance Components (IACs) is expected to be deployed within the environment. This includes boundary protection devices, import and export control devices, intrusion detection and prevention systems. Accounting logs are produced by all IACs and servers. Accounting logs should be reviewed to ensure compliance with the system security policy.	SA-L2-03
Audit data from the different IACs should be consolidated within a central Security Information Management (SIM) system. The SIM should support the automatic correlation and analysis of the accounting data. Commercial attack signature vectors would be expected to be used with the SIM.	SA-L2-04
Active monitoring of supplier web sites, GovCertUK and other sources of information on current vulnerabilities is performed. An active link to the national Government response centre is maintained to enable early identification of new threats and vulnerabilities.	SA-L2-05
A central incident response team should be established. This should have an agreed set of documented incident response plans to cover all significant eventualities. These incident plans should be regularly tested to ensure that they are effective and current.	SA-L2-06
A forensic readiness plan should be established and frequently tested.	SA-L2-07
All services should be operated in accordance with commercial good practice.	SA-L2-08
Examples
Examples of services that might merit Level 2 Awareness protection include: a. On-line self assessment tax return services; b. On-line access to medical information or the results of health screening; c. A client undertakes a financial transaction. Electronic attack might result in disclosure of credit or debit card details, causing significant distress and inconvenience to the client.	SA-L2-09
Provision
Provision is similar to Level 1. This will be supplemented by the use of commercial security products that provide boundary protection, import and export controls and host and network based Intrusion Detection System (IDS). These will all provide audit information. Accounting will include recording of: a. Business data importing and exporting at the boundary; b. Suspicious activity at the network boundary; c. Internal workstation, server or device status; d. Suspicious internal network activity; e. Events relating to network connections; f. Session activity by user and servers; g. Data backup status; h. Status of the audit system.	SA-L2-10
Accounting data will be consolidated and analysed within a central security information management system. This will be manned during core business hours. Critical events will be alerted to the response team at all times.	SA-L2-11
Accounting logs will be protected to ensure their integrity. The logs will be archived. Retention periods will be determined from the business needs but are unlikely to be less than 3 months.	SA-L2-12
Accounting logs will be regularly audited (at least once a week).	SA-L2-13
A central incident response team exists to ensure a coordinated and prioritised response to incidents. For example, the team could plan to be able to perform initial response to critical events in under 4hrs and to start a detailed investigation within 2 days.	SA-L2-14
An active link with the HMG national response centre will be established to enable early identification of new threats and vulnerabilities and responses to be taken to these.	SA-L2-15
Service monitoring processes are operated and provided in accordance with good practice on service management (e.g. ISO/IEC 20000-1 (reference [s]) and ISO/IEC 20000-2 (reference [t])).	SA-L2-16
Analysis and checking for security breaches will be used on a routine basis. Standard commercial tools will be used to perform this.	SA-L2-17
Regular review activities of the Information Security Management System and associated processes will be performed to check its effectiveness and to allow continuous improvement.	SA-L2-18
A forensic readiness plan will be in place and will be regularly tested to ensure its continuing effectiveness. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), standards or guidance should be applied as specified by their business.	SA-L2-19

Table 38 – Situational Awareness Security Components at Level 2

Level 3 Situational Awareness – Informed awareness and coordinated response	Reference
All aspects of situational awareness at Level 2 are required, plus the following additional requirements:
At Level 3 the service is assessed as being of interest to specific capable adversaries with evidence of ongoing activity against the service or its peers.	SA-L3-01
A comprehensive computer network defence capability is deployed at this level with ongoing links to a national threat and incident monitoring service.	SA-L3-02
Requirements
At Level 3 more comprehensive monitoring of the environment should be performed. This includes scanning the system to identify vulnerabilities and to enable early detection of unauthorised changes in network and system configuration.	SA-L3-03
Event data from all Information Assurance Components (IACs) should be fed back to a central coordination centre that is provided with the tools to allow the consolidation and analysis of the data. The latest Government signatures for signs of attack should be used within the analysis tools to identify potential attack.	SA-L3-04
Tools should be provided to enable the response centre to prioritise incidents and manage their response.	SA-L3-05
Examples
An example of a service for which Level 3 awareness may be appropriate is a defence e-procurement service, or travel booking service used by the FCO, VIPS or Defence staff.	SA-L3-06
Provision
A comprehensive fully resourced computer network defence capability will be deployed including: a. Boundary protection devices; b. Import/export filtering; c. Network and host based IDS (host on critical servers), likely to exploit both anomalous behaviour and signature based approaches; d. Vulnerability scanning; e. Network discovery (to allow real time audit of network configuration); f. Network behaviour analysis.	SA-L3-07
Event data from all IACs (including internal devices) will be fed back to a central coordination centre that is provided with tools to allow the consolidation and analysis of this data. Latest Government attack signature data will be provided to enable analysis of event information.	SA-L3-08
An active link to the Government national response centre will be established to enable early identification of new threats and vulnerabilities and responses to be taken to these.	SA-L3-09
Audit and accounting records will be archived to allow future forensic analysis. Retention periods for archive data will be determined by business needs but are unlikely to be less than 12 months.	SA-L3-10

Table 39 – Situational Awareness Security Components at Level 3

5. Business Logic Components

Key Principle

• Covers the measures necessary to ensure accountability and non-repudiation of a transaction

Introduction

The business logic security components cover the measures necessary to ensure accountability and non-repudiation of a transaction. It is considered under two headings:

a. Internal Accountability – this is concerned with the measures taken to establish the traceability and accountability of significant transaction steps within the server environment.

b. External Accountability – this is concerned with the measures taken to establish the Accountable Authority for, and provenance of, transfers of data to and from external sources.

Internal Accountability

The Internal Accountability security component provides the means by which assurance is gained that the transaction logic is correct, that information is not changed in an unauthorised manner when received, stored or processed within the server environment and the necessary accounting logs are maintained to enable traceability and accountability.

Many of the measures required to provide the required internal accountability are common to the measures needed to protect the information access and availability of data within the server environment. There is therefore a significant degree of commonality between the Information Access and Information Availability Security Components levels and the Internal Accountability Security Component Levels.

The organisational, personnel and physical security requirements of the organisations managing the servers are described in the Organisational Assurance Security Component requirements.

Level 0 Internal Accountability – No Specific Measures	Reference
At Level 0 there are no explicit internal accountability requirements other than those required to meet commercial practice for financial accounting and asset management.	IA-L0-01
Requirements
Commercial good practice should be followed to minimise the vulnerability of the system to attacks on the integrity of the service provided and the data captured, processed and stored.	IA-L0-02
A means should be provided to enable the detection of any breach in data integrity held within the server environment. This may be a manual process or automated tools may be used.	IA-L0-03
Data archive and data backup should be performed on a regular basis. The frequency of data backup should be determined from the level of data loss the business is prepared to accept.	IA-L0-04
The archive and backup process should be regularly tested to confirm its correct operation. Backup and archive data should be afforded the same level of protection as the operational data to ensure that its integrity is maintained.	IA-L0-05
Examples
Services for which Level 0 internal accountability is appropriate are those for which failure of the transaction is likely to result in minimal inconvenience to any party. For example, a service that provides publicly available information from a public sector website. Corruption of the information due to a malicious or non-malicious impact would cause at most minimal inconvenience to the client.	IA-L0-06
Provision
At Level 0, commercial products are likely to be used to meet the requirements. The in-built security features of these products are likely to be sufficient to meet the security needs. The products will be configured and hardened in line with commercial good practice. No specific security enhancement will be required to these products. Clients may be able to detect where modifications have occurred (e.g. document format errors, incomplete web pages), but the ability to be able to detect modifications is not a high business need.	IA-L0-07

Table 40 – Internal Accountability Security Components at Level 0

Level 1 Internal Accountability – Auditable	Reference
All aspects of internal accountability at Level 0 are required, plus the following additional requirements:
At Level 1 a basic level of accountability for transactions is required. Standard commercial levels of quality control and testing on transaction logic are required. Basic accounting records are produced and retained in a secure manner that can be used to relate a transaction to an identified individual at a specific time. Standard commercial methods are used to preserve the integrity of records.	IA-L1-01
Requirements
The system should be designed, developed, implemented and operated in accordance with the requirements of Technical Assurance Level 2 or 3. This should include performing an independent review of the transaction logic to confirm its validity.	IA-L1-02
Commercial good practice should be followed to minimise the vulnerability of the system to attacks on the integrity of the service provided and the data captured, processed and stored.	IA-L1-03
An information management policy should be produced. This policy should, as a minimum: a. Specify what information types are covered; b. State the policy regarding protective marking; c. State the policy regarding identifying the impact of a breach of integrity on different information and identifying information with high impact; d. State the policy regarding identifying the impact of a breach of availability on different information and identifying information with high impact; e. State the policy with regard to the type of media to be used for storage; f. State the policy regarding data file formats and version control; g. State the policy regarding relevant information management standards to be complied with; h. Define the retention periods and disposal policies; i. Define the responsibilities for information management functions and for ensuring compliance with the policy; j. Include the results of consultations with appropriate legal and/or regulatory bodies; k. Define requirements for auditing relative to particular document types.	IA-L1-04
Procedures should be in place that ensures that the authenticity and integrity of data can be maintained. The procedures should be documented and cover at least capture, indexing, output, transmission, retention, disposal, backup, data migration, maintenance, security, outsourcing, workflow, self modifying files, maintaining accuracy of date and time of an event, quality control and/or time and version control.	IA-L1-05
Regular audits should be performed to confirm compliance with the information management policy. Certificates of compliance should be obtained.	IA-L1-06
Security risk assessments should be performed and regularly reviewed. The risk assessment should explicitly consider the risks to data integrity. Of particular importance are the security measures implemented to control the information storage media, both the live and backup media. Business continuity plans should give explicit consideration as to how the integrity of information is to be maintained during a disaster and recovery from the disaster.	IA-L1-07
Segregation of roles should be considered for key information management roles, including input reconciliation, quality control, data entry, information disposal and information security.	IA-L1-08
As a minimum, the physical, personnel, procedural, access control, user access management, service operation, service continuity, server hardening, import and export controls and audit requirements defined for Information Access Level 2 should be met.	IA-L1-09
Audit trails should be produced. These audit trails should contain sufficient information to be able to demonstrate all necessary historical activities relating to the data whose integrity needs protection.	IA-L1-10
Access to the audit trail should be limited to those with an explicit need. Access to the audit trail should be audited. The audit trail should be managed to ensure it is understandable and to ensure its authenticity and accessibility. It should be sufficiently comprehensive to enable independent review to confirm all changes to protected information. It should be retained for at least the same period as that of the data it relates. It should include date and time stamp information for each event recorded.	IA-L1-11
For critical records, consideration should be given to the use of cryptographic controls to improve security and provide tamper evidence. Where cryptographic techniques are exploited, key material should be managed in accordance with Business Logic External Accountability Level 2.	IA-L1-12
Where data compression is to be used (e.g. prior to electronic communication) the type of data compression to be used should be carefully considered and assessed for its impact on data integrity.	IA-L1-13
For information that may be stored for a considerable length of time (longer than the lifetime of the current technology) a data file migration strategy should be developed. Records should be kept to demonstrate that integrity has not been compromised in the process of migrating and converting data.	IA-L1-14
Examples
Example transactions that might merit Level 1 Internal accountability include: a. A self assessment tax application for which the client may subsequently seek to deny responsibility for the contents of the return, claim forgery or interference or for which incorrect operation of the software could result in invalid financial calculations leading to significant loss or damage to reputation. b. A service that allows a client to pay a fixed penalty fine. Delay in payment of the fine results in additional penalty charges being incurred.	IA-L1-15
Provision
Standard commercial products are likely to be exploited. These will be configured so that:	IA-L1-16
Data is recorded on to final data storage as soon as possible after the time of data capture.	IA-L1-17
Access controls are in place to limit those users with write or modify privileges to records to a minimum.	IA-L1-18
Anti-virus and other systems used to prevent malicious alteration of stored data files are implemented.	IA-L1-19
Backup power supplies or UPS are used to minimise the risk of data corruption in the event of a power failure.	IA-L1-20
Full data backup is performed with comparison of backup data to the relevant operational data to confirm its integrity. The frequency will be determined from the level of data loss the business is prepared to accept. The archive and backup process will be regularly tested to confirm its correct operation. Backup and archive data will be afforded appropriate protection to ensure that its integrity is maintained.	IA-L1-21
Checksums or digital signatures may be used to confirm integrity of stored or transmitted data records and, where appropriate, the identity of the party who originated the data. Procedures will be in place for the verification of signatures and for recording verification timings. Where automated controls to detect alterations to or removal of data do not exist, manual random checks to verify that critical records which have been frozen have not been altered or removed will be performed on a regular basis.	IA-L1-22
Lossless techniques are used for data compression where any reduction in detail is not acceptable.	IA-L1-23
Automatic processes are in place to verify the receipt of electronic communications. For example, if Simple Object Access Protocol (SOAP) is used for web transactions it will be configured to require receipts to be generated by the receiving system.	IA-L1-24
Accounting logs will be produced that enable a full record of the changes made to a record. For compound documents audit trails will be such that the historical content of the data file can be assessed at any relevant time;	IA-L1-25
WORM technology may be used for data storage of critical records for which it is important to prevent the modification of stored records.	IA-L1-26
Import and export controls are likely to be based on blacklisting. Procedural controls are likely to be used to control the import and export of objects from media (e.g. CDs). Mail and other electronic imports are likely to be screened automatically at the gateway to the system. Dangerous file types (e.g. executables) are likely to be automatically blocked or quarantined at the gateway. The list of file types to be blocked or quarantined is likely to be based on a blacklisting approach. Data that is likely to be reasonably required by the business will be allowed by default.	IA-L1-27
The communications across the gateway will be minimised to those that are reasonably required by the business. Filtering technology is likely to be used to remove SPAM, SPIT and SPIM. All import and exported objects will be subject to anti-virus scanning using a commercial anti-virus product. An anti-virus strategy will be in place to ensure the timely update of anti-virus signatures.	IA-L1-28
Standard system provided activity monitors are likely to be used to regularly confirm that the system is operating in accordance with its expected parameters and to enable any suspicious activity or patterns of activity to be identified. Standard system-provided accounting logs will be reviewed by appointed security personnel for the system to ascertain whether there is any activity or pattern of activity that might indicate an unexpected electronic attack on the system. Account logs are likely to be reviewed at least monthly. Alerts are likely to be configured for critical events to ensure a timely response. Accounting logs will be retained to enable a record of transaction times and record changes. Access to the logs will be strictly controlled to minimise the risk of tampering.	IA-L1-29

Table 41 – Internal Accountability Security Components at Level 1

Level 2 Internal Accountability – Accountable	Reference
All aspects of internal accountability at Level 1 are required, plus the following additional requirements:
At Level 2 strong measures are needed to ensure that those involved in a transaction can be held to account. At this level it is anticipated that it may be necessary to present evidence in support of legal action.	IA-L2-01
Requirements
The system should be designed, developed, implemented and operated in accordance with the requirements of Organisational and Technical Assurance Level 3. This should include performing independent review of the transaction logic to confirm its validity.	IA-L2-02
The requirements of Level 1 should be satisfied. The measures required should however be stronger and it should be possible to demonstrate that all relevant requirements of BSI BIP 0008-1 (reference [u]), BIP 0008-2 (reference [v]) and BIP 0008-3 (reference [w]) are satisfied.	IA-L2-03
Government good practice should be followed to minimise the vulnerability of the system to attacks on the integrity of the service provided and the data captured, processed and stored.	IA-L2-04
Examples
Level 2 internal accountability applies where it is necessary to be able to hold a person accountable for a transaction. For example, passport issuing services may need Level 2 accountability as part of the measures necessary to prevent the fraudulent issue of a passport. Driving licence record services may need Level 2 accountability as part of the measures necessary to prevent the fraudulent issue of licences or the fraudulent modification of driving licence endorsements.	IA-L2-05
Provision
Provision of the services at Level 2 is similar to that at Level 1. The main areas of difference are that:	IA-L2-06
The technical controls will be supplemented by strong physical, procedural and personnel security measures to ensure the required authenticity, accountability and integrity of data can be maintained.	IA-L2-07
All personnel with physical access to the system are likely to have been vetted in accordance with BPSS requirements. Personnel with more privileged access, e.g. system administrators, are likely to have been subject to SC vetting or equivalent.	IA-L2-08
The physical controls protecting the environment in which servers, backup media, etc are stored will be sufficient to deter a skilled attacker.	IA-L2-09
Level 2 or Level 3 situational awareness is likely to have been implemented.	IA-L2-10
Regular audits of all accounting records will be performed.	IA-L2-11
Regular independent inspections will be performed to confirm conformance with the security procedures.	IA-L2-12
Products providing key elements of the security enforcing functionality should have been certified using the CESG CPA certification to at least foundation grade (reference [o]).	IA-L2-13
The system design and security documentation is likely to have been subject to independent review by CESG, CLAS Consultants or CTAS approved supplier and appropriate action taken to mitigate any significant issues identified. The service configuration is likely to be subject to regular independent health checks by CESG, a CHECK approved supplier or a CTAS approved supplier. This will be at least annually and after any significant configuration change.	IA-L2-14

Table 42 – Internal Accountability Security Components at Level 2

External Accountability

The external accountability security component covers the measures taken to establish the accountable authority for, and provenance of, transfers of data to and from external sources.

Three levels of external accountability are defined.

Level 0 External Accountability – no specific measures	Reference
At Level 0 items received are taken at face value.	EA-L0-01
Requirements
There are no explicit external accountability requirements though any system logs may be used to establish a transaction history if needed.	EA-L0-02
Examples
Services for which Level 0 external accountability is appropriate are those for which failure of the transaction is likely to result in minimal inconvenience to any party. For example, a service that provides publicly available information from a public sector website. Corruption of the information due to a malicious or non-malicious impact would cause at most minimal inconvenience to the client.	EA-L0-03
Provision
At this level items received or transmitted are taken at face value. Normal service elements provide sufficient assurance that an object originated from a particular source. For example, an e-mail from user@isp.net.uk would be sufficient to assume the information provided is from user. A web page http://www.dept.gov.uk/ would be sufficient to confirm the information it contains is from dept. No special mechanisms are implemented to support traceability. The risks associated with impersonation are acceptable to the business at this level.	EA-L0-04
Normal service components would be used to confirm that a transaction has occurred. For example, a confirmation e-mail provides sufficient evidence that the transaction was completed by the public sector service.	EA-L0-05

Table 43 – External Accountability Security Components at Level 0

Level 1 External Accountability – Auditable	Reference
All aspects of external accountability at Level 0 are required, plus the following additional requirements:
Level 1 provides a basic level of accountability for transactions performed. Evidence of receipt of a transaction is provided by the service to the client. It would be relevant for transactions of an official nature in which failure to complete the transaction may be interpreted as a statutory infringement that may incur a penalty, or which may have a significant impact on a third party. A strong and persistent binding between the transaction and the security information, while desirable, is not essential and other means of providing the required traceability and accountability can be exploited.	EA-L1-01
Requirements
Level 1 Internal Accountability requirements should be met.	EA-L1-02
A transaction should: a. Occur via a trusted route that provides basic assurance as to the identity of the originator and receiver (where relevant). b. A trusted out of band route should be used to confirm the transaction with the originator before transaction completion. c. A digest of the transaction (or the transaction) should be signed by the originator to provide evidence of origin and to provide integrity protection.	EA-L1-03

If signatures are used they should be verified by the recipient of the transaction, or by a third party. Ownership of any public keys should be verified by a recognised entity, which may be the recipient or some other party. Verification should include checking that the end certificate and all those in the required trust path have not been revoked. It should also include checking all certificates have been issued under an appropriate policy for which they are being relied on. Both the Public Key Infrastructure (PKI) Service Provider and business Service Provider should synchronise their time with a reputable time source.	EA-L1-04
Accounting logs should be generated and kept, showing transaction times and records of system operation. Sufficient information should be recorded within the accounting logs so that it can be demonstrated to a third party (if needed) who the transaction originator was. A response demonstrating receipt of a transaction should be returned to the transaction originator (whether the transaction is successful or not).	EA-L1-05
Evidence of receipt of a successful transaction should be provided by the service. The receipt should confirm the success of the transaction.	EA-L1-06
The integrity and authenticity of the returned response should be protected at a comparable level to the original transaction.	EA-L1-07
It should contain sufficient information that the recipient is able to validate the transaction against what they submitted.	EA-L1-08
Retention periods for accounting logs and other transaction periods should be determined as part of the design process.	EA-L1-09
Any requirements for the clients of a service to retain records should be clearly communicated to them.	EA-L1-10
Examples
Examples of services for which Level 1 External Accountability include: a. Payment for low value goods and service that are delivered to the recipient’s known address. b. Payment of a fixed penalty fine for which the Government organisation could deny receipt incurring additional penalty charges and loss for the client.	EA-L1-11
Provision
At this level a transaction could occur via a trusted route that provides basic assurance as to the identity of the originator and receiver (if relevant) of the transaction. For example, it might involve the use of TLS with Server and Client Authentication.	EA-L1-12
Basic accounting records would be produced and retained in a secure manner that can be used to relate a transaction to an identified client at a specific time and provide information on success or failure of the transaction.	EA-L1-13
Additional degrees of trust may be achieved by the use of informal measures to deter later repudiation of a transaction. For example, the client is provided at intervals with a list of recent transactions. It is important that expert guidance be sought when setting up such schemes, as the additional trust achieved is often illusory unless the scheme is carefully constructed. Such schemes are rarely foolproof, it is therefore important that the limits of such schemes are understood and accepted by both parties to the transaction. However, these methods may provide a useful extra degree of trust in specific cases and provide the client with greater confidence.	EA-L1-14

Table 44 – External Accountability Security Components at Level 1

Level 2 External Accountability – Accountable	Reference
All aspects of external accountability at Level 1 are required, plus the following additional requirements:
This level would cover transactions of an official nature in which failure to complete the transaction might have a substantial financial impact (which might not be recoverable), or impact on the health or safety of installations or individuals. Such transactions may be attractive to criminal exploitation leading to a substantial risk of fraud or criminal damage. At this level there is a need for strong and persistent binding between transaction and security information.	EA-L2-01
Requirements
Level 2 Internal Accountability requirements should be satisfied.	EA-L2-02
A transaction or a digest of the transaction, signed by the originator, should be used to provide evidence of origin and to provide integrity protection to the transaction details.	EA-L2-03
The signature should be verified by the recipient of the transaction, or by a third party. Ownership of any public keys should be verified by a recognised entity, which may be the recipient or some other party. Verification should include checking that the certificate has not been revoked or suspended and that it has been issued under an appropriate policy. Time should be synchronised between the PKI Service Provider and the business Service Provider.	EA-L2-04
Accounting logs should be generated and kept, showing transaction times and records of system operation.	EA-L2-05
The signing algorithm used should be selected to be compliant with Cryptographic Standards. For those mandated to do so, the relevant SPF Mandatory Cryptographic Requirements should be applied. For those not mandated to use the SPF (reference [j]), cryptographic standards or guidance should be applied as specified by their business.	EA-L2-06
Private keys used for signing should be protected using recognised, cryptographically assessed and approved software or hardware tokens. Trust anchors should be distributed to where they are used by a secure means that enables their origin to be validated and confirmation that they have not been tampered with in transit confirmed. The trust anchors should be stored in a secure environment that provides tamper protection.	EA-L2-07
The PKI services used should have been approved under t-Scheme (reference [x]) or an equivalent.	EA-L2-08
A response demonstrating receipt of a transaction should be returned to the transaction originator (whether the transaction is successful or not). It should confirm success or failure of the transaction.	EA-L2-09
The integrity and authenticity of the returned response should be protected at a comparable level to the original transaction.	EA-L2-10
The receipt should be signed by the originator. It should contain sufficient information that the recipient is able to validate the transaction against what they submitted.	EA-L2-11
Retention periods for accounting logs and other transaction periods should be determined as part of the design process.	EA-L2-12
Any requirements for the clients of a service to retain records should be clearly communicated to them.	EA-L2-13
Examples
Example transactions that might merit Level 2 external accountability include: a. An organisation files a fraudulent tax return electronically and, upon being challenged, may deny submitting the return; b. A client receives results of medical testing electronically. The client needs to be assured that the results are indeed from the Service Provider and could not have been altered in transit; c. A client is issued a recall notice arising from participation in a health screening programme. A failure to complete the transaction might prevent or delay treatment for the condition detected, causing risk to the client’s health and substantial distress amongst other consequences; d. A laboratory service provides clinical tests and may file the results electronically to speed up the response to the results. The consequence of wrongly attributing the results to the patients may be serious and should be minimised, it should be clear where such an incorrect attribution arose.	EA-L2-14
Provision
At Level 2 it is expected that commercial PKI technology will be exploited. The technology used would have undergone independent assurance by a recognised organisation to confirm that it provides adequate security functionality (e.g. obtained certification at EAL 4 under the Common Criteria scheme (1) (reference [o]). The cryptographic modules used would have been expected to have been validated by CESG or a FIPS 140 accredited laboratory.	EA-L2-15
The PKI services would have been validated against HMG requirements to confirm they have been implemented as expected. This could involve, for example, obtaining t-scheme assurance.	EA-L2-16
Private keys used to sign the transactions are expected to be generated and stored within a secure environment. It is likely that evaluated Smart Cards will be used to provide this secure environment.	EA-L2-17

(1) It is important to review the product’s Common Criteria Security Target to ensure that the required security enforcing functionality has been included in the scope of the evaluation.

Table 45 – External Accountability Security Components at Level 2

6. Assurance Components

Key Principle

• Covers the activities required to confirm the secure end-to-end delivery of a service

Introduction

Assurance security components cover the activities required to confirm the secure end-to-end delivery of a service. It covers the review of the design, implementation, configuration, operation and disposal activities to ensure that the security requirements are met. Two aspects are considered:

a. Organisational Assurance - covering management, procedural, personnel and physical security aspects of the service delivery against security requirements.

b. Technical Assurance - covering design, implementation, configuration, maintenance and operation of the public sector service against security requirements.

Organisational Assurance

Organisational assurance covers the review of the organisations involved in the delivery of a service to ensure that the required management, procedural personnel and physical security arrangements are in place to secure the service.

Level 0 Organisational Assurance – no specific measures	Reference
This statement is currently under development.	OA-L0-01
Requirements
There are no explicit requirements for external independent audit of the organisation’s information security management system. Self certification is expected to provide sufficient assurance that the organisation is effectively managing its security.	OA-L0-02
Examples
An example of a service that falls into this category is the provision of a public website that provides general publicly available information. A breach in the security would be expected to have a minimal impact.	OA-L0-03
Provision
While there are no formal requirements for independent external assurance to be obtained of the effectiveness of the organisation‘s information security management system, the service provided by the organisation is still expected to be designed, implemented, configured, operated and maintained in accordance with commercial good practice.	OA-L0-04
The organisation is expected to have a documented Information Security Management System. This Information Security Management System (ISMS) is expected to meet the requirements of ISO/IEC 27001 (reference [y]) although independent certification of this is not required at this level. An information risk policy is expected to have been defined. This policy is expected to clearly document the organisations risk appetite. A process for identifying information risks and allocating these to appropriate owners and managers is expected to have been defined and be in operation. In assessing risks, consideration of those risks that arise from the supply chain are expected to be considered.	OA-L0-05
Management arrangements for information security are expected to have been established. This is expected to include senior leadership. Processes are expected to be in place to enable the organisation to confirm its compliance to the ISMS. Periodic internal audit of compliance is expected to be performed to reassure the organisation’s Board that security is being effectively managed.	OA-L0-06
The organisation is expected to have effective personnel security controls in place. This includes ensuring security role and responsibilities are defined and documented in relevant contracts. Pre-employment screening is expected to verify individuals’ identities and the claims they make in their application. CPNI guidance on preemployment screening is provided in (reference [z]). Once employed, a programme of training, education and security awareness is expected to be provided. On termination or change of employment processes to ensure the return of assets, removal of access rights and ensure individuals are aware of their ongoing security obligations are expected to be in place.	OA-L0-07
Physical Security controls are expected to be in place to prevent unauthorised physical access, damage and interference to the organisation’s premises and information resources. Centre for the Protection of National Infrastructure (CPNI) guidance on physical security controls is provided in (reference [aa]).	OA-L0-08
The organisation is expected to have a documented incident management plan – ISO/IEC 18044 (reference [r]) provides good practice guidance.	OA-L0-09
An assessment of the organisations IA maturity is at least Level 1. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF, standards or guidance should be applied as specified by their business.	OA-L0-10
The design, implementation and operation of the service is expected to be performed in accordance with good practice (e.g. in accordance with the service management requirements of ITIL (reference [bb]). Formal configuration and change control procedures are expected to be in place. Changes to an element of the service are expected to be subject to acceptance testing within a test environment prior to implementation in the operational environment. Formal sign-off of a change by the service manager is expected to be obtained before the changes are made within the operational environment.	OA-L0-11
Other standards relevant to the design, implementation and operation of the service include: a. ISO 9000 and ISO 9001 for quality assurance. b. ISO 20000 for service management. c. BS25999 for disaster recovery. d. BS25999 and ISO 24762 for business continuity planning.	OA-L0-12
Independent certification of compliance with the standards would not however be expected.	OA-L0-13

Table 46 – Organisational Assurance Security Components at Level 0

Level 1 Organisational Assurance – Independent Assessment	Reference
All aspects of organisational assurance at Level 0 are required, plus the following additional requirements: This statement is currently under development.	OA-L1-01
Requirements
Independent assurance is required for those involved in the provision of the service and the locations from which they provide the service have appropriate (commercial good practice) organisational, physical and personnel controls in place. This includes assurance that:	OA-L1-02
The organisation’s Information Security Management System is compliant with ISO 27001 or an equivalent standard.	OA-L1-03
The organisation has an effective process for assessing and managing the risk associated with personnel.	OA-L1-04
The organisation has effective physical security measures in place that are capable of deterring a skilled attacker.	OA-L1-05
An assessment of the organisations IA maturity is at least Level 2. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), standards or guidance should be applied as specified by their business.	OA-L1-06
Relevant service design, implementation and operation standards (e.g. ISO 9000) from a UKAS accredited certification organisation.	OA-L1-07
Examples
Example services for which Level 1 organisational insurance is relevant include: a. A service that enables a client to purchase a low cost public sector publication over the Internet. The impact of failure is inconvenience and possibly recovering or refunding incorrect payments; b. A client requests general or case specific information from a public sector organisation which is needed to meet some obligation to a third party and which the department has a published commitment to supply promptly. The consequences of failure to obtain the information are inconvenience or delay but are not business critical.	OA-L1-08
Provision
The organisation is expected to have an Information Security Management System in place that is compliant with ISO 27001 (reference [y]) or equivalent standard. Effective security governance arrangements are expected to have been established. This includes a Board level Senior Information Risk Owner (SIRO) who: a. Is accountable; b. Fosters a culture for protecting and using data; c. Provides a focal point for managing information risks and incidents; d. Is concerned with the management of all information assets.	OA-L1-09
The SIRO is expected to be supported by an Accreditor who: a. Provides policy guidance to staff; b. Ensures ICT systems have accurate risk assessments in compliance with national and organisational policy; c. Audits all the security aspects of the Service Provider’s implementation of appropriately assured technical and nontechnical countermeasures, including reviewing all securityrelevant documentation; d. Formally accredits ICT systems on behalf of the SIRO/Board; e. Re-accredits ICT systems as required.	OA-L1-10
Personnel security aspects that should be considered include: a. Personnel with potential access to the information assets are expected to be subject to background checks. This includes checks on their identity and on their employment, academic and professional qualifications. References are expected to be checked by following up in writing with written evidence of all qualifications. b. Staff performing key management and security roles are likely to have at least three years’ service with the organisation. All personnel with access to information assets are expected to have been required to sign appropriate Confidentiality agreements. This agreement should expressly prohibit the unauthorised disclosure or amendment of information and should make clear the penalties if such incidents occur. c. Management responsibilities for security are expected to be defined. A formal disciplinary process is expected to be in place for dealing with employees who have committed a security breach. Staff duties are likely to be rotated in order to avoid dependency on key individuals and to allow any unauthorised activities to be identified by changing roles. d. Security awareness, education and training is provided to all staff including providing regular updates. e. Responsibilities for performing employment termination or change of employment activities are clearly defined. f. Procedures are in place to ensure all assets are returned when no longer needed and to cover the revocation of access rights. g. Good practice guidance on managing the risks associated with personnel may be found on the CPNI website (reference [cc]).	OA-L1-11
Physical security controls that are adequately resistant to unauthorised access are expected to have been implemented. These controls are likely to include: a. Segregated secure areas for accommodating information assets of particular sensitivity and to which only staff that have undergone an appropriate level of security checking would have access. b. Measures to manage the risk of computer screens or other documentation being overlooked by possible attackers are expected to have been implemented. c. Physical intrusion detection systems and access control systems are expected to be present; event information will be recorded and monitored. d. Access control systems uniquely identify every person entering the location. e. Security passes are expected to be issued to and worn by all authorised personnel with access to the location. f. There are likely to be frequent security guard patrols. g. Rigorous supervision of building and maintenance works is performed. h. Restrictions on staff carrying specified personal items, such as PDAs, USB and other storage devices, mobile telephones and cameras in sensitive areas are likely to be in place. i. Controls over the removal of assets from the location, including paper records and removable media are also in place. j. CCTV monitoring of sensitive areas as well as building entrances, exits, vulnerable points and perimeter is likely to be in place. k. The CPNI website provides guidance on identifying appropriate physical security controls (reference [aa]).	OA-L1-12
Audit of the ISMS, personnel and physical controls may be performed by a UKAS accredited ISO 27001 auditor.	OA-L1-13

Table 47 – Organisational Assurance Security Components at Level 1

Level 2 Organisational Assurance – Government Approved Assessment	Reference
All aspects of organisational assurance at Level 1 are required, plus the following additional requirements:
This statement is under development.	OA-L2-01
Requirements
Independent assurance is required that those involved in the provision of the service and the locations from which they provide the service have appropriate (commercial good practice) organisational, physical and personnel controls in place. This includes assurance that:	OA-L2-02
An Information Security Management System is in place that meets the requirements of HMG Security Policy Framework (SPF) (reference [j]).	OA-L2-03
Personnel controls are in place that meet the requirements of SPF Security Policy Number 3. Staff in privileged positions (e.g. system administrators) are likely to have at least SC clearances. Other staff are likely to have at least BPSS clearance.	OA-L2-04
Physical controls are in place that meet the requirements of SPF Security Policy Number 5.	OA-L2-05
An assessment of the organisations IA maturity is at least Level 3. For those mandated to do so, the relevant SPF Mandatory Requirements should be applied. For those not mandated to use the SPF (reference [j]), standards or guidance should be applied as specified by their business.	OA-L2-06
Relevant service design, implementation and operation standards (e.g. ISO 9000) from a UKAS accredited certification organisation.	OA-L2-07
Examples
Example services for which Level 2 organisational assurance is appropriate include: a. Electronic filing of income tax and Value Added Tax (VAT) returns; b. Services that give access to sensitive private information, for example a person’s medical record.	OA-L2-08
Provision
The organisation’s Information Security Management System is expected to be compliant with the Security Policy Framework (reference [j]).	OA-L2-09
All personnel with potential access to the service assets are expected to have been cleared in accordance with the BPSS. Higher levels of security vetting may be required for some key personnel (e.g. those with System Administrator privileges). Appropriate aftercare is expected to be provided.	OA-L2-10
The physical controls in place at the locations at which the service assets are located will have met the requirements stipulated in SPF Security Policy Number 5 for the storage and process of information with a protective marking of at least RESTRICTED. Higher levels of controls may be required for some services.	OA-L2-11
Assurance that the organisation meets the required standard is expected to be obtained through audits performed by Defence Security Standards Organisation, CESG, the relevant Departmental Security Officer or another organisation approved by the Departmental Security Officer.	OA-L2-12
Certification of compliance with ISO standards is expected to be provided by a UKAS accredited organisation.	OA-L2-13

Table 48 – Organisational Assurance Security Components at Level 2

Technical Assurance

The Technical Assurance security component covers the technical review of the totality of an e-Government service to ensure that it is designed, implemented, configured, maintained and operated in accordance with the security requirements.

Level 0 Technical Assurance – no statement	Reference
This statement is under development.	TA-L0-01
Requirements
There is no requirement for assurance that the security requirements are met by the service.	TA-L0-02
Examples
An example of a service that falls into this category is the provision of a public website that provides general publicly available information for which a breach in the security of the service is expected to have a minimal impact.	TA-L0-03
Provision
While formal independent security assurance that the security requirements are met by the service is not required, a systematic approach to the design, implementation, configuration, maintenance, operation and disposal is expected to be adopted. The key stage in the development of a service and security expected at each stage are as follows:	TA-L0-04
Service concept development - as part of service concept development a security concept is expected to be produced describing the eGovernment service, the top-level threats and the likely nature of the countermeasures.	TA-L0-05
Service requirements specification and review of compliance - During this stage it is expected that the following security activities will be performed: a. Analyse the threats and vulnerabilities to the system and produce a risk assessment; b. Produce an outline risk management and Accreditation Document Set.	TA-L0-06
Service design, implementation and test - During this stage it is expected that: a. A structured design technique is used; b. The risks are addressed by appropriated countermeasures; c. The security countermeasures are documented in the security design document; d. The architecture is locked down to cover only required services, in line with good commercial practice; this is expected to be documented in the security design document; e. Comprehensive functional and non-functional testing of the business application(s) and the systems that host them to confirm their correct implementation; f. The system configuration is checked to be compliant with the risk management and Accreditation Document Set; g. The residual risks are assessed and either accepted or additional countermeasures identified until the risks are acceptable; h. Strong audit and accounting measures are implemented; i. Security operating procedures are established.	TA-L0-07
Service acceptance, including security accreditation - During this stage it is expected that the security countermeasures are tested and reviewed to ensure they meet the requirements.	TA-L0-08
Service delivery - During this stage it is expected that: a. The service is operated in accordance with the security operating procedures, including regularly monitoring system logs; b. The assurance status of the services is reviewed on a periodic basis to confirm the effectiveness of the countermeasures and security operating procedures and ensure any necessary enhancements are identified;	TA-L0-09
Service close down - During this stage it is necessary to ensure that information assets are removed and transferred to a successor service, if appropriate, destroyed or stored securely in accordance with the service specific security policy.	TA-L0-10
At this level the service delivery manager produces the risk management and Accreditation Document Set including performing the risk assessment and identifying the appropriate countermeasures are identified. The Accreditor is expected to accept these at face value.	TA-L0-11
Key security enforcing functionality would be expected to be provided by good commercial products. These products would not however, be expected to have undergone formal assurance.	TA-L0-12

Table 49 – Technical Assurance Security Components at Level 0

Technical Assurance at Level 1 – Independent Assessment	Reference
All aspects of technical assurance at Level 0 are required, plus the following additional requirements:
At Level 1 there is a requirement to obtain independent assurance that the service is operated in accordance with good practice.	TA-L1-01
Requirements
The measures identified at Level 0 are to be covered. In addition, at Level 1:	TA-L1-02
A formal system development cycle is to be followed.	TA-L1-03
Security enforcing functionality used by the service is required to be provided by appropriately evaluated products.	TA-L1-04
A quality review of the service implementation is expected to be carried out by independent policy auditor (2) prior to the service going live, after any major changes, and periodically during its life.	TA-L1-05
Verification of the implementation carried out by independent compliance auditors (3) prior to service go live. During the in-service phase, after any significant change to the service and periodic (normally yearly) during its life re-verification of the system is expected.	TA-L1-06
Examples
Example of a service that falls into this level include: a. On-line purchase of low cost public sector publications; b. On-line purchase of vehicle tax disks.	TA-L1-07
Provision
At this level a formal system development lifecycle is expected to be followed. Sign off of all elements of development is expected before they go into production.	TA-L1-08
A clear documented design that has been subject to rigorous peer review is expected to have been produced.	TA-L1-09
Software coding standards are expected to have been developed and implemented to ensure consistent and secure code is developed. The code is expected to be documented and reviewed to support validation. Code review is likely to include review by independent third parties. A Gold Build State of software developed and off-the-shelf software that is used is expected to be established. Module level, system-level and overall testing of the software is expected to be performed. This is expected to include final user acceptance testing that would include confirmation that security needs are met. Security testing is expected to include penetration testing (including at the application level). Measures are expected to be in place to ensure the integrity of built system components is maintained while awaiting deployment.	TA-L1-10
Formal configuration and change management procedures are expected to be in place. Configuration control is audited and monitored and all changes documented. Any changes to the system are subject to acceptance testing within a reference facility environment prior to implementation in the operating environment. Formal sign-off of a change by the design authority will occur before the changes are made within the operational environment.	TA-L1-11
All hardware and software used for security critical roles will be purchased from trusted sources (i.e. whose security interests are aligned with those of the stakeholders). If trusted sources cannot be used, specific steps will have been taken to gain assurance that hardware and software products can be trusted.	TA-L1-12
Products providing security enforcing functionality should have been certified using the CESG CPA certification to at least foundation grade (reference [o]).	TA-L1-13
Appropriately accredited independent security experts (e.g. CLAS consultants) assess the security architecture to confirm that it meets the security requirements. CTAS, CREST, TIGER or CHECK approved suppliers might perform the security compliance audits.	TA-L1-14

(2) One possibility is the use of CLAS consultants.
(3) Through the use of, for example, CHECK, CREST or TIGER consultants.

Table 50 – Technical Assurance Security Components at Level 1

Level 2 Technical Assurance – Government Approved Assessment	Reference
All aspects of technical assurance at Level 1 are required, plus the following additional requirements:
This statement is under development.	TA-L2-01
Requirements
The requirements at Level 2 are similar to those at Level 1 except that:	TA-L2-02
Key security enforcing functionality used by the service is required to be provided by appropriately Government approved or higher assurance evaluated commercial products.	TA-L2-03
Policy and compliance audits are required to be performed by CESG approved auditors.	TA-L2-04
Examples
Example services for which Level 2 organisational assurance is appropriate include: a. Electronic filing of income tax and Value Added Tax (VAT) returns; b. Services that give access to sensitive private information, for example a person’s medical record.	TA-L2-05
Provision
Provision at Level 2 will be similar to Level 1 except that:	TA-L2-06
It would be expected that CTAS, CLAS or CESG are used to validate the overall system design. CESG or a CHECK green light accredited organisation is expected to be used to perform a comprehensive health check of the overall service (unless this has been performed by a CTAS organisation).	TA-L2-07
Components used within the system are likely to be standard commercial products. Products providing security enforcing functionality that the service relies on will have been subject to independent assurance. Where appropriate, products should have been certified using the CESG CPA certification to at least foundation grade (reference [o]) or CAPS (reference [o]).	TA-L2-08

Table 51 – Technical Assurance Security Components at Level 2

References

[a] CESG Good Practice Guide No. 43, Requirements for Secure Delivery of Online Public Services, Issue 1.1, December 2012. Available from the CESG website.

[b] CESG Good Practice Guide No. 43, Annex A, Requirements for Secure Delivery of Online Public Services, Issue 1.1, December 2012. Available from the CESG website.

[c] CESG Good Practice Guide No. 45, Validating and Verifying the Identity of an Individual in Support of HMG Online Services, Issue 1.0, April 2012. Available from the CESG website.

[d] CESG Good Practice Guide No. 46, Validating and Verifying the Identity of a business or other organisation to HMG Online Services, currently in development.

[e] CESG Good Practice Guide No. 44, Authentication Credentials in Support of HMG Online Services, Issue 1.1, December 2012. Available from the CESG website.

[f] ‘Level 2, Remote Authentication’, IMSPG (02) 05, 2008.

[g] CESG guidance on biometrics, available from the CESG website under the policy and guidance section at www.cesg.gov.uk.

[h] Privacy Engineering, S Marsh, I Brown, M Khaki, Cybersecurity KTN, 2008.

[i] Privacy Impact Assessment Handbook, Version 2, Information Commissioner’s Office.

[j] HMG Security Policy Framework (SPF), Tiers 1-3 (Not Protectively Marked), available at http://www.cabinetoffice.gov.uk.

[k] `Clinical Systems Security – Implementing the BMA Policy and Guidelines’, A Hassey, M Wells, see also ‘Security Engineering, R Anderson, Second Edition, Wiley, 2008.

[l] ‘Implementing access controls to protect the confidentiality of patient information in clinical information systems in the acute hospital, I Denley, S Weston-Smith, Health Informatics Journal v 4, December 2008. See also, ‘Privacy in Clinical information systems in secondary care’ British Medical Journal’, I Denley, S Weston-Smith, May 1999. See also, ‘Security Engineering, R Anderson, Second Edition, Wiley, 2008. Page 168

[m] Implementing summary care records guidance, Connecting for Health, available from http://www.connectingforhealth.nhs.uk/systemsandservices/scr/staff/impguidpm/ ig.

[n] Security Compliance Management Toolkit, available at, http://technet.microsoft.com/en-us/library/cc677002.aspx.

[o] Common criteria for information technology security evaluation, available at: http://www.commoncriteriaportal.org/.

[p] CESG guidance, available from the CESG website (www.cesg.gov.uk), under the service catalogue section.

[q] CREST approved providers, information available from http://www.crestapproved.org/

[r] ISO/IEC TR 18044 - Information technology – Security techniques – Information security incident management, International Organisation for Standardisation, 2004.

[s] ISO/IEC 20000-1 Information Technology Service Management, Part 1 Specification, International Organisation for Standardisation, 2005.

[t] ISO/IEC 20000-2 Information Technology Service Management, Part 2 Code of Practice, International Organisation for Standardisation, 2005.

[u] BIP 0008-1 - Evidential Weight and Legal Admissibility of Information Stored Electronically. Code of Practice for the Implementation of BS 10008, BSI, 2008.

[v] BIP 0008-2 - Evidential Weight and Legal Admissibility of Information Transferred Electronically. Code of Practice for the Implementation of BS 10008, BSI, 2008.

[w] BIP 0008-3 - Evidential Weight and Legal Admissibility of Linking Electronic Identity to Documents. Code of Practice for the Implementation of BS 10008, BSI, 2008.

[x] T-scheme, information available from the t-scheme website at http://www.tscheme.org/

[y] ISO/IEC 27001 – Information technology – Security techniques – Information security management systems – Requirements, International Organisation for Standardisation, 2005. Page 169 Requirements for Secure Delivery of Online Public Services – Annex B

[z] A good practice guide on pre employment screening, CPNI, 2nd Edition. Available from the CPNI website, see www.cpni.gov.uk.

[aa] CPNI guidance on physical security controls is available from the CPNI website at www.cpni.gov.uk.

[bb] IT Infrastructure Library, information available from the ITIL website at http://www.itil-officialsite.com/home/home.asp.

[cc] CPNI guidance on personnel security is available from the CPNI website at www.cpni.gov.uk.

Customer Feedback

CESG Information Assurance Guidance and Standards welcomes feedback and encourage readers to inform CESG of their experiences, good or bad in this document. We would especially like to know about any inconsistencies and ambiguities. Please use this page to send your comments to:

Customer Support CESG A2b Hubble Road Cheltenham GL51 0EX (for the attention of IA Policy Development Team)

Fax: (01242) 709193 (for UNCLASSIFIED FAXES ONLY) Email: enquiries@cesg.gsi.gov.uk

For additional hard copies of this document and general queries please contact CESG enquiries at the address above.