Answer yes if your organisation forces all remote connections to its network infrastructure or cloud environment to be secured with a suitable solution such as a VPN or SSH connection.
What is the control?
Without encryption, remote communication sessions are essentially sent in plain text and are open to eavesdroppers. This is because the transmission to the destination can take place over public and other untrusted networks that may be out of your control or compromised. It’s somewhat like communicating to someone across a crowded room by shouting at them.
Why should I have it?
If you connect to a system over the internet (or any other public network, or even other parts of your own network) any individuals with access to any of the network segments along the path of your session to its destination can see the data you are sending and receiving, including your credentials.
Historically, a protocol called Telnet was used for connecting to and managing remote systems. This protocol was however in plain text, meaning anyone monitoring the network would see the credentials used and be able to use them to access the system themselves. As a replacement, SSH, or “Secure SHell”, was created which had similar functionality, allowing remote [administrative] access, but this time using encryption so that the sessions could not be eavesdropped on.
Virtually all modern communication protocols now feature encryption and it’s important to use them whenever possible, including between hosts on your internal network. This way, even if someone gains access to a machine on your network, they won’t automatically be able to listen to all the traffic on the segment (Technically they will, but it will be encrypted and therefore useless to them).
One common solution for remote connectivity is Virtual Private Networks (VPNs). A VPN creates an overarching and encrypted tunnel that covers all the communication being sent between the hosts forming the tunnel (typically the remote host and a VPN Gateway which gives access to the internal network). This means that everything in the tunnel is protected even if the individual sessions aren’t encrypted, and that it’s impossible for anyone outside the tunnel to see not just the content of each network packet but the packets themselves.
The VPN name comes from the fact that this tunnel effectively stretches the internal network out to the remote endpoint.
Your policy dictating standards for remotely accessing the internal network should specify that any connecting to resources on the internal network (with the exception of DMZ hosts) should be done over a VPN connection.
Most SSH or VPN connections rely on Public Key Infrastructure (PKI) to provide authentication. The NCSC have published some useful guidance on how to set this up securely.
With regards to using encrypted protocols in general, you should have a policy dictating that all communication protocols should be encrypted where possible and that unencrypted, or less secure alternatives, should be disabled so that users cannot accidentally use the less secure protocols where more secure ones are supported.
There are numerous consultancies or individual consultants that will be able to assist in crafting the correct security architecture in a way that meets your business and technical requirements.
If you would like to contribute to this article or provide feedback, please email knowledge@riskledger.com. Contributors will be recognised on our contributors page.