This guide provides a detailed, step-by-step approach to setting up secure environments for OpenMRS. It includes instructions on deployment models (public and private), cybersecurity assessments, and the implementation of key security controls such as network segmentation, Vulnerability Assessment and Penetration Testing, endpoint security, user access management, infrastructure security, and continuous monitoring of network and application activities.

OpenMRS STEP-BY-STEP GUIDE FOR SETTING UP SECURE ENVIRONMENTS

Abbreviations and Acronyms

Introduction

Cybersecurity plays a crucial role in the lifecycle of application. Cybersecurity directly influences the usefulness and availability of the web and mobile application platforms, OpenMRS platform included. NIST recommends the consideration of cybersecurity under 3 pillars of information security: confidentiality, integrity, and availability. The balance and the proper implementation of all the 3 pillars ensures a secure, always available and reliable platform. 

Open

Confidentiality  includes maintaining  authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. Availability involves providing surety on the timely  and reliability in the access and use of information. Availability ensures that the information and information sources are always available as required by the authorized users. Information systems are only useful only when they can be reliably retrieved as required by the right people or systems.  Integrity involves safeguarding information and information systems against illegitimate alteration or destruction and ensuring that the authenticity of the information and non-repudiation is maintained from the point of creation of information to when it is destroyed. Integrity ensures that systems that consume information are fed using the correct input and given no interference with their functionality, the systems give the correct and desired output. 

Maintaining a cyber secure environment is a continuous and progressive effort that involves different processes, tools and people. The steps include a continuous iteration of : 

1. Cyber security discovery and baselining

2. Remediation 

3. Documentation 

Cybersecurity discovery and baselining involves carrying out continuous cybersecurity scans and professional checks to determine the current state of cybersecurity controls or lack of and the deviation from the recommended standard. It requires deliberate effort to collect and understand the proposed standards and deploying different tools and techniques to ascertain how far the organizations’s current cybersecurity control implementation deviates from the standards. Remediation is the process through which organizations deliberately take effort to close on the gaps identified from the security scans and discovery. It involves the implementation of the recommended best practices and standards so as to close the gaps. Remediations can be incorporated in the organization production pipeline through automation to ensure always on implementation of the set standards or as a manual process enforced through administrative controls  and procedures. Documentation allows organizations to keep records of progress and to track the progress of implementation of the cybersecurity controls. Documentation also provides reference and evidence of compliance in highly regulated environments. 

Deployment Models

Deployment models refers to the manner in which the platform or application is set up in relation to the hosting environment, the platform accessibility and integration with other applications. 

There are two different deployment models in reference to accessibility and connectivity:

1. Public deployment model

2. Private deployment model

All the deployment models have these 3 basic components: 

1. Application hosting environment

2. The network access layer

3. The access layer 

As illustrated in the figure below, these components function together to ensure the availability of the OpenMRS platform. Organizations therefore need to ensure that all the components are securely deployed to guarantee the security  of the whole.  

Open

Figure 1: OpenMRS Application Deployment Environment

Cybersecurity Assessment 

There are various tools and techniques recommended by different bodies on controls and standards that can be used to implement and track the cybersecurity controls implementation. These tools include:

1. Vulnerability assessment and penetration testing (VAPT)

2. Threat Modeling 

3. Risk assessment

Deployment models have a significant influence on application of different cybersecurity assessment models in evaluating the security posture on the serving platform or application. 

Vulnerability Assessment and Penetration Testing (VAPT)

Vulnerability Assessment & Penetration Testing (VAPT)  refers to the security testing to identify security vulnerabilities in an application, network, endpoint, and cloud. Vulnerability Assessment scans the digital assets against pre-configured security standards and signatures and notifies organizations about pre-existing flaws. Penetration test exploits the vulnerabilities in the system & determines the security gaps. Organizations running the OpenMRS platform should as a standard perform a quarterly vulnerability assessment on the OpenMRS platform to ensure continued security of the application. The security assessment and scans should also be enforced on new capability added to the platform including new integrations.Upon the completion the VAPT exercise should seek to remediate the discovered vulnerabilities. 

