Server Certificate Security Standard

Overview

Purpose

Pepperdine University's information systems rely on encryption to protect data in the restricted and confidential classifications from being intercepted.  Certain encryption configurations have proven insecure.  The following standard has been issued by the Pepperdine University Information Security Office to provide configurations for secure protocols for all services that are protected by Transport Layer Security (TLS) as well as restricted information protected by these services.

Audience

This standard is meant to be used by competent system administrators and is based on current IETF best practice for TLS (transport layer security).  This IT standard may also be referenced when application managers are proposing system change or creation.  It is the system administrator's responsibility to learn or be competent with methods for configuring their systems to match this standard and for engaging actively with the provided vulnerability scanning tool (Qualys) that can confirm and document fixes to misconfiguration.

Certificate Standards

Persons specifying or ordering encryption certificates must create them to match this standard.

Standards checklist for creating/renewing certificates:

• 2048 bit key minimum length (larger keys recommended).
• SHA2 algorithm is required for all new/renewed certs.
• Certificate Service Request standard (use no abbreviations except country code):
  • CN/FQDN - full name of the system, e.g. hostname.pepperdine.edu
  • Organization - Pepperdine University
  • Org Unit - Information Technology
  • City - Malibu
  • Region/State - California
  • Country Code - US
  • Email - email address specified by IT Server Engineering or ISO.
• For efficiency, use the maximum certificate term allowed (1 year for both regular and EV)
• Certificates for pepperdine.edu sites must be issued by Pepperdine's InCommon service.

Request & justify exceptions to the above in writing to ISO three weeks prior to go live. Renewal does not justify non-InCommon certs.

Extended Validation (EV) certificates

Systems requiring Pepperdine users to input their NetworkID & password directly (as opposed to single sign-on) shall use Extended Validation (EV) certs and the CSR shall be submitted via secure attachment to infosec@pepperdine.edu two weeks prior to go live.

All other certificates are ordered/installed by application manager relationship with their Server Engineering SysAdmin.

Network Transport Encryption Standards for Server/Network Systems

System administrators shall configure all applications on the system to use these standards. Network encryption is UNIVERSITY POLICY REQUIRED for network transmission of restricted data, such as passwords, SSN, Driver's License and HIPAA data. Network encryption is ISO STANDARD REQUIRED for transmission 

Encryption Protocol standards

TLSv1.2 is currently the only recommended protocol.

Protocol negotiation should start protocol negotiation with the highest version of TLS currently available and work down towards the lowest allowed protocol.  For example, servers should offer TLSv1.2 first then work down to TLSv1.0 as clients negotiate it.

TLSv1.1 & TLSv1.0 are allowed but should be phased out and are currently deprecated; new services that depend on TLSv1.0/1.1 should be scrutinized and written feedback provided to the vendor.

SSLv2 and SSLv3 are not allowed; if these are active on your system this violates standard because it is functionally insecure.

Encryption Cipher standards

Prohibited ciphers:

• Null
• RC4
• Export grade ciphers
• Ciphers beginning with TLS_RSA_WITH_

Recommended ciphers in order of strength:

1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
3. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
4. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

System configuration should order ciphers by highest strength first.

System should include ciphers (DHE/ECDHE) that provide Perfect Forward Encryption.

 ISO in CTO March 2015