Security standard SS-007: Use of Cryptography

Q: 3. Approval history

Version Role Date 1.0 Chief Security Officer 02/04/2017 2.0 Chief Security Officer 07/12/2022 2.1 Chief Security Officer 25/03/2025 This document is continually reviewed to ensure it is updated in line with risk, business requirements, and technology changes, and will be updated at least every 2 years - the current published version remains valid until superseded.

Question 1

1.  Table 1 – Terms

Accepted Answer

Term	Intention
must	denotes a requirement: a mandatory element.
should	should denotes a recommendation: an advisory element.
may	denotes approval.
might	denotes a possibility.
can	denotes both capability and possibility.
is/are	is/are denotes a description.

Question 2

2.  Revision history

Accepted Answer

Term	Intention
must	denotes a requirement: a mandatory element.
should	should denotes a recommendation: an advisory element.
may	denotes approval.
might	denotes a possibility.
can	denotes both capability and possibility.
is/are	is/are denotes a description.

Question 3

3.  Approval history

Accepted Answer

Term	Intention
must	denotes a requirement: a mandatory element.
should	should denotes a recommendation: an advisory element.
may	denotes approval.
might	denotes a possibility.
can	denotes both capability and possibility.
is/are	is/are denotes a description.

This document is continually reviewed to ensure it is updated in line with risk, business requirements, and technology changes, and will be updated at least every 2 years - the current published version remains valid until superseded.

Question 4

4.  Compliance

Accepted Answer

Compliance with this standard will be verified through various methods, including but not limited to;

controls tests performed by 1st line teams and by 2nd line activities (e.g. security testing teams)
security assurance activities to ensure that Architectural Design and delivery are appropriate and aligned to applicable Authority Security Standards [See Security Assurance Strategy – Ref. D]
independent external audit

Results of these will be fed back to the appropriate Authority Risk and System Owners.

Question 5

5.  Exceptions Process

Accepted Answer

(Important) this paragraph contains ‘must’ activities.

In this document the term “must” is used in bold letters to indicate a mandatory security measure. Any exceptions to the application of this standard, or where specific security measures cannot be adhered to, must be presented to the Authority. This must be carried out prior to deployment and managed through the design caveats or exception process. 

Such exception requests will invoke the Risk Management process to clarify the potential impact of any deviation to the configuration detailed in this standard.  

Exceptions to the standard must be maintained on a risk register for accountability, traceability, and security governance reporting to senior management.

Question 6

6.  Audience

Accepted Answer

This document is intended for, but not necessarily limited to, technical architects, engineers, developers, security teams, project teams, including suppliers engaged in the design, development, implementation and operation of systems, services and applications. It must be applied in the design, assurance, and audit of cryptographic controls deployed across the Authority and supplier base where applicable.

Question 7

7.  Accessibility statement

Accepted Answer

(Important) this paragraph contains ‘must’ activities.

Users of this standard must consider accessibility design requirements as appropriate.  Further information on accessibility standards can be found in Appendix F.

Question 8

8.  Introduction

Accepted Answer

(Important) this paragraph contains ‘must’ activities.

This standard defines a set of minimum-security measures that must be met when implementing cryptographic controls for the purposes of mitigating risks, or to comply with legal and regulatory requirements or both. When considering risk, an assessment must include consideration of mitigating factors and compensating controls.

Cryptographic controls must be implemented whenever it is necessary to protect the confidentiality and integrity of electronic information in transit or at rest from threats facing the Authority. Threats can be physical or logical in nature such as media containing sensitive data being stolen, or hackers sniffing data packets across the network. Cryptographic controls can also be used to authenticate the identities of both the sender and recipient to one another and protect against repudiation.

Below are some examples of when cryptographic controls must be used:

Sending sensitive data over an untrusted network e.g., between two endpoints over the internet
Storing sensitive data in a multi-tenanted cloud hosted environment e.g., passwords, personal citizen information
Connecting remote workers from home to access the Authority’s network
Protecting citizen data at rest e.g., in databases or object stores
To comply with legal or regulatory requirements