Threat  Modeling

A threat model is a structured representation of threats or vulnerabilities that may impact a particular system, platform, or network. The threat model allows system support and administrators to identify the nature of exposures and how the threats can affect the availability of services. Threat modeling relies on the documentation of architecture and data flows to evaluate and map the possible threats. The model considers the likely threats to a system like  OpenMRS as a whole and in parts. This ensures that vulnerabilities that may arise due to integration and coupling between different components are also evaluated. 

The figure below details the possible vulnerabilities and areas of exposure on the OpenMRS application in a production environment.

Figure 2: Possible Vulnerabilities and Areas of Exposure on OpenMRS

Risk Assessment 

Risk assessment is the identification of risk factors that could negatively affect an organization's ability to conduct business. Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems. The purpose of risk assessments is to inform decision makers and support risk responses by identifying:

1. Relevant threats to organizations or threats directed through organizations against other organizations; 

2. Vulnerabilities both internal and external to organizations;

3. Impact (i.e., harm) to organizations that may occur given the potential for threats exploiting vulnerabilities

4. Likelihood that harm will occur. 

The end result of risk assessment is to identify  and quantify risk, which is the function of the degree of harm and the likelihood of the harm and the likelihood of the harm happening. 

Risk assessment can be conducted in 3 different tiers within the organization with the focus of each of the categories of the tiers informing the difference between the different categories. The first category- Tier I, focuses on the organizational level, the second  category - Tier 2, focuses on the business or process level and the third tier - Tier 3, focuses on the information system level assessment including security categorization; security control selection, implementation, and assessment; information system and common control authorization; and security control monitoring

Public Deployment Model Risk Assessment

The public deployment model allows for  accessibility of the OpenMRS platform and its workloads over both the internet and the local area network (LAN). In this deployment the risk surface is broadened due to the platform's availability and reachability over the internet. The risks and exposures for the public deployment model include and not limited to DNS attacks, network attacks and application attacks. The figure below illustrates the access path for the public deployment models.

In the figure illustrated above for the public deployment model, the request is generated from the access methods, the request is resolved to the mapped public IP address by the DNS. The request is then directed to the serving server mapped to the resolved IP address. The server upon receipt of the request, processes and replies to the server request with the right information that the user is seeking to get from the OpenMRS application. Each of these processes and system integration presents an opportunity for  exploitation which poses a risk to the OpenMRS platform. 

As shown in the diagram below, a risk assessment carried out on the various components of the OpenMRS platform reveals different exposures both security and business that needs to be put into consideration when deploying the platform. These risks can be 

As shown in the figure above, the public deployment model has a broader attack surface as brought about by the connectivity over the internet. The risks associated can be summarized as below:

1. Risks associated with access layer 

2. Risks associated with the network layer 

3. Risks associated with the hosting environment

Risks associated with the Access Layer 

These are risks that result from the nature of access to the platform. They are primarily associated with the nature and type of access that the platform adopts to authenticate and authorize use to access the platform. These also include the risks associated with the security posture of the access devices that the users use to access the platform. Environments which are not properly and comprehensively configured to detect and prevent cyber attacks, compromises on the users device such  as virus outbreak can be easily propagated to the platform.  Similarly, improper custody of access credentials especially for privileged users can result in platform takeover, which may  effectively lock out everyone from accessing the platform thereby affecting the platform’s availability. Where the organization does not administer the devices used to access the platform, the cyber attackers can also easily gain access to the the platform through monitoring the access profiles of different users using several attack techniques such as key logging, where the attackers instal spying softwares on the users devices to track and steal users’ credentials and inappropriately use them to compromise the integrity of the devices. Users can also be subjected to credentials compromise through shoulder surfing, if they inappropriately display their credentials during login sessions. 

In events of access breach to the platform, the attackers can take advantage to manipulate the data store on the OpenMRS platform, these manipulations can include deleting entries, wiping out data, feeding stale data to the databases which may compromise the integrity of of the data, the operations and the decisions and inferences made based on the stored data. Similarly, confidential data about patients, health and practitioners can be exposed leading to both financial and reputation damages to the affected organizations. In highly regulated environments, where the handling of sensitive data and personal information is prioritized, organizations may incur severe penalties including but not limited to the withdrawal of licenses of operation  

