Versions Compared

Old Version 2

changes.mady.by.user Eric McDonald

Saved on

compared with

New Version Current

changes.mady.by.user Tabassum Jafri

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

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

...

  • 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

...

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.

...