Example of Encryption Policy for Information Security Management System

1. Purpose

1. The purpose of this policy is to provide guidance that limits the use of encryption to those algorithms that have received substantial public review and have been proven to work effectively.
2. This policy outlines the requirements for protecting encryption keys that are under the control of end users. These requirements are designed to prevent unauthorized disclosure and subsequent fraudulent use. 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.
3. This document also describes Information Security’s requirements for encrypting data at rest on XXX mobile devices.

2 Scope

1. This policy applies to all XXX employees and affiliates.
2. This policy applies to any mobile device issued by XXX or used for XXX business which contains stored data owned by XXX.
3. This policy applies to any encryption keys listed below and to the person responsible for any encryption key listed below. The encryption keys covered by this policy are:
   • encryption keys issued by XXX
   • encryption keys used for XXX business
   • encryption keys used to protect data owned by XXX

3 Policy

3.1 Acceptable Encryption Policy

3.1.1 Algorithm Requirements

1. Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
2. 4.1.2 Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
3. 4.1.3 Signature Algorithms

Algorithm	Key Length (min)	Additional Comment
ECDSA	P-256	Consider RFC6090 to avoid patent infringement.
RSA	2048	Must use a secure padding scheme. PKCS#7 padding scheme is recommended. Message hashing required.
LDWM	SHA256	Refer to LDWM Hash-based Signatures Draft

3.1.2 Hash Function Requirements
In general, XXX adheres to the NIST Policy on Hash Functions.

3.1.3 Key Agreement and Authentication

1. Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).
2. End points must be authenticated prior to the exchange or derivation of session keys.
3. Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.
4. All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.
5. All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider.

3.1.4 Key Generation

1. Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.
2. Key generation must be seeded from an industry standard random number generator (RNG). For examples, see NIST Annex C: Approved Random Number Generators for FIPS PUB 140-2.

3.2 End User Encryption Key Protection Policy

Encryption Key Management, if not done properly, can lead to compromise and disclosure of private keys use to secure sensitive data and hence, compromise of the data. While users may understand it’s important to encryption certain documents and electronic communications, they may not be familiar with minimum standards for protection encryption. All encryption keys covered by this policy must be protected to prevent their unauthorized disclosure and subsequent fraudulent use.

3.2.1 Secret Key Encryption Keys

Keys used for secret key encryption, also called symmetric cryptography, must be protected as they are distributed to all parties that will use them. During distribution, the symmetric encryption keys must be encrypted using a stronger algorithm with a key of the longest key length for that algorithm authorized in XXX’s Acceptable Encryption Policy. If the keys are for the strongest algorithm, then the key must be split, each portion of the key encrypted with a different key that is the longest key length authorized and the each encrypted portion is transmitted using different transmission mechanisms. The goal is to provide more stringent protection to the key than the data that is encrypted with that encryption key. Symmetric encryption keys, when at rest, must be protected with security measures at least as stringent as the measures used for distribution of that key.

3.2.2 Public Key Encryption Keys

Public key cryptography, or asymmetric cryptography, uses public-private key pairs. The public key is passed to the certificate authority to be included in the digital certificate issued to the end user. The digital certificate is available to everyone once it issued. The private key should only be available to the end user to whom the corresponding digital certificate is issued.

