Minimum Baseline Security Standard for OpenMRS (MBSS)
Best Practices and Security Considerations Document
This document outlines the Minimum Baseline Security Standard (MBSS) where the core security principles and best practices tailored specifically for OpenMRS implementations are defined. It covers essential areas including network security, server hardening, data protection, authentication and authorization.
This work was contributed by IntelliSOFT Consulting Ltd. in September 2024 thanks to a generous grant from Digital Square for CyberSecurity improvement work, organized by OpenMRS Inc.
Table of Contents
Abbreviation/Acronym | Definition |
AAA | Authentication, Authorization, and Accounting |
API | Application Programming Interface |
DNS | Domain Name System |
HTTP | Hypertext Transfer Protocol |
HTTPS | Hypertext Transfer Protocol Secure |
NTP | Network Time Protocol |
REST | Representational State Transfer |
SOAP | Simple Object Access Protocol |
TTL | Time-to-Live |
TLS | Transport Layer Security |
JWT | JSON Web Token |
LDAP | Lightweight Directory Access Protocol |
Introduction
With the increasing number of systems, services, and integrations that organizations implementing the OpenMRS system continue to deploy within their environments, it is mandatory to define a minimum security baseline required to ensure that all services respond to a minimum level of assurance and none of which will impose a threat to the system and\network, thereby affecting the availability of the OpenMRS services. The minimum baseline standards provide a point of reference for all the stakeholders interacting with the platform allowing the system developers, administrator and integrators to incorporate security measures by design in the implementation of the OpenMRS system.
The minimum baseline standard lays the guardrails for incorporating the three fundamental principles of information security in the implementation of the OpenMRS system as defined below:
Confidentiality: Protecting sensitive information from unauthorized access, disclosure, or misuse. This ensures that only those with legitimate business needs can view or use data.
Integrity: Maintaining the accuracy and completeness of information. This prevents data from being modified, destroyed, or corrupted.
Availability: Ensuring that information and systems are accessible when needed. This prevents disruptions to business operations due to system failure or cyberattacks.
The document addresses different areas of interest in the implementation of the OpenMRS system including:
Operating Systems and Platform Configurations
System Security Architecture
Accountability
Access Control
Data Security and Privacy
Third-Party Security
Application and API Security
Scope Questionnaire
The scope questionnaire allows the end user of the minimum baseline standards and the policy administrators to effectively determine the boundaries of application of the standards based on the deployment environment and/or the service being integrated and/or the implementing parties
No. | Question | Answer (YES/NO) | Instructions |
1 | Does the project process, store, and/or transfer personal data, sensitive or confidential data?
|
| Please also answer the Data Privacy and Data Protection worksheets |
2 | Does the solution provide or access an API(s) either internally or externally using HTTP-based interfaces such as SOAP, REST, or JSON? |
| Please also answer the Application and API worksheet |
3 | Is the solution partially or fully hosted in a cloud? |
|
|
4 | Is any 3rd party company involved in one or more of the following activities:
|
|
|
Secure Network and Physical Environment
No. | Question | Answer (YES/NO) | Instructions |
1 | Has the hosting server(s) been secured in a locked rack or an area with restricted access? |
|
|
2 | Has all the non-removable media been configured with file systems with access controls enabled? |
|
|
3 | Has the server(s) been set up in an environment with appropriately restricted network access. ? |
|
|
4 | Has the server(s) been set up to display a trespassing banner at login. ? |
|
|
Patching/ Server Maintenance
System Hardening Features
System hardening is the practice of reducing a system's vulnerability by reducing its attack surface. Hardening may involve a reduction in attack vectors by culling the pathways, or vectors, attackers would use.
No. | Question | Answer (YES/NO) | Instructions |
1 | Have all system components (OS, DB, applications, network devices) been hardened according to specified guidelines as well as specifications provided by the product manufacturer? |
|
|
2 | Have all servers and applications been configured to disable/prevent access by trusted communities and systems (such as the use of .rhosts and .shosts for UNIX)? |
|
|
3 | Have all software (OS, application, DB) packages and modules not required for this system been deactivated and removed (where possible) from the system? |
|
|
4 | Has an account been created with adequate permissions eg. With sudo rights to facilitate continuous compliance scans on all system components even after go-live |
|
|
Patch Management and Vulnerability Reporting
The patch and vulnerability management program (PVMG) outlines the requirements for keeping the organization’s systems updated with the most current versions of their software. PVMG ensures that the organization installs remediation patches for known vulnerabilities and exposures.
No. | Question | Answer (YES/NO) | Instructions |
1 | Is the most recent version in use with the latest security patches/service packs applied across all components? |
|
|
2 | Have all patch and non-patch vulnerabilities been tested and remediated before the system go-live? |
|
|
3 | Has an exhaustive list of all the installed security patches and modifications been provided? |
|
|
4 | < |