Identity Platform virtual appliance security hardening details
SecureAuth® Identity Platform is a highly configurable product that can be installed on any network as a virtual appliance.
This document provides component details and build information about this product.
Client type and supported servers
The Identity Platform 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 2019
Windows Server 2016 Standard
For more information about supported Windows Server operating systems for new installs and upgrades, see the SecureAuth compatibility guide.
Appliance types
Images for virtual appliances can be downloaded for: AWS AMI, VMware vSphere, and Microsoft Hyper-V hypervisors.
For the virtual appliance, SecureAuth builds the base image for the Identity Platform product. SecureAuth calls this the Gold Image Build Process.
Gold Image Build Process
The Gold Image Build Process includes installing and configuring the following components:
Server operating system
Server roles
Applications and frameworks
We automate the operating system (OS) installation and build process to ensure consistency between physical and virtual platforms. To address all known vulnerabilities, each build image gets the latest updates and patches applied to its components. Components include the OS, .NET Framework, and required applications (for example, Visual Studio, C# code, and redistributable packages). After installing and patching the OS, the OS gets hardened in preparation for the installation of the Identity Platform.
We build the base image for the Identity Platform in a secure and isolated environment with limited inbound and outbound access. The subnet is actively scanned for viruses and malware using WhiteHat Sentinel Premium Edition. The Identity Platform source code is scanned during development and before all major and minor releases. We use the Checkmarx Static Code Analysis appliance to scan the code, and it is compliant with OWASP, PCI, and HIPAA vulnerability standards.
Operating system hardening process
After installing and patching the underlying OS, we apply the various scripts and policies based on the baseline security templates from Microsoft Security.
After completing the OS hardening phase, we install the Identity Platform.
Install the Microsoft baseline security templates
During the OS hardening process, we install and apply the following:
Security applications prerequisites (for example, EMET and LocalGPO)
Relevant templates on the base member server
The above actions affect the local group policy and registry. Specific information on these templates is available in the documentation for the Identity Platform appliance baseline security hardening settings.
Configure Microsoft Edge browser security
One of the most common types of attack on a system (client or server) targets the browser. The Identity Platform web admin is a web-based console that requires the use of a browser. To remotely carry out most (but not all) administrative functions, it requires the use of a local browser. For security purposes, do not use the browser for anything other than configuring the Identity Platform.
The local group policy in Microsoft Edge controls the browser functionality on the appliance. This policy limits the ability of the browser to run specific script types, update/add sites on the Trusted Sites and Intranet Zone, and relax other browser security settings. If permitted by your organization's security policies, you can modify those policy restrictions.
Information about settings for auditing the baseline is available in the documentation for the Identity Platform virtual appliance baseline security hardening settings.
Address browser component security vulnerabilities
During the OS hardening process, security vulnerability checks in browser components include certificates and protocols.
SHA-2 certificate support
There are some 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 to migrate any SHA-1 SSL and code signing certificates to the SHA-2 hashing algorithm.
The Identity Platform supports and issues SHA-2 hashed certificates to improve security, reliability, and performance with SecureAuth hosted services. The Identity Platform software code is signed with a SHA-2 code signing certificate.
Schannel TLS/SSL tuning
The Identity Platform 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
Tuning of the cipher suite includes disabling TLS 1.0 and weaker ciphers, and enabling and prioritizing TLS 1.1 and higher GCM and SHA-2 based ciphers. The following 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: Support ECDSA-based appliance and user certificates
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.
To meet secure Perfect Forward Secrecy (PFS) standards in the X.509 certificate infrastructure on the Identity Platform appliance, SecureAuth provides optional support for X.509 certificates, based on SHA-256 ECDSA. This offering enables SecureAuth to put in place more cipher suite enablement and prioritization, thereby enhancing the performance and security of client to server communications.
We offer variable cipher suite tuning options to suite unique customer environment requirements, based on security, performance, and compatibility needs.
In most cases, the Identity Platform 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. The Identity Platform 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.
Install required Web server role and .NET framework
To enforce security and limit the attack surface, we only install the Web server role and its related features.
Scripted installation includes the Internet Information Services (IIS) role and minimal IIS features. Explicit uninstallation of specific features ensures that expected feature sets are available, and prevents installation of any non-required functionality.
We install MS .NET Framework version 4.7.2 on the virtual appliance
Enable local Windows firewall with advanced security
Enabling the Windows Firewall with advanced security by default, protects the Identity Platform virtual appliance during the initial setup. Configuration of the Windows advanced firewall denies incoming sessions, by default. Custom rules are added, allowing only Identity Platform-specific inbound and outbound network communications. More specific information on these communications is available in Network communication requirements for SecureAuth IdP.
Optional OS hardening: address other security requirements
The appliance delivered to the majority of SecureAuth customers are generally configured to exceed PCI and HIPAA security standards. Yet, a growing percentage of the customer base includes state and federal agencies that need HSPD-12 compliance or other pertinent requirements. SecureAuth has worked with several federal customers as well as Conscious Security, Inc. to develop and test more 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 might be required, depending upon the enterprise or security needs of an organization.
These might 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 Identity Platform 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 Identity Platform 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.
Note
Important information about MS level encryption
The msg level encryption endpoints are deprecated (no longer appending /msg after .svc in the URL). Going forward, use https in the URL configuration in SecureAuth cloud services.
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
The Identity Platform 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 two-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. The secure and highly available redundant infrastructure 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
SecureAuth hosted services also include clustered database services and redundant back-end services.
For more information, see SecureAuth cloud services.
Ongoing appliance security patching and update maintenance
The SecureAuth appliance is extensively hardened throughout the build process. It contains the latest Microsoft High Priority OS and VIPRE Antivirus updates, and the system is scanned for virus and malware. Then, it is enabled with a customized local firewall policy.
SecureAuth recommends implementing the Enterprise security update strategies for operating system security and anti-virus updates.
For more information, see the Ongoing Appliance Security Patching and Update maintenance document.
Additional hardening options
By default, the Identity Platform deployment contains an overall configuration to designed to meet PCI regulatory requirements. There are more hardening options available for high security environments. Some optional settings include: limiting algorithms to FIPS compliance, disabling NetBIOS over TCP/IP, SMB Signing requirements, and so on. For specific security requirements, contact your SecureAuth account representative.
Baseline security settings for Identity Platform appliances running Windows 2019 or 2016
For information about baseline security settings applied to operating systems of the Identity Platform appliances, see: