[Servercert-wg] Ballot SC29v3: System Configuration Management

[Dimitris Zacharopoulos (HARICA)]

Sorry for the late response, we couldn't get the entire team together 
sooner to discuss.


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.

>
> As Trev highlighted in the minutes, there's an element of making sure 
> that applying the patch is not going to disable some security control. 
> I'm shocked and disappointed by how many CAs have made configuration 
> changes and had it cause issues or disable their security or system 
> checks. Patches are no different, OS vendor or not.

And you will continue to be shocked and disappointed because 
configuration changes remain under human review. This is a worldwide 
phenomenon, not limited to just CAs and Browsers or just our industry.

However, some people would be somehow more relieved if they knew that 
automatic installation of OS vendor security updates are done without an 
additional human review (which cannot possibly be performed at the level 
of an OS vendor *group of experts*), and at the same time be confident 
that the vast majority (I cannot say about 100%) have not introduced any 
new security issues that the system didn't already have. This doesn't 
prevent you from knowing *exactly **what **has changed in your system* 
and *when*.

We would still like to see real documented cases where an OS vendor 
introduced a security patch that created NEW security problems. And even 
if there were such few cases, these are probably very rare compared to 
the number of security patches that have been published by OS vendors.

>
> 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). 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.

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).

> I'm not sure the right approach to resolve this. Normally, it'd be 
> ideal to capture in the ballot, but I can understand that some CAs may 
> be self-interested to oppose security requirements stronger than what 
> they practice, and not unreasonably so. It may be that the answer is 
> via Root Program communication. Unfortunately, simply "telling" isn't 
> enough to have confidence that the issue isn't practiced, and 
> "showing" (i.e. audits) is what's desired. I think if we were to pass 
> this up with the NCSSRs, given the issue posed, one possibility is 
> that CAs will be required to provide the detailed control reports and 
> show and document exactly their change management process. Root 
> Programs could use that to provide feedback about whether or not it 
> meets the Root Programs' expectations, helping the CA improve their 
> security posture to an acceptable level. That's a much bigger change, 
> and puts a lot more work on the Root Programs, and so I'd prefer a 
> more equitable solution such as via the BRs/NCSSRs.

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. I am glad I brought this up in Bratislava, even 
if it was "by accident", because it revealed an ambiguity that resulted 
in different interpretations. The subcommittee tried to clarify this by 
stating "the intent" of the ballot that clearly and unambiguously allows 
the practice we described.

We presented a different approach supported by arguments, and, unless I 
am greatly misunderstanding things, you consider that CAs that follow 
this practice are either not "responsible CAs", or that they do not meet 
the "Root Programs' expectations" or that their security posture is not 
at "an acceptable level". It would save everyone the trouble of having 
to interpret complicated security requirements and trade-offs if there 
was a list of detailed "recipes" for how to be a "responsible CA" and 
here are the "Root Program expectations". But that would shift the 
burden from CAs to Relying Parties. So, I'm really confused about how we 
should engage in such discussions. We have made an honest and earnest 
attempt to present an approach to a security case and instead of seeing 
more counter arguments and leaving this for Members to decide (via 
voting), we see negative characterizations of CAs that might actually 
follow an equally good (or even -as we claim- better) practice.

For what it's worth, with the exception of that last paragraph from your 
last post, I think it was a good discussion, we presented our arguments 
on a security related topic. For security topics we believe that there 
is no "single and ultimate truth". If Root Programs feel too strong 
about how some of these practices must be implemented, despite being 
allowed by the SCWG and the NetSec Subcommittee when they drafted this 
ballot, of course they can require them via their individual Policies.


Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200427/51b60d58/attachment.html>