...

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

Vulnerability Management Workflow

...

The Process

Overview

Reception

A public page must be made available detailing the ONAP vulnerability procedures, and providing a single point of contact for contacting the ONAP vulnerability sub-committee. This should be a private email list (onap-security@lists.onap.org) that only members of the ONAP vulnerability sub-committee have access to.

The ONAP vulnerability sub-committee as well as the developers should also monitor development mailing lists and bug creation feeds to ensure that there are no issues that have been publicly reported which need to be treated as a security flaw. Should such a situation exist the public security issue workflow needs to be followed.

Upon receiving a privately reported security issue the ONAP vulnerability sub-committee needs to complete the following tasks.

Extent of disclosure:

• Original Reporter
• ONAP vulnerability sub-committee

Next Steps:

1. Send reception confirmation email
2. Create private security bug
3. Add reporter to private security bug
4. Add project security contact to help triage the flaw

Triage

report can be received either as a ticket in Vulnerability Reporting Jira Project /Insert link when created/, 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 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.
2. Assign the task to one of VMS members (capable of decrypting the bug content)
3. Add "Uncategorised" label to the ticket
4. Send a signed reception confirmation email (pay attention to not include the original message in plain text).

Reception via Jira Ticket

1. Edit the ticket description by adding embargo notice in the beginning

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

VMS should do its best to provide a prompt confirmation to the reporter. Bug reception should be confirmed no later than within 3 business days.

It's worth to notice that every new bug in 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 The bug must then be confirmed to be a security problem. This may require the inclusion of a subject matter expert 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 why; the bug should then be opened and fixed by following the normal development process.

Should all parties agree that the issue is a security flaw then all parties need to work on determining the affected code, assessing the risk to users, and proposing a fix to the flaw. All of this work must be done under embargo. Proposed fixes must not be committed to Source Code Management (SCM), and the problem should not be discussed outside of those that have been added to the bug.

Extent of disclosure:

• Original Reporter
• ONAP vulnerability sub-committee
• Subject matter expert (optional)

Next Steps (status: confirmed):

1. Post the confirmed security issue notification in the bug
2. Determine which versions of the project are affected by the flaw
3. Draft an impact description
4. Confirm whether the original reporter wants to be credited for finding the flaw
5. Propose a fix / patch for the flaw
6. Get the patch peer reviewed

Next Steps (status: non-security):

1. Post a statement for non-security issues in the bug
2. Change the bugs security status from private to public
3. Follow the normal development process to get the issue fixed if necessary

Pre-disclosure

When a patch has been developed and peer reviewed, by a subject matter expert, it is then possible to start planning on how and when to announce the issue. This involves agreeing on a disclosure date. Extent of Disclosure:

• Original Reporter
• ONAP vulnerability sub-committee
• Subject Matter Expert (optional)

Next Steps:

1. Send CVE request email to NIST/NVD  (TBD)
2. Agree on disclosure date with original reporter. This will most likely need to fall on a Tuesday,  Wednesday, or a Thursday. Ensure a developer is available at that time to push up the fix.
3. Re-test the patch. Ensure that it still applies to the various branches and that all unit tests pass.

Disclosure date

When the coordinated disclosure date has been reached the assigned member from the ONAP vulnerability sub-committee must perform the following tasks.

Extent of Disclosure:

• Everybody. The issue will now be public.

Next steps:

1. Re-test the patch and make sure all unit tests pass.
2. Open the bug to the public
3. Coordinate the submission of the patch. The fix should be fast tracked as it has already been peer reviewed.
4. Create an advisory
5. When the commit has been merged into the code an announcement must be sent individually to the following mailing lists:, ,      TBD

.

Post-disclosure

Post disclosure the standard development process applies. Some optional additional tasks that the ONAP vulnerability sub-committee could undertake, or coordinate with the projects, would be:

