[Servercert-wg] Ballot SC29: System Configuration Management

Mon Mar 30 04:06:54 MST 2020

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

Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

703-299-4705 (office)    703-965-2990 (cell)

wendy.brown at gsa.gov
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> 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 listServercert-wg at cabforum.orghttp://cabforum.org/mailman/listinfo/servercert-wg
>
>
> _______________________________________________
> 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/14365f1c/attachment-0001.html>