Risks associated with the Network layer 

The network layer provides the medium of access and connectivity between the users and the platform. The security and the controls deployed on the network layer are therefore very crucial for the availability of the platform and the integrity and confidentiality of the information being exchanged over the medium. Different network components have different exposures and vulnerabilities that should be handled both individually as a unit and collectively as a system to prevent unintentional oversight that might be introduced through the integration of different network components. For public facing assets and network components, the security of the operating systems (OS) is crucial, as the OS can easily be exploited leading to an exposure of the same whole setup. Equally considerations and care should be taken to ensure that the property of the different components of the equipment including the interface and backplane capacities are capable of supporting the total throughput of the network. If not checked, overutilization of the link capacities may lead to congestion and poor network experience. Similarly, the overloading of the equipment backplane may lead to the total system collapse due to the inability to process the requests due to lack of resources. 

The network layer is also exposed to both internally and externally generated distributed denial of service (DDoS) attacks which may target both the transmission and the application layers of the network. These attacks pose a risk to both the availability and access of the platform. The forming components of the network should therefore be resilient enough to withstand the DDoS attacks while still maintaining the confidentiality and integrity of data during the attacks. The network layer also introduces an exposure on the data being transmitted between the  platform and the users. The choice of the equipment should ensure the confidentiality of the data while both in transit and while at rest. The equipment should support the end to end encryption of data including protection against man in the middle attack, replay attacks and cryptographic attacks. Equally, the existence of the network layer components in physical form poses a risk to the confidentiality of the data being transmitted. The individual components should remain secure to ensure the confidentiality of the data stored in any of its memories in the event that equipment is lost or partly damaged. 

Risks associated with the Hosting Environment

Similarly, the safety  and security of the hosting environment poses a risk to the availability, confidentiality and integrity of the OpenMRS platform. The choice of the hosting environment should be secure enough to ensure the proper and efficient running of the OpenMRS application. Where possible, the deployment should allow for scalability to optimize resource utilization and scale out as required to match the demand on the platform. The system integration should not introduce new attack surfaces that  can be easily exploited.The hosting environment also poses business continuity risks. In instances where the organization only operates single deployments of the OpenMRS, occurrence of catastrophes and other events that may lead to total loss or isolation of the OpenMRS environment may lead to loss of both access and availability of the platform. Organizations should seek to deploy highly available platforms to protect  against business continuity risks. High-availability deployment ensures that the organization can still run from the redundant deployment sites in the event that the production site is lost or isolated. The security of the data hosted in the databases. The  security set up for the hosting environment should be such that it protects against risks posed by unauthorized access. This should include limiting access to only authorized users from trusted internet sources. 

Private Deployment Model Risk Assessment 

Unlike the public deployment model, the private deployment model does not suffer the risks associated with internet access since the platform is only accessible on local area network  (LAN). The platform however, still faces other risks associated with the different layers. 

Risks associated with the Access Layer 

Most of the access layer risks for the private deployment model are majorly associated with actions of compromised and disgruntled internal users who may abuse their powers and privileges to compromise the platform. The access, handling and storage of data on the platform is a major concern for the private deployment model. Brute force attacks and credentials theft pose confidentiality and integrity risks to the platform and the data hosted within. In instances where organizations allow for access to the platform using the bring-your-own-device (BYOD) model, then platform’s data run the risk of getting corrupted and possibly taken over by undetected malware if the no proper security measures are put in place to safeguard the data and the environment at large against viruses and malware attacks. Organizations should explore putting in place policies and controls governing the use of end points whether organization owned or personal devices brought in by the workforce. 

Risks associated with the Network Layer 

The private model deployment model network access layer faces availability risks that are intrinsic to the deployment model.  Due to the nature of deployment, private models of deployment face availability risks due. In the event the production site is lost or isolated, there is no way of redirecting the requests to another site as the services are only available on the LAN. Similarly,  it also suffers from risks inherent to physical deployments including risk of total outage should any of the physical network devices be a target from the attackers. 

