Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CA Infrastructure Scope update #44

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+19 −30
Open

CA Infrastructure Scope update #44

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5142604
CA Infrastructure Scope update
clintwilson Nov 20, 2024
675271f
Update from comments
clintwilson Dec 17, 2024
8412df0
Merge branch 'main' into ca-infrastructure-scope
clintwilson Dec 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
128 changes: 64 additions & 64 deletions docs/NSR.md
View file
Open in desktop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this objective, "CAs are able to clearly understand the minimum security requirements found in this document and successfully adapt/implement these Requirements to their own infrastructure and architecture" maybe add something like ", which requires a comprehensive inventory of their Certificate Systems to ensure that their infrastructure is adequately protected."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CS group thoughts: What if we use something similar to what is in section 3.1.2.1 "The CA SHOULD ensure retained and/or archived audit logs are kept and managed in a manner sufficiently effective to prevent unapproved alteration or access." for all other relevant security support system sections (e.g. change management, vuln management, etc.) The benefit of this is that it would bring back the requirements to protect security support systems without blowing up the trusted roles bit (which was a concern in the past).

Vuln management example: "Vuln management systems would have to be configured/locked down in a way that prevents malicious attacks on Certificate Systems"

Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
---
title: Network and Certificate System Security Requirements
subtitle: Version 2.0.1
subtitle: Version {}
author:
- CA/Browser Forum
date: 11 November, 2024
date: {}
copyright: |
Copyright 2024 CA/Browser Forum

Expand Down Expand Up @@ -64,16 +64,10 @@ The following are outcomes that this document seeks to achieve:

**CA Infrastructure**: Collectively the infrastructure used by the CA or Delegated Third Party which qualifies as a:

* Certificate Management System;
* Certificate System;
* Delegated Third Party System;
* Issuing System;
* Root CA System (Air-Gapped and otherwise); or
* Security Support System.
* Certificate System; or
* Root CA System (Air-Gapped and otherwise).

**Certificate Management System**: A system used by a CA or Delegated Third Party to process, approve issuance of, or store certificates or certificate status information, including the database, database server, and storage.

**Certificate System**: A system used by a CA or Delegated Third Party to access, process, or manage data or provide services related to:
**Certificate System**: A system used by a CA or Delegated Third Party to access, process, or manage data or provide services related to performing:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to store, access, process, or manage data

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cloud Services Subgroup Concern: Removal of Support Systems from Certificate Systems no longer encompasses those periphery systems in any kind of requirements for controls. How can we incorporate those requirements into this definition?


1. identity validation;
2. identity authentication;
Expand All @@ -82,21 +76,13 @@ The following are outcomes that this document seeks to achieve:
5. certificate approval;
6. certificate issuance;
7. certificate revocation;
8. authoritative certificate status; or
8. generation and signing of authoritative certificate status; or
9. key escrow.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be "CA Key Escrow" as just "Key Escrow" is rather broad?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's intended to apply also to escrow of Subscriber keys, where allowed (such as with S/MIME Certificates), so I believe it's correct as-is. Where key escrow is not performed by a CA, then this becomes not applicable (therefore neither constraining nor expanding the requirements applied to the CA).


