Have to drop Qubes because of company policy: workarounds?

[Pablo Di Noto]

Hello!

I have been a Qubes user for 3+ years and adopted its separation-of-concern model deeply into my day to day activities.

A year ago I started to work for a cloud company that is seeking/re-certifying several security certifications, and among the requirement of these certifications are strict policies that require any organization member accessing any company resource to have a certified antivirus solution installed on their computer(s), including Linux. That is a very common requirement for corporate work. 

Unfortunately, these policies leave much room for interpretation, and companies tend to lean on the safe side to avoiding corner cases that may "upset" the certification auditing teams.

Long story short, as Qubes cannot run (and does not make any sense to run) a self-updating, status reporting antivirus on dom0, it is not compliant.

Sad times, as I will be having to go back many, many steps back in terms of real security and data protection in order to use one of the main distributions.

My managers are ok for me to to use xen (or other hypervisor, for that matter) and a compliant distribution as dom0 which would make the whole thing almost indistinguishable from a regular endpoint to any auditor.

Now finally the question: How difficult would be to have a Xen-based Fedora (or better, Debian) dom0 and then install the libvirt and qubes middleware for template handling, inter VM communications, etc? I know that would require a cumbersome install process, but does seem feasible. At the same time, it could be a nice experience in terms of testing Qubes middleware into multiple dom0 environments. 

I know there are security implications to this: All the hardening on non-connected dom0 would be lost, the use of a off-the-shelf dom0 may bring lots of attack vectors, all installation-time setup of sys-* VMs would have to be redone manually, etc. But the final product would have the isolation-by-nature workflow I grew to love.

Thanks for any advice about feasibility of this.

Cheers,

///Pablo

[Chris Laprise]

I think you may be overstating the problem of running anti-virus on
Qubes. If you could find an AV that updates its virus definitions via
signed RPMs, then it can be made to work without a lot of effort.

Beyond that, you could still do it without RPMs, assuming the AV program
requires all of its data to be signed.

-

Whatever AV installation you had in dom0 would also need to be installed
in a template as well... this allows DispVMs to scan your various
working VMs while still maintaining isolation. The definition update
mechanism for the template would be the same as for dom0 (i.e. import an
RPM, or some other signed data file via qvm-copy).

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Pablo Di Noto]

Hello,

 

I think you may be overstating the problem of running anti-virus on
Qubes. If you could find an AV that updates its virus definitions via
signed RPMs, then it can be made to work without a lot of effort.

The issue in this case is two fold: The designated ~antivius~ endpoint protection solution (Sentinel One in our case) offers no support for Fedora, specially an oldish one like F25. Also, the whole compliance point is to have the endpoint report frequently its compliance status, which dom0 would not do.

And, of course, this solution has its own update mechanism, so it cannot be made work with the RPM proxy Qubes offers.

Beyond that, you could still do it without RPMs, assuming the AV program
requires all of its data to be signed.

-

Whatever AV installation you had in dom0 would also need to be installed
in a template as well... this allows DispVMs to scan your various
working VMs while still maintaining isolation. The definition update
mechanism for the template would be the same as for dom0 (i.e. import an
RPM, or some other signed data file via qvm-copy).

I see no issue with that.

Unfortunately, from my company point of view, having only all VMs with the endpoint security software would not make me compliant.

Thanks for your comments!

///Pablo

[Metatron]

On Sat, Sep 07, 2019 at 09:33:11AM -0700, Pablo Di Noto wrote:
> Hello,
>
>
> > I think you may be overstating the problem of running anti-virus on
> > Qubes. If you could find an AV that updates its virus definitions via
> > signed RPMs, then it can be made to work without a lot of effort.
> >
>
> The issue in this case is two fold: The designated ~antivius~ endpoint
> protection solution (Sentinel One in our case) offers no support for
> Fedora, specially an oldish one like F25. Also, the whole compliance point
> is to have the endpoint report frequently its compliance status, which dom0
> would not do.
> And, of course, this solution has its own update mechanism, so it cannot be
> made work with the RPM proxy Qubes offers.

1) Create a standalone VM called sys-net-work based on Debian.
2) Install your AV there.
3) When you are at work boot that one and map your firewall to it instead of
the standard sys-net.

This is equivalent to a non hypervisor OS as sys-net is the root of the
system and through it flows all network traffic.

This should check your management's tick box as sentinel will report back
that it is running.

And it should meet your needs as you can stay on qubes OS and additionally
remap to sys-net when you are home so you need not run their closed source
"security" software when you are not obliged to.

