This newsletter is the second of a set dedicated to 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 first part is available here.
In this newsletter we are addressing Requirement 2 - Do not use vendor-supplied defaults for system passwords and other security parameters.
In this newsletter we are addressing Requirement 2 - Do not use vendor-supplied defaults for system passwords and other security parameters.
The Microsoft Azure platform is generally well protected against attacks that try to exploit default credentials and default settings. Most services are “secure by default”: when you instantiate a new service, Azure does not create generic/default accounts but asks you for a password or grants you access to resources using your existing credentials instead.
However, be aware that this logic may not be true for Azure services provided by third-party vendors (like pre-configured virtual machines) or with additional software that you install on top of what Azure provides. For strict PCI DSS compliance, you may also have to disable unneeded features that can be included by default in IaaS or PaaS resources.
Also keep in mind that Azure is evolving very rapidly and that you must stay informed of the latest changes (and their default values) if you want to maintain the highest security level. For instance, you may want to disable features that become obsolete.
However, be aware that this logic may not be true for Azure services provided by third-party vendors (like pre-configured virtual machines) or with additional software that you install on top of what Azure provides. For strict PCI DSS compliance, you may also have to disable unneeded features that can be included by default in IaaS or PaaS resources.
Also keep in mind that Azure is evolving very rapidly and that you must stay informed of the latest changes (and their default values) if you want to maintain the highest security level. For instance, you may want to disable features that become obsolete.
Objective of Req 2.
Ensure that systems in scope are appropriately configured and hardened based on industry best practices, run only services and accept only protocols required, justified and approved for their purposes.
PCI-DSS Controls
2.1-2.6
Responsibilities
There is no requirement which compliance lays solely on Microsoft. Compliance with Requirement 2 is either fully ported by the Customers or shared with Microsoft.
Customers sole responsibilities:
Shared responsibilities
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
Customers sole responsibilities:
- 2.1.1 - For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Customers are responsible for ensuring any on-site wireless networks are properly segmented and have proper security such that the Azure VM’s within the customer CDE and not at risk of compromise.
- 2.2.1 - Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. For example, web servers, database servers, and DNS should be implemented on separate servers. Customer must ensure that only one primary function is used per Iaas instance. Not applicable for Paas service.
- 2.3.e - If SSL/early TLS is used for the encryption of non-console access, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS. Customers using SSL/ early TLS protocols for their non-console administrative access must comply with PCI-DSS Appendix 2.
- 2.4 Maintain an inventory of system components that are in scope for PCI DSS. Customers are responsible for maintaining an inventory of all in-scope Paas services and Iaas instances.
- 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties. Customers are responsible for maintaining their own policies and procedures for configuring security parameters on in-scope Paas services and Iaas instances.
Shared responsibilities
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
- Microsoft is responsible for enforcing Azure Active Directory policy requirements on new passwords supplied by customers within the AADUX portal
- Customers are responsible for not setting or using default credentials for in-scope Paas service and removing defaults during the configuration of their baseline configuration process for in-scope Iaas instance
- 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
- 2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure.
- 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
- 2.2.4 Configure system security parameters to prevent misuse.
- 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
- Microsoft is responsible for ensuring the use of strong cryptography on the access to the hypervisor infrastructure and on the Customers access to their service/iaas consoles through the Azure portal.
- Customers are responsible for enforcing strong cryptography for non-console Iaas instance access
Azure Toolkit for Req 2
 | Azure Active Directory Azure AD is the main directory and identity management service in Azure. It centralizes user and application accounts used in Azure Portal and PaaS services. As such, it includes important security settings (including password policies). Many default settings can be changed via menus in Azure Portal but some settings can only be changed using an API. The AzureAD and MSOnline modules for PowerShell or the Microsoft Graph Explorer Web site are valuable tools to query this API. |
 | Azure AD Domain Services Azure ADDS is an extension to Azure AD for IaaS services. It is the Azure equivalent of an on-premises Active Directory domain. If your architecture includes several virtual machines, it is highly recommended to setup Azure ADDS and join them to a domain. You will then be able to leverage the power of Group Policy Objects (GPO) to deploy and enforce your configuration standards (security policies, computer configuration, hardening…) Azure ADDS itself is a PaaS service and has limitations. For example, the Domain Administrator privileges will not be accessible, which will prevent you from changing some domain-wide security settings (like the password policy of local user accounts). The alternative option is to create and manage your own domain controllers, using virtual machines. |
 | Azure Virtual Machines An important aspect of Requirement 2.2 is the segregation of server roles. This can be achieved more easily on a cloud environment thanks to the lower cost of virtual machines. Azure has a very large offer in terms of VM sizes, including servers with dynamic (burstable) performance. This allows you to create dedicated VMs at virtually no cost. |
 | Remote Desktop Remote Desktop access is particularly important in a cloud scenario as it replaces the physical console access. To comply with requirement 2.3, you may have to increase the default encryption level used by the RDP protocol (depending on your clients compatibility). Azure virtual machines are not different from on-premises servers regarding this configuration. |
 | Azure Security Center Azure Security Center is an interface in Azure Portal that brings you an overview of your platform in terms of security. It will recommend corrective actions if a default configuration that creates a risk has not been changed. |
 | Azure Portal The “All resources” view of Azure Portal is an exhaustive list of your cloud resources. It can prove very useful when building the inventory of system components required by PCI DSS. |
RSS Feed
