IT-Grundschutz Module for Qubes Client

[GWeck]

Qubes OS version (if applicable) R4.0+

Affected component(s) or functionality (if applicable) Documentation

Brief summary Although Qubes is able to provide a high level of security, like with any other operating system this can be subverted by sufficient stupid usage. Installation, configuration and usage may be done in such a way that the excellent features of the system are wrongly used or not used at all.

In order to help users set up a secure operating environment, the German Federal Office for Information Security (BSI, Bundesamt für Sicherheit in der Informsationstechnik) has defined an excellent standard covering most relevant issues, in a much more detailed way than is done in ISO 27001. The standard is called IT-Grundschutz (some thing like baseline security) and covers about 100 areas, called modules. In the area of operating systems, there are, among others, modules for Windows, Unix, and MacOS.

As a module for Qubes OS could be helpful, I have written such a module (which is not too much work, as these modules are restricted to 10 pages at most). The module describes 6 specific threats to Qubes usage and 18 requirements for security measures which can help counter these threats.

Additional context A draft version of the module is here: Qubes_GSC_Module.pdf Any comments, corrections and suggestions for improvement are highly welcome! In a few weeks, the German version of the module will be published as a user module on the webserver of the BSI. If the BSI sees sufficient interest in this module, it can be promoted to be a part of the standard.

Relevant documentation you've consulted A lot of suitable parts of the documentation, which helped a lot in the construction of the module.

[SvenSemmler]

Hi @GWeck ,

your introduction to Qubes OS on page 1 is the most compact, technically correct and complete description of Qubes OS I have seen to date. Excellent! I hope this get's copied and reused often.

Some very minor feedback points:

• page 2: misspelling "operatins system" --> "operating systems"

• SYS.2.8.A3 "No additional software MUST be installed in Dom0" might be downgraded to "additional software in Dom0 must be reviewed and approved by the CISO and should be a rare exception" or something of that nature. The example that comes to my mind immediately is: redshift (a program that will change the color composition based on time of day to reduce eye strain and aid sleep quality).

• SYS.2.8.A7 ... one may add a sentence to point out the usefulness of the firewall regarding OUTGOING connections. Many qubes holding critical data might not need any network connection at all, hence severely limiting the damage Malware can do (no exfiltration). Others, like qubes dedicated to the email client might be configured to only allow connections to the respective IMAP/POP and SMTP (maybe LDAP) servers. Thus eliminating HTML email based attacks like https://efail.de or just plain spying/tracking since they won't be able to connect.

Just as you point out that INCOMING connections should be configured as restrictive as possible, the same argument can be made for OUTGOING connections. This comes back to the basic idea of Qubes as I understand it: minimize trust! I don't trust the software running in any qube. Therefore compartmentalization and firewall are the tools at hand to limit the damage that can be done. Trusted qubes containing critical data SHOULD be completely offline. Less trusted qubes that require network connections should be firewalled as strictly as possible. Qubes that allow all outgoing traffic SHOULD NOT contain ANY confidential data.

Another very effective step is the extensive use of offline/disposable qubes to edit documents. Just like you point out it is unsafe and potentially compromising to run any software in a TempalteVM, one may extend the same principle to qubes containing confidential and/or documents of untrusted origin. One may have an "archive" qube that holds the respective files but never ever opens/edits them in that qube. Instead any view/edit operation happens in a disposable offline qube and therefore any potential compromise is contained to that ephemeral instance.

See also: https://github.com/Qubes-Community/Contents/blob/master/docs/common-tasks/opening-urls-in-vms.md

[mfc]

great & interesting effort!

some minor typos/grammos:

• SYS.2.8.A1 "Qubes OS’ team" -> "Qubes OS developers"
• SYS.2.8.A3 "No additional software MUST be installed in Dom0" -> "Additional software MUST NOT be installed in Dom0"
• SYS.2.8.A9 "UDB" -> "USB"
• SYS.2.8.A15 "SHOLUD" -> "SHOULD"

comments:

• SYS.2.8.A16 it may be worthwhile to mention Heads in this context, which integrates with Qubes

[GWeck]

