Adopters Implementation Guidelines

Owned by Eric McDonald (Unlicensed)
Last updated: Aug 01, 2019 by Tabassum Jafri

Overview

The purpose of this document is to provide general guidelines to configure secure CONNECT. 

Implementation Guidelines

The following are best practices for implementing CONNECT. 

Deploying CONNECT in a Production Environment

Because CONNECT enables the exchange of health information online, adopters should take precautions to protect information. We strongly recommend that CONNECT be deployed behind a firewall that limits port access and monitors and blocks requests with suspect byte ranges on http and https ports. Appropriate system administration security practices should always be in place.

The latest information regarding security alerts for Oracle products can be found here: http://www.oracle.com/technetwork/topics/security/alerts-086861.html.

Secure Connections

  • Use a secure communication over NwHIN network and TLS protocol is expected to protect the information flowing between different channels. 
  • An exchange of valid X509 certificates required for internal and external connections that are exposed to the system.
  • Expected to verify that the certificate is signed by trusted CA and certificate is not expired.
  • Utilize TLS connections for all content requiring authenticated access and for all other sensitive information.
  • Failed TLS connections should not fall back to an insecure connection.

Database Security

  • Prohibit access to product database from any unsecured endpoints and before allowing access make sure user has permissions that are expected, otherwise expected to fail gracefully. 
  • Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted.
  • Expected to close the connection as soon as possible.
  • Remove unnecessary default vendor content (e.g., sample schemas).
  • Expected effective use of input validation and output encoding and be sure to address meta characters. If these fail, do not run the database command.
  • Required to remove or change all default database administrative passwords. Utilize strong passwords/phrases or implement multi-factor authentication.
  • Disable any default accounts that are not required to support business requirements.
  • Use strongly typed parameterized queries.

Change Default Password:

  • Change all default passwords when deploying to Production.  Below are locations where CONNECT uses during developing and testing:

  • Navigate to <binary-location>/CONNECT-<VERSION>/DBScripts/nhincdb/nhincdb.sql

CREATE USER nhincuser IDENTIFIED BY 'nhincpass';

INSERT INTO adminguidb.UserLogin (id, salt, sha2, userName, userRole) VALUES (1, "ABCD", "TxMu4SPUdek0XU5NovS9U2llt3Q=", "CONNECTAdmin", 1);

Note: To generate sha1 hash, please use the following command in unix:  echo -n <salt><userpassword>| sha1sum| xxd -r -p | base64

For Post 4.6: We rename the column from sha1 into sha2 by using sha2-512 bit, please use the following command in unix to generate new hash: echo -n <salt><userpassword>| sha512sum| xxd -r -p | base64

  • Navigate to <binary-location>/CONNECT-<VERSION>/Properties folder, change the following properties:

saml.properties:  

org.apache.ws.security.saml.issuer.key.password=changeit

signature.properties: 

org.apache.ws.security.crypto.merlin.keystore.password=changeit 

truststore.properties: 

org.apache.ws.security.crypto.merlin.keystore.password=changeit

File System Access 

  • Enable two-way TLS to authenticate and authorize users. It is expected that local access management have restricted access to the file system. 
  • Files in publicly writable directories must be treated as inherently untrusted.  It is expected to create a subdirectory with tightly controlled permissions, then write your files inside that subdirectory. 
  • Limit the type of files that can be uploaded to only those types that are needed for business purpose. Ensure to validate file mime type instead of file extension alone.
  • Scan user uploaded files for viruses and malware.
  • Expected not to pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs.
  • Ensure application files and resources are read-only.
  • Make sure the uploaded file is not larger than a defined maximum file size.

Upgrade to latest version

  • If CONNECT have latest releases to counter a possible security vulnerability, apply it as soon as possible using the correct procedure. 
  • Always use the latest version of the product, if possible, as it contains fixed to known vulnerabilities. 

