[cabf_netsec] Minutes of Meeting 21-Feb-2019

[David Kluge]

Great. Welcome.
Does anyone else want to join?

I created a doodle to find a good time for a first call.
https://doodle.com/poll/2ys9xvx59ntafzpd

On Tue, Feb 26, 2019 at 7:14 PM Bruce Morton via Netsec <netsec at cabforum.org>
wrote:

> I would be interested in joining the Pain Points SubGroup.
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Netsec [mailto:netsec-bounces at cabforum.org] *On Behalf Of *Ben
> Wilson via Netsec
> *Sent:* February 21, 2019 5:45 PM
> *To:* netsec at cabforum.org
> *Subject:* [EXTERNAL][cabf_netsec] Minutes of Meeting 21-Feb-2019
>
>
>
> *WARNING:* This email originated outside of Entrust Datacard.
> *DO NOT CLICK* links or attachments unless you trust the sender and know
> the content is safe.
> ------------------------------
>
> Here are my notes from today’s meeting.  Please send me any corrections.
>
>
>
> Minutes of NetSec Subcommittee Teleconference of 21-February-2019
>
>
>
> Present:  Corey Chapeski, Tim Crawford, Patrick Milot, David Kluge, Robin
> Alden, Tobias Josefowitz, Ben Wilson, Fotis Loukos, Peter Miskovich, Trev
> Ponds, Nick Naziridis, Tim Hollebeek, Aaron Poulsen
>
>
>
> Ben read the Antitrust Statement
>
>
>
> Tobias provided a recap of the discussion during our last meeting about
> feedback from WebTrust on the NCSSRs (email from Tim Crawford of
> 5-Feb-2019)—some fundamental changes need to be done and there are also
> comments that relate to discreet things that could be changed.  Ben said
> that this was consistent with what we’ve discussed previously—there are
> macro issues and micro issues.
>
>
>
> We took up the WebTrust Feedback and flagged the following as a “macro”
> issue – “The NSRs are highly prescriptive, which does not allow for
> implementation of controls based on the risk of the environment. A
> higher-level principle approach would allow for more flexible
> implementation based on the risk for each system component.”  Tim C. noted
> that there are 4-5 groupings of systems and that with a more granular
> break-out there would be 10-12.  The current broad grouping approach leads
> to too broad of application of criteria to CAs.  Fotis suggested that we
> look at systems and the data flows to prepare threat analysis that we can
> address.  Trev suggested that we look at this in terms of system boundaries
> and then data flows.
>
>
>
> Comments to Section 2k were discussed. It was felt that the section can be
> rephrased to eliminate specificity and remove the phrase “cannot be
> leveraged for a denial of service attack”.  Trev, David and Ben will work
> on a ballot to address this issue.  Rewording could be something like “The
> CA SHALL implement reasonable measures to prevent unauthorized access to CA
> accounts, for example, limiting the number of failed access attempts, etc.”
>
>
>
> David asked about the objectives of the requirements—are we prioritizing
> quick fixes or macro change? There was general agreement that we could move
> forward with both approaches on parallel tracks.
>
>
>
> Tim H. suggested that we add a section dealing with high level security
> objectives—the what and why of the Network Security Requirements.  Fotis
> suggested that we break out into subgroups and that one group work on the
> threat model. For example, one might identify unauthorized users getting
> access as a threat, and the security objective would be “unauthorized users
> cannot get access to CA systems.”
>
>
>
> Tobias was concerned that edits to the NCSSRs might cause compliance
> problems, but Dimitris said a new document with a good structure would be
> applauded. Fotis said a mapping document would help people make the
> transition.  It was decided to have a subgroup to discuss document
> organization and  structure.  PCI DSS might be a good model to follow.
>
>
>
> The group discussed section 2.g. and passwords. Trev would like to address
> this—we shouldn’t be prescriptive on 121-character passwords. Dimitris said
> that we need to segregate controls for offline vs. online CAs. Fotis said
> we should look at password entropy.  There was discussion about whether to
> reference external standards like NIST 800-63 or specify requirements. Tim
> H. suggested that we have at least one clear requirement, rather than
> merely reference NIST 800-63.  He recommended that we stick with password
> length as a clear requirement because that is currently the key requirement
> extrapolated out of NIST 800-63.
>
>
>
> The meeting concluded by outlining the following subgroups:
>
>
>
> Threat Modeling SubGroup -  Fotis and Nick (Trev, etc.)
>
> Document Structure SubGroup – Ben and Tim H. (Dimitris, etc.)
>
> Pain Points SubGroup – David and Tim C. (Corey C., etc.)
>
> Authentication and Access Control SubGroup – Trev and Ben (Fotis, etc.)
>
>
>
> Those interested in  participating in a particular subgroup should contact
> the people above.
>
>
>
> Meeting adjourned.
>
>
>
>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
>


-- 

David Kluge | Technical Program Manager | kluge at google.com |  +41 44 668 03
54
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190228/1a1042b5/attachment.html>