Double the fun
Let me propose another configuration: Suppose you have two different VM security domains, one for personal matters and one for the company. Each runs its own browser, email, and applications; data from one never crosses to the other. That might sound good at first, but how do you secure both without doubling your effort?
Patching, for instance, tends to be in a sorry state on most computers and remains responsible for 50 to 80 percent of all successful compromises. If you have two or more virtual instances of the same software that need constant patching, how likely are you to be better at patching mutliple security domains rather than one?
How do you handle password management? Either you have to remember which passwords you use for the same application in the different virtual environments or you use the same password across multiple environments, which defeats the purpose. By the way, a stolen biometric identity would work equally well across environments.
Suppose you decide to use a password management tool to handle the password overhead. What environment is it supposed to run in? How can its automation access the other environments? If I store all passwords in one environment, that means a single compromise threatens all environments. Or do you run multiple password management tools?
If your personal environment gets compromised, assuming you even notice, how will it be cleaned? Will you have to do it manually, using separate antimalware tools, or simply reset the environment? If you reset the environment, how do you keep or restore your needed applications, configuration settings, state settings, latest patches, and so on? Where do you store them? Who decides what can be kept and reused between resets without weakening security? I can think of countless real-life scenarios where separate virtual environments make securing computers harder rather than easier.
Then there's the potential security risk of virtualization itself. A virtualized environment has every problem a single physical system has and more -- that is, guest-to-guest, guest-to-host, and host-to-guest exploits. If Qubes or some other virtualized environment became very popular, the bad guys would focus on exploiting those additional weak points. It's not like hackers and malware writers are going to give up.
Qubes has its place
I don't want this article to be misconstrued as saying that Qubes fails to make security better. Qubes and other red/green solutions can work -- for a little while. But they can't provide the ultimate answer to the computer security, nor do they pretend to.
The real long-term solutions to preventing attacks don't depend on secure operating systems -- in part because most exploits don't target the OS anymore. Most people don't use "more secure" operating systems such as OpenBSD, though they've existed for a while.
More important, malicious hacking will only diminish when we are better able to identify hackers and prosecute them quickly and consistently. Hackers hack because they almost never get caught. Until you solve that problem, they will continue to hack. Meanwhile, I've been writing about the real solutions to keeping hackers at bay for a long time.
Qubes is an interesting solution for highly regulated or locked-down environments where people are required to undertake extraordinary efforts to maintain security. For the rest of us, basic best practices offer more bang for the buck.
This story, "Should you switch to a supersecure operating system?," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.