Risks associated with the Hosting Environment 

Like the public deployment, the private deployment model also faces the risks associated with the hosting environment. Though immune to external attacks, the platform faces risks that can be introduced as a result of BYODs, hosting platform vulnerabilities, and the vulnerabilities caused by integration with other platforms. These risks need to be evaluated and contained where possible to alleviate the possibility of an outage on the platform. The organization should also evaluate the resources requirements and size the environment appropriately to ensure that enough resources are provisioned for the OpenMRS deployment. This should be extended to the shared infrastructure hosting the other support services such as monitoring and logging. 

Security Controls and Best Practices

Security controls and practices involve putting into place proven and working security measures that address the requirements of confidentiality, integrity and availability of information hosted on the OpenMRS platform and or exchanged between the OpenMRS platform and the other integrations. It involves empowering and equipping the workforce with the necessary knowledge, skills and tools to be able to securely operate and use the OpenMRS platform. Security controls implementation for the OpenMRS can be evaluated in the following different facets including 

1. Application Security 

2. Network Security 

3. Infrastructure Security

4. Monitoring and Logging  

5. User Access Management 

6. Endpoint Security 

Monitoring  and Logging 

Cybersecurity monitoring is the continuous practice of observing an organization's traffic profile and pattern, endpoints posture and behavior, user behavior and the compliance to organizations set standards. Monitoring is primarily important to organizations because of the following reasons 

1. Reputation

2. Privacy of User Data

3. Availability

4. Misuse of Organization Service

Monitoring gives the organizations the capability to actively spectate the network and to identify unusual patterns and malicious behavior on the network. This allows organizations time to react to the different changes right before they affect the normalcy on the network or before the organization incur significant damages due to the exploit. 

Monitoring is targeted towards two different areas

1. Endpoint Monitoring

2. Network Monitoring 

Endpoint Monitoring

Endpoint Monitoring involves actively monitoring the security posture of the devices that users use to access the organization network. It involves putting into place policies and procedures that govern the uses of the devices on the network and the tools to enforce the policies. Endpoint monitoring is specifically important in preserving the confidentiality and integrity of those that are accessible to the users through the workstations or phones. 

Organizations should put into practice zero trust  policies for all the devices  being allowed to access the network that hosts the OpenMRS application and other applications. A zero trust approach to cybersecurity allows the organization to enforce requirements and criteria  that visiting hosts must fulfill before they join the network, including having an up-to-date antivirus, having a running data loss prevention tool and running the right versions of softwares of interest to the organization. Ths capabilities may be achieved through installing a mobile device management solution (MDM), endpoint detection and response tool or an antivirus to prevent against viruses and malwares. All logs from all the endpoints should be collected from different sources and tools on the network and sent to the Security Information and Event Management (SIEM) platform for monitoring and logging.

Network Monitoring

Network elements refers to all the nodes and technologies that are used to provide the connectivity between the OpenMRS platform and the end user. It includes the hosting infrastructure, the switches, the routers and the firewalls that exist within the internal network or on the periphery of the hosting network.  Network monitoring also includes baselining the normal organization’s network traffic and setting limits for  consideration of offsets from expected traffic. It is particularly important in keeping ready against attacks such as DDOS, Web application attacks, user manipulation, geo-attacks. Network monitoring should also be extended to wireless networks in cases where the organization has also deployed wireless networks. Particularly, network monitoring is important in making sure that service availability is not compromised either through attacks or through loss of power or connectivity that establishes reachability between the devices. In instances where the network devices store data locally, then access to the devices should also be monitored to ensure that the confidentiality and integrity of the hosted data is maintained. Similarly, user access behavior and the use of privileged accounts should be monitored to arrest cases of network misuse, abuse and takeover. 

