The impact of the new PCI 4.0 on the 3.2.1 requirement 1 are in the form of Reformulation, Clarification, Splitting / bundling, Scope extension and Removal.

The scope extension expresses itself through terminology changes, namely: 

• Firewall(s) and router(s) are replaced by the notion of "Network Security Control(s) (NSG)". This is related to use of virtualization technologies as well as usage of cloud technologies.
• Internet is replaced by the term more general notion of "Untrusted network"
• Cardholder data environment is enlarged to the notion of "Trusted network".
• Cardholder data is replaced by "account data"

​Get your PCI 4.0 COMPLIANCE DASHBOARD TOOL . Fully aligned with PCI DSS V4.0. It includes the defined approach requirements, the customized approach, applicability notes, purpose, good practices & further information, definition, example and defined testing procedures and prioritization approach. It also provides templates to register your compensating controls, controls met with remediations but also to register your customized Controls, the outcome of the customized approach risk assessments and the risk assessments for the definition of frequency periods as well as to register execution of vulnerability scans and penetration tests.

It all starts with the Title
3.2.1 - INSTALL AND MAINTAIN A FIREWALL CONFIGURATION TO PROTECT CARDHOLDER DATA
Becomes
4.0 - INSTALL AND MAINTAIN NETWORK SECURITY CONTROLS

3.2.1 - 1.1 Establish firewall and router configuration standards. 
Change: Reformulation + Scope

4.0 - 1.2.1 Configuration standards for Network Security Controls (NSC) rulesets are: 
• Defined.
• Implemented.
• Maintained.

3.2.1 - 1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations
Change: Reformulation + clarification + Scope

4.0 - 1.2.2 All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1.

​3.2.1 - 1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.
Change: Reformulation 

4.0 - 1.2.3 An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks.

​3.2.1 - 1.1.3 Current diagram that shows all cardholder data flows across systems and networks
Change: Reformulation + Clarification 

4.0 - 1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:
• Shows all account data flows across systems and networks.
• Updated as needed upon changes to the environment.

​3.2.1 - 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone

Change: Removal due to Redundancy

​3.2 1 - 1.1.5 Description of groups, roles, and responsibilities for logical management of network components
Change: Reformulation + clarification 

4.0 - 1.1.2 Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.

​3.2.1 - 1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
Change: Reformulation + Split 

4.0 - 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.
+
4.0 - 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.

​3.2.1 - 1.1.7 Requirement to review firewall and router rule sets at least every six months
Change: Reformulation + Scope

4.0  - 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

​3.2.1 - 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
Change: Removal due to Redundancy

​3.2.1 - 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.
+
3.2.1 - 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
Change: Reformulation, Split and Clarification

3.2.1 - 4.0 - 1.3.1 Inbound traffic to the CDE is restricted as follows:
• To only traffic that is necessary.
• All other traffic is specifically denied.
+
4.0 - 1.3.2 Outbound traffic from the CDE is restricted as follows:
• To only traffic that is necessary.
• All other traffic is specifically denied.

​3.2.1 - 1.2.2 Secure and synchronize router configuration files.
Change: Reformulation + Clarification

4.0 - 1.2.8 Configuration files for NSCs are:
• Secured from unauthorized access.
• Kept consistent with active network configurations.

​3.2.1  - 1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
Change: Reformulation + Clarification + scope

4.0 - 1.3.3 NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that:
• All wireless traffic from wireless networks into the CDE is denied by default.
• Only wireless traffic with an authorized business purpose is allowed into the CDE.

​3.2.1 - 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.
Change: Reformulation and scope

4.0 - 1.4.1 NSCs are implemented between trusted and untrusted networks.

​3.2.1 - 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
+
3.2.1 - 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.
Change: Reformulation + Bundle + Scope

4.0 - 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
• Stateful responses to communications initiated by system components in a trusted network.
• All other traffic is denied.

​3.2.1 - 1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.
Change: Reformulation

4.0 - 1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

​3.2.1 - 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
Change: Reformulation + Clarification

4.0 - 1.3.2 Outbound traffic from the CDE is restricted as follows:
• To only traffic that is necessary.
• All other traffic is specifically denied.

​3.2.1 - 1.3.5 Permit only “established” connections into the network.
Change: Reformulation

4.0 - 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
• Stateful responses to communications initiated by system components in a trusted network.
• All other traffic is denied.

​3.2.1 - 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks
Change: Reformation

4.0 - 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.

​3.2.1 - 1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.
Change: Reformation + clarification

4.0 - 1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.

​3.2.1 - 1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. 
Change: Reformation + clarification + Scope

