[cabf_netsec] Partial Minutes from October 17 2019

[Ben Wilson]

Here are partial minutes from our meeting on October 17, 2019 (I don't have
access to the recording to play back the rest).

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.

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

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.

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.

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.

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.

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

Trev asked to replace “databases” with “data stores”.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20200102/2c3002b0/attachment.html>