[Servercert-wg] Ballot SC20v2: Configuration Management

[Wayne Thayer]

Ballot SC20 has exceeded the 21 day discussion period limit imposed by
section 2.3(3) of the Bylaws. Therefore, ballot SC20 has failed.

Please reserve a new ballot number and start a new discussion period when
ready to proceed with this ballot.

Thanks,

Wayne

On Mon, Feb 3, 2020 at 8:23 AM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

>
>
> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/3c566e74/attachment.html>