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.