[cabf_netsec] Netsec Digest, Vol 18, Issue 4

Sun Jan 27 23:28:55 MST 2019

Thanks,  Ken.

I’ve also uploaded some of the other mapping documents to the  Google folder.

From: Netsec <netsec-bounces at cabforum.org> On Behalf Of Kenneth Myers - QT3LB-C via Netsec
Sent: Sunday, January 27, 2019 7:35 PM
To: netsec at cabforum.org
Subject: Re: [cabf_netsec] Netsec Digest, Vol 18, Issue 4

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<mailto:Kenneth.Myers at GSA.gov>

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

   Send Netsec mailing list submissions to
           netsec at cabforum.org<mailto: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<mailto:netsec-request at cabforum.org>

   You can reach the person managing the list at
           netsec-owner at cabforum.org<mailto: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<mailto:ben.wilson at digicert.com>>
   To: CABF Network Security List <netsec at cabforum.org<mailto:netsec at cabforum.org>>
   Subject: [cabf_netsec] Draft Minutes of 24-Jan-2019
   Message-ID:
           <BYAPR14MB25984B1B2E95FEFB67F3C7EBF1950 at BYAPR14MB2598.namprd14.prod.outlook.com<mailto: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<mailto: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/20190128/0ca19c63/attachment-0001.html>