[Servercert-wg] Ballot SC29: System Configuration Management

[Neil Dunbar]

On 01/04/2020 11:36, Dimitris Zacharopoulos (HARICA) wrote:
>
> The team considers this "Emergency Change Order" to cause unnecessary 
> delay in some cases, for some categories of OS patches (e.g. security 
> updates). Whenever the vendor has patches that *the vendor* labels as 
> security updates, we would like to have the option for these patches 
> to be applied as soon as possible, without requiring additional human 
> review by the CA.
>
> Just to avoid any misunderstanding, only existing installed packages 
> would be updated. This would not invoke installation of new packages 
> (e.g. bluetooth packages or other unwanted software). Servers that 
> follow the NSRs 1g already ensure that only the utmost necessary 
> software is installed.
>
> We would also like to remind everyone that this ballot affects 
> "Certificate Systems, Issuing Systems, Certificate Management Systems, 
> Security Support Systems, and Front-End / Internal-Support Systems", 
> which covers almost every system under the CA's PKI management.

Well, yes. I would consider it strange to have an audited system which 
wasn't managed via a well described change management process.

So, I'm trying to summarize the disconnect here. Most of the strongest 
objection centres around being able to apply patches without any further 
intervention in order to shorten any potential vulnerability.

As for ECOs getting in the way - really? I've been at places where the 
ECOs were in place within _minutes_. Are we really saying that CAs need 
to apply unaudited patches in a sub-hour period? If a CA's belief is 
that patches must be put in place within seconds of a vendor announcing 
availability, then I don't think we can see eye-to-eye on this one.

All CAs are required to have a means of reconfiguring their systems 
according to well described change protocols; they are required to keep 
their software development life cycle via well described change 
protocols; they are required to be able to provide a system inventory 
for each object in their network (in terms of function, sensitivity). 
And yet the core OS deployment and updating should be treated as 
something entirely outside of a CA's descriptive purview? That doesn't 
seem (to me) to be a tenable position.

> Again, we are not discussing about upgrading something that is outside 
> the installed software stack. According to NSRs 1g, only necessary 
> software should be installed in the first place. But, just to 
> entertain the idea, and assuming we have allowed the Bluetooth stack 
> to remain installed, what potential "harm" would you see if a patch 
> for the Bluetooth stack were installed unattended?

Because that patch might introduce further vulnerabilities which can be 
exploited; if the patch wasn't installed then it couldn't provide that 
avenue of vulnerability. We're all in complete agreement that if 
software doesn't need to be on a host, then it shouldn't be. However, 
some packages (like kernels) provide functionality which is broader than 
strictly needed, and thus CAs need to know what's in a given patch to 
see whether its worth installing or not.

I do hope that no-one understands SC29 as meaning that every CA is 
required to perform exhaustive source code analysis and formal proof of 
every patch for every package that they ever deploy. I see it as simply 
meaning that continuous risk assessment is performed by reviewing the 
changelogs, sensitivity and deployment reach of each package, putting 
that into a curated repository and deploying from that. If the 
vulnerability highlighted by a package is ultra-serious and there's 
really no time to test properly, file an Emergency Change Order and 
deploy to production. At least there's a paper trail to illustrate what 
state a host is in, so if it does get compromised, you have an idea of 
what moving parts that box had before it got owned.

I guess I might just be a bit salty on this one. Patch review is one of 
the most boring parts of my job, and I don't see why anyone else should 
have a more interesting job than me. :-)

Regards,

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200402/0b1be5f8/attachment.html>