PCI-DSS-DOC-04-1 Cryptographic Policy

Cryptographic Policy

PCI DSS Toolkit: Version 6 ©CertiKit

Cryptographic Policy [Insert classification]

Implementation guidance The header page and this section, up to and including Disclaimer, must be removed from the final version of the document.

Purpose of this document This document defines the organization’s policy about the use and management of cryptographic controls.

Areas of the standard addressed The following areas of the PCI DSS standard are addressed by this document: •

•

•

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters o 2.3 Encrypt all non-console administrative access using strong cryptography Requirement 3: Protect stored cardholder data o 3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties Requirement 4: Encrypt transmission of cardholder data across open, public networks o 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission

General guidance Cryptography can be a very complex area and you will need to ensure that your policy covers the technical aspects specific to your organization. New devices and techniques are regularly launched by vendors and your policy may need to be updated as more effective methods enter usage within your environment.

As cryptography technologies advance, so will the compliance requirements for PCI DSS. You must ensure the organization is always using an acceptable encryption solution. For more information see the PCI DSS and PA-DSS Glossary of Terms, Abbreviations and Acronyms under “Cryptographic Key Generation”, found on the PCI DSS website.

You will also need to ensure your use of cryptography stays within the limits of any applicable laws within your country.

Review frequency We would recommend that this document is reviewed annually and upon significant change to the organization or IT systems.

Version 1

Page 2 of 13

[Insert date]

Cryptographic Policy [Insert classification]

Document fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.

To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.

2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab).

3. Press F9 on the keyboard to update all fields.

4. When prompted, choose the option to just update TOC page numbers.

If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.

Further detail on the above procedure can be found in the Toolkit Completion Instructions. This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.

Copyright notice Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.

Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence. If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.

Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use.

Version 1

Page 3 of 13

[Insert date]

Cryptographic Policy [Insert classification] Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country.

You should take all reasonable and proper legal and other professional advice before using this document.

CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Version 1

Page 4 of 13

[Insert date]

Cryptographic Policy [Insert classification]

Cryptographic Policy

Version 1

DOCUMENT CLASSIFICATION

[Insert classification]

DOCUMENT REF

PCI-DSS-DOC-04-1

VERSION

1

DATED

[Insert date]

DOCUMENT AUTHOR

[Insert name]

DOCUMENT OWNER

[Insert name/role]

Page 5 of 13

[Insert date]

Cryptographic Policy [Insert classification]

Revision history VERSION

DATE

REVISION AUTHOR

SUMMARY OF CHANGES

Distribution NAME

TITLE

Approval NAME

Version 1

POSITION

SIGNATURE

Page 6 of 13

DATE

[Insert date]

Cryptographic Policy [Insert classification]

Contents 1

Introduction ........................................................................................................................ 8

2

Policy on the use of cryptographic controls ........................................................................... 9

3

2.1

Risk assessment ........................................................................................................... 9

2.2

Technique selection ..................................................................................................... 9

2.3

Deployment ............................................................................................................... 11

2.4

Testing and review ..................................................................................................... 11

Key management ............................................................................................................... 12 3.1

Cryptographic architecture ......................................................................................... 13

Tables Table 1: Cryptographic techniques .............................................................................................. 10 Table 2: Cryptographic architectures .......................................................................................... 13

Version 1

Page 7 of 13

[Insert date]

Cryptographic Policy [Insert classification]

1 Introduction A key component in the set of controls available to organizations to protect their classified information (including cardholder data) is the use of cryptographic techniques to “scramble” information so that it cannot be accessed without knowledge of a key.

Cryptographic controls can be used to achieve several information security-related objectives, including: • • • •

Confidentiality – ensuring that information cannot be read by unauthorised persons.

Integrity – proving that data has not been altered in transit or whilst stored.

Authentication – proving the identity of an entity requesting access to resources.

Non-repudiation – proving that an event did or did not occur or that a message was sent by an individual.

