William T. (Tim) Shaw
PhD, CISSP / CIEH / CPT

On the front cover of a recent edition of CONTROL magazine the editors highlighted (as they put it) a growing trend among automation vendors and plant owners towards enabling remote electronic access to plant systems for the purpose of enabling rapid (remote) vendor support, access by plant personnel who are off-site and access by corporate IT support personnel and users.

Aside from pointing out that this is far from a recent trend (vendors enabled dial-in phone access as far back as the 1980s and migrated to access over the Internet in the 1990s) it also highlights the constant battle between what is secure and what is convenient. To be fair, the editors did point out that the available technologies used for remote access were more varied today than in the past. As a former vendor I can vouch for that statement.

In the 1980s we usually employed ‘dumb’ terminals to interact with remote customer systems via character-oriented command line interfaces (think the DOS command tool in Windows or telnet), all connected via analog dial-up phone lines running at blinding 2400/4800 bits/second. In the 1990s we switched to graphical X-terminals and much faster modems (or even Internet connectivity) for remote access. In the 2000s, as Microsoft’s Windows operating system became the predominant platform for much of the automation technology, and Internet connectivity became ubiquitous, we often used the Remote Desktop capabilities (or commercial products with similar capabilities) to connect to distant systems. Today a system, and even a rack or skid of equipment, may come with an embedded cellular gateway that allows the vendor to make a direct connection to the equipment through the 3G/4G cellular phone system and to interact with the system/equipment via a web interface. (And the customer may not even be aware that this capability exists!)

In general terms, any such remote access capability would be seen as a highly desirable attack pathway by someone trying to gain malicious access to your systems and networks. Obtaining remote access means not having to breach your physical security mechanisms and a much lower chance of an attacker getting caught. There are many techniques available for breaking into and hijacking a TCP/IP communication session. Similarly there are attack methodologies for gaining unauthorized access to wireless networks. Breaking into an analog phone connection is mere child’s play in comparison (and something hackers have been able to do for years). So although enabling remote access to critical systems is very convenient, it carries a high risk if not done well.

Two major differentiations need to be made about remote access and they involve endpoint security. If remote access to your critical systems is only allowed from a fixed location (or a small set of them) that is (are) also controlled by your organization, then you can probably provide adequate endpoint security. You can control the equipment used to make the remote connection. You can control access to that equipment. You may even have control over the communications channels used. And you can manage and limit the personnel who are given the credentials used to establish remote access.

On the other hand, if you have the more typical kind of remote access, you merely provide an ‘open to all comers’ access point (e.g. a VPN gateway facing out to the Internet) and hope that your security mechanisms are adequate to fend-off the people who periodically attempt to gain unauthorized access.

The amount of physical security and cyber security required to adequately ensure that remote access will not be co-opted by a malicious actor depends on a range of factors, and most particularly on the trustworthiness of the networks used and the physical facilities/locations from which access is initiated. I broadly categorize remote access into three slightly different scenarios:

• Remote within the physical constraints of a plant/facility – In this scenario you control the physical security and access, the communication infrastructure used (typically a private LAN) and personnel access authorization.
   
• Remote within a corporate wide-area network that uses “private” infrastructure – In this scenario you have endpoint control, although it may vary from location to location without the corporation. You control the communication infrastructure and connections thereto and personnel access authorization. Of course there is a much greater “attack surface” in this scenario due to the number of personnel with WAN access.
   
• Remote across public networks, particularly the Internet or the phone system (wired/cellular) – In this scenario you only control the physical security and personnel access at your ‘end’ of the connection. Anyone with access to the public network can attempt to make an unauthorized connection into your systems.

One of the biggest problems with ‘typical’ remote access (the third scenario above) is the lack of control over what is happening at the other end of the connection. If a vendor is granted remote access to your systems then you have to be concerned about their physical security, their vetting of authorized personnel and their management of the systems and credentials used to establish such remote access. As a threat agent who wants to attack your critical systems I might find it much easier to penetrate or compromise a vendor organization with lax security and procedures then to try and attack you directly.

This notion brings up the whole issue of supply chain vulnerabilities. The term “remote access” takes on other meanings if I elect to use your vendor’s organization to attack your systems. What kind of procedures do you use to validate and verify the software updates and patches sent to you by your vendors? Do you just install them with no questions asked? Lots of organizations do.

It is possible to enable remote access to critical systems in a manner that provides high assurance of adequate cyber security. This is more than just setting up a VPN gateway and issuing credentials. Of course having strong encryption and strong authentication are a necessary component. But, there also have to be procedures in place, and suitable physical security, at the remote end. Your procedures have to consider the possibility of endpoint compromise; whether it is a stolen company laptop with your client VPN software or a malicious actor (or intimidated employee) in the remote organization. There are well understood techniques used to address these issues … but that will be the subject matter for a future column. – Tim.

About the Author

Dr. Shaw is a Certified Information Systems Security Professional (CISSP), a Certified Ethical Hacker (C|EH) a Certified Penetration Tester (CPT) and has been active in industrial automation for more than 35 years. He is the author of Computer Control of BATCH Processes and CYBERSECURITY for SCADA Systems. Shaw is a prolific writer of papers and articles on a wide range of technical topics has also contributed to several other books and teaches several courses for the ISA and participates in several committees. He is currently Principal & Senior Consultant for Cyber SECurity Consulting, a consultancy practice focused on industrial automation security and technologies. Inquiries, comments or questions regarding the contents of this column and/or other security-related topics can be emailed to timshaw4@verizon.net.