::

  This work is licensed under a Creative Commons Attribution 3.0
  Unported License.
  http://creativecommons.org/licenses/by/3.0/legalcode

========================================
 Free and Open Vulnerability Management
========================================

Blank Slide
-----------
.. hidetitle::

Main Title
----------
.. transition:: tilt
   :duration: 2
.. hidetitle::
.. figlet:: Free and Open Vulnerability Management

Jeremy Stanley <fungi@yuggoth.org>

Goals
-----
.. transition:: pan
.. container:: progressive

  - receive potential vulnerability reports in confidence
  - assist in documenting and assessing impact and relative severity
  - help developers track and resolve vulnerabilities quickly
  - aid downstream distributors coordinating disclosure of fixes
  - get information into the hands of impacted users

Enablement
----------
.. transition:: pan
.. container:: progressive

  - stable maintenance process
  - project governance
  - defect tracker with configurable privacy and access controls
  - mailing lists, both community-specific and wider-reaching
  - separate security team

Tools
-----
.. transition:: pan
.. container:: progressive

  - detailed vulnerability management process
  - report taxonomy
  - templated communication
  - structured data for advisories

Public Process
--------------
.. transition:: pan
.. container:: progressive

  1. confirm impact and draft description
  2. help review proposed solutions for backport acceptability
  3. request CVE identifier(s)
  4. notify downstream stakeholders
  5. review and publish security advisory

Embargoed Process
-----------------
.. transition:: pan
.. container:: progressive

  1. receipt of suspected vulnerability report
  2. identify first-tier subject matter experts and make them aware
  3. confirm impact and draft description
  4. help review proposed solutions for backport acceptability
  5. request CVE identifier(s)
  6. schedule coordinated disclosure date and (approximate) time
  7. notify downstream stakeholders
  8. assist in pushing pre-approved fixes into public code review
  9. review and publish security advisory

Embargo Challenges
------------------
.. transition:: pan
.. container:: progressive

  - bugs across software handled by different teams
  - limited group of subscribers reduces the amount of review
  - testing performed manually in private
  - inefficiency of private coordination
  - delay accommodating advance notification to stakeholders

When not to Embargo
-------------------
.. transition:: pan
.. cowsay:: "It is now time for the security process to change and become more
	    open." "For the majority of lower severity issues [...] the cost of
	    embargoes really makes no sense." "Why not treat most security bugs
	    like normal bugs and get them fixed quickly and properly the first
            time around?"

( Kurt Seifried in https://access.redhat.com/blogs/766093/posts/1976653 )

Recommendations
---------------
.. transition:: pan
.. container:: progressive

  - have clear documentation on how and who to contact
  - follow a process and report taxonomy (feel free to reuse ours!)
  - publish advisories, perhaps to oss-security@lists.openwall.com
  - always credit people who report vulnerabilities to you
  - cryptographically sign your public communication
  - trade key signatures with prominent members of your community

Template Example (Impact Description)
-------------------------------------
.. transition:: pan
.. code::

  Title: $TITLE
  Reporter: $CREDIT
  Products: $PROJECT
  Affects: $AFFECTED_VERSIONS
  
  Description:
  $CREDIT reported a vulnerability in... By doing... a... may...
  resulting in... Only setups.... are affected.

Structured Data Example
-----------------------
.. transition:: pan
.. code:: yaml

  date: YYYY-MM-DD
  id: OSSA-YYYY-NNN
  title: Advisory title
  description: Impact description with full details goes in this space.
  affected-products:
    - product: affected software
      version: versions through X, and Y versions through Z
  vulnerabilities:
    - cve-id: CVE-YYYY-NNNN
  reporters:
    - name: Some reporter
      affiliation: Some organization
      reported:
        - CVE-YYYY-NNNN

Structured Data Example Continued
---------------------------------
.. transition:: pan
.. code:: yaml

  issues:
    links:
      - https://launchpad.net/bugs/NNNNNNN
    type: launchpad
  reviews:
    kilo:
      - https://review.openstack.org/NNNN
  notes:
    - This fix will be included in future V (crufty) and W (smarmy) releases.

Publication Pipeline
--------------------
.. transition:: pan
.. container:: progressive

  1. YAML (reviewable) http://yaml.org/
  2. rST (E-mailable) http://docutils.sourceforge.net/rst.html
  3. HTML (browseable) http://www.w3.org/html/

Thanks and Links
----------------
.. transition:: pan

- Other members of the OpenStack Vulnerability Management Team:

  - Tristan de Caqueray <tdecacqu@redhat.com>
  - Grant Murphy <grant.murphy@hp.com>
  - find us at https://security.openstack.org/

- OpenStack community: http://www.openstack.org/
- Proudly presented in presentty: http://pypi.python.org/pypi/presentty

Closing Slide
-------------
.. hidetitle::
.. transition:: tilt
   :duration: 2
.. ansi:: qrcode.asc