Secure Remote Work

By Luke Willadsen

As many organizations move to a remote-work posture due to the rapid spread of COVID-19, it’s important that those responsible for IT and IT security can ensure their organization’s remote work policies and technologies are securely implemented and capable.  No two organizations are alike, and exact security requirements are unique to your organization.
​
The bottom line is that remote work technologies and policies should be designed to prevent unauthorized access to your network, systems, and confidential and/ or proprietary data.  There is no on-size-fits-all approach to this, organizations must develop a true understanding of their threat profile to better determine which security controls are right for them.

To accomplish this, it’s important to ask the right questions:

• What is my budget?
• What technologies are currently in-place within my organization?
• How many employees need to work remotely?
• What are the security requirements for my organization?
• How can I ensure that remote work is secure?

​This blog post specifically focuses on answering the last question.  There are multiple solutions for implementing remote work technologies and policies, and it is possible to be budget-conscious while also ensuring that remote access is secure.  You will have to make the choices that are right for your organization.  EmberSec suggests taking one of these two routes to achieve secure remote access for employees:

1. Connection into the network with a properly implemented VPN.
2. Use of Remote Desktop technologies such as Citrix or Microsoft RDS.

Before diving into proper implementation, it’s important to recognize that many employees at many organizations do not work with confidential or proprietary information.  If these employees can perform their work tasks remotely, then it’s generally safe; just ensure that these employees are isolated from systems and network segments that could encounter confidential and/or proprietary information and are educated on current policies and expectations.

Secure VPN Use
Let’s dig into option number one – the use of a VPN for remote work.  If confidential or proprietary data is involved, or if employees must interact with critical systems and/or networks, these employees should never be connecting into company networks from personal devices.  These devices could be infected with malware and introduce it into your greater organizational network.

CAVEAT: if there is no requirement for employees to access confidential or proprietary information, then it might be safe for employees to connect to the VPN, but they must land in a secure enclave of the network.  It may be better to let these employees rely on cloud services and skip connecting to the VPN altogether.

If employees work with confidential or proprietary information, or they interact with business-critical systems, their origination system (when connecting to the VPN) needs to be an organization-managed system such as a company laptop or desktop.  There are essential reasons why this is important.  An organization-managed system allows for necessary control over the device, allowing your system administrators to:

• Require and enforce your own endpoint security solutions on these systems, such as traditional antivirus and endpoint detection and response.
• Perform application whitelisting to ensure that only organization-approved applications are running on these systems.
• Implement multi-factor authentication by utilizing an authenticator, smart card, or biometrics (fingerprint).
• Configure additional security controls through Group Policy or similar solutions.
• Ensure systems have full disk encryption enabled, so that in the event of loss or theft, the data is likely secure.
• Force security updates as mandatory for both the operating system and the applications installed on these systems where possible.
• Manage and configure the firewalls for these systems
• Disable USB drive writing (as an additional precaution).
• Authenticate the company device to deter personal device usage.

With full configuration management over the devices that are authorized to connect into the network, organizations can ensure they have taken strong precautions before allowing users to connect into their network and access confidential or proprietary information.

Now let’s get into the VPN configuration.  It’s just as important for organizations to properly implement their VPN solution.  Multi-factor authentication (MFA) for your VPN(s) is crucial and should NOT be optional.  MFA is arguably the most effective security control you can use to prevent unauthorized access and increases the difficulty for adversaries to achieve a breach by several factors.

Second, you should ensure that VPN clients land in a secure network enclave.  The secure VPN client enclave should have granular firewall rules that dictate exactly which hosts and ports VPN clients can communicate over.  Employ the principle of least privilege when determining firewall rules.

Finally, find a way to ensure that organization-owned devices are the only devices allowed to connect into the VPN.  This is hard to do, and you may have to get creative to accomplish this.  The use of client certificates that are locked down and cannot be exported from the organization-owned device is one solution.