**Common Vulnerability Scoring System (CVSS)**: A quantitative model used to measure the base level severity of a vulnerability (see <http://nvd.nist.gov/vuln-metrics/cvss>).

**Critical Security Event**: An event, set of circumstances, or anomalous activity that could lead to a circumvention of CA Infrastructure security controls or compromise of CA Infrastructure integrity or operational continuity, including, but not limited to, excessive login attempts, attempts to access prohibited resources, DoS/DDoS attacks, attacker reconnaissance, excessive traffic at unusual hours, signs of unauthorized access, system intrusion, or physical compromise of component integrity.

**Critical Vulnerability**: A system vulnerability that has a CVSS v2.0 score of 7.0 or higher according to the NVD or an equivalent to such CVSS rating (see <https://nvd.nist.gov/vuln-metrics/cvss>), or as otherwise designated as a Critical Vulnerability by the CA or the CA/Browser Forum.

**Delegated Third Party**: A natural person or legal entity that is not the CA and that operates any part of a Certificate System.

**Delegated Third Party System**: Any part of a Certificate System used by a Delegated Third Party while performing the functions delegated to it by the CA.

**Issuing System**: A system used to sign certificates or validity status information.

**Key Pair**: The Private Key and its associated Public Key.

**Multi-Factor Authentication**: An authentication mechanism consisting of two or more of the following independent categories of credentials (i.e. factors) to verify the user’s identity for a login or other transaction:
Expand All @@ -109,14 +95,8 @@ Each factor is independent of the other(s).

**Multi-Party Control**: An access control mechanism which requires two or more separate, authorized users to successfully authenticate with their own unique credentials prior to access being granted.

**National Vulnerability Database (NVD)**: A database that includes the Common Vulnerability Scoring System (CVSS) scores of security-related software flaws, misconfigurations, and vulnerabilities associated with systems (see <http://nvd.nist.gov/>).

**Network Equipment**: Hardware devices and components that facilitate communication and data transfer within the CA Infrastructure.

**OWASP Top Ten**: A list of application vulnerabilities published by the Open Web Application Security Project (see <https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project>).

**Penetration Test**: A process that identifies and attempts to exploit openings and vulnerabilities on systems through the active use of known attack techniques, including the combination of different types of exploits, with a goal of breaking through layers of defenses and reporting on unpatched vulnerabilities and system weaknesses.

**Physically Secure Environment**: A controlled and protected physical space consisting minimally of a physical environment which is:

1. protected by security controls which address the topics outlined in [section 4.5.1 of RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647#section-4.5.1); and
Expand Down Expand Up @@ -155,24 +135,9 @@ Each factor is independent of the other(s).
2. store a Root CA Private Key; or
3. create digital signatures using a Root CA Private Key.

**SANS Top 25**: A list created with input from the SysAdmin, Audit, Network, and Security (SANS) Institute and the Common Weakness Enumeration (CWE) that identifies the Top 25 Most Dangerous Software Errors that lead to exploitable vulnerabilities (see <http://www.sans.org/top25-software-errors/>).

**Security Support System**: A system or set of systems supporting the security of the CA Infrastructure, which minimally includes:

1. authentication;
2. network boundary control;
3. audit logging;
4. audit log reduction and analysis;
5. vulnerability scanning;
6. physical intrusion detection;
7. host-based intrusion detection; and
8. network-based intrusion detection.

**System**: One or more pieces of equipment or software that stores, transforms, or communicates data.

**Trusted Role**: An employee or contractor of a CA or Delegated Third Party who has authorized access to any component of CA Infrastructure.

**Vulnerability Scan**: A process that uses manual or automated tools to probe internal and external systems to check and report on the status of operating systems, services, and devices exposed to the network and the presence of vulnerabilities listed in the NVD, OWASP Top Ten, or SANS Top 25.
**Trusted Role**: An individual employee or contractor of a CA or Delegated Third Party who has authorized access to any component of CA Infrastructure.
clintwilson marked this conversation as resolved.
Show resolved Hide resolved

**Workstation**: A device, such as a phone, tablet, or desktop or laptop computer, which is capable of accessing CA Infrastructure and/or Network Equipment with elevated privileges compared to any given point on the general internet.

Expand Down Expand Up @@ -219,7 +184,9 @@ CA Infrastructure MUST be in a Physically Secure Environment.

##### 1.2.2

Connections to and within the CA Infrastructure MUST be authenticated and encrypted except OCSP and CRL.
Connections to the CA Infrastructure MUST be authenticated and encrypted, except where documented that a formal specification prohibits or limits the use of authentication and/or encryption.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should say ", except where a formal specification prohibits ..."? It seems that "where documented that" adds an unnecessary record-creating requirement and could be deleted without changing meaning. But I'm open to other suggestions/comments.


Connections within the CA Infrastructure SHOULD be authenticated and encrypted.

CA Infrastructure and Network Equipment MUST be implemented and configured in a manner that minimizes unnecessary active components and capabilities such that:

Expand Down Expand Up @@ -298,6 +265,7 @@ The CA MUST ensure personnel assigned to Trusted Roles that are authorized to ac
###### 2.2.1.2

The CA SHOULD NOT allow group accounts or shared role credentials to authenticate to or access CA Infrastructure and/or Network Equipment. If group accounts or shared role credentials are used, the CA MUST be able to attribute each use to

* an approved activity; and
* an individual user or service account.

Expand Down Expand Up @@ -445,37 +413,69 @@ The CA SHOULD ensure incident response plans minimally include:
2. containment of the incident to minimize further impact; and
3. identification and mitigation or eradication of the incident root cause(s).

### 4. Vulnerability Detection and Patch Management
### 4. Vulnerability Management

The CA MUST implement the policies and procedures in this Section for identifying, evaluating, and resolving security vulnerabilities.

These policies and procedures MUST apply to all Certificate Systems.

These policies and procedures SHOULD apply to Security Support Systems.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Security Support Systems has been removed as a defined term.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


#### 4.1 Inventory of Certificate Systems

The CA MUST define an inventory of Certificate Systems.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CS group feedback: what if we move this up so that it pertains not just to vuln management, which I don't believe was the intention?


#### 4.2 Intrusion Detection and Prevention

The CA MUST protect the systems in the inventory of Certificate Systems against common network and system threats using intrusion detection and prevention controls.

#### 4.3 Vulnerability Management Lifecycle

The CA MUST document and follow a vulnerability correction process that includes:

1. identification;
1. review;
1. response; and
1. remediation.

##### 4.3.1 Vulnerability Identification

The CA's vulnerability identification process MUST include monitoring for relevant security advisories and penetration testing.

Certification Authorities and Delegated Third Parties SHALL:
###### 4.3.1.1 Penetration Testing

a. Implement intrusion detection and prevention controls under the control of CA or Delegated Third Party Trusted Roles to protect Certificate Systems against common network and system threats;
As part of the identification component of the CA's vulnerability correction process, the CA MUST define and follow a program for performing penetration tests that ensures:

b. Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities;
1. penetration tests are performed:
* at least on an annual basis; and
* after infrastructure or application changes that are organizationally defined as significant; and
2. penetration tests are performed by a person or entity (or collective group thereof) with the requisite skills, tools, proficiency, code of ethics, and independence; and
3. vulnerabilities identified during the penetration test are remediated using the vulnerability correction process in [Section 4.3](#43-vulnerability-management-lifecycle).

c. Undergo or perform a Vulnerability Scan
##### 4.3.2 Vulnerability Remediation

1. within one (1) week of receiving a request from the CA/Browser Forum,
2. after any system or network changes that the CA determines are significant, and
3. at least every three (3) months, on public and private IP addresses identified by the CA or Delegated Third Party as the CA’s or Delegated Third Party’s Certificate Systems;
A vulnerability is remediated when the CA has:

d. Undergo a Penetration Test on the CA’s and each Delegated Third Party’s Certificate Systems on at least an annual basis and after infrastructure or application upgrades or modifications that the CA determines are significant;
* fixed the vulnerability such that the vulnerability is no longer present; or
* confirmed the impact of the vulnerability and documented why the vulnerability does not impact the CA's security posture.

e. Record evidence that each Vulnerability Scan and Penetration Test was performed by a person or entity (or collective group thereof) with the skills, tools, proficiency, code of ethics, and independence necessary to provide a reliable Vulnerability Scan or Penetration Test; and
#### 4.4 Vulnerability Management Timeframe

f. Do one of the following within ninety-six (96) hours of discovery of a Critical Vulnerability not previously addressed by the CA’s vulnerability correction process:
The CA MUST establish one or more timeframes for reviewing, responding to, and remediating all identified vulnerabilities.

1. Remediate the Critical Vulnerability;
2. If remediation of the Critical Vulnerability within ninety-six (96) hours is not possible, create and implement a plan to mitigate the Critical Vulnerability, giving priority to
Each timeframe MUST be established based on a risk assessment performed by the CA.

i. vulnerabilities with high CVSS scores, starting with the vulnerabilities the CA determines are the most critical (such as those with a CVSS score of 10.0) and
ii. systems that lack sufficient compensating controls that, if the vulnerability were left unmitigated, would allow external system control, code execution, privilege escalation, or system compromise; or
The risk assessment MUST be based on a documented security analysis. The security analysis SHOULD take into account and address the following principles:

3. Document the factual basis for the CA’s determination that the vulnerability does not require remediation because
* criticality of assets;
* maintaining confidentiality, integrity, and availability of assets;
* regulatory requirements;
* likelihood and impact of exploitation;
* dependencies and interdependencies;
* remediation resource requirements;
* historical data; and
* present threat landscape.

i. the CA disagrees with the NVD rating,
ii. the identification is a false positive,
iii. the exploit of the vulnerability is prevented by compensating controls or an absence of threats; or
iv. other similar reasons.
The CA MUST ensure vulnerabilities are reviewed, responded to, and remediated in accordance with their established timeframe(s).

g. Apply recommended security patches to Certificate Systems within six (6) months of the security patch's availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch.
The CA MUST document in Section 6.7 of their Certificate Policy and/or Certification Practices Statement each timeframe established for responding to and remediating vulnerabilities.