The logging for the network devices and the endpoints should be properly configured to ensure that all the relevant logs for traffic and events are picked by the logging agents for purposes of monitoring. The logging agent, however, should not have any effect on the availability or loading of the network devices. Similarly, encryption should be configured for the logs being stored locally on the devices and while in transit to the log collectors. This is in compliance with the integrity and confidentiality standards, making sure that in case of any breach on the network confidential information stored in the logs remain inaccessible to the malicious actors. 

Monitoring Platform Setup

Effective monitoring requires an always-on presence on the monitoring console to ensure that the right actions are being taken as the events stream into the SIEM platform. To reduce the reliance on the monitoring analysts, the SIEM platform should be configured with effective playbooks for known attack use cases to make sure that the threats are automatically mitigated and logged on time. The availability of the monitoring platform is critical to the operation of the organization’s cyber defense center. The monitoring platform should be highly available, allowing the organization to recover from any attack on one of the serving sites. The availability should extend to the data storage, making it possible to re-instantiate the SIEM platform from the backup data should the intelligent head of the SIEM be taken out by malicious actors. To allow for effective operations, the SIEM should be integrated with the available threat intelligence sources to allow for continuous updates on cyber threats and attack signatures. This will protect the organization from zero day attacks. 

The organization should also make sure that the access to the SIEM platform is audited and properly configured. Privileged users and system administrator roles and actions should be reviewed continuously to ensure that the system remains properly set up and instances of privilege abuse do not occur. 

A typical SIEM setup includes the deployment for the log collectors, log indexers, and the SIEM intelligent head. The collectors are primarily responsible collecting and parsing the logs into a format that can be read by the SIEM, the indexers are responsible for indexing and enriching the logs, the SIEM intelligent head works to correlate and derive meaning from the logs, perform the automated tasks, maintain the devices inventory,provide platform administration, SIEM reporting, and providing user console. 

The figure below illustrates the deployment of a typical SIEM platform. Organizations running the OpenMRS platform should consider deploying the available open source SIEM solutions such as the Wazuh to ensure visibility into the OpenMRS network and the organization IT network as whole. The documentation for implementation of Wazuh platform can be accessed on: Wazuh SIEM monitoring platform documentation

Infrastructure  Security

The choice of hosting of the OpenMRS platform defines the security efforts required by the organization to ensure the availability, integrity and confidentiality of the platform and the data stored. Irrespective of the choice of deployment, the organization has to ensure that the hosting environment is secure. The organization also has to make sure that all the softwares  for different building blocks are updated and patched with the latest versions.  This can be achieved through the Patch and Vulnerability  Management Program (PVMG)

Patch and Vulnerability Management 

The patch and vulnerability management program (PVMG) outlines the requirements for keeping the organization’s systems updated with most current versions of their software. The program functions

1. To fix vulnerabilities or bugs in a timely manner in order to reduce the risk of confidentiality, integrity and availability to the information systems

2. To ensure that patches are first validated and researched to determine the patch signature, pre/post requisites and dependencies.

3. To ensure that patches are formally tested prior to being deployed so as to capture any unexpected behavior on the system and to ensure that patches are deployed in a timely manner.

4. To ensure that new security vulnerabilities are identified, evaluated, prioritized and remediation tested and applied accordingly in a timely manner.

Patch and Vulnerability Management Program 

• Patches shall be consistently and promptly applied to systems in order to address security issues, update system services, fix stability and performance issues, or to add features to the system or applications.

• The patch and vulnerability management program shall adopt a risk based approach.

The responsibility of patching will be shouldered by both the security team and the system administrators. 

The cybersecurity team shall:

1. Conduct automated or on demand scanning for patches and vulnerabilities across the enterprise.

2. Disseminate patch management & vulnerability advisories: in a timely manner to the PVMG.

3. Create an organization specific remediation database that needs to be applied in the enterprise systems.

4. Verify vulnerability remediation through network and host vulnerability scanning to verify that vulnerabilities have been successfully remediated. 

5. Regular progress reports and meetings: convene sessions with the PVMG, Service Owners and Custodians to review progress of the patch management process.

The PVMG team shall;

1. Make use of the organization system inventory: the group shall use existing asset inventories to determine which hardware equipment, operating systems and software applications are used within the organization. 

