Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Vulnerability Response Models

 

Draft Vulnerability Response Standard (derived form Cloudstack)

This is a draft of a standard followed by changes/tools needed to implement the standard.

Reporting

If you've found an issue that you believe is a security vulnerability in a released version of CAS, please report it to security@jasig.org with details about the vulnerability, how it might be exploited, and any additional information that might be useful.

Upon notification, the Jasig security team will initiate the security response procedure. If the issue is validated, the team generally takes 2-4 weeks from notification to public announcement of the vulnerability. During this time, the team will communicate with you as they proceed through the response procedure, and ask that the issue not be announced before an agreed-upon date.

The security team asks that you please do not create publicly-viewable JIRA tickets related to the issue. If validated, a JIRA ticket with the security flag set will be created for tracking the issue in a non-public manner.

Standard

  • Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members
  • Security team investigates the issue to confirm/deny the presence of a vulnerability within CAS
  • If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid.
  • If issue is confirmed as a CAS vulnerability:
    • Security team notifies the Apereo Security team (happens automatically - they're on security@ list Is this true for cAS?)
    • Security team creates a Jira issue to document and track the issue, marking it private
    • Security team notifies release manager for target release version (need to modify for CAS)
    • Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System
    • Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue
    • Security team works with Apereo Security Team ??? to reserve a CVE Identifier for future public release
    • Security team works with appropriate code maintainer(s) to create patch to mitigate the issue
    • Testing is conducted to verify patch mitigates issue and does not cause regression errors.
    • Once fix is confirmed, notify release manager to ensure the fix is in the appropriate release.
    • Security team creates a vulnerability announcement
    • Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability. ??? Do we need a private repo for this
    • A new CAS release or hotfix is prepared and tested, containing the new security patch.
    • Distributor coordination is implemented to enable a coordinated announcement.
    • Security team posts vulnerability announcement to...
      • CAS dev list
      • CAS users list
      • CAS alerts web page???
      • The Bugtraq mailing list
    • After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.
    • Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.
  • After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.

Changes/Tools Implied

  1. Some way to mark Jira's as securituy related and therefore private.
  • No labels