NOTICE

...

...

Glossary

...

Credits

This document is strongly based on Vulnerability Management Process defined by Open Stack Community.

...

• The Linux Kernel process for reporting security issues
• The  OpenDaylight vulnerability management process
• Recommendations for a minimal security response process
• The fd.io vulnerability management process

Vulnerability Management Process Overview

Image Added

Vulnerability Management Process

The ONAP vulnerability management subcommittee (VMS) is responsible for coordinating the response to a reported vulnerability from initial reporting until coordinated disclosure.

...

This activity is approved and supported by the ONAP TSC and operates under the ONAP vulnerability sub-committee. The sub-committee functions are as described below. The committee has a chair, appointed by the membership from among the membership, who is responsible for seeing that work proceeds and serves as a point of contact for the TSC and community to the vulnerability sub-committee. The chair and membership, as well as pointers to this charter and the relevant email lists are document at link-to-page.

Supported projects and versions

All ONAP projects are currently in scope for vulnerability support. The participants of the ONAP projects are expected to support the ONAP vulnerability procedures when required.

As ONAP is very young project with a lot of code coming in every release. Even through we are interested in receiving bugs for all ONAP releases that are currently in use, we will develop patches  ONLY FOR THE LATEST RELEASE and FOR THE MASTER BRANCH (next version under development) . Unfortunately ensuring security in very early stages of the project is not always possible, that is why we declare three first releases (Amsterdam, Beijing, Casablanca) as unsupported in terms of security bug fixes. Dublin is going to be first version that will be supported as described by above rule.

Third party components

Third party components (i.e. dependencies) are only in scope for security support if they are statically compiled or otherwise bundled by an ONAP project. Dynamically linked dependencies should patch security issues independent of ONAP.

Dependencies on managed functions (eg. VNFs)

Vulnerabilities of managed functions (e.g. VNFs) are out of the scope of ONAP, however if an ONAP vulnerability has a dependence with a managed function, the managed functions vulnerability procedures will be used to coordinate the issue.

The Process

Notice

All the tasks mentioned below should be executed by VMS coordinator who is chosen and assigned by VMS based on their internal agreements on case by case basis.

Overview

Reception

A report can be received either as a ticket in Vulnerability Reporting Jira Project/Insert link when created/, , email to onap-security@lists.onap.org or as a private encrypted email to one of the VMS members /Insert a link to a suitable page/ .

Steps that has to be completed depend on reception method:

Reception via Jira Ticket

1. Edit the ticket description by adding embargo notice in the beginning (VMS team)

2. Add "Uncategorised" label to the ticket (VMS team)
3. Confirm bug reception by assigning the task to one of VMS members and adding a reception confirmation comment. (VMS team)

Reception via email

1. Create new Jira ticket and post embargo notice and the content of original message re-encrypted with public keys of other VMS members. (email recipient)
2. Add "Uncategorised" label to the ticket (email recipient)
3. Assign the task to one of VMS members (capable of decrypting the bug content) (email recipient)
4. Send a PGP signed reception confirmation email (DO NOT include the original message in plain text). (email recipient)

...

It's worth noting that every new bug in the Vulnerability Reporting Jira Project by default is visible only to reporter and VMS members.

Triage

The bug must then be confirmed to be a security problem and assigned initial severity level. This may require the inclusion of additional subject matter experts to determine if the problem needs to be treated as a security flaw. If the bug is determined not be a security issue then a statement should be added indicating the justification. The bug should then be opened and fixed by following the normal development process.

Steps to be completed

1. Identify affected projects and versions
2. Update bug description with data mentioned above
3. Perform initial severity assessment
4. Label task with a suitable severity level and add impact description
5. Add PTL or security responsible person of affected project to the bug

Extra steps for critical vulnerabilities

1. Extreme caution is necessary while handling this bug.
2. If the bug has been reported via encrypted email, no plain text communication should be used
3. Secure communication channel with PTL or project security contact point should be established (GPG, zoom with e2e encryption enabled etc)

All Vulnerabilities

1. PTL or project security contact point should receive bug details to confirm initial severity
2. Severity level should be fixed:
   1. If PTL or project security contact point agrees with initially assigned severity a "Severity-confirmed" label should be added to the task.
   2. If PTL or project security contact point disagrees with initially assignment, a clear justification should be provided, severity level updated and "Severity-confirmed" added to the task.
3. If a bug has been received via email the triage confirmation email should be sent to the reporter.

Hardening opportunities

1. If received ticket is not a security bug which can be fix with a patch of reasonable size but a good hardening idea, the ticket visibility should be set to public and "Hardening" label should be added
2. After public discussion, it will be determined if resources should be assigned for this task.

Non-Security bugs

1. If bug has been classified as a non-security, the ticket should be made publicly visible
2. PTL of impacted project is responsible for further handling of this bug

Patch development

The PTL or project security contact point is responsible for fixing the bug or delegating the work to the subject matter experts. Even through patch development can be delegated by PTL or project security contact, only the VMS has a right to add new people to the ticket. Thus, the PTL should explicitly request access for additional developers by adding a comment with their LFID.

...

Security fixes, especially critical should be treated as highest-priority tasks. If project delays are encountered at this or any subsequent stage of the process, the VMS and other interested parties may escalate the issue to the TSC but without providing any details on bug itself apart from reporter, severity, impacted project and versions.

Steps to be completed

1. Develop the fix (PTL or delegate)
2. Do not sent it to the public code review system (gerrit) unless the ticket is already public.