>
>
> > Beyond that, you could still do it without RPMs, assuming the AV program
> > requires all of its data to be signed.
> >
> > -
> >
> > Whatever AV installation you had in dom0 would also need to be installed
> > in a template as well... this allows DispVMs to scan your various
> > working VMs while still maintaining isolation. The definition update
> > mechanism for the template would be the same as for dom0 (i.e. import an
> > RPM, or some other signed data file via qvm-copy).
> >
>
> I see no issue with that.
> Unfortunately, from my company point of view, having only all VMs with the
> endpoint security software would not make me compliant.
>
> Thanks for your comments!
> ///Pablo
>
> >
> >
>

> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ca6a5923-15f7-42c2-a0c4-d2179b61abcd%40googlegroups.com.

[Pablo Di Noto]

Hello,

 

> > I think you may be overstating the problem of running anti-virus on
> > Qubes. If you could find an AV that updates its virus definitions via
> > signed RPMs, then it can be made to work without a lot of effort.
> >
>
> The issue in this case is two fold: The designated ~antivius~ endpoint
> protection solution (Sentinel One in our case) offers no support for
> Fedora, specially an oldish one like F25. Also, the whole compliance point
> is to have the endpoint report frequently its compliance status, which dom0
> would not do.
> And, of course, this solution has its own update mechanism, so it cannot be
> made work with the RPM proxy Qubes offers.

1) Create a standalone VM called sys-net-work based on Debian.
2) Install your AV there.
3) When you are at work boot that one and map your firewall to it instead of
the standard sys-net.

This is equivalent to a non hypervisor OS as sys-net is the root of the
system and through it flows all network traffic.

This should check your management's tick box as sentinel will report back
that it is running.

And it should meet your needs as you can stay on qubes OS and additionally
remap to sys-net when you are home so you need not run their closed source
"security" software when you are not obliged to.

That is, indeed, a clever hack.

I did not think about installing the endpoint security software on a `sys-net` role VM.

Fortunately my organization is ran by very bright technical people, with whom I interact everyday. 

It is clear that despite ticking the check boxes from the auditor point of view with this idea, I would be willingly violating the internal rules they have setup, and maybe risking the company certification in case of a deeper review after an incident. Despite the overall lack of consideration for specific (and arguably better) security setups, doing this hack will have me connecting to our internal networks and avoiding the endpoint security scan the applications really using them.

Thanks a lot for you idea!

Regards,

///Pablo

[awokd]

Pablo Di Noto:

> It is clear that despite ticking the check boxes from the auditor point of
> view with this idea, I would be willingly violating the internal rules they
> have setup, and maybe risking the company certification in case of a deeper
> review after an incident. Despite the overall lack of consideration for
> specific (and arguably better) security setups, doing this hack will have
> me connecting to our internal networks and avoiding the endpoint security
> scan the applications really using them.

The auditors might be satisfied if you are able to explain how Qubes
itself is a compensating control on the limited file scanning ability of
your AV, but doing so could be a challenge.

For a really ugly hack, you might be able to readonly loop mount -pool00
(and -root?) into a network connected AppVM running your AV, so it could
scan them as large files. This breaks the Qubes security model pretty
thoroughly, but would make auditors happy I guess. You'd at least have
the benefit of continuing to use Qubes.

[Pablo Di Noto]

Hello,

> It is clear that despite ticking the check boxes from the auditor point of
> view with this idea, I would be willingly violating the internal rules they
> have setup, and maybe risking the company certification in case of a deeper
> review after an incident. Despite the overall lack of consideration for
> specific (and arguably better) security setups, doing this hack will have
> me connecting to our internal networks and avoiding the endpoint security
> scan the applications really using them.

The auditors might be satisfied if you are able to explain how Qubes
itself is a compensating control on the limited file scanning ability of
your AV, but doing so could be a challenge.

Yes, it is challenge in many levels. Been thru five companies during their PCIDSS certification, for instance, and the way the whole business work is to promote the usage of know things, despite their real security value.

To give and rough idea, a relatively patched Windows machine will always be seen as a more compliant endpoint device that using Chromebook.

If Google is not yet able to get that into the "nobody got fired by" circle despite having a huge financial backing and a decent usage track , imagine the relatively obscure OS we love.

On the bright side, all auditors I spoke to are either a) aware of Qubes as state of the art in secure endpoint (given a decently trained user, that is) or b) Amazed when told and show how it works.

 

For a really ugly hack, you might be able to readonly loop mount -pool00
(and -root?) into a network connected AppVM running your AV, so it could
scan them as large files. This breaks the Qubes security model pretty
thoroughly, but would make auditors happy I guess. You'd at least have
the benefit of continuing to use Qubes.

I soon have the annual company meeting, and may find a suitable stop to discuss this with my managers.

Will be an interesting talk, for sure.

Thanks for the idea, will check how S1 deals with images and raw filesystems.

Cheers,

///Pablo