Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

From this original document:

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

Abbreviations and Acronyms

Abbreviation/Acronym

Definition

API

Application Programming Interface

AUP

Acceptable Usage Policy

DDOS

Distributed Denial of Service 

DNS

Domain Name System

HTTP

HyperText Transfer Protocol

HTTPS

HyperText Transfer Protocol Secure

IT

Information Technology

LAN

Local Area Network

MFA

Multi-Factor Authentication

MDM 

Mobile Device Management

OWASP

Open Web Application Security Project

PIM

Privileged Identity Management

PVMG

Patch and Vulnerability Management 

RBAC

Role-Based Access Control

RMS

Rights Management System

SFTP

Secure File Transfer Protocol

SIEM

Security information and event management

SSL

Secure Sockets Layer

VAPT

Vulnerability Assessment and Penetration Testing 

WAF

Web Application Firewall

XDR

Extended detection and response

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. 

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

Figure 1: OpenMRS Application Deployment Environment

Cyber security 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.

Figure 3: OpenMRS Application Public Deployment Model Access Path

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 

Figure 4: OpenMRS Application Public Deployment Model Risk Assessment

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. 

Fig 5: Risks associated with Private  deployment model

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

Fig 6: SIEM deployment architecture

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:

ASSESSED PRIORITY

PRIORITY DESCRIPTION

TIMELINE

EMERGENCY

Critical priority Common Vulnerability Scoring System (CVSS) exploit information is notified; AND

‘Zero day’ vulnerability affecting hardware/software used by organization ; OR

Vulnerability being actively and successfully exploited by threat actors to breach the organization or other integrating organization’s

Cyber Security Team and PVMG shall jointly agree whether vulnerability and associated patches meet criteria for using the P0 Crisis Management process, and jointly agree deadlines for deployment.

Time from patch issue to deployment shall not exceed 7 calendar days under any circumstances.

Normal levels of patch testing may be reduced or removed due to the level of risk posed by not patching.

CRITICAL

Potential for Intolerable/Major business impact; OR

High value information at actual or potential risk of exposure; OR

Critical rated vulnerability is identified

Deploy without undue delay and as soon as testing has shown patches to be safe. Deadline for deployment shall be jointly agreed between the Cyber Security team and PVMG on a case by case basis.

Deployment timeline shall never exceed 15 calendar days under any circumstances.

HIGH

Potential for Significant business impact; OR

Valuable information at risk of exposure; OR

High rated vulnerability is identified.

 

Remediation shall be applied within 30 calendar days  and within 90 calendar days if internally exposed.

MEDIUM

Potential for Moderate business impact; OR

Valuable information at limited risk of exposure; OR

Medium rated vulnerability is identified.

Remediation by software update: Next Planned Lifecycle software update or release. 

 

Remediation by configuration hardening: within 90 calendar days internet exposed, within 180 calendar days internally exposed. 

 

LOW

Potential for Minor business impact; OR

Valuable information may be at risk of exposure; OR

Low rated vulnerability is identified.

Remediation by software updates: next Planned Lifecycle software update or 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. 

ENTITY   

SECURITY ROLE   

  

Employees/Contractors/Third Parties 

  

  1. Responsible for securing the USERID and password issued to them for access to OpenMRS and information systems.    

  1. Comply  with  the requirements of policies, confidentiality/nondisclosure agreement & acceptable usage policy which is signed by all staff. 

  1. Obtain approval for access request forms from line manager or departmental head, information owner and system custodian.   

  1. To refrain from using another employee’s USERID and/or password or sharing their own.  

  1. Request for system access revocation or privilege change whenever the employee changes job roles  

Information Owners

  1. Establish the rules of behavior for the appropriate use and protection of the information or data in the information systems owned.  

  1. In conjunction with the users’ line managers, decide who should have access to the information system and determine what type of privileges or access rights are to be granted based on job role.  

  1. Maintain and update access matrices for information systems under their jurisdiction.  

  1. Perform review of system access based on the access matrices, at least monthly or bimonthly depending on system categorization.  

  1. Ensure movers get necessary approval for system access and that redundant access is revoked; this is in conjunction with the HR communication.  

  1. Ensure leavers are de-registered from applications, systems, shared folders and mailing lists via communication to appropriate system custodian.  

  1. Ensure monthly and bimonthly user access reviews are done on time for all systems under their care and notifications sent to the relevant system custodians for action.