The need for cryptographic controls is ever growing and is often required to be compliant with industry recognised standards (for example PCI DSS). Cryptographic controls will be highlighted from the [Organization Name] risk assessment and will obviously not be applicable in all cases. However, where their use can provide the required level of protection, they must be applied according to the provisions set out in this policy.

This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to [Organization Name] systems.

The following policies and procedures are relevant to this document: • • • • • •

Acceptable Use Policy Mobile Device Policy Remote Working Policy Software Policy Network Security Policy Information Security Policy

Version 1

Page 8 of 13

[Insert date]

Cryptographic Policy [Insert classification]

2 Policy on the use of cryptographic controls In order to identify those areas in which the deployment of cryptographic techniques will be useful, [Organization Name] will take a managed approach as follows.

2.1 Risk assessment The first step will be to undertake a risk assessment in line with industry recognised standards (for example PCI DSS or the ISO/IEC 27001 information security standard.) For each of the information assets identified within the organization, possible threats will be assessed together with their likelihood and impact should they occur.

The following documents within the [Organization Name] Information Security Management System (ISMS) set out how this is achieved: • •

Risk Assessment and Mitigation Process Risk Mitigation Plan

Requirements for the use of cryptographic techniques will be identified in the last of these documents.

This risk mitigation plan will show in overview where cryptographic techniques must be applied and in what form to achieve the level of protection needed.

In addition, cryptography will generally be implemented by default in the following scenarios: • • • •

On mobile devices such as laptops, tablets and smartphones For authorised use of removable media such as USB memory sticks Where classified data is transmitted across communications lines that extend beyond the boundaries of the organization e.g. over the Internet Where cloud services are used, regardless of the type of cloud service (e.g. IaaS, PaaS, SaaS)

2.2 Technique selection Once the general need for the use of cryptography has been identified by the risk assessment or for compliance reasons, a decision needs to be made about which specific techniques will be deployed.

This will also involve the selection and possible purchase of software or hardware in order to implement the technique. Facilities provided by cloud service providers (CSPs) may also be used – in some cases choice may be restricted by the tools available, compliance requirements or the policies of a CSP. Note that the selection of such techniques must consider any current regulations or national restrictions on the procurement and use of cryptographic technology.

These are currently: •

[list any applicable regulations or national restrictions]

These may affect the type, strength and quality of the encryption algorithm used.

Version 1

Page 9 of 13

[Insert date]

Cryptographic Policy [Insert classification] In general, the policy of [Organization Name] is to use the following techniques for the relevant business process or situation:

PROCESS/SITUATION

TECHNIQUE

SPECIFIC GUIDANCE

Storage of data in the cloud

AES-256 encryption at rest

Keys not to be held by the CSP

E-Commerce transactions over the Internet

Symmetric encryption using TLS (Asymmetric techniques used to share session key)

RSA to be used for public key cryptography. Certificates to be obtained from a reputable supplier

Protection of data on removable media

Symmetric encryption

AES-256 encryption to be used where available

Protection of passwords on systems

All passwords must be hashed

MD5 hashing to be used where available

Email Security

Symmetric/asymmetric encryption using S/MIME

Features available in the relevant email client should be used to simplify the process

Remote Access

Virtual Private Network (VPN) using TLS 1.2 or higher

An IPSec VPN may be used where permitted by the Network Security Policy

Processing and/or Transmitting Cardholder Data internally

Strong cryptography as per industry recognised standards

Strong cryptography as per industry recognised standards

Processing and/or Transmitting Cardholder Data over a public/open Wi-Fi

Strong cryptography as per industry recognised standards

Only trusted keys and certificates are to be used

Storing Cardholder Data

Strong cryptography as per industry recognised standards One-way hashes based on strong cryptography Truncation (hashing cannot be used to replace the truncated segment of PAN) Index tokens and pads (pads must be securely stored)

Logical access will be managed separately and independently to OS authentication and access methods Decryption keys will not be associated with user accounts

Accessing systems that store, process or transmit cardholder data

Strong cryptography as per industry recognised standards

Encrypt all access to systems to avoid sending ID/Passwords in clear text

Additional security required for known services, protocols or daemons (HTTP)

TLS 1.2

