There was recently a rather heated twitter discussion between @Guisebule, @VirtualTal, and @Texiwill (myself) about using virtual desktops as a part of cyber defense. While this could be true, there is a need to ensure you know where your virtual desktop(s) start and end, not only within the network, but your applications in use. In addition, it is very important to fully understand the scope of a virtual desktop architecture as well as use. There are some use cases that work very well for use of virtual desktops as a part of cyber defense or for that matter just make sense for virtual desktops. There two ways to make virtual desktops part of your cyber defense but they both require more than network security.
The two ways to which I refer are: inside virtual desktops (used to egress to Internet) and outside virtual desktops (used to ingress from Internet). These are very different beasts and have very different use cases yet logically both fit the same overall architecture but with one slight difference. That over all architecture we have seen before (Virtual Desktop Patching and Data Protection) as Figure 1.
The crucial component is now the location of the end user computing device, and how it accesses the first firewall to gain access to the connection broker and eventually the virtual desktop.
Cyber Defense: Inside to Outside
When we look at Cyber Defense from inside to outside, we realize that the EUC device is wholly within our well protected network, and that the virtual desktop is outside our trust zone and is being used to bridge access to the outside of our network. Taking the over all architecture, we need to determine where the trust zones are, and how much we trust them. We will use red (untrusted), green (trusted), orange (DMZ), and purple (DMZ) to depict these trust zones. A set of trust zones could be those seen in Figure 2.
In this case the most trusted element is the EUC device, which is some form a blessed and IT controlled device such as a desktop, laptop, or static tablet device. In essence, these devices NEVER leave their trust zone, so static implies they are well controlled and stay put where ever they are located within your physical defense zones with IT controlled security. However, the desktop pool which you access to go outside your physical defenses can live anywhere: within a cloud or local. For those organizations that have this need, there is a further requirement that any data used by the virtual desktops also use distinct storage for profiles and any data. It may even be feasible to use non-persistent desktops to control possible data leakage, as well as the use of seamless window approaches such as teminal services, Citrix ICA, etc. Desktops is just one approach that could work.
However, this approach does not imply there is no need for more than networking defenses to secure your desktop (which could be used to pivot deeper into the network) or to properly secure the EUC device, storage, and hypervisors. Actually, using things in this way imply you need to secure these elements even more. Why is this? Because, your data is vital and access to this data is highly regimented.
Inside to Outside use of virtual desktops also implies a need to fully educate your users in the limitations this approach, the need to change their normal behavior to access the internet, instead of having it ‘right’ there, unless your IT department has gone the extra step and made all internet facing tools bring up a seamless window that is running elsewhere within the reg zone. This still implies that Internet data is trapped somewhere that is not accessible by normal users and can not cross boundaries through screen capture, sharing devices, etc.
Cyber Defense: Outside to Inside
Outside to Inside cyber defense could make use of virtual desktops, actually, my approach is to use virtual desktops to access internal only resources in a controlled way. There are a number of trustzone changes required to make this approach an effective cyber defense. Specifically, our EUC device is outside and therefore untrusted, while our virtual desktops are isolated and untrusted. Figure 3 shows this approach and furthermore shows that in order for the virtual desktops to access internal items, you must go through some form of security bastion (a firewall for example).
This is a typical approach for use of a VPN style mechanism. The end point of the VPN is within its own trust zone while the end data is within a highly protected zone.
The problem with the twitter discussion I referenced was that @Guisebule was discussing inside to outside and I was thinking outside to inside use of virtual desktops. Does this invalidate the need to use Bromium or something like that as @VirtualTal was espousing? There are several common items between these two approaches:
- Profile and Data for the virtual desktops are segregated from everything else
- Active Directory (or some other directory service) must be usable within the realm of the virtual desktops (to manage users)
- They are both network security approaches
- The Connection Broker and security server are considered to be in a dangerous location so must be locked down.
What is interesting in this discussion, is really the lack of discussion about the end user computing device. Its location is really the start of this discussion. We cannot ignore it.
While virtual desktops can be used as a part of cyber defense, it is important to realize their use case. In the twitter discussion we had mixed use cases. In a properly architected and controlled EUC device is there a need for a tool like Bromium if you are going inside to outside (if I could use Bromium within a virtual desktop I would use it or perhaps Symantec CSP)? Perhaps not, but for outside to inside, I would say if should be seriously considered. Do you need to use virtual desktops to achieve cyber defense? absolutely not, but it is one more tool in the toolbox. It is far easier to control access to the outside or the inside in a highly regimented environment than it is in a non-regimented environment. In either case, there will be training required and we cannot forget the underlying security at all, networking is only one small part of a fully virtualized cloud. We need to also consider the application(s), hypervisor, storage, etc.
Share this Article:
Latest posts by Edward Haletky (see all)
- Finding your Sensitive Data to Protect - March 27, 2017
- Scale and Engineering - March 23, 2017
- SDS and Docker: The Beginnings of a Beautiful Friendship - March 21, 2017