[Servercert-wg] Ballot SC20v2: Configuration Management

[Ryan Sleevi]

On Mon, Feb 3, 2020 at 9:48 AM Neil Dunbar via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Ryan,
>
> Many thanks for the feedback - always welcome.
>
> With respect to rescoping the word "change" to mean "a workflow process
> described in a change management system" (ie, Bug Tracker, ITIL Workflow,
> etc.), I can see that this is a _possible_ interpretation. I'm not sure
> that it's a _plausible_ interpretation. Plausible, in this instance,
> meaning plausible to a qualified auditor. The reason that I think this is
> so is because 1(h) defines the targets systems for any change, and demands
> that those changes must be documented in a change management process.
>
I can appreciate your optimism and faith in auditors, but I do not share
that same optimism. Considering this Forum itself has had debates on what
it means to send a mail, I'm wanting to make sure any requirements here
have no 'reasonable' chance at misinterpretation, however implausible.
After all, even when discussing on this very list what entropy meant and
how a 64-bit serial could not consistently ensure 64-bits of entropy, we
still saw widespread issues.

I think the problem is compounded by, and not resolved by, the proposed
1(h). That is, a CA seems like they can reasonably conclude that a "change"
is a modification to the system configuration managed through a "Change
Management System". Unauthorized modifications to the system are not
changes, because they did not go through the change management system.

<snip>

> Thus, by your given example, a system change not reflected in the change
> management process would be, by definition, unauthorised. Thus, any
> continuous monitoring system which did not note such unapproved changes
> would be deficient by its nature, since it is required to report "any
> configuration change".
>
I think the problem with this, that I was trying to highlight was a CA that
defines "change" as "The thing within the Change Management System", rather
than "a modification". Under such a definition, "any configuration change"
is "All things within the change management system", and any unauthorized
changes are "those modifications entered into the change management system
but were applied without being signed off".

Such a definition has the obvious flaw of leaving a gap for "modifications
not entered into the change management system", which is the flaw I want to
make sure we address.

> Now that said, I'm certainly open to even more stringent language (hoping
> that it doesn't allow yet other "creative interpretations"!)
>
My previous message tried to explore possible ways to resolve this.

Certainly, the inconsistent use of "Change Management Process" doesn't
help, because if we assume it's a Proper Thing that should be defined, then
the definition is left ambiguous. This is similar to the problem that
happens when you have a Bug Tracker as a term; the known bugs are tracked
as Bugs (proper), while the unknown bugs are, well, unknown to the Bug
Tracker.

A different way to try to resolve it, if you found the previous attempt
lacking, is to separate out "configuration change" from "Change Management
Process". For example, if "any modification" must go through a Change
Management Process, then the Change Management Process can manage Changes
(authorized modifications), while any unauthorized modifications are, by
definition, things not tracked in the Change Management Process.

If you want to open a GitHub pull request from your branch, I can comment
in-line with suggested edits/modifications to try to accomplish this, which
might be easier than the above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200203/2391e22f/attachment.html>