VDI and TS are not more secure than physical desktops, Part 3/5: Mitigation Strategies

If you read "Part 1: There's Only Two Types of Data" and "Part 2: Centralization Helps in Other Ways: of my "VDI and Terminal Server are not more secure than physical desktops" series you may have noticed that I ended them without providing advice on how we can reduce the data security risks. Your wait is over!

If you read "Part 1: There's Only Two Types of Data" and "Part 2: Centralization Helps in Other Ways: of my "VDI and Terminal Server are not more secure than physical desktops" series you may have noticed that I ended them without providing advice on how we can reduce the data security risks. Your wait is over!

Look at this cool wooden horse we made for you…

According to Greek folklore, during the battle of Troy the Greeks withdrew from Troy after delivering a large wooden horse.  The Trojans believed it to be a peace offering of sorts and towed it inside the city walls of Troy.  After the Trojans went to sleep, approximately 40 Greek soldiers emerged from the giant wooden horse and opened the gates of Troy where the rest of the Greek army was waiting.  The army easily overran the Trojans and claimed victory over Troy.

In modern day terms a Trojan Horse is a piece of computer software that the end user believes is a legitimate piece of software or a document that they actually wanted.  Instead the software or document has malicious intent that can range from stealing information such as software licenses, banking account information, website passwords, etc.  Trojans often will control the PC from that point forward (becoming a "zombie" PC) receiving command/control instructions from central system(s) on the Internet.  Collections of these "zombie" machines are called Botnets and in many cases contain millions of PCs.

How computers get compromised

Most computers will get compromised by one of the following methods:

  • Downloading software that contains a virus/trojan horse.  This method can largely be prevented by not allowing users to install software and locking down their PCs.
  • Inserting a removable storage device that contains a virus/trojan that executes automatically upon insertion of the drive.  Even though the user may not intend to invoke the software there are many ways to compromise various operating systems simply by inserting media into a PC.
  • Opening an infected document.  A very common exploitation vector for viruses / trojans over the last few years has been opening documents such as Office documents, JPG/PNG images, PDF Documents or ZIP libraries.  There has been massive investments by Microsoft, Adobe and other vendors to try and sandbox their software to reduce the likelihood that their software will cause the compromised entry point of the PC.  This remains the largest security concern for targeted attacks since an attacker can do research on people that work at a particular organization, discover their email addresses and then deliver a spearphishing attack via email.  Through some effective social engineering, this can be a highly effective means at getting directly to the source of information you are trying to obtain.  Also, through the use of new unknown zero day attacks, the recipient of said exploit will be largely unprotected against it by any means of A/V, HIPS, IDS, etc.
  • Visiting a compromised website.  Drive-by downloads, client-side Javascript, XSS, CSRF, etc are all forms of web-based attack mechanisms.  While each of these attacks differs by the amount of potential damage it can cause on a system, in all cases information security when it comes to browser is completely compromised.

Of the above methods, the opening of a document file (usually delivered via email) and the attack delivered via the web browser are the most common security risks we face today.

Does it matter where the PC is located for these attacks?

It is almost completely immaterial where the PC is located for one of these attacks to be successful.  A user could be on a VDI desktop in the data center or they could be on a laptop connected over a 3G connection via a tethered cell phone.  If the exploit code is a few megabytes worth of content embedded into an email attachment it will execute the same way whether it has a Gigabit connection in the data center or a latent crappy mobile network connection.  

