[cabf_netsec] Netsec Digest, Vol 18, Issue 4

Sun Jan 27 19:34:30 MST 2019

The Federal PKI also put together a PKI overlay that aligns with NIST
800-53.

https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FPKI-Overlay-of-SP-800-53.pdf

*Kenneth Myers*
*Supporting GSA Federal PKI Management Authority*
Protiviti | Government Solutions | Senior Manager
DC | +1 571-469-9038 | Kenneth.Myers at GSA.gov

On Sun, Jan 27, 2019 at 4:10 PM <netsec-request at cabforum.org> wrote:

> Send Netsec mailing list submissions to
>         netsec at cabforum.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://cabforum.org/mailman/listinfo/netsec
> or, via email, send a message with subject or body 'help' to
>         netsec-request at cabforum.org
>
> You can reach the person managing the list at
>         netsec-owner at cabforum.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Netsec digest..."
>
>
> Today's Topics:
>
>    1. Draft Minutes of 24-Jan-2019 (Ben Wilson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 27 Jan 2019 21:07:29 +0000
> From: Ben Wilson <ben.wilson at digicert.com>
> To: CABF Network Security List <netsec at cabforum.org>
> Subject: [cabf_netsec] Draft Minutes of 24-Jan-2019
> Message-ID:
>         <
> BYAPR14MB25984B1B2E95FEFB67F3C7EBF1950 at BYAPR14MB2598.namprd14.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Here are the draft minutes from our last call.  Please let me know if any
> corrections need to be made.
>
>
>
> Present:  Bruce Morton, David Kluge, Corey Chapeski, Corey Rasmussen,
> Tobias Josefowitz, Trev Ponds, Tim Crawford, Ben Wilson, Gordon Bock, Fotis
> Loukos, Tim  Hollebeek, Aaron Poulsen, Patrick Milot,
>
>
>
> During our last call we reviewed the version of the Network Security
> Requirements saved on Google Docs -
> https://docs.google.com/document/d/1SrEzvE4PIiOlevy2SJ-gqZ68qMBkxCO_Ihlx6340c-M.
> (Since the last group review of the Google Doc, David accepted the
> changes/suggestions and added content to give the classes more definition.)
>
>
>
> David asked that we look at the asset classification definitions first,
> then assign requirements to each of the asset class definitions.  Then, as
> a result of the threat modeling exercise, we should see whether new
> requirements should be added or whether existing ones should be removed.
> We'll have to decide how much of it to take offline for discussion.
>
>
>
> "Root Key Material" would be one of the asset types or asset classes.  To
> progress this, the next step would be to agree on the definitions.  Some
> definitions are less controversial, e.g. "firewall".  Ben asked whether we
> consider the key shares (e.g. shards, keys to encrypt other keys, operator
> cards, PED Keys, etc.) needed to activate the root keys to be part of the
> "root key material"?  If so, then they should be in the definition. We
> should call out private keys and activation data, too.
>
>
>
> Ben also asked whether as a style issue we wanted to nest the definition
> of Root Key Material as a type of CA Key Material? David agreed as long as
> we distinguish roots from other types because they have to be protected in
> certain ways.
>
>
>
> Gordon asked whether we could layer onto something that has already been
> established, like NIST publications.  Could something act as the baseline
> and then we identify those things that are extra for CAs?  Have we had
> previous discussions on that approach?  Ben said that he had mapped the
> Network Security requirements to ETSI and WebTrust and shared his document
> on screen.  We also did a mapping exercise for the NISTIR 7924.  We could
> pull these out and resume those annotation efforts.  It might help auditors
> to have an annotated version. It might also help guide implementers. Gordon
> agreed.
>
>
>
> Trev said that we had previously discussed using parts of other standards,
> as applicable. For example, access control requirements could be pulled
> from another compliance regime.  We have talked about that approach
> multiple times. We decided that none of them were suitable for all
> requirements, but for specific parts we could use them. Gordon thought that
> this was a good approach.  Ben noted that if those other standards used a
> slightly different term, we could modify the language of that other
> requirement to the terminology we're using and add a note of what we did.
> E.g., "taken and modified from NIST 800-53."
>
>
>
> Fotis asked whether it would be possible to map between the two documents
> and use them directly. We have done side by side mapping in the past.
> Gordon said that some terms will likely be the same side by side. Ben said
> that annotations provide a map back to the source and make it so people
> don't have to reinvent the wheel,  but whatever we do, it requires signoff,
> and in our case that would mean signoff by the Server Cert Working Group.
> With an adopted annotated version, we could have a prefatory statement that
> annotations are tools or references but are not binding.
>
>
>
> Gordon said he would look at the ETSI requirements closer.  He asked about
> the corpus of documents that we should be looking at.  What are some other
> requirements that we could look at for inspiration? Trev suggested ISO PKI
> / ISO 21188.  Ben noted that ISO, WebTrust and ETSI all came out of the
> same origins. It was noted that X9.79 is where these frameworks started.
> PCI was mentioned. What Trev likes about it is the concept of inbound and
> outbound traffic from your resources, rather than let's say, an internal
> network.  It talks about perimeter rules and how you secure your network.
> The PCI DSS was another document that contributed to the Network Security
> Requirements.
>
>
>
> Next, we reviewed the Trello board. We clarified that flow diagram meant
> that we were going use it with threat modeling to identify threats and
> vulnerabilities. Trev asked that we create a Google doc in the shared
> folder to discuss threat modeling.  She said we could take one section of
> the Network Security Requirements and generate a list of threats just for
> that one section. We should pick an easier section, like section 2, or
> maybe section 4, to give us some momentum and a pattern.  For instance, we
> could focus on bad actors.  Fotis said that with the previous working
> group, we followed that same methodology.  We did a threat assessment, but
> we did not create a final threat model.  Trev requested that we share it in
> the Google folder.
>
>
>
> David asked whether we would work in parallel, because his mental model
> was that we'd look at the asset classes first and then assess the threats
> to those asset classes. Trev said she thinks we can do both in parallel.
> For example, if we look at risks to the offline CA equipment, you'll be
> going through workflow scenarios that could introduce threats, and in that
> process, we might identify changes that need to be made to the definitions.
> For instance, for offline CA equipment, does that include internal closed
> networks, air gapped equipment, etc.? There will be some back and forth
> between such parallel tracks.
>
>
>
> In summary, Trev suggests, that we take vulnerabilities and threats, like
> with asset location -- theft, rogue employee and intruder (from cell C2 in
> the Root CA System Threat Analysis spreadsheet).  Let's say someone
> attempts to steal your HSM.  In response, we write up how to mitigate that
> someone tries to steal the HSM.  Then we would write up the mitigations --
> required controls. Ben said that one of the issues is that some of this
> stuff has already been done (e.g. WebTrust/ETSI).  So, at what point do we
> reinsert that stuff into our analysis? We don't want to recreate the
> wheel.  Similarly, we could go through this exercise and actually identify
> 10 things and one of those things might be important but not included in
> WebTrust and ETSI, so we'd add it. The other nine that have been stated as
> standard we wouldn't have to recreate.
>
>
>
> One of the problems we're trying to solve is the wording in the Network
> Security Requirements. Tim Crawford agreed. We should identify what other
> problems still exist with interpretation of the Network Security
> Requirements. Some clients might have a good security posture, but they
> don't follow the very prescriptive NSRs. Trev wondered whether we could
> work back from the WebTrust principles. Are the WebTrust principles and
> criteria the way that we should approach this?  Interpret and test the
> principles and criteria and then go back and amend the NSRs?  Take for
> example the password section, which happens to be more detailed.  WebTrust
> has better, broader language - users are required to follow policies and
> procedures when selecting passwords.  Trev said she was referring to 2.7
> that talks about secure zones and high security zones and the number of
> characters that a password should have.  Ben said that with regard to
> passwords, in answer to Gordon's question, there is NIST 8
>  00-63 on
>   authentication that is another reference.
>
>
>
> Ben said that one of the problems with working back from the WebTrust
> principles is that they may be behind with the current state of the art and
> the way things are done. David noted that the WebTrust principles are, as
> the name suggests, a principles-based regulation versus a rules-based
> regulation like the NSRs. There may be a question as to what is better, but
> David favors principles-based regulation because it is more flexible and it
> allows the auditor to align better with the intent of the author.  It does
> give more discretion to the auditor, but that is not a bad thing.
> Somewhere in the middle is also a good approach. Ben agreed on the middle
> approach and that principles-based was better.  However, he noted that in
> the past when the CA/Browser Forum has tried to adopt principles-based
> rules, those have been shot down in favor of more specific, objective
> requirements that people can follow without allowing for discretion or the
> ability to exercise professional judgment.
>    We cou
>  ld scrap what we've done in the past and revisit the WebTrust principles
> and see how we can improve them for CAs that are publicly trusted.  Take
> for instance, Diginotar, they passed an audit, and the result was the NSRs.
>
>
>
> Trev would like to attempt a middle-ground, principles-based approach. The
> passwords provisions are still examples of the problems we've had with the
> NSRs.  Whereas what we really care about is access controls and
> credentials. She would like for us to amend section 2.7 to avoid counting
> characters in passwords, and instead look at the mechanisms for
> authentication and access control. The rules-based approach also leads
> people to try and redefine the scope and argue that the rule doesn't apply
> so that they avoid compliance. A standard should be written not so you can
> evade it, but so you cannot evade it.
>
>
>
> Ben will upload documents to the Google folder. Tim said that WebTrust is
> meeting and that he could ask for input on the NSRs-for problems that
> auditors are facing from an auditability or flexibility standpoint or
> because the NSRs are too prescriptive. Then we can target those as things
> that we'd like to tackle first.  Ben will also reach out to ETSI
> representatives regarding the prescriptiveness of the NSRs.
>
>
>
> Meeting adjourned.
>
>
>
> Next meeting February 14, 2019.
>
>
>
>
>
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://cabforum.org/pipermail/netsec/attachments/20190127/a9bb192f/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
>
>
> ------------------------------
>
> End of Netsec Digest, Vol 18, Issue 4
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190127/037082da/attachment-0001.html>