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

[Ben Wilson]

Thanks, Wayne, for your suggestions.

On Thu, Dec 10, 2020 at 11:51 AM Wayne Thayer <wthayer at gmail.com> wrote:

> Thanks Ben. I've responded inline.
>
> On Tue, Dec 8, 2020 at 1:06 PM Ben Wilson <bwilson at mozilla.com> wrote:
>
>> Hi Wayne,
>>
>> Thanks for your comments.  Below are some proposals that we hope will
>> address your concerns.
>>
>>
>> On Mon, Nov 23, 2020 at 4:51 PM Wayne Thayer <wthayer at gmail.com> wrote:
>>
>>> 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.
>>>
>>
>> This is acceptable, we can amend the language to say, "Review
>> configurations of Air-Gapped CA Systems on at least an annual basis."
>>
> It now reads,  a. Review configurations of Air-Gapped CA Systems at least
on an annual basis;

>
>>
>>> 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".
>>>
>>> What if we replaced the word "who" with "which"?  It would read, "Follow
>> a documented procedure for appointing individuals to Trusted Roles, which
>> are authorized to operate Air-Gapped CA Systems."
>>
>>
> I'm mostly in agreement but would prefer "Follow a documented procedure
> for appointing individuals to Trusted Roles that are authorized to operate
> Air-Gapped CA Systems." (I believe "that" is the proper meaning here
> because not all Trusted Roles are authorized.)
>
It now reads,

b. Follow a documented procedure for appointing individuals to those Trusted
Roles that are authorized to operate Air-Gapped CA Systems;


>
>>>>
>>>>> 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.”
>>>>
>>> It now reads,
c. Grant logical access to Air-Gapped CA Systems only to persons acting in
Trusted Roles and implement controls so that all logical access to Air-Gapped
CA Systems can be traced back to an 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)?
>>>
>>>
>>
>> What if it was rewritten to say, "Document the responsibilities assigned
>> to Trusted Roles based on the security principle of multi-person control
>> and the security-related concerns of the functions to be performed." ?
>>
>>
>
> That works for me.
>
It now reads,

d. Document the responsibilities assigned to Trusted Roles based on the
security principle of multi-person control and the security-related
concerns of the functions to be performed;


>
> >> 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.
>>>>
>>> It now reads:
p. Grant physical access to Air-Gapped CA Systems only to persons acting in
Trusted Roles and implement controls so that all physical access to
Air-Gapped CA Systems can be traced back to an accountable individual;

>
>>>> 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.
>>>>
>>>>
>>>
It now reads,

t. Implement a Security Support System that monitors, detects, and alerts
personnel to any physical access to Air-Gapped CA Systems;

It is also proposed to amend the definition of Security Support System as
follows:

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).

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?
>>>
>>> Because this is really about physical security, what if we re-wrote this
>> to say something like, "Review all physical access lists at least every
>> three (3) months, including lists of holders of physical keys and
>> combinations to doors and safes as well as logical accounts tied to
>> physical access controls, to ensure that only authorized individuals have
>> physical access to Air-Gapped CA Systems." ?
>>
>>
> I think this language is clearer, but I'm still concerned that it could
> imply the need to travel to and access all locations where CA materials are
> stored to perform this "review". Is the intent for CAs to review readily
> accessible information - such as online access control system account
> configurations and documentation of offline device access configurations
> (e.g. a list of the Trusted Personnel who hold safe keys or combinations)?
> If so, I'd like to find a clearer way to distinguish that from a
> requirement that would involve physical access to the device every 3 months
> (e.g. connecting to an electronic safe or offline HSM to review the actual
> device configuration).
>

Not only does this subsection u. need to require the 3-month review of
access lists, but it also needs to require immediate removal of physical
access for anyone no longer authorized, similar to section 2.l.  Currently,
the draft language is as follows:

u. Implement a process that removes all physical access of an individual to
an Air-Gapped CA within twenty-four (24) hours of removal from the relevant
authorized Trusted Role, and review lists of holders of physical keys and
combinations to doors and safes as well as logical accounts tied to
physical access controls at least every three (3) months, and;

I would like to move this ballot into the discussion period soon and get
the entire ballot passed, despite the need to smooth out its rough edges.
Nonetheless, I really want to improve this language to the extent we can
during this round of changes. So, if anyone has suggestions on how to this
language in u. can be improved, please let us know. As you can see, some
action needs to be taken if it is discovered, during a three-month review,
that physical access had not been timely removed for an individual.

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210111/43dbb5c3/attachment-0001.html>