OpenMRS Security Governance: Roles & Communication Channels

OpenMRS Security Governance: Roles & Communication Channels

OpenMRS Security Squad

Mission

The OpenMRS Security Squad is designed to be a human repository of knowledge of OpenMRS security needs, processes, and communications, and a central coordinating body for responding to security vulnerabilities and incidents.  The squad helps make security work more visible, easier to participate in, and better supported over time.  This, in turn, ensures that the community is creating and following best security practices.  The ultimate goal is to ensure that the OpenMRS system is more secure.

Member Goals and Responsibilities

  • Gather and receive input from the community on security needs, issues, weaknesses, ideas for strengthening; and serve as a repository for OpenMRS security knowledge.

  • Advise the community by providing ideas and thoughts on how to improve OpenMRS Security.  

  • Raise awareness of the importance of security practices 

  • Be a champion and advocate for best security practices, such as the adoption of tools meant to improve the security of OpenMRS.

  • Advocate for the OpenMRS community to continue to build security practices and skills required to build secure code.  

  • Provide feedback on the NSF OSE project and other initiatives related to OpenMRS Security.

  • Confidentially respond to reports of security vulnerabilities/issues, and communicate the resolution/patch to the implementers and other community members in an agreed upon method (as appropriate); Communicate security updates publicly at agreed upon periods of time post-resolution.  

Members 

The Security Squad is a group of community members who are interested in actively moving this work forward and improving the security of OpenMRS. You do not need to be a security expert to participate. Interest, curiosity, and willingness to collaborate are more important than prior experience. Membership is voluntary, and the Security Squad may include:

  • Developers and maintainers

  • Implementers with real-world security experience

  • QA software testers

  • Students and researchers interested in health software security

  • Security professionals who want to contribute to a high-impact open-source project

How you can get involved

  • Join the discussion on the #security slack channel

  • Volunteer to participate in the Security Squad conversations

  • Share feedback on current security challenges or gaps

  • Help in addressing security issues in OpenMRS

  • Help spread the word to security-focused communities or colleagues

OpenMRS Security Documentation: Security

Meetings Schedule

  • TBD by the Squad Members

The OpenMRS Security Group

This Security Group contains trusted, knowledgeable members of the community who receive incoming concerns such as university student group findings, code-scan questions from implementers, and specific reports from security researchers. Together they also publish security advisories to the OpenMRS Forum & mailing list. See more on the Security Group below. 

Member Roles and Responsibilities

The role of the group is to work with the finder or reporter to resolve the identified vulnerability. It is also tasked to continually review and understand vulnerabilities that are currently occurring within the system. This group is responsible for identifying the requisite resources needed to address any vulnerabilities addressed.

Scope of activities:

  1. Identify requisite resources to develop fixes for identified vulnerabilities

  2. Oversee at least one major vulnerability scan a year and map a corrective action plan to address vulnerabilities identified

Roles within the Security Group:

  • Finder (Discoverer/ Reporter) – the individual or organization that identifies the vulnerability

  • Manager - An individual with a role of managing the vulnerability process till the fixing and its updated release, appointed by the management of OpenMRS.

  • Vendor –  the individual or organization that created or maintains the vulnerable product.

  • Deployer – the individual or organization that must deploy a patch or take other remediation action

    • Implementers

    • Release managers who need to include the patch in the ongoing release process

  • Coordinator – an individual or organization that facilitates the coordinated response process

    • TPM

    • OpenMRS Software Security Lead

  • Tester  -the individual who tests the updated release, its feedback is taken from the Deployer and documents the fixes finally report it to the "Owner".

Security Vulnerability “Manager” - Roles and Responsibilities

  1. Deciding (with the core team) which versions should be released

  2. Ensuring that a developer is working on the problem on a timely fashion

  3. Ensuring that a release is done as soon as possible

  4. Create the initial draft of the security advisory and ask for reviews. Create the CVE if relevant.

  5. Follow the process to release the security advisory

  6. Ensure all public OpenMRS community environments are updated.

  7. Follow up on any discussions or questions about the incident.

  8. Ensuring the documentation of vulnerabilities and their updated solutions to have a review for the next developments.

  9. Ensuring the proper testing of the Vulnerability fixing by cross-checking by with the pre-vulnerability state and documenting the final report for future use.

OpenMRS Security Mailing List

This is the channel used to notify known implementer organizations about security vulnerabilities before they're made public. When the OpenMRS Security Group finalizes a fix for a reported vulnerability, an advisory email is sent out to implementer leads who are in the community's security mailing system, giving them a head start to patch or prepare before the issue is posted publicly on GitHub and the OpenMRS Forum.

If you are an implementer and would like to receive security notifications, reach out directly to request inclusion to the mailing list via community@openmrs.org or beryl@openmrs.org