Once the machine has been compromised, the data center connection certainly makes it easier for the attacker to reach hundreds if not thousands of other machines inside the corporate network (assuming you don't isolate systems).  However, these machines could also be accessed over a 3G connection or a home DSL/Cable connection as well.  Modern day attacks will often be created to not port scan a network aggressively because attackers know that serialized port scanning at a high rate will be caught by an IDS system.  Instead the attacker will use randomized port scanning or even manual efforts to avoid detection.  So while there are people out there that insist that being in the data center increases your risk, that's just plain FUD.

So how do we improve security against the email/browser threat?

Joanna Rutkowska has a great blog article that talks about the three main ways to implement security.  I encourage you to read the whole article, but in short here's a summary of the three ways we can try to implement security.

  1. Security by Correctness - Security by correctness means we shouldn't create software bugs in the first place.  This is obviously a very difficult thing to do.  If it wasn't hard to do then there literally would be no security software/hardware companies in the first place because there would be nothing to prevent attacks against.  Software developers are human and they make mistakes.  Because of that, we can't count on this resolve our issue.
  2. Security by obscurity - Security by obscurity is all about creating methods to make it more difficult for an attacker to compromise a system by known weaknesses.  Examples of this method are things like code obfuscation which makes it more difficult for an attacker to reverse engineer someone's code by mangling it so it's execution is not as easy to follow within a debugger.  Another example of a security by obscurity solution is Address Space Layout Randomization (ASLR) which is designed to allow code to load in "somewhat random" addresses within memory in order to prevent a predictable memory loading address which would allow an attacker to more easily perform buffer overflows, etc.  While security by obscurity solutions do improve security, we can hardly count on this to resolve all the issues.
  3. Security by isolation - Security by isolation is exactly what it sounds like.  Find a way to isolate the resources that would be exposed to an attacker when the code in question executes.  If you find a way to create a secure perimeter around a piece of code, then you potentially mitigate the risks of running that code on your system.

Security by isolation provides the best method of defense and can be implemented in a number of different ways.  Stay tuned for part 4 where I'll discuss the different methods of security by isolation and how they help (and hinder) our end users.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Good series.

However, the argument of increased risk if the desktops are in the datacenter is valid. The desktop is not more vulnerable in the datacenter, the data is.

However, VDI does not mandate you to place the desktops in the datacenter. It allows you to funnel your computing experience where IT dictates.

You can segregate your networks accordingly and separated by firewalls. One for end-point access, one for desktop/app access, and one for data access.

The arguments saying VDI, RDS, or Traditional Desktops are either more secure or less secure is completely based on the use case.

All of these technologies can be deployed in a secure way, albiet when Bromium's Microvisor comes out the Traditional Windows Desktop will the most secure, but that is only because it is the only technology that the Microvisor is compatible with.

It all boils down to which technology is easier to consume and manage for your organization. One cannot have security without management.


This is a brilliant series, kudos to Shawn for going through the mental inconvenience of thinking through and writing all of this.

Whilst we can take issue with some of the questions he is asking, I think Shawn is doing a brilliant job of articulating some of the distilled truths of security.

He is beginning a conversation with us and I am not finding any fault with anything he is actually saying, I like you Icelus question some of his underlying assumptions but its a fruitless endeavour until we see where the he eventually arrives.

The important thing is that Shawn is starting a conversation and that its one we should strongly engage with and contribute to, I am disappointed more people are not commenting on these threads of Shawns.

I agree with the conclusions Shawn is arriving at, I am in total agreement with the idea that security through isolation offers the only real certainty.

I agree primarily though because Shawn is very careful in his writing, there is little that you can disagree with, I hope to see something that challenges our thinking in subsequent parts.

His conclusions concur with my belief that logically only a true separation of personalities on a multi-tenant infrastructure can occur through physical means.

I also agree with your points about the Traditional Windows Desktops being the most secure because of Bromium, but only because it is the technology that the Microvisor is compatible with.

Why would the same kind of virtualization that Bromium applies to the desktop not work on a server based virty desktop ?  No real reason.

I agree with your thinking, but I do not think that anything Shawn has said so far contradicts this other than his title.

The more I read of this series, the more I think he is trying to start a genuine conversation and outline our best understanding of the issue rather than set out to specifically prove that Traditional Windows Desktops are more secure than VDI/TS.

I suspect that Shawn's chosen title was the least clumsy one he settled on for this huge conversation.

I could be wrong though, but I hope not.


Hopefully part 4 will include a nice discussion on all the problems isolation brings with inter app communication and management. Let's face it, application virtualization vendors have claimed security for a long time also, and those who know anything about security is that all you need to do in infect in the virtualization engine and you are into every app, making things worse than before....

Bromium type approaches will argue more secure due to hardware attestation which is great, but face the same management problem and hence will argue things like XX% of attacks come from a small set of apps that they can help with. Another tool in the belt if it works but like anything it will be a while to see how far it gets.

I think the best comment so far in this series so far is comments #19 in part 1 via Meko_Siluka. A practical view as opposed to arguing theory which can be argued any way to prove a point.


Meko is definitely a no-nonsense practical kind of guy, but I am positive that these arguments around theory are essential to the development of sound practice, we need to imagine a thing before we can build it.

You have been too quiet recently appdetective, we do not hear from you as much as we used to.


I've posted my uber blog on the topic here:


appdetective - You've inspired me to commission a blog on the delta between micro-virtualization and sandboxing. I'm going to ask our chief architect to write it so that it satisfies the technical depth you likely desire. Stay tuned.