From ad224e266a0ae0bdfa5018e9f4baf4ee8b1e0e90 Mon Sep 17 00:00:00 2001 From: miguelantonios <159276983+miguelantonios@users.noreply.github.com> Date: Mon, 16 Dec 2024 23:48:10 -0500 Subject: [PATCH 1/2] Ballot NS004 - Updating Section 4 - Vulnerability Management - of the NSRs (#34) * Updating NSR Section 4 This is the latest PR for the work that the NetSec team is doing to revamp section 4 of the NSRs * Update NSR.md * Update NS-004 based on discussion in NSWG Incorporate feedback from Clint as discussed at CA/BF F2F #62 NB: This had to be rebased onto a branch that also changed the definition of Certficate Systems, to Certificate System, with a list similar to the one initially contained in this commit, but in fact more extensive. The list after Ballot NS-003 was: 1. identity validation; 2. identity authentication; 3. account registration; 4. certificate application; 5. certificate approval; 6. certificate issuance; 7. certificate revocation; 8. authoritative certificate status; or 9. key escrow. in the NS-004 pull request, the list was: * certificate application; * certificate validation; * certificate approval; * signing; * certificate revocation; * serving authoritative certificate status information; or * key escrow. I have resolved this conflict by taking "certificate validation" and inserting it into the list as of NS-003 as the fifth item. -- tobij * Remove "certificate validation" from the Certificate System definition In the Cloud Services call, we agreed that the term is problematic as "certificate validation" is something that is performed by browsers when encountering a certificate on a website, and also otherwise not required as it should be covered by the "identity validation" list item. * Update NSR.md Added a very minor addition to the Network Equipment definition by adding an "other" in "Hardware devices and OTHER components that..." * Update NSR.md Added some language for clarity to the Certificate Systems definition. * Update NSR.md Removed the word `minimally` from section 4 as it is already covered in the Introduction section. Made some verbiage changes to make the requirements clearer in section 4 * Reorder Section 4 and update from NSWG discussion Based on discussion August 13, 2024, update Section 4. Also reordering 4 of the 5 subsections to be more "sequential" * Address comments * Add effective date for CP/CPS SLO * Update NSR.md Added a preamble to section 4.4 that states: "The CA's vulnerability identification process MUST include monitoring for relevant security advisories and penetration testing." * Update NSR.md Added preamble for section 4.4 "The CA's vulnerability identification process MUST include monitoring for relevant security advisories and penetration testing." * Update NSR.md Closing out some comments. Changes made: 1. Removed duplicate sentence about monitoring external sources for vulns 2. Updated language in 4.3 * Updates from 10 Sep 24 NSWG Based on Dan's comments and discussion in 10 Sep 24 NSWG meeting, incorporating these changes prior to discussion period start. * Update NSR.md Updating the effective date to April 22, 2025 and making it optional to adhere to these new requirements prior to April 22, 2025. * Update NSR.md Changed the language in the ##Requirements section to read: "Effective 2025-04-29, the CA shall adhere to these Requirements" This represents an effective date that is 7 days after NS-005 ballot goes into effect. * Update NSR.md Updated ## Requirements language. * Update NSR.md Remove unused definitions and clarify what NCSSR version is in force. This was made in response to Corey Bonnell's feedback at https://groups.google.com/a/groups.cabforum.org/g/netsec/c/k4T0UfTRBDI/m/6LBjnhWbAQAJ The date in force was revised to reflect what was used in NS005. * Update NSR.md Remove the OWASP Top 10 definition. I missed it in my previous commit. --------- Co-authored-by: Clint Wilson Co-authored-by: Tobias S. Josefowitz Co-authored-by: Cade Cairns Co-authored-by: Clint Wilson --- docs/NSR.md | 97 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 59 insertions(+), 38 deletions(-) diff --git a/docs/NSR.md b/docs/NSR.md index aada664..65f486e 100644 --- a/docs/NSR.md +++ b/docs/NSR.md @@ -73,7 +73,7 @@ The following are outcomes that this document seeks to achieve: **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; @@ -82,15 +82,11 @@ 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 ). - **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 ), 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. @@ -109,13 +105,7 @@ 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 ). - -**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 ). - -**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. +**Network Equipment**: Hardware devices and other components that facilitate communication and data transfer within the CA Infrastructure. **Physically Secure Environment**: A controlled and protected physical space consisting minimally of a physical environment which is: @@ -155,8 +145,6 @@ 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 ). - **Security Support System**: A system or set of systems supporting the security of the CA Infrastructure, which minimally includes: 1. authentication; @@ -172,9 +160,10 @@ Each factor is independent of the other(s). **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. +**Workstation**: A device, such as a phone, tablet, or desktop or laptop computer, which is: -**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. + 1. connected to the same network as CA Infrastructure and/or Network Equipment; and + 2. capable of accessing CA Infrastructure and/or Network Equipment. ## Requirements @@ -445,37 +434,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. From 607a34dbf7e054f2e191804c3edafe0eda074221 Mon Sep 17 00:00:00 2001 From: Daniel Jeffery <11964037+danjeffery@users.noreply.github.com> Date: Mon, 16 Dec 2024 21:49:39 -0700 Subject: [PATCH 2/2] NS-006: Fix 1.2.2 encrypted connections scoping (#40) * Fix 1.2.2 encrypted connections scoping * Set dates * Update dates --------- Co-authored-by: Clint Wilson --- docs/NSR.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/NSR.md b/docs/NSR.md index 65f486e..3e646f6 100644 --- a/docs/NSR.md +++ b/docs/NSR.md @@ -3,7 +3,7 @@ title: Network and Certificate System Security Requirements subtitle: Version 2.0.1 author: - CA/Browser Forum -date: 11 November, 2024 +date: 28 Oct, 2024 copyright: | Copyright 2024 CA/Browser Forum @@ -208,7 +208,12 @@ 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. + + 1. between CA Infrastructure components; and + 2. between CA Infrastructure and non-CA Infrastructure. CA Infrastructure and Network Equipment MUST be implemented and configured in a manner that minimizes unnecessary active components and capabilities such that: