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

Mon May 20 13:34:52 MST 2019

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 <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/netsec/attachments/20190520/90773894/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4934 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20190520/90773894/attachment-0001.p7s>