SSL or early TLS should not be used

Securing Wireless Networks

WPA2 or 802.1x (TLS 1.2)

WEP or SSL not to be used

Table 1: Cryptographic techniques

The continued use of the specified techniques will be evaluated on each review of this policy.

Version 1

Page 10 of 13

[Insert date]

Cryptographic Policy [Insert classification]

2.3 Deployment The deployment of cryptographic techniques must be managed carefully to ensure that the desired level of security is in fact achieved. Where possible, more than one member of staff must be closely involved in the deployment in order to avoid both a single point of failure for support and to allow segregation of duties to take place.

Close consideration must be given to the on-going operation of the installed encryption so that documented operational procedures are fully in place and the relevant staff are trained in them.

2.4 Testing and review Once deployed, it is critical that the security of the encryption be tested under as realistic conditions as possible in order to identify any weaknesses. Such testing should cover the use of: • • • •

Commonly-available software tools to try to break the encryption Social engineering methods to try to discover the key Interception of encrypted data at various points in its transmission [Other methods you believe may be applicable in specific instances]

The results of tests will be formally reviewed, and lessons learned will be applied to the tested situation and communicated to other areas in which encryption is used in the organization.

Note that in the case of cloud services, approval from the Cloud Service Provider (CSP) may be required prior to performing tests.

Version 1

Page 11 of 13

[Insert date]

Cryptographic Policy [Insert classification]

3 Key management It is vital that cryptographic keys are stored and protected from modification, loss, destruction and unauthorised disclosure. The following controls must be in place to protect the keys: • • • •

Access to keys must be restricted to the fewest number of custodians necessary Key-encrypting keys must be at least as strong as the data-encrypting keys they protect Key-encrypting keys must be stored separately from data-encrypting keys Keys must be stored securely in the fewest possible locations and forms

A lifecycle approach must be taken to key management which will require the creation of specific procedures to cover the following stages: • • • • • • • • • • • •

Key generation Distribution of keys to point of use Storage at point of use Backup as protection against loss Recovery in the event of loss Updating keys once expired Revoking if compromised Archiving once expired Destroying when no longer required Logging and auditing of key management related activities Prevention of unauthorized substitution of keys Acknowledgement and understanding of being a key custodian

These procedures must take account of the specific circumstances in which encryption will be used.

In principle, private asymmetric keys and symmetric keys shall only exist in the following secure forms: • • • •

As cleartext within the memory of a hardware-based encryption device As ciphertext outside the memory of a hardware-based encryption device As two or more key fragments either in cleartext or ciphertext, managed using dual control with split knowledge Within a secure cryptographic device (SCD) such as a hardware security module or PTSapproved point-of-interaction device

Use of one of these forms will ensure that the confidentiality of private asymmetric and symmetric keys is always maintained. Public asymmetric keys are generally available and so do not require protection. Their integrity and authenticity does however need to be protected and this should be achieved via the use of a signature from a reputable certification authority.

Where key management functionality is provided as part of a cloud service, the following information must be requested about the facilities provided by the CSP: • • •

Type of keys Key management system specifications Recommended key management procedures for each stage of the key management lifecycle as defined above

Version 1

Page 12 of 13

[Insert date]

Cryptographic Policy [Insert classification] In the event that cryptographic keys are subject to a request by a government agency, [Organization Name] will comply with all legally authorised requests in a timely manner. The compliance process will be subject to senior management oversight and control.

3.1 Cryptographic architecture Below is a table that lists all the cryptographic architectures used in [Organization Name]:

KEY USAGE

ALGORITHMS, PROTOCOLS AND KEYS USED

KEY STRENGTH

KEY EXPIRY

HARDWARE SECURITY MODULE (HSM)

SECURE CRYPTOGRAPHIC DEVICE (SCD) USED

Encrypting the PAN

AES-256

2048-bit

July 2017

Encryption Hardware xx

N/A

Taking card payments

AES-256

2048-bit

July 2017

N/A

P2PE chip and pin device 1

Table 2: Cryptographic architectures

Version 1

Page 13 of 13

[Insert date]