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.

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

Clarify the nested CNA structure #49

Open
EvansJonathan opened this issue Aug 1, 2017 · 13 comments
Open

Clarify the nested CNA structure #49

EvansJonathan opened this issue Aug 1, 2017 · 13 comments

Comments

@EvansJonathan
Copy link
Contributor

GOAL: Better describe the nested Root CNA structure (with a new diagram?).
CHANGE: Describe the nested Root CNA structure. Provide diagrams to give a visual representation of the structure for further clarity.
OUTCOME: Reduce confusion when speaking about the Root CNA structure and operation.

@dadinolfi
Copy link
Contributor

dadinolfi commented Aug 15, 2017

Suggested new Federated CNA Structure diagram:

cnaprogramchart

Figure 1. Federated CNA Structure

@dadinolfi
Copy link
Contributor

Current text of section 1.2:
In a federated CNA structure, CNAs are categorized as Primary, Root, and Sub-CNAs. Multiple Sub-CNAs may operate under the oversight of a Root CNA, while the Root CNAs operate under the oversight of a single, Primary CNA. Sub-CNAs only assign CVEs for vulnerabilities in their own products or their domain of responsibility, hereinafter referred to as scope. Root CNAs manage a group of Sub-CNAs within a given domain or community, train and admit new Sub-CNAs, and are the assigners of last resort (i.e., no Sub-CNA exists for the scope) within that domain or community. The Primary CNA operates the CVE Program, manages Root CNAs and Sub-CNAs, trains and admits new Root CNAs and Sub-CNAs, and is the assigner of last resort for requesters that are unable to have CVEs assigned at the Sub- or Root CNA levels.
In cases where requests or issues cannot be resolved by a given CNA, the issues are escalated to the next higher-level CNA. Requests and issues at the Sub-CNA level can be elevated to Root CNAs, and requests and issues at the Root CNAs can be elevated to the Primary CNA. The same flow, from Sub-CNAs to Root CNAs to the Primary CNA, is followed to alert the next higher CNA when CVEs are assigned, or when reporting other programmatic data. The Primary CNA provides blocks of IDs to Root CNAs, and Root CNAs provide blocks of IDs to Sub-CNAs.

@dadinolfi
Copy link
Contributor

To add under the diagram:
Figure 1. shows how different Root CNAs have different areas of responsibility. Each colored box is a distinctly described scope. For the gray box, part of the scope of the gray box has been delegated to a Root CNA and its Sub-CNAs, as indicated by the yellow box.

@dadinolfi
Copy link
Contributor

Update to first paragraph:
In a federated CNA structure, CNAs are categorized as Primary, Root, and Sub-CNAs (or just "CNAs", generically). Multiple Sub-CNAs may operate under the oversight of a Root CNA, while the Root CNAs operate under the oversight of a single, Primary CNA or another Root CNA. Sub-CNAs only assign CVEs for vulnerabilities in their own products or their domain of responsibility, hereinafter referred to as scope. Root CNAs manage a group of Sub-CNAs within a given domain or community, train and admit new Sub-CNAs, and are the assigners of last resort (i.e., no Sub-CNA exists for the scope) within that domain or community. The Primary CNA operates the CVE Program, manages Root CNAs and Sub-CNAs, trains and admits new Root CNAs and Sub-CNAs, and is the assigner of last resort for requesters that are unable to have CVEs assigned at the Sub- or Root CNA levels.

@dadinolfi
Copy link
Contributor

The Board's Strategic Planning Working Group is still considering this suggestion and where other language can be improved. Leaving this issue open until they have had time to review it.

@kurtseifried
Copy link

one note: the DWF CNA entries now include who the parent is, who the primar and secondary CVE Mentors are, e.g.:

https://github.com/distributedweaknessfiling/DWF-CNA-Registry/blob/master/CNA-Registry/000000/cna-4.json

so people are welcome to parse this data and make a graph if they want.

@kurtseifried
Copy link

To be clear: we should require CNA's to publish their sub-CNA data publicly, for a ton of reasons, not just to make graphs, but also to allow people to find them, report problems to the parent, etc.

@david-waltermire
Copy link

With regards to "The Primary CNA operates the CVE Program, manages Root CNAs and Sub-CNAs, trains and admits new Root CNAs and Sub-CNAs" in your original text, the intent of the federated model is for delegation of management of Sub-CNAs to the Root CNAs. The primary will manage the roots, the roots will manage the subs. The text needs to be revised to reflect this.

@david-waltermire
Copy link

Similar to my previous comment, the expectation under a federated model is that root CNAs are responsible for recruitment of sub-CNAs in their scope. The text in the summary "The Primary CNA operates the CVE Program, [...], trains and admits new Root CNAs and Sub-CNAs" should be revised to reflect this. One way of handling this is for the Primary to forward to the appropriate root any party interested in joining a scope covered by that root.

@david-waltermire
Copy link

Are we disallowing further federation under a Sub-CNA? Should this be allowed? Should roots have the ability to organize in a way that makes sense for their scope?

@ghost
Copy link

ghost commented Sep 15, 2017

@david-waltermire-nist so we already have people/orgs that exist in multiple hierarchies (e.g. Josh Bressers in DWF and for Elastic), I'm wondering what other styles of organization are needed (hierarchy with membership in multiple hierarchies/levels seems to address most things no?).

@dadinolfi
Copy link
Contributor

We are not allowing further federation under a Sub-CNA. We have an example of a nested Root in the third column of the graphic.

The goal of having Root organize by scope is correct, in my opinion. But for edge cases, not every Sub-CNA will be a perfect fit. As long as we have things well documented and can direct requests to the right place, escalate problems appropriately, and disseminate CVE ID blocks efficiently, I'm not sure it will have a huge impact.

@dadinolfi
Copy link
Contributor

Some minor rewording for the first paragraph of 1.2:

In a federated CNA structure, CNAs are categorized as Primary, Root, and Sub-CNAs (or just "CNAs", generically). Multiple Sub-CNAs may operate under the oversight of a Root CNA, while the Root CNAs operate under the oversight of a single, Primary CNA or another Root CNA. Sub-CNAs only assign CVEs for vulnerabilities in their own products or their domain of responsibility, hereinafter referred to as scope. Root CNAs manage a group of Sub-CNAs within a given domain or community, train and admit new Sub-CNAs, and are the assigners of last resort (i.e., no Sub-CNA exists for the scope) within that domain or community. The Primary CNA oversees the CVE Program, coordinates Root CNAs and Sub-CNAs, trains and admits new Root CNAs and Sub-CNAs, enables Root CNAs to administer their CVE scope, and is the assigner of last resort for requesters that are unable to have CVEs assigned at the Sub- or Root CNA levels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants