1. Becoming a CNA
CVE Team

2. Overview Defining CNAs How to organize your CNA(s)
Defining the scope of your coverage
Updating your internal processes
CNA resources and community involvement

3. Defining CNAs

4. Role of the CNA What are CVE Numbering Authorities (CNAs)?
CNAs are organizations that are authorized to assign CVE IDs to vulnerabilities affecting products within their distinct, agreed upon scope
Why do we need CNAs?
CNAs help to address the CVE Program's primary challenge to satisfy the demand for timely, accurate CVE ID assignments while rapidly expanding the scope of coverage to address the increasing number of vulnerabilities and evolving state of vulnerability management
What value do CNAs provide?
CNAs allow CVE IDs to be produced more quickly and in a more distributed manner

5. Benefits of Being a CNA Benefits of becoming a CNA include:
More control over CVE Entry publication process
Ability to publicly disclose a vulnerability with an already assigned CVE ID
Ability to control the disclosure of vulnerability information without pre-publishing
Early notification, by researchers requesting a CVE ID, of vulnerabilities in products within a CNA’s scope
Being part of the CNA community

6. CNA Qualifications A CNA must be:
A vendor with a significant user base and an established security advisory capability or an established entity with an established security advisory capability that typically acts as a neutral interface between researchers and vendors
An established distribution point or source for first-time product vulnerability announcements (which may concern their own products)
Willing to follow CNA Rules
The CNA must follow coordinated disclosure practices as determined by the community they serve in order to reduce the likelihood that duplicate or inaccurate information will be introduced into CVE
Root CNA and Primary CNA are defined in Governance section.

7. Cost of Being a CNA There is no fee There is no contract to sign
You are expected to put in the time and effort to implement the CNA Rules

8. Who to Contact Which parent CNA is right for you? National level
Industry level
Program Root level
If you are not sure, contact the CVE Program Root CNA:
Contact information for the CNAs:

9. Organization

10. Organizing Your CNA Program
How your organization is configured will influence the way you set up your CNA program
Most organizations designate a single group to manage their CNA program; however, that is not always the case. For example:
The Android and Chrome PSIRTs work independently and act as their own CNAs, even though they are both part of Google
Cisco and Cisco Talos are separate CNAs due to their vastly different scopes (i.e., Cisco products versus the vulnerabilities they found during their research)
Within Dell, the Dell CNA covers Dell, EMC products, and the products of many of their subsidiary companies; however, they do not cover VMware, which has its own CNA program

11. Types of CNA Structures
A single group handles all vulnerabilities
Create a single CNA
A single group handles the coordination with multiple internal groups
Usually results in a single CNA
That CNA sometimes chooses to create unofficial sub-CNAs to which it can give blocks of IDs
There is no issue with a CNA creating internal unofficial sub-CNAs if the results meet the needs of the CVE Program
Multiple groups handle their own vulnerabilities
Create a CNA for each independent group

12. Scope

13. Defining Scope
A CNA’s scope defines the vulnerabilities to which it is responsible for assigning CVE IDs
The scope sets expectations, which should:
Prevent CNAs with overlapping scopes (e.g., their Root CNA) from assigning duplicate IDs
Save reporters’ time and frustration by preventing them from reporting irrelevant issues
Save the CNA time by reducing the number of unwanted reports
Save the Root CNA time by reducing the number of complaints by unhappy reporters

14. Scope: Types of CNAs Vendors: Cover products
e.g., Microsoft, OpenSSL, Debian
Coordinators: Cover the vulnerabilities coordinated by the organization
e.g., CERT/CC, JPCERT/CC, HackerOne
Research Organizations: Cover the vulnerabilities discovered by individual researchers
e.g., Rapid7
Mixed
e.g., Flexera (vendor and research), Drupal (vendor and coordinator)
Other: Some CNAs do not fall into the typical categories described above
e.g., MITRE

15. Scope: Limited by Advisory Policy
Are there some scenarios where advisories are not published?
All advisories must meet the CVE Program’s requirements for being published:
Must have a URL
The Terms of Service must allow a link to the URL
The document linked to the URL must contain the minimum required information for a CVE Entry:
Product
Version
Problem type (vulnerability type or impact)
Must not require a fee to access

16. Scope: Limited by Products
Do you plan to cover all of the products you produce?
Consider the following types of products when deciding which products will be covered within the scope:
Products from subsidiary companies
Products from newly acquired companies
Discontinued products
Versions that have reached their end of support
Experimental products or development branches
Freebie products

17. Scope: Limited by Vulnerability Type
Explain the criteria used to determine if an issue is a vulnerability
e.g.,
Provide an explicit list of the types of issues not considered vulnerabilities to help limit the number of unwanted requests:
Self-DoS
CSRF logout
Insecure default configurations
Default credentials

18. Update Processes

19. Process: Accepting Vulnerability Reports
Are third party requests accepted?
If so, provide contact information:
Contact information should be provided to your Root CNA
A registry of contact information is maintained on the CVE Program website:
What information should vulnerability reporters provide?
[1]

