Sahana Security Team

DRAFT – This is a draft document - Do NOT rely on the information contained herein – DRAFT

Goals of the security team

  • Investigate and Resolve reported security issues in a timely manner
  • Monitor bundled libraries for security vulnerabilities.
  • Provide ongoing code review for potential security weaknesses, including pre-release reviews
  • Provide documentation and communication with the community regarding security issues
  • Issue security-related release updates

Reporting a new security issue.

If you wish to report a new security vulnerability in Sahana, please send an email to security@sahanafoundation.org For reporting non-security bugs, please see the Enhancements and Bug page.

Security Updates:

Security updates are primarily made available as minor version upgrades. You are always advised to use the latest minor version available, as it will likely also contain other non-security related fixes. All known security issues are always fixed in the next major release, when it comes out.

Disclosure Policy:

The Sahana security team encourages a full disclosure policy. Withholding information about a security problem and hoping that it won’t be discovered by others, is almost always futile. Public announcements are made when the threat has been addressed and a secure version has been made available available. When reporting a security issue, we respectfully request that you observe the same policy. Do not share your knowledge of security issues with the public at large.

Communications:

Security team members shall communicate announcements of security vulnerabilities on both the sahana-user and sahana-maindev mailing list. In addition, announcements shall be made on community recognized security mailing lists (ie. oss-security)

Security Support:

Sahana supports how many versions??

Internal Security Team Goals:

These are internal goals, that we are trying to adhere to in general. Certainly some security issues may require more amounts of work than can be accomplished in this time period. This information is released in the spirit of openness, not as a guarantee. Respond to original reporter within 24 hours acknowledging receipt. Validate whether a vulnerability exists within 72 hours and what versions it affects. Patch and test completed within one week, and release work begun. Release resolving the vulnerability out within 10 days.

Security Team Members:

  • Ajay Kumar
  • Chamindra de Silva
  • David Nalley
  • Greg Miernicki
  • Mark Prutsalis
  • Gavin Treadgold

Internal Security Response Plan

Scope:

Sahana is a rapidly developing disaster management platform, and has limited resources. As such, Sahana shall identify N supported releases (identified by major version number) for which security issues shall receive priority treatment.

Response Times:

  • Respond to original reporter within 24 hours acknowledging receipt.
  • Validate whether a vulnerability exists within 72 hours and what versions it affects. Regardless of outcome, response to the reporter shall occur at this point.
  • Patch and test completed within one week, and release work begun. Reporter shall be updated when a patch is available offered the patch to confirm that it does indeed mitigate the vulnerability.
  • Release resolving the vulnerability out within 10 days along with announcements.

Severity evaluation:

Upon initial discovery/communication of a vulnerability one or more security team members shall work to verify the vulnerability and evaluate it's severity based on the following criteria: Scope - is the effect of the vulnerability limited to Sahana, or does it result in system vulerablity

  • Remote or local user - can the vulnerability be effected remotely
  • Sahana privileges required? - does the vulnerability require an account in Sahana
  • Access or crash: Does the vulnerability stop the system from working or permit access to data.

This is not meant to provide a strict 'XYZ severity rating' but rather to provide for comparative consideration.

Communication:

Communication of a security vulnerability shall occur when the vulnerability has been mitigated and a patched release is available.

In the event that the above response time goals are unable to be met for a critical security vulnerability the security group shall make the decision whether or not to make intermediate communication that identifies the problem, along with any workarounds that may be used until the issue is mitigated.

All security-related communications traveling outside of Sahana mailing lists shall be reviewed by the author and at least one other security team member.


Navigation
QR Code
QR Code dev:securityteam (generated for current page)