Human Resources 

  1. Send revocation request, via established communication channels, on leavers and movers to system custodians, information owners and appropriate line managers to facilitate user access de-registration.  

  1. Send access requests to system custodians for account creation.  

  1. Ensure all staff (permanent, temporary or contractors) have signed the confidentiality agreement and acceptable usage agreement prior to granting of system access.  

  1. Ensure all staff (permanent, temporary or contractors) have signed the confidentiality agreement and acceptable usage agreement prior to granting of system access.  

System Custodians

  1. Ensure timely granting or revoking of user access based on officially documented requests.  

  1. Review user access for all users monthly or bimonthly (depending on system categorization) by seeking confirmation from information owners who maintain the access matrices.  

  1. Approve, monitor, and log events for user accesses as detailed in corporate standards and policies.  

  1. Ensure shared drives/folders, servers, applications, or any other system resources have designated information owner(s) before creation or installation. 

  1. Ensure de-registration of staff (movers and leavers) includes revoking redundant access from applications, systems, shared folders, mailing lists and other IT resources.  

  1. Maintain remote access (VPN) register for all VPN users.  

  1. Where possible, automate the user account management process for easier and effective access management.   

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) 

  1. Management Plane controls 

1.1  Infrastructure Protection 

1.1.1 

  Configure the hostname of the device

It is suggested to define the name of the device following the VCNO node naming convention. Each device’s hostname should contain the country’s initials, the city’s initials, the type of the device (FW for Firewall) and the number of the node 

Required for identification purposes

M

1.1.2

Configure a management IP address 

Set an IP address for management purposes on the devices; this IP address must be on a segregated subnet and management traffic must not go via production interfaces and must adhere to the zoning standard. 

Setting a management IP segregates management traffic and data traffic whilst preventing snooping.

M

1.1.3

Require a loopback address

To ensure continuity of source addressing of the services on the firewall, a Loopback address should be used

Issues can arise if services do not use the same source address, it can potentially cause packets to be handled incorrectly by receiving hosts.

R

1.1.4

Configure login banner 

Display a warning banner when a user connects to the device. The warning banners must be the same on all Firewalls

In some legal jurisdictions it can be impossible to prosecute and it is illegal to monitor malicious users, unless they have been notified that they are not permitted to use the system. 

M

1.1.5

Set at least two IP name servers 

Specify the address of two name servers to use for name and address resolution. The local or the zone internal servers must be used and should be located in separate geographical locations to provide resiliency 

Defining a name server ensures that the authorized/designated server responds to the client request.

R

1.1.6

Configure thresholds for load monitoring 

The network element must generate an event if the amount of CPU usage or memory usage breaks the operator- configured threshold.

Running low in memory is usually caused by increased traffic, which can potentially be an indication of DDoS attack.

M

1.2 Password Policy

1.2.1

Encrypt configuration passwords 

The strongest password encryption method must be applied to all passwords, based on the device’s capabilities, including username passwords, authentication key passwords, the privileged command password, console, virtual terminal passwords, etc. 

Passwords must always be encrypted and they shall never be displayed in plain text, therefore preventing a non-authorised user from having visibility of the passwords.

M

1.2.2

Create a fall back account

Create a local user for fall back access purposes.

The local (fall back) account can be used to access the device if all AAA servers become unavailable, providing emergency access. 

M

1.2.3

Set an encrypted management password 

Define the management or root password for the device. The strongest encryption method must be used, based on the device’s capabilities.

The management password is used to gain access to the exec shell, or equivalent, using the console or a remote connection. 

M

1.3 Unnecessary services 

1.3.1

Disable HTTP web management service and use HTTPS where possible  Disable HTTP web management service and use HTTPS where possible 

Disable the HTTP service, which is an unsecure protocol and shall not be used to manage firewalls. Use HTTPS web management to ensure data is protected across the network.

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks.

M

1.3.2

Disable DHCP Server and DHCP relay services 

Disable DHCP server, which are used for dynamic IP assignment, as only dedicated DHCP servers must be able to provide IP addresses to other devices

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks

M

1.3.3

Disable DDNS services  

DDNS should not be used within private address space to prevent inconsistent configurations between services.

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks. 

M

1.3.4

Disable the neighbor discovery protocols for external facing interfaces 

The exchange of device information via neighbor discovery protocols must be prohibited via external interfaces (Internet, 3rd party access, external leased line). 

