Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.






Once Upon a CVE

Managing Security Events as an Upstream




@stahnma





Michael Stahnke



Engineering Director

@stahnma





Security Events at Puppet Labs

  • 18 events in 2012
  • 15 events ytd in 2013
  • Security is not unlike a popularity contest

    • Code shipped in many forms
  • source downloads
  • packages from us
  • bundled solutions
  • Linux distributions
  • 3rd parties
    • What Makes up a Security Event?
  • Code is vulnerable
  • Something used by your code is vulnerable
    • What makes these events difficult?
  • Bits for the fix
  • Compatibility
  • Protection of end-users
  • Privacy

    • For this, we need a process



    Processes have a beginning

    Vulnerability is discovered

    Confirm the Vulnerability


  • Can you reproduce it?
  • Is it purely hypothetical?

    • Is the problematic pattern in use elsewhere?




    Privacy of the vulnerability



  • Is the vulnerability known to the public?

  • Is it based upon a common pattern that is plubicly known?

  • Has the vulnerability been responsiby disclosed?

    • Public Knows?

  • Work fast
  • Offer public work-arounds if possible
  • Be as transparent as possible
  • Figure out severity of issue

    • Responsibly disclosed?


    Figure out the impact of issue

    Request CVE




    Common Vulnerability Exposure number


    Determine the impact
    Impact - Attack
  • How large is the attack vector?
  • Window of time?
  • Feature enabled by default?
  • Complicated to do?
    • Impact - Risk
  • Data integrity
  • Confidentiality
  • Availability
    • Impact - Type
  • Local privlege escalation
  • Remote arbitrary code
  • DOS
  • Bad practice
    • Communication
  • Begin coordination effort
  • People fixing issue need information
  • Doc writers might
  • Website team
  • No downstream comms yet
    • Communication
  • Private bug tracker
  • Request CVE if needed
  • Review who downstream will need info/fixes
  • Decide on versions to support/backport fixes for
    • Engineering

  • Create fixes (in private repo if possible)
  • Run tests (in private)
    • External Communication
  • Testing looks good?
  • Communication confidential release plan (if required)
  • Establish black-out period
  • Give downstream enough time to react (at least 48 hours)
    • Announce
  • Shout to educate your userbase
  • Send to mailing list
  • IRC, blog, website, podcast, etc
    • Decision Points
  • Publish tests with exploits? When?
  • Publish all new patches in public VCS? When?
  • Follow up questions
  • Make public bug-tracking issues
    • Attribution Did you forget?

  • puppetlabs.com/security
  • reddit.com/r/netsec
  • access.redhat.com/security/team
  • wiki.ubuntu.com/SecurityTeam
  • www.debian.org/security/
  • www.first.org/cvss/cvss-guide
  • cve.mitre.org/