Skip to content

Commit

Permalink
CA Infrastructure Scope update
Browse files Browse the repository at this point in the history 
Following discussions in the NSWG, this is an example version of the NCSSRs which removes several of the "Systems" from the scope of CA Infrastructure (and the document in general).
The changes are based on the assumed completion of IPR review for NS-004 and NS-006.

Additionally, fixed some minor issues arising from NS-004 and NS-006:
* Reversion of Workstation definition
* Orphaned text in 1.2.2
* Markdown formatting in 2.2.1.2
  • Loading branch information
@clintwilson
clintwilson committed Nov 20, 2024
1 parent b2e6786 commit 5142604
Showing 1 changed file with 64 additions and 64 deletions.
128 changes: 64 additions & 64 deletions docs/NSR.md
View file
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:

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.

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

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

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.

#### 4.1 Inventory of Certificate Systems

The CA MUST define an inventory of Certificate Systems.

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

0 comments on commit 5142604

Please sign in to comment.