[Servercert-wg] Ballot SC29v3: System Configuration Management

[Ryan Sleevi]

On Wed, Apr 15, 2020 at 8:45 AM Tobias S. Josefowitz via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> However, maybe one could indeed argue - as in fact Dimitris has - that by
> having good logging, monitoring and alerting about unsupervised security
> updates, and by having personnel following up on these in due time, that a
> CA may have an equally good grip, overview, understanding and control of
> their systems.
>

While I agree that Dimitris has argued that, I don't think that this is a
good or reasonable state for system administration. I think it's very
negligent and dangerous, because it relies on the potentially-compromised
machine attesting that it's not been compromised. RFC 3514 is nice and all,
but that's not a recipe for system's management approaches.


> Assuming it took (for some CAs) maybe 6 hours until staff can look at
> security updates, would we prefer security updates were applied or not
> applied in the meantime? Or is the very first problem with this scenario
> anyway that 6 hours is much too long regardless?


Microsoft's Security Response Center (MSRC) has a great treatise on this: The
10 Immutable Laws of Security
<https://blogs.technet.microsoft.com/rhalbheer/2011/06/16/ten-immutable-laws-of-security-version-2-0/>
.

Law #1: If a bad guy can persuade you to run his program on your computer,
it's not solely your computer anymore.
Law #2: If a bad guy can alter the operating system on your computer, it's
not your computer anymore.

The lack of threat modeling for supply-chain attacks is concerning. I agree
that just like it's turtles all the way down
<https://en.wikipedia.org/wiki/Turtles_all_the_way_down>, and trusting trust
<https://dl.acm.org/doi/10.1145/358198.358210> is hard, there's no doubt a
necessity to trust your OS vendor not to Be Evil. But that trust to not Be
Evil is not the same as trusting them to not make mistakes or have bugs.
The point of the review is to make sure that systems are in defined states;
ideally, states that can be readily recreated if necessary (modulo the
private key, of course). The point of the NCSSRs is to make sure that state
changes do not go undetected (i.e. DigiNotar), but that's necessary, not
sufficient. Understanding when and how a CA system undergoes a state change
is equally important - least of all, because it's necessary to know what
state you "should" be in to compare when you look at what state you "are"
in.

As Trev highlighted in the minutes, there's an element of making sure that
applying the patch is not going to disable some security control. I'm
shocked and disappointed by how many CAs have made configuration changes
and had it cause issues or disable their security or system checks. Patches
are no different, OS vendor or not.

I think you're right to highlight that, unfortunately, the state of the
world for some CAs may be security practices very misaligned with the goals
and expectations of a globally, publicly trusted CA (or at least, those
goals and expectations as seen by a root program), and so I appreciate that
SC29 brings this to stark, unfortunate attention. I also agree that we
shouldn't let the perfect be the enemy of the good - we need to make
incremental improvements.

My worry from the discussion, however, is that responsible CAs with strong
change management systems will see such systems as unnecessary, because as
the Forum, we potentially voted on a weaker set of expectations. New CAs
will also lack the context that indicates such an approach of blindly
trusting the vendor is dangerous.

I'm not sure the right approach to resolve this. Normally, it'd be ideal to
capture in the ballot, but I can understand that some CAs may be
self-interested to oppose security requirements stronger than what they
practice, and not unreasonably so. It may be that the answer is via Root
Program communication. Unfortunately, simply "telling" isn't enough to have
confidence that the issue isn't practiced, and "showing" (i.e. audits) is
what's desired. I think if we were to pass this up with the NCSSRs, given
the issue posed, one possibility is that CAs will be required to provide
the detailed control reports and show and document exactly their change
management process. Root Programs could use that to provide feedback about
whether or not it meets the Root Programs' expectations, helping the CA
improve their security posture to an acceptable level. That's a much bigger
change, and puts a lot more work on the Root Programs, and so I'd prefer a
more equitable solution such as via the BRs/NCSSRs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200421/fce38637/attachment-0001.html>