[cabf_netsec] FW: [Servercert-wg] Ballots SC20 and SC21

[David Kluge]

We drafted a response to address Ryan's comments. I'm planning to send it
out tomorrow.

On Mon, May 20, 2019 at 10:35 PM Ben Wilson via Netsec <netsec at cabforum.org>
wrote:

> Group,
>
> Let’s review Ryan’s comments and see if they can be appropriately
> addressed.
>
> Thanks,
>
> Ben
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Sunday, May 19, 2019 7:48 PM
> *To:* Ben Wilson <ben.wilson at digicert.com>; CA/B Forum Server Certificate
> WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Ballots SC20 and SC21
>
>
>
> 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
>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
>


-- 

David Kluge | Technical Program Manager | kluge at google.com |  +41 44 668 03
54
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190529/7c0067ed/attachment-0001.html>