• Convert the advisory publication to CVRF format and publish on a separate CVE stream
• Calculate the CVSS2 score for the flaw
• Determine the appropriate CVE for this flaw
• Write an automated reproducer of the flaw and add it to the regression tests
• Write a static analysis / lint rule to detect the pattern that lead to the flaw

Handling public 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 workflow process is either not followed, or at some stage a party leaks the details of the flaw. In these cases a different workflow is applicable, as there is no longer any need to maintain an embargo. The private security issue workflow can be followed from the "Disclosure date" step onwards.

...

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 would be 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 be delivered with 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 assigned 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.

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

The security team should provide a judgement call for the severity of the issue for the most common use case of the project. Suggested impact rating categories:

• Critical: This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.
• Important: This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service.
• Moderate: This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
• Low: This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.

Note: Formal methods such as CVSS may follow.

Workflow for private security issues

Triage

The bug must then be confirmed to be a security problem. This may require the inclusion of a subject matter expert 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 why; the bug should then be opened and fixed by following the normal development process.

Should all parties agree that the issue is a security flaw then all parties need to work on determining the affected code, assessing the risk to users, and proposing a fix to the flaw. All of this work must be done under embargo. Proposed fixes must not be committed to Source Code Management (SCM), and the problem should not be discussed outside of those that have been added to the bug.

Extent of disclosure:

• Original Reporter
• ONAP vulnerability sub-committee
• Subject matter expert (optional)

Next Steps (status: confirmed):

1. Post the confirmed security issue notification in the bug
2. Determine which versions of the project are affected by the flaw
3. Draft an impact description
4. Confirm whether the original reporter wants to be credited for finding the flaw
5. Propose a fix / patch for the flaw
6. Get the patch peer reviewed

Next Steps (status: non-security):

1. Post a statement for non-security issues in the bug
2. Change the bugs security status from private to public
3. Follow the normal development process to get the issue fixed if necessary

Pre-disclosure

When a patch has been developed and peer reviewed, by a subject matter expert, it is then possible to start planning on how and when to announce the issue. This involves agreeing on a disclosure date. Extent of Disclosure:

• Original Reporter
• ONAP vulnerability sub-committee
• Subject Matter Expert (optional)

Next Steps:

1. Send CVE request email to NIST/NVD  (TBD)
2. Agree on disclosure date with original reporter. This will most likely need to fall on a Tuesday,  Wednesday, or a Thursday. Ensure a developer is available at that time to push up the fix.
3. Re-test the patch. Ensure that it still applies to the various branches and that all unit tests pass.

Disclosure date

When the coordinated disclosure date has been reached the assigned member from the ONAP vulnerability sub-committee must perform the following tasks.

Extent of Disclosure:

• Everybody. The issue will now be public.

Next steps:

1. Re-test the patch and make sure all unit tests pass.
2. Open the bug to the public
3. Coordinate the submission of the patch. The fix should be fast tracked as it has already been peer reviewed.
4. Create an advisory
5. When the commit has been merged into the code an announcement must be sent individually to the following mailing lists:, ,      TBD

.

Post-disclosure

Post disclosure the standard development process applies. Some optional additional tasks that the ONAP vulnerability sub-committee could undertake, or coordinate with the projects, would be:

• Convert the advisory publication to CVRF format and publish on a separate CVE stream
• Calculate the CVSS2 score for the flaw
• Determine the appropriate CVE for this flaw
• Write an automated reproducer of the flaw and add it to the regression tests
• Write a static analysis / lint rule to detect the pattern that lead to the flaw

Handling public 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 workflow process is either not followed, or at some stage a party leaks the details of the flaw. In these cases a different workflow is applicable, as there is no longer any need to maintain an embargo. The private security issue workflow can be followed from the "Disclosure date" step onwards.

Communication

Embargo notice

This issue is being treated as a potential security risk under embargo.

Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the ONAP Vulnerability Subcommittee in the form of an official ONAP Security Advisory.

This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems, jira and wiki.

Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication.

All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.

Reception confirmation email

...