> On 15 Aug 2017, at 17:08, Ryan Sleevi <sle...@google.com> wrote:
>
> The challenge, which I think is worth articulating even as I try to form a
> suggestion, is that it creates ambiguity as to what's "sufficiently not
> stupid".
>
> For example: Is a physical host running a hypervisor sufficiently isolated
> from its guests? (Maybe, maybe not - and if not, popping the hypervisor is
> sufficient to gain lateral access).
> For example: Is a physical host with two dedicated NICs, each going to
> different segments, sufficiently isolated? (Arguably, no, it's effectively a
> bridging state - but that may be non-obvious to some CAs, based on past
> evidence)
> For example: Is a switch handling VLAN tagging sufficiently segmenting?
> (Maybe, maybe not - popping the switch would be sufficient to gain lateral
> movement)
>
> Even if we have roots in a fully (physically) airgapped configuration, for
> the online issuance, we need to have some interaction between the untrusted
> 'outside' and the trusted 'inside' - and wanting to make sure we've got
> something sufficient enough that it would survive a pentest seems a
> reasonably low bar. The problem is articulating that.
I think that’s it’s a reasonable context to say that no host can be allowed to
even logically bridge networks - but that, IMO, is an addition to the existing
NetSec rules. A perfectly reasonable one, but outside the scope of “clean up
some obsolete text”.
So a dual NIC’ed host can have bonded NICs, or failover NICs - but they must
all hook to the same network segment. *For the moment* I take the view that
hypervisors can only hold guests which are part of the same logical network.
There is further discussion on virtualisation and cloud stuff to come, but
we’re not there yet.
[Note: here I’m talking about hypervisors as standard hosts. Not TPM’ed hosts
running launch controlled attestation, or stuff like that]
The question of pen testing air gapped configs did come up: there is reasonable
resistance, though, to connecting the airgapped system to an outside network
*purely* for pen testing to happen. In other words, pen testing is a reasonable
thing to request *on the assumption that the core architecture is not changed*.
Otherwise you’re not actually pen testing the system under description.
For instance, if using a USB storage device to export CRLs, for instance, it’s
probably reasonable to ensure that the device isn’t carrying executable
content, or at least that such content cannot execute. I guess that a security
sweep could cover that.
>
> Yeah, another perspective I can totally appreciate, although not without risk
> :) I think we'd be in agreement that an 'admin' password and an 'operator'
> password is a terrible idea - but as worded, it'd be permitted (unless I'm
> misreading). Is the concern limited to HSMs (which, as you note, may have
> physically distinct controls)? Is there a way to encompass that single-factor
> is permitted if it's physically distinct (e.g. two different physical devices
> / "something you have"), but otherwise, multi-factor is required ("something
> you know" + something else)? Does that strike the right balance, conceptually?
I think that two physical devices required as keying material for
authentication is a reasonable understanding, since that’s where we were going.
Like I said, it stems from the notion that you might well have a crappy laptop
which is responsible for hooking to the Root HSM for generating CRLs, etc. But
the security isn’t vested in the laptop really, it’s in the HSM activation
protocol. But, as things stand, your laptop would need to have MFA because
that’s what the NetSec rules state. And even providing that MFA on an isolated
system can be very tricky, given how OTP/U2F etc works.
The problem statement, as a whole, for this ballot was [paraphrased]: “Some of
the text here is obsolete, or highlights security postures which are, at best,
of limited utility, given what we know today. Can we propose some low
controversy changes which don’t make the position materially worse?”. There are
many other discussions and future requirements to come. This was only a first
stab.
Cheers,
Neil
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public
