[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