Policy Template for Key Management and Cryptography Policy

The purpose of this policy is to establish requirements for selecting cryptographic keys, managing keys, assigning key strengths and using and managing digital certificates. The protection methods outlined will include operational and technical controls,  such as key backup procedures, encryption under a separate key and use of tamper-resistant hardware.

This Standard applies to all IT Resources that store, transmit or process {{organization.name}}’s or its customer’s information and that use encryption keys or digital certificates.

• Cryptography: a method of storing and transmitting data in a form that only those it is intended for can read and process.

• Encryption: the process of converting data from plain text to a form that is not readable to unauthorized parties, known as cipher-text.

• Key: the input that controls the process of encryption and decryption. There are both secret and public keys used in cryptography.

• Digital Certificate: An electronic document that is used to verify the identity of the certificate holder when conducting electronic transactions. Secure Sockets Layer (SSL) certificates are a common example that has identified data about a server on the Internet as well as the owning authority’s public encryption key.

• Sensitive Data: Sensitive information is data that must be protected from unauthorized access to safeguard the privacy or security of an individual or organization.

• Data at rest: Data at rest is data that is not actively moving from device to device or network to network such as data stored on a hard drive, laptop, flash drive, or archived/stored in some other way.

• Data in transit, or data in motion, is data actively moving from one location to another such as across the internet or through a private network.

Encryption shall always be used to protect strictly confidential or sensitive information transmitted over data networks to protect against risks of interception. This includes when accessing network services that require authentication (for example, usernames and passwords) or when otherwise sending or accessing strictly confidential information (for example, in emails).

Where confidential or sensitive data is stored on or accessed from mobile devices (for example, laptops, tablets, smartphones, external hard drives, USB sticks, digital recorders) the devices themselves must be encrypted (using "full disk" encryption), irrespective of ownership.

Where strictly confidential data is stored in public, cloud based storage facilities, the data must be encrypted prior to storing to ensure that it is not possible for the cloud service provider to decrypt the data. Where data is subject to an agreement with an external organization, the data should be handled (stored, transmitted or processed) in accordance with the organization’s specified encryption requirements.

Encryption key lengths should use current industry standard encryption algorithms for Confidential or Sensitive Information.

Sensitive data at rest shall be encrypted at all times.

The encryption of data at rest shall only include strong encryption methods such as AES or RSA.

Encrypted data shall remain encrypted when access controls such as usernames and passwords fail. Increasing encryption on multiple levels is recommended.

Confidential or Sensitive Information at rest on computer systems owned or operated by {{organization.name}} shall be protected by one or more of the following mechanisms:

• Disk/File System Encryption.

• Use of Virtual Private Networks (VPN’s) and Firewalls with strict access controls that authenticate the identity of those individuals accessing the Confidential or Sensitive Information.

• Sanitizing, redacting, and/or de-identifying the data requiring protection during storage to prevent unauthorized risk and exposure (e.g., masking or blurring).

• Supplemental compensating or complementary security controls including complex passwords, and physical isolation/access to the data.

• Strong cryptography on authentication credentials (i.e. passwords/phrases) shall be made unreadable during transmission and storage on all information systems.

• Password protection to be used in combination with all controls including encryption.

• File systems, disks, and tape drives in servers and Storage Area Network (SAN) environments are encrypted using industry standard encryption technology.

• Computer hard drives and other storage media that have been encrypted shall be sanitized to prevent unauthorized exposure upon return for redistribution or disposal.

{{organization.name}} shall ensure that formal transfer policies, protocols, procedures, and controls are implemented to protect the transfer of information through the use of all types of communication and transmission facilities.

The transfer of sensitive data shall be through a secure channel. A secure channel is an encrypted network connection.

Strong cryptography and security protocols (e.g. TLS, IPSEC, SSH, etc.) shall be used to safeguard Confidential or Sensitive Information during transmission over open public networks. Such controls include:

• Only accepting trusted keys and certificates, protocols in use only support secure versions or configurations, and encryption strength is appropriate for the encryption methodology in use.

• Public networks include but are not limited to the Internet, Wireless technologies, Bluetooth, and cellular technologies.

• Confidential or Sensitive Information transmitted in e-mail messages is encrypted. Any Confidential or Sensitive Information transmitted through a public network (e.g., Internet) to and from vendors, customers, or entities doing business with {{organization.name}} must be encrypted or transmitted through an encrypted tunnel (VPN) or point-to-point tunnelling protocols (PPTP) that include current Transport Layer Security (TLS) implementations.

• Wireless (Wi-Fi) transmissions used to access {{organization.name}} computing devices or internal networks must be encrypted using current wireless security standard protocols (e.g. RADIUS, WPS private/public keys or other industry standard mechanisms).

