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

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

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