Ballot NS004 - Updating Section 4 - Vulnerability Management - of the NSRs #34
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
miguelantonios
changed the title
miguelantonios
changed the title
miguelantonios
changed the title
clintwilson
pushed a commit
that referenced
this pull request
May 29, 2024
Update wording throughout Section 4 Fix headings to fit within NS-003 structure
clintwilson
reviewed
Jul 2, 2024
This is the latest PR for the work that the NetSec team is doing to revamp section 4 of the NSRs
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
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.
Added a very minor addition to the Network Equipment definition by adding an "other" in "Hardware devices and OTHER components that..."
Added some language for clarity to the Certificate Systems definition.
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
Based on discussion August 13, 2024, update Section 4. Also reordering 4 of the 5 subsections to be more "sequential"
…iscussion Proposed NS004 reorder and NSWG discussion updates
dkluge
reviewed
Aug 28, 2024
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."
miguelantonios
commented
Sep 3, 2024
Added preamble for section 4.4 "The CA's vulnerability identification process MUST include monitoring for relevant security advisories and penetration testing."
danjeffery
reviewed
Sep 3, 2024
docs/NSR.md
Outdated
|
|
||
| 3. Document the factual basis for the CA’s determination that the vulnerability does not require remediation because | ||
| The CA's vulnerability identification process MUST include monitoring for relevant security advisories and penetration testing. |
There was a problem hiding this comment.
This duplicates line 502. Probably just cut it.
There was a problem hiding this comment.
Will remove one of them. Thanks.
Closing out some comments. Changes made: 1. Removed duplicate sentence about monitoring external sources for vulns 2. Updated language in 4.3
danjeffery
reviewed
Sep 4, 2024
Based on Dan's comments and discussion in 10 Sep 24 NSWG meeting, incorporating these changes prior to discussion period start.
Updating the effective date to April 22, 2025 and making it optional to adhere to these new requirements prior to April 22, 2025.
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.
Updated ## Requirements language.
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.
Remove the OWASP Top 10 definition. I missed it in my previous commit.
clintwilson
approved these changes
Dec 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary: Section 4 of the Network and Certificate System Security Requirements (NCSSRs) stipulates that CAs have to perform a number of vulnerability management practices and emphasizes regular vulnerability scans and penetration tests. This Ballot proposes to replace Section 4 with a more comprehensive vulnerability management approach that is not limited to specific practices. Vulnerability scans and penetration tests are useful controls for some CA system environments but they are insufficient if they are not embedded in a broader set of policies and procedures that take CA specific risks into account. The network and system architecture can differ significantly between CAs. CAs should identify and address vulnerabilities based on the risks in their respective environments .
We propose that CAs should address all vulnerabilities within their own predefined timelines that must be commensurate with the risks they introduce. To meet the requirements of the new Section 4, CAs need to demonstrate that they have developed and implemented an effective vulnerability management program. We expect the CAs’ auditors to verify that remediation timelines are defined, measurable and adequate. This will replace the specific rule that limits remediation tracking to only critical vulnerabilities and within a 96 hour timeline. We have determined that this is an insufficient mechanism to achieve vulnerability management as multiple lower risk issues can also create an insecure system.
Similarly, CAs must create a policy definition of what network or system changes they regard as significant and require an additional (non-periodic) penetration test. The definition can vary from CA to CA. As a guideline, we assume that changes which alter the data flow or introduce new service integrations are typically significant. Penetration tests must still be performed by qualified and independent internal or external penetration testers as stated in the requirements.
All systems that are involved in performing CA functions must be in scope of the vulnerability management program. After multiple discussions in the NetSec and other meetings it has been determined that the system definitions in the NCSSRs can be interpreted in multiple different ways. This could create an inconsistency in what may be audited across CAs. To resolve this we propose two changes to Section 4. First, we have defined the functions of a CA. Second, CAs will be formally required to maintain an inventory of systems instead.
This Pull Request:
How can you help?