Secure Software Development | Information Security Guideline | Version 2.1 Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 1 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI Communications Security [DG 1-1] Utilize TLS certificates issued by the officially supported certification authority issued for the correct domain scope. Do not utilize self-signed TLS certificates. Ensure components requiring TLS connectivity cease to function if TLS certificates are invalid (expired, X X X revoked, not issued from a trusted authority, not issued for the correct subject, etc.). If possible, implement OCSP stapling to enhance the usability and availability of Online Certificate Status Protocol validation. If possible, implement HTTP Public Key Pinning to resist man-in-the-middle attacks. Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 2 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI [DG 1-2] Ensure login form pages and other pages used to submit sensitive data to or retrieve sensitive data from the server are loaded over strongly encrypted TLS 1.2+ connections. Protocol obfuscation is not X X X a sufficient means of protecting data transmissions. [DG 1-3] Ensure authentication credentials, security tokens, and session identifiers are only sent over strongly encrypted TLS 1.2+ connections. Protocol obfuscation is not a sufficient means of protecting data X X X transmissions. [DG 1-4] Disable HTTP and other clear text communication protocols for access to protected resources. If HTTP is required for initial ease of availability (e.g., for an external customer typing a domain name into a web browser address bar), redirect all HTTP requests to HTTPS and avoid transmitting sensitive X X X information in requests and responses until HTTPS is in use. Encrypt the channel for all communications involving protected resources. [DG 1-5] Send and receive sensitive communications (e.g., Top Secret, Confidential, PCI, PII, HIPAA/HITECH, SOX, proprietary, or otherwise used in decisioning) exclusively over encrypted HTTPS, encrypted IPsec, or equivalently encrypted channels. Use HTTP Strict Transport Security (HSTS) headers to force user agents to connect to domain names X X X only over HTTPS. The “max-age” attribute value should be far in the future (e.g., 7776000, representing 90 days) and should be the same value in every response. Include the “includeSubDomains” attribute. Include the “preload” attribute and submit the domain to browser vendor HSTS preload lists (e.g., https://hstspreload.appspot.com/). [DG 1-6] Use a 2048-bit or larger RSA modulus in certificate generation. X X X [DG 1-7] Issue and use certificates only with the correct trust anchor and chain of trust order. X X X [DG 1-8] Disable client-initiated TLS renegotiation. X X X [DG 1-9] Disable TLS compression. X X X [DG 1-10] During the TLS handshake, select the strongest cipher suite supported by both the client and server. X X X [DG 1-11] TLS connections should use TLS 1.2 or higher. Disable SSL 2.0, SSL 3.0, and TLS 1.0. X X X [DG 1-12] Disable TLS cipher suites utilizing the following components: For key exchange: • Anonymous Diffie Hellman algorithm (no authentication) For bulk encryption: • Camellia algorithm • DES and 3DES algorithms • IDEA algorithm • RC4 algorithm • SEED algorithm • Block sizes under 128 bits X X X • Electronic codebook (ECB) mode For message authentication: • MD5 algorithm • MD2 algorithm If possible, avoid operating bulk encryption algorithms in cipher block chaining (CBC) mode. If possible, support the following components: • Key exchange algorithms that support forward secrecy, including Diffie Hellman and Elliptic Curve Diffie Hellman. Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 3 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI • Authenticated encryption with associated data (AEAD), including AES-GCM and ChaCha20- Poly1305. [DG 1-13] For protected resources, ensure that active content (e.g., scripts, CSS, embedded controls, and XMLHttpRequest requests) is embedded and loaded with HTTPS URIs to avoid man-in-the-middle attacks and browser blocking of “mixed content.” Consider loading passive content (e.g., images and HTML5 video) over HTTPS to avoid man-in-the-middle attacks and browser warnings. Where third party APIs do not support encrypted channels, perform pre-load data validation to ensure X X X malicious content cannot be executed unwittingly or through social engineering. Refer to the W3C Mixed Content specification and individual browser vendors to determine what content types are “blockable” and “optionally-blockable.” [DG 1-14] Use a cryptographically strong signature algorithm in certificate generation. Do not use MD5 or SHA-1. X X X Privacy [DG 2-1] Do not pass sensitive parameters, including PCI data, GLBA data, HIPAA/HITECH data, SOX data, PII data, transactional data, security tokens, session identifiers, or passwords within the URL request path. When parameters must be logged, utilize the application server platform’s supported logging X X X mechanism in a secure manner (see DG 9-6). [DG 2-2] Apply the following anti-caching HTTP headers to pages containing identifiers (e.g., username, email address, and account number), form input fields for identifiers (e.g., input fields on login, registration, forgotten password request, forgotten username request, forgotten associated email request, and username change workflows) and other sensitive form fields: X X X Cache-Control: no-cache, no-store Expires: 0 [DG 2-3] Apply the following anti-caching HTTP headers to pages containing sensitive information: Cache-Control: no-cache, no-store Expires: 0 X X X Ensure end user agents observe anti-caching headers. [DG 2-4] Never return passwords to clients, including for forgotten password requests, and limit returning other unnecessary sensitive information (visible or otherwise). X X X [DG 2-5] Never permit passwords to be displayed (e.g., in form fields). X X X [DG 2-6] Set the TYPE attribute to PASSWORD for HTML password fields. X X [DG 2-7] Do not cache passwords. X X X [DG 2-8] Set the AUTOCOMPLETE attribute to OFF for HTML password fields, credit card numbers, and other sensitive form fields. X X [DG 2-9] Ensure files persisted to disk during application usage are only accessible with appropriate permissions by authorized users. X X X [DG 2-10] Do not unnecessarily persist files (especially those containing sensitive data elements) to disk. X X X [DG 2-11] Delete data files containing sensitive information after use. Securely overwrite data files containing sensitive information with a cryptographically random data sequence prior to deletion. X X X [DG 2-12] Scrub sensitive data from memory (e.g., sensitive variables) as soon as possible after use. X X X [DG 2-13] Protect temporary files. Only write temporary files to the runtime-specific temporary directory, and ensure the filenames of temporary files are generated randomly. X X X [DG 2-14] Clear payment card information stored for non-recurring payments (i.e., payment for web purchases) upon successful completion of a password change initiated using an out-of-band activation X X code sent in response to a forgotten password request. Password/PIN Length and Complexity Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 4 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI [DG 3-1] Permit one password change per user per day. X X X [DG 3-2] Do not permit the ability to change the password to the most recent value. X X X [DG 3-3] For employees, do not permit reuse of the previous six (6) passwords. For elevated access such as administrator or service accounts, do not permit reuse of the previous twenty (20) passwords. For X X X customers, do not permit reuse of the previous password. [DG 3-4] Require passwords to have a minimum length of eight (8) characters for employees, sixteen (16) characters for elevated access such as administrator or service accounts, or six (6) characters for X X X customers. If possible, permit passwords to have a length of up to 64 or more characters. [DG 3-5] Permit passwords to contain uppercase letters, lowercase letters, digits, and special characters including but not limited to ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } and ~. X X X Treat uppercase and lowercase versions of the same letter as distinct characters. [DG 3-6] For employees or for elevated access such as administrator or service accounts, do not permit the following types of passwords: • Passwords including the user’s username in any combination of casing. For example, the user “jdoe” would not be permitted to have a password of “3jDOE4”. • Passwords based on simple constructions of identifying information entered during registration sequences. For example, John Doe, born February 19, 1991, with a phone number of 555-777- 7777, and username of “mr_doe”, would not be permitted to have a password of “johndoe”, “2/19/91”, or “5557777777”. • Passwords listed in various top 1,000; 500; 200; and 100 most common passwords lists. For example, no user would be permitted to have a password of “mountain”. • Passwords based on dictionary words (in any language). X X X • Passwords matching known weak password patterns. For example, no user would be permitted to have a password containing only repeated characters (e.g., “1111111”, “YYYYYYYYYY”, “;;;;;;;;;;;;;;;;;;;”) or obvious sequences (e.g., “98765432”, “asdfghjk”, “ASDFASDF”, “HIJKLMNOP”, “!@#$%^&*”).Passwords matching a component of the application’s domain (or, for servers without a domain name, the server name). For example, no user would be permitted to have a password of “screenshots” or “thisisareallyfunwebsite” if the domain name of hosted content was screenshots.thisisareallyfunwebsite.com.