[Servercert-wg] Ballot SC29: System Configuration Management

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Mar 30 04:12:27 MST 2020



On 2020-03-30 2:06 μ.μ., Wendy Brown - QT3LB-C wrote:
> You may want to change the OS Vendor in the following to 
> software vendor - to cover the case where the CA is not from the same 
> vendor as the underlying OS
>
>     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
>
> Just a thought

The team's primary concern was focused on the OS patches but I see your 
point. We don't have strong feelings about it and would be fine with 
changing "OS vendor" to "software vendor".

Dimitris.

> Wendy
>
> Wendy Brown
> Supporting GSA FPKI
> Protiviti Government Services
>
> 703-299-4705 (office)    703-965-2990 (cell)
>
> wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov>
> wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com>
>
>
>
> On Mon, Mar 30, 2020 at 6:08 AM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <servercert-wg at cabforum.org 
> <mailto:servercert-wg at cabforum.org>> wrote:
>
>
>     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  <mailto:Servercert-wg at cabforum.org>
>>     http://cabforum.org/mailman/listinfo/servercert-wg
>
>     _______________________________________________
>     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/20200330/88cdc8a9/attachment.html>


More information about the Servercert-wg mailing list