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

[Ben Wilson]

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.


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


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

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

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