8 (and a Half) Questions for Your OT “Secure” Remote Access Vendors
Ask different questions, get different answers: What should you be asking your OT “secure” remote access (SRA) vendor?
Waterfall team
Terminology first. The word “secure” is in quotes, because cybersecurity (like safety) is a continuum, not a pair of discrete yes/no states. We can always be safer, or less safe. We can always be more secure, or less. The question “Are we secure?” is meaningless. The question “How secure are we?” has an answer. The question “How secure should we be?” is even more important. Anyone who uses “secure” as an adjective is selling something – “secure” communications (really: encrypted and/or authenticated), “secure” boot (really: cryptographically authenticated firmware), “secure” by design (really: better security by designing security in), and so on.
There is no such thing as “secure” remote access.
Want to learn more about OT remote access? Join our next webinar: “13 Ways To Break “Secure” OT Remote Access Systems”
Question 1: For SRA into OT systems, does your vendor provide IT-grade protection we HOPE can detect attacks in time, or do they provide hardware-enforced, engineering-grade protection?
What is IT-grade protection? Imagine a long suspension bridge has dangerous harmonic frequencies – people simply walking over the bridge risk setting up oscillations that build up, eventually to the point of tearing the bridge apart. See the 1940 Tacoma Narrows disaster for an example. Imagine that a bridge you cross every day on the way to work has this problem, and so is stabilized by hydraulic dampers – multiply redundant dampers, redundant power supplies and “secure” control systems. How happy would you be driving across that bridge every day if you knew the design engineer HOPED that, if there was a cyber attack on the control system, HOPED we could detect the attack before the bridge tore itself apart. How happy would you be knowing the design engineer HOPED that, if we detected the attack in time, HOPED we could scramble an incident response team fast enough to prevent disaster?
Hope is not what we expect of design engineers. we expect bridges to carry a specified load, in a specified operating environment, for a specified number of decades, with a large margin for error. Engineering-grade solutions, like over-pressure relief valves and unidirectional gateways, behave deterministically, no matter how sophisticated a cyber attack is launched at them.
Question 2: If someone phishes an SRA credential, can they exploit a vulnerability in the Multi-Factor Authentication (MFA) to get into the protected OT systems?
“Secure” Remote Access vendors boast about their MFA, but MFA is software. Yes, the little dongle on our keychain looks like hardware, but the “secure” SRA system we are logging into with the dongle is software. All software has defects, and some defects are security vulnerabilities. Some of those vulnerabilities are known to the SRA product developers, who are madly trying to develop patches / security updates for the vulnerabilities. Others are known only to our enemies, who are using these zero-day vulnerabilities against us without our knowledge. Our attackers phish our “secure” password, ignore our RSA dongle or cell phone authentication app, and exploit a zero-day in the “secure” system to break in with our credentials and work their will upon our OT networks. Is this possible in the “secure” system we are using or considering using?
Question 3: Is that SRA a H2M solution, or an M2M solution?
Terminology:
- H2M = human-to-machine = sends keystroke & mouse movements in / receives screen images back out.
- M2M = machine-to-machine = software talking to software – for example: an HMI running on our remote laptop, talking through a VPN to PLCs or OPC servers in the OT network, or a PLC programming tool on our remote laptop, talking through a VPN to update firmware in our safety-instrumented systems (SIS).
When “secure” remote access supports M2M, then any malware that might be present on our laptops can reach across the M2M/VPN and connecting to any vulnerable, out-of-date (eg: XP) OT systems in our OT network. Such systems are a bonanza to common malware that relies on exploiting known vulnerabilities.
Question 4: Can users override SRA encryption / certificate warnings?
Many “secure” OT solutions use industry standard Transport Layer Security (TLS) to protect their connections across the Internet. This is the same technology used by web browsers, M2M applications, and the vast majority of Internet and IT applications. TLS uses certificates. If an attacker intercepts our communications, they can substitute their certificates. Our software – eg: our web browsers – are supposed to diagnose the substitution. A lot of these applications, like many web browsers, caution their users when they see an unexpected certificate and ask if the user really wants to proceed. Most users answer, “yes of course – override the warning / force the connection to complete / finally I’m connected through this nonsense!” And they successfully use their MFA and other credentials to log into the “secure” remote access system in a way that lets the bad guys take over their session.
Question 5: Can you paste or file-transfer arbitrarily complex files into OT equipment remotely?
A lot of OT equipment is sensitive – it malfunctions if anti-virus is running on it, so we do not run AV on it. It costs a lot of money to re-certify for safety if anything changes, so we have not applied any security updates, nor upgrade the operating system. These systems are often found still running obsolete versions of Windows XP. What risk is there in downloading a PDF file to this device? Or a software update executable? Or a clever new OT tool we just found on the Internet that claims it can “clean the hard drive” on this very old, very vulnerable, very important OT system? If people can transfer files that can contain malware, sooner or later they will do so. Does our “secure” remote access permit this very dangerous operation?
Question 6: Is there a session timeout?
Many users find session timeouts to be really annoying. Users must log in repeatedly when they get distracted by other emergencies during OT SRA sessions. But what happens if there is no session timeout? We log in and finish a job in the evening on our home computer. We go to work the next day. Our kids log into the home computer to do their homework. They find our session still open, still connected. What harm could that cause? Or – we put no password on our cell phones, because constantly entering PINs is annoying. Now open a “secure” remote access session, set the phone down and forget it. A stranger picks it up. There is no PIN. The remote session is still active into our critical infrastructure operations. What harm could be done?
Question 7: Do you require deny-by-default on firewalls protecting OT networks?
Many “secure” remote access vendors claim we can install their software on the OT computer of your choice, and the software will connect straight out to the Internet through IT/OT and IT firewalls, without needing to do anything to reconfigure the firewalls. This design assumes that OT firewalls are configured like most IT firewalls are configured – they allow any outbound connection by default, disallowing only inbound connections and outbound connections to known-dangerous destinations.
Such configuration means the “secure” remote access solution counts on a firewall configuration that any well-meaning technician on the OT network can use to install their own rogue remote access solution, among other things. For example: open a persistent SSH connection to a home Linux computer that is able to forward connections back into OT systems or download a “free” remote access / support solution, connect it out to the cloud and at home, rendezvous with this solution from a home computer. Well-meaning technicians imagine that there is no need to “bother” IT or engineering with matters like this when anyone with the most modest of computer skills can download and install whatever “secure” remote access software they wish, using their XP admin credentials.
Question 8: Does your OT SRA need a firewall?
Most SRA vendors assume there is a firewall between the IT and OT networks, and their SRA software relies on establishing connections through this firewall. Firewalls, however, are vulnerable to many attacks. For examples, see Thirteen Ways to Break a Firewall. In contrast, hardware-enforced remote access (HERA), for example, is compatible with, but does not require a vulnerable firewall at the IT/OT interface.
Question 8 1/2: Does your SRA support MFA?
We count this as only half a question, because all commercial-grade OT SRA supports MFA. The only SRA without MFA is the “roll your own” kind, where you are hard-pressed to find any vendor to ask these questions of in the first place. Internet-exposed, and even IT-exposed OT facilities should all support MFA and we must enable that MFA without fail.
Digging Deeper
To better understand why these questions are important, or to dig deeper into the simple attack scenarios that lie behind these questions, please join us in our April webinar 13 Ways To Break “Secure” OT Remote Access Systems – And questions you should be asking your OT SRA vendor about these attacks”.
About the author
Waterfall team
Share
Trending posts
Webinar: 13 Ways To Break “Secure” OT Remote Access Systems
Webinar: 2026 OT Cyber Threat Report
Stay up to date
Subscribe to our blog and receive insights straight to your inbox
