Secure Remote Access Blog Part 1: There are Better Approaches Than a VPN
As the full implications of the Coronavirus pandemic became clear to businesses in March, understandably there was a scramble to enable remote access for entire workforces – overnight! While many companies had solutions in place for portions of their employee base to work from home, many found themselves switching from providing a convenience to instead complying with necessity. For most organizations, the idea of scaling an existing VPN-based solution that now required dozens, hundreds, or even thousands of extra licenses, additional infrastructure to support it, along with associated operational overhead, was untenable.
Rightfully so, another priority is securing remote access for all employees. After all, it only takes one compromised credential to potentially impact millions, in terms of revenue, shareholder value, post-breach cleanup costs, identities, intellectual property…the list goes on.
Some companies, however, failed to factor in remote access for privileged users as they scrambled to maintain business continuity. The most highly privileged accounts – those of internal IT, outsourced IT, managed service providers, and other third-parties – these represent the highest potential value to hackers.
The challenge at the heart of this conundrum is how to provide legitimate users secure access to IT resources. By resources we mean Windows, Linux, and UNIX systems and network devices in the IT estate that run our business. They may be in a data center, DMZ, a private cloud, one or multiple public clouds – or any combination thereof. By legitimate users, we mean people whose job it is to touch those resources, keep them healthy and running, and protect them. Secure remote access is about getting these legitimate users (wherever they are) access to infrastructure (wherever it is), while keeping attackers out.
In this two-part blog, we’ll explore the approaches to secure remote access for administrators, outlining Good-Better-Best options to provide secure, granular access to critical infrastructure resources regardless of location.
A Good Option: VPN
For many organizations, Virtual Private Networks (VPNs) are a known quantity. They’ve been around forever, and IT has the requisite knowledge to manage and operate them. To a VPN, a remote internal IT admin is no different than outsourced IT admin. Install a VPN client, get a set of credentials, and you have a secure connection from your workstation to a corporate network.
While VPNs represent a viable option, however, there are some drawbacks. One we already mentioned – the cost to scale. Another – for me, the biggest – is that the VPN physically attaches the administrator’s workstation to your network. So, while you might have limited her job to only managing the web server on Machine X, there a risk of being able to access other systems on that broader network. That’s great, if you happen to be a hacker who has compromised that account. Another drawback of being network-attached is the potential to infect your IT systems with any viruses or malware present on the admin’s workstation. You may have control over your own employees, but with 3rd-parties it’s likely much harder to guarantee a “clean source”. Finally, VPNs can be complex to configure, and generally only provide coarse-grained access controls that hamper your ability to be as prescriptive as you should be.
Is a VPN better than nothing? Yes, of course; that’s why it’s a Good option. As discussed, however, there are inherent risks. Perhaps the poster-child is the U.S. retailer, Target, who was breached in 2013. A 3rd-party company employee with a VPN login to Target, was phished. With a legitimate credential in hand, the hacker walked in through the VPN front door and compromised over 40m credit and debit cards. To date, the total cost of the breach has been over $200 million including $18.5 million to settle claims by 47 states.
While a viable option, realistically it should be short-term in lieu of a stronger approach.
A Better Option: VPN + Centrify Privileged Access Service
The “Better” approach, by far, gives you the most benefits. With this, you can still leverage your investment in a VPN infrastructure, but it introduces the Centrify Privileged Access Service for better control, security, and operational efficiencies.
Rather than allowing VPN access into the entire network, you permit VPN access into a controlled network, where the admin can only get to the internal infrastructure through Centrify, via a Centrify Gateway Connector.
In this hub and spoke model, the Centrify Gateway Connector spoke acts as a bridge – the ONLY bridge – to the servers and network devices. You can configure your firewall to only allow VPN users access to the Centrify Gateway Connector, so there’s no direct path to your resources through the VPN alone. Unlike the Good option, the Centrify Gateway Connector surgically places the administrator on the target system – not on the broader network. The user is still network-attached, so there’s inherent risk there, but with the additional Centrify security, many risks of the Good approach are mitigated.
To establish a remote login session, administrators have the option of using their familiar desktop client apps such as PuTTY, Microsoft Remote Desktop or ssh via the MacOS Terminal. Alternatively, they can log into the Centrify Privileged Access Service hub – a SaaS service accessible from anywhere – and obtain a login session from there through their browser instead of a local client. This would typically be the method of choice for outsourced IT, along with the option of SAML-based federation to log into the Centrify Privileged Access Service, giving your IT more time back since they don’t have to manage the external identities.
Centrify’s fine-grained access controls dictate the systems and network devices the administrators can log into, along with which accounts they can use. Since not all resources are equal, for more sensitive ones you may want the administrator to request access “just-in-time” (either through Centrify workflow or a third-party such as ServiceNow or SailPoint). You can (and should) time-limit such access to avoid the risk of standing privileges being exploited.
The Centrify Gateway Connector, acting as a Policy Enforcement Point (PEP – per NIST best practices), enforces the policies configured in the Centrify Privileged Access Service portal (Policy Definition Point or PDP). It also captures a recording of the session so that incident response, audit, or compliance teams can visually review privileged activity. Finally, you get better account password management. Centrify Privileged Access Service can automatically rotate vaulted passwords. Reducing their lifetime reduces an attacker’s window of opportunity. Should someone physically change a local account password on a server, automatic password reconciliation ensures the password is brought back in sync with the Centrify Privileged Access Service, avoiding breaking users, applications, or services that depend on them.
This is clearly a much better solution, but it’s not the best. We’ll explore that in the second installment of this blog next week.
This post was first first published on Blog | Centrify website by TonyGoulding. You can view it by clicking here