Search - National Standard Microsite

All public services sending emails out on behalf of government organisations must follow all protocols, processes and guidelines to ensure that they secure their email service. This includes:

• the service providing users with mailbox access

• internal relays and gateways

• email filtering services

• third party services that send email on your behalf, like transactional email services

Key configurations are needed to ensure you email services run smoothly:

• Transport Layer Security (TLS)

• DomainKeys Identified Mail (DKIM)

• Domain-based Message Authentication, Reporting & Conformance (DMARC)

• Public Domain Name System (DNS)

• Ability to make administrative changes

If there are any changes made to your email security, ensure that you communicate such changes to all staff in your organisation.

This guidance applies to all email domains that public sector organisations run on the internet. It also helps ensures that public sector organisations exchanges email securely with other public sector organisations. Protecting emails in transit makes it difficult for domains to be spoofed.

All public sector emails must be kept secure by:

• encrypting and authenticating email in transit by supporting Transport Layer Security (TLS) and Domain-based Message Authentication, Reporting and Conformance (DMARC) as a minimum

• making sure the recipient protects the data you send to them

• making email security invisible to end users as far as practically possible

Encryption and authentication only work if both the sender and the recipient use them.

The Government Digital Service recommends protecting email by:

• forcing TLS when sending to .gov.uk

• forcing TLS when sending to any other domains that supports it if the local risk profile requires it

• using extra encryption services if needs be

DomainKeys Identified Mail (DKIM) verifies an email’s domain and ensures it has not been tampered with in transit. The receiving email service can then filter or reject email that fails the DKIM check. In order for DKIM to verify an emails domain it uses public key encryption to check email by creating a hash using the content of each outbound email. The sending service then encrypts the hash with its private key and adds it to the email header. This is the DKIM signature.

The receiving email service looks up the public key in the sender’s DKIM DNS (DOMAIN NAME SYSTEM) record then uses the public key to decrypt the DKIM signature on the email. It also generates a hash of the email in the same way the sending email service did. If the hash matches the decrypted DKIM signature then the email passes the DKIM check. This means the email came from where it says it came from and has not changed in transit.

An agreed and designed common data standards are used by the Criminal Justice System, ICT suppliers to support ICT communications between systems used by Criminal Justice Organisations (CJO) to support CJS operations. They are also used with open data standards as defined in the government’s Open Standards Principles. These common standards are also used to support data analytics, bidding for CJS contracts etc.

The selection of the CJS data standards is made by the CJS Data Standards Forum. This is a technical forum which has representatives from the principal CJOs.

There is a Data Standard Catalogue used to support the exchange of criminal justice information between different CJOs.

There are three different types of data standard reflected in the catalogued:

• formatting standards

• organisational structure standards

• reference data standard

The Data Standard catalogue is constantly reviewed by the Data Standards Forum to ensure a set of standards is produced that is as small as possible while still being fit for purpose. 

The End User Device (EUD) Security Principles sets out 12 core guidance principles that underpin the safety and security of using devices that serve the purpose of working remotely. The twelve principles are as follows: 

1. Data-in-transit Protection: Data should be protected as it transits from the EUD to any services the EUD uses. 

2. Data-at-rest Protection: Data stored on the device should be satisfactorily encrypted when the device is in its “rest” state. 

3. Authentication:

- User to device: the user is only granted access to the device after successfully authenticating to the device.

- User to service: The user is only able to access enterprise services after successfully authenticating to the service, via their device.

- Device to service: Only devices which can authenticate to the enterprise are granted access.

4. Secure Boot: An unauthorised entity should not be able to modify the boot process of a device, and any attempt to do so should be detected.

5. Platform Integrity and Application Sandboxing: The device can continue to operate securely despite potential compromise of an application or component within the platform, 

6. Application allow Listing: The enterprise can define which applications are able to execute on the device, and these policies are robustly enforced on the device.

7. Malicious code detection and prevention: The device can detect, isolate and defeat malicious code which is present on the device.

8. Security policy enforcement: Security policies set by your organisation are robustly implemented across the platform.

9. External interface protection: The device is able to constrain the set of ports (physical and logical) and services exposed to untrusted networks and devices. 

10. Device Update Policy: You are able to issue security updates and can remotely validate the patch level of your entire device estate.

11. Event Collection for Enterprise Analysis: The device reports security-critical events to your audit and monitoring service. 

12. Incident Response: Your organisation has a plan in place to respond to and understand the impact of security incidents.

All of these principles must be considered when securing and deploying devices.