Often as a part of Digital Transformation, your organization will decide to enable remote access for operators and trusted third parties to your industrial control systems. There are many sensible reasons for this – faster reactions, better uptimes, a simpler commissioning process, and more painless updates – but these improvements also create potential security risks.
If you don’t choose your secure remote access IoT vendor carefully, you can be left with a tool that fails to satisfy the needs of your operators, IT security individuals, and your business manager. You might also find that the tool compromises on security basics in order to provide fast and easy access, or alternatively, focus on covering security best practices while neglecting the user experience.
Your remote access tool should provide iron-clad security but also go above and beyond to make your life easier. It’s the vendor’s job to demonstrate how their solution maps to your regulations and security frameworks, provide a simple, trusted interface, and not surprise you with hidden “costs” of implementation, administration, and maintenance.
If you’re in the process of looking for a remote access vendor or would like to implement it and don’t know where to start, we’ll discuss the questions to ask to properly vet your remote access vendor. The last thing you want is to be stuck using a remote access provider that is slow to connect, cumbersome to use, and fails to properly secure your systems.
The questions you want to ask include:
- How does the vendor’s idea of ROI compare with what your team will actually be measured on?
- Does it uphold security best-practices?
- MFA
- Encryption
- User-specific Whitelisiting
- Least Privilege
- Administration
- Active Directory Integration
- Screen Recording
- Logging and Monitoring
- Segmentation
- Moving Target Defense Networks
- Time-Based Access
- Hot-Standby
- How does their solution map to your regulations and security frameworks
- Does the solution provide a simple, trusted interface?
- What are the “costs” of implementation, administration, and maintenance?
Let’s break down the specifics of each question.
1. How does the vendor’s idea of ROI compare with what your team will actually be measured on?
There are three players needed for discussing ROI: the operator, the IT security individual, and the business manager. These three individuals are measured based on different factors that you need to take into consideration. The operator is judged based on uptime, availability, and safety, the IT team is concerned with implementation, and the impact of security events, and the business manager is most likely looking at bottom-line ROI, and efficiency, and is the one pushing for a digital transformation in the first place.
Your remote access vendor, and even your own coworkers, might have ROI goals that differ from yours. For example, your IT department might push for a certain remote access tool to help eliminate risk factors and check the appropriate boxes, but this same tool could introduce cumbersome steps for the OT team that contribute to potential downtime. It’s clear that in this case, IT and OT want, and expect very different things. You don’t want to set OT up to fail and force them to compromise on uptime and availability just because IT is concerned about maintaining security. Therefore, it’s important for your team to discuss their own remote access needs with each other first, before meeting with a potential vendor.
When it comes to your vendor, if they’re advertising the product as secure, chances are it’s not fast, and vice versa. Your team shouldn’t have to choose between security or speed—that doesn’t help anyone. Look for a vendor that provides both security and speed, a partner that goes above and beyond to understand your team, and a tool that is flexible enough to meet your organization’s unique needs.
2. Does it uphold security best practices (MFA, encryption, user-specific whitelisting, etc.)?
Any good remote access tool should contain the following:
a. Multi-factor Authentication: Most frequently provided in the form of a Temporary One Time Password (TOTP) or Hardware (Yubikey or equivalent FIDO2 compatible device).
b. CNSA Suite Encryption: At a minimum, encryption throughout the secure remote access product should be conducted using algorithms that are part of the CNSA Suite, with key strengths that at least meet CNSA Suite guidelines.
c. User-Specific Whitelisting: Users should only be able to see and access the assets to which they are permissioned. User-specific whitelisting should be available at the device and protocol levels. It is important that administrators can update these whitelists simply and that they are automatically terminated at the end of a project or when a user’s access is revoked.
d. Least Privilege: Least trust should be used when granting systems access in order to minimize the risks of a data breach and the possibility of insider threat. Access should be granted to code repositories, billing systems, customer relationship management tools, email servers, and cloud environments based upon business requirements. Workers should request access from their manager or responsible owner when seeking to escalate privileges. When workers no longer require access, their credentials should be revoked. Access audits should be conducted quarterly to determine if granted accesses are still necessary.
e. Administration: Administrators should be able to enforce access rights, segment what is visible to each user, and require multi-factor authentication. Additionally, they should manage virtual desktops, provision virtual desktops to third parties, and remove desktop access by destroying the desktop once the work is completed.
f. Active Directory Integration: Does it integrate with common user management systems like AD, LDAP, or OKTA? Depending upon the situation at the customer site, the solution should either tie to a pre-existing AD, LDAP, or OKTA system reflecting the appropriate access permissions process or provide the customer with a custom form approval process embedded in the remote access tool’s web portal.
g. Screen Recording: Screen recording is often recommended, if not required by many industries. Depending on your industry’s regulatory frameworks, screen recording that monitors a user’s activities is sometimes mandated for auditing purposes. If you need to grant access to vendors, screen recording on virtual desktops offers a safe way of doing so.
h. Logging and Monitoring: Access and activities on production and development environments should be logged. Notices on code repositories, servers, databases, and other systems should be distributed in real-time to relevant workers.
Consider whether the vendor places a log server within each of their networks. The customer can then pull these logs to their SEIM. Determine if they have an audit database of login attempts, including successful and unsuccessful logins at each authorization level.
i. Segmentation: Are the remote access networks single-tenant and, in ICS settings, single-purpose with no potential for lateral movement into a corporate or business network?
j. Moving Target Defense Networks: You do not want your remote access product to reveal the location of your end target network. Imagine if hundreds of operators are connecting to the same address, every day from 9-5. That’s a huge arrow towards where they are going. Static solutions, even encrypted, pose this problem. For example, VPNs are static, far too easy to find, and creating new VPN networks is cumbersome. Almost all modern VPNs have been compromised by zero day attacks. In many cases patches exist for these threats, and yet, most are still unpatched because maintaining these systems is too time consuming and threatens potential downtime.
A true MTD network is composed of virtual machines drawn from public or private clouds. To make the network a moving target, these virtual machines must be regularly destroyed and replaced with fresh instances built from Golden Images with the latest patches and updates automatically applied.
k. Time-Based Access: If you are able to terminate the network on a regular basis, you can cap the time an attacker can spend trying to attack your network.
As a preventative measure, all network components should be scheduled to self-destruct and rebuild periodically from golden images. If malicious code is detected between periodic refreshes, components should be manually destroyed and replaced.
l. Hot Standby for Critical Connections: A service level agreement promising 99% uptime is little comfort when a failure takes place. Secure remote access products should keep hot standby systems available that operate in geographically independent locations.
3. How does their solution map to your regulations and security frameworks?
Industry best practices are communicated through regulations and security frameworks. Some of these regulations are industry requirements, while some are recommendations.
Make sure to ask your vendor to identify your industry framework, and to explain how their product maps to it. It’s not just about meeting minimum security requirements and checking your industry-specific boxes. A vendor should provide a tailored, industry-specific mapping to demonstrate how they go above and beyond these requirements, which will ultimately help you pitch the product internally.
4. Does the solution provide a simple user experience?
A remote access experience should be simple, secure, and ultimately delightful to use. Why? Because if it’s too complicated, employees will try to find easier workarounds and jeopardize your system security.
The process shouldn’t be cumbersome. The more incremental steps used to log in with your remote access tool, the longer the process takes. Depending on the amount of time you lose, efficiency could be reduced by 4-5x. If you look at the time spent on the login process across both operators and vendors per year, these minutes translate to dollars lost.
Operators are judged based on how long it takes them to check off their tasks. If they’re spending most of their time logging in, they’re going to look inefficient. It’s not the operator’s fault that efficiency is weighing them down—it’s the tools they’re given.
5. What are the “costs” of implementation, administration training, and maintenance?
A vendor might tell you that they have a simple, trusted interface, that you can begin to use right away. But what they won’t mention is how much you’re spending on implementation, administration, training, and maintenance. Question where all the hidden inefficiencies are—ask your vendor what is the total cost of ownership.
If you’ve read this far, you’re equipped with the knowledge to avoid getting played by your remote access vendor, and you know how to find the right solution to fit your needs. At Dispel, we believe in transparency, and any good remote access solution should have the information we discussed publicly available. For example, you can find Dispel’s on our security page: https://dispel.io/security.
If you want to implement a remote access tool that covers all of the security features we discussed, in addition to offering a simple and fast user experience, schedule a demo with Dispel. We promise not to surprise you with any hidden costs, or compromises in your security or user experience. You can learn more here: https://dispel.io/.
Disclaimer: Thank you to Josh Varghese from Traceroute for inspiring this post. You can find his article here: https://www.linkedin.com/pulse/remote-access-ics-sample-questions-josh-varghese/.
Invest in reliable vendor remote access that doesn’t come at the cost of network security. Whether you have 1 vendor or 1,000, use a standardized system that works every time.
Ask us questions or get your demo at https://dispel.io