[Servercert-wg] Ballot SC40: Security Requirements for Air-Gapped CA Systems

[Ryan Sleevi]

On Tue, Feb 2, 2021 at 4:59 PM Jos Purvis (jopurvis) via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Should add: Ben’s email below formally opens the discussion period for
> this ballot as of 2021-02-02 21:00 UTC, which will conclude 2021-02-09
> 21:00 UTC if no further updates are required. 😊
>
>
>
>
>
> --
> Jos Purvis (jopurvis at cisco.com)
> .:|:.:|:. cisco systems | Cryptographic Services
> PGP: 0xFD802FEE07D19105 | Controls and Trust Verification
>
>
>
>
>
> *From: *Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> CABF Server Cert WG <servercert-wg at cabforum.org>
> *Reply-To: *Ben Wilson <bwilson at mozilla.com>, CABF Server Cert WG <
> servercert-wg at cabforum.org>
> *Date: *Tuesday, February 2, 2021 at 3:26 PM
> *To: *CABF Server Cert WG <servercert-wg at cabforum.org>
> *Subject: *[Servercert-wg] Ballot SC40: Security Requirements for
> Air-Gapped CA Systems
>
>
>
> Ballot SC40: Security Requirements for Air-Gapped CA Systems
>
>
>
> Purpose of the Ballot:
>
>
>
> This ballot increases the security of Air-Gapped/Offline CA systems
> (“Air-Gapped CA Systems”) by clarifying the controls that CAs must
> implement to protect them.
>
>
>
> Air-Gapped CA systems (usually Root CA private keys) are maintained in
> highly secure locations, and while they can share certain exterior physical
> controls with online systems, they are not connected to online systems or
> the Internet. Thus, they have different operational requirements and
> controls due to their separate risk profile. While the scope of the current
> Network and Certificate System Security Requirements (NCSSRs) includes
> Air-Gapped CA systems, the current NCSSRs focuses on online systems and
> contains a number of requirements that are not practical to implement in an
> offline environment and could actually increase the risk to such offline
> systems.
>
> As an example, access to offline/air-gapped CA systems frequently elevates
> the risk to the environment. A quarterly vulnerability scan in the offline
> environment is not practical, because there is an increased risk involved
> with attaching a scanning device to such Air-Gapped CA system. Just as
> another example among several, because such systems are not connected, the
> provisions of subsection 1.g (ports and protocols) are not applicable.
>
> This ballot develops a working definition for an “Air-Gapped CA System” to
> allow for a clear delineation between those system components that fall
> under this category of Air-Gapped/Offline requirements and those under
> other requirements. In doing so, the ballot creates two sets of
> requirements tailored to their respective operating environments and
> characteristics.
>
> Not only does this ballot introduce a new section 5, it also adds
> additional physical security requirements for air-gapped CAs by requiring
> video monitoring, intrusion detection, and other intrusion prevention
> controls to protect Air-Gapped CA Systems against unauthorized physical
> access attempts. The new section 5 presents logical security requirements
> in subsections a through m and physical security requirements in
> subsections p through w.
>
>
>
> These proposed subsections in the proposed new section 5 are based on
> sections 1 through 3 of the existing NCSSRs as follows:
>
>
>
> *Description*
>
> *Offline *
>
> *Criteria #*
>
> *General *
>
> *Criteria #*
>
> *Logical Security of Air-Gapped CA Systems*
>
> Configuration review
>
> 5a
>
> 1h
>
> Appointing individuals to trusted roles
>
> 5b
>
> 2a
>
> Grant access to Air-Gapped CAs
>
> 5c
>
> 1i
>
> Document responsibilities of Trusted roles
>
> 5d
>
> 2b
>
> Segregation of duties
>
> 5e
>
> 2d
>
> Require least privileged access for Trusted Roles
>
> 5f
>
> 2e
>
> All access tracked to individual account
>
> 5g
>
> 2f
>
> Password requirements
>
> 5h
>
> 2gi
>
> Review logical access
>
> 5i
>
> 2j
>
> Implement multi-factor access
>
> 5j
>
> 2m
>
> Monitor Air-Gapped CA systems
>
> 5k
>
> 3b
>
> Review logging integrity
>
> 5l
>
> 3e
>
> Monitor archive and retention of logs
>
> 5m
>
> 3f
>
> *Physical Security of Air-Gapped CA Systems*
>
> Grant physical access
>
> 5p
>
> 1i
>
> Multi-person physical access
>
> 5q
>
> 1j
>
> Review physical access
>
> 5r
>
> 2j
>
> Video monitoring
>
> 5s
>
> 3a
>
> Physical access monitoring
>
> 5t
>
> 3a
>
> Review accounts with physical access
>
> 5u
>
> 2j
>
> Monitor retention of physical access of records
>
> 5v
>
> 3f
>
> Review integrity of physical access logs
>
> 5w
>
> 3e
>
>
>
> This motion is made by Ben Wilson of Mozilla and endorsed by David Kluge
> of Google Trust Services and Neil Dunbar of TrustCor.
>
>
>
> --- Motion Begins ---
>
>
>
> That the CA/Browser Forum Server Certificate Working Group adopt the
> following requirements as amendments to the Network and Certificate System
> Security Requirements.
>
>
>
> 1. Replace the current language in section 1.c. with "Maintain Root CA
> Systems in a High Security Zone and as Air-Gapped CA Systems, in accordance
> with Section 5;"
>
> 2. Add a definition of "Air-Gapped CA System" as "A system that is kept
> offline or otherwise air-gapped and separated from other systems and that
> is used by a CA or Delegated Third Party in storing and managing CA private
> keys and performing signing operations."
>
> 3. Revise the definition of Security Support System to read:
>
> "A system used to provide physical and logical security support functions,
> which MAY include authentication, network boundary control, audit logging,
> audit log reduction and analysis, vulnerability scanning, and intrusion
> detection (physical intrusion detection, Host-based intrusion detection,
> Network-based intrusion detection)."
>
> 4. Add a new Section 5 to read as follows:
>

Ben,

One thing that struck me while working on the conversion of the NCSSRs to
Markdown was the numbering and structure do make it more difficult,
compared to our other documents.

Would you be receptive to the following changes:

1) Divide "Logical Security of Air-Gapped CA Systems" and "Physical
Security of Air-Gapped CA Systems" into sub-sections (specifically, 5.1 and
5.2)
2) Use "1, 2, 3" instead of "a, b, c" (Yes, this will result in an
inconsistency with the previous sections of the NCSSRs, but will align with
the BRs and EVGs)
3) Remove "n" and "o" from the (new) 5.1; we don't need those placeholders,
as they can be addressed in a subsequent ballot.

I suspect that #3 was a result of not having #1 in place, and so you needed
to reserve space, but as currently structured, introducing any additional
requirements for logical security beyond the two imagined would require
renumbering the entire thing, and that seems silly. That's why I think #1
makes sense and makes #3 easier (as you can and should restart the
numbering in 5.2).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210203/323ad25f/attachment-0001.html>