Patch review

Once the patch has been attached to the ticket, patch should be reviewed and pre-approved by PTL or delegated committers. Privately-developed patches need to be pre-approved so that they can be fast-tracked through public code review later at disclosure time.

For public reports, usual public code review process apply.

Steps to be completed

1. Review the fix (PTL and committers)
2. Pre-approve fix by providing a comment to the ticket "Acked-by: Name Surname <email@domain.tld>" (PTL, committers and VMS coordinator)
3. When all required approval are collected, commit message should be updated and  comments from the previous step should be added to the commit message (VMS coordinator)

Draft Vulnerability description

While the patch is being developed, the VMS coordinator prepares a vulnerability description that will be communicated to downstream stakeholders, and will serve as the basis for the Security Advisory that will be finally published.

The description should properly credit the reporter, specify affected versions (including unsupported ones) and accurately describe impact and mitigation mechanisms. The VMS coordinator should use the template below.

Steps to be completed

1. Prepare draft of vulnerability description
   

Review impact description

The description is validated by the reporter and the PTL.

Steps to be completed

1. Review the draft of vulnerability description(PTL and commiters)

Send CVE request

If reporter did not request for a CVE number on his or her own, VMS coordinator should attempt to obtain one to ensure full traceability. This is generally done as the patch gets nearer to final approval. The approved impact description is submitted through MITRE’s CVE Request form. The request type is Request a CVE ID, the e-mail address should be that of the requester, and for critical reports the coordinator’s OpenPGP key should be pasted into the field provided.

...

At the bottom of the page, fill in the security code and click the submit request button. If some fields contain invalid data they will be highlighted red; correct these, update the security code and submit request again until you get a confirmation page.

Steps to be completed

1. Request CVE number from MITRE
   

Get assigned CVE

MITRE returns the assigned CVE. VMS coordinator adds it to the jira ticket, and retitles the bug to “$TITLE ($CVE)”.

Steps to be completed

1. Receive the assigned CVE number
2. Add received CVE number to the Jira ticket
3. Re-title the ticket to “$TITLE ($CVE)”

Embargoed disclosure

Once the patches are approved and the CVE is assigned, a signed email with the vulnerability description is sent to the downstream stakeholders by VMS coordinator or other designated VMS member. The disclosure date is set to 3-5 business days, excluding Monday/Friday and holiday periods, at 1400 UTC. No stakeholder is supposed to deploy public patches before disclosure date.

For non-embargoed, public vulnerabilities no separate downstream advance notification is sent.

Steps to be completed

1. Set up disclosure date with the reporter, PTL and required committers.
2. Add note about planned disclosure date to the ticket
3. Send a PGP signed email with vulnerability description to downstream stakeholders.

Coordinated disclosure

In preparation for this, make sure you have a PTL available to help pushing the fix at disclosure time.

...

MITRE’s CVE Request form should be used again at this point, but instead select a request type of Notify CVE about a publication and fill in the coordinator’s e-mail address, provide a link to the advisory (the URL to official OSA), the CVE IDs covered, and the date published. Once more, fill in the security code at the bottom of the page and submit request.

Steps to be completed

1. Ensure that PTL and committers are available
2. On the disclosure hour:
   1. Remove embargo notice from ticket description
   2. Open the ticket to public
   3. Push attached patches for review on master
   4. Notify PTL and committers that patch is ready to be merged
3. Publish ONAP security advisory
4. Update the ticket title to “[OSA-$NUM] $TITLE”
5. Sent notification to MITRE about a publication

Handling public/leaked security issues

What is considered public?

• Any comment on a public forum, whether it be a mailing list, irc, twitter, or news group, that discloses the details of the flaw.
• Any commit or review comment that indicates that the change may be security related.

Public security issue workflow

There will be occasions where the vulnerability management process is not followed and the issue is publicly disclosed before reporting it to the vulnerability subcommittee. In this case it's important to properly identify the issue and create a task to make it traceable. As the flaw has been already disclosed there is no need to keep the Jira ticket private so it should be set to publicly available in a very beginning of the process. In general, standard vulnerability management process should be followed, just embargoed disclosure should be skipped.

Steps to be executed:

1. Create ticket with issue description in Vulnerability Reporting Jira Project (VMS members)
2. Make the ticket publicly visible (VMS members)
3. Assign the bug to one of VMS members
4. Perform bug triage and CVE request if necessary (VMS coordinator)
5. Send email containing triage results to ONAP TSC Chair and LFN representative (Kenny Paul and Jim Baker) 
6. Rest of standard process should be followed, skipping embargoed disclosure step
   

Leaked security issue workflow

Occasionally it may happen that the bug reporter or some else break the embargo and disclose details of the flaw before official disclosure date. In this case a timely answer is extremely important.

Steps to be executed:

1. Make the related ticket publicly visible
2. If a patch has been already proposed push it immediately to gerrit
3. Skip embargoed disclosure.
4. Send email confirming that issue has been leaked to ONAP TSC Chair and LFN representative (Kenny Paul and Jim Baker)
5. Rest of standard process should be followed and finished as soon as possible.
   

Roadmap

Action Items

...

Topic

...

Assignee

...

...

Status

References

1. Common Vulnerabilities and Exposure (https://cve.mitre.org/about/faqs.html )
2. CVE  numbering authorities (https://cve.mitre.org/cve/cna.html)
3. CVE FAQ (https://cve.mitre.org/about/faqs.html#what_is_cve_identifier )

...