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

[Wayne Thayer]

Ben,

Thanks for the detailed response. I've added a few new comments below where
I still have some concerns.

Wayne

On Mon, Nov 23, 2020 at 7:48 AM Ben Wilson <bwilson at mozilla.com> wrote:

> Thanks, Wayne, for reviewing this.  Responses are inline below.
>
> On Wed, Nov 18, 2020 at 9:00 AM Wayne Thayer <wthayer at gmail.com> wrote:
>
>> Ben,
>>
>> I have some questions about the proposed language.
>>
>> On Mon, Nov 2, 2020 at 10:19 AM Ben Wilson via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>>
>>> 5. GENERAL PROTECTIONS FOR AIR-GAPPED CA SYSTEMS
>>>
>>> This Section 5 separates requirements for Air-Gapped CA Systems into two
>>> categories--logical security and physical security.
>>>
>>> Logical Security of Air-Gapped CA Systems
>>>
>>> Certification Authorities and Delegated Third Parties SHALL implement
>>> the following controls to ensure the logical security of Air-Gapped CA
>>> Systems:
>>>
>>> a. Review static configurations of Air-Gapped CA Systems at least on an
>>> annual basis to determine whether any changes violated the CA’s security
>>> policies;
>>>
>>
>> Is "static" necessary here, or would it be clearer just to "review
>> configurations"?
>>
>
> The Doc Subgroup agrees that “Static” is not necessary.  It can be removed.
>
>
>
>> The phrase "...to determine whether any changes violated the CA’s
>> security policies;" seems unnecessary and a bit confusing (changes to
>> static configurations?).
>>
>>
> The language concerning whether changes violate security policies was in
> section 1.h. of the NCSSRs until SC29 (v. 1.4) when it was replaced by:
>
> Ensure that the CA’s security policies encompass a change management
> process, following the principles of documentation, approval and review,
> and to ensure that all changes to Certificate Systems, Issuing Systems,
> Certificate Management Systems, Security Support Systems, and Front-End /
> Internal-Support Systems follow said change management process;
>
> Without the phrase, “to determine whether any changes violated the CA’s
> security policies”, the remaining language would read, “Review
> configurations of Air-Gapped CA Systems”.
>
> A better alternative might be language ensuring that changes to Air-Gapped
> CA Systems follow the CA’s change management process, as now required by
> subsection 1.h.
>

My proposal would simply read "Review configurations of Air-Gapped CA
Systems at least on an annual basis." I do see that as a valuable
requirement and would not suggest relying only on subsection 1.h.

b. Follow a documented procedure for appointing individuals to Trusted
>>> Roles on Air-Gapped CA Systems;
>>>
>>
>> A "Trusted Role on a system" doesn't make sense to me. I think the
>> meaning here is "...to any Trusted Roles that grant the individual
>> privileges on Air-Gapped CA Systems;"
>>
>> The Doc Subgroup flagged section 2.a. as applicable.  It states, “Follow
> a documented procedure for appointing individuals to Trusted Roles and
> assigning responsibilities to them”.
>
> As noted below in c. and d., the operation of CA systems involves
> multi-person control.  Depending on the HSM chosen, people handling Offline
> CA systems fulfill roles of operator, officer, administrator, etc.
>
> Alternative language might be:
>
> “Follow a documented procedure for appointing individuals to Trusted Roles
> who are authorized to operate Air-Gapped CA Systems.”
>

I agree with the intent, but I still find the alternative language to be
confusing because it's unclear if it means "...individuals who are
authorized..." or "Trusted Roles who are authorized".


>
>> c. Grant logical access to Air-Gapped CA Systems only to persons acting
>>> in Trusted Roles and require their accountability for the Air-Gapped CA
>>> System's security;
>>>
>>
>> How does a CA "require their accountability"? I'm skeptical that this
>> part of the requirement adds value, and it seems better suited for BR
>> section 5.3 (Personnel controls).
>>
>> The Doc Subgroup flagged section 1.i. as applicable. It states, “Grant
> administration access to Certificate Systems only to persons acting in
> Trusted Roles and require their accountability for the Certificate System’s
> security.”  Typically, CAs require that persons in Trusted Roles be
> formally appointed and that they are aware of their duties and
> responsibilities.
>
> Back in 2012 when the NCSSRs were being developed, this requirement
> originally proposed that persons in trusted roles “assume responsibility”
> for system security. That was thought to raise an issue of personal
> liability, so “require their accountability” was chosen. At the time that
> the NCSSRs were developed, the proponents referenced audit criteria
> requiring CA personnel to be held accountable. Accountability is a core
> information security concept. Someone needs to take responsibility for the
> physical security of HSMs.
>
> Finally, the Doc Subgroup previously considered whether to amend section
> 5.2 of the BRs (the appropropriate spot) and decided that that were enough
> challenges in just trying to update the NCSSRs, but we can consider
> revisiting that, along with other things that could be added to Section 5
> of the BRs.
>
> Alternative language might be:
>
> “Grant logical access to Air-Gapped CA Systems only to persons acting in
> Trusted Roles and design technical and/or procedural controls such that all
> access to Air-Gapped CA Systems can be traced back to the accountable
> individual.”
>
>> d. Document the responsibilities and tasks assigned to Trusted Roles and
>>> implement "separation of duties" for such Trusted Roles based on the
>>> security-related concerns of the functions to be performed;
>>>
>>
>> How is "separation of duties" relevant in the context of Air-Gapped
>> systems? In my experience, operations on Air-Gapped systems are performed
>> in ceremonies and include multi-party authentication. I'm concerned that
>> this requirement could be interpreted as adding requirements that don't fit
>> those processes.
>>
>> This provision is based on section 2.b. of the NCSSRs, which states,
> “Document the responsibilities and tasks assigned to Trusted Roles and
> implement ‘separation of duties’ for such Trusted Roles based on the
> security-related concerns of the functions to be performed.”
>
> It requires that CAs document the assignments and responsibilities of
> personnel in Trusted Roles.  This provision goes hand-in-hand with
> subsection c., discussed above.
>
> There is typically a separation of duties among key ceremony participants,
> even if they are not the same as typically referenced, e.g. primary
> engineer, secondary engineer, ceremony administrator, witness, auditor, etc.
>
I understand that different Trusted Roles typically have distinct duties
during a ceremony, but this requirement means that one individual cannot
hold multiple roles that are in conflict. In your example, which roles
would typically be considered to be in conflict (i.e. the same person can't
hold both roles)?