2. Prioritize vulnerability remediation: In coordination with the Cyber Security Team, the PVMG shall prioritize the order in which the business addresses vulnerability remediation.

3. Test remediation or patches before they are applied: where technically feasible, the PVMG shall test patches before they are applied in production.

4. Deploy vulnerability remediation: the PVMG team shall be accountable for patch and vulnerability management activities in their respective areas.

5. Perform automated deployment of patches: where technically feasible, the PVMG shall deploy patches automatically using an enterprise patch management tool. Alternatively, manual procedures shall be employed. 

Prioritizing patching and Vulnerability Remediation 

In order to take the right corrective action in addressing the vulnerabilities in the different softwares, there is a need to prioritize the vulnerabilities appropriately. The PVMG shall make the following considerations when prioritizing the vulnerabilities:

1. Determine the ease of exploitation of the threat or vulnerability. 

2.  Risk is acceptable involving the Information (Data) owner where necessary.

Remediation Testing Guidelines 

Remediation testing guidelines are as outlined below: 

1. Most vendors provide some type of authentication mechanism. The downloaded patch should be checked against any of the authenticity methods the vendor provides, including cryptographic checksums, Pretty Good Privacy (PGP) signatures and digital certificates. 

2. A virus scan should also be run on all patches before installation. Before running the scan, the PVMG shall ensure that the virus signature database in the antivirus program is up to date.

3. Patches and configuration modifications should be tested on non-production systems since remediation can easily produce unintended consequences. 

4. Installing one patch might also inadvertently uninstall or disable another patch. If there is a dependency, there is the need to ensure that patches are installed in a certain sequence. Also, it is important to determine whether other patches are uninstalled when a particular patch is installed.

5. Testing should be performed on a selection of systems that accurately represent the configuration of the systems in deployment.

Patch Deployment Timelines

Any patches required in response to a security incident, Threat Action Notices, Vulnerability Notification or penetration testing report shall be reactively installed in line with the prioritization schedule below, specified in calendar days from the point of patch release:

User Access Management 

User access review refers to the periodic assessment of credentials and privileges of users who can access a computer system or server, shared folder or drive or a specialized system, program, application or other information system resources (e.g. communication equipment/telephony) used to perform one’s duties. 

Accountability for actions taken on an IT resource belongs to the owner of the specific USERID or username under which those actions take place. To ensure total ownership of the responsibility, the organization should put in place a user acceptance document that clarifies the responsibilities and obligations of the user while interacting with the OpenMRS platform or with different systems hosting the OpenMRS platform. 

The user access management program places different expectations and responsibilities on different stakeholders that  interact with the platform as discussed below ;

1. Every platform user is responsible for securing the USERID and password issued to them for access to the OpenMRS platform or any other information system integrated with the platform. All the users should choose passwords that meet the basic requirements for securing passwords including the password complexity, minimum length of 8 characters, a combination of uppercase letters, lowercase letters, numbers, and symbols. The system design should hence incorporate the basic requirements for passwords allowing users and administrators to set and use only passwords that meet the requirement .

2. Line managers, information owners and system custodians must ensure that all system accesses are authorized and appropriate for the job roles of staff. Where applicable, all appropriate access forms must be filled by the requestor and reviewed by the line manager/departmental head and information owner before submitting to the system custodian for action.   

3. Information owners, heads of department, section heads or line managers and  HR should also ensure that timely information is sent to system custodians for well-timed user registration (and de-registration) as occasioned by new joiners, staff/role changes and exits. This information should be formally communicated as necessary using the established communication channels (e.g., exit notification mailing list).  

Logical Access Request 

In order to be granted access users should fulfill all the requirements as dictated by the company  system access policies. The official access request workflows applicable to business units shall be completed whenever access to any OperMRS platform or any information resource is requested.

User Account Management Procedure.

The access request shall, as a minimum, gather the following information from the user to allow for processing:

• Full name;

• Surname;

• Employee unique number;

• Telephone number;

• Electronic mail;

• System/Application;

• Request justification;

