Skip to main content

Part 1 - What, Why and How / The landing zone of a PCI-DSS compliant application inside Microsoft Azure

This is the first article from a series of them about how to build a PCI-DSS-compliant application on top of Microsoft Azure and Kubernetes. Together we cover the journey of building a PCI-DSS compliant application. The final output is a blueprint that can be used as a starting point to build an application.


What is PCI-DSS?
Payment Card Industry Data Security Standard is a regulatory requirement that aims to secure credit and debit card transactions against data theft and fraud. The compliance is divided into 4 levels depending on the number of transactions. Level 1 starts at 6M transactions per year compared to Level 4, with less than 20k transactions per year. 
Each level involves different levels of audit, as we can see below:
  • Level 4: yearly SAQ assessment + quarterly PCI scan (may be required)
  • Level 3: yearly SAQ assessment + quarterly PCI scan (may be required)
  • Level 2: yearly SAQ assessment + quarterly PCI scan (may be required)
  • Level 1: yearly an internal audit by an authorized PCI auditor + quarterly a PCI scan by an ASV (Approved Scanning Vendor) 
PCI-DSS Core Mission
Increase and enhance the cardholder data security for the organizations that transmit,  process and store credit card data by reducing the vulnerabilities and preventing fraud. This is done by increasing the control at all layers where cardholder data is transmitted, processed and stored.
The standard applies to all legal entities that maintain CDE (Cardholder Data Environment) from banks that issue credit cards and online payment services to retail or service providers that offer online services for payment processing.

The technical view
From the technical point of view, PIC-DSS requirements cover 6 main categories: Security network, Secure cardholder data, Vulnerability management, Access Control, Networking monitoring and testing. Let's take a look in more detail at what each of these categories requires:
Secure network:
- Firewall needs to be installed and managed
- System password needs to be in place and not inherited from the vendor
Secure cardholder data:
- Stored data of the cardholder must be protected
- Cardholder information transmitted over the network needs to be protected (encrypted)
Vulnerability Management:
- Anti-virus software must be used and managed (updated)
- Secure application and system needs to be developed and maintained
Access control:
- Access to cardholder data must be restricted to business need-to-know basic
- Unique ID must be assigned for each person with computer access cardholder
- Physical access to cardholders must be restricted a 
Network monitoring and testing:
- The access to cardholder data and network resources must be monitored and tracked
- Security systems and processes must be regularly tested
Information security:
- Maintain a policy that addresses information security for all personal

In total, there are over 300 requirements that are grouped into the above 12 categories. Depending on the category some requirements are prescriptive related to the technology and products that need to be used. 

PCI-DSS and Cloud
Yes, it is! What do we mean by YES? Large cloud providers like AWS, Google Cloud and Microsoft Azure provide services that are certified as a PCI-DSS Level 1 Service Provider. Each cloud vendor offers a list of services certified as PIC-DSS Level 1, but it doesn't mean that all their services are certified. 
The service certification can be only for specific tiers. For example, there are tiers from different computation services that are not certified because they are using a shared model and not dedicated resources. It is up to us how we use, configure and build the application on top of them.

Above, we can see an extract from Microsoft Azure Compliance Offerings where two services are not certified.








Comments

Popular posts from this blog

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Can User Technical Profile Influence AI Architecture Decisions?

In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see...