20. Process: Block Management
Who in your organization can assign IDs?
At what point in the process should a CVE ID be assigned?
When an ID is assigned, how is it recorded?
How are vulnerabilities tracked (i.e., which vulnerability is assigned to which CVE ID)?

21. Process: Publish a Disclosure Policy
The disclosure policy should at least include the expected timeframe and conditions under which vulnerability information will be published
The following additional communication points are advised:
Acknowledge receipt of submission (i.e., provide an initial response to reporter, even if it is just a “we received your request and are looking into it”)
Give reporter approximate time it will take to get back to them with a determination on whether there is a vulnerability
Advise the reporter when they can expect to receive the CVE ID for the vulnerability
Advise the reporter when the issue will be fixed and when an advisory can be published

22. Process: Publication Advisories must be made public
The advisory should clearly state which CVE ID is associated with which vulnerability
Are CVE Entries sent to the Root CNA, or directly to the Program Root CNA?
The Root CNA may require CVE Entries be sent directly to them
CVE Entries should be sent within 24 hours of the vulnerability being made public

23. Process: CVE Entry Update Requests
CNAs will receive requests to update CVE Entries that have been created; a process should be established to handle these requests
If the request to update a CVE Entry is sent to a Root CNA or the Program Root CNA, the issuing CNA should decide if they want to be notified.
Decide if notification is necessary under the following conditions:
Spelling or grammar issues
Adding a reference

24. Process: Reporting (All CNAs)
Quarterly reports on the functioning of the CNA program are required
The current requirements are:
For All CNAs:
Number of unique vulnerability reports received from external parties (assigned and not assigned CVE IDs) Rationale: This gives an idea of how much vulnerability disclosure activity there is in each CNA, which can then be extrapolated to sectors or some other category of CNA.
Average time between assignment of CVE ID and publication of CVE Entry Rationale: Again, taken in aggregate, gives an idea for what the common timeframes are, which can inform discussions of best practice.

25. Process: Reporting (Root CNAs)
The current requirements are:
For Root CNAs:
Number of times an issue was escalated to the Root CNA Rationale: How much of a Root CNA’s time is spent dealing with escalations? Does it scale with the number of Sub-CNAs they have? Does it vary between sectors?
Categories of escalated issues and percentage of total:
Dispute
Responsiveness
Misuse of CVE
Rationale: What is the nature of the issues that Root CNAs are addressing, which can inform training, documentation, and process improvement.
List of Sub-CNAs and New Sub-CNAs this quarter Rationale: Forces the periodic update of the full CNA directory.

26. Information CNAs Are Required to Provide to their Parent CNA
Point of Contact (POC)
As defined by the parent CNA
Scope definition
Disclosure policy
Root CNAs may require additional information to be provided

27. CNA Resources and Community Involvement

28. Training Parent CNA provides initial training
The training should include:
A CNA Rules review
Training batch of IDs which will be reviewed with Parent CNA
Additional Training
CNA Summits
Supplementary documentation
An internal training process should be developed for those who join the team
Program Root CNA (currently MITRE) can help provide supplemental material

29. CVE Working Groups (1 of 2)
Automation WG
JSON format
CVE Entry submission service
CVE ID allocation service
CVE user registry

30. CVE Working Groups (2 of 2)
Strategic Planning WG
Cloud Services WG
CNA Coordination WG
CVE Entry Quality WG

31. Other Community Participation
CNA mailing list
For program wide announcements
Used by CNAs to discuss issues that may affect multiple CNAs
Limited to CNA and Board members
CNA Summits
Yearly conference to discuss lessons learned, issues, and program improvements
Webinars
Ad-Hoc meetings to discuss issues affecting CNAs and the CVE Program
Handshake (MITRE’s social media platform)

32. Questions

33. Backup Slides

34. Assignment Rules
The following rules apply to all CNAs when assigning CVE IDs to vulnerabilities:
Assign CVE IDs to security vulnerabilities within scope of authority for vulnerabilities that are, or will be, made public
Only assign CVE IDs to security vulnerabilities when no lower level CNA exists that already covers a more constrained scope (this may require coordination)
Follow CVE counting rules established by the CVE Program as implemented by the Program Root CNA and augmented by Root CNAs and Sub-CNAs if applicable
Disputes related to scope should first be addressed by the next higher-level CNA before being escalated

35. Communication Rules (1 of 2)
The following communications rules apply to all CNAs:
Provide points of contact (POCs) (e.g., addresses, URLs, etc.) to all levels above their own
Publish a disclosure (embargo) policy and a description of its scope
If a CNA accepts requests from parties outside the CNA, provide a means (e.g., hyperlink, ) for the public to contact them regarding vulnerabilities. CNAs can also provide guidelines for how to communicate with them, such as language restrictions (“English- only”, “Japanese or English”, etc.). Provide the list publicly and to all levels above their own
Be responsive to inquiries from all CNAs
When a vulnerability is reported to the CNA and a CVE ID is assigned to that vulnerability, provide the CVE ID to the reporter. This rule does not override any embargo rules established by the CNA

