[Servercert-wg] Ballot SC29v3: System Configuration Management

[Ryan Sleevi]

On Mon, Apr 27, 2020 at 4:58 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> On 2020-04-22 3:14 π.μ., Ryan Sleevi via Servercert-wg wrote:
>
> The point of the review is to make sure that systems are in defined
> states; ideally, states that can be readily recreated if necessary (modulo
> the private key, of course). The point of the NCSSRs is to make sure that
> state changes do not go undetected (i.e. DigiNotar), but that's necessary,
> not sufficient. Understanding when and how a CA system undergoes a state
> change is equally important - least of all, because it's necessary to know
> what state you "should" be in to compare when you look at what state you
> "are" in.
>
>
> And that's the argument, right there "that by having good logging,
> monitoring and alerting about unsupervised security updates, and by having
> personnel following up on these in due time, that a CA may have an equally
> good grip, overview, understanding and control of their systems". In
> addition to that, we don't consider this to be "equally good grip" but
> *better*.
>
> Delaying installation of vendor provided security OS patches brings more
> harm than good and the risk of getting your systems compromised from
> someone exploiting a known vulnerability, is not compared to the risk of
> "decreasing service availability" which will happen if "something breaks".
> We provided more details about the trade-offs in previous posts on this
> thread.
>

I'm sorry, but we're simply not going to find agreement here. I am not
disputing timely patch installation, as you try to frame it. I am, however,
trying to make sure that there is a documented procedure for knowing what
patches you're installing on your system. Installation from a 3P
source/vendor, without any approval process, is not and cannot be that.

The argument you're advancing here is basically "It's more important to do
something fast than do the right thing", and no, it's not, especially not
when that "fast" thing can lead to harm. You are not on an equally good
grip. You're in a bad place. Setting aside service availability, which is
an argument others are making, I'm trying to make very clear that if you
aren't maintaining an inventory of what's on your system, *before* it's on
your system, it's no longer your system and no longer trustworthy. It
doesn't matter who the source is.

Look, there are ways to implement controls to achieve the service level
objectives you have. You can ensure that there's a system that monitors for
available updates, and triggers a pager when an update is available. You
can review that update, approve that update, and install that update
quickly.

However, the very premise that CA systems should be connected to the
Internet, probing for new software to install from 3rd parties, is flawed
and cannot be reasonably secure.


> I think you're right to highlight that, unfortunately, the state of the
> world for some CAs may be security practices very misaligned with the goals
> and expectations of a globally, publicly trusted CA (or at least, those
> goals and expectations as seen by a root program), and so I appreciate that
> SC29 brings this to stark, unfortunate attention. I also agree that we
> shouldn't let the perfect be the enemy of the good - we need to make
> incremental improvements.
>
> My worry from the discussion, however, is that responsible CAs with strong
> change management systems will see such systems as unnecessary, because as
> the Forum, we potentially voted on a weaker set of expectations. New CAs
> will also lack the context that indicates such an approach of blindly
> trusting the vendor is dangerous.
>
>
> There is a disconnect here. Strong change management is useful for some
> areas but not a panacea. You have argued in the past that strong change
> management is an obstacle for cases that need more automation (e.g.
> automated certificate installation/renewals/changes).
>

Throughout this discussion, I've repeatedly discussed how these are not in
conflict. Automation is about making sure you can effectively and
confidently deploy, at scale, the configuration you want. Change management
is about making sure you know the configuration you want. You're arguing
here that you don't need to know what you're deploying, because surely it's
fine to delegate this to a third-party.


> We support strong change management for configuration changes and other
> areas but we consider it *counterproductive *to add human review to
> decide if an OS vendor security patch (that has been tested, reviewed and
> vetted already by a group of OS vendor experts) is "good enough" for it
> to be installed. And how long should this "independent" human review last
> for it to be *effective*? Just a few seconds? A week? A month? For how
> long would the systems need to remain unpatched/vulnerable in case this
> procedure is blocked/postponed by more imminent matters? Do people
> honestly believe that a CA-level human review of the contents of a security
> update can determine if that update introduces a NEW security issue? We see
> hundreds of security updates throughout each year.
>

You're anchoring on something I haven't said, while ignoring what I have.
If you don't know what's on your system, it's not your system. I'm not
arguing for a careful *testing and qualification* process, I'm arguing for
a human *review* process that says "Yes, this patch came from this vendor,
and we're going to set aside a copy, and this copy, this one we approved,
is what we install"

This is about knowing what is on your systems at all times. This is not
about inspecting after the fact and going "Huh, our software claims it
downloaded a patch last night, that's interesting" - that sort of
post-facto review is simply *unacceptable*.


> After almost a month of discussion, I am still trying to find our
> misunderstanding of the situation. We are merely discussing about security
> updates of packages that are already installed, right? We are not
> discussing about installing *new *packages for which there might be an OS
> security update (like the Bluetooth example that was discussed previously
> on this thread). We are also *not* discussing about updates of third
> party software (in general software that is not provided directly by the OS
> vendor).
>

You've shared no thought to what language allows you to make this
distinction - from the OS vendor to third-party software. It doesn't exist,
it's artificial, and that's why it's so dangerous to even entertain.


> This statement proves that there must be a huge misunderstanding somewhere
> that I still can't exactly pin-point. None of what you say above matches
> anything related to this thread. The NetSec subcommittee stated on the last
> call I participated (with an auditor present), that even when they wrote
> the original ballot language, they thought that the practice HARICA tried
> to clarify was allowed. Their intent was not to prohibit this practice.
>

My intent is to prohibit this practice.

It's not safe - it's outright dangerous and harmful for a CA to do it, and
it is highly suspect that it can meet the language as written.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200427/2661093a/attachment.html>