Hidden dangers of remote management

In Secure remote management for ICS I have written and stated that you can have a secure remote management solution / setup for ICS environments.

Having a centralized, time based, source IP controlled, strong authenticated, monitored and logged solution is good and secure – but remains limited to your environment. Nevertheless, there are hidden dangers to any remote management solution which focuses solely on the internal environment.

I see the following potential dangers with any remote management connection to your OT environment (actually this is true for any environment).

1. You don’t know who is actually using the remote connection
2. You don’t know the security of the device used to connect to your environment
3. You don’t know the security of the network environment from where the connection is made

You don’t know who is actually using the remote connection – for all that you know, the person that “should-be-using-the-remote-connection” is really that person that should be using it or has been granted the right to do so. However, as you do not see him (or her) in front of you, this might be a false assumption. And even if it is the correct person, (getting really paranoid now) he could have been forced by an adversary to login to your environment and then hand over control to that adversary. Or he could have been forced into handing over his/her credentials to facilitate a login by adversaries.

You can apply one or several of the following mitigating activities to counter these:

• keep a remote access token at your premises. Whenever remote access is needed by that particular person, they will have to call you to get the code.
• Use a Skype video call to verify that the person is who he claims to be (you can also use other video call solutions of course)

You don’t know the security of the device used to connect to your environment. That is in that case when somebody is connecting to your environment using their personal devices or their own company devices. Another example of this case could be that these systems used to connect could have been hacked and the persons using those have lost control of their equipment.

Things that could be done here are:

• Distribute company controlled devices to everybody in need of network based remote access (if that person needs to connect to several systems directly from the remote laptop for example) – however you have to be able to manage those distributed devices then
• Use a “remote access (virtual) desktop environment” through which all remote management traffic is to be done (in a controlled manner)
• Do not allow disk/folder/printer/clipboard sharing through the remote (virtual) desktop but use a secure file transfer solution and thoroughly scan every single file being transferred through this solution.
• Enforce the remote end to give proof of the security of the device

You don’t know the security of the network environment from where the connection is made. All to may times I see a remote support VPN connection without any limitation on the destination ports or IP addresses (they have to be able to support everything, no?) although there might be a potential limitation in source IP address/range. This however opens the logical doors for network based attacks and/or malware infections coming from the remote maintenance provider.

• You should certainly limit access to your network environment from remote locations, especially within ICS environments where consequences might be just that tiny bit bigger…
• You might also require the remote maintenance provider to give proof of their network setup and security
• If such proof can not be given, you might want to enforce them to let you perform a security assessment on their support environment