• Request Identification number;

• Date

The access request shall, at the minimum, be approved by the following parties to authorize the access

requested:

1. User’s line manager – to ensure that the requested access is indeed needed and that all other details supplied are correct; e.g. business case submitted/attached with the request.

2. Appropriate Information Owner of the system/application/resource for which access is requested.

3. The system custodian – to effect the access

Grant Logical Access

Granting access to a user is one of the most important activities performed on a daily basis within the organization as this enables the user to perform his/her role in the organization. Having access to a specific information system is, however, also a privilege that should not be abused.

To prevent the abuse of access to systems, it is imperative that access is granted in an orderly manner after a number of basic verifications have been performed. As a basic rule only least privileges shall be provided when granting access. The following lists the basic verification points:

1. Access shall only be granted upon receipt of an official request and the original authorized access request.

2. Access shall only be granted upon positive identification and authentication of the user requesting the access.

3. Access shall only be granted with the authorisation of the relevant information system owner and the user’s manager.

4. Access shall be granted according to the principle of least privileges needed to perform the user’s specific role in the organization.

User Access Review Implementation Guide 

User access review refers to the assessment of the existing user database for compliance with the access management policies. It includes auditing the user rights and privileges to ensure adherence to the need to know policy and the least privilege policy.  As an implementation guide user access reviews should consider the following: 

1. Overall user access rights should be reviewed by information owners as follows: monthly for the systems in the list defined by risk department, bimonthly for all other systems and after any changes e.g., job role changes or termination of employment.   

2. User access rights should be reviewed and re-allocated when employees move from one section to another; both the line manager (of the previous role held) and end user have a responsibility to ensure system access is aligned, a request to have the previous access rights removed should be made to the system custodian by either the line manager or the end user affected.   

3. Authorizations for special privileged access rights should be reviewed at least quarterly. 

4. Access to generic (shared) or service accounts must be limited and strictly controlled.  

5. Changes to privileged accounts should be logged for periodic review; on a monthly or bimonthly basis depending on system categorization, and as an added layer of control, system custodians should send information owner’s snapshots of current user access matrices for confirmation and follow up activity.   

In the case of a shared IT resource, the system custodian should ensure that the resource (newly created or existing) has a designated information owner(s). The designated information owner(s) will be responsible for the information in the shared resource and identifying who should have access to it.

Summary – User Account Management Roles & Responsibilities  

The table below shows a summary of the roles and responsibilities of different participants in the management of user access to the OpenMRS platform and other information systems. 

Endpoint Security 

An endpoint is any device used by the users to connect to the corporate/LAN network. It includes laptops, desktops, digital printers, phones, tablets and point-of-sales (PoS) systems. An endpoint, therefore, becomes part of the network once access to the network has been granted. Endpoints therefore can be a major source of security exposure if proper security posturing is not carried out on the devices. The organization should implement an endpoint security solution that provides protection against virus and malwares. The endpoint protection solution should also allow the organization to remotely administrate and control the endpoint incase of any breach. In order to protect against the spread of attacks resulting from a compromised endpoint, the solution should be able isolate and quarantine the endpoint from the wider network, allowing the endpoint administrator to carry out the necessary security checks on the device before access is granted. The organization should also ensure that the choice of endpoint security solution should provide protection against data loss and theft by providing the capabilities to logically lock the USB ports of the endpoints to limit the transfer of sensitive data from the endpoint. The solution should be intelligent enough to be able to decipher the different classification of the organization data and documents, allowing the end users to only share documents that are not sensitive and confidential. Additionally, the endpoint security solution should be configured to provide for encryption of the data stored on the device. The administrator should also configure the endpoint security solution to authenticate and authorize the users before granting access to the system ensuring integrity and confidentiality of the data stored on the device. There are several endpoint security management solutions including endpoint detection and response (EDR), Mobile device management (MDM) and Extended detection and response (XDR) solutions which organizations implementing the OpenMRS platform can leverage on to ensure the security of the endpoints. 

Network Security