Thanks a lot for your comments. I have amended the description accordingly.

In the meantime, I have translated the text to German, the native language of IT-Grundschutz, and now I have submitted the module in both versions to the German Federal Office for Information Security (BSI, Bundesamt für Sicherheit in der Informsationstechnik), where it will hopefully be published on their webserver in the near future.

The current drafts in both languages can be found here:

Qubes_GSK_Baustein.pdf Qubes_GSC_Module.pdf

[GWeck]

For environments having sensitive data, it might be useful to encrypt the private volumes of AppVMs, even if Qubes as a whole is encrypted. This would be similar to the German SINA devices which are used to process classified information. For this reason, if have added an additional requirement to the text.

The new version of the draft can be found here:

Qubes_GSK_Baustein_V1_1.pdf Qubes_GSC_Module_V1_1.pdf

[brendanhoar]

@GWeck - FYI there are some cross-pool data leakage issues with multiple volume pools in 4.0, in particular with disposable VMs where the volatile volumes are created in the default pool even if the VM/template is located in a separately encrypted pool.

I believe Marek has resolved this issue in 4.1.

B

PS - there are also quite a few areas where it is clear that the Qubes design is primarily about compartmentalization and is NOT about anti-forensics (at least, not yet). Lots of chaff (e.g. VM window titles, etc.) ends up in dot directories in the dom0 primary user home tree, as well as other stuff in logs in dom0. This chaff might be converted to gold by an adversary.

[andrewdavidwong]

For environments having sensitive data, it might be useful to encrypt the private volumes of AppVMs, even if Qubes as a whole is encrypted.

This would be #1293.

[GWeck]

Thank you both for your clarification on this issue!

With the IT-Grundschutz module, the problem is the limited space (max. 10 pages). So I just could touch this issue. To fulfill the requirement, one would first have to decide on a threat model: What are we protecting against - a casual spy, a government agency with lots of power, compromising forensic analysis etc. Probably we would need different implementaions for each of these scenarios, so the requirement would have to be solved differently.

IT-Grundschutz provides a tool for these complex situations. A module might be accompanied by so-called implementation hints ("Umsetzungshinweise"), giving longer explanations and security measures for each requirement. It would be very helpful to have such implementaion hints for the Qubes module, but unfortunately writing this text would be well beyond my resources and, in part, beyond my knowledge. If this could be written as a community effort, however, I would gladly try to help and to enter it into the BSI data.

[GWeck]

After finishing the harmonization with the German BSI, now the final version of the Qubes Grundschutz module has been created. The main differences between that and the previous versions is the removal of redundant explanations which can be (better) found in the Qubes documentation. The resulting text is more concise and concentrates on what should be done and what not when installing and using Qubes. This final text will be published - hopefully soon - on the BSI Grundschutz website. I will put a note here as soon as this happens.

With this module available, Qubes systems can now be treated like any other systems when creating an IT security concept based on Grundschutz. As this is currently a user-defined module, it will not be relevant for a certification according to ISO 27001 based on Grundschutz, however, but it can help to provide a better consistency of the security concept.

Here are the texts of the module:

• in English: Qubes_GSC_Module_V3.pdf

• in German: Qubes_GSK_Baustein_V3.pdf

[GWeck]

The Qubes Grundschutz module now has finally been published by the German BSI, as a user-defined module. You can find it at Benutzerdefinierter Baustein Clients unter Qubes OS. The German version is located at Benutzerdefinierter Baustein Clients unter Qubes OS.

If you think it should be promoted to a standard module, relevant for certification, send an E-mail to grundschutz@bsi.bund.de. If a sufficient number of users need that module, the BSI may promote it.

[deeplow]

The Qubes Grundschutz module now has finally been published by the German BSI, as a user-defined module. You can find it at Benutzerdefinierter Baustein Clients unter Qubes OS. The German version is located at Benutzerdefinierter Baustein Clients unter Qubes OS.

If you think it should be promoted to a standard module, relevant for certification, send an E-mail to grundschutz@bsi.bund.de. If a sufficient number of users need that module, the BSI may promote it.

Quite a nice document. Thank you for your effort @GWeck.