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

[Ryan Sleevi]

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?

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.

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)

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.

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

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/20200626/f55cdca9/attachment-0001.html>