<div dir="ltr"><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Here are partial minutes from our meeting on October 17, 2019 (I don't have access to the recording to play back the rest).</p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Tobias reviewed the version 2 of Ballot SC 20 and noted that
Ryan and Wayne would like the group to expound upon three things: (1) explain
why the current section 1(h) is a problem, (2) explain why the proposal is
better than the current section 1(h), and (3) explain how the new language
would be incorporated into the audit criteria and why CAs would not be able to
arbitrarily do anything. </p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">When we started drafting the modifications to section 1(h),
we assumed that CAs were doing these reviews on a weekly basis. Ryan had said
to Tobias that he didn’t know why CA review of configuration changes was too
complex and he wondered why CAs would be changing configurations so often.
There is some confusion on whether the provision is meant to address change
control approvals, or security reviews of changes, or whatever. We need to make
the purpose of this subsection clearer. (To Ryan’s point, CAs are not making
configuration changes very frequently.) </p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Reinterpreted, this section wouldn’t be a pain point. However,
from a security perspective there may be configuration changes that were not
intentional or might even be malicious. For instance, if this were read to mean
that CAs only had to review changes after deploying a change, then other
changes would go undetected. So, subsection 1(h) needs to be changed such that
it addresses both concerns—change control and good configuration management. Trev
asked why anyone would review a change only after it had been made – wouldn’t
you review it before putting it in place? Ben agreed and said that we’re really
addressing two threats—the approved change that is not well thought out, but
more importantly the malicious change—we were trying to address DigiNotar. An
attacker might be making changes, and if you review your configurations, you
might discover them. </p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Trev said it would be better to detect a change within at
least three days. The proposal would need to be changed because we don’t want
to say that changes are checked only once after you’ve deployed them. The first
proposal addresses the how and when of reviewing a change. The new proposal is
that you check it 3 days after you make a change you know about. Ryan
apparently reads the existing section to require a CA to check a change within
7 days of rolling it out, but we agree that this is not enough. In other words,
a change should be reviewed sooner and then regularly thereafter to detect
unintentional changes. Hence, there is a misunderstanding about the intent of
this subsection—change management vs. configuration management.</p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Ben said that the original intent of the subsection was
configuration management – detection if someone changed the approved
configuration. Trev noted that change management is discussed elsewhere in the
NetSec requirements. It was noted that subsection 3.a. requires a system to monitor,
detect, and report security-related configuration changes to “Certificate
Systems.” The group discussed the scope of sections 1 and 3 (General
Protections and Logging, Monitoring and Alerting). Ben said that the location
in 1.h. is due to its relation to other sections in 1, even though it is about
Logging, Monitoring and Alerting.</p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Patrick Milot said that the section should address changes
that haven’t gone through the change-approval process. No one is going to
re-review something that has already been reviewed. Everyone agreed that the
purpose was to ensure ongoing configuration management.</p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Why is our proposal better? More language has been added to
the beginning of the document to address this. In the first version of the
ballot, we had begun enumerating security-relevant configurations. If we take
these and combine them with the various components in 1.h. (Issuing Systems,
Certificate Management Systems, Security Support Systems, and Front-End /
Internal-Support Systems), you can imagine 100s of data points to review. We do
not consider this a practical solution to require that type of weekly
review—that is our problem statement. So, how is our proposal better?  It resolves that problem with continuous
monitoring in place of review, and we have shorter response times—three days / continuous
monitoring.  The proposal is to replace
reviews with continuous monitoring, and then we just need to clarify the
purpose of this section for the benefit of others. (If we cannot come to
agreement that this subsection is about configuration management, and we need a
subsection on change management, then we’ll have to develop that subsection.)</p>

<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Trev asked to replace “databases” with “data stores”.</p></div>