View source for TSC:Vulnerability Management

= fd.io - Vulnerability Management =

== WORK IN PROGRESS ==

This is a draft document that is still a work in progress. It has NOT been approved by the TSC, and does not reflect implemented policy or process.

== Glossary ==

{| class="wikitable"
|-
! Term !! Definition
|-
| Embargo || A time period where vendors have access to details concerning the security vulnerability, with an understanding not to publish these details or the fixes they have prepared. The embargo ends with a coordinated release date ("CRD"). (from [https://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/ source])
|-
| Subject matter expert || A developer or other specialist who can provide contextual information that helps to determine the validity and impact of a potential security vulnerability. 
|
|-
| Peer reviewed || In the context of a patch, the term peer reviewed refers to the patch having been reviewed by the security response team 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.
|
|}

== Motivation ==

The fd.io project has gained enough momentum and popularity that the responsible management of security issues in the upstream community is warranted.

== Proposed Security Response Procedure ==

=== Reference procedures ===

In an attempt to avoid re-inventing the wheel, the fd.io vulnerability management process borrows from the following procedures:
*[https://www.kernel.org/doc/Documentation/SecurityBugs The Linux Kernel process for reporting security issues]
*[https://wiki.opendaylight.org/view/TSC:Vulnerability_Management The OpenDaylight vulnerability management process]
*[https://securityblog.redhat.com/2013/01/30/a-minimal-security-response-process/ Recommendations for a minimal security response process]

=== Security supported projects ===

All fd.io projects are currently in scope for security support.

=== Security supported versions ===

The latest version of an affected project is in scope to receive security paches. Backporting to older versions is the responsibility of downstream maintainers.

:'''Note''': The security team 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 ===

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

== Vulnerability Management Workflow ==

=== Workflow for private security issues ===

==== Reception ====

A public page must be made available detailing the fd.io vulnerability management process, and providing a single point of contact for contacting the security team. Preferably this should be a private email list that only members of the fd.io security team have access to. TODO: is GPG in scope? I am not convinced it is critical.

The fd.io security team 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 fd.io security team needs to complete the following tasks.

'''Extent of disclosure:'''

* Original Reporter
* fd.io Security Team

'''Next Steps:'''

# Send ''reception confirmation email''
# Create private security bug
# Add reporter to private security bug
# 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 [[#glossary|embargo]]. Proposed fixes must not be committed to SCM, and the problem should not be discussed outside of those that have been added to the bug. 

'''Extent of disclosure:'''

* Original Reporter
* fd.io Security Team
* Subject matter expert (optional)

'''Next Steps (status: confirmed):'''

#Post the ''confirmed security issue'' notification in the bug
#Determine which versions of the project are affected by the flaw
#Draft an impact description
#Confirm that the original reporter wants to be credited for finding the flaw
#Propose a fix / patch for the flaw
#Get the patch peer reviewed

'''Next Steps (status: non-security):'''

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

==== Pre-disclosure ====

When a patch has been developed and peer reviewed 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
*fd.io Security Team
*Subject Matter Expert (optional)

'''Next Steps:'''

#Send CVE ''request email'' to TODO: who? both MITRE and Red Hat?
#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.
#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 fd.io security team must perform the following tasks.

'''Extent of Disclosure:'''

*Everybody. The issue will now be public.

'''Next steps:'''

# Re-test the patch and make sure all unit tests pass.
# Open the bug to the public
# Coordinate the submission of the patch. The fix should be fast tracked as it has already been peer reviewed.
# Create an advisory
# When the commit has been merged into the code an announcement must be sent individually to the following mailing lists: oss-security@lists.openwall.com, discuss@lists.fd.io, TODO: can we create a specific security-announce list?
.

==== Post-disclosure ====

Post disclosure the standard development process applies. Some optional additional tasks that the security team could undertake 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 for this flaw
*Write an automated reproducer of the flaw and add it to the regression tests
*Write an 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 ===

==== Reception confirmation email ====

Upon reception of a security report the fd.io security team needs to clearly indicate the expectation of how the issue will be handled.

  Thankyou for reporting a security issue to the fd.io security team. 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.
  
  {jira_issue_url}
  
  Thanks
  {fdio_security_team_member}, on half of the fd.io security team

==== 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 team.

  #security-status: confirmed
  
  This issue has been confirmed as a security vulnerability in { project } and is to be fixed under the fd.io embargoed 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.

==== Confirmed public security issues ====

===== When an issue is leaked =====

  #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 fd.io embargoed security vulnerability process. As this issue is now public it is important that the flaw is addressed in a timely manner. The fd.io security team will ensure that a CVE is assigned for this issue.

===== When an issue was not reported privately =====

  #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 fd.io embargoed security vulnerability process. As this issue is public it is important that the flaw is addressed in a timely manner. The fd.io security team will ensure that a CVE is assigned for this issue.

===== Risk Assessment ===== 
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 [http://www.first.org/cvss CVSS] may follow.

Description : The description must endeavour 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.

==== CVE Request ====

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

  A vulnerability was discovered in { project }, part of the fd.io 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
  {fdio_security_team_member}, on half of the fd.io security team

== Roadmap ==

=== Action Items ===

{| class="wikitable"
|-
! Topic !! Assignee !! Description !! Status
|-
| organizational || unassigned || Send out a call for participation and form the security team ||
|-
| infrastructure || unassigned || Create a private mailing list for security team ||
|-
| infrastructure || unassigned || Enable private security issues in JIRA ||
|-
| infrastructure || unassigned || Create a public page indicating contact information for the security team. ||
|-
| documentation || unassigned || Create a public page detailing the vulnerability management process and how to report security problems to fd.io ||
|-
| documentation || unassigned || Create a single page listing the security issues fixed in fd.io projects (advisories) ||
|-
| communication || unassigned || Ensure the new security process is announced on all major mailing lists. ||
|}