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

[Ben Wilson]

We're open to making changes for whatever makes the best sense in the long
run.

On Wed, Feb 3, 2021 at 5:59 PM Ryan Sleevi <sleevi at google.com> wrote:

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