This newsletter is our seventh 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.
Previous episodes
Objective
Ensure critical data can only be accessed by authorized personnel, systems and processes to limit access based on need to know and according to job responsibilities and ensure that each individual is uniquely accountable for their actions.
PCI-DSS Controls
7.1 - 8.8
Responsibilities
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
Customers are responsible for limiting access to system components and cardholder data to only those individuals whose job requires such access. This includes limiting and restricting access to the Azure Management Portal as well as specifying accounts or roles with permission to create, modify or delete PaaS services or VM’s.
Azure is responsible for enforcing existing ISMS policies regarding Azure personnel access to Azure system components, verification of access control effectiveness, providing Just-In-Time administrative access, revoking access when no longer needed, and ensuring staff accessing the Azure platform environment have a business need. Azure access to customer environments is highly restricted and only allowed with customer approval.
Azure is responsible for establishing policies to restrict physical access to the data center to authorized employees, vendors, contractors, and visitors. Security verification and check-in are required for personnel requiring temporary access to the interior data center facility. Physical access logs are reviewed every quarter by Azure teams.
7.2 Establish an access control system for systems components that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed.
7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.
Customers are responsible for defining and documenting a User ID approval process, defining least privileges, restricting access to cardholder data, using unique IDs, providing separation of duties, and revoking user access when no longer necessary.
8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components
Customers are responsible for defining and documenting a User ID approval process, defining least privileges, restricting access to cardholder data, using unique IDs, providing separation of duties, and revoking user access when no longer necessary.
Customers are responsible for creating, enforcing, and monitoring a password policy compliant with PCI DSS requirements.
8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
- Something you know, such as a password or passphrase
- Something you have, such as a token device or smart card
- Something you are, such as a biometric.
Customers are responsible for ensuring secrets used to access their application and data are stored using encryption or equivalent mechanism.
Customers are responsible for creating, enforcing and monitoring a password policy compliant with PCI DSS requirements for PaaS service and Portal access. Customers are responsible for keeping passwords from being disclosed to unauthorized parties and for choosing passwords with sufficient entropy as to be effectively non-guessable and for deployment of services such as multi-factor authentication.
Azure has established key management procedures to manage cryptographic keys throughout their lifecycle (e.g., generation, distribution, revocation). Microsoft Azure uses Microsoft's corporate PKI infrastructure.
8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.
Customers are responsible for implementing multi-factor authentication mechanisms for access to their CDE.
Azure administrators are required to use multi-factor authentication to access when performing maintenance and administration to Azure systems and servers.
8.4 Document and communicate authentication procedures and policies and procedures to all users
Customers are responsible for following guidance and document and communicate authentication procedures and policies to all users
8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
- Generic user IDs are disabled or removed.
- Shared user IDs do not exist for system administration and other critical functions.
- Shared and generic user IDs are not used to administer any system components.
Customers are responsible for following guidance when maintaining storage credentials and not use group, shared, or generic IDs, passwords, or other authentication methods
8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
- Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
- Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
Customers are responsible for developing and enforcing an access control policy consistent with the provisions of this control
8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
- All user access to, user queries of, and user actions on databases are through programmatic methods.
- Only database administrators have the ability to directly access or query databases.
- Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
Customers are responsible for managing access to in-scope databases.
8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
Customers are responsible for ensuring that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
Customers are responsible for limiting access to system components and cardholder data to only those individuals whose job requires such access. This includes limiting and restricting access to the Azure Management Portal as well as specifying accounts or roles with permission to create, modify or delete PaaS services or VM’s.
Azure is responsible for enforcing existing ISMS policies regarding Azure personnel access to Azure system components, verification of access control effectiveness, providing Just-In-Time administrative access, revoking access when no longer needed, and ensuring staff accessing the Azure platform environment have a business need. Azure access to customer environments is highly restricted and only allowed with customer approval.
Azure is responsible for establishing policies to restrict physical access to the data center to authorized employees, vendors, contractors, and visitors. Security verification and check-in are required for personnel requiring temporary access to the interior data center facility. Physical access logs are reviewed every quarter by Azure teams.
7.2 Establish an access control system for systems components that restricts access based on a user’s need to know and is set to “deny all” unless specifically allowed.
7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.
Customers are responsible for defining and documenting a User ID approval process, defining least privileges, restricting access to cardholder data, using unique IDs, providing separation of duties, and revoking user access when no longer necessary.
8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components
Customers are responsible for defining and documenting a User ID approval process, defining least privileges, restricting access to cardholder data, using unique IDs, providing separation of duties, and revoking user access when no longer necessary.
Customers are responsible for creating, enforcing, and monitoring a password policy compliant with PCI DSS requirements.
8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
- Something you know, such as a password or passphrase
- Something you have, such as a token device or smart card
- Something you are, such as a biometric.
Customers are responsible for ensuring secrets used to access their application and data are stored using encryption or equivalent mechanism.
Customers are responsible for creating, enforcing and monitoring a password policy compliant with PCI DSS requirements for PaaS service and Portal access. Customers are responsible for keeping passwords from being disclosed to unauthorized parties and for choosing passwords with sufficient entropy as to be effectively non-guessable and for deployment of services such as multi-factor authentication.
Azure has established key management procedures to manage cryptographic keys throughout their lifecycle (e.g., generation, distribution, revocation). Microsoft Azure uses Microsoft's corporate PKI infrastructure.
8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.
Customers are responsible for implementing multi-factor authentication mechanisms for access to their CDE.
Azure administrators are required to use multi-factor authentication to access when performing maintenance and administration to Azure systems and servers.
8.4 Document and communicate authentication procedures and policies and procedures to all users
Customers are responsible for following guidance and document and communicate authentication procedures and policies to all users
8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
- Generic user IDs are disabled or removed.
- Shared user IDs do not exist for system administration and other critical functions.
- Shared and generic user IDs are not used to administer any system components.
Customers are responsible for following guidance when maintaining storage credentials and not use group, shared, or generic IDs, passwords, or other authentication methods
8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
- Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
- Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
Customers are responsible for developing and enforcing an access control policy consistent with the provisions of this control
8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
- All user access to, user queries of, and user actions on databases are through programmatic methods.
- Only database administrators have the ability to directly access or query databases.
- Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
Customers are responsible for managing access to in-scope databases.
8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
Customers are responsible for ensuring that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
The Azure Toolbox for Req 7 & 8
Azure Active Directory is Microsoft’s cloud-based identity and access management service. It is a central component to implement requirements 7 & 8, as it handles user identification, authentication and authorization (authorization can also be managed at application level).
Azure AD is integrated to most Azure services (PaaS and IaaS), including Azure Portal, virtual machines, SQL databases and key vaults. Custom applications can integrate Azure AD simply by configuration or using the SDK.
For users created and managed in the portal (cloud users):
Azure AD is integrated to most Azure services (PaaS and IaaS), including Azure Portal, virtual machines, SQL databases and key vaults. Custom applications can integrate Azure AD simply by configuration or using the SDK.
- In Azure AD, a unique ID is assigned to each security object. A different account can be created for each individual and each application (requirement 8.1.1).
The management of these accounts (add/modify/delete) is done in Azure Portal by specific security administrators (requirement 8.1.2). Alternatively, accounts can be synchronized with an existing on-premises Active Directory and managed in a controlled Windows Server context. - Azure AD authentication procedures ensure all credentials are encrypted during transmission and storage (requirement 8.2.1). The password change procedure verifies the user identity by asking for the current password (requirement 8.2.2).
- The centralized nature of Azure AD can greatly simplify PCI-DSS user management procedures. For example, disabling a user will automatically revoke access to all Azure resources secured via Azure AD (requirement 8.1.3).
- Azure AD Identity Governance is a set of Azure AD features designed to manage the lifecycle of user identity and assigned access. Key topics in requirements 7 and 8 can be implemented using these features, including the principle of least privileges (requirement 7.1.2).
- Azure AD Groups, Azure AD Admin Roles and Azure Resources Roles are the solution to implement access based on user job classifications (requirement 7.1.3). If additional flexibility is needed, Dynamic Groups can be used to automatically add or remove users from groups.
- Azure RBAC is the native access control system for Azure Resources. It covers authorization to all resources (requirement 7.2.1), can assign permissions based on roles (requirement 7.2.2) and can be configured with a default “deny all” behaviour (requirement 7.2.3).
- Azure AD Privileged Identity Management (PIM) is a component of Azure AD that provides time-based and approval-based role activation. It can be used to implement documented approval procedures (requirement 7.1.4) and limit a third-party access (requirement 8.1.5) in an automated way.
- Azure Multi-Factor Authentication can easily be enabled to meet requirements 8.3. Azure AD natively supports voice calls, SMS, mobile apps and OATH hardware tokens. Third party MFA providers can also be integrated.
- Azure AD Domain Services is an important component in PaaS scenarios. It provides a bridge between Azure AD and Windows Server to integrate virtual machines into the security scope of Azure AD.
- Group Policy Objects can then be used to enforce local security policies like disabling generic/guest accounts (requirement 8.5) or setting the timeout value of Terminal Services sessions (requirement 8.1.8).
- Azure AD Password Policies controls password rules and account lockout. Depending on your infrastructure type (PaaS, IaaS or hybrid), you may need to use Group Policy Objects in combination with Password Policies to achieve the correct results.
For users created and managed in the portal (cloud users):
- Account lockout attempts (requirement 8.1.6) and lockout duration (requirement 8.1.7) are set by default to 1 minute after 10 attempts. For full compliance, you must customize this using Azure AD Smart Lockout or Azure Graph API.
- Password complexity (requirement 8.2.3) is compliant by default thanks to a minimum length of 8 characters and a set of characters that must include 3 of the following: lowercase, uppercase, number, symbol. This cannot be customized but Azure AD Password Protection can provide an additional level of password security.
- Password expiration (requirement 8.2.4) is already 90 days by default but can be changed using a PowerShell command.
- Password history (requirement 8.2.5) is limited to the previous password, which means you may need to implement additional controls for full compliance (last 4 passwords).
- Initial password value and mandatory password change at first use (requirement 8.2.6) are managed automatically by Azure AD when “auto-generate password” is selected during user creation.
- Disabling inactive users (requirement 8.1.4) can be done based on their login history. Azure Portal can display the last 7 days of user activity, but scripts can query up to 30 days.
RSS Feed