Neighbor discovery protocols must be disabled unless explicitly required, as the protocol can potentially leak device information to rogue users on the network.

M

1.3.5

Prohibit telnet connections 

Define that remote connection can be established to the firewall only via secure protocols. 

Only secure communications must be allowed, in order for the traffic to be encrypted and protected from sniffing attacks.

M

  1.4 Connection security 

1.4.1 

Enable TCP keepalives for inbound and outbound connections where supported

TCP keepalives must be configured, as they check that the device on the remote end of the connection is still accessible

Enabling TCP keepalives ensures that half−open or embryonic connections are deleted by the device.

M

1.5 Interactive Management Sessions 

1.5.1 

Enable SSH Version 2 

Only secure connections must be allowed.

  SSHv2 is considered to be more secure than the v1 which is known to have vulnerabilities. 

M

1.5.2

Generate encrypted key for SSH 

Generate an encrypted key to be exchanged during SSH communication initiation. 

Data is transferred encrypted via SSH communication

M

1.5.3

Define inactivity time out for both console and remote sessions 

A predefined inactivity time-out period must be configured on the firewall to logout remote sessions that have been left idle.

Required for ensuring that the session is used by an authorized user and has not been left unattended. 

M

1.5.4

Define the allowed authentication retries for SSH connections 

Specify the number of attempts a user has before the connection resets.

This ensures that after a set number of attempts the SSH session is disconnected and possible brute force attacks are prevented.

M

1.5.5

Use authentication method for both console and remote management sessions

Define a specific password for remote authentication and specify that an AAA method must be used for authenticating user login via interactive management sessions. 

Necessary service for authenticating and identifying remote login users.

M

1.5.6

Forbid the installation of externally sourced scripts, other than provided by the manufacturer or sanitized first before use

  Scripts can be useful to perform tasks on the device but should only be used under specific circumstances

Externally sourced scripts may have malicious content and should not be installed onto the system under any circumstances.

M

1.6 AAA  

1.6.1

Set the source IP address for the AAA server 

Associate an interface’s IP address to the packet sent to the AAA server regardless of which interface the packet exited the device facilitating the analysis of the logs.

Specifying the address that the device sources management traffic from, ensures that the network can be configured in a prescriptive manner, reducing an attacker’s opportunities

M

1.6.2

Authenticate communication with AAA server

Define a key to be used for communication with the AAA server in- line with password policy 

Communication with the AAA server must be authenticated prior to exchange of any messages for assuring the communication security. 

M

1.6.3

Define the login authentication method to be AAA compliant 

Define that the AAA method must be used for login authentication and for gaining access to the privilege/configuration mode. 

The default authentication method must be AAA compliant, since it provides better security when transferring the packets and supports multiple communication protocols

M

1.6.4

Enable user authorisation 

Authorize a user’s actions depending on the permissions granted from the AAA server, only if he has been authenticated first. 

Ensures that appropriate authorisation and permissions are being granted to the user when accessing the device.

M

1.6.5

  Enable accounting to monitor the user’s actions

Provide information about the user’s actions including authorisation failure, configuration commands, system changes and all the connections made from the network access server, ensuring that periodic updates are sent to the AAA server. 

Information logged by the AAA accounting options can be valuable during the investigation of an attack. 

M

1.7 Logging  

1.7.1

  Define the time zone 

Time zone information shall be expressed in universal time coordinates (UTC) in alignment with NTP servers 

Necessary for synchronizing the log files. Accurate timekeeping is critically important for correlating network events.

M

1.7.2

  Configure timestamps for logging 

Attach timestamp information to the log and debug files. Timestamp information shall express absolute time, not time since the last power-on / reboot of the network element.

Necessary for auditing purposes and for identifying the exact time during which a change took place

M

1.7.3

Logs must be sent to at least two logging servers

Logs should be replicated on at least two logging servers to provide redundancy of events for resiliency purposes.

Logging is critical to device security because it creates an audit trail of system activity. 

M

1.7.4

Set the source IP address for the syslog

An interface’s IP address must be associated with the packet sent to any external device, regardless of which interface the packet exited the device, facilitating the analysis of the logs. 

Specifying the address that the device sources management traffic from ensures that the network can be configured in a prescriptive manner, reducing an attacker’s opportunities.

M

1.7.5

Configure notifications to be sent to a syslog server 

