[Servercert-wg] Ballot SC29v3: System Configuration Management

[Tobias S. Josefowitz]

On Wed, 15 Apr 2020, Neil Dunbar via Servercert-wg wrote:

>
> I suspect that this reply will be a bit disappointing to you; the minutes of 
> the fuller discussion can be found on: 
> https://cabforum.org/pipermail/netsec/2020-April/000326.html

When taking in the (preliminary) minutes on this topic from the NetSec 
meeting on 2020-04-02, I think in addition to Neil's excellent conclusion:

> In conclusion, then, I think that the text of the ballot does allow 
> automated updates from the vendor or mirror, but I think that the 
> description of the change control process would need to be considerably 
> more documented than a mere "we just patch when Red Hat pushes a patch".

We should probably say that the text of the ballot *isolated from 
everything else by itself* does allow automated updates from the vendor or 
mirror in the sense that it does not explicitely prohibit it.

To progress with SC29(vX) we probably have to answer a few seperate 
questions.

First of all, are 1h and 3a really the place to explicitely prohibit 
automatic/unsupervised system updates from a vendor? The current 1h 
requires a weekly review of configuration "to determine whether any 
changes violated the CA's security policies", with SC29(v3) we instead 
require a change management process and that changes follow the change 
management process (and fall back on 3a for technical 
enforcement/monitoring).

The CA's security policies could at this point be just as arbitrarily bad 
as the change management process (and it's results) required if SC29(v3) 
was adopted.

So maybe the question of whether to allow unsupervised "security" updates 
is not strictly related to SC29(vX).

Yet, whether unsupervised "security" (or other) updates are acceptable is 
certainly a good question. My very own first impulse when the notion came 
up in Bratislava was "no, just no". I had not even considered the option 
that somebody would even consider this appropriate (in CA context).

Then again, larger parts of the security circuit will emphasize a lot how 
important - in general at least - swiftly applying security updates and 
patches actually is, and in fact whenever I hear an organization bring up 
their "patch management" it certainly gets my eyebrows raised and more 
often than not leaves me, admittedly, somewhat disappointed.

CA context is not just any context, I would certainly hope and hope to do 
my part in making sure that CA systems are managed by some of the most 
qualified personnel there is to be had, and in the best and most secure 
ways possible. This obviously includes knowing every detail of the system 
(state), having an overview of changes applied over time, and so on.

Certainly, providing my own repository with contents controlled by me is a 
handy building block to such an approach, and probably is the default 
approach here.

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.

Fundamentally, this approach introduces a time of uncertainty during which 
systems will be in a state not fully tracked by CA perrsonnel. Maybe 
fundamentally, that's not acceptable. On the other hand, fundamentally, 
requiring approval of "security" updates does introduce a delay to when 
patches and "security" updates are applied, however with certain levels of 
staffing this delay can be reduced to the "minutes" range.

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?

Tobi