I love QubesOS and have been using it for quite some time now, with a lot of success. I also think it’s the best OS in terms of security that’s actually usable for most workloads.
I’d love to see QubesOS used at work in more places as well, to drastically increase the security, especially in high-assurance workloads, but there is (at least) one problem. Many workplaces require MDM, such as Intune, Jamf or other solutions (especially Microsoft’s own tools). This makes it very difficult to have QubesOS installed and compliant with the workplace’s security policies.
In most situations, this means that although QubesOS would be significantly more secure in almost all avenues, the fact that it does not conform to the security policy and MDM (as mandated by e.g. ISO 27001), it is not possible to use the OS in the workplace.
I’m making this post to collect ideas as to what could possibly be done about that. If you have any ideas on how to help use Qubes in such an environment and make it compliant/possible to use with MDM, please post below, any and all ideas are greatly appreciated!
From experience, Qubes OS is far from matching requirements for regulated environments, the following bullets points are usually a problem, but depending on the security referential some may be ok or not
user is administrator
remote administration is hard
virtualization may not be considered safe enough
where to run MDM / antivirus
qubes are not encrypted independently
qubes are not hardened
Intune on Linux does not even do anything useful at the moment, and is poorly supported (officially ubuntu and red hat only)
provides a framework within which organisations develop their security
policies, and MDM is a tool that helps compliance within that
framework. I’ve seen cases where exceptions and exclusions are
acceptable within the IS management system.
The questions is whether Qubes systems can be brought within the system
in a way that is acceptable under 27001. In my experience this can
be done but it requires active engagement with IS and commitment from
management.
On @solene points, these are valid but our experience obviously differs.
No doubt - it is possible to run Qubes with a limited second user, but
it requires intervention and hand holding at the deployment stage. Even
where this is not acceptable, a properly conducted risk assessment and
policy structure can bring user/root cases within 27001.
In my experience, remote management can be set up relatively easily,
so that the whole Qubes system can be administered remotely. Auditing
and administration can be difficult but is possible, and can be brought
within the 27001 framework.
This is just a question for the organization - I’d be amazed if they are
not already using virtualisation at the server level, and I know compliant
organizations who use it at user level. (If they already use Xen,
perhaps as Citrix or Oracle, it’s a help.)
This is a great question, and is probably one of the most difficult for
IS/IT to understand and deal with. It requires an understanding of the
principles underlying their 27001 system and Qubes, and how they can be
applied in the Qubes case. Should there be AV in every Qube? Should
there be AV in only qubes that connect to the network? Should there be
AV only in Qubes that store and process data? Should there be AV only in
qubes where data leaves the system? These are all valid positions, and
will need to be considered and documented before roll out.
Harden them to a level that brings them within the 27001 system. Patch
and configuration management are very important here, and a decent
remote management system will help compliance,
Many people dont think of the ISO standards as providing a framework,
particularly if they use a consultant who has little interest in
providing understanding. But that is exactly what they do, and given
a good risk assessment and implementation it is possible to bring Qubes
use within an 27001 compliant system. The details of this will be
specific to each organisation, and some auditors may require detailed
walk throughs, but this is acceptable.
In my experience the benefits provided by Qubes can be highlighted and
the systems brought within a 27001 compliant ISMS, (confirmed by audited
and accredited cases). No doubt there are Qubes specific issues, but
with the right setup and onboarding, in my experience, calls on IT are
no greater than Mac/Windows.
As always, it really helps if there is a commitment at board level. If
there is a separate audit group, demonstrations and Q&A sessions are
useful before developing a roll out strategy. But there’s nothing Qubes
specific in these points.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Side note, I did not say Qubes OS can’t be used in such environments, but it might involve a lot more work than management would tolerate compared to using Ubuntu or Windows
ISO27K is not a pinnacle of security, to be honest.
It’s updated approximately once a decade, and frequently lags behind industry accepted best practice in some areas. The scope of ISO27K’s reach is also different to each organization, as each organization can choose its own scope (1 login page, 1 application, 1 business unit, 1 continent, or the entire organization).
ISO27K has no definition on how to approach security for an operating system designed for segmentation in the way that Qubes OS does.
And on MDM, most MDM systems make a default assumption that the MDM infrastructure is both trusted and secure - which almost none of them actually are. From various known exploits on these platforms, to the fact that MDM is often deployed in known exploitable ways by its IT Administrators.
MDM requires you to trust an additional infrastructure not anticipated by Qubes OS. And that’s perfectly fine if an organization wants to do that, but it’s also against Qubes OS’s own stated goals (distrust the infrastructure). It raises questions, such as which MDM platform should Qubes OS consider trusted vs. ones it should not trust?
I’m not sure Qubes could or ever would be able to make these decisions on behalf of their users.
From my perspective that leaves you with two broad options:
Make the Qubes (the VM’s) conform as much as possible to corporate MDM, ISO27K, patching policies etc., and get an exemption for some or all of dom0.
Make the Qubes and dom0 conform as much as possible to corporate MDM, ISO27K, patching policies etc. and sacrifice the local control that some of Qubes OS is defined for, and which it relies upon (e.g. give up on certain security functionalities built in to Qubes OS).
The choice is yours, but it certainly does need to become a concious choice of security, compliance, threat, and risk tradeoffs.
I am a bit fuzzy on what aspects of MDM are being discussed. MDM stands for mobile device management, so Qubes on a desktop would not seem applicable.
(note: I do understand the part where often companies can implement brittle policies, sometimes with a lack of understanding of the topics.)
Are we talking centralized/remote configuration in general? (For example, one well known example being windows group policy)
Possibly related is the recent qubes-ansible.
While it does not address remote administration, it tries to provide centralized administration of the local system from a MgmtVM qube. Link here:
(Note: If a centralized system could be given access to MgmtVM in a secure way, there would be the potential for centralized configuration.)
If you’re unlucky, ISO27K might even lessen your security or hide important holes, like it happened sometime ago with the Crowdstrike crash: They were certified according to ISO27001, but no one seems to have noticed that the whole architecture of this system posed (poses?) a significant security risk, because it had (has?) access to critical system components and was not properly secure itself.
Unfortunately, this may occur with most security audits and certifications according to ISO 27001, because only security management is typically checked, and technical security may not be examined at all. But such a type of security evaluation may be attractive to management, if they are not technical people and are content to have a checklist saying they have done all that is needed. In many cases, this may be the reason that tools like MDM, AV, patch management, etc. are prescribed, whether they make sense in a given situation or not, or even reduce security.
Especially if a somewhat unusual, modern system like Qubes OS is used, this may be a problem, since checklists that were created for conventional environments like Windows may not be applicable here. For instance, you may question if a virus scanner is necessary if you use disposable, Linux-based VMs for your work, which are automatically cleaned by being destroyed after use.
Here, it might be helpful to switch from the ISO27K mindset to the German IT-Grundschutz, which adds technical security to the management aspects and does this in such a way that a certification according to Grundschutz automatically contains an ISO27001 certification, too. In Grundschutz, there is even a module for Qubes OS, and an audit using this module goes a long way to make Qubes OS “officially secure”, helping a non-technical management to understand the situation better.
Appreciate that document! I wish I knew about it earlier (more on this later).
As sad as it might sound, some portions of the certifications might be implemented as mere security theater and outdated guidelines, which cause the end-users to workaround them, lessening the overall security.
I was involved in writing and verifying one company’s procedures for their ISO 27001 certification: in particular with the “Bring Your Own Device” part, but a general review was also needed. This is the point, where the linked document would come in handy, and assist me with writing some of the processes, even though I had to improvise and use common sense, e.g. “If using Qubes OS, domains other than dom0 and stubdomains must not be virtualized in PV mode”. However, whether the final procedures would account for what I wrote or recommended (or even actually enforce it later) is not for me to decide - after all, that’s not my company: most likely some of the more annoying, outdated guidelines, like so that passwords must be rotated periodically, were kept as part of the certification, despite the NIST SP 800-63 recommendations, i.e.:
[…]
Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
After all, a company, a system, or an employee might have a certification and it won’t matter in practice, if the means to “receive a fancy paper” are not based on “the real deal”.
Still, I wouldn’t mind a work machine managed by a company’s Service Desk team, which runs Qubes OS, but the management part is handled by a “Service Desk management qube”, which has the permissions to create, modify and delete other qubes with their appropriate tags, e.g. “created-by-mycompany-mgmt”, and each one having not only preinstalled and preconfigured software for me to focus on the actual work and not do anything stupid by accident, but also, them being the endpoints, having agents for a SIEM/XDR like Wazuh preinstalled.
Note: that’s me thinking out loud. If there’s a market demand for something like this, I’d be happy to cooperate on making a ready-made technical solution or writing further guidelines and procedures.
It’s been possible to run remote centralized administration in Qubes for
some years. Take a look at Joanna’s introduction to the Admin API
from 2017, and the use of Salt.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
The big mindswitch for me is the absence of a paywall for access to the documents. It’s almost as if the BSI is hoping for widespread adoption of good security practices… even in small and micro enterprises!
Wow, I had no idea guidelines like that (from an agency reputable enough to probably be followed in a corporate environment) even existed. Thanks much!
Yup. The existence of an ISO 27k1-compatible standard that explicitly includes QubesOS is a good sign, though, as this could help convince management/IT to allow QubesOS to exist as an OS option.