Send logs to syslog server above warning messages including errors, critical & emergencies. 

Allows the administrator to focus on and process the logs that need immediate attention/action and which might pose a security risk. 

M

1.7.6

Enable the logging for all interactive management sessions 

Logging on interactive management sessions must be enabled

Logging is critical to device security because it creates an audit trail of system activity.

M

1.7.7

Define names for firewall policies, where supported

Firewall policy should be named; the name should be the ticket reference from where the policy change was requested.

Naming the firewall policies is required to create an audit trail to allow for changes on the firewall policy to be tracked.

R

1.8 Border Device Filtering 

1.8.1

Enable anti-spoofing for both inbound and outbound traffic where supported 

  Verify that both inbound and outbound traffic from the network has a valid source address. 

Filtering denies any traffic that does not have the source address that was expected on a particular interface

M

1.8.2

Unicast Reverse-Path Forwarding where supported

  Ensure RPF is enabled to verify source addresses. 

A number of different attacks rely on spoofing the traffic source address. By verifying the source address it will enable the firewall to drop attack traffic. 

R

2 Control Plane controls

2.1 Border Gateway Protocol (BGP)

2.1.1

Enable BGP Authentication 

Authentication between BGP neighbors should be enabled; MD5 password authentication or keychain must be used to secure BGP sessions. 

Authentication between BGP neighbors should be enabled; MD5 password authentication or keychain must be used to secure BGP sessions. 

M

2.1.2

Enable logging for neighbor changes, if applicable 

The device must be configured to log BGP neighbor resets. 

Logging of neighbor changes ensures that all changes are retained and facilitates investigation of a potential attack.

M

2.1.3

Maximum prefixes limit must be enforced for external connected peers 

A limit must be applied regarding how many BGP prefix records a firewall can store in its memory. Must be used on all customer BGP sessions 

Limiting the BGP prefixes is required for ensuring the effectiveness and the functionality of the firewall. 

M

Limit BGP AS path length for external connected peers, if applicable 

Maximum AS path length should be configured to protect elements from errors and mis-configuration. 

Overlong AS paths should not be expected in normal circumstances and are symptomatic of problems within external networks. 

2.1.4

Specify a Time to Live, if unavailable use maximum number of hops for eBGP peers. 

A maximum TTL should be configured so that BGP packets are received from directly connected peers. 

This prevents the firewall from receiving potential malicious or false BGP advertisements and reduces the possibility of the device receiving false firewall updates that would allow an attacker to potentially corrupt the route tables, compromise network availability or redirect network traffic. 

M

2.2 Interior Routing Protocol Security 

2.2.1

Neighbour Authentication 

Neighbor authentication, such as MD5 password or key authentication, depending on the firewalls capabilities, must be used between neighboring devices exchanging routing protocols updates

A strong authentication algorithm will enhance the connection security and ensure that routing messages are exchanged between only authorized neighbors. 

M

2.2.2 

Enable routing only on participating interfaces 

Explicitly enable routing updates for those interfaces that need to participate in the routing updates. 

Ensures that only authorized interfaces participate in the routing procedure, protecting the network from receiving rogue updates. 

M

2.2.3

Enable routing updates only on the participating interfaces

Ensure that non-participating interfaces in routing updates are passive and packets are not sent or received on those interfaces. 

This prevents an interface from sending or receiving packets if it has not been specifically allowed, reducing the size of the device's attack footprint. 

R

2.3 NTP 

2.3.1

Configure at least two NTP servers or create specific NTP access groups 

Configure two NTP servers, which are part of the relative zone in which the device belongs, with one being preferred. Should be located in separate geographical locations to provide resiliency. 

Accurate and reliable time is required in order to ensure that logs can be compared across systems when investigating potential attacks. Using at least two servers provides redundancy. 

M

2.3.2

Authenticate NTP communications

Create an encrypted NTP authentication key and authenticate all NTP connections via the configured key

NTP authentication shall be configured to provide assurance that NTP messages are exchanged between trusted NTP peers, reducing an attacker’s opportunity to affect timestamps on system logs or affect other time-dependent services.

M

2.3.3

Disable NTP on external interfaces

Block an interface from sending or receiving NTP messages. 

  Reduces the footprint of the device by limiting the interfaces it sends NTP packets out of internal interfaces only. 

M

2.3.4

Configure the source address for NTP 

