[cabf_netsec] Minutes of NetSec meeting on 2020-04-02

[Neil Dunbar]

All,

I've compiled the minutes for last meeting's lengthy discussion on the 
NetSec meeting. Please do read and review to ensure that there are no 
material inaccuracies in what has been recorded.

Also - there was one participant: Paschalis Korosoglou for whom I don't 
have any affiliation information and no email address - Paschalis, can 
you forward me your affiliation so that I can properly record you in the 
attendee list?

Note that the next meeting will be asked to consider both these minutes 
and the previous one for approval.

Regards,

Neil


-------------- next part --------------
Minutes for NetSec Meeting - 2020-04-02

Attendees

Neil Dunbar (TrustCor) [Chair]
Mariusz Kondratowicz (Opera)
Janet Hines (SecureTrust)
Tim Crawford (BDO)
Tobias Josefowitz (Opera)
Wendy Brown (FPKI)
Aaron Poulsen (DigiCert)
Corey Rasmussen (OATI)
Clint Wilson (Apple)
Joanna Fox (GoDaddy)
Daniela Hood (GoDaddy)
David Kluge (Google)
Trevoli Ponds-White (Amazon)
Dustin Hollenback (Microsoft)
Paschalis Korosoglou ()
Ben Wilson (IP)
Dimitris Zacharopolous (HARICA)
Bruce Morton (Entrust Datacard)
Michol Murray (DigiCert)
Robin Alden (Sectigo)

1. Review Agenda

The agenda was reviewed and approved without further comment.

2. Last Meeting Minute Notess

Owing to time pressures, the last meeting (2020-03-19) were not published until the
day of the next meeting. As such, the members have not had a chance to review. Approval
of those minutes (and approval of these minutes) will be recorded at the next meeting
on 2020-04-16.

3. Pain Points Subgroup Update

David reported his team's review of HARICA's comments on SC29 (which emanated from the 
PP subgroup); their conclusion was that it was good practice to review OS patches prior
to deployment through a change management process. However, they consider that the wording
of the change management text in the ballot is still rather open, and indeed would allow
HARICA to consider patches from a trusted vendor to be pre-approved. However, while this
is not contrary to the ballot wording, it represents poor practice.

Tobi commented that while such a practice might not fall foul of the change management
wording, it may not pass other audit requirements.

Neil replied that it was not the purpose of the ballot to express what the change
management process should be; merely that configuration changes must go through a defined
change management process.

Trev then asked, for the benefit of others who might not have been familiar with the
discussion to date, if a summary could be given.

Neil summarised the ballot discussion as follows:

 - the ballot requires CAs to follow a change management process while rolling out
   configuration changes to their systems
 - the discussion in previous meetings turned on what was an adequate definition of
   a change management process
 - HARICA, via Dimitris, has expressed reservations that change order type approaches
   could leave internet facing hosts in a vulnerable position for too long a period
   for which a CA might feel comfortable
 - The question then became: "could a CA simply define a given repository (say Red
   Hat's repositories) as automatically trusted?"
 - The consensus was that such a policy would be permitted by this ballot: whether
   this was a good policy or not was another question entirely.
 - Ryan (Sleevi) has indicated on the main list that such a policy was essentially
   delegating system configuration to a third party, who might have a very different
   risk assessment policy from the CA. But having a curated mirror of a repository
   means that the CA has still performed some risk assessment and approval on the
   patches to be installed.
 - (Trev reported) that Tim Hollebeek asked that the ballot did not permit "no-op"
   type change management policies, where a CA could simply state that "we do not
   perform risk assessment, therefore all patch deployment is automatically allowed";
   and further to forbid the notion of unqualified personnel blindly accepting
   everything a vendor produces.
 - Jos Purvis had said that he did not necessarily agree with Ryan, and that if 
   merely mirroring a patch repository was the criterion for compliance, it did
   not enhance the security posture of the CA.

Tobi said further that the location of the software update was largely irrelevant;
it is the knowledge of what is to be installed and who had approved that decision
to install.

Trev reiterated that Ryan Sleevi's other point was that rollback was not a good
remediation for a "bad" patch being installed, by virtue of the fact that the CA has
then lost control of the platform for that time, and that stopping an image getting
into a bad state in the first place was always preferable.