Remote (and Virtual) Desktop Technologies
One alternative to VPN use over secure organization-managed systems are remote desktop technologies like Microsoft’s Remote Desktop Services (RDS), and virtualized desktop technologies like Citrix, Hyper-V, VirtualBox, and VMware Horizon.  Rather than connecting a device into your organization’s network as a host, you can allow users to connect into hosts that are already in your environment.  There are pros and cons to this option, as there are with using a VPN.  With the right security controls implemented, remote desktop technologies can be made to be secure, and you’ll find that many of the same security controls apply to both options I’m discussing in this blog.

In addition to standard security measures (ex. endpoint security, EDR, firewalls, whitelisting, mandatory updates, group policy configuration), there are two security controls that are crucial when using remote and virtual desktop technology for remote work:

1. Multi-factor authentication.  Do not let your employees connect into your network without it -plain and simple.
2. Don’t let any data pass between the machine originating the connection and the remote/virtual desktop. Disable the clipboard and shared drive access between the origination host and the virtual/remote system.  We don’t want a single byte of information to be exchanged between the two hosts (aside from the network connection that facilitates the session).  This prevents the introduction of malware into your network and it prevents employees from exfiltrating confidential or proprietary files.  Disable screenshotting of the window containing the remote/virtual desktop on the host computer as well.  This won’t prevent someone from taking a picture of their monitor, but it’s still a good precaution.

Stress-Testing
If you’re going with either of the options I’ve presented, it’s crucial that your infrastructure can handle the load of implementing a remote work policy during these trying times.  If the infrastructure isn’t robust enough, you’re going to have big problems.  If you lack the proper bandwidth and are allowing all your employees to connect via your VPN, the network connection could be frustratingly slow and heavily impact the productivity of your employees.  If the systems hosting your remote or virtual desktop services lack the required computing power, your users’ interactive sessions could slow to a crawl, preventing them from getting any work done.  You need to stress test your remote work technologies to ensure they can handle the load.  If your VPN has only ever had 50 concurrent users, what makes you think it can handle 1000?

Conclusion
Is your organization ready for a 100% remote work policy?  If so, count yourself lucky.  With the rapid spread of COVID-19 and ensuing global panic, many organizations aren’t ready and may attempt to implement such a policy anyway for fear of lost productivity.  Implementing a 100% remote work policy without being properly prepared could do more harm than good for your organization, as it could result in a breach or outages.  I hope this blog is helpful in enabling you to facilitate safe and secure remote work.

Things We Didn’t Talk About
This blog didn’t cover everything under the sun.  We haven’t talked about any mobile applications that many organizations use, such as Outlook, Slack, Teams, and many more.  We often discuss confidential information over email and other collaboration tools, and many of our organizations allow us to access to these platforms on our mobile devices.

We also haven’t talked about externally hosted applications that many of our organizations use, such as Slack, Teams, GitHub, Salesforce, Confluence, Jira, and many more.  Without employing certain security controls, these applications can be accessed from any system.

Stay tuned for a future blog post on these topics!

Anecdotal Misconfigurations I’ve Observed
As a penetration tester, my job is to find security holes in the technologies implemented by my organization’s clients.  Below are a few misconfigurations that I’ve observed in past remote work technology implementations.

1. I once gained access to client VPN credentials through phishing.  There was no multi-factor authentication protecting VPN access, and when I connected to the VPN, I was not in a secure enclave.  I could access almost every system and network in the corporate enterprise.  This type of access is just as good as on-site access for a hacker.
2. For an assumed breach assessment of a client, I was provisioned an Active Directory account with standard user privileges.  Standard users were able to connect into the client’s Citrix platform.  The shared clipboard between my host computer and my virtual system was enabled, and I was able to leverage the clipboard to copy my malware over to the virtual system and perform exploitation with ease.
3. On multiple occasions, I’ve connected to client VPNs from a Kali Linux system.  If tightly secured client certificates were in use, I wouldn’t have been able to do this.