[Servercert-wg] Ballot SC29v3: System Configuration Management

[Tobias S. Josefowitz]

On Mon, 27 Apr 2020, Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote:

> This statement proves that there must be a huge misunderstanding somewhere 
> that I still can't exactly pin-point. None of what you say above matches 
> anything related to this thread. The NetSec subcommittee stated on the last 
> call I participated (with an auditor present), that even when they wrote the 
> original ballot language, they thought that the practice HARICA tried to 
> clarify was allowed. Their intent was not to prohibit this practice. I am 
> glad I brought this up in Bratislava, even if it was "by accident", because 
> it revealed an ambiguity that resulted in different interpretations. The 
> subcommittee tried to clarify this by stating "the intent" of the ballot that 
> clearly and unambiguously allows the practice we described.

Just as a clarification, at least in so far as I am concerned, I think the 
intention of SC29 - for me - is neither to allow nor to necessary deny 
unsupervised and unchecked security updates. It is, for me, much more from 
transitioning from [human] review to configuration management and/or 
continuous monitoring.

I think it is fair to say that the NetSec Subcommittee aimed to enable 
this transition without side effects on what goes and what does not, other 
than at the very core of review vs. continuous monitoring. We do introduce 
the concept of change management and rely on it, but to be honest we fully 
assume that all CAs naturally already have a change management process, so 
this should at least practically not have any side effects.

With SC29, we place as many or as little requirements on the change 
management process as we currently place on the "CA's security policies". 
I personally think we should develop the NSRs into making more concrete or 
substantial demands, generally, but for now allowing to replace 
error-prone [human] review with automation seems like a net benefit both 
for security and for reducing unnecessary pain in CA operations.

SC29 should in so far, if worded/executed right, really not forbid or 
allow that much that was not allowed or forbidden before.

Thus, as far as I am concerned, SC29 really should not be taken as an 
endorsement of unsupervised automatic security updates as provided by some 
kind of upstream.

In the same vein, I would think that - while the discussion about 
unsupervised and unchecked security updates is a good one to be had - I 
think it is respectively should be mostly disconnected from SC29.

That said, I will say that I am not convinced that you could not possibly 
design a framework with compensating controls around unsupervised 
automatic updates on some systems that would at least in practice be as 
robust as reviewing all updates before publishing them via your own 
repository. The question maybe is more, how likely are you to instead 
shoot yourself in your foot if you attempt this, and should this be 
discouraged/forbidden even if someone could get this [some value of] right 
in theory?

Tobi