I have had lively discussions with a number of people regarding remote access, the Internet of Things (IoT) and cybersecurity. Man, oh man, are there ever many differing opinions and misconceptions.
What I really mean is that I want to discuss use cases with you—the “one size fits all” just doesn’t work. IT departments force-feed their solutions down the throats of their users in the name of security and ease of use. Some homegrown solutions are very valid, but most use open-source software where there is a blind trust. Virtual network computing (VNC) for high-risk applications is just not an option.
I had a conversation with some guys at ARC Advisory Group. It was very informative and lively, and it made me realize that I had to write this column. Remember back in the day when IEC 61131 was just starting to gain a bit of traction, and the vendors were all clamoring about reusable code? I distinctly remember a chap from an automation vendor company in the 1990s holding up a floppy disk and telling the audience that the software on that disk could be loaded on anyone’s hardware that supported IEC 61131.
I gasped because I knew it wasn’t true. He failed to mention the fact that the hardware had to have the same firmware and be running the same extensions; in fact, the software created for that vendor’s product could only be downloaded to a product with the same signatures. Trying to download to a another vendor’s PLC was not going to be successful.
But he failed to mention that detail.
I had another conversation with Bob McIlvride, director of communications of Skkynet Cloud Systems and asked him to have a look at the Route1 MobiKEY technology. He reviewed the technology from an IoT point of view and mentioned a number of pitfalls that this technology would have in accessing IoT devices.
One of the biggest roadblocks, he mentioned, is that the MobiKEY doesn’t allow for multiple access by multiple parties, which is very true.
We also agreed that, with those many landing zones of IoT, none of them should be directly accessible from the Internet, which would expand the attack surface exponentially.
So, he agrees with my “one door to the floor” mentality, which suggests that any remote access should only occur through one portal, if you will.
The ARC conversation started very generically, and then as we moved into some specifics of remote access; points were made regarding multiple access to devices such as PLCs, customer access and length of time allowed on a connection.
It became clear that use cases were at the bottom of my confusion when discussing remote access with these two entities, so one size doesn’t fit all.
I thought about things a bit and wondered how many use cases there could be and why any of them would be different in the context of “one door to the floor.”
In the real world and on any given day, internal employees have access to assets from within the firewall as part of their normal day-to-day operations. The range of employee responsibility goes from soup to nuts, and this range is duly noted in the ability to access assets using such instruments such as Active Directory and user profiles.
So, use cases for internal employees should be relatively simple. Allow access to the main entry point for employees at the point that they would normally access their assets, such as an engineering workstation, a maintenance computer or a transient laptop.
Nothing really changes for this use case under these conditions.
The access requirements for the external entity, such as a system integrator, machine builder, consultant, project programmer or transient access, is totally different than for an internal employee.
Even within this group of users, there are different requirements based on software licensing, time-of-day access, connection time and the ability of the end user to initiate connectivity.
One major requirement for external entities is the need to narrow their access on the OT network. You cannot allow an SI who only worked on the refrigeration units to have access to the recipe server for your batch operations. Just ask Target.
So, use cases should define the methodology for your remote access. There are many options that should be considered when implementing a remote access policy as such.
Use cases will help you determine what needs to happen and what level of functionality is required for your plant and your personnel.
It became obviously clear to me after my two conversations that a one-size-fits-all approach to remote access is very dangerous. Consider all angles.