36. Communication Rules (2 of 2)
The following communication rules apply to all CNAs (continued):
Notify the next higher level CNA when CVE IDs are assigned and the associated vulnerability is made public (the publication of the vulnerability can be made in any language, but the CVE ID entry must include English only; references to information related to the CVE ID in non-English languages would be included in the reference list for the CVE ID entry)
Provide CVE information to the next higher-level CNA when a CVE ID is assigned and the associated vulnerability made public
For new CVE IDs, this information includes, at a minimum, the CVE ID used, product, affected or fixed version, the problem type, references, and a description on a per-ID basis
When a CVE ID is updated, the CVE ID and data change must be included
Have an established distribution point for in-scope vulnerability disclosures that is freely available to the general public without restrictions (e.g., open websites, websites with registration and free accounts without restrictions, etc.)
Publish required CVE information in a standard format and presentation

37. Administration Rules
The following rules apply to all CNAs for the administration of the CVE Program:
Operate under the CVE Terms of Use
Track and provide metrics related to responsiveness to higher-level CNAs
Responsiveness metrics are established to ensure that CNAs are responsive to different types of requests from their various communities, and in timeframes appropriate for those communities
Metrics are provided quarterly to the next higher-level CNA
Responsiveness metrics may vary by CNA as determined by the unique circumstances of the particular CNA community
Provide any documentation required to adjudicate disputes to the higher-level CNA

38. Additional Root CNA Rules (1 of 3)
In addition to following the aforementioned rules, Root CNAs must perform the following functions:
Assignment Rules
Request CVE ID blocks from the Program Root CNA
Provide CVE ID blocks to Sub-CNAs from their CVE ID block
Assign CVE IDs as a CNA when necessary within its scope per the CVE counting rules when none of their Sub-CNAs cover that scope
Address CVE assignment issues from its Sub-CNAs that require escalation

39. Additional Root CNA Rules (2 of 3)
Communications Rules
Notify the Program Root CNA when Sub-CNAs are established or removed
Provide a public list of POCs and web links for each Sub-CNA in the Root CNA's domain; provide this information to the Program Root CNA
Maintain a private list of individual POCs within each Sub-CNA for use by CNAs only; provide this information to the Program Root CNA
Maintain a public listing of the established counting rules followed by the Root CNA and Sub-CNAs in its domain

40. Additional Root CNA Rules (3 of 3)
Administration Rules
Accept metrics reports from Sub-CNAs; the format and instructions for sending metrics are determined by the Root CNA
Submit metrics from Sub-CNAs quarterly, within two weeks of the quarter, to the Program Root CNA; quarters are based on the calendar year
Act as an escalation and adjudication point for issue resolution for Sub-CNAs in its domain
When appropriate, apply sanctions upon any Sub-CNAs within its domain and notify the Program Root CNA; the application of sanctions should occur as a last resort
Facilitate the enforcement of any administrative actions taken by the Program Root CNA against a Sub-CNA
Follow the CNA Candidate Process described in Section 4 of the CNA Rules when adding new Sub-CNAs

41. Additional Program Root CNA Rules (1 of 3)
In addition to following the afore mentioned rules, the Program Root CNA must perform the following functions:
Assignment Rules
Provide CVE ID blocks to Root CNAs
Maintain the CVE List and provide that information to the public
Assign CVE IDs as a CNA when necessary, per the CVE counting rules, when no Root CNAs cover that scope
Act as the CNA of last resort for assignment issues that require escalation

42. Additional Program Root CNA Rules (2 of 3)
Communications Rules
Provide a listing of all Root CNAs and Sub-CNAs, including public points of contact and web links; obtain this information from Root CNAs
Maintain a private list of individual POCs for each Root and Sub-CNA for use by CNAs only
Provide coordination of communication channels between Root CNAs
Respond to inquiries by Root CNAs and Sub-CNAs in a timely manner; establish responsiveness metrics for such responsiveness
Maintain a public listing of the established counting rules for the CVE Program

43. Additional Program Root CNA Rules (3 of 3)
Administration Rules
Serve as a member, and the Board moderator, of the CVE Board
Accept metrics reports from Root CNAs quarterly, within one month of the calendar quarter
Act as the final arbiter for appeals regarding CNA assignment decisions and CNA program issues
Act as an escalation point for issue resolution should this process fail at the Root CNA level
When appropriate, apply sanctions upon any CNA
Follow the CNA Candidate Process described in Section 4 of the CNA Rules when adding new Root CNAs

44. CVE ID Appeals Process
For situations where CVE ID assignment decisions are disputed, or where there is a disagreement between Root CNAs or between a Root CNA and one of their Sub-CNAs, the following process should be followed to resolve the issues:
The party seeking to appeal a decision made by a Root CNA, or resolve a disagreement between Root CNAs, contacts the Program Root CNA at and asks for arbitration of the appeal
The Program Root CNA sets expectations for when a timely resolution may be available; appeals of time-sensitive issues are prioritized, as determined by the Program Root CNA
The Program Root CNA contacts the appropriate entities to collect information relevant to the issue. The CNAs involved in the dispute provide documentation per the rules established in the CNA Rules. The Program Root CNA may also engage the CVE Board for their consideration of the issue
The Program Root CNA communicates its decision to all relevant parties once the disagreement or appeal has been fully considered; this result is final