[cabf_netsec] Draft Minutes of 24-Jan-2019

Ben Wilson ben.wilson at digicert.com
Mon Jan 28 09:04:08 MST 2019


Thanks, Tony

Yes - we did a quick mapping of those controls.  It's been uploaded to the
Google shared folder.

Thanks again,

Ben

 

From: Tony Rutkowski <tony at yaana.com> 
Sent: Monday, January 28, 2019 4:44 AM
To: Ben Wilson <ben.wilson at digicert.com>; CABF Network Security List
<netsec at cabforum.org>
Subject: Re: Draft Minutes of 24-Jan-2019

 

Hi Ben,

 

Speaking as both ETSI Rapporteur for the Critical Security Controls, and for
the Center for Internet Security (CIS), had you considered use of the
Controls (formerly known as the 20 Controls)?  They are widely used and
applied by multiple jurisdictions and companies, and indeed, in ETSI TC
CYBER we are applying them for middlebox security purposes.  You can see and
download the entire TR 103305 ensemble at
https://portal.etsi.org/webapp/WorkProgram/Frame_WorkItemList.asp?SearchPage
=TRUE
<https://portal.etsi.org/webapp/WorkProgram/Frame_WorkItemList.asp?SearchPag
e=TRUE&qSORT=HIGHVERSION&qINCLUDE_SUB_TB=True&butSimple=++Search++&qETSI_STA
NDARD_TYPE=&qETSI_NUMBER=103305>
&qSORT=HIGHVERSION&qINCLUDE_SUB_TB=True&butSimple=++Search++&qETSI_STANDARD_
TYPE=&qETSI_NUMBER=103305

  _____  

From: Netsec <netsec-bounces at cabforum.org
<mailto:netsec-bounces at cabforum.org> > on behalf of Ben Wilson via Netsec
<netsec at cabforum.org <mailto:netsec at cabforum.org> >
Sent: Sunday, January 27, 2019 4:07:29 PM
To: CABF Network Security List
Subject: [cabf_netsec] Draft Minutes of 24-Jan-2019 

 

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_Ihlx6340
c-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 800-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 could 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/20190128/7e0139cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4934 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20190128/7e0139cf/attachment-0001.p7s>


More information about the Netsec mailing list