Recommended Security Practices

With constantly evolving external attacks, most users face security breaches either external or insider threats. In order to be prepared, a layered approach with the application’s security is much needful.

Here are the set of best practices available categorically for a comprehensive security strategy.

Platform

  • For an extensive security cover, ensure all the security level options are reviewed. See Private Cloud security and access control, for more information.

  • For any password authentication profile, Platform allows setting password lengths until 128 characters. Yet the administrators have the privilege to review and modify the default security levels to enforce more stringent minimum password length requirements. See Password Authentication, for more information.

    • To furthermore broaden the security authentication, Multi-Factor Authentication can be enabled. For more details, see Multi-Factor Authentication.

  • For any sensitive text or file uploads, enable the field level encryption option. See Enhanced Security & Auth-related features, for more information.

Application Server (Tomcat)

  • Platform creates all cookies with httpOnly and secure flag wherever applicable on a HTTPS enabled instance. To improve the security and set httpOnly secure flag over tomcat’s jsessionid cookie:

    1. Add the following syntax at session-config tag to the web.xml file available at <tomcat-install-dir>/conf:

      <cookie-config>
      	<http-only>true</http-only>
      	<secure>true</secure>
      </cookie-config>

      The following screenshot is an example of adding the above code to the web.xml file:

    2. Save the file and restart tomcat.

  • For generic Tomcat 40x and 50x error pages on any broken links exceptions, Platform now allows to white label and create custom 40x and 50x error pages.

Load Balancer (Nginx/Kubernetes)

  1. Prior to Platform 6.4, any HTTP Strict-Transport-Security (HSTS) changes should be manually enabled on the HTTPS instance using respective configuration changes at Nginx or other load balancer configuration options. Some load balancers such as Kubernetes ingress have this security option enabled by default. With 6.4, Platform ships with required nginx configuration options which enables HSTS by default on the HTTPS enabled instance.

    For example, to enable HSTS in the instances prior to 6.4.x, add the following code for HTTPS server section in nginx_conf for platform deployments.

    # Security headers
add_header Strict-Transport-Security "max-age=15811200; includeSubDomains" always;

    Only if the Platform HTTPS instance is not equipped with Nginx or any other load balancer, the HSTS setting can also be enabled at the instance level using the shared property - EnableSecureServerHSTS. However, please remember this setting works alongside the IsSecureServer option and should only be enabled when the Platform instance does not have the capability, instead set the HSTS option via any load balancer. If enabled from shared property, the header has default value of "max-age=15811200; includeSubDomains".

  2. Before 6.4, Nginx conf options can be modified to not print exact Nginx version on custom error pages.