The outbound VDI: Internet access while protecting enterprise systems
- By (ISC)2 Government Advisory Council Executive Writers Bureau
- Nov 01, 2016
The internet supports nearly every corporate environment, from research and communications to purchasing and billing. Unfortunately, it also has become the primary threat vector for bad actors conducting criminal activity, fraud and espionage. Finding the right balance between embracing internet use and protecting enterprise systems and data is an ongoing challenge for information security and technology leaders.
While web proxies can be used in a variety of ways to limit exposure to known risky internet resources -- and web proxy technologies can significantly reduce the overall attack surface for known threats -- the approach still directly exposes internal systems to both permitted internet resources and unknown threats. For government organizations with a low risk tolerance, one of the most effective approaches to defending against both known and unknown internet threats may be the use of an outbound virtual desktop infrastructure.
An outbound VDI uses an additional layer of virtual systems that have direct access to the internet and that receive mouse and keyboard commands from internal corporate systems but that restrict return inbound communications. Instead of accessing the internet directly, internal users connect to a virtual system outside of the core network and access the internet from the virtual host. The internal system will only display the screen for the end user and play audio content as appropriate. Because the virtual system has no access to corporate data and no connectivity to other internal resources, it can, therefore, be exposed to otherwise risky internet content without risking internal corporate systems or data. When a given session is complete, the virtual system can be discarded to free up resources for future sessions.
An outbound VDI may be the ideal solution for a number of situations. First, for organizations that have strict internet policies and aggressively block risky content, users may currently be unable to take advantage of external collaboration capabilities, virtual training, social media, webmail or research sites that have been blocked to prevent exposure to potential threats. An outbound VDI can solve this problem by allowing access to these types of risky resources while preventing exposure to internal systems and data. On the other the extreme, organizations that are currently very open to dangerous internet resources but that want to mitigate the risk can also benefit from an outbound VDI implementation. In this case, users can still be allowed to access the risky resources by using the isolated virtual systems outside of the core network, thereby eliminating the direct risk to internal systems and data.
If implemented correctly, an outbound VDI solution can allow full access, or any level of access desired, without exposing internal enterprise assets or data. Access can be permitted to resources otherwise determined to be too risky, such as personal email, social media or high-risk domains. This architectural solution protects internal resources from unknown threats as well. Users can even be permitted to download and install programs or other executable files because any malicious content will only impact the temporary virtual system. In the event that the external virtual system is compromised, damage is limited to that single virtual system, which can simply be blown away and reimaged at any time.
While there are many benefits, outbound VDI technologies also present a number of challenges. For starters, correct implementation is critical. In order to properly implement an outbound VDI, up-front planning is required, and associated budgets must be properly allocated. Additionally, the benefits of isolating virtual systems also present some unique challenges. For example, if only mouse and keyboard instructions are permitted from internal systems to the outbound VDI, users will be unable to copy (for example) links to online meetings from their internal system to the virtual environment. Returning files or content determined to be of value or interest from the VDI to the corporate environment for printing or future use is also a challenge.
To ensure a successful implementation of an outbound VDI, identifying and documenting the architecture is essential. It is critical to remember that the purpose of an outbound VDI is to provide isolation of internal corporate resources and data from the untrusted internet and associated risks. Instead of attempting to solve every possible challenge with an initial implementation, IT managers should start small and avoid scope creep. Documented requirements are important and should be the basis for all architectural decisions. Also remember that an outbound VDI solution can protect internal system resources from internet threats, but there still may be a need to monitor or restrict usage from the VDI environment for inappropriate use or productivity loss. A VDI solution can significantly improve the security posture of an organization, but it should not be considered a replacement for most existing cybersecurity tools and capabilities.
In the scenario where an outbound VDI solution gives users access to previously restricted internet content, IT managers should be prepared for wide growth and adoption by users. For environments where previous access to risky internet content from internal systems is being mitigated by an outbound VDI, users may not understand why they are being forced to do things differently. After an outbound VDI is implemented, they may need additional training to reinforce the new way of doing business. In both scenarios, and the many in between, an outbound VDI solution can significantly reduce the risks of internet threats to internal corporate systems and data while maintaining the benefits of internet access.
Members of the (ISC)2 U.S. Government Advisory Council Executive Writers Bureau include federal IT security experts from government and industry. For a full list of Bureau members, visit https://www.isc2.org/About/Advisory-Council#