Best Practices: Application Hardening

Application Hardening

Application hardening is a term for “hardening” or protecting an app against intrusion by eliminating vulnerabilities and increasing layers of security. This document discusses general principles and best practices for application hardening for your Shinydocs solutions.

Infrastructure

Hardening the network infrastructure prevents users from plugging a device into the server network. There are a few different ways to harden your network infrastructure:

• Manage physical access to the network devices. Only authorized administrators should be able to physically access network hardware such as routers, firewalls, switches, etc…

• Deploy an intrusion prevention system. Administrative alerts can be helpful for detecting and blocking malicious activity.

Server and Operating System

Hardening the server and operating system lays the foundation for a successful application hardening process. If users are able to gain access to your server, it doesn’t matter how much effort has been done to harden the application running on it.

Recommendations for hardening the server:

• Manage physical access to the server. Only authorized admins should be able to physically access the server.

• Maintain a log indicating which individuals have physically accessed the server location. Electronic record keeping methods, such as key fob logs or surveillance cameras are ideal for this type of audit control.

Recommendations for hardening the operating system:

• Only install the minimum software required to run the application. Extraneous applications running on the server may have their own vulnerabilities and require software patch lifecycle.

• Disable unnecessary services, if they cannot be removed.

• Restrict network access using firewalls, IP filters, etc…

• Minimize open network ports to only those required for the application.

• Use disk encryption to protect data.

• Delete or disable unnecessary operating system users.

• Limit user access to the minimum privileges required. Not everyone needs to be a domain administrator.

• Log access to the operating system.

• Each administrator should have their own authorized account. Sharing accounts makes it very difficult to audit access.

• Implement a patching process that keeps the operating system up-to-date. Operating System vendors release security patches often to patch newly discovered vulnerabilities.

• Consider Just In Time (JIT) access to authorized administrators. JIT access opens the required network ports for remote access (SSH, RDP etc) for a specific incoming IP address/port for a specified period of time. Most cloud services offer JIT access in order to avoid having an open port in the firewall that others can use to gain access to the operating system.

• If possible, implement 2-factor authentication to the operating system. There are a number of 3rd party products that can do this.

• Ensure former staff have access permissions removed as soon as possible.

• If possible, implement a monitoring tool to alert you to suspicious activity.

• Use group policy to enforce security requirements (Windows only).

• Use anti-virus / anti-malware, and keep the definitions up-to-date. Use reputable, well-known and well-tested applications. Limit exclusions to the minimum required.

• Use single sign-on as much as possible (e.g. Active Directory, LDAP, azure active directory, etc.).

• Back up the systems regularly, and ensure the backups are valid.

• Enforce strong passwords.

• Lock accounts after too many login requests.

• Ensure the operating system locks after a period of inactivity. This amount of time should be relatively short.

• Keep the server clock in sync. Use time synchronization protocols such as NTP.

• Disable insecure protocols.

• Use recommended security baseline tools, such as Microsoft Security Baselines or RedHat Security Hardening Guide

Third-Party Software

Internet Information Services (IIS) for Windows® Server

The following recommendations can help ensure that your IIS is protected from vulnerabilities:

• Enforce TLS with a valid trusted certificate, and avoid using self-signed certificates in production environments.

• Disable any insecure/weak protocols (e.g. SSL v3, TLS 1.0, TLS 1.1, etc.). Test the ciphers and protocols using an external tool.

• Define a content security policy header. More details can be found in Content Security Policy

• Use Http Public Key Pinning to enforce valid certs. This helps mitigate man-in-the-middle attacks. More details can be found in Http Public Key Pinning.

• Implement Http Strict Transport Security (HSTS). More details can be found in HTTP Strict Transport Security.

• Implement the Referrer Policy Http Header. More details can be found in Referrer Policy.

• Implement the X-Content-Type-Options header to prevent the browser from sniffing data and loading them as scripts and stylesheets. More details can be found in X-Content-Type-Options.

• Implement the X-Frame-Options header. This exerts control over how the site can be displayed within an iframe to help prevent clickjacking. Typically this header should be set to ‘Deny’ to prevent other sites from embedding your site within a frame. More details can be found in X-Frame-Options.

• Optionally implement the X-XSS-Protection header. This is typically better set with the Content Security Policy header, but may be useful for older browsers. More details can be found in X-XSS-Protection.

• Disable any IIS features that are not required.

• Use the firewall to ensure access to only the required ports.

• Control which IP address ranges can access the server.

• Use logging to monitor traffic.

• Run the application under a dedicated application pool identity.

  • Delegate any access to the specific application pool identity.

  • Do not share application pool identities across applications.

  • Do not share application pools across websites.

• Give the application user account the least permissions required to run. The application should be read-only, and write access only granted to files/folders to which they need access. Other application pool identities should be restricted only to the applications they are running.

• Ensure excessive logging should not be able to fill up the disk.

• Define a log retention policy.

• Error pages should not display sensitive information, such as usernames, passwords, server names, IP addresses, etc...

• Make sure IIS patches are applied. This is typically done as part of the operating system patch process.

• Use a dedicated server for the IIS server. If the server is being shared, a breach may expose data from everything on the server.

• Move the inetpub directory from the system drive to a different drive.

• If you are using authentication, ensure anonymous access is disabled.

• Do not allow anonymous writes to the server.

• Configure request filtering to limit the types of http requests. For example, if your application only uses GET and POST http methods, configure request filtering to only allow GET and POST.

• Debug modes should be turned off unless actively being used for debugging purposes.

• Review and remove IIS branded headers. Telling the attacker what server you are using helps them determine how to attack it.

• Use tools to test your configuration, and periodically retest the site (Qualsys SSL Labs, Mozilla Observatory, etc…).

Elasticsearch

The following best practices can help you harden your Elasticsearch instance:

• Ensure the Elasticsearch data directory is on an encrypted disk. This ensures the data at rest is protected.

• Ensure that the Elasticsearch cluster is in its own isolated network. Access can be managed with firewall rules, a reverse proxy in IIS or VPN access.

  • The request port (default 9200) should be accessible only to the applications that need to access Elasticsearch. This can be achieved by restricting the IP addresses that can access this port.

  • The cluster communication port (default 9300) should only allow communication between the instances of the cluster.

  • Issue node certificates to each of the nodes in the elastic search cluster. These should be issued by a certificate authority that is trusted (either a corporate certificate authority or a commercial certificate authority). This enables secure communication between the nodes of the cluster and any applications accessing the cluster. More details can be found in https://www.elastic.co/guide/en/elasticsearch/reference/6.8/configuring-tls.html#node-certificates.

  • If node certificates are used, Kibana will also need these certificates configured to access data in the index. More details can be found in https://www.elastic.co/guide/en/kibana/6.8/configuring-tls.html#configuring-tls.

• If Kibana is installed to power Shinydocs Visualizer, it should be within the same network as Elasticsearch, and access to it should be managed by setting up a reverse proxy within IIS or by using a VPN. Only users that need access to Shinydocs Visualizer should be permitted access, since they will have un-permissioned access to all index data.

  • If using a reverse proxy to control access, windows authentication should be used to authenticate users. Restrict the users who can access the proxy by using IIS Authorization rules. More details can be found in ElasticSearch Reverse Proxy using IIS.