Pci dss doc 04 1 cryptographic policy

Cryptographic Policy

PCI DSS Toolkit Version 2 ©CertiKit

Cryptographic Policy [Insert Classification]

Implementation Guidance (The header page and this section must be removed from final version of the document)

Purpose of this document This document defines the organization’s policy with regard to 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: 2.3 Encrypt all non-console administrative access using strong cryptography 3.x Protect stored cardholder data 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 using an acceptable encryption solution at all times. 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

Toolkit Version Number PCI DSS Toolkit Version 2

Version 1

Page 1 of 12

[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 on the ribbon) 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 i.e. so that they are no longer updateable, then 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 then go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check that you have updated all fields correctly.

Further detail on the above procedure can be found in the Toolkit Completion Instructions within the Project Resources folder.

Copyright notice Except for any third party works included in this document, as identified in this document, this document has been authored by CertiKit, and is © copyright CertiKit except as stated below.

CertiKit is a trading name of Public I.T. Limited, a company registered in England and Wales with company number 6432088 and registered office at 5 Falcons Rise, Belper, Derbyshire, DE56 0QN.

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.

Version 1

Page 2 of 12

[Insert date]

Cryptographic Policy [Insert Classification]

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. 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 3 of 12

[Insert date]

Cryptographic Policy [Insert Classification]

[Replace with your logo]

Cryptographic Policy

Document Classification: Document Ref. Version: Dated: Document Author: Document Owner:

Version 1

Page 4 of 12

[Insert Classification] PCI-DSS-DOC-04-1 1 [Insert date]

[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 5 of 12

Date

[Insert date]

Cryptographic Policy [Insert Classification]

Contents 1

INTRODUCTION ....................................................................................................................................... 7

2

POLICY ON THE USE OF CRYPTOGRAPHIC CONTROLS ............................................................ 8 2.1 2.2 2.3 2.4

3

RISK ASSESSMENT .................................................................................................................................... 8 TECHNIQUE SELECTION ............................................................................................................................ 8 DEPLOYMENT.......................................................................................................................................... 10 TESTING AND REVIEW............................................................................................................................. 10

KEY MANAGEMENT ............................................................................................................................. 11 3.1

CRYPTOGRAPHIC ARCHITECTURE ........................................................................................................... 12

List of Tables TABLE 1 - CRYPTOGRAPHIC TECHNIQUES .............................................................................................................. 10 TABLE 2 - CRYPTOGRAPHIC ARCHITECTURES ........................................................................................................ 12

Version 1

Page 6 of 12

[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 a number of information securityrelated 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: • • • • •

Personal Commitment Statement Mobile Device Policy Remote working Policy Software Policy Network Security Policy

Version 1

Page 7 of 12

[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 Treatment Process Information Security Risk Treatment Plan

Requirements for the use of cryptographic techniques will be identified in the last of these documents. This risk treatment 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: • • • •

2.2

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)

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.

Version 1

Page 8 of 12

[Insert date]

Cryptographic Policy [Insert Classification]

Note that the selection of such techniques must take into account 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.

In general, the policy of [Organization Name] is to use the following techniques for the relevant business process or situation: Process/Situation Storage of data in the cloud E-Commerce transactions over the Internet

Technique AES-256 encryption at rest Symmetric encryption using TLS (Asymmetric techniques used to share session key) Protection of data on Symmetric encryption removable media Protection of passwords All passwords must be on systems hashed Email Security Symmetric/asymmetric encryption using S/MIME Remote Access Virtual Private Network (VPN) using TLS 1.2 or higher Processing and/or Strong cryptography as Transmitting Cardholder per industry recognised Data internally standards Processing and/or Strong cryptography as Transmitting Cardholder per industry recognised Data over a public/open standards Wi-Fi 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)

Version 1

Page 9 of 12

Specific Guidance Keys not to be held by the CSP RSA to be used for public key cryptography. Certificates to be obtained from a reputable supplier AES-256 encryption to be used where available MD5 hashing to be used where available Features available in the relevant email client should be used to simplify the process An IPSec VPN may be used where permitted by the Network Security Policy Strong cryptography as per industry recognised standards Only trusted keys and certificates are to be used

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

[Insert date]

Cryptographic Policy [Insert Classification]

Accessing systems that store, process or transmit cardholder data Additional security required for known services, protocols or daemons (HTTP) Securing Wireless Networks

Strong cryptography as per industry recognised standards TLS 1.2

Encrypt all access to systems to avoid sending ID/Passwords in clear-text SSL or early TLS should not be used

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.

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 CSP may be required prior to performing tests.

Version 1

Page 10 of 12

[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: 1. As cleartext within the memory of a hardware-based encryption device 2. As ciphertext outside the memory of a hardware-based encryption device 3. As two or more key fragments either in cleartext or ciphertext, managed using dual control with split knowledge 4. Within a secure cryptographic device (SCD) such as a hardware security module or PTS-approved point-of-interaction device Use of one of these forms will ensure that the confidentiality of private asymmetric and symmetric keys is maintained at all times. 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.

Version 1

Page 11 of 12

[Insert date]

Cryptographic Policy [Insert Classification]

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

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

Encrypting the PAN Taking card payments

Algorithms, protocols and keys used AES-256

Key Strength

Key expiry

2048-bit

July 2017

AES-256

2048-bit

July 2017

Hardware Security Module (HSM) Encryption Hardware xx N/A

Secure Cryptographic Device (SCD) used N/A

P2PE chip and pin device 1

Table 2 - Cryptographic architectures

Version 1

Page 12 of 12

[Insert date]