[Servercert-wg] Ballots SC20 and SC21

[Ben Wilson]

Hi Ryan,



Here is a response from the Network Security Committee working on these revisions, which reach beyond what is covered in just these two ballots.  In other words, the efforts of this group as a whole will result in anything but less rigor and we believe that they are indeed improvements on the existing language.



Subgroup Response:



Thank you for sharing your comments Ryan.



Our goal is to reach a net increase in the effectiveness of security practices while achieving clarity on what configurations need attention to reduce confusion between CAs and auditors. Most of the changes we are proposing are based on best practices that CAs currently have in place.




CA and Auditor determinations:


We want to encourage CAs to monitor system configurations instead of reviewing them manually. Under the current section 1(h) a CA might only detect a security-relevant configuration change after 6 days without violating the NSRs. In contrast, a CA that monitors system configurations continuously can react to such a change within hours or minutes.  Additionally, they will be able to perform more in-depth analyses than the routine, broad analyses they might otherwise perform.



It is not our intention to provide more discretion to CAs or auditors, but to gain clarity as to what monitoring is the minimum requirement. This is important because in order to design their system monitoring controls, CAs require a definition of which security metrics should be monitored.  Ballot SC-20 outlines those configurations that the NetSec committee considers security-relevant (as a minimum).



The NSRs are silent as to how the relevant policies shall be defined and what they should contain.  Thus, some CAs might only review configurations whose alteration would result in a policy violation.



Our proposal is that CAs should determine security relevance based on a systematic assessment. The assessment has to be documented in writing, which makes the applied methodology and the assessment results testable by the CA’s auditor.



It is likely that under the current NSRs, CAs already make determinations on how the term “configuration” should be understood in the context of their system environment. Thus, we do not see our proposal to reduce security. Rather, we aim to make a common process visible and measurable.




List of 8 configurations


The list of 8 configurations to review or monitor is not exhaustive. On the contrary, it names configurations which are considered security-relevant, irrespective of the CA’s assessment.



During the discussion period, it is our hope that people will point out items that should be added in case there are elements we have overlooked.




7-day response timeline


The 7-day timeline is not intended to prolong the permissible response time, it is intended to enhance the response time. A CA which performs configurations “on a weekly basis” will in the worst case not notice a configuration change earlier than within 7 days after it occurred. If the “weekly basis” is applied as “once per week” it might even be longer. The current requirements only define the timeline for a review, but do not provide a timeline to address any potential issues identified from the review or require that CAs have a process by which they review and act upon any deviations. The proposal requires that CAs proactively investigate and react in accordance with the CA’s incident response procedures.



There is no specification as to whether it is a “review” or “monitoring” because we did not want to prescribe which of the two measures a CA should use. However, if there are concerns that the proposed language is misleading we can modify it to make it clearer. For example:  “(...) Such configurations shall be systematically implemented, policy- and standard violations shall be detected within at most seven (7) days by means of continuous monitoring or an appropriate review and follow up action shall be instigated in accordance with the CA’s incident response procedures.”



We look forward to hearing your thoughts.

Thanks again,

Ben Wilson on behalf of the NetSec Committee





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<mailto: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<mailto: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/20190530/c41bf001/attachment-0001.html>