[Servercert-wg] Ballots SC20 and SC21

[Ryan Sleevi]

Thanks for sharing these, Ben.

These seem like a net-reduction, overall, in the security of the CA
systems. I appreciate the desire to apply more rigor, but I worry that it
actually does the opposite, by giving significant more leeway to the
interpretation of CAs and auditors as to what constitutes security
relevant. I appreciate that the goal is to ensure documented policies are
followed, but that seems to already be captured by the existing language.

Could you perhaps explain what you /don't/ see as security relevant in the
context of "Issuing Systems, Certificate Management Systems, Security
Support Systems, and Front-End / Internal-Support Systems"? I can already
see significant gaps that have been present in a number of CA issues with
the proposed list, so perhaps having a clearer understanding of why the
attempt to enumerate and leave to CAs' discretion would help understand if
those gaps are intentional.

Similarly, while I can understand and appreciate the 7 days to deviation
detection is meant to apply greater rigor, I believe as a matter of
practice, it will be more harmful than good. In particular, I worry that it
encourages both CAs and auditors to view failures to detect as minor
issues, as they have in the past with respect to configuration issues,
rather than the major systemic flaws they represent to the ecosystem.
Similarly, for non-English speakers, I worry that speaking of the objective
without discussing the expected means of achieving that objective does more
harm than good; it does not immediately follow that one must be reviewing
on a weekly basis in order to achieve the control objective, for example.


