 | This newsletter is our third thread on the implementation of PCI DSS in Azure. With the expertise of my friend Nicolas Giraud, architect specialized in Microsoft technologies and my knowledge of PCI DSS we decrypt this still nebulous subject. For each PCI requirement we discuss the responsibilities (who is in charge of what), the implementation mechanisms at your service (your toolbox) as well as implementation guidance wherever deemed necessary. The previous episode is available here. |
In this newsletter we are addressing Requirement 3 - Protect stored cardholder data
Objectives:
Ensures that cardholder data minimization and protection against unauthorized disclosure when at rest or displayed on screens.
PCI-DSS Controls
3.1-3.7
Responsibilities
Microsoft Azure is solely responsible for: Nothing. None of the requirements 3 are under the sole responsibility of Microsoft Azure.
Customers are solely responsible for:
3.2.x Do not store sensitive authentication data after authorization. If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process`
Customers are responsible for ensuring authentication data, track data, verification code and PINS are not stored after authorization, unless they are issuers.
3.3.x Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.
3.4.x Render PAN unreadable anywhere it is stored
Customers are responsible for masking PAN data, managing cryptographic keys and documenting all related procedures
3.6Fully document and implement all key- management processes and procedures for cryptographic keys used for encryption of cardholder data
Customers which are service providers are responsible for managing cryptographic keys and documenting all related procedures for their customers
3.6.6 Manual clear-text cryptographic key management
3.6.8 Key custodians
3.7 Policies and procedures
Customers are responsible for managing cryptographic keys and documenting all related procedures.
Shares responsibilities
3.1.x Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes
3.5.x Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse
3.6.1 Generation of strong cryptographic keys
3.6.2 Secure key distribution
3.6.3 Secure cryptographic key storage
3.6.4 Cryptographic key change
3.6.5 Retirement or replacement of keys
3.6.7 Prevention of unauthorized substitution of cryptographic keys
Customers are solely responsible for:
3.2.x Do not store sensitive authentication data after authorization. If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process`
Customers are responsible for ensuring authentication data, track data, verification code and PINS are not stored after authorization, unless they are issuers.
3.3.x Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.
3.4.x Render PAN unreadable anywhere it is stored
Customers are responsible for masking PAN data, managing cryptographic keys and documenting all related procedures
3.6Fully document and implement all key- management processes and procedures for cryptographic keys used for encryption of cardholder data
Customers which are service providers are responsible for managing cryptographic keys and documenting all related procedures for their customers
3.6.6 Manual clear-text cryptographic key management
3.6.8 Key custodians
3.7 Policies and procedures
Customers are responsible for managing cryptographic keys and documenting all related procedures.
Shares responsibilities
3.1.x Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes
- Azure is responsible for ensuring that customer data designated for deletion are securely decommissioned
- Customers are responsible for limiting CHD storage, defining retention requirements, deleting CHD in a timely fashion, ensure all CHD is securely deleted or destroyed and verify timely deletion on a quarterly basis.
3.5.x Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse
- For customers using key vault, Microsoft Azure ensures that customer key vaults are logically isolated from each others. Key vault is designed so that Microsoft does not have access to customer’s key vault.
- Customers are responsible for the management of their keys outside the key vault and determining which key vault to use.
3.6.1 Generation of strong cryptographic keys
- For customers using key vault, when generating keys in key vaults, Azure is responsible for generating per the customers specifications. Keys are generated using a HSM.
- Customers are responsible for defining key characteristics whether generated in Microsoft Azure or imported from their environment.
3.6.2 Secure key distribution
- For customers using key vault, the Bring Your Own Key tool encapsulates the customer key and target a specific vault which is tied to a specific Azure subscription. The key can only be imported to the defined subscription’s key vault, in the specific region. This process uses the encryption procedures provided by the hardware manufacturer.
- Customers are responsible for selecting the correct key vault for an import using the BYOK tool.
3.6.3 Secure cryptographic key storage
- For customers using key vault, keys are stored in HSM secured using the hardware manufacturer’s cryptographic security.The metadata on keys is stored in Azure storageby Microsoftin an encrypted state unique for each key vault.
- Customers are responsible for managing cryptographic keys and documenting all related procedures.
3.6.4 Cryptographic key change
- For customers using key vault, Key vault supports functionality to update or roll keys which is defined by the customers.
- Customers are responsible for setting the cryptographic period for a key in key vault. Customers are responsible for creating and enforcing defined cryptoperiods for which a particular cryptographic key can be used.
3.6.5 Retirement or replacement of keys
- For customers using key vault, Key vault supports functionality to retire or replace a key which is defined by customers.
- Customers are responsible for setting the lifecycle of the key in the key vault. Customers are responsible for retiring and replacing keys as necessary.
3.6.7 Prevention of unauthorized substitution of cryptographic keys
- For Customers using key vault, Key vaults are logically separated and do not support cross-directory operation preventing therefore unauthorized substitution.
- Customers are responsible for managing cryptographic keys and documenting related procedures.
The Azure Toolbox for Req 3
 | Azure Key Vault Azure Key Vault is a PaaS service that provides a secure and centralized storage of secrets, certificates and cryptographic keys. Key Vaults are backed by hardware security modules (HSM) and are certified FIPS 140-2. Azure Key Vault can be a response to many of the technical challenges raised by PCI-DSS requirement 3:
|
 | Azure SQL Database Azure SQL Database is a PaaS service that hosts your relational databases in Azure in a managed way. Cardholder data are typically stored in a SQL database. Azure SQL Database offers several features that can be leveraged to protect the storage of cardholder data:
|
 | Azure Automation Azure Automation is a SaaS application that provides a scalable way to automate processes. It provides a task scheduling feature that can be used to implement recurrent procedures. For example, an Azure Automation Runbook can trigger the disposal of card holder data (req. 3.1) or the rotation of cryptographic keys in key vaults (req. 3.6.4). |
Resources
 |  |
RSS Feed
