...
Term | Definition |
Embargo | A time period where |
Subject matter expertMatter Expert (SME) | A developer or other specialist who can provide contextual information that helps to determine the validity and impact of a potential security vulnerability. |
Security SME | A security SME is a specialist who is familiar with the ONAP security vulnerability procedures and security in general. |
Peer reviewed | In the context of a patch, the term peer reviewed refers to the patch having been reviewed by the ONAP vulnerability sub-committee and any other relevant key stakeholders. There is not yet a strict definition of the number of people who need to have reviewed the patch, or how they provide sign off. |
...
The ONAP vulnerability management subcommittee (VMS) is responsible for coordinating vulnerabilities during its whole life cycle (from reporting till coordinated disclosure)the response to a reported vulnerability from initial reporting until coordinated disclosure.
Members of the team are independent and security-minded folks people who ensure that vulnerabilities are dealt with in a timely manner and that downstream stakeholders are notified in a coordinated and fair manner. Where a member of the team is employed by a downstream stakeholder, the member does not give their employer prior notice of any vulnerabilities. In order to reduce the disclosure of a vulnerability in the early stages, membership of this team is intentionally limited to a small number of people.
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 serving 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.
...
/Should be checked with tsc/
As ONAP is very young project with a lot of code coming in every release. That's why for now we support will develop patches for ONLY THE LATEST RELEASE and MASTER BRANCH (next version under development) .
...
Vulnerabilities of managed functions (e.g. VNFs) are out of the scope of ONAP, however if a an ONAP vulnerability has a dependence with a managed function, the managed functions vulnerability procedures will be used to coordinate the issue.
...
Steps that has to be completed depend on reception method:
Reception via Jira Ticket
Edit the ticket description by adding embargo notice in the beginning
- Add "Uncategorised" label to the ticket
- Confirm bug reception by assigning the task to one of VMS members and adding a reception confirmation comment.
Reception via email
- Create new Jira ticket and post embargo notice and the content of original message re-encrypted with public keys of other VMS members.
- Assign the task to one of VMS members (capable of decrypting the bug content)
- Add "Uncategorised" label to the ticket
- Send a signed reception confirmation email (pay attention to not DO NOT include the original message in plain text).
Reception via Jira Ticket
Edit the ticket description by adding embargo notice in the beginning
- Add "Uncategorised" label to the ticket
- 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 noting that every new bug in the Vulnerability Reporting Jira Project by default is visible only to reporter and VMS members.
...
The bug must then be confirmed to be a security problem and assigned initial severity level. This may require the inclusion of a additional subject matter expert 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 why; the .Tthe bug should then be opened and fixed by following the normal development process.
...
- Identify affected projects and versions
- Update bug description with data mentioned above
- Perform initial severity assessment.
- Label task with a suitable severity level and add impact description
- Add PTL or security responsible person of affected project to the bug
Extra steps for critical vulnerabilities
- Extreme caution would be is necessary while handling this bug.
- If the bug has been reported via encrypted email, no plain text communication should be used
- Secure communication channel with PTL or project security contact point should be established (GPG, zoom with e2e encryption enabled etc)
...
- PTL or project security contact point should be delivered with receive bug details to confirm initial severity
- Severity level should be fixed:
- If PTL or project security contact point agrees with initially assigned severity a "Severity-confirmed" label should be added to the task.
- If PTL or project security contact point disagrees with initially assigned assignment, a clear justification should be provided, severity level updated and "Severity-confirmed" added to the task.
- If a bug has been received via email the triage confirmation email should be sent to the reporter.
...
- 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
- It's up to After public discussion, it will be determined if resources should be assigned for this task.
...
- If bug has been classified as a non-security the ticket should be made publicly visible
- 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. That's why Thus, the PTL should explicitly request access for additional developers by adding a comment with their Jira idtheir LFID.
A fix should be prepared against current master branch and other affected branches and attached to the ticket. Do not sent it to the public code review system (gerrit) unless the ticket is already public.
Security fixes, especially critical should be treated as highest-priority tasks. If project -side 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
- Review the fixGet the
- fix pre-approved by PTL and committers pre-approve fix
Draft Vulnerability description
In the mean timeWhile 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.
...
In the required section set the checkboxes check boxes indicating the product is not CNA-covered and that no prior CVE ID has been assigned, select an appropriate vulnerability type (using Other or Unknown to enter a freeform free form type if there is nothing relevant on the drop-down), set the vendor to ONAP, and the product and version fields to match the affected project name and version from the impact description. In the optional section set the radio button for confirmed/acknowledged to Yes, choose an appropriate attack type in the drop-down (often this is Context-dependent for our cases), check the relevant impact checkboxes, attempt to fill in the affected components and attack vector fields if possible, paste in the suggested description from the prose of the impact description (usually omitting the first sentence as it’s redundant with other fields), put the $CREDIT details in the discoverer/credits field, and the bug URL (along with Gerrit URLs for patches if already public) in the references field. If the report is still private, note that in the additional information field like This report is currently under embargo and no disclosure date has been scheduled at this time.
...
Steps to be completed
- Request CVE number from MITRE
Get assigned CVE
MITRE returns the assigned CVE. It is added to the jira ticket, and the bug is retitled to “$TITLE ($CVE)”.
...
- Receive the assigned CVE number
- Add received CVE number to the Jira ticket
- Retitle Re-title the ticket to “$TITLE ($CVE)”
...
There will be occasions where the vulnerability management process is not follow 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 sent 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.
...