Network Security focuses on the technical and operational measures to protect network infrastructure, data, and users from cyber threats. This includes implementing firewalls, intrusion detection systems, encryption, and access controls to prevent unauthorized access, data breaches, and other security incidents. Network security is proactive, continuously evolving to adapt to emerging threats and vulnerabilities. The network security controls deployed should be able to inspect and detect vulnerabilities and attacks at the point of entry into the network. Significantly, at the network level, the firewall plays a crucial role in controlling the traffic that can get into the network. When deployed as a next generation  firewall (NGFW), the firewall is not only able to inspect traffic up to layer 4 of the OSI model but also does the layer 7 network control functionalities. The NGFW deployment capabilities include intrusion detection, network segmentation, intrusion prevention, application control, web filtering and secure software defined wide area network (SD WAN). 

Network Segmentation

Network segmentation refers to the practice of dividing the internal network/local area network (LAN) into different segments that allows the network and security administrators to adapt to different security requirements. Network segmentation requires  the evaluation of the organization's risk appetite to determine which components of the network to be grouped together, to ensure the effectiveness of the process while also allowing continued access to the network as required by different users. With proper implementation, network segmentation also limits lateral (East <>West)  movement of traffic  and consequently the lateral reach of attackers in case of breach, These segments become logically isolated and sealed off unless an implicit access between the segments are granted by the administrators. This in effect shrinks the attack surface thereby ensuring security of the different workloads in different network segments. Organizations implementing the OpenMRS system in their environments can segment and host the application components in separate network segments limiting the reach of the attackers on the platform and the environment as  whole.

Intrusion Detection Prevention System (IDPS).

An intrusion detection prevention system (IDPS) is a technology that continuously scans and monitors the 

networks for vulnerabilities, attacks and compromise. By implementation, the IDPS is deployed at the network boundary, allowing the device to check all the network traffic and events at the point of entry into the network. The technology uses signature-based and/or statistical anomaly-based-detection to identify and block attacks before they reach the protected network. The signature-based detection method relies on the readily available signatures referencing different attacks and vulnerabilities. These signatures are available and downloaded into the IDPS from the global and vendor threat intelligence centers. The IDPS scans the incoming traffic against the available database checking for matches before traffic is allowed entry into the network. The statistical anomaly-based-detection randomly samples network traffic and compares samples to performance level baselines. When samples are identified as being outside the baseline, the IPS triggers an action to prevent a potential attack.

Application Control and Web Filtering 

The NGFW also allows the network administrator to control the content that can be accessed by the internal users. This is particularly important as it allows the administrators to control access to compromised sites and command and control centers (CnC) which may increase the organizations susceptibility to the online attacks. It also allows network administrators to prioritize application traffic ensuring that no application hogs bandwidth causing poor access experience on other platforms hosted within the same environment. Network administrators for environments hosting the OpenMRS service should inventory all other applications and services running on the same environment and configure the network access priorities commensurate with the requirements of the applications. Where possible, access to the critical  applications such as OpenMRS should be made available on a dedicated connectivity to prevent competition from resources from other non-essential services. This will ensure availability of the platform especially for the public deployment model where the platform is also accessible over  the internet. 

Firewall Hardening Standard 

As discussed above, firewalls play a major role in securing the network infrastructure. The decision on the placement, management and configuration of the firewall is therefore crucial in ensuring that the OpenMRS platform and the hosting environment is secured. The firewall standard presented below defines the controls and requirements that must be followed for implementation and configuration of firewall network devices in the network in order to enhance the infrastructure security and mitigate threats.

The information provided in this section of the document outlines the controls required to be in place, in order to ‘harden’ the security of the Firewall devices in the network. Each requirement is followed by a description, a justification for the need of it and an indication of whether it is Mandatory (M), Recommended (R) 

Secure Web Application Development Standard 

The Web Application Security standard lays out the general requirements for implementing Web App Security and Web App Server Security in the OpenMRS hosting environment. This standard serves as a reference point for product and service teams who are involved in securing web apps and web servers, including but not limited to designers, developers, testers, product owners as well as security architecture and assessment specialists.

The standard requires the implementation of the following requirements: