In this newsletter we are addressing Requirement 2 - Do not use vendor-supplied defaults for system passwords and other security parameters.
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.
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.
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 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.