Dimitris disagreed that this was Ryan's main point; rather that the CA must have
a change management process so that there is a log, alerting and awareness of the
patches to be deployed. He again argued that if a vulnerability is known about
when staffing levels are low (for example at a weekend) then leaving an internet
facing host vulnerable when a patch exists could be an unacceptable risk to a given
CA. He gave the argument that there could be (for instance) multiple OCSP responders
which could mitigate the risk of the "bad patch".

Neil then asked that if the CA had a policy of "deploy upon availability of patch",
would this not mean that all such OCSP responders would be in the same bad state.

Dimitris did not think that was necessarily true.

Trev said that it was interesting that while in some cases, security patches were
generally applied as soon as possible, CAs were being asked to be in a separate
place such that they should be testing the patches so as not to wholly trust the
authors of the original OS software, and that such testing was being asked to
be done using "better knowledge" than the patch producer.

Neil then said that he thought the central criteria were:

 - can the CA speak to what the state of each system under their control is?
 - does the CA know how each system should behave?
 - does the CA know _why_ each system is being changed via a patch?

Trev agreed, but said that the testing model was generally not done because the
CA does not trust the patch, but rather to ensure that the patch does not
interfere with the custom deployment which that CA has put in place, and needs
to know that the patch will not break anything from an availability or system
integrity standpoint. Generally speaking, CAs will trust their vendor's patches.

The discussion turned to patches which address critical vulnerabilities (which
Dimitris correctly pointed out was handled via the 96-hour rule). Neil replied that
he still didn't see a conflict between a change management process and rapid
deployment of patches when needed.

Dimitris answered that, in his opinion, every CA already has monitoring, alerting
and other tools which allow the state of each system to be known, and the time of
modification similarly to be known. In a similar vein, patch reversion is possible
in order to restore the status quo prior to the patch being deployed. He was of
the opinion that the text in the preface did not allow pre-approved repositories
being deployed.

Neil said that he did not believe that the text prevents such a policy. Dimitris
disputed this, saying that had the preface text around change approval not been present
he could well see HARICA supporting the ballot as it stood.

Dimitris said that, from what he understood, the ballot intended every patch to be
human approved prior to being deployed.

Trev said that if it was being read in such a fashion, it was certainly not what was
intended.

Tobi commented that the reason that such a reading was not considered was that no-one
thought about a practice of automatically deploying patches from the internet as a
normal practice.

Neil read out the ballot text and preamble, and said that the practice of trusting
a vendor's repository was not prohibited - it only requires that patches be approved
as being suitable for deployment; not necessarily on a case by case basis. He also
said that it did not mean that such a policy was a good or a bad policy; that was for
an auditor to decide.

Dimitris was pleased that such an interpretation was accepted as being compliant with
the ballot.

Neil offered to change the text in the preamble to explicitly state that a patch by
patch change approval was not required, and that having a policy whereby a CA states
that they will accept certain patches from certain pre-approved channels - would be in
keeping with the ballot.

Dimitris opined that it seemed self evident that all files on systems must be monitored
for changes in any case, since it would be impossible to perform weekly analysis were
this not the case. He also added that perhaps it would be better if the terms around
risk assessment were not given as much weight, since it can act as a red flag to some
commenters.

Trev agreed with the point around risk assessment, adding that the issue is not about
trusting or not trusting a vendor's patch process, but rather that the testing
is about eliminating potential failures when the patch is installed in combination
with the CA's other software; and that it is more likely that the CA's own software
is the thing likely to break rather than the OS vendor's patched software.

Neil gave the example of systems with mandatory access control enabled, where the
owner had tightened up the access controls to a minimally working state, and a patch
emerging which requires a more permissive set of constraints to work. Trev said that
in that case, the patch was not broken, but the system was. Neil agreed, but pointed
out that in one model of a change management process, a testing regime would identify
that breakage, and either delay the patching based on the vulnerability addressed (
after reconfiguring the mandatory access controls) or to retain the existing mandatory
accesss controls and not perform the patch at all.

Dimitris then said that this is the trade off that a CA would need to address: whether
to leave the vulnerability in place or to close it with the patch, rather than
leave a system open to potential compromise.

Tobi argued that it is possible, in that instance, that applying the patch actually
decreases your system security.

Dimitris reported that in his experience, no patch had ever decreased system security;
Neil countered by saying that in his experience, such things have happened. Dimitris
argued that given the number and frequency of security patches provided, the chances
of such a case are very low.