One of the biggest challenges that cryptography faces today is the future threat from substantially more powerful quantum computers. Quantum computing leverages the properties of quantum physics to perform operations that are impossible or impractical for classical computers, and thus has the potential to impact asymmetric, and to a lesser extent symmetric cryptographic operations. To address this challenge, post-quantum cryptography (PQC) algorithms are being developed that are resistant to quantum attacks. See ‘NIST Post-Quantum Cryptography’ and ‘NCSC: Post-Quantum Cryptography – what comes next ?’ [External References].

See the DWP Approved Cryptographic Algorithms document [Ref. B] for approved algorithms.

It should also be noted that weak passwords, social engineering attacks, and accidental data exposure are common pitfalls in maintaining secure encrypted systems, so a ‘defence-in-depth’ approach must be followed to protect Authority data.

As this standard only provides minimum measures, they should be exceeded as appropriate depending on the threats and risks that need to be addressed, the sensitivity of the data, and in keeping with latest security enhancements.  

The security measures are derived from industry best practice i.e., guidance published by NIST, CIS and OWASP (see Appendix C for full list external references) and support the implementation of appropriate security controls as selected by DWP or our third-party providers, such as the CIS Critical Security Controls set. [see External References]

Every effort has been made to ensure the security measures are vendor and technology agnostic as far as possible; this is to ensure greater applicability of the standard regardless of the technologies used. The security measures may be implemented in different ways, depending on the technology choices and business requirements in question.

The aim of this standard is to:

enable technical teams to work towards a set of minimum-security measures which are based on industry best practice
ensure cryptographic controls are designed, developed, and deployed consistently respecting the cryptographic manual on which validation was awarded
ensure cryptographic controls are configured to only use Authority approved cryptographic algorithms as defined in DWP Approved Cryptographic Algorithm document [Ref. B]
enforce the use of independently assured cryptographic products where needed

Technical security standards ultimately support the achievement of security outcomes sought by the Authority. They set the expectations for what needs to be done to achieve them and why, and provide an objective, measurable statement of the Authority’s existing security posture in a number of important areas. The outcomes are based on the official NIST sub-categories where possible to ensure close alignment with the NIST Cyber Security Framework (CSF), and are enabled by the implementation of controls from the CIS Critical Security Controls set. [see External References]. Those relevant to the subject of each standard can be found in Appendix A of every technical security standard.

Question 9

9.  Purpose

Accepted Answer

The purpose of this standard is to ensure systems and services utilising cryptography to encrypt Authority data are designed, configured, deployed, and managed consistently to protect against typical threats at the OFFICIAL tier.  

This standard also serves to provide a baseline in which assurance and compliance activities can be carried out, so that the Authority can be assured that security obligations are being met or exceeded.  

Question 10

10.  Scope

Accepted Answer

(Important) this paragraph contains ‘must’ activities.

This standard must be applied whenever it is determined that cryptographic controls are required following a security risk assessment process or to satisfy legal and regulatory requirements. Therefore, all the Authority’s ICT systems, networks, and end user devices including portable storage devices are in scope of this standard.

There are however certain measures regarding the use of cryptography in the cloud deliberately excluded from this standard, as this is covered in SS-023 – Cloud Computing Security Standard [Ref. C]. As such, this standard must be read in conjunction with SS-023.

It should also be noted that while key management is a fundamental aspect of ensuring the security of information protected by cryptography, this area is outside of the scope of this standard and is covered elsewhere in SS-002 PKI and Key Management Security Standard [Ref. D].

Where FIPS 140 is referenced, the dash numbers are not included e.g. FIPS 140-2. The reason for this is that these represent versions of the standard that are valid for a period of time for certification to be issued against. These certificates have a defined lifespan, so that older versions of the FIPS 140 standard expire over time. Hence newer versions of the FIPS standard are automatically covered.

The security measures must be applied to new and existing installations, and adherence to these measures must be included in all contracts for outsourced services where applicable.

Any queries regarding the security measures laid out in this standard must be sent to an assigned DWP Security Architect or Project Team Lead.

Question 11

11.  Minimum Technical Security Measures

Accepted Answer

(Important) this paragraph contains ‘must’ activities.

The following section defines the minimum security measures that must be implemented to achieve the security outcomes described in Appendix A. For ease of reference, the official NIST sub-category ID is provided against each security measure e.g. PR.PT-3, to indicate which outcome(s) it contributes towards. Refer to Appendix A for full description of outcomes.