[cabf_netsec] Minutes of Meeting 2017-Nov-16

[Ben Wilson]

Here are the draft notes of our meeting this past Thursday on 16-Nov-2017.
Please suggest any changes you feel are necessary.

 

In attendance:  Ben Wilson, Fotis Loukos, Xiu Lei, Dimitris Zacharopoulos,
Neil Dunbar, Tobi Josefowitz, Bruce Morton, Steven Hillier

 

The group discussed an email from Josh Aas regarding HSMs to which Fotis had
replied.  The email exchange indicated a difference in opinion on how
firmware updates could be applied and how that affected compliance and/or
FIPS certifications.  When an HSM vulnerability becomes known, the HSM
vendor creates an update to firmware, but NIST/CC validation takes time.  

 

BR Section 6.2.7 (Private Key Storage on Cryptographic Module) currently
states, "The CA SHALL protect its Private Key in a system or device that has
been validated as meeting at least FIPS 140 level 3 or an appropriate Common
Criteria Protection Profile or Security Target, EAL 4 (or higher), which
includes requirements to protect the Private Key and other assets against
known threats."

 

There was some agreement between Fotis and Josh that HSMs should be updated
with the latest firmware.  Ben asked for some updated ballot language.
Fotis said that we should use the FIPS 140-2 language and specify FIPS 140
Level 3 in at least these two areas:  Level 3 for physical security of the
device and Level 3 for EMI/EMC.  Josh proposes to exclude firmware, "FIPS
Level 3 physical device excluding firmware."  Fotis' criticism of this
approach is that we haven't defined "physical device excluding firmware."
Josh will be working on another draft of the ballot.

 

Regarding the threat modeling subcommittee, Dimitris said that it meets on
Wednesdays and continues to make progress.  They have completed Google
spreadsheets for threats to Root CA systems.  The group has discussed
transferring capabilities in an air-gapped system and the bad USB model.
Next they hope to discuss and address network transfer capabilities, but
still in an air-gapped system (the same local area network).  Fotis and Ryan
are going to develop a model.

 

We noted that another subgroup exists that is supposed to be working on
passwords.  That group needs to pick the ball up again / pick up the pace of
discussion.

 

There are places in the Network Security Requirements where the term "CA"
needs to be changed to "TSP".  

 

The group next discussed definitions - workstation, account, etc.  

 

"Workstation" is only used in 2.h and 2.i.  Does "workstation" need to be
defined?  And if so, what would that definition be?  Tobi suggested that the
concept of the operator of the workstation is more important than the
definition of workstation.  The "who" operates this computer is more
important.  Dimitris said that a workstation is a client computer that is
used by the person to perform that person's trusted role.  Different roles
will have different access.  The same rule is being applied regardless of
whether they are vetting agents, CA administrators, sysadmins, etc.  Ben
said that editing these sections may require more of an overhaul-it won't be
easy to just replace a few words.  Maybe 2.h. and 2.i  could be merged
because they're similar?  Section 2.h. could be reworded to say that "policy
must require .."  That would require the CA to maintain documentation.
Dimitris noted that 2.i  more likely requires a practice-configure the thing
to have an inactivity timeout.  

 

Do auditors have trouble defining the term "workstation"?  Ben envisioned
situations where the auditor, in dealing with the CA, might have discussed
this and may have needed guidance on what a workstation is, as compared to
other computing components.   

 

The word "account" is used a few times in the Network Security Requirements.
Disabling of accounts is required upon employee termination.  Changing
passwords is required on privileged accounts.  There is a requirement to
review all "system accounts".  Do we need to define "account"?  Dimitris
said we should use the phrase "privileged account" instead.  "Privileged
accounts" are used by trusted roles to exercise the privileges of a trusted
role.  Should we look at our use "Privileged Account" vs lowercase "account"
in other places?  Or we could just define "Account" to mean privileged
accounts.  We cannot define a word in terms of itself.  So account could be
"A location on a network server used to store a computer username, password,
and other information.  A user account allows a user to connect .."  A user
account contains information that allows a user to connect to a network
resource.  Tobi asked why we feel we need to define the term "account"
further?  Ben said that there may be situations where the auditor and the CA
are looking for guidance when interpreting the Network Security
Requirements.  They could look at the definition and decide on one side or
the other of the issue presented (with the help of the definition).  Then,
in the future, if they find this doesn't help them, they can come back and
ask us to clarify the requirement more.  Tobi said that we may not know
ahead of time the problem that we're trying to solve.  We can direct them,
but if we don't know which way we anticipate the way that the word "account"
would be misunderstood by an auditor, we cannot be sure that we'll be
directing the discussion in the right direction.  

 

Dimitris said that this issue reminds him of the reasons why we went back to
the threat assessment approach for the offline root CA issue.  We didn't
know what we were trying to protect against.  So, we went back to identify
the threats so that we can tell what these controls are used for.  When you
read this intuitively, "accounts that are accessible outside a secure zone"
it's usually remote access, web portal accounts, VPNs, you wouldn't go so
far as to say you mean the HSM accounts.  So, there were some corner cases
where some auditors thought that this control should expand to every
possible account in a CA system.  Not every account supports these types of
protections, protections against reuse, etc.  

 

Should we address the definition of "Zone"?  Zone is defined as "a subset of
certificate systems ."  The definition uses the phrase "certificate systems"
twice.  Could the second phrase be deleted?  Or do we delete the definition
altogether?  There are already good definitions for "Secure Zone" and "High
Security Zone".   We use the phrase "Secure Zones" throughout the NetSec
Requirements.  The definition doesn't imply that there is only one "Secure
Zone" - CA systems have multiple Secure Zones.  We could add the phrase "or
parts thereof" after "Secure Zone", to clarify it.  Dimitris suggested that
we delete the definition Zone.  Tobi noted that "Zone" isn't used and that
it is always used in conjunction with Secure Zone or High Security Zone.
The group was of consensus that "Zone" could be deleted.

 

Next meeting we'll start by discussing 3.e. of the Network Security
Requirements ("Certification Authorities and Delegated Third Parties SHALL:
. e. Ensure that application and system logs have integrity and are
operating properly (the CA or Delegated Third Party MAY use an in-house or
third-party audit log reduction and analysis tool);").

 

Next meeting in 3 weeks (7-Dec-2017).

 

Meeting adjourned.  

 

 

Ben Wilson, JD, CISA, CISSP

DigiCert VP Compliance

+1 801 701 9678

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20171119/f1234443/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/20171119/f1234443/attachment-0001.p7s>