Tobi said that presenting the argument as "leave a system open to attack" or "patch
immediately" did not cover all the possible cases; it may be that a system administrator
could decide that some vulnerabilities should be closed immediately, but that some
required a little more testing before deployment, or that some required other system
changes before the patch can be deployed.

Dimitris said that in the case where monitoring and reaction to patch alerts was not
available on a 24x7 basis there may be cases where delaying a patch would not be an
acceptable one.

David agreed with Tobi that immediate patching versus not patching was not the only
approach - that some CAS could test quickly and deploy within a few hours, but that
it depends on the CA's resources. He added that he saw some risks in immediate deployment
of patches without human approval. He concluded that, as others had said, testing
is more about testing the integration of the patch with the existing system setup.

Neil agreed with David, but thanked Dimitris for bringing these issues more clearly
into focus. Neil said that the next heartbeat of the ballot process would clarify
the scope of the text.

Trev made a suggestion on the ballot discussion document as to a better wording to
perform such clarification; to remove the term "risk mangagement" in favour of "approval
and testing". Neil suggested that "approval and testing" be replaced by "approval
and review", rather than explicitly demanding a test process.

Dimitris preferred that text. Neil then adjusted the ballot text to match and said
that he would put that out as Ballot SC29v3.

This concluded the discussion.

4. Threat Modelling Subgroup Update

Mariusz reported that nothing new had emerged from the previous scheduled meeting
on March 19, since that meeting was not convened. But there was a meeting on March
5.

That meeting concentrated on access controls, and those changes were placed in the
modelling checklist maintained by the Threat Modelling subgroup. The plan for the
meeting following the NetSec meeting was to continue the development of that checklist.
The six risk categories identified would be expanded in greater detail.

Upon receipt of a joining request, Mariusz asked for any join requests to be given
to him so that he could share the materials with new participants.

5. Document Structuring Subgroup Update

Following previous discussions regarding "physically secure environment", Ben has
gone through the new structured document and removed all references to "Secure Zone
and High Security Zone", replacing those with a definition for Physically Secure
Environment.

This document was reviewed in the previous DSG meeting and edited further - this is
now the Zones Draft.

There was further discussion and editing on the text surrounding authentication
strength and multi-factor authentication; since this currently depends on Zone definitions,
more adjustment was required to shift the terminology onto more neutral terms like
"CA's environment" or "network".

Trev said that there were some good changes into the document, and encouraged others
to read the document.

Neil asked if these changes were sufficient to work into a ballot. Ben said that there
were a few cleanups but the text is near ballot status. Trev thought that after a cleanup,
the text would be ready for ballot discussion at an upcoming NetSec meeting.

Ben thought Section 2.g was still the most problematic [2.g refers to authentication
strength and requirements]. Neil thought that 2.g was orthogonal to the Zones ballot,
and that two ballots might be a better approach. Ben thought that might be a good
idea. Neil asked for a discussion document to be prepared to explain the reasoning
behind the proposals. Ben said that he would work something up for discussion.

6. Ballot SC29 Update

Because of discussion under the Pain Points heading, there was no need to continue
discussion on Ballot SC29.

7. Ballot SC28 preparation

Tim reported that no progress had been made on Ballot SC28, but was unsure what points
remained to be resolved.

Neil replied that the question was still around whether the three categories of retained
information should be split into 4 [CA Key, CA Certificate, Subscriber Certificate and
Security Events] categories. Also that point 3 in the Certificate category [Phone call data]
seemed redundant and could be removed. He then said that that discussion could be handled
on list, if no further discussion had happened.

8. Ballot discussion

David did mention that some more changes to the System Account ballot had been made, but
there was no real time to discuss them on this call; but that it is ready to be discussed
in the main call. Neil said that he would ensure this was in the next agenda.

9. Any Other Business

Neil proposed that the NetSec meeting time be aligned to immediately follow the SCWG
meeting, and shift with the timezone so that it is always at 12:00 ET, rather than 17:00
UTC.

Dimitris said that this matter has come up time and again with the SCWG meetings. He
offered to help Neil adjust the Webex meeting invite.

10. Adjourn

The meeting was adjourned and will recommence on 2020-04-16 at 09:00 PST/12:00 EST/17:00 BST.