[Servercert-wg] Ballot SC20v2: Configuration Management

[Ryan Sleevi]

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> 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
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200131/04f2750f/attachment.html>