> >> Physical Security of Air-Gapped CA Systems
>
> >> Certification Authorities and Delegated Third Parties SHALL implement
> the following controls to ensure the physical security of Air-Gapped CA
> Systems:
>
> >> p. Grant physical access to Air-Gapped CA Systems only to persons
> acting in Trusted Roles and require their accountability for the Air-Gapped
> CA System’s security;
>
>>
>> Same comment as above on accountability.
>>
>> The Doc Subgroup flagged section 1.i. as applicable. It states, “Grant
> administration access to Certificate Systems only to persons acting in
> Trusted Roles and require their accountability for the Certificate System’s
> security". We could make changes similar to those proposed above in
> subsection c.
>
>> q. Ensure that only personnel assigned to Trusted Roles have physical
>>> access to Air-Gapped CA Systems and multi-person access controls are
>>> enforced at all times;
>>>
>>> r. Implement a process that removes physical access of an individual to
>>> all Air-Gapped CA Systems within twenty four (24) hours upon termination of
>>> the individual’s employment or contracting relationship with the CA or
>>> Delegated Third Party;
>>>
>>> s. Implement video monitoring, intrusion detection, and intrusion
>>> prevention controls to protect Air-Gapped CA Systems against unauthorized
>>> physical access attempts;
>>>
>>> t. Implement a Security Support System that monitors, detects, and
>>> reports any security-related configuration change to the physical access to
>>> Air-Gapped CA Systems;
>>>
>>
>> I'm not convinced that the NCSSR definition of Security Support System
>> fits here. Would feeding the logs from a physical security system into a
>> CA's logging and monitoring pipeline satisfy this requirement?
>>
>> We think it fits, and we want CAs to implement security support systems
> that monitor, detect and report physical intrusions. The current NCSSR
> definition of “Security Support System” is very broad.  It 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 proposed language is based subsection 3.a., which previously required
> that CAs “Implement a Security Support System under the control of CA or
> Delegated Third Party Trusted Roles that monitors, detects, and reports any
> security-related configuration change to Certificate Systems.”  Subsection
> 3.a. has subsequently been changed to read, “Implement a System under the
> control of CA or Delegated Third Party that continuously monitors, detects,
> and alerts personnel to any modification to Certificate Systems, Issuing
> Systems, Certificate Management Systems, Security Support Systems, and
> Front-End / Internal-Support Systems unless the modification has been
> authorized through a change management process. The CA or Delegated Third
> Party shall respond to the alert and initiate a plan of action within at
> most twenty-four (24) hours.”
>
> We could make a similar modification here, if needed.
>
> It does mention “audit logging” and “audit log reduction and analysis.”
> Most physical security support systems have recordkeeping capabilities.
> The definition also mentions several other concepts that are commonly
> thought of as related more to network security.
>
> We agree that the current definition of Security Support System does not
> expressly mention physical security.  Therefore, we are open to future
> revisions of that definition so that it more clearly includes physical
> security.
>
>
>> u. Review all system accounts on physical access control lists at least
>>> every three (3) months and deactivate any accounts that are no longer
>>> necessary for operations;
>>>
>>
>> What does "system accounts on physical access control lists" mean? Are we
>> talking about logical access to physical security systems?
>>
>
> This provision comes from subsection 2.j., which reads “Review all system
> accounts at least every three (3) months and deactivate any accounts that
> are no longer necessary for operations”.
>
> This issue/question is related to 5.t., above. Many physical access
> controls have logical access controls. An example of a physical access
> control list is the configuration of a badge lock that controls access to
> the rooms in which the Air-Gapped systems are located. So, “yes” to your
> second question.  Logical accounts that are tied into physical access
> controls would be included in this requirement.
>

I agree with the intent, but I think the language could be clearer. I also
wonder if we need to exclude systems that are not online. For example, is
it necessary to access the physical environment where the air-gapped CA
systems are stored every 3 months to review the access control list on an
electronic safe that implements per-user pin codes?

Thanks again for your attention to this.
>
> Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201123/12588a4a/attachment-0001.html>