Developer Guides

Security Review Process for Production

Suggest Edits

ICE Mortgage Technology (IMT) has a large ecosystem of Partners who ensure customers can efficiently engage, originate, close, and sell loans. Our high security standards protect thousands of customers and our ever-expanding Partner network.

At IMT, we continuously enhance our code and security assurance processes to help Partners deliver high-quality and secure integrations. The following security standards are the minimum that must be in place before a Partner integration can be approved for production. These standards are referenced in the contract between IMT and the Partner.

Security Process Checklist

  1. The Partner must allow IMT to conduct a TLS analysis.

  2. The Partner must maintain an overall rating of A or above per the TLS server tests.

  3. The Partner must allow IMT to perform static code scans of the Partner API or of code for any JavaScript or API-related vulnerabilities that could infect the IMT environment.

  4. The Partner must conduct a static code scan if the application is hosted on a lender environment, and the report should be shared with IMT.

  5. Digital certificate requirements:

  • The Partner must not use wildcard certificates.
  • The certificate key type and size must be RSA 2048 bits or stronger.
  • The certificate must be in active status and not expire within a year of submission.
  • The certificate chain must be signed by a third-party certificate authority (CA) for the server certificate, intermediate CA, and root CA.
  • The certificate must be trusted.
  • There should be no trust chain issues.
  1. Secure communication requirements:
  • Data communication must use HTTPS.
  • Data-in-transit secure communication protocol must be TLS 1.2 and above.
  • The server must be configured with HTTP Strict Transport Security.
  • TLS compression must be disabled as it may allow for a CRIME attack.
  • The servers must not be vulnerable to the following:
  • POODLE over TLS
  • OpenSSL padding-oracle flaw (CVE-2016-2107)
    • Heartbleed
    • CVE-2014-0224 (OpenSSL CCS flaw)
    • CVE-2009-3555 (client-initiated insecure renegotiation could allow MITM attacks)
    • RC4
  • The server must support the TLS_FALLBACK_SCSV extension for protocol downgrade attack prevention
  • Forward Secrecy is required. Based on the platform, the Partner utilizes the following protocols and associated ciphers.
  • Partners are to use only the approved ciphers or policy listed for the cloud platform below.
PlatformProduct/PolicyCipher
Azure TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLSECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 TLSECDHE_ECDSA_WITH_AES_128_CBC_SHA
 TLSECDHE_ECDSA_WITH_AES_256_CBC_SHA
 TLSECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 TLSECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 TLSECDHE_RSA_WITH_AES_256_GCM_SHA384
 TLSECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLSECDHE_RSA_WITH_AES_128_CBC_SHA
 TLSECDHE_RSA_WITH_AES_256_CBC_SHA
 TLSRSA_WITH_AES_256_GCM_SHA384
 TLSRSA_WITH_AES_128_GCM_SHA256
 TLSRSA_WITH_AES_256_CBC_SHA256
 TLSRSA_WITH_AES_128_CBC_SHA256
 TLSRSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_AES_128_CBC_SHA
AWS ECDHE-RSA-AES128-GCM-SHA256
 ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
 ECDHE-RSA-AES256-SHA384
AES128-GCM-SHA256
 AES256-GCM-SHA384
* AES128-SHA256
Heroku TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
 TLSECDHE_RSA_WITH_CHACHA20_POLY1305
 TLSECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLSECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLSECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 TLSECDHE_RSA_WITH_AES_256_GCM_SHA384
 TLSECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Additional ciphers may be enabled for TLSv1.2 regardless of platform: ECDHE-RSA-AES256-GCM-SHA384
 ECDHE-RSA-AES256-GCM-SHA256
ECDHE-RSA-AES256-CBC-SHA384
 ECDHE-RSA-AES256-CBC-SHA256
ECDHE-RSA-AES128-CBC-SHA256
 ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
 ECDHE-ECDSA-AES256-GCM-SHA256
ECDHE-ECDSA-AES256-CBC-SHA384
 ECDHE-ECDSA-AES256-CBC-SHA256
ECDHE-ECDSA-AES128-CBC-SHA256
 ECDH-RSA-AES128-CBC-SHA256
ECDH-ECDSA-AES256-GCM-SHA384
 ECDH-ECDSA-AES256-CBC-SHA384
ECDH-ECDSA-AES128-GCM-SHA256
 ECDH-ECDSA-AES128-CBC-SHA256
TLS_AES_128_GCM_SHA256
 TLSCHACHA20_POLY1305_SHA256
 TLSAES_256_GCM_SHA384
 TLS_RSA_WITH_AES_256_CBC_SHA256
  1. The Partner must use AES encryption with a key strength of 256 bits to encrypt the data received from IMT at REST.
  2. The Partner must implement IP-whitelisting support between the Partner’s and IMT’s EPC servers.
  3. The Partner must not include any third-party URLs in the JavaScript code hosted by IMT on the Partner’s behalf.
  4. The Partner must inform IMT of any significant security incidents, such as data breach incidents, within 4 hours.

Updated over 1 year ago

What’s Next