Versions Compared

Old Version 9

changes.mady.by.user David Ohsie

Saved on

compared with

New Version Current

changes.mady.by.user David Ohsie

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Zero Day Response Model

  1. Cleaning up and automating the build and publishing process to enable releases to be cut quickly by whoever is available.
  2. No "grace periods" or "private discussions"; publicly discuss asap.
  3. Ideally set up a conference call to initiate discussion on how to resolve the issue and to assign responsibilities.
  4. Set up a secure communication channel for security advisories and notifications.  Perhaps update a public websites.

Current process:

    1. Open a JIRA "private security" issue.  It must be an issue, not just a change in "type".  Just changing the type doesn't help.
    2. Don't open pull requests; do a direct commit.  (David construct email on creating private repo for more extensive commit processes when needed).
    3. Cut the security releases including release notes.
    4. Community Notification
    5. After announcement, create JIRA's.
    6. Three possibilities: 
      1. No grace period - Everyone knows before people can patch + poeople  who follow many projects on bugtraq know right away
      2. 15 business day grace period - People watching bugtraq will be unhappy with what looks sloppy reporting + Lets adopters try to patch first
      3. short grace period  - People don't really have time to benifit.
    7. Public disclosure: bugtraq

Draft Vulnerability Response Standard (derived form Cloudstack)

...

Upon notification, the Jasig security team will initiate will initiate the security response procedure. If  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.

Current process:

...

  1. No grace period - Everyone knows before people can patch + poeople  who follow many projects on bugtraq know right away
  2. 15 business day grace period - People watching bugtraq will be unhappy with what looks sloppy reporting + Lets adopters try to patch first
  3. short grace period  - People don't really have time to benifit.

...

 

For CAS, the cas-appsec-private@lists.jasig.org list should be contacted. The CAS appsec WG will initiate the security response procedure.

Standard

  • Upon receiving notice of a potential security issue, a security team member will contact representatives for the affected project.  For CAS, the cas-appsec-private@lists.jasig.org list should be contacted. The CAS appsec WG 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 CAS appsec WG 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 designates a release manager for target release version (need to modify for CAS)versions as needed
    • 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 downloads page
      • CAS alerts web page???
      • The Bugtraq mailing list
    • After announcement, create JIRA's and update the release notes. 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 from cloudstack procedure:

Deleted: 

  • CAS appsec team notifies the Apereo Security team (happens automatically - they're on security@ list Is this true for CAS?)

Changes/Tools Implied

  1. Some way to mark Jira's as security related and therefore private: Misagh to investigate.Current suggestion:
  2. Look at switching to security@apereo.org.

Action Items

Nancy: Point person to get CVE creation process going.  (Added some research to the wiki).

Misagh: Investigate JIRA further to see if we can have private security issues.

 

 

Proposed Vulnerability Procedure

...

Public disclosure - CVE, http://cve.mitre.org/, etc

CVE Process

1.        Request CVE-ID from a CNA.

2.       The CNA provides CVE-ID and MITRE creates blank content on CVE website.

3.       The CVE-ID is shared with everyone involved in vulnerability disclosure.

4.       The CVE-ID is included in a vulnerability advisory.

5.       After the CVE is made public the requestor or CNA will notify MITRE.

6.       MITRE update the CVE-ID on website and database.

 

CNA to contact for the CVE-ID:

MITRE can be contacted by email at cve-assign@mitre.org CERT/CC (Third party CNA) has an online form (https://forms.cert.org/VulReport/)

 

The other listed CNAs are probably not good choices.  There is a long list of large software comapanies that run their own CNA for their own vulnerabilities.  Then there are two CNAs for researchers, which have make public p;olicie.  Then there are are the three Third party CNA's.  One is CERT/CC whose contact form I listed above, one is in Japan, the other seems concerned with vital infrastructure vulnerabilities.

 

Basically the choice is do you want to contact the MITRE CNA via email, or fill out a third party CNAs online form.

 

Some of the resources I check out:

http://cve.mitre.org/cve/cna.html

http://www.coresecurity.com/

http://secunia.com/community/advisories/report_vulnerability/

https://www.jpcert.or.jp/english/about/

https://ics-cert.us-cert.gov/

https://www.cert.org/vulnerability-analysis/