Session & Transport Layer Protection

  • In order to exchange the information in network traffic, it is mandatory to use an encrypted HTTPS (TLS) connection for the entire web session. 
  • Session cannot be used to send or receive unencrypted information and It is expected to disable algorithms offering no encryption.
  • Expected to generate a new session identifier and deactivate the old one periodically.
  • Do not expose session identifiers in URLs, error messages or logs.
  • Disallow persistent logins and enforce periodic session terminations, even when the session is active. Especially for applications supporting rich network connections or connecting to critical systems. Termination times should support business requirements and the user should receive sufficient notification to mitigate negative impacts.
  • Logout functionality should fully terminate the associated session or connection and logout functionality should be available from all pages protected by authorization.
  • Do not allow concurrent logins with the same user ID.
  • Use anti caching headers to relevant sensitive responses. 
  • Configure your TLS provider to support strong (e.g., FIPS 140-2 compliant) algorithms.
  • Expected to follow NIST Transport Layer guidelines:

Authentication and Password Management

  • Require authentication for all resources and pages, except those specifically intended to be public
  • All authentication controls must be enforced on a trusted system
  • User is required to create a new passwords and not to use default or null passwords. 
  • Password reset and changing operations require same level of controls as account creation and authentication. It is expected to re-authenticate users prior to performing critical operations. 
  • Password hashing must be implemented on a trusted system. 
  • Expected to use a centralized implementation for all authentication controls, including libraries that call external authentication services.
  • Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code.
  • Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system. The source code is NOT a secure location.
  • Password entry should be obscured on the user's screen.
  • Enforce password length and password change requirements established by policy or regulation.
  • Expected to follow NIST guidelines for Identification and Authentication:
  • Expected to follow NIST guidelines for password management:
  • Expected to follow NIST guidelines for Security Management Process:

Error and Logging

  • Expected to use the log4j logging API. Use of other compliant logging mechanisms is also permitted. 
  • Proper logging of exceptional conditions is context-dependent. 
  • Do not disclose sensitive information in error responses, including system details, session identifiers or account information and expected to sanitize message appropriately before logging such exceptions.
  • It is expected that the application should handle adopter errors and not rely on the server configuration.
  • Expected to log attempts to connect with invalid or expired session tokens.
  • Expected to log all authentication attempts, especially failures.
  • Log access control failures and ensure that a mechanism exists to conduct log analysis.
  • Logging controls should support both success and failure of specified security events.
  • Ensure to implement custom error pages instead of generic error message.

Deployment Considerations

  • Security policy determines what adopters are allowed to do and what the users of the application are permitted to do. 
  • Expected to Identify and work within the framework defined by security policy while designing to make sure you do not breach policy that might prevent the application being deployed.
  • Make sure to understand the structure provided by your target environment and understand the baseline security requirements in terms of filtering rules, port restrictions, supported protocols.
  • Expected to identity flow and identify the accounts that will be used for network authentication when connects to remote servers.

Path management

  • Expected to use URI's that are generated by either gateway system or by the system's own adapters.
  • Ensure that the user cannot supply all parts of the path – surround it with your path code.
  • Validate the paths to ensure users have proper role before granting permission.

Access Control

  • Expected to have an Access Control Policy to document adopter's business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. 
  • Server side implementation and presentation layer representations of access control rules must match.
  • Enforce application logic flows to comply with business rules.
  • Limit the number of transactions a single user or device can perform in a given period of time. The transactions/time should be above the actual business requirement, but low enough to deter automated attacks.
  • Restrict access to user and data attributes and policy information used by access controls.
  • If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate.
  • Expected to support disabling of accounts and terminating sessions when authorization ceases.
  • Expected to follow NIST guidelines for Access Control:

General Coding Practice

  • Expected to use tested and approved managed code rather than creating new unmanaged code for common tasks.
  • Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files.
  • Required to review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality, as these can introduce new vulnerabilities.
  • Implement safe updating. If the application will utilize automatic updates, then use cryptographic signatures for your code and ensure your download clients verify those signatures. Use encrypted channels to transfer the code from the host server.
  • Do not pass user supplied data to any dynamic execution function.
  • Expected to explicitly initialize all variables and other data stores, either during declaration or just before the first usage.
  • Do not put sensitive information in hidden fields.

Memory Management

  • Expected to double check that the buffer is as large as specified.
  • Utilize input and output control for un-trusted data.
  • Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space.
  • Expected to avoid the use of known vulnerable functions.
  • Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
  • Properly free allocated memory upon the completion of functions and at all exit points.