In this blog post we explore how to build microservices with a focus on achieving PCI DSS Level 1 compliance while minimizing our responsibility for card holder data. Businesses commonly need to meet PCI, HIPAA, or alternative compliance standards as part of doing business. So why PCI compliance? It’s an often challenging but typical requirement that organizations must meet when dealing with payment details at scale. The requirements are easily accessible and are interesting requirements for evaluation purposes.
What is PCI compliance?
PCI compliance is an established set of standards created to safeguard transactions and the details of transactions in a secure and confidential manner. There are various aspects of PCI compliance, depending on the nature of the application and where it fits into the transaction process. Generally speaking the focus is commonly on PCI DSS Level 1 (which requires auditors to review and certify the compliance). Not all compliances require level 1 certification - if you handle a smaller number of transactions you can complete a questionnaire rather than complete a full auditor.
The PCI data security standard specifies twelve requirements for compliance, in six groups. The six groups include:
- Building and maintaining a secure network and systems
- Protect cardholder data
- Implement and maintain a vulnerability management program
- Implement strong access control measures
- Regularly monitor and test networks containing PCI data
- Maintain an information security policy
Each version of PCI DSS has divided these six requirements into a number of sub-requirements differently, but the twelve high-level requirements have not changed since the inception of the standard. PCI compliance can be controversial, and should be considered a minimum bar for the security of cardholder data. Being PCI compliant does not prevent a company from suffering a breach, but it can help mitigate the effects.
It’s important to note, this article will focus on a subset of the technical requirements of PCI and does not extensively review all of the various requirements an organization must meet to be PCI compliant.
Highlights from the PCI standard include:
- Use network and host level firewalls!
- Continuously monitor and review network traffic!
- Encrypt cardholder data during transit and at rest!
- Provide audit logs for all aspects of the services with access to PCI data!
We’re going to focus on these highlights throughout the article, as we narrow the scope of our PCI audit and aim for minimal effort responsibility. The information protected by the PCI DSS Level 1 standard includes the primary account number, bank identification numbers, the account holder name, the expiry date, and service code. Any and all credit card authentication data (track data, verification number, pin or passcode) cannot be stored at any time. The more data you store as part of your service, the more risk there is of exposure - both for the merchant and for the cardholder.
Considering the data elements involved, it’s now appropriate to discuss PCI scoping!
Controlling the compliance scope?
In order to minimize the risk associated with handling cardholder data, it’s
important to carefully consider and control the scope of your PCI compliance. In
general any system with access to credit card data elements in
ENCRYPTED with decryption key available is considered in scope for an audit.
You can exclude systems where the card holder data is encrypted without access
to the decryption key, the data is run through a oneway hashing algorithm such
as SHA256, or the data in question is the bank identification number (which is a
permitted truncation of the primary account number). Minimizing the scope of
systems with access to the card holder data will assist in minimizing the effort
required for compliance.
You can use these rules to minimize the systems that are considered in scope. Ensuring the data is unreadable removes it from scope. If a service can read the data, it is in scope. If a human can read the data, it’s also in scope.
Using AWS Services as building blocks for compliance!
AWS has achieved PCI DSS Level 1 compliance status for many of their services. You can review the PCI compliant AWS services here: Services in Scope
AWS regularly reviews and adds new services to it’s PCI scope based on customer requests. You can use these services to help reduce the scope of your compliance audit. If there’s a service that does not hold the desired compliance state, let the teams at AWS know.
Let’s consider using a managed service like RDS to store card holder information as an example:
- If you store card holder data in a managed service, you must still ensure that the data (like the PAN) is encrypted at rest to meet the requirements.
- Services such as AWS RDS allow you to create a PCI compliance database cluster when configured correctly.
- There are three key configuration items to ensure you have configured correctly:
- Encryption in transit (TLS1.2)
- Encryption at rest (AES 256)
- Audit logging
- In addition to the above, you also need to provide strong network and host firewalls.
- The host firewall requirement can be met by the AWS security groups feature.
- The network firewall requirement can be met by both VPC design and Network ACLs.
- Within a VPC network, you can generate flow logs. Depending on the requirements you can do this for all network interfaces within the VPC or just a few targeted adapters.
- Any system with access to the RDS database and the PCI data is also in scope.
- Web servers, application servers, anything with the ability to connect to and read the data is in scope.
As you can tell from the example above, even though we’re using a PCI compliant service like AWS RDS the scope expands to include other systems that have the potential to access the card holder data. We can use additional AWS building blocks (like VPCs and Security Groups in the example) to help minimize the scope.
While services such as AWS EC2 are extremely flexible and allow for maximum customizability of the service you are building, it’s also the most complex in terms of compliance. With AWS EC2 you are responsible for the entirety of the configuration of the operating system, it’s logging, antivirus, system integrity monitoring, etc. In order to minimize the scope and operation burden, it can be significantly easier to leverage managed services (or simply move higher up the system stack) to accomplish your objectives - if your requirements allow for it.
This leads us to compare AWS services which meet PCI compliance requirements to our business and technical requirements. Commonly I would lean towards the usage of AWS’s API Gateway and Lambda as opposed to AWS EC2 to minimize the scope for an audit. This can lead to architectual decisions that need to balance several technical requirements.
Since we’re looking at PCI compliance as the use case, let’s expand on that. Do you know a common business case for PCI? E-commerce!
Let’s pretend that we’re operating a business that develops robotic companions for the general public. On our website we have a list of robots, with specifications and options. Prices yet to be announced, and no method of payment available yet. In order to take payments from customers the company has decided to build a service to accept credit card data.
Let’s step through the payment process they are looking to implement:
- A user will order products from the robotic companion catalog.
- The user will store details such as their name in the application.
- The user will need access to order history.
- A user will need to pay a one-time-fee for the robotic companion.
- Optionally the user can subscribe to monthly software updates to improve the robotic companion.
Here’s how this might look:
Here’s what’s going on in the diagram:
- Customers load up the e-commerce website in their browser. The website is loaded over AWS CloudFront which performs WAN optimization and some content caching.
- Dynamic website components, user authentication, and payment processing is sent through AWS CloudFront to AWS API Gateway.
- User authentication is handled by AWS Cognito, which stores user profiles, mfa, and limited data sets.
- AWS API Gateway uses the provided user identity from AWS Cognito to query the product catalog from AWS DynamoDB.
- Custom logic (like decrypting card data, encrypting card data, generating derivitive data, etc.) can be executed by AWS Lambda.
- Transactional and card data is stored on the AWS RDS Aurora cluster (encrypted, tls, audit logs to AWS CloudWatch Logs).
- Using AWS CloudWatch Events, the AWS Lambda function can be triggered on a schedule (e.g. for monthly billing).
Of course you could also minimize this a bit further by utilizing another managed service such as Amazon Payments instead of storing any card holder details at all. This would remove steps 7 and 8 from the list.