• Secure encrypted transfer of documents and Confidential or Sensitive Information over the internet using current secure file transfer programs such as “SFTP” (FTP over SSH) and secure copy command (SCP).

• All non-console administrative access such as browser/web based management tools is encrypted using TLS based browser technologies using the most current security algorithm.

All new laptops, tablets and portable storage devices purchased through IT Purchasing will have encryption enabled during deployment. Any USB storage device may have encryption applied through an appropriate software tool.

Effective enterprise public and private key management is a crucial element in ensuring encryption system security. Key management procedures must ensure that authorized users can access and decrypt all encrypted Confidential or Sensitive Information using controls that meet operational needs. {{organization.name}}’s key management systems shall be characterized by the following security precautions and attributes:

• {{organization.name}} should use procedural controls to enforce the concepts of least privilege and separation of duties for staff. These controls apply to persons involved in encryption key management or who have access to security-relevant encryption key facilities and processes, including Certificate Authority (CA) and Registration Authority (RA), and/or contractor staff.

• Keys in transit must be encrypted.

• Private keys must be kept confidential.

• Application and system resource owners should be responsible for establishing data encryption policies that grant exceptions based on demonstration of a business need and an assessment of the risk of unauthorized access to or loss of Confidential or Sensitive Information

• Decryption keys shall not be associated with user accounts.

• Restrict access to cryptographic keys to the fewest number of custodians necessary. Cryptographic keys are stored in the fewest possible locations.

• Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys should be done when the integrity of the key has been weakened or keys are suspected of being compromised.

• Archived cryptographic keys should only be used for decryption/verification purposes.

• Cryptographic key custodians shall formally acknowledge that they understand and accept their key-custodian responsibilities.

{{organization.name}} must use industry-approved strong algorithms for encryption and/or digital signing processes. The following subsections detail requirements that also ensure an adequate level of protection. {{organization.name}} must protect private encryption keys to prevent their unauthorized disclosure and subsequent fraudulent use. All private keys protecting {organization.name}}’s and its customer’s information are classified as per Information Sensitivity/Classification policy.

Private Keys

{{organization.name}} handled private keys must:

• Physically and logically secure them.

• Store keys in/on:

  • An encrypted key store or in an otherwise encrypted form.

  • A security token.

  • An Encryption keyring.

• Not share the key with anyone other than those expressly authorized.

• Always use randomly generated key(s) to encrypt a set of unrelated or separate {{organization.name}} Information.

• {{organization.name}} users handling private keys must record access so the use of the keys is auditable.

• {{organization.name}} users handling private keys must follow the Disposal procedure when retiring keys.

• {{organization.name}} users handling private keys protecting {{organization.name}’s or its customer information shall use a privileged access management tool.

Generating strong keys

{{organization.name}} users generating private keys must:

• Select a key size using the minimum specified by the encryption method or greater when symmetric key encryption is employed.

• Generate keys on the IT Resource itself or, if transmission of a private key is required, distribute keys manually using a public key transport mechanism or using a previously distributed or agreed-upon key-encrypting key.

• Use a random key generation mechanism.

Emergency access to keys

IT Ops Team must have auditable procedures in place to provide access to private keys in the event of an emergency and/or the passphrase holder being unavailable.

Changing private keys and the private key lifecycle

{{organization.name}} must:

• Have a process to approve key changes, record dispositions and change keys when a user with access to a private key(s) separates or changes roles.

• Have a process to change keys as part of the response to an Information Security incident.

• For private keys protecting {{organization.name}}’ or its Customers’ information, change keys at least once annually.

• Private keys must be revoked and/or deleted when they are no longer needed to perform a business function.

• Private keys must not be re-issued or reused.

Access to keys

{{organization.name}} handling private keys must be limited to those who have a need-to-know based on job responsibilities.

Encryption methods

{{organization.name}} must select the stronger of the following methods:

• An encryption method based on the Risk Assessment;

• Symmetric - using the minimum recommended key strength or higher; or

• Asymmetric/Public-Private key pair - using the minimum recommended key strength or higher

Compromised keys

• {{organization.name}} must change encryption keys immediately if the key becomes compromised or is discovered by any unauthorized person or party.

• {{organization.name}} users must report any compromised key to the CISO.

Web server certificates

{{organization.name}} users handling web server certificates must:

• Use digital certificates signed by a CISO approved Certificate Authority (CA).

• Select a key size of 2048 bits or greater.

• Select an expiration of not more than one year for IT Resources accessing {{organization.name}} and its customers' information.

• Not use wildcard digital certificates for top level domains or subdomains.

Self-signed certificates

{{organization.name}} users handling self-signed certificates must:

• Not use them for any production purpose on a public network.

• Not use them for the testing of IT Resources processing, storing or transmitting {{organization.name}} or its customer information.

• IT resources with factory-installed self-signed certificates can only be used on protected private networks.