Security Principle Number 1 - Protecting Data In-Transit

2 minute read

This post has been archived

What’s difficult about protecting data sent from A to C, via B – but is applying encryption and hashing end-to-end the answer; or are there better ways? The protection of data at rest, or in-transit should be fundamental to the aims of all organisations; of course the more valuable or sensitive the data, the greater the protection that should be afforded. But what is being protected? In the case of data-in transit the aim is to protect its Confidentiality and Integrity – which means protecting the data from eavesdropping and tampering/degradation. Ordinarily this is done through applying encryption (making it harder for an attacker to read) and network protection (making it more difficult for an attacker to intercept). But if you’re connecting to cloud services outside your organisation’s direct control is there a problem? Consider this, there are typically 3 parts to the journey of the data: From the originating system to the boundary of your organisation; From the boundary of your organisation to the boundary of your service providers infrastructure; and From the boundary of you service provider’s infrastructure to the destination system. In considering it in this manner, your organisation has direct control of one of the steps (your infrastructure), and significant influence over the third (your service provider’s infrastructure). So before discussing the middle portion we should consider the importance of providing an appropriate degree of protection to the data within these steps; therefore don’t rely on encryption and hashing. Deploy detection and protection systems, conduct cyber-analysis, and provide end-user training within your infrastructure. Ensuring similar levels of are deployed within that of your service provider. Now to discuss step 2 and what should be considered. The first approach is the use of assured components; whether by using fully managed and controlled HMG community wide network interconnects such PSN, GCSX, GSI, RLI or other accredited Multi-Protocol Label Switching (MPLS); or assured IPsec VPN gateways. Network interconnects can be either encrypted or in-the-clear, though technical and security requirements for the connection can be obtained from the interconnect’s service provider. Advice on the selection and deployment of the appropriate grade of the VPN gateway (foundation or enhanced) will again dependent upon the classification/sensitivity of services, and should be sought from CESG. Another approach is the use of assured bonded fibre connections, delivered and maintained by the service provider. The service provider will give assurances with regards their implementation and monitoring of this approach which should be studied; and like in Part 1 of this series I would definitely recommend that these assurances are assessed and validated by suitably qualified and experienced individuals/organisations. An additional control which could be added, and can be deployed in all 3 stages is encryption; now I know that I said that this isn’t the be-all and end-all, but it is important. Therefore the use of TLS, whilst not providing formal assurance, will support the protection of data in-transit. However it should be noted that most accreditors will insist on the use of TLS version 1.2 (or later). So that’s it data in-transit; to sum up, secure the end-infrastructures (including session level encryption) and select a an appropriate and secure inter-site transmission infrastructure … simples!