Secure Remote Access is Not a One Size Fits All Vision
Unlocking the puzzle of OT security
By Kevin Kumpf, Cybersecurity Evangelist at Cyolo
Secure Remote Access (SRA) is a term that can be technologically defined in many ways, depending on whom you talk to, from a customer or vendor role and through what “lens” they are looking. No matter what the person’s role or perspective though, Secure Remote Access must be safe and secure, but everything else that can encompass Secure Remote Access is truly open for discussion.
What is “Secure” Remote Access
“Secure” Remote Access by technical definition, is a combination of security processes / controls that are designed to prevent unauthorized access to digital resources. Successfully implemented SRA, however, does not just include the technology used to connect a user to a resource or even a resource to a resource. The weakest link in any implementation of SRA is people.
In the recently published “State of Industrial Secure Remote Access (I-SRA)” report which surveyed respondents from the Operational Technology (OT) space, 75% of the respondents overwhelmingly acknowledged that threats to business operations were the biggest concern when dealing with any form of SRA to a resource. Additionally, 67% of respondents felt that Advanced Persistent Threats (APTs) are a growing concern and 72% viewed third-party connections as their biggest risk for any Remote Access.
Now, you may be asking why an OT targeted report is relevant to SRA across any organization and the answer is simple. Many SRA solutions are shared, maintained, managed or controlled in some form by IT resources within an organization. The threat of Ransomware as an example, is not just focused on attacking specific company resources but is focused on being able to disrupt as many business operations as possible to extract financial gain for the threat actors.
Navigating the Scope of Secure Remote Access Components
As for the human component of SRA, 59% of respondents were concerned about even trusted users with direct access to resources. This is where the definition of SRA and trusted users gets murky.
In most organizations, SRA is not just used by third parties but is also used by remote workers, internal users crossing organizational boundaries to connect to resources and a growing segment where SRA and Software Defined Networking (SDN) are being used together as well. This brings us back to the “lens” statement above.
To many organizations or technology vendors, a Virtual Private Network (VPN) is a form of Secure Remote Access, and they are not incorrect in this statement. A VPN is encrypted (secure) and uses a form of 2FA/MFA user / device authentication (ex. token, cert, key, etc.) prior to granting access (safe) but that is where it ends generally. Some can enforce access policies, resource controls, connection time but generally they place you on a jump / bastion host where applications are published to the multiple users.
Things such as session recording, supervised access, shared credential vaulting and function restricting are not available. Lastly this type of connectivity is at the Network layer (the letter N in VPN) not the application layer so if the end device is compromised ransomware and other network layer threat vectors can be attempted successfully.
Another form is the highly discussed and promoted ZTA / ZTNA, which for those of you who do not know is based on NIST SP 800-207 (I highly suggest reading this Special Publication before using the term freely). In this vision of SRA the premise is trusting nothing, hence the Z for Zero. It also practices the principle of continuous validation which means inspecting the session to ensure everything is still safe and secure. This form of SRA also is deeply rooted in policy which means granular control or people, process, and the technology being used within the SRA session.
Unmasking the Weakest Link in Secure Remote Access
The point of this article is not to get into which technology model (and there are others as well) is the best, but to discuss the real underlying problems of any SRA solution and those are proper configuration, oversight, usage and management.
The underlying problems above all are directly related to the weakest link in any SRA implementation and that is the people component. We do not truly trust the end users or devices they are connecting from or to (hence the Zero in ZTA / ZTNA) and for valid reasons. We also cannot trust that internal staff (or external resources managing our SRA implementations) follow published best practices for creating a safe and secure access infrastructure. From the auditor “lens” we all have found open VPN connections, weak passwords, shared user accounts, ineffective policies and just overall poor security hygiene. We also have found a lack of audit trails or that collaboration tool installed on a jump host so a third party can easily get in to do urgent work after hours.
In conclusion, no matter what we define as an SRA solution we all must do a better job from both a vendor and end user perspective in creating a more secure and risk reducing safety posture for SRA implementations overall, which 55% of respondents stated was a concern as well.
About the Author
Kevin Kumpf has more than 20 years of IT security and compliance experience, including over 10 years of cybersecurity, governance and critical infrastructure experience working in the energy, medical, manufacturing, transportation and FedRAMP realms. Kevin’s past roles include Director of OT Security (N.A.) for Iberdrola, where he oversaw the security, and regulatory compliance of multiple OpCo’s, and Principal Security and Regulatory Lead for interactions with the NY and NE ISO’s, NERC, ISAC’s as well as state and federal entities. He has also worked internally and as a vendor/consultant at multiple healthcare and manufacturing entities to mitigate the threats they were under in relation to ransomware, insider threats and malware infestation. Today Kevin works as the OT Technical Lead at Cyolo. More information can be found at Cyolo’s website here: https://cyolo.io/
