Security incident handling - improvements for 2017

Vanilla Forums
Vanilla Forums
in General

These are proposed ground rules for handling security issues. Questions, feedback, and updates welcome. This is simply to make sure everyone is on the same page regarding communication around security issues so we don't drop the ball along the way.

Receiving

  • All security issues MUST be reported to security@vanillaforums.com.
  • If YOU receive a security report, send it there. Include contact / source info.
  • Each security issue must have a separate, dedicated support ticket.
  • Support and all developers are notified of incoming security issues.
  • Reports received via HackerOne will be put into this same workflow.

Rating

We use a Critical / High / Medium / Low rating for issues.

Red Hat has good descriptions for a similar 4-part scale here: https://access.redhat.com/security/updates/classification

Assignment

  • A developer must give an initial review within 24 hours (critical? yes or no).
  • Escalate critical issues to your manager or senior management.
  • Support is responsible for finding a developer to respond.
  • Responding developer is responsible for the issue until explictly reassigned.

Developer assignment

Find the first available developer (waiting for response before moving on at support's discretion) using HipChat and/or SMS as needed. If no developer has responded after 24 hours, escalate to phone calls until someone is reached.

As of May 2017, the developer availability order is:

  • Lincoln
  • Ryan
  • Alex
  • Tim
  • Todd

Coordination

All communications regarding reported but unsolved security issues should be in one of:

  • Support ticket (to reporter)
  • HipChat 'Security' room (internal coordination)
  • Google Hangout posted to said room (if real-time is needed)
  • GitHub issue posted to said room (solution planning)

Never backchannel via chat or email.

Special Workflow Requirements

  • Every security issue must be filed on the appropriate repo.
  • Security issues must be worked on in every subsequent, sequential sprint until resolved.
  • Critical & high priority issues require:
    • Insertion into the current sprint.
    • Immediate deploys to all clusters upon resolution.
    • An open source release within 48 hours of resolution.

External Communication

  • Responding developer is responsible for composing detailed response to the reporter.
  • Any media or third-party requests for comment are to be referred to marketing.
  • Do not obfuscate details or minimize the issue.
  • Do not publish exploit details for at least three months after an open source patch is released.

Vendors

If a third-party is involved (e.g. an upstream vendor like Htmlawed) the responding developer owns said conversation and must copy security@vanillaforums.com on emails. Update status via Security chat.

Categories