1. XXX’s Public Key Infrastructure (PKI) Keys:The public-private key pairs used by the XXX’s public key infrastructure (PKI) are generated on the tamper-resistant smart card issued to an individual end user. The private key associated with an end user’s identity certificate, which are only used for digital signatures, will never leave the smart card. This prevents the Infosec Team from escrowing any private keys associated with identity certificates. The private key associated with any encryption certificates, which are used to encrypt email and other documents, must be escrowed in compliance with XXX policies. Access to the private keys stored on a XXX’s issued smart card will be protected by a personal identification number (PIN) known only to the individual to whom the smart card is issued. The smart card software will be configured to require entering the PIN prior to any private key contained on the smart card being accessed.
2. Other Public Key Encryption Keys:Other types of keys may be generated in software on the end user’s computer and can be stored as files on the hard drive or on a hardware token. If the public-private key pair is generated on smartcard, the requirements for protecting the private keys are the same as those for private keys associated with PKI. If the keys are generated in software, the end user is required to create at least one backup of these keys and store any backup copies securely. The user is also required to create an escrow copy of any private keys used for encrypting data and deliver the escrow copy to the local Information Security representative for secure storage. The Infosec Team shall not escrow any private keys associated with identity certificates. All backups, including escrow copies, shall be protected with a password or passphrase that is compliant with XXX Password Policy. Infosec representatives will store and protect the escrowed keys as described in the XXX Certificate Practice Statement Policy.
3. Commercial or Outside Organization Public Key Infrastructure (PKI) Keys: In working with business partners, the relationship may require the end users to use public-private key pairs that are generated in software on the end user’s computer. In these cases, the public-private key pairs are stored in files on the hard drive of the end user. The private keys are only protected by the strength of the password or passphrase chosen by the end user. For example, when an end user requests a digital certificate from a commercial PKI, such as VeriSign or Thawte, the end user’s web browser will generate the key pair and submit the public key as part of the certificate request to the CA. The private key remains in the browser’s certificate store where the only protection is the password on the browser’s certificate store. A web browser storing private keys will be configured to require the user to enter the certificate store password anytime a private key is accessed.
4. PGP Key Pairs: If the business partner requires the use of PGP, the public-private key pairs can be stored in the user’s key ring files on the computer hard drive or on a hardware token, for example, a USB drive or a smart card. Since the protection of the private keys is the passphrase on the secret keying, it is preferable that the public-private keys are stored on a hardware token. PGP will be configured to require entering the passphrase for every use of the private keys in the secret key ring.

3.2.3 Hardware Token Storage

Hardware tokens storing encryption keys will be treated as sensitive company equipment, as described in XXX’s Physical Security policy, when outside company offices. In addition, all hardware tokens, smartcards, USB tokens, etc., will not be stored or left connected to any end user’s computer when not in use. For end users traveling with hardware tokens, they will not be stored or carried in the same container or bag as any computer.

3.2.4 Personal Identification Numbers (PINs), Passwords and Passphrases

All PINs, passwords or passphrases used to protect encryption keys must meet complexity and length requirements described in XXX’s Password Policy.

3.2.5 Loss and Theft

The loss, theft, or potential unauthorized disclosure of any encryption key covered by this policy must be reported immediately to The IT Team. IT personnel will direct the end user in any actions that will be required regarding revocation of certificates or public-private key pairs.

3.3 Mobile Device Encryption Policy

Mobile devices such as smart phone and tablets offer great flexibility and improved productivity for employees.  However, they can also create added risk and potential targets for data loss.  As such, there use must be in alignment with appropriate standards and encryption technology should be used when possible. All mobile devices containing stored data owned by XXX must use an approved method of encryption to protect data at rest. Mobile devices are defined to include laptops, PDAs, and cell phones. Users are expressly forbidden from storing XXX data on devices that are not issued by XXX, such as storing XXX email on a personal cell phone or PDA.

3.3.1 Laptops

Laptops must employ full disk encryption with an approved software encryption package. No XXX data may exist on a laptop in plain text.

3.3.2 PDAs and Cell phones

Any XXX data stored on a cell phone or PDA must be saved to an encrypted file system using XXX-approved software. XXX shall also employ remote wipe technology to remotely disable and delete any data stored on a XXX PDA or cell phone which is reported lost or stolen.

3.3.3 Keys

All encryption keys and pass-phrases must meet complexity requirements described in XXX’s Password Protection Policy.

3.3.4 Loss and Theft

The loss or theft of any mobile device containing XXX data must be reported immediately

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the IT team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.