Apple is ≠ Apple: Audit Scoping vs. PCI-DSS Scoping.

Photo credits: https://stock.adobe.com/

           I used to think all apples were the same until I went into the grocery store one day and met a lovely attendant who told me the right apple brand to buy. I tried a couple of the apples they had in the store and I could tell the difference in their taste.  I got to learn that some apples are only good raw, some others are better for cooking, and some types are good for just about anything. It was a surprise to me to learn that almost half the apples grown in the United States end up as applesauce, jellies, juice, and other apple products.

Enough about apples for now; can we say all scoping engagements are the same?

           Scoping in most audit engagements is centered on determining what is important to the audit engagement. If you have all the time in the world and also possess all the resources; then everything is important and must be covered in the audit engagement, but this is not always the case. We often adopt a risk-based approach to deciding what should be included in an audit engagement at a point in time or over a period of time. This method saves time and helps us to tailor our resources appropriately during the audit engagement. In PCI-DSS assessments, it is not so. Whatever is important to a credit cardholder data environment (CDE), must be in scope, and what is in scope must be assessed and documented. In the context of PCI DSS, scoping refers to the process of identifying and documenting the boundaries of the CDE. At this moment I would like to share what I think is important when it comes to PCIS-DSS scoping within a cloud environment.

           Properly scoping a cloud environment is important in PCI DSS (Payment Card Industry Data Security Standard) because it helps us to ensure that only authorized personnel have access to sensitive cardholder data. Another main benefit of proper scoping in the cloud environment is to ensure that we prevent unauthorized access to this data by third parties such as service providers, especially because some service providers might not have effective controls to help secure your company’s data and it is also possible for these service providers to experience breaches or have some insider threat that could access your data.

There are several specific requirements in PCI DSS standards that are related to scoping and segmentation of the CDE. For example, requirement 1.3.6 mandates that the CDE be placed in an internal network zone (which is physically or logically) separated from the DMZ and other untrusted rest of the network. Also according to Appendix A1.1.1, logical separation with regard to service providers should be implemented as
follows:
• The provider cannot access its customers’ environments without authorization.
• Customers cannot access the provider’s environment without authorization.

In a cloud environment, account segmentation refers to the practice of dividing a cloud account into smaller, isolated units called “segments.” This is often done to improve security, control access to resources, and manage costs.

Here are some of the ways to implement account segmentation in a cloud environment so as to meet PCI-DSS requirements:

  • Use multiple accounts: Each segment is created as a separate cloud account, with its own set of resources and permissions. This is a good option if you need to completely isolate segments from one another.
  • Use resource groups: You can use resource groups to organize resources within a single account. This allows you to apply permissions and policies at a more granular level, without creating multiple accounts.
  • Use network segmentation: You can use network segmentation techniques such as virtual private clouds (VPCs), subnets, and security groups to isolate segments from one another.
  • Use identity and access management (IAM): You can use IAM to control access to resources within a single account. This allows you to grant permissions to users, groups, and applications based on their needs.

Overall, account segmentation can help you improve the security and control of your cloud environment, but you would need segmentation penetration testing to help you determine whether or not the segmentation approach you adopted is effective. According to requirement 11.4.5, if segmentation is used, it must be verified periodically by technical testing to be continually effective, including after any changes, in isolating the CDE from all out-of-scope systems. Your Qualified Security Assessors (QSA) would have to assess and determine if your segmentation approach is adequate or not. The QSA would also decides if your scoping covers all the assets that should be reported in your CDE or not.

Proper scoping and segmentation of the CDE are important because they help ensure that only those systems and networks that need access to cardholder data have access to it and that all other systems and networks are restricted from accessing this data. This helps reduce the risk of data breaches and other security incidents involving cardholder data.

While it is better to say that each apple is different and unique, with a specific purpose, we can also rightly say that each scoping in audits is different and unique compared with scoping in PCI-DSS assessment. I would love to write more on scoping at a later date and write about how to really perform scoping for PCI-DSS assessment.