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
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 :
Cyber security discovery and baselining
Remediation
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
Public deployment model
Private deployment model
All the deployment models have the 3 basic components
Application hosting environment
The network access layer
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:
Vulnerability assessment and penetration testing (VAPT)
Threat Modeling
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:
Relevant threats to organizations or threats directed through organizations against other organizations;
Vulnerabilities both internal and external to organizations;
Impact (i.e., harm) to organizations that may occur given the potential for threats exploiting vulnerabilities
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:
Risks associated with access layer
Risks associated with the network layer
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
Application Security
Network Security
Infrastructure Security
Monitoring and Logging
User Access Management
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
Reputation
Privacy of User Data
Availability
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
Endpoint Monitoring
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
To fix vulnerabilities or bugs in a timely manner in order to reduce the risk of confidentiality, integrity and availability to the information systems
To ensure that patches are first validated and researched to determine the patch signature, pre/post requisites and dependencies.
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.
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:
Conduct automated or on demand scanning for patches and vulnerabilities across the enterprise.
Disseminate patch management & vulnerability advisories: in a timely manner to the PVMG.
Create an organization specific remediation database that needs to be applied in the enterprise systems.
Verify vulnerability remediation through network and host vulnerability scanning to verify that vulnerabilities have been successfully remediated.
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;
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.
Prioritize vulnerability remediation: In coordination with the Cyber Security Team, the PVMG shall prioritize the order in which the business addresses vulnerability remediation.
Test remediation or patches before they are applied: where technically feasible, the PVMG shall test patches before they are applied in production.
Deploy vulnerability remediation: the PVMG team shall be accountable for patch and vulnerability management activities in their respective areas.
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:
Determine the ease of exploitation of the threat or vulnerability.
Risk is acceptable involving the Information (Data) owner where necessary.
Remediation Testing Guidelines
Remediation testing guidelines are as outlined below:
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.
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.
Patches and configuration modifications should be tested on non-production systems since remediation can easily produce unintended consequences.
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.
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 ;
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 .
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.
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:
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.
Appropriate Information Owner of the system/application/resource for which access is requested.
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:
Access shall only be granted upon receipt of an official request and the original authorized access request.
Access shall only be granted upon positive identification and authentication of the user requesting the access.
Access shall only be granted with the authorisation of the relevant information system owner and the user’s manager.
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:
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.
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.
Authorizations for special privileged access rights should be reviewed at least quarterly.
Access to generic (shared) or service accounts must be limited and strictly controlled.
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
|
|
Information Owners |
|
Human Resources |
|
System Custodians |
|
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.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 |