Skip to main content

SecureAuth IdP Appliance Security Hardening Details

Introduction

SecureAuth IdP is a highly configurable product that can be installed on any network as a physical appliance or as a virtual appliance. This document provides details on components included in this product and how the product is built.

Client type and supported servers

SecureAuth IdP is a Microsoft .NET web application that runs on Microsoft Windows Internet Information Services 7.x and 8.x, and supports these Microsoft Windows Server operating systems:

  • Windows Server 2016 Standard

  • Windows Server 2012 R2

Appliance types

The physical appliance comes in two form factors: Standard and advanced.

Images for virtual appliances can be downloaded for: VMware vSphere, Citrix Xen, and Microsoft Hyper-V hypervisors.

For either appliance type, the same process is used to build the base image for the SecureAuth IdP product. SecureAuth calls this the Gold Image Build Process.

Gold Image Build Process

The Gold Image Build Process includes the installation and configuration of the following components:

  • Server Operating System

  • Server Roles

  • Applications and Frameworks

The OS installation and configuration process is automated to ensure consistency between physical and virtual platforms. Only slight variations in the build process exist between OS versions (2016 vs. 2012 R2). Latest updates and patches are applied to components on each build image to address all known vulnerabilities. Such components include the OS, .NET Framework, and required applications (e.g. Visual Studio, C# code, and redistributable packages). After the OS is installed and patched, the OS is hardened in preparation for the installation of the SecureAuth IdP web application (see Operating System hardening process).

The base image for SecureAuth IdP is built in a secure and isolated environment with limited inbound and outbound access, and the subnet is actively scanned for viruses and malware using WhiteHat Sentinel Premium Edition. SecureAuth IdP's source code is scanned during development and prior to all major and minor releases using the Checkmarx Static Code Analysis appliance which is compliant with OWASP, PCI, and HIPAA vulnerability standards.

Operating System hardening process

Once the underlying OS is installed and patched, various scripts and policies based on Microsoft Security's baseline security templates are applied.

SecureAuth IdP is installed after the OS hardening phase is completed.

Microsoft's baseline security templates installed

During the OS hardening process, security applications prerequisites (e.g. EMET and LocalGPO) are installed on the base member template, and relevant templates are applied on the base member server. These actions affect the local group policy and registry. More specific information on these templates is available in the SecureAuth IdP appliance baseline security hardening settings documents.

Internet Explorer 11 browser security configured

One of the most common types of attack on a system (client or server) targets the browser. The SecureAuth Web Admin is a web-based console that requires the use of a browser. Most administrative functions – though not all – can be executed remotely, requiring a local browser to perform these tasks. Thus, for security purposes, the browser used by SecureAuth IdP should not be used for anything other than configuring the IdP application.

Using Internet Explorer 11, the browser's functionality on the appliance is controlled by the local group policy. This policy limits the browser's ability to run specific script types, update/add sites on the Trusted Sites and Intranet Zone, and relax other browser security settings. Restrictions imposed by these policies can be modified if permitted by the organization's security policies.

Additional settings for auditing the baseline are documented in the SecureAuth IdP appliance baseline security hardening settings documents.

Browser component security vulnerabilities addressed

Browser components examined for security vulnerabilities during the OS hardening process include certificates and protocols.

SHA-2 certificate support

Due to a number of known security issues with SHA-1 SSL certificates, Microsoft, Google, and Mozilla have issued security advisories recommending that certificate authorities (CAs) deprecate SHA-1 SSL certificates by January 1, 2017, and that customers migrate any SHA-1 SSL and code signing certificates to the SHA-2 hashing algorithm at the earliest opportunity.

SecureAuth IdP supports and issues SHA-2 hashed certificates to improve security, reliability, and performance with SecureAuth hosted services. SecureAuth IdP software code is signed with a SHA-2 code signing certificate.

Schannel TLS/SSL tuning

The SecureAuth IdP appliance operating system protects against TLS and SSL vulnerabilities by only allowing the configuration of specific protocols, hashes, key exchange algorithms, and appropriate cipher suites.

  • Supported ciphers are AES 128/128 and AES 256/256

    • Legacy ciphers such as DES, 3DES, RC2 and RC4 are not supported

  • Supported hashes are SHA (for backwards compatibility), SHA256, SHA384 and SHA512

    • MD5 is not supported

  • Supported key exchange algorithms are Diffie-Hellman, Elliptic Curve Diffie-Hellman (ECDH), and PKCS

  • Supported protocols for client and server are TLS versions 1.0 (for backwards compatibility and remote desktop with NLA functionality), 1.1, and 1.2

Cipher suite tuning has been implemented to disable TLS 1.0 and weaker ciphers, and enable and prioritize TLS 1.1 and higher GCM and SHA-2 based ciphers. Here is a prioritized list of the first ten SHA256 GCM compatible ciphers:

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384

Roadmap item: ECDSA-based appliance and user certificate support

As previously mentioned, the limited cipher, protocol, hash and key exchange algorithms, as well as cipher suites prioritization, provide an increased level of client security and performance. The standard appliance certificate and user certificates issued today are SHA256RSA based certificates.

In order to meet secure Perfect Forward Secrecy (PFS) standards in the SecureAuth IdP appliance's X.509 based certificate infrastructure, SecureAuth provides optional support for X.509 based certificates, based upon SHA256 ECDSA. This offering enables SecureAuth to implement additional cipher suite enablement and prioritization, thereby enhancing the performance and security of client to server communications.

Variable cipher suite tuning options are offered to suit unique customer environment requirements, based on security, performance, and compatibility needs.

In most cases, the SecureAuth IdP appliance is protected using a customer-provided SSL certificate purchased through a commercial signing authority (e.g. Verisign/Symantec, GoDaddy, or Comodo). The level of security, compatibility, and performance provided by this SSL certificate (with regard to client browser connections) varies, since these factors are dependent upon the type of certificate installed. SecureAuth IdP has the ability to enable/disable/prioritize the optimal cipher suites for the specific certificate type (SHA2RSA or SHA2 ECDSA) to match security, performance, or compatibility needs for a given customer.

Additionally, as part of the ongoing enhancements on the roadmap, SecureAuth will be keeping in compliance with SSL security standards across modern web browsers and applications.

Local Windows firewall with advanced security enabled

Windows Firewall with advanced security is enabled by default on the SecureAuth IdP appliance as a protective measure during the initial setup. The Windows advanced firewall is configured to deny incoming sessions by default. Custom rules are added, allowing only SecureAuth IdP-specific inbound and outbound network communications. More specific information on these communications is provided in Network communication requirements for SecureAuth IdP.

Optional OS hardening: other security requirements addressed

The standard appliance shipped to the majority of SecureAuth's customers is generally configured to exceed PCI and HIPAA security standards. However, a growing percentage of the customer base includes state and federal agencies that require HSPD-12 compliance or other pertinent requirements. SecureAuth has worked with several federal customers as well as Conscious Security, Inc. to develop and test additional configuration options that meet requirements for higher security guidance defined in the DISA Security Technical Implementation Guide (STIG), along with other general security settings that may be required depending upon the enterprise or security needs of an organization. These may include, but are not limited to, the following:

  • Application of STIG Local Group Policy

  • FIPS compliance mode

  • NetBIOS over TCP/IP disabled

  • SMB 2 signing requirements

Appliance to SecureAuth Cloud communication methods

Each SecureAuth IdP appliance communicates with the SecureAuth hosted services environment to complete specific functions. These functions include:

  • SecureAuth license validation

  • OTP delivery to mobile, work, or home numbers via SMS or Telephony

  • Push Notification to Android or iOS mobile devices

  • Authentication transaction auditing

  • SecureAuth signed X.509 personal certificate issuance and revocation

  • Adaptive Authentication services (IP reputation, geo-velocity, etc.)

Security for appliance to Cloud Services communications

Secure communications for appliance to hosted services are enabled via WSE 3.0 / WCF message-level encryption over TCP Port 80 for HTTP, and TLS / transport-level encryption over TCP Port 443 for HTTPS.

Message level security

Message-level security uses the WS-Security specification to secure messages, providing confidentiality, integrity, and authentication at the SOAP message level (instead of the transport level). Message-level security encapsulates the security credentials and claims for each message, along with any message protection (signing or encryption). Security is applied directly to the message by modifying its content, thereby ensuring the security of the message is self-contained.

By encrypting the message body and leaving the header in clear text, communications between the SecureAuth IdP appliance and the SecureAuth hosted services can easily traverse router and other SOAP intermediaries without requiring the data be exposed at each hop. Additionally, WCF message-level security provides mutual authentication between the two parties.

Transport Layer Security

Transport Layer Security (TLS), a cryptographic protocol, is designed to provide communications security over a network. Using X.509 certificates, asymmetric cryptography is employed to verify the relationship between a certificate and its owner, and to negotiate a symmetric session key.

The most common implementation of this protocol can be found in the use of Secure Sockets Layer (SSL) to encrypt and sign contents of packets sent over Secure HTTP (HTTPS).

Security in an air-gapped environment

SecureAuth IdP can accommodate organizations with special requirements for limiting communications that take place outside the internal or isolated networks. However, in such environments, only STS, SSO, and 2-Factor Authentication functionality can be used.

Strong authentication methods for air-gapped environments include:

  • Browser Fingerprinting

  • Email OTP delivery

  • CAC / PIV card

  • Hard or soft token

  • SCEP-based X.509 certificates

  • PIN

  • KBQ and KBA

SecureAuth hosted services

SecureAuth hosted services are redundant at the site and service levels operating in SSAE16 Type II certified hosting facilities providing secure, highly available (redundant) infrastructure which includes redundant power, cooling, and Internet connectivity; dedicated firewall, IDS, DoS and application firewall protection; and backup services, monitoring, and alerting.

Highly available and redundant web services include:

  • SHA-2 based certificates for SSL/TLS and WSE/WCF communications

  • Load balanced Web services hosting APIs providing SMS, TTS, Push, Push-to-Accept OTP services, Threat Intelligence Services and X.509 Certificate signing services

Highly available and redundant certificate authority features include:

  • SHA-2 based, Intermediate Certificate Authorities (CAs) with HSM-protected private keys (FIPS 140-2 Mode)

  • Offline, Root CAs stored in physically secure locations with an offline, physically-secure HSM that stores the private keys

  • Minimum two of four physical PED access keys held by senior IT staff members, required for any private key management in Root or Intermediate CAs

SA hosted services also include clustered database services and redundant back-end services.

Refer to SecureAuth cloud services for more information.

Ongoing appliance security patching and update maintenance

The SecureAuth Appliance is extensively hardened throughout the build process; the latest Microsoft High Priority OS and VIPRE Antivirus updates are applied; the system is scanned for virus and malware and then shipped with customized local firewall policy enabled.

SecureAuth recommends implementing the Enterprise security update strategies for Operating System security and anti-virus updates. Refer to the Ongoing Appliance Security Patching and Update maintenance document for more information.

Additional hardening options

The Default deployment of SecureAuth is shipped with an overall configuration designed to meet PCI regulatory requirements. There are additional hardening options available for high security environments. Some of these optional settings include: limiting algorithms to FIPS compliance, disabling NetBIOS over TCP/IP, SMB Signing requirements, etc. If there are specific security requirements, then contact the SecureAuth Sales Account manager or Sales Engineer to ensure that the appropriate hardening is applied or made available when required.

Baseline security settings for SecureAuth IdP appliances running 2012 R2

Refer to the following document for information about baseline security settings applied to operating systems of the SecureAuth IdP appliance models: