OpenMRS seeks to be a reliable and trusted application. We also recognize that security incidents can (and do) still happen, and so it's just as important to have effective methods for handling them should they arise.

The 3 Different Types of OpenMRS Security

There are three very different angles when it comes to OpenMRS CyberSecurity. 

1. OpenMRS Community Tools

   1. What: Anything tooling leveraged to support the communication and organization of the world-wide OpenMRS community & membership. This includes things like forums, newsletter mailing lists, Demo / Reference Application Environments, Issue Tracker, Wiki, CI Pipeline, SSO Member Accounts, and our Help Desk. None of these contain patient information as that is outside the purview of these tools. 

   2. How: This infrastructure is managed through a combination of OpenMRS Community Support Engineers, and volunteers from around the world. For questions or concerns about our Community Infrastructure, please contact Community Architect @Burke Mamlin. 

2. OpenMRS Production Implementations in the Real World

   1. What: Any real-world, production implementation of OpenMRS software. 

   2. How: OpenMRS Support Team members do not directly implement production software in the field under their OpenMRS Support Mandate. Instead, we depend on Implementers (e.g. Service Providers like the ones listed here), or the independent NGOs or MoH-backed organizations using OpenMRS, to ensure their systems are set up and accessed securely. Some guidance for such implementers is suggested here. The OpenMRS community itself, as a whole, is not an implementation vendor.

3. OpenMRS Community Software Project

   1. What: This includes the actual community-maintained software products: e.g. the Backend Platform and Reference Application (which includes both Platform & Frontend). 

   2. How: The OpenMRS EMR software is an opensource, community-maintained artifact, with some limited dedicated support from a small OpenMRS Global Product Support team, and a wider, private group called the OpenMRS Security Group.  Examples of controls employed by these groups and the concerns we watch for include:

      1. 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 we also publish security advisories to the OpenMRS Forum & mailing list. See more on the Security Group below. 

      2. GitHub Security Reporting: Security Researchers are able to use GitHub Security Reporting to open issues, and for issues of concern, the OpenMRS Security Group contributes back to the GitHub community through using GitHub’s Security Advisory & CVE system. 

      3. Code Review: 2+ Reviewers are required on all PRs in the OpenMRS GitHub project.

      4. Code Scanning: All OpenMRS EMR software code goes through automated review from GitHub/npm assets like dependabot, which checks for known vulnerabilities that might be introduced by libraries we use. Based on this we often update our library versions as part of our community software releases. 

      5. Access Control: This is a feature of the OpenMRS EMR platform. Deeper levels of role-based access control etc are also provided through OpenMRS backend modules. 

      6. Common Concerns like SQLi, XSS, and CSRF: We fix and discuss these on an ongoing basis and in the OpenMRS Security Group private forum. We often also leverage projects like Google Summer of Code to address focused issues. A backlog of known issues is periodically reviewed by members of the OpenMRS Security Group. 

A framework for managing security incidents

To ensure our incident response process is consistent, repeatable and efficient, we have a clearly defined internal framework that covers the steps we need to take at each phase of the incident response process.

1. Receipt of Incident

Community members and concerned parties work with OpenMRS' Security Group in logging, monitoring of our artifacts and infrastructure. The designated mechanisms through which security incidents are reported are:

• By Email: on security@openmrs.org - Emails are automatically posted on the private Security Talk category, where they are immediately available for review & discussion by relevant OpenMRS community members in technical or operational leadership positions.

• On GitHub: you can use the Private Vulnerability Report feature in GitHub here. This helps us leverage GitHub's Security Advisory & CVE tools. 

2. Assessment of Incident

Members of the Security Group will review the incident report and determine an incident severity categorization as depicted below:

Routine security updates will be highlighted in the release notes for each release. If a vulnerability is a critical one (e.g something submitted by an external body), members will receive an email to that effect

3. Activities for containment, eradication, and recovery 

The security vulnerabilities group will determine depending on the level of severity of the incident, agree what corrective measures need to be taken to contain the incident, eradicate the underlying causes and start our recovery processes to ensure that operations return to normal.  Thus a summary of activities at this stage would include:

1. Upon receipt of incident the security vulnerabilities group is activated: Identify an “Owner,” developer, others on the core team

2. Minimum a team of 3-5 people can be assigned to a certain vulnerability group i-e ‘Owner’, ‘developer’ and a ‘tester’, 'coordinator' etc.

3. The team can be formed by a security management team with discussion to OpenMRS management, based upon previous contributions of members in their concerned (security) area.

4. Define a plan of action to be agreed and executed upon. 

5. We also have access to a range of external experts to assist us with investigating and responding as effectively as possible.

6. Work on the fix

7. Compliance with the deadlines

8. Test and release

9. Create an initial draft of the security review and circulate for review

10. Deploy to our environments

11. Notify the public via OpenMRS Talk

12. Vulnerability with its solution and updated fixes be documented properly. (if possible within major other languages also.)

4. Notification to Implementers and the Public

We aim to notify affected community members within 5 business days or without undue delay if their data is involved in an incident or a breach. This might be light on detail at first, but we’ll provide every detail available when it is available. These initial communications will be done directly with the affected party as the matter is being resolved, however, as soon as the security group deems that it is possible to inform a broader audience, such information will be posted to the designated communication channel which is  OpenMRS Talk.

Step 1: Set up a DRAFT Security Advisory in GitHub & Request a CVE

1. Create a DRAFT Security Advisory in the relevant repo. (Any repo admin can do this.)

2. Click "Request CVE" when you are happy with the draft advisory contents (don't worry, you can edit them again later after disclosure). GitHub will assign the advisory a CVE within 72hrs (but usually within an hour.) Requesting a CVE for a draft will not disclose the vulnerability.

   1. Open

      

3. Add the CVE number to your Advisory Email and Forum Post. One of the code owners will need to do so. 

Step 2: Notify Implementers

1. Create and review email text for an Advisory email to implementers. (We like to send out an internal notice to known organizations using our software to give them some time to react before the vulnerability is publicly posted. This helps organizations have a plan on-hand instead of feeling surprised/caught off guard.) 

2. Request an OpenMRS MailChimp admin to send the Advisory email to all known implementer leads in the Security Advisory tag in MailChimp: (As of 2022-02, @Burke Mamlin , @Jennifer Antilla , and @Ian Bacher have access to this list.)

Step 3: Notify Publicly on Talk and GitHub

After some period of time (e.g. ranging from immediately to 2 weeks, depending on the severity): 

1. GitHub: Publicize the Security Advisory.

   Open

   

2. Talk Forum: Post the Advisory on Talk. Add the tag security-advisory and include a link to the GitHub repo advisory. 

3. If the issue is High or Critical: A tweet from the OpenMRS Twitter account is also recommended. This can link to the relevant Talk Forum advisory post in case folks have questions. 

Notification Format & Sample Template

Security Advisory Format

Contains at a minimum:

• Severity

• Exploit

• Affected versions (including mentioning EOL’d versions)

• Exact steps on how to fix the problem, and any available workarounds (list exact versions)

• Acknowledgments to people who reported it and fixed it.

Sample Template Here:

More about the OpenMRS Security Group

Role:

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 either by themselves or via programs such as bug bounties. 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

•  

  • External group (i.e: Bishop Fox)

  • Internally (i.e:bug bounty/Hackerone)

• 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.

Helpful Cybersecurity Resources

We recommend that OpenMRS community members, especially implementers, familiarize themselves with the following highly-recommended resources: 

• OWASP Top 10

• Secure development principles - National Cyber Security Centre 

• NIST Cybersecurity Standards

• SOC2 Audit Guide