An interface’s IP address must be associated with the packet sent to any external device, regardless of which interface the packet exited the device, facilitating the analysis of the logs. 

By assigning a specific source interface to messages, consistent device identification is ensured and logging management is simplified. 

M

3 Data Plane Controls

3.1 Layer 2 Security 

3.1.1

Disable unused ports 

Disable all unused ports and place them in an unused state that is isolated from the rest of the network. 

Unused interfaces shall be disabled to prevent unauthorized use. 

M

3.1.2

Do not use default VLANs for management traffic 

Set a secure VLAN for management purposes and disable VLAN 1 which is the default in most of the firewall devices. 

Setting a management VLAN segregates management traffic and data traffic and prevents snooping. 

M

3.1.3

Configure interfaces to be in the correct zone 

External interfaces must be identified as untrusted and all internal interfaces must be configured in accordance with the VCNO Zoning Standard. 

By identifying interfaces as untrusted it enables screening to be performed on traffic.

M

3.1.4

Disable source routing

IP source routing must be disabled. 

This feature must be disabled as an attacker can exploit the IP options to affect the way a device forwards the packets and avert security controls 

M

3.2 Connection Controls

3.2.1

Limit concurrent sessions from singular external client 

Limits should be placed on client connections to protect flooding the network.

Attackers can attempt to flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.2

Limit the amount of connections received on external interfaces

Limits should be placed on incoming connections to protect flooding the network. 

Attackers can attempt to flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.3

Limit the amount of connections sent on external interfaces 

Limits should be placed on outgoing connections to protect flooding the network. 

Services can flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.4

Limit requests per second on external interfaces 

Limits should be placed on the number of outgoing connections per seconds to protect flooding the network. 

Services can flood the network causing a denial of service with connections if thresholds are not in place.

M

3.2.5

Screen on untrusted and semi-trusted interfaces on external interfaces 

Screening should be performed on non-trusted interfaces. 

Screening is mandatory on non-trusted network to protect against malicious traffic, 

M

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:

Mandatory Requirement (MR)

Technical Requirement 

MR1

Web application input and output must clearly define how to handle and process data based on type, content, and applicable laws, regulations and policy compliance 

MR2 

All web applications must be designed to handle authentication in a secure manner and apply access and authentication best practices

MR3 

All web applications must be designed to handle authorization in a secure manner and apply access and authentication best practices 

MR4 

All web applications must include secure session management requirements

MR5 

All web applications must apply input validation controls such as HTML entity encoding, checking for correct syntax, strongly typed data and that numbers are correctly signed within range boundaries 

MR6 

Output encoding for web applications must occur close or adjacent to the interpreter

MR7

Web applications which use systems language or unmanaged code must apply memory, string and unmanaged code requirements 

MR8 

Web applications must prevent insecure deserialization 

MR9

Web apps must apply approved cryptographic algorithms, modes and libraries

MR10 

Error handling and logging must be protected and handled securely per its data classification 

MR11

Client-side data protection must be applied 

MR12 

Sensitive data must be protected from being created, read, updated or deleted without authorisation 

MR13 

All client communication must only take place over encrypted communication paths and apply Transportation Layer Security Hardening Guide 

MR14 

Secure connections to and from monitoring systems, management tools, remote access and SSH, middleware, database, mainframes, partner or external source systems must be in place  

MR15

Software code itself must satisfy integrity controls (e.g. checksum, HMAC, encryption, digital signature) to ensure that the data has not been tampered with and is the same as before 

MR16 

Applications must be protected against common attacks such as executing unsigned code from untrusted sources and sub-domain takeovers

MR17 

Business logic flow must be sequential, processed in order and must not be bypassed and include limits to detect automated attacks 

MR18

Untrusted file data obtained from untrusted sources must be stored outside the web root.

MR19 

Applications must use Trusted Service Layer APIs (e.g. JSON, XML, GraphQL) and must have adequate authentication, session management and authorisation of all web services

MR20

Application build and deployment must be performed in a secure, repeatable, automatable build environment 

MR21

Dependencies must be managed using a dependency checker during build or compile time

MR22

Production environments must be hardened to protect against common attacks and unintended information disclosure 

MR23

HTTP request header requirements must be validated in the application according to industry best practice

MR24

Web application server hardening guidelines must be applied using approved guidelines and Standards 

MR 25 

All applications must pass a data assurance check to prevent sensitive data leakage 

  • No labels