On today’s Board call, it was discussed WGs need assure the Board is aware of what they are doing and decisions they are making. WG decisions need to be brought back to the Board in the form of recommendations
for the Board to decide on. Real decisions need to be made on the Board list. It was discussed WGs should provide a report-out to the CVE Board list assuring any decisions made are clearly identified as recommendations. The Board will then have an opportunity,
for a specified period of time, to review the recommendations. If Board members have issues or questions, they are expected to ask for clarification and have the discussions needed to assure consensus one way or another. In many cases, there may be no need
for clarification or discussions. In that case, if the specified period of time passes, the recommendation(s) are considered approved. Silence begets acceptance...

It is hoped this approach will be more efficient and less intrusive than voting on each individual WG recommendation. The above approach was agreed to by the Board members on the call and the WG Chairs for
the exiting CVE WGs.

What follows are the recommendations from the January 4th Strategy WG meeting.

Proposed Recommendations:

1.The Board move forward in proposing JPCERT/CC becomes a Root CNA, as a peer to DWF.

2.The Board begins the discussions needed to address supporting the localization of other languages in CVE.

3.The Board encourages MITRE to continue working to find and identify CVEs until all CVEs, ever officially issued, are in the CVE corpus.

6. The Board encourage MITRE to determine what it will take to support additional devices, firmware and software not traditionally supported. Additionally, the Board needs to encourage MITRE to make
the intentions of CVE to expand to support hardware, firmware and software official on their web site.

Please see the attached slides for additional background. The Topics slide explains what was discussed and has the following in the notes section as well.

Attendees: Kent, Art, Scott, Chris, Dan, Harold B.

All the recommendations to the Board below are based on the WG members in attendance on the call.

International expansion of CVE

·A second root CNA.

Agreed discussions with JPCERT/CC to be a Root CNA should move forward. It will be beneficial to have two Root CNAs developing procedures to manage their specific needs. A message
to Taki needs to be sent to setup a time to have an initial discussion on the topic. MITRE and interested Board members will be included on the call.

Recommendation: The Board move forward in proposing JPCERT/CC becomes a Root CNA, as a peer to DWF.

·CVE internationalized

CVE syntax parsing code should support Unicode, not simply ASCII. It was agreed this needs to be done but... This will need to be considered appropriately in much the same manner as
the syntax change was. This will potentially affect existing software in the community and in vendor products so it should be properly planned and communicated. This will not be a short term effort and should be taken quite seriously due to its potential impacts.
We need to have a discussion with JPCERT/CC on potential pitfalls and ideas for making this transition easier.

Recommendation: The Board begins the discussions needed to address supporting the localization of other languages in CVE.

As CVE’s sponsor is encouraging the move to bring CVE to the international community, these two items seem to have support of the working group members and the sponsor.

CNAs need to have a means to centralize their issued CVEs

From a strategic perspective it was agreed we want all CVEs listed in the CVE corpus. This has not been the case in the past but this change was codified in the CNA Rules document.
CNAs are required to notify MITRE is a reasonably timely fashion when they issue CVEs. New CNAs are doing so while there are a few legacy CNAs that still have not. MITRE is working to identify historically issued CVEs not currently in the corpus and are reaching
out to the individual CNAs to get the needed information so as to include them. This will take time.

Recommendation: The Board encourages MITRE to continue this work until all CVEs, ever officially issued, are in the CVE corpus.

There was discussion of a CNA report card sort of summary. This would list things such as CVEs reserved, CVEs published, timing of CVE reporting to MITRE, quality of the data, etc.
Just an initial thought at this point. The intent is not to poke CNAs but to show them how they compare with their peers in order to encourage them to do better where needed. It was discussed this should not be posted to a publically archived mailing list
but would be posted to the Handshake CNA Group instead since Handshake is a private community.

MITRE recognizes the need to establish and execute a CVE marketing plan. The plan has not been developed and MITRE would like the Board’s and WG’s participation in making that real.
All on the call agreed it was needed but more discussions around what it would consist of and the funding needed to execute, it need to be had.

Recommendation: The Board supports and assists MITRE in developing a global marketing plan for outreach to nations, technology sectors and emerging technologies.

Adding support for more than just software

Today there is no mention of supporting emerging devices, firmware and non-IT software on the MITRE CVE web pages. It is important CVE be able to support the identification of vulnerabilities
in firmware and hardware devices as well. This is a discussion / decision the Board must have / make. If the decision is made to support the expansion of CVE, then MITRE should change the web site to reflect the directional change. It was also stated and
agreed to that we should not limit the hardware CVE would be supporting. Things are moving very fast and putting limitations on categories of hardware would not help anyone.

Recommendation: The Board encourage MITRE to determine what it will take to support additional devices, firmware and software not traditionally supported. Additionally, the
Board needs to encourage MITRE to make the intentions of CVE to expand to support hardware, firmware and software official on their web site.

General items of note:

·MITRE gave some interesting statistics about CVE in 2016 but will leave it to them to officially announce to the Board.

·Discussions that decisions should not be made on WG calls or even on Board calls without giving the full Board the opportunity to respond on the mailing list. With more international members becoming
a part of the Board, it is important we give all an opportunity to actively participate regardless of their time zone. This is why you are seeing WG recommendations listed in the topics above.

·Need to discuss alternate times for WG and Board calls so international participants have the opportunity to attend.

While this set of notes reflects the conversations and deliberations of the working group, it is not our intent to circumvent the Board but to inform the Board as to what is recommended. WGs may
from time to time make internal working decisions for the group but they need to bring those decisions back to the Board in the form of recommendations for the Board to actively decide on. Real decisions should be made on the Board list – as was discussed
during the call – but today we have a heavy process of decision making. It seems we need a much more lightweight version of voting to assure all have time for input and we accurately understand the consensus of the group. I personally do not want to be voting
every week because a working group has a decision that needs to be made. I will leave the idea open to the group to weigh in on but note the Charter states;

Working groups are advisory in nature and established to effectively address specific issues in depth and in a forum better suited to that focus than the regular
Board meetings. Non-Board members may participate in working groups as required with prior notification sent to the Board indicating their participation. Working groups may be organized as required to meet the objectives of the group. Working groups must
have documented objectives and outcomes. Group progress must be reported back to the Board on an ad hoc or routine basis, either through the Board meetings or through the Board email lists as appropriate.

Thoughts on the proper way to address decisions made by the individual working groups would be appreciated.