[Servercert-wg] Ballot SC20v2: Configuration Management

Mon Feb 3 07:48:20 MST 2020

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 think the establishment of a continuous monitoring system per 3(a) 
demands that _any_ system changes are monitored _and subsequently 
reconciled with a change management system_. That is, the continuous 
monitoring system refererence to the change management system exists 
only to suppress those alerts which can be definitively said to have 
been pre-authorised. It does not give any permission to restrict such 
monitoring to those changes described in a change management system; in 
fact it gives no permission to rescope the notion of "change" at all. I 
think that the normal parsing of a "change" would be "such actions which 
transfer a system from one state to a different state".

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

Hence, in the adversarial reading of the text, one of two failures would 
obtain. Either the CA would be allowing changes to systems which were 
not documented, or, the monitoring system so established would be 
defective, because it was not reporting what it is required to report.

As to your perception that such an interpretation would be flawed and 
contrary to the goal - you are 100% correct. We certainly would not wish 
to see such perverse interpretations take root!

Now that said, I'm certainly open to even more stringent language 
(hoping that it doesn't allow yet other "creative interpretations"!)

Best regards,

Neil

On 01/02/2020 00:15, Ryan Sleevi wrote:
> Thanks for circulating this, Neil!
>
> I really found the write-up helpful, especially in understanding the 
> goals and being able to evaluate how well this ballot supports those 
> goals, or where there might be risks. To restate in my own words, to 
> make sure I've got the high level:
> - All changes should be authorized ( 1(h) )
> - Systems should continuously monitor for any unauthorized changes ( 
> 3(a) )
>
> As it's currently worded, I have a slight worry that a CA might 
> interpret "changes" to mean "Changes reflected in our change 
> management system", not "Changes in the actual system configuration". 
> That is, consider a CA that adopts the incorrect interpretation, and 
> implements a Change Management System that uses a bug tracker to track 
> the process flow of making system changes. Under this incorrect 
> interpretation, 1(h) can be fulfilled by the existence of a policy 
> that says "Every Change Request should either be Approved or Rejected 
> before it is Closed". 3(a) might be fulfilled by a system that 
> continuously monitors the bug tracker, and makes sure every bug that 
> is Closed was either Approved or Rejected before it was Closed.
>
> Such a CA, arguing from an incorrect interpretation and understanding 
> of the underlying goal, might argue they're compliant, because they're 
> ensuring that everyone who approves a change creates the correct 
> artifact (in the bug tracker). This helps address issues like "I 
> talked to Ryan over lunch and he said it was cool", by making sure 
> that I actually approved it in the bug tracker.
>
> However, if I went into the system itself, and made the change (i.e. I 
> didn't create a bug first), I would have violated the policies - but 
> 3(a) would not detect it, as the CA (incorrectly) implemented! That 
> is, if I went and sudo'd onto the production box, the system in 3(a) 
> would never look.
>
> Am I correct in understanding that such an interpretation of these 
> requirements would be flawed, and not the goal?
> If I am correct, then I think we might be able to address that by 
> tweaking 3(a), so that instead of monitoring "configuration changes" 
> (i.e. the bug tracker), it's clear that the monitoring should be of 
> "the System Configuration for any changes (since the last scan? 
> Probably a better way to phrase this), and ensure that any and all 
> changes to the System Configuration were authorized by a Change 
> Management Process"
>
> I'm not sure that's much better, but what I'm trying to separate here 
> is that you don't monitor the configuration changes (i.e. the bugs), 
> but you monitor the actual changes to configuration. Which, is of 
> course clunky, and might also be addressable by making 1(h) say "all 
> proposed changes", to try and separate 1(h) [the process management] 
> from 3(a) [the configuration monitoring]
>
>
> Related, it appears 1(h) uses "Change Management Process" (capitalized 
> Proper Phrase, implying a defined term), while 3(a) uses "change 
> management process" (lower case, implying something different or 
> unrelated)
>
> Hopefully this is helpful feedback in trying to adversarially read 
> this and imagine the most contorted interpretation possible, so we can 
> head that off.
>
> On Wed, Jan 29, 2020 at 3:23 AM Neil Dunbar via Servercert-wg 
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>
>     A few folks have reported problems accessing this document; so I've
>     attached it here in PDF format - hopefully that will make people's
>     life
>     easier.
>
>     Neil
>
>     On 28/01/2020 16:04, Neil Dunbar via Servercert-wg wrote:
>     > More detailed discussions and considerations can be found in this
>     > document, maintained by the NetSec Subgroup:
>     >
>     https://docs.google.com/document/d/1yyadZ1Ts3bbR0ujAB1ZOcIrzP9q4Un7dPzl3HD9QuCo
>
>     >
>
>     _______________________________________________
>     Servercert-wg mailing list
>     Servercert-wg at cabforum.org <mailto: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/20200203/2a75313b/attachment-0001.html>