4.0 - 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows:
• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.
• Security controls are actively running.
• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period

​3.2.1 - 1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.
Change: Reformulation + Scope + clarification

4.0 - 1.1.1 All security policies and operational procedures that are identified in Requirement 1 are:
• Documented.
• Kept up to date.
• In use.
• Known to all affected parties.

Risk assessment was already part of the genesis of PCI DSS up to 3.2.1. Requirement 12.2 of PCI DSS 3.2.1 states: Implement a risk-assessment process that:
-Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
-Identifies critical assets, threats, and vulnerabilities, and
-Results in a formal, documented analysis of risk.

This enterprise-wide risk assessment is subjected to two key validation check by QSA: 

• Verify that an annual risk assessment process is documented and identifies threats, vulnerabilities, and results in a formal, documented analysis of risk
• Review risk-assessment documentation to verify that the risk-assessment process is performed at least annually and upon significant changes to the environment.

​PCI DSS 4.0 removes the mandatory character on the execution of  enterprise-wide risk assessments. Entities are however encouraged to continue  execution such assessment as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy and to enable entities to determine and understand broader and emerging threats with the potential to negatively impact its business.  

Target Risk Assessments are required for:

How frequently is frequently ? 
About 11 PCI DSS requirements provide organizations with flexibility to choose the frequently a given control is executed. 
The determination of the frequency must be supported by a targeted risk analysis taking int account: the sensitivity of the assets in scope of the given control, the threat(s) that the given control is protecting the assets from, the factors that could contribute to likelihood or impact and the the level of risk the entity is willing to accept.

PCI DSS 4.0 - 12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed must be supported by a targeted risk analysis that is documented and includes:
• Identification of the assets being protected by the requirements
• Identification of the threat(s) that the requirement is protecting against.
• Identification of factors (vulnerabilities) that contribute to the likelihood and/or impact of a threat being realized.
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.

Do you use a customized approach? 
Documented target risk assessments are also required wherever a customized approach is followed to meet the control objectives. 

PCI DSS 4.0 - 12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach.

PCI DSS 4.0 proposes a template to document these assessments. It  covers the following points:

Identify the PCI DSS requirement

• What is the objective the requirement
• Describe the mischief that the requirement was designed to prevent

Describe the proposed solution

• Customized control name/identifier (Use same identifier than in the Customized control matrix sheet)
• What parts of the requirement as written will change in the proposed solution?
• How will the proposed solution prevent the mischief?

Analyze any changes to the LIKELIHOOD of the mischief occurring, leading to a breach in confidentiality of cardholder data

• How successful the controls will be at preventing the mischief
• Typical reasons for the control to fail, the likelihood of this, and how could it be prevented
• How resilient the entity’s processes and systems are for detecting that the control(s) are not operating normally?
• To what extent do the controls detailed in the customized approach represent a change in the likelihood of the mischief occurring  (Mischief more likely to occur/No change/Mischief less likely to occur)
• Provide the reasoning for your assessment of the change in likelihood that the mischief occurs once the customized controls are in place.

Analyze any changes to the IMPACT of unauthorized access to account data

• What volume of account data would be at risk of unauthorized access if the solution failed?
• How the customized controls will directly:
• Reduce the number of individual PANs compromised if a threat actor is successful, and/or Allow quicker notification of the PANs compromised to the card brands.

Risk analysis Reviews and updates
Targeted risk assessments must be reviewed at least once every 12 months and upon changes that could impact the risk to the environment;.

The brand new PCI 4.0 Compliance dashboard 

• Lists requirements subjected to targeted risk assessments
• Provides a template for documenting the frequency related risk assesments 
• Provides a template for documenting the customized approach risk assessments

What you need to know

• It is up to each entity to determine whether and where to follow the defined approach or the customized approach. 
• The use of the customized approach will require greater initial effort to ensure the controls are properly implemented and can be effectively assessed.
• Controls met through a customized approach must be supported by a risk assessment, proper documentation (see below) and proper testing
• The customized approach can only be used for RoCs (Report of Compliance) and not SAQs (Self Assessment Questionnaires). 
• About 12% of the PCI DSS controls are not eligible for a customized implementation.
• Customized approach cannot be used mid-assessment to correct something that is not compliant. 
• Entities wishing to use the customized approach should consult with their compliance-accepting entity (acquirers or payment brands) to understand any related requirements or impacts.
• A QSA may assist with defining customized approaches but it cannot be the same QSA as the one performing the assessment. 
• The adequacy of customized approaches, the design, the implementation is left to the discretion of the QSA's. 
• It is recommended that entities design, implement, and document the controls for a customized approach long before the PCI DSS assessment begins.

Documentation - evidences
For each PCI control implemented through a customized approach, the following information is expected to be documented:

• • What is the name of the customized control 
  • What is the associated PCI control Id
  • What is the customized  approach objective (check customized approach column of the PCI Compliance Dashboard)
  • Description of the implemented control
  • Where is the control implemented
  • When is the control performed
  • Who is responsible and accountable for this control
  • Who is involved in managing, maintaining, and monitoring the control
  • How the implemented control meets the stated defined objective (defined in the standard)
  • What are the tests performed to prove the control meets the stated objective
  • Brief description of the results of the risk analysis for this control. (See below)
  • How  the control is maintained and how the control's effectiveness is assured.

How the PCI 4.0 Compliance Dashboard could help?
The PCI DSS 4.0 Compliance Dashboard provides in one view all information you need to consider for your compliance journey. In the context of the customized approach, it includes the defined approach requirements, the customized approach objectives, controls not subjected to customized approach as well as a register for the documentation of controls met with a customized approach with all the above information.

Track these "new requirements" with the new version of the PCI Compliance dashboard fully aligned with PCI DSS V4.0. It includes the defined approach requirements, the customized approach, applicability notes, purpose, good practices & further information, definition, example and defined testing procedures and prioritization approach. It also provides templates to register your compensating controls, controls met with remediations but also to register your customized Controls, the customized approach risk analysis, execution of vulnerability scans and penetration tests. A must to stay in the lead of your compliance journey. 
​
Get your PCI 4.0 Compliance dashboard right here

In the previous thread, I have briefly introduced the concept of Organization Compliance Environment (OCE) as the global elements within the organization which are subjected to a regulation or a standard in terms of processes, people, data and upholding IT infrastructure. This concept should be put in perspective with the scope of assessment being the part of the OCE subjected to a specific assessment/audit. 

For some organizations, the span of the assessment scope is equal to the OCE. However, for others the OCE could reveal quite large and therefore demanding in terms of resources, time, finance as well as being a considerable source of stress. To rationalize the resources, avoid endless, tedious and unmanageable projects, poor outcomes, frustration, huge set of evidences, and minimize the risk of non-compliance, it is paramount to reduce the scope of an assessment as much as possible. Hence, subdividing the validation of the organization compliance into multiple assessments, each associated to a specific scope dealing with a subset of the OCE.  

In physics, fission is the act of splitting a nucleus of an atom into nuclei of lighter atoms. “Compliance-fissioning” is the term I give to the act of splitting the OCE. An analogy could be a global country subdivided into territories or states. 
The management of the organization compliance program to a specific regulation or standard is equivalent to the management of multiple compliance projects, each one associated to a manageable scope, timeline, resources and budget. It is the responsibility of the government (Executive Boards + Compliance managers) to clearly draw and document the OCE and each portion (nuclei) in terms of the scope/ object of the assessment and what is excluded from it (from the original OCE). 

There is a panel of ways to OCE-fission. Production channels, legal entities,  business units, region, assets, network subnets are just few examples. I however draw your attention to the fact that the definition of the boundaries as it could be a sensitive matter in some cases where the regulatory or standardization bodies set the rules for such segregation. Not abiding with these rules put the whole compliance at risk. A good practice is to be aware of what is allowed and to involve the compliance validation body early in the loop and get their approval. Based on my experience, compliance bodies tempt to stay unengaged, away from any "official" and clear validation in this matter. However, proactively sharing our compliance plan and map with them is a good thing, something they could not ignore and could be used in a later stage.      

Didier Godart
Check my PCI ressources (Tools, book, templates)  on PCI-GO

This part covers the very first step of establishing a compliance program. 

Compliance management can be defined as the process by which managers, plan, organize, control, and lead activities that ensure compliance with laws and standards.



Without a clear understanding of the context, no headway is possible and we are deemed to run like a headless chickens! Hence, the very first task a compliance manager must undertake is the collect and analysis of information about the context at stake. 

By context, I’m tackling two points: 

1. The regulation or norm. What is it about? Which are the subjected entities? What is the certification process? Who are the certification bodies? Is there a timeframe set by the regulators? What are the requirements and associated objectives? What are the usual pitfalls hindering the path to certification? What evidences are expected to prove compliance?  
2. The organization context. What is the organization compliance environnement (OCE), meaning which business processes and assets are subjected to the regulation or norm? What are the organization motivators and inducers? What are the risks incurred by the organization in case of non-compliance? What are the risks incurred by the organization by complying to the regulation or norms, meaning what are the potential expected constraints, impediments and additional costs associated to the compliance implementation and maintenance? Are there other similar compliance requirements already in place? What are the usual pitfalls for running such program in this organization? What are the risks of failure? What is the current level of in-house expertise and which additional expertise is required in the form of trainings or external assistance?  Who are the internal stakeholders, including the program sponsors and third parties? What is the expected due date for compliance?   

In the context of the sundry missions fulfilled in my humble career, one of my preferred roles is the one of compliance manager. A challenging role wherein I support and advise my clients with the double aim of getting them certified and maintaining this status over time.



Ensuring compliance with a regulation or a specific norm is far from being a trifling matter. It is a long and tedious program requiring human and financial devotion. 

Depending on the compliance matter, some departments will be more affected. But one should not be mistaken. Compliance isn’t just the brainteaser of Legal, IT, Finance, Production or Security. No, it generally involves, at one point or another, the whole company spectrum. All individuals from the top to the bottom of the hierarchy. Resources that are digressed from their core activities and priorities. Thus, this is seldom for the sake of indulgence that company boards decide to follow this path. No, the two major drivers are: 1) Avoid or limit financial penalties or business disruption in case of legal or contractual infringements and 2) Get access to markets requiring such compliances.

In the following posts, I will endeavor to further delve into this field of compliance management and further discuss the key components, activities and milestones but also about the methods and tools. 

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. ​​

7.1 - 8.8​

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.

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.

• 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.

This newsletter is our sixth 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. ​​

Complying with Req 1 on Azure

Complying with Req 2 on Azure

Complying with Req 3 on Azure​​

Complying with Req 4 on Azure

Complying with Req 5 on Azure

​Protect systems and applications against the exploitation and compromise of cardholder data through appropriate vulnerability management, change management and secure development processes. 

​6.1-6.7

th6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities. 
PaaS & IaaS customers must design, implement and maintain a process for identifying vulnerabilities and assigning appropriate risk rankings.

Microsoft Azure is responsible for establishing and implementing procedures to scan for vulnerabilities on hypervisor hosts in the scope boundary. Vulnerability scanning is performed on server operating systems, databases, and network devices with the appropriate vulnerability scanning tools. The vulnerability scans are performed on a quarterly basis at minimum. Microsoft Azure contracts with independent assessors to perform penetration testing of the Microsoft Azure boundary. Red-Team exercises are also routinely performed, and results used to make security. 

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches. Install critical security patches within one month of release. 
IaaS customers are responsible for ensuring all IaaS instances are protected from known vulnerabilities by installing applicable vendor supplied security patches. 
Microsoft Azure is responsible for ensuring all network devices and hypervisor OS software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Unless a customer requests to not use the service, a patch management process exists to ensure that operating system level vulnerabilities are prevented and remediated in a timely manner. Production Servers are scanned to validate patch compliance on a monthly basis. 

6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: 

• In accordance with PCI DSS (for example, secure authentication and logging) 
• Based on industry standards and/or best practices. 
• Incorporating information security throughout the software-development life cycle 

PaaS & IaaS customers are responsible for developing and following a secure software development program for both classic and cloud based applications. Industry standards, such as OWASP, should be incorporated into the program. 
Microsoft Azure applications and endpoints are developed in accordance with the Microsoft Security Development Lifecycle (SDL) methodology which is inline with DSS requirements. 

6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. 

PaaS & IaaS customers are responsible for ensuring all development and test accounts and passwords are removed from their servers and applications before promoting changes to production. 
Microsoft Azure is responsible for ensuring that major releases are subjected to a Final Security Review (FSR) prior production deployment. This review is performed by a designated Security Advisor outside of the Azure development team to ensure only applications ready for production are released. As part of this final review it is ensured that all test accounts and test data have been removed. 

6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: 

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. 
• Code reviews ensure code is developed according to secure coding guidelines 
• Appropriate corrections are implemented prior to release. 
• Code-review results are reviewed and approved by management prior to release. 

PaaS & IaaS customers are responsible for having a documented, approved and in-place SDLC program that incorporates code review prior release. The program should be aligned with industry standards and should also incorporate independent third party application review. 
Microsoft Azure is responsible for ensuring that Microsoft Azure applications and endpoints are developed in accordance with the Microsoft Security Development Lifecycle (SDL)methodology. 
 
 6.4-6.4.6 Follow change control processes and procedures for all changes to system components. 
Microsoft Azure is responsible for ensuring that an established change and release management processes in place to control implementation of major changes on their scope.

IaaS and PaaS customers are responsible for their own applications hosted in Microsoft Azure. Customers are responsible for creating and maintaining their own change control processes and procedures for all changes to their in scope Azure components. 
More specifically for: 

• 6.4.1, 6.4.2 - Customers are responsible for maintaining segregation and access controls between non card data environments, test and development environments and the cardholder data environments. This includes ensuring Iaas instances are created and deployed on appropriate virtual networks. 
• 6.4.3 - Customers are responsible for ensuring that production PANs are not used for testing or development. 
• 6.4.4 - Customers are responsible for removal of test data and accounts before promoting changes to production. 
• 6.4.5, 6.4.6 - Customers are responsible for creating and maintaining their own change control processes and procedures for all changes to their in-scope Azure components. 

6.5 Address common coding vulnerabilities in software-development processes as follows: 

• Train developers at least annually in up- to-date secure coding techniques, including how to avoid common coding vulnerabilities. 
• Develop applications based on secure coding guidelines. 

Microsoft Azure is responsible for educating their developers to secure coding techniques and ensuring that developments are based on secure coding practices.  

Paas and Iaas customers are responsible for protecting against common coding vulnerabilities and training developers in secure coding techniques.

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: 

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes 
• Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic. 

Microsoft Azure is responsible for testing public-facing web applications as part of its SDL process before applications are deployed to the production environment. Additionally, Microsoft Azure is responsible for scanning all public-facing web applications in production on a regular basis to detect any possible vulnerabilities. 
​
Paas and Iaas customers are responsible for ensuring all their public-facing web applications undergo security assessments at least annually, or when a major change has been made. 
​
6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. 
Paas and Iaas customers must ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. 

Azure Security Center and Azure Monitorare the key Azure components for Requirement 6.

They leverage Azure Log Analytics and Azure Automation engines to collect, store and analyze logs, events and metrics on all Azure resources of an infrastructure. They are also the entry point to many other Azure security tools.
​
Most relevant Security Center features:

• Security Center lets you create security policies that define the target security level for your system components and is used by Azure to constantly analyze them. link
• Security Center computes a global Secure Score and generates recommendations for each security concern found. In accordance with Requirement 6.1, each recommendation is ranked with a severity level (low/medium/high). link
• Security Center is also PCI DSS aware and can directly generate a compliance report based on the current configuration of your Azure resources. link

Tools for Virtual Machines:

• Azure Security Center can identify and help you apply missing operating system patches on virtual machines. This is a valuable functionality for Requirement 6.2. link
• Azure Virtual Machine Update Management allows you to gain control over operating system updates (which ones to install and when). It can also be useful for Requirement 6.2. link
• Azure Virtual Machine Inventory Collection can help you maintain a documented inventory of your servers, as needed by several PCI DSS Requirements. link
• Azure Virtual Machine Change Tracking is a solution to identify changes made on installed software, file system, running services and registry keys. It can be used to meet Requirement 6.4. link

Tools for SQL Databases:

• Azure SQL Database Vulnerability Assessment is a tool that scans databases to discover vulnerabilities. It generates a report with a risk classification and pointers to resolve the issues. link

Tools for Web Applications:

• Azure Application Gateway includes a Web application firewall that protects Web sites from common exploits and vulnerabilities. Based on OWASP CRS 3.0 rules, this includes SQL injections, Cross-site scripting, HTTP protocol violations, etc. It can be a good solution to meet Requirement 6.6. link
• Azure Marketplace also provides firewall solutions from third-party vendors like FortiGate, Barracuda and SonicWall. These network appliances are bundled as pre-configured virtual machines that you can insert into your IaaS network infrastructure.

Environment isolation:

• Azure Subscriptions and Resource Groups are the first layer to isolate development, test and production environments to comply with Requirement 6.4.1. Subscriptions and Resource Groups help you organize your infrastructure assets and are used to implement access control. link
• Depending on the resource type, each Azure component car then be further isolated using specific features. link

Third-party security scanners:

• TenableCore Nessus is available on Azure Marketplace as a pre-configured virtual machine that you can deploy inside your architecture to run vulnerability scans.
• Qualys Virtual Scanner Appliance is also available for the same purpose (Requirements 6.1 and 6.2).

Development tools:

• SonarQube is an open-source code analyzer useful to detect flaws listed in Requirement 6.5. It is available on Azure as a virtual machine or as an extension on Azure DevOps (the Microsoft Developer Services solution hosted on Azure).
• Microsoft Security Code Analysis is a new tool from Microsoft to achieve the same result.
• Azure Repos (part of Azure DevOps) includes built-in support for Git repositories, which allows you to include code reviews (Pull Requests) in your development workflow to meet Requirement 6.3.2. link
• With Git repositories, Azure Repos also provides a full history of code changes.