...

<<This is a page to fill out the draft ONAP vulnerability management procedures.  It will remain draft until it is approved>>

Draft ONAP Vulnerability Management

<<This is a page to fill out the draft ONAP vulnerability management procedures. It will remain draft until it is approved>>

ONAP Vulnerability Management

Glossary

Security Response Procedure

...

In an attempt to avoid re-inventing the wheel, the ONAP vulnerability management process borrows from the following procedures:

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

Operating Structure

This activity, while not a formal project, 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 as a point of contact for the TSC and community to the security response teamsub-committee. The chair and membership, as well as pointers to this charter and the relevant email lists are document at link-to-page.

...

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

Security supported versions

All versions of ONAP still supported by the project, and affected by the security issue, must be patched. This will usually start with the latest version of an affected project. Following that, the security team vulnerability sub-committee will work with downstream maintainers to ensure that the patch is applied to all maintained and affected versions.

Note: The security team ONAP vulnerability sub-committee needs to provide accurate information about the version the flaw was first introduced so that vendors operating still maintaining older product lines can backport fixes outside of the upstream maintenance window.

...

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 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

...

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

The ONAP vulnerability management team 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 management team sub-committee needs to complete the following tasks.

...

• Original Reporter
• ONAP vulnerability management Teamsub-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

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.

...

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

...

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

...

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

...

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 management Teamsub-committee
• Subject Matter Expert (optional)

...

1. Send CVE request email to NIST/NVD      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.

...

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

...

• 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 security team 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 CWE CVE for      this flaw
• Write an automated reproducer of the      flaw and add it to the regression tests
• Write an a static analysis / lint rule      to detect the pattern that lead to the flaw

...

• 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.

...

Upon reception of a security report the ONAP vulnerability management team sub-committee needs to clearly indicate the expectation of how the issue will be handled.

...

Thank you for reporting a security issue to the ONAP securityvulnerability teamsub-committee. We have created a private security issue in JIRA to track this issue. 
Please provide us with your JIRA username so we can add you to the issue. 
All communications and decisions about how this issue will be handled will be recorded on this issue to provide proper tracking.

...

 Thanks

 { onap_vulnerability_management_team sub-committee _member}, on behalf of the ONAP vulnerability management teamsub-committee

Confirmed private security issues

Clear instructions need to be provided to all parties involved with the fix as to how the issue needs to be fixed. When the flaw is confirmed, the following statement should be added to the bug by a member of the security teamONAP vulnerability sub-committee.

 #security-status: confirmed

This issue has been confirmed as a security vulnerability in { project } and is to be fixed under the ONAP ONAPembargoedembargoed security vulnerability process. 
Please do not discuss or disclose details about this flaw prior to the agreed disclosure date (TBA). 
All decisions, discussions, and proposed patches and reviews are to be done via this tracking issue only.

...

 #security-status: confirmed-leaked

This issue has been confirmed as a security vulnerability in { project }. Unfortunately the details of this flaw have been made public { reference_to_leak }. 
Therefore it cannot be fixed under the ONAP embargoed security vulnerability process. 
As this issue is now public it is important that the flaw is addressed in a timely manner. The ONAP vulnerability managementsub-committee team will ensure that a CVE is assigned for this issue.

...

 #security-status: confirmed-public

 This issue has been confirmed as a security vulnerability in { project }. 
As this issue was originally a public report it cannot be fixed under the ONAP embargoed security vulnerability process. 
As this issue is public it is important that the flaw is addressed in a timely manner. The ONAP vulnerability managementsub-committee team will ensure that a CVE is assigned for this issue.

Risk Assessment

The ONAP vulnerability management team sub-committee should provide a judgement judgment 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.
• High: 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 high 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.

Description Description: The description must endeavor to accurately depict the nature of the flaw. Information that should be included must indicate the attack vector that is exposed by the flaw and the initial access level required by the attacker. Where applicable advice on how an operator may audit for abuse of the flaw within their environment.

...

To ensure proper traceability a CVE identifier needs to be requested from a CNA. An email requesting a CVE should be sent to either cve-assign@mitre.org or secalert@redhat.com.

 AA vulnerability was discovered in { project }, part of the ONAP project (see below). In order to ensure full traceability, we need a CVE number assigned that we can attach to private and public notifications. Please treat the following information as confidential until further public disclosure. 

 { impact_description } 

 Thanks

 {onap_vulnerability_teamsub-commitee_member}, on half of the ONAP vulnerability management teamsub-committee

Roadmap

Action Items

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 )