[Servercert-wg] Ballot SC29v3: System Configuration Management

[Neil Dunbar]

On 14/04/2020 19:21, Ryan Sleevi wrote:
>
>
> On Tue, Apr 14, 2020 at 9:49 AM Neil Dunbar via Servercert-wg 
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>
>     After lengthy discussions both on list and on the NetSec meeting,
>     the question about whether a CA approved source of
>     patches/software updates counts as a change managed process within
>     the text of the ballot. The conclusion to those discussions was
>     that it _does_ fall within the terms of this ballot. Note: it lies
>     entirely outside the remit of the NetSec committee to say whether
>     this is a good practice or a bad one - merely that it has the
>     criteria of approval and review as required. To that extent, the
>     ballot has been changed to explicitly require the change
>     management process results to be subject to review, rather than
>     "testing" per the previous wording.
>
> Just to make sure - that specific change (from previous versions) is 
> https://github.com/cabforum/documents/commit/aefc8ad1a106e40315ba01aa13ea00cb93363805 , 
> correct?
>
> I am concerned a bit with the above disclaimer, but may just be 
> confused, and so wanting to check my understanding and make sure we've 
> got the same conclusion :)

The github change is correct, yes.

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

Apologies that those were not made available sooner, but (as you can 
see) it was a very ... spirited ... discussion which covered a lot of 
ground - I tried to capture everyone's viewpoint. The people on the call 
will be able to say whether or not I succeeded.

> Goal: Enabling automatic updates (i.e. directly via software), which 
> connects to a third-party (e.g. the OS or software vendor), without 
> requiring any human documentation or approval of the specific updates 
> being applied, is clearly and explicitly forbidden.
>
> Goal: Enabling automatic updates (i.e. directly via software), from a 
> CA-maintained list of approved updates, is fine. A CA process that 
> defines that they approve updates provided by the OS vendor, and 
> maintaining documentation to the effect of exactly what was approved 
> and installed, is also fine.
>
> Is that a correct understanding and conclusion?

I do not think that these are accurate statements of the principal goal 
of the ballot. The goal of the ballot was primarily to encourage CAs to 
move away from manual reviews of system configurations towards a 
continuous automated approach to reporting and reviewing and alerting 
upon of configuration changes, unless such changes were the anticipated 
results of an authorised modification via a change control process.

The discussion pointed to above does allow the notion of an automated 
update process *assuming* such a process has been clearly documented, 
it's approval clearly noted (by someone capable of knowing what this 
entails and properly authorised to make the determination) and the 
review process for when and how changes happen is also well documented. 
I presume that an auditor would want to know upon what basis the trust 
in such an automated approach was founded, but clearly I can't speak for 
any auditor.

Now - I (and others) have noted risks in the above process; but it seems 
to me that - according to the text of the ballot, as well as the intent 
of the team members discussing said ballot - that such a configuration 
is within the context of a change control process requiring 
documentation, approval and review (as specified in the text). I cannot 
say that I consider it a *good* change management process, but the 
ballot's corollary goal is to ensure that system modifications follow a 
defined change management process, without specifying what that process 
should be. We do not, for instance, state that the change control must 
follow ITIL specifications - although I know for a fact that some CAs do 
use ITIL as their change control process form.

> Specifically, I want to make sure that the view is not that the NCSSRs 
> permit treating the OS or software vendor as a Delegated Third Party, 
> where the OS vendor themselves are (effectively) tasked with 
> documentation, approval, and review of updates to the CA's systems. 
> The effect of allowing automatic updates is to effectively give 
> control of the system to the vendor, and there needs to be some CA 
> responsibility in ensuring the systems are in a defined and documented 
> state.
I still think that the CA is responsible for the representation and 
behaviour of the systems so managed: merely saying "Oh, Canonical put 
out a bad Ubuntu patch and that allowed system X to get owned" would not 
(to me) be an acceptable explanation. The CA is still responsible for 
knowing about, and taking responsibility for, any changes which occur on 
any of their systems, including ones which came from patching via 
sources from an externally curated repository.
> Given the discussion folks had, I want to make sure that no CA or 
> auditor will interpret this as allowing automatic updates. More 
> concretely, a statement "Running on a fully patched OS" would be bad, 
> while a statement "Running on this OS version, with patches X, Y, Z 
> applied" is good, in that it's always concretely defined the state of 
> the CA's system. It doesn't seem that "fully patched" can meet the 
> criteria of approval/review, but I'm hoping I'm not missing some of 
> the discussion.

I think that any CA would still be expected to say "the state of this 
system is base OS version aa.bb.cc, with the following list of patches 
applied: X, Y, Z" - some nebulous term like "fully patched" is clearly 
defined as a function of time (since patches appear from vendors at 
points not under the control of the CA), rather than as an iterative 
function of patching activity. The patch history remains entirely the 
responsibility of the CA to attest; a CA cannot just perform a current 
package list, hand that to an auditor and say "there you go" - the CA 
still has the responsibility of saying "Patch C on date X replaced Patch 
B on date Y which replaced Patch A which was deployed on date Z".

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".

Regards,

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200415/99b41983/attachment.html>