On Sun, May 19, 2019 at 7:16 PM Ben Wilson via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> The Network Security Committee of the Server Certificate Working Group has
> two ballots ready to present to the SCWG for review and vote. We have a
> proposer and two endorsers, but we haven’t set a discussion period yet, and
> we want to find out when it would be best to present these and begin the
> discussion and voting periods.  Here they are:
>
>
>
> https://wiki.cabforum.org/scwg/sc20_-_configuration_management
>
>
>
> https://wiki.cabforum.org/scwg/sc21_-_log_integrity_controls
>
>
> SC20 Ballot (NSR 2): System Configuration Management
>
> *Purpose of Ballot:*
>
> Section 1(h) of the Network and Certification Systems Security
> Requirements provides that CAs shall:
>
> Review configurations of Issuing Systems, Certificate Management Systems,
> Security Support Systems, and Front-End / Internal-Support Systems on at
> least a weekly basis to determine whether any changes violated the CA’s
> security policies;
>
> In relation to this requirement the WebTrust/PKI Assurance Task Force
> found and recommended that:
>
> Section 1h requires a weekly review of system configurations (…). In our
> experience this almost always includes a component of automated monitoring
> along with human review.
>
> Systems are too complex to perform a meaningful human review of
> configuration changes. Software monitoring tools play a large part in
> achieving this requirement, but there is a required human element to
> inspect the monitoring software as well as consider changes in physical
> security. Consider better detailing the goals of this criterion.
>
> This ballot seeks to implement the above recommendation and to provide CAs
> with greater certainty on what automated system configuration monitoring
> satisfies the goal of Section 1(h). It has been prepared based on the work
> of the CA/B Forum’s Network Security Subcommittee. Summary of Changes:
>
> The term “review” has been removed. Instead, CAs are required to
> systematically enforce and monitor system configurations. The new provision
> focuses on the outcome of the CA’s controls, namely that configurations are
> aligned with the CA’s security policies and that the CA detects whenever
> active (and security relevant) configurations deviate from their desired
> state. It is for the CA to decide based on the complexity of its
> infrastructure whether it enforces and monitors configurations by means of
> automated controls or human reviews.
>
> Instead of defining a review frequency, the seven-day term now defines the
> time window within which a deviation has to be detected. In this regard the
> new provision is more rigorous than the old one. CAs should rely on
> automated controls, which are more likely to detect unauthorized
> configuration changes at an early stage. Seven days is sufficient time for
> CAs to take action.
>
> The current Section 1(h) leaves open how the CA should respond to a
> deviation. The new provision adds additional rigor because it demands a
> formal response. Invoking the CA’s Incident Response procedure appears to
> be the most suitable course of action because in addition to providing
> remediation timelines such procedures typically end in the creation of a
> root cause analysis which will help the CA determine why its other controls
> were not effective at ensuring that the concerned configuration was in the
> desired state.
>
> In its current wording, Section 1(h) leaves open who should decide on the
> scope of the configuration reviews. The new wording places this role on the
> CA as the enforcement and monitoring actions relate to the definitions the
> CA made on the basis of its security policies and standards. This
> responsibility assignment is important to enable the use of automated
> controls, because the CA has to define the data points to be monitored
> before its controls are audited at the end of its 12-month audit period.
>
> The following motion has been proposed by David Kluge of Google Trust
> Services and endorsed by Tobias Josefowitz of OPERA and Dustin Hollenback
> of Microsoft.
>
> *— MOTION BEGINS —*
>
> This ballot modifies the “Network and Certificate System Security
> Requirements” based on Version 1.2. Section 1(h) is replaced with the
> following:
>
> (Each CA or Delegated Third Party SHALL)
>
> (…)
>
> Configure its CA equipment in accordance with its security policies and
> standards. Based on a documented assessment, the CA shall identify which
> configurations of Issuing Systems, Certificate Management Systems, Security
> Support Systems, and Front-End / Internal-Support Systems are security
> relevant. Such configurations shall be systematically implemented, policy-
> and standard violations shall be detected within at most seven (7) days and
> follow up action instigated in accordance with the CA’s incident response
> procedures. If the system is operated in an offline and air-gapped state,
> detection should be conducted at least every thirty (30 days) or when the
> system is powered-on.
>
> Where applicable, at least the following configurations are considered
> security relevant:
>
> user databases
>
> any means for administrative access (e.g. SSH, RDP)
>
> channels for configuration management (e.g. Puppet)
>
> network settings
>
> host-local firewall
>
> host-local IDP/IDS settings
>
> package repositories and other sources of system-level updates
>
> operating system logging service or its equivalent
>
> *— MOTION ENDS —*
>
> ** WARNING **: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE
> OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
> A comparison of the changes can be found at:
> https://github.com/tobij/documents/compare/SCWG/NetSecSC/Ballot-2%5E...tobij:SCWG/NetSecSC/Ballot-2
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: <INSERT>
>
> End Time: <INSERT>
>
> Vote for approval (7 days)
>
> --------------------------------------------------------------------
>
>
> SC21 Ballot (NSR 3): Log Integrity Controls
>
> *Ballot SC21: Revise the Network and Certificate Systems Security
> Requirements section 3.e. to allow for automated monitoring, edit section
> 3.f., and add section 3.g. to establish a response time for automated
> alerts
>
> Purpose of Ballot*
>
> The Network and Certificate System Security Requirements committee is
> proposing this ballot to revise the current requirements to better allow
> for automation in the monitoring of systems. The goal of this ballot is to
> remove manual efforts that can be less effective and more
> resource-intensive than automated monitoring and alerting.
>
> This ballot also adds specific requirements in terms of the timeliness for
> addressing alerting from automated monitoring and alerting to ensure the
> implementation of automation does not increase the length of time that a
> potential issue could go without being detected.
>
> It is proposed by David Kluge of Google Trust Services and endorsed by
> Trev Ponds-White of Amazon and Ben Wilson of DigiCert to revise the stated
> sections of the Network and Certificate System Security Requirements to be
> reflected as follows.
>
> **— BALLOT BEGINS —* *
>
> e. Monitor the integrity of the logging processes for application and
> system logs through continuous automated monitoring and alerting or through
> a human review to ensure that logging and log-integrity functions are
> effective. If a human review is utilized and the system is online, the
> process must be performed at least once every 31 days. Log integrity for
> offline system must be checked at every use or once every 31 days,
> whichever is longer.
>
> f. Monitor the archival and retention of logs to ensure that logs are
> retained for the appropriate amount of time, in accordance with the
> disclosed business practices and applicable legislation. Monitoring of
> archival and retention should be performed in the same manner as the
> systems log integrity is monitored.
>
> g. If continuous automated monitoring and alerting is utilized to satisfy
> any of the objectives of the Network and Certificate System Security
> Requirements, resulting alerts must be addressed within at most seven (7)
> days and follow up action instigated in accordance with the CA’s incident
> response procedures.
>
> **— BALLOT ENDS —* *
>
> ** WARNING **: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE
> OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
> A comparison of the changes can be found at:
>
>
> https://github.com/benwilson-digicert/documents/commit/f5e535454527b0cd886704ec32775cb0674229ed
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: <INSERT>
>
> End Time: <INSERT>
>
> Vote for approval (7 days)
>
>
> _______________________________________________
> 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/20190519/1ad4c72d/attachment.html>