[Servercert-wg] Ballot SC29: System Configuration Management

[Ryan Sleevi]

On Mon, Mar 30, 2020 at 6:07 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.
>
Similar to Neil's remarks, doesn't this conclusion seem to be predicated on
"It is OK to design CA systems to be so complex that they cannot be
reviewed and understood" (your "Observation 3"). Is that necessarily the
goal worth supporting, and is that good for security when a CA has their
system so designed?

I can appreciate the desire to rapidly install fixes. I think we're in
agreement, there, that it's imperative that CAs be applying security
patches, although I disagree with the framing of "0-day" as being more
special than an "n-day" (from a defender/blue-team perspective). However,
I'm concerned that there exists systems for CAs that they feel it's
impossible to put through a change review process.

Perhaps it's a misunderstanding of degree? For example, on a Microsoft
system, patches are aligned with a "Patch Tuesday". On a Linux/BSD system,
CAs absolutely should be customizing their image to remove any and all
packages not necessary for the CA management, such that the affected set of
packages quickly contracts to a 'base image' of stable software, and begins
to look remarkably similar to the Microsoft case. I think this is similar
to what Neil was getting to in his remarks re: bluetooth. The order of
preferences here would be
1) Not having a Bluetooth stack at all
2) Ensuring the Bluetooth stack was disabled by configuration
3) Having the Bluetooth stack in its default configuration

I hesitate to question whether 3 is allowed, but I think, for every value
non-essential to a CA's operations, substituting "Bluetooth" with that
feature would have a clear preference of 1 over 2.

If that's not the reality, it strikes that there's more systemic issues at
play here.

There's understandably a tension here. We want policies to be achievable
and implementable, and policies that are unreasonably or impossibly so
don't do CAs favor. At the same time, policies should reflect where we want
the ecosystem /to go to/, and should not be gated on where /things are/. If
things seem unreasonably complex with a proposed policy, it's worth
re-evaluating whether that's a property of the policy, or a property of the
system and how it's been designed. Simplifying the system seems like it
makes the policy achievable, and supporting complexity in the system
doesn't seem like it does anyone any favors.

The assumption on / reliance upon OS software updates similar produces a
new set of issues here. OS-based patch management is often best-effort;
it's designed to be non-disruptive, and /not/ meant to guarantee patches
are timely applied, but rather, that they're eventually applied (e.g. if
the user consents, based on exponential backoffs, etc). They are not
designed to be robust against DoS systems, more often than not (e.g. a MITM
blocking the capability to update). Having the human in the loop guarantees
that patches are being reviewed and applied, and not simply the CA trying
to absolve itself of the responsibility for how its systems work or
how/when patches are applied.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200330/398ce184/attachment.html>