[Servercert-wg] Ballot SC29: System Configuration Management

Mon Mar 30 03:07:42 MST 2020

On 2020-03-09 6:39 μ.μ., Neil Dunbar via Servercert-wg wrote:
>
> This begins the discussion period for the Ballot SC29: System 
> Configuration Management
>
> [Note: this is the resubmission of Ballot SC20, which did not proceed 
> to a voting phase]
>
> Purpose of Ballot:
>
> Two sections of the current NSRs contain requirements for 
> configuration management. Section 1(h) demands a weekly review and 
> Section 3(a) a process to monitor, detect and report on 
> security-related configuration changes.
>
> There was consensus in the discussions of the Network Security 
> Subgroup that unauthorized or unintentional configuration changes can 
> introduce high security risks but the current wording allows CAs to 
> comply with s1(h) without noticing such a change for several days. 
> Whether the weekly human reviews have to be performed every 7 days or 
> just once per week is a matter of interpretation but for the 
> discussion of our proposal this is immaterial. The change we are 
> proposing seeks to encourage CAs to rely on continuous monitoring 
> rather than human reviews because alerts created by a continuous 
> monitoring solution can notify a CA by orders of magnitude earlier 
> than a human review i.e. within minutes not within days.
>
> The question has been raised (at the Bratislava F2F meeting) as to 
> whether this ballot should also cover OS patching, since that involves 
> installing new packages on top of others. The view of the proposers is 
> an unequivocal “yes” - patched packages from OS vendors should go 
> through a CA change management process, and only those patches which 
> are approved for installation should make their way to production systems.
>
>

We had an internal discussion at HARICA and focused mainly on the OS 
security patching process. Here are some of the team's observations:

 1. Security patches, especially for 0-day exploits, should be applied
    as soon as possible. Human review in most cases adds unnecessary
    delay and increases the risk of the CA being vulnerable to attacks.
 2. Human review doesn't scale as the number of Systems increase.
    Automation is the only way to handle large number of Systems.
 3. Human review of patches for so many different OS components,
    sometimes without enough details or the source code available, is
    too difficult to be done correctly and humans do make mistakes.
 4. The risk of being non-functional is of lesser importance and
    potential impact, compared to the risk of remaining vulnerable while
    waiting for a human review.

We believe that OS patches, digitally signed by the software vendor and 
provided through secure channels, MUST be allowed as a dully approved 
Change Management Policy practice, to be applied without employing a 
human review process. Such updates and patches are beforehand thoroughly 
tested by the software vendors themselves and the CA staff should be 
discouraged to duplicate such a process with dubious results.

The recommended change in 1.h:

"Ensure that the CA’s security policies encompass a Change Management 
Process, following the principles of documentation, approval and 
testing, and to ensure that all changes to Certificate Systems, Issuing 
Systems, Certificate Management Systems, Security Support Systems, and 
Front-End / Internal-Support Systems follow said Change Management Process;"

doesn't seem to clearly allow this practice. We cannot support a ballot 
that enforces manual human review in applying OS patches which puts 
systems at risk, even for a short amount of time.

This is a recommended change that allows OS patches to be automatically 
installed, should the CA decides to document and approve this practice 
in the CA's Change Management Process. Further improvements are welcome.

"Ensure that the CA’s security policies encompass a Change Management 
Process, following the principles of documentation, approval and 
testing, and to ensure that all changes to Certificate Systems, Issuing 
Systems, Certificate Management Systems, Security Support Systems, and 
Front-End / Internal-Support Systems follow said Change Management 
Process. Τhe Change Management Process MAY allow automated retrieval and 
installation of OS patches, provided the CA has the necessary controls 
to secure the integrity and authenticity of the updates originating from 
the OS vendor."

Dimitris.

> **More detailed discussions and considerations can be found in this 
> document, maintained by the NetSec Subgroup: 
> https://docs.google.com/document/d/1yyadZ1Ts3bbR0ujAB1ZOcIrzP9q4Un7dPzl3HD9QuCo.
> <https://docs.google.com/document/d/1yyadZ1Ts3bbR0ujAB1ZOcIrzP9q4Un7dPzl3HD9QuCo> 
>
>
> [For those unable to view the discussion document, a PDF of the above 
> document is attached to this mail]
>
> The following motion has been proposed by Neil Dunbar of TrustCor 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.3. A redline against the CA/B Forum 
> repository is found here:
>
> https://github.com/cabforum/documents/compare/16a5a9b...neildunbar:108e555?diff=split
>
> (Each CA or Delegated Third Party SHALL)
> (...)
>
> Insert as new Section 1(h):
>
> Ensure that the CA’s security policies encompass a Change Management 
> Process, following the principles of documentation, approval and 
> testing, and to ensure that all changes to Certificate Systems, 
> Issuing Systems, Certificate Management Systems, Security Support 
> Systems, and Front-End / Internal-Support Systems follow said Change 
> Management Process;
>
> Remove from Section 3(a):
>
> Implement a Security Support System under the control of CA or 
> Delegated Third Party Trusted Roles that monitors, detects, and 
> reports any security-related configuration change to Certificate Systems;
>
> Insert as new Section 3(a):
>
> Implement a System under the control of CA or Delegated Third Party 
> that continuously monitors, detects, and alerts personnel to any 
> configuration change to Certificate Systems, Issuing Systems, 
> Certificate Management Systems, Security Support Systems, and 
> Front-End / Internal-Support Systems unless the change has been 
> authorized through a change management process.  The CA or Delegated 
> Third Party  shall respond to the alert and initiate a plan of action 
> within at most twenty-four (24) hours.
>
> --- MOTION ENDS ---
>
> This ballot proposes a Final Maintenance Guideline.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 2020-03-09 17:00:00 UTC
>
> End Time: 2020-03-16 17:00:00 UTC
>
> Vote for approval (7 days)
>
> Start Time: 2020-03-16 17:00:00 UTC
>
> End Time: 2020-03-23 17:00:00 UTC
>
>
> _______________________________________________
> 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/20200330/228f3968/attachment.html>