Cloud Security Principle 1: Data in transit protection

Created:  21 Sep 2016
Updated:  21 Sep 2016
User data transiting networks should be adequately protected against tampering and eavesdropping. 

This should be achieved through a combination of:

  • network protection - denying your attacker the ability to intercept data
  • encryption - denying your attacker the ability to read data



You should be sufficiently confident that:

  • Data in transit is protected between your end user device(s) and the service
  • Data in transit is protected internally within the service
  • Data in transit is protected between the service and other services (e.g. where APIs are exposed) 

Implementation approaches - Data in transit protection





Private WAN service

You access the service via a private WAN circuits offered by a telecommunications provider.Privacy between different customers of private WAN services is typically by virtue of the routing protocols used, such as MPLS.

Using private circuits will make it more difficult for an attacker to gain access to communications. These connections do not normally provide cryptographic protectionbut are likely to be hard to intercept and process, which may be adequate for your needs.

Cryptographic protections, should you choose to deploy them, would provide greater confidence in the protection of the confidentiality and integrity of your communications.

Public sector organisations can procure circuits which connect to the Public Services Network (PSN). This WAN, and the providers who give access to it, have had their services assessed against the CESG Assured Service (Telecoms) scheme.


Legacy SSL and TLS

The service is accessed using SSL or legacy versions of TLS (including TLS versions below 1.2).

Use of SSL or TLS versions earlier than version 1.2 is not recommended. There are known vulnerabilities in protocols which could be manipulated by an attacker to access your data.


TLS (Version 1.2 or above)

Use of TLS, configured to use cipher suites and certificate sizes recommended in our TLS guidance.

The lack of formal assurance in TLS implementations means there may be implementation weaknesses. Using recent, supported and fully patched versions of TLS implementations from reputable sources will help to manage this risk.


IPsec or TLS VPN gateway

The service exposes a TLS or IPsec VPN Gateway which can be configured to support a strong cryptographic profile. 

See our advice on IPsec and TLS configuration to ascertain whether the gateway supports a good profile.

Also, a list of VPN products which have been assessed against our Commercial Product Assurance scheme is available here.


Bonded fibre optic connections

Bonded fibre optic connections between physically protected locations can be used to provide private connections between data centres. 

Independent validation of the service provider’s implementation of their bonded fibre optic connections by a recognised expert is advisable.

Note that the security of these links is dependent on effective monitoring - this should be one of the considerations for any independent validation of the security provided.



Additional notes – Points of attack

To compromise data in transit, an attacker would need access to infrastructure over which the data transits. This could take the form of physical access, or logical access if the attacker has compromised software components within the service.

It’s more likely that attackers would access infrastructure between the user and the service, as opposed to infrastructure within the service. However, the impact of an attacker accessing communications internal to the service would likely be significantly greater.

Additional notes – TLS

In addition to network layer protections across internal or community networks, you should use TLS protection for the following scenarios:

  • if additional confidentiality of data within your organisation or community is required
  • to support end user authentication and access control within applications

Additional notes – Joiners and Leavers

On-boarding and off-boarding of users and workloads may involve the transfer of bulk data into or out of the service. In this scenario, you should consider the protection of data during transit using one of the approaches described above. If storage media is being used to transit data, this should be protected in line with Principle 2: Asset protection and resilience.


next principle >

Was this guidance helpful?

We need your feedback to improve this content.

Yes No