[Servercert-wg] SC32: Remove “zone” from NCSSRs and add provisions to BR 5.1

[Ben Wilson]

Hi Ryan,

See responses below.

On Fri, Jun 26, 2020 at 1:40 PM Ryan Sleevi <sleevi at google.com> wrote:

> Thanks for sharing this, Ben. I appreciate the detailed motivations.
>
> This seems like a rather significant and substantial change to the
> security properties of CAs. I'm a bit nervous about the "or Delegated Third
> Party" inclusions here, this seems like it would reduce the effective
> security controls rather substantially, right?
>
> The NCSSRs have always applied to Delegated Third Parties (DTPs), and DTPs
are required to comply with them. For this ballot, we're trying to minimize
the changes by focusing on the removal of the term “zone” and thereby limit
the number of changes that we are making to the NCSSRs as much as possible.
DTPs are mentioned at the beginning of section 2, and were already
mentioned in section 2.n. “Enforce Multi-Factor Authentication for all
Trusted Role accounts on Certificate Systems (including those approving the
issuance of a Certificate, which equally applies to Delegated Third
Parties) ….”  By adding “the CA’s or Delegated Third Party’s network” we
are only replacing “Secure Zone” and “High Security Zone”.


> There's also a host of other things that I think merit raising an eyebrow.
> For example, "lockable enclosures" doesn't require that they actually be
> secured in locked enclosures, just that they could be. For example, if I
> always left my cage unlocked, it still seems like it would be fully
> compliant.
>
> This point was discussed in the committee. We noted, for instance, that as
amended, section 5.1.2 would say, “CAs SHALL ensure that CA Equipment is
protected by physical locks equipped with access control devices”.  We
believed that common sense and that this and other language would not lead
CAs to believe that they could leave cages, etc., unlocked. However, we can
reword this amendment to BR section 5.1.1. and use the term “locked
enclosures.”


> I'm quite worried about the introduction of "trusted networks" into the
> NSRs. This was, of course, a concern Google raised as far back as 2012 when
> discussing the NCSSRs, as trusted networks generally encourage unsafe
> assumptions. This concept appears in several places (1.e, 2.g, 2.n)
>
> The NCSSRs have always recognized a distinction between a CA’s network and
an outside network. We can address the issue you raise in a subsequent
ballot. Here, in this ballot, we have only added the "non-trusted network"
distinction in section 1.e. (as an alternative to "public network").  We
believe that “non-trusted network” is a good alternative to “public
network”.  In response to your concern, however, there is nothing to
suggest that "trusted" networks peculiarly suffer from insecure practices
just because they are considered "trusted". Similar to what is allowed for
a Trusted Role to perform, a trusted network is one in which different
security policies are allowed to exist. A non-trusted network would be one
that is not managed, owned and operated, by the CA. It is non-trusted
because the CA is not in a position to control or detect anomalous behavior
occurring within it. So there is a monitoring element to the distinction
between the two. In a perfect world, we would not have any trusted networks
and rely entirely on strongly attestable properties of endpoints
communicating across the non-trusted substrate, but the state of the
technology is not there yet, so enclaves of traffic restricted
communications are the current state. We would be interested in knowing why
you think that trusted networks are inadequately secure in light of the
NCSSRs; and in future iterations, we can build in additional requirements.


> It's not clear to me that this, overall, is a net improvement. That is, it
> seems to weaken the logical security controls, while allowing a substantial
> mixing of the physical security controls. I would think that, in general,
> we would be better served by ensuring such zones are both logically AND
> physically distinct, but this seems to allow mixing such access entirely;
> as you note, High Security Zone and Secure Zone are now functionally
> indistinguishable.
>
> The current NCSSRs never had a High Security logical zone. "High Security"
was defined as a physical location. We are working on improving the
distinction between physical and logical security and strengthening logical
security requirements. In fact, we have a draft ballot for offline CAs that
separates out physical and logical security.


> Am I overlooking important details about why these concerns might not be
> valid, or why this lowering of security might be desirable?
>

We agree with your sentiments, but the committee believes that our ballot
strategy will strengthen security because in the end we'll be able to have
clearer, more enforceable provisions.

Ben


> On Fri, Jun 26, 2020 at 2:56 PM Ben Wilson via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> This email begins the discussion period for Ballot SC32.
>>
>> Purpose of Ballot: To remove ambiguity and delineate requirements for
>> physical security and logical security.
>>
>> The Network and Certificate System Security Requirements (NCSSRs) were
>> drafted with the concept of physical and logical “Zones” (Secure Zones,
>> High Security Zones, and everything else outside those zones). However, the
>> approach did not clearly separate the physical security aspects from the
>> logical security aspects. “Zone” was defined as a “subset of Certificate
>> Systems created by the logical or physical partitioning of systems from
>> other Certificate Systems,” and “Secure Zone” was defined as an “area (
>> physical or logical) protected by physical and logical controls that
>> appropriately protect the confidentiality, integrity, and availability of
>> Certificate Systems.” “High Security Zone” was defined as a physical area—
>> "A physical location where a CA’s or Delegated Third Party’s Private Key
>> or cryptographic hardware is located”.
>>
>> It has been difficult for auditors and CAs to delineate when NCSSR
>> controls are appropriate from a logical perspective versus a physical
>> perspective for various aspects of the CA’s operation, and the NCSSRs could
>> benefit from greater clarity.
>>
>> This ballot proposes to remove the term “zone” from the NCSSRs, and
>> definitions of “Zone,” “Secure Zone,” and “High Security Zone” will be
>> deleted. Two approaches will address physical security:  (1) section 5.1 of
>> the Baseline Requirements will be enhanced, and (2) the NCSSRs will contain
>> cross-references to section 5.1 of the Baseline Requirements. For logical
>> security, the term “Secure Zone” will be replaced with “CA’s network” or
>> “Certificate Systems”.
>>
>> Baseline Requirements
>>
>> This ballot amends the Baseline Requirements by adding a definition for
>> “CA Equipment” to section 1.6.1 as follows: “Hardware involved in the
>> issuance of certificates or the signing of certificate status information,
>> e.g. signing servers and appliances that issue certificates, sign CRLs, or
>> generate OCSP responses.”
>>
>> The following language will be added in section 5.1 of the Baseline
>> Requirements:
>>
>> *BR § 5.1.1. Site location and construction*
>>
>> CAs SHALL ensure that CA Equipment is located in an environment that
>> provides physical security through the use of lockable enclosures (e.g.
>> locked rooms, cages, safes, or cabinets).
>>
>> *BR § 5.1.2. Physical access*
>>
>> CAs SHALL ensure that CA Equipment is protected by physical locks
>> equipped with access control devices (e.g. keys, tokens, biometric readers,
>> and/or access control lists) that control physical access to CA Equipment.
>>
>> Sections 5.1.3 through 5.1.8 of the BRs have been populated with language
>> requiring other physical environment protections, e.g. “CAs SHALL ensure
>> that CA Equipment is protected from damage due to water exposure”, etc.
>> (See redline/diff for exact text.)
>>
>> Rationale: These proposed additions simply restate the basic physical
>> environmental requirements that CAs must meet.
>>
>> Section 1.c.
>>
>> Section 1.c of the NCSSRs will be amended to require CAs to maintain Root
>> CA Systems in accordance with BR section 5.1, and in an offline state or
>> air-gapped from all other networks. (See redline/diff for exact text.)
>>
>> Rationale: CAs currently keep these offline systems in a physically
>> secure environment. Also, the proposed additional language to the Baseline
>> Requirements will ensure there is less wiggle room concerning the actual
>> physical protections for critical CA Equipment.
>>
>> Section 1.d.
>>
>> Section 1.d. will be amended to require CAs to maintain and protect Certificate
>> Systems, Issuing Systems, Certificate Management Systems, Front End /
>> Internal Support Systems, and Security Support Systems in accordance
>> with section 5.1 of the Baseline Requirements. (See redline/diff for exact
>> text.)
>>
>> Rationale: This modification replaces the term “Secure Zone.” The
>> definition of “Secure Zone” as a physical OR logical area has been a major
>> cause of confusion. An early draft of the NCSSRs defined “Secure Zone” as
>> “The area where the CA’s and Delegated Trusted Agent’s equipment used in
>> providing Certificate Services are located. The Secure Zone is often inside
>> a data center or network operations center.” In this section, “Secure Zone”
>> is replaced with a reference to the requirements of BR section 5.1 to
>> clarify the original intent of this section to address physical security,
>> that systems be located in at least a physically secure area (while section
>> 1.e., below, was meant to address the logical security of CA systems). Note
>> that another aspect of this revision is that it adds Certificate Systems
>> and Front End / Internal Support Systems to the group of systems that need
>> to be physically protected.
>>
>> Section 1.e.
>>
>> Section 1.e. will require CAs to implement and configure Security Support
>> Systems that secure and protect communications and Certificate Systems
>> from non-trusted networks. (See redline/diff for exact text.)
>>
>> Rationale: A “Security Support System” is a “system used to provide
>> security support functions, which MAY include authentication, network
>> boundary control, audit logging, audit log reduction and analysis,
>> vulnerability scanning, and intrusion detection (Host-based intrusion
>> detection, Network-based intrusion detection).” This provision requires the
>> use of a system to provide logical security to protect communications and
>> Certificate Systems from external threats. The ballot also deletes the
>> parenthetical “including those with organizational business units that do
>> not provide PKI-related services” because it is unnecessary as it is
>> already included as part of public networks and communications with public
>> networks.
>>
>> Section 2.c.
>>
>> Amendments to section 2.c. will require that only persons in Trusted
>> Roles have logical or physical access to Certificate Systems, Issuing
>> Systems, Certificate Management Systems, Front End / Internal Support
>> Systems, and Security Support Systems. (See redline/diff for exact text.)
>>
>> Rationale: Section 2.c. currently says that access to Secure Zones and
>> High Security Zones can only be granted to persons in Trusted Roles. It
>> does not currently specify the types of access that persons in Trusted
>> Roles have or to which systems.
>>
>> Section 2.g.
>>
>> This section will likely be modified further in a subsequent ballot, but
>> meanwhile it will retain the current password rules (based on whether or
>> not the user is inside the CA’s network). If authentication occurs within the
>> CA’s network, then the password must be at least 12 characters, but if
>> authentication occurs from outside the CA’s network, then Multi-Factor
>> Authentication must be used, and any password used must be at least 8
>> characters and not one of the previous 4 passwords.  The CA must also
>> implement the account lockout provisions of section 2.k. The phrase in ii.
>> “cross a zone boundary into a Secure Zone or High Security Zone” is
>> replaced with the phrase “For authentications from outside the boundary of
>> the CA’s network.” (See motion language and redline/diff for exact text.)
>>
>> Rationale: The terms “Secure Zone” and “High Security Zone” are being
>> removed from the NCSSRs. The current version of 2.g.ii. has two sentences
>> that can be combined into one, which will eliminate ambiguity caused by
>> having two separate sentences with slightly different phrasing. These two
>> sentences read, “For authentications which cross a zone boundary into a
>> Secure Zone or High Security Zone, require Multi-Factor Authentication. For
>> accounts accessible from outside a Secure Zone or High Security Zone
>> require passwords ….” A reader might find these two sentences
>> contradictory. Rephrasing the sentence as a series of requirements
>> eliminates the potential confusion -- “For authentications from outside the
>> boundary of the CA’s network: require Multi-Factor Authentication, require
>> passwords that have at least eight (8) characters and are not one of the
>> user's previous four (4) passwords, and implement account lockout for
>> failed access attempts in accordance with subsection k.” (Note – this
>> doesn’t require that passwords be used -- the opening part of g. makes it
>> conditional on using a password in the first place, “If an authentication
>> control used by a Trusted Role is a username and password, then, where
>> technically feasible, implement the following controls:” ….)
>>
>> Section 2.n.
>>
>> The last part of the requirement replaces the phrase “a Secure Zone or
>> High Security Zone” with “the CA’s or Delegated Third Party’s network” so
>> that the section reads, “Enforce Multi-Factor Authentication for all
>> Trusted Role accounts on Certificate Systems (including those approving the
>> issuance of a Certificate, which equally applies to Delegated Third
>> Parties) that are accessible from outside the CA’s or Delegated Third
>> Party’s network.”  (See redline/diff for exact text.)
>>
>> Rationale: This modification makes no substantive changes apart from the
>> replacement of terms as described above. Future efforts by the Network
>> Security Subcommittee can address whether and how section 2.n. can be
>> integrated into section 2.g.
>>
>> NCSSR DEFINITIONS
>>
>> Definition of “Critical Security Event” – The phrase “a Zone’s” is
>> removed so that the definition reads, “Detection of an event, a set of
>> circumstances, or anomalous activity that could lead to a circumvention of
>> security controls or a compromise of a Certificate System’s integrity, ….”
>> (See redline/diff for exact text.)
>>
>> Rationale: Removal of the phrase “a Zone’s” doesn’t substantially change
>> an interpretation of the defined term.
>>
>> Definition of “Trusted Role” – The phrase “a Secure Zone or High
>> Security Zone” is being replaced so that the definition will read, “An
>> employee or contractor of a CA or Delegated Third Party who has authorized
>> access to or control over a Root CA System, Certificate System, Issuing
>> System, Certificate Management System, Front End / Internal Support System,
>> or Security Support System.”
>>
>> Rationale: This modification is consistent with the elimination of
>> “Zone” from the NCSSRs.
>>
>> Deleting “High Security Zone,” “Security Zone,” and “Zone” – as
>> described above.
>>
>>
>> *The following motion has been proposed by Ben Wilson of Mozilla and
>> endorsed by Trev Ponds-White of Amazon and Neil Dunbar of TrustCor Systems.*
>>
>> * --- MOTION BEGINS ---*
>>
>> This ballot modifies the “Network and Certificate System Security
>> Requirements” based on Version 1.4 and sections 1.6.1 and 5.1.1 through
>> 5.1.8 of the Baseline Requirements for the Issuance and Management of
>> Publicly-Trusted Certificates, based on Version 1.7.0., as follows:
>>
>> MODIFY the Baseline Requirements as defined in the following redline:
>>
>>
>> https://github.com/cabforum/documents/compare/095fc4f7992dbd186503a4b0ec4e643ae4ea1624...BenWilson-Mozilla:2a255d8d159e8e4b59952ed9de272f2a72349036
>>
>>
>> MODIFY the Network and Certificate System Security Requirements as
>> defined in the following redline:
>>
>>
>> https://github.com/cabforum/documents/compare/095fc4f7992dbd186503a4b0ec4e643ae4ea1624...BenWilson-Mozilla:2a255d8d159e8e4b59952ed9de272f2a72349036
>>
>>
>> The Chair or Vice-Chair is permitted to update the Relevant Dates and
>> version numbers of the Baseline Requirements and the Network and
>> Certificate System Security Requirements to reflect these changes.
>>
>> *--- MOTION ENDS ---*
>>
>>
>>
>> This ballot proposes two Final Maintenance Guidelines.
>>
>> The procedure for approval of this ballot is as follows:
>>
>> Discussion (7+ days)
>>
>> Start Time: 2020-06-26 19:00:00 UTC
>>
>> End Time: 2020-07-03 19:00:00 UTC
>>
>> Vote for approval (7 days)
>>
>> Start Time: TBD
>>
>> End Time: TBD
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/2a9f582c/attachment-0001.html>