[cabf_netsec] FW: Ballots SC20 and SC21
Ben Wilson
ben.wilson at digicert.com
Sun May 19 16:19:09 MST 2019
FYI
Also, Tobias, could you update the GitHub version with the language from the
Google Doc? - "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."
Thanks,
Ben
From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ben
Wilson via Servercert-wg
Sent: Sunday, May 19, 2019 5:17 PM
To: servercert-wg at cabforum.org
Subject: [Servercert-wg] Ballots SC20 and SC21
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/f5e535454527b0cd88670
4ec32775cb0674229ed
The procedure for approval of this ballot is as follows:
Discussion (7+ days)
Start Time: <INSERT>
End Time: <INSERT>
Vote for approval (7 days)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190519/3fc4f3fa/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/20190519/3fc4f3fa/attachment-0001.p7s>
More information about the Netsec
mailing list