This article was made in preparation for a webinar on this topic. You can watch the recording of this webinar on BrightTalk.

What is PCI-DSS?

PCI-DSS or Payment Card Industry Data Security Standard “is an information security standard for organizations that handle branded credit cards from the major card schemes.” — Wikipedia

What is PCI-DSS Compliance?

“According to the PCI Security Standards Council, PCI DSS is a set of universally accepted standards that help protect the safety of customer data. PCI DSS sets the operational and technical requirements for organizations accepting or processing payment transactions, as well as for software developers and manufacturers of the applications and devices used in those transactions.

Put simply, any business entity that is involved in accepting, processing, and storing payment card information is required to comply with PCI DSS.”

What are the different levels of PCI-DSS?

• Level 1: Merchants processing over 6 million card transactions per year.
• Level 2: Merchants processing 1 to 6 million transactions per year.
• Level 3: Merchants handling 20,000 to 1 million transactions per year.
• Level 4: Merchants handling fewer than 20,000 transactions per year.

How can you avoid PCI-DSS compliance?

Leverage a PCI compliant integration. Even if PCI-DSS compliance can be achieved in a serverless context we highly recommend that you don’t roll your own PCI compliant system and instead lean on a level 1 PCI compliant integration such as Stripe.

At Serverless Guru, we work with clients all the time who need to handle card payments for their web applications, we always help lay out the strict requirements and cost involved to create their own PCI compliant systems.

While initially pushing them to use a fully managed level 1 PCI compliant integration such as Stripe. This ensures the least amount of overhead and it does not restrict you from accessing certain information which does not fall under the PCI compliance umbrella.

For example, Stripe “returns non-sensitive card information in the response to a charge request. This includes the card type, the last four digits of the card, and the expiration date. This information is not subject to PCI compliance, so you are able to store any of these properties in your database.”

Therefore, you’re getting the best of both worlds. You have access to non-sensitive data which gives some amount of insight and you’re off loading the full PCI compliance burden to a third party.

What will happen if I handle cardholder data?

If you need to handle cardholder data or choose not to simply use a fully managed UI integration like Stripe and instead take in cardholder data into your backend.

The second that cardholder data touches your system you will fall under SAQ-D or Self-Assessment Questionnaire D. SAQ-D is the most strict out of all the SAQs, “with over 40 pages of requirements you must implement to remain PCI compliant.”

The definition for who falls under SAQ-D according to PCI-DSS includes anyone who falls underneath this classification:

• E-commerce merchants who accept cardholder data on their website
• Merchants with electronic storage of cardholder data

Meaning that if you’re making an E-commerce site or your web/mobile application needs to simply accept payments and you have no need past accepting payments then use something like Stripe or Braintree.

Serverless Guru’s recommendation is to avoid handling card data all together. However, if you need to handle card data, let’s now take a look at a few areas a serverless application which will need to be PCI compliant.

PCI-DSS compliance with serverless

Below we will talk about a few ways to be compliant in a serverless environment. This is not exhaustive.

Core Areas

• Data Access
• Data Encryption
• Logging and Auditing
• High Availability and Disaster Recovery

Data Access

We recommend to all of our clients the usage of the Serverless Framework or Serverless Components (beta) to build the application infrastructure. We specifically use the Serverless Framework IAM role per function plugin to ensure that every Lambda function is operating with least privilege.

We also isolate AWS accounts based on stages/environments to ensure that we have clear boundaries around production data. Depending on the size of the client we even go as far as to scope AWS accounts down to individual developers. However, we can typically achieve similar isolation by having each developer inside the dev AWS account deploy to their own stage.

This keeps overhead low, prevents developers from stepping on each other when rolling out new code, makes deployments quick (as all resources don’t need to be recreated) and easier collaboration between developers as they all live in the same account.

Data Encryption

When working with AWS, most services are either encrypted by default or give you the ability to turn on encryption. When working with AWS S3 we have the option to turn on encryption manually and with a service like Amazon DynamoDB encryption is enabled by default.

Another area we consider at Serverless Guru is limiting who has access to data inside the AWS console as even though you can have AWS S3 encryption or DynamoDB encryption. When viewing this data in the AWS console the data will still be visible. One strategy to safeguard against this is using IAM deny rules.

Logging and Auditing

Every cloud provider should have services offered around logging and auditing. AWS has a service called AWS CloudTrail which will track all the actions inside your AWS account which will be invaluable for auditing and post-mortems.

If you’re using AWS S3 for asset storage or even static web hosting then you’re going to also want to ensure that you have the following logging:

• Amazon S3 Server Access Logging
• S3 Object Level Logging for CloudTrail

Serverless applications which are leveraging AWS Lambda will have application logs streamed to Amazon CloudWatch automatically.

From CloudWatch, we would subscribe an Amazon Kinesis Data Firehose stream which will handle pushing logs into AWS S3 in real-time. We can get more sophisticated and have another AWS Lambda function process and analyze these logs as needed.

Once the logs arrive in AWS S3 we would set a lifecycle policy that pushes logs older than 30 days to Glacier storage reducing the total cost and ensuring that we keep a long running history of all logs flowing through our application.

High Availability and Disaster Recovery

With serverless high availability and disaster recovery become quite a bit easier as most of the common serverless services check these boxes automatically.

However, when you’re building serverless applications most of the time, only part of your system is serverless and some other part is augmented with containers or virtual machines.

In an ideal world, every service you incorporate into your application can match the scaling and performance of the last component, however that’s not a reality most of the time unless you invest into identifying where bottlenecks are taking place and address them.

In cases where a serverless component is handing off to a non-serverless component which may not be able to scale horizontally you will need to use a queue or a series of queues. AWS and other cloud providers offer services to make queuing easier.

Once you have queues in place you need to do load testing and see how your system responds when being hit with a large volume of requests.

When working with something like AWS SQS, you’re also going to have something called a DLQ or Dead Letter Queue. This is going to ensure that failing events are captured and able to be audited in the future. Where it makes sense you can also loop over your DLQ to re-execute those failed events, but that won’t make sense for a lot of systems as the event that failed might have been retried by the user and re-running the event could cause duplication, double charging, or some other undesired behavior.

However, DLQ’s are a great way to ensure some level of disaster recovery. Other parts of your system will also need to be designed with disaster recovery in mind.

For example, if you’re using MySQL or PostgreSQL on AWS you could opt to use something like Amazon Aurora which “features a distributed, fault-tolerant, self-healing storage system”.

Additional Reading

If you would like to learn more about serverless security and what serverless security means, checkout this whitepaper by Nuweba.

Have any useful links on serverless security you want added to this story? — message us

Conclusion

Securing serverless applications for PCI-DSS is in a lot of ways much easier than the virtual machine or container counterpart. This is due to less overhead and more fully managed alternatives. Lowering the total burden on the individual company to implement as a cloud provider like AWS will be solving this type of problem for thousands of companies.

The takeaways from this article should stretch past the PCI-DSS use case and simply be some security best practices that we’ve learned through building serverless applications for clients. Security is typically the first thing to be pushed by teams, but results in the biggest losses when data leaks or hacks take place. Which is a strong argument for hiring a serverless consulting company to simply help you avoid common pitfalls.

Looking for more help?

Serverless Guru offers a FREE 30 minute architecture review where serverless experts from the Serverless Guru team will ask you questions about your architecture and development/deployment processes. We’ve seen this be invaluable to those who have signed up.

Serverless Guru also offers serverless application development, serverless consulting, and serverless training to help you in every step of your journey. Hire us to help lay the foundation for your serverless applications, create a serverless migration plan, train your team on serverless best practices, or develop serverless applications shoulder to shoulder with your team.