Last updated January 2025

Title of Contents

Policies and Practices

• All HIEs should have accompanying policies that identity specific user roles and responsibilities for the different components of the Health Information Exchange.

• These policies must align with local data protection laws and policies

Server Administration, Port Configuration and Networking

Server Administration

• Each administrator should have their own account on the server.

  • No user should be able to login via SSH as default users like “ubuntu” or “root”.

• Administrator accounts should be configured to only allow SSH access via an SSH key. It should be impossible to access the server via SSH with just a password.

• Review SSH certificate approach to ensure it follows up-to-date recommendations and standards.

VPN Setup

In order to reduce the attack surface and protect application-level access, a VPN setup can be used to ensure any user that needs to access a HIE-level service authenticates and joins the restricted private network, and only users on this network have access to the HIE functionality.

VPN encrypts web traffic by creating a tunnel between the computer and a internal network. In this case, the internal network is the HIE network, and a VPN can be used to globally protect from unauthorized access to any user-facing HIE services.

Note: For cases where a communication protocol does not support an encryption layer (eg. LIS01-A2), and is leaving a secure local network, a VPN is a necessity to ensure that the communication happens securely.

Load Balancing

For Central HIE deployment, it is recommended to use load balancing, or more than one server to spread out functionality to not put too much load on any particular server. Here is in-depth documentation for AWS on the topic:

Penetration Testing

Regular penetration testing is necessary for maintaining the security of live systems. This should be done by dedicated internal security teams and/or external security organizations.

Port Scanning

Port scanning is a necessary component of penetration testing for ensuring that the server’s state is being well maintained and vulnerabilities from open ports are not being introduced. Port scanning tools are plentiful with many common options like nmap.

Having logs of port scanning is also useful to check if your system is being probed as a target by potential hackers and should be part of an Intrusion Detection System.

Secure Networking

• Identify the critical ports that are required to be open for the HIE setup. Only required ports should be open on the server. By default, all ports should be closed, except 22,80 and 443. If the HIE setup requires other custom ports, they need to be identified and the security configurations both on the Hosting side and the HIE side require an update.

• Update the HIE configuration to allow and correctly route traffic from the necessary ports to the proper services.

• Properly configure a firewall on the Hosting environment.
  Firewalls act as a barrier to prevent the spread of cyber threats such as viruses and malware and a firewall has to be set up.

  • Provide as restrictive firewall rules as possible on the Hosting level, and only open up traffic on the critical ports, as described above.

  • Make sure to apply the least-privilege principle to both inbound and outbound rules.

  • Refer to Hosting environment documentation for firewall setup guidelines.

    • AWS: https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html

  • For production setups, use a whitelist approach to allow outgoing (and any possible incoming) connections only from a trusted list of IPs or DNS entries

Secure Access

1. Physical servers: physical access needs to be managed by storing servers in a secure server room, and managing who has access to the server room. Total disk encryption should be used for any permanent storage solutions.

2. SSH access to Cloud/Remote Servers: Principle of least privilege should be applied. Sudo access should only be given to employees and contractors that need it.

Server Certificates and Domains

• The server should run with updated certificates. Certificate expiry times should be monitored or alerts configured, so that certificates can be updated before they go out of date.

• In most situations, auto-generated and auto-renewable certificates can be used, such as those provided by Let’s Encrypt. The HIE configuration should be updated to ensure timely certificate renewal and possible notification of renewal.

• Certificate should support modern communication protocols and server configuration should disallow outdated/insecure protocols.

• The server should have a domain name.

Software/Application Management

1. Software on the server should be kept up to date to take advantage of the latest security fixes. An SOP should be created for timely updates to the production server based on an HIE release process.

2. Software on the server should be kept minimal to minimize the number of potentially insecure applications. This involves removing no longer needed programs and not installing unnecessary programs on the server and in containers.

3. Applications should not be run as a root user or with root permissions unless absolutely necessary

Account Requirements

Account Permissions

• The principle of least privilege should be applied to all users, which means identifying the minimal set of permissions that a user needs to complete their function.

  • Root account use should be avoided and only used when necessary, even for admin tasks. Instead, a admin user(s) should be created and used for maintaining the server and services.

  • SSH access: Principle of least privilege should still apply. Sudo access should only be given to employees and contractors that need it.

Usernames

• Administrators should establish clear policies on who is allowed access to the HIE.

• All users should have their own separate usernames.

  • This enables better logging and auditing to understand who did what actions when interacting with systems

Passwords

Passwords are the first line of defense in protecting access to accounts and sensitive information.

• Users should use different passwords for each application

• The use of password managers (like 1password) is encouraged to help keep track of complex passwords and usernames across applications

• Ensure you use a strong password:

  • Use at least a 16 character password with numbers, upper case letters, lowercase letters and symbols ($, %, *). The longer and more complex a password is the more difficult it is to crack. 

  • Default passwords, like admin123, root, etc. should never be used.

  • Passwords should not use words related to the system, meaning that passwords should NOT contain the name of the application (e.g. @p@nH1M for openHIM is a bad password)

  • Here’s a visual for you showing how fast it will take to crack a password.

    • 2023 Password Cracking Times: Faster Than You Think! (citation)

Open

• Password expiry

  • Critical Passwords, such as server admin passwords, should be changed regularly in-line with a password expiration policy, or at least every 3 months

  • A user password should be reset anytime that it is suspected that their password has been leaked

  • All passwords should be changed every time after a suspected data breach

Additional Authentication Methods

• Multi-Factor Authentication (MFA) should be enabled where supported

• Non-password authentication can be used where supported (such as through a hardware security key, or SSH key)

Monitoring and Notifications

Hosting Environment

Cloud services like AWS provide robust capabilities for monitoring running services. These should be properly configured and set up to alert the right people when an alarm is raised.

AWS Resources:

HIE Environment

The HIE environment comes with a monitoring module that provides a view into the HIE services, performance and networking using Grafana dashboards. This environment needs to be properly configured for the HIE setup to ensure access for required users and alerting for critical events.

The HIE environment also utilizes OpenHIM as an interoperability, security, and auditing layer. OpenHIM needs to be properly set up, with access controlled through the Keycloak ecosystem. OpenHIM access needs to be granted to only the proper individuals, and alerting needs to be set up properly as well.

Related resources

• : Alerting and reports | OpenHIM

HIE Hardware Recommendations

HIE Hardware requirements depend heavily on the scale of the HIE, the services that are running, and the load on these services. For a robust production setup targeting high throughput an auto-scaling solution that can adjust for both peaks and troughs of activity level and scale up if load becomes too high is ideal. For more basic or pilot-level setups, here are some guidelines for hardware requirements:

1. CPU: An HIE setup runs multiple services at once using a Docker Swarm-based setup. These services compete for CPU time; as a result, the number of cores should at least

2. Memory:

3. Hard Disk: The more space the better, but they should always be in a redundant RAID configuration with a backup to another server. I would not want to start with less than 10TB of space.

4. Networking

Backups and Restoration

• Back-up docker-based set-up and need to move RDS-based or data-base focused services 

• In set-ups, running on dockerized containers and there are probably ways to back-up, but can use hosted database solution for back-ups by turning on settings

• Back-up functionality sufficient for current docker, and for performance and 

Also important is actually testing your recovery strategy. You can have a “perfectly designed” backup system that happens automatically and securely, and then go to restore your latest backup only to realize that it is insufficient for actually restoring your system, or that no one actually knows HOW to restore the backup

1. Define a Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for your database. To minimize RPO, database replication via data streaming is recommended.

2. Follow 3-2-1 backup strategy

3. Total server backup can occur less frequently, but should still be quite regular

4. Define a restoration procedure that fits within your RTO

Security Checklist

Tools for Threat Mitigation.

1. https://owasp.org/www-project-top-ten/

2. https://www.sans.org/cloud-security/securing-web-application-technologies/

3. Security