navigating pci compliance in the cloud (sec206) | aws re:invent 2013

© 2013 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

Jesse Angell

November 14, 2013

Navigating PCI DSS Compliance in the Cloud

Friday, November 15, 13

Who am I?• Jesse Angell

–CTO of PaymentSpring–Background in both IT operations and software development–When I’m not building software you’ll find me working on my

experimental airplane

@jesseangell

[email protected]


mailto:[email protected]

mailto:[email protected]

–Level 1 PCI compliant gateway–We make it easier for our clients to accept credit card transactions while

greatly reducing their PCI compliance without sacrificing their customer’s user experience.

–As a payment gateway storing credit card numbers, we bet our business on our security.

–Built, certified, and launched a level 1 compliant gateway in a year with a small team.


• Why we chose AWS• How we architected our systems• How AWS makes PCI compliance easier

What is this about?This is the real story of how PaymentSpring built a level 1 PCI compliant gateway entirely on AWS.


What is PCI and why do I care?


What is the PCI DSS?• The PCI DSS (data security standard) is a publicly

available document setting forth the requirements you must meet to handle credit card data.

• The current version of the DSS, is not very cloud oriented.


Levels of PCI• Level 1: over 6 million transactions per year• Level 2: 1 to 6 million transactions per year• Level 3: 20,000 to 1 million transactions per year• Level 4: Less than 20,000 transactions per year

Compliance becomes more difficult and costly with each level


Does it apply to me?

If you are a merchant or a service provider to a merchant that processes, stores, or transmits credit card data PCI applies to you.If your customers do the above through your systems you must be compliant.If you are asking yourself this question, PCI likely applies to you.

If you are asking yourself this question. It’s likely going to apply to you


Understanding PCI on AWS• All AWS services can be PCI compliant. The more

you utilize their services (such as Amazon RDS, Amazon DynamoDB) the less infrastructure you will have to worry about.

• With Amazon EC2, you are responsible for everything from the hypervisor and up. This includes patching the operating system.


Compliance is not automatic• You must understand all PCI requirements and

know how you are complying with it. Some requirements are fully handled by Amazon, others partially, and some fully your responsibility.

• Many requirements, such as the physical ones, are completely handled by Amazon.


Finding the right QSA• Level 1 compliance requires an annual RoC (report

on compliance) that must be created by a QSA (qualified security assessor)

• Talk to the QSA about AWS before engaging with them. You don’t want to pay to educate them.

• If you cannot get them to understand how security groups work, run, and find another!


Where do I begin?

1.Download the PCI DSS2.Write policy and create processes to address each

requirement3.Audit that you are operating per your policy.


Where do I begin?

1.Download the PCI DSS2.Write policy and create processes to address each

requirement3.Audit that you are operating per your policy.

0. Can I get out of this?


We need a host


Requirements• High-availability• As low cost as possible during initial build• PCI compliant environment• Real security and real scalability• Like any startup we need to spend our money

carefully


Our options

vs vs


Traditional hosting

•Our area of expertise•Absolute control

•No local PCI compliant colo•Physical audit•Waste of our talent•Upfront cost

Pro Con


Traditional hosting

•Give it some time and this is what will happen•Audit that


PCI Compliant “Clouds”

•Local company •Expensive, was quoted 4 times AWS•2-3 days to turn up a new instance

Pro Con



Relational Database

Load Balancer

Memcached

ElasticSearchCassandra

MogileFS

NagiosQueue service

No hosted services


AWS

•End-to-End PCI•Lowest cost PCI compliant cloud•Hosted services save us tons of time and shrinks our PCI environment

•No experience on our team•We were worried about instance failures•Small fish in big ocean

Pro Con


AWS•Our team learned quickly and we were still able to build faster than we could have in colo•Instance reliability has been better than our IBM and Supermicro servers•We receive better service from our AWS account manager than our local colo

My fears were unfounded


We designed for PCI


Our strategy• Thoroughly reviewed the entire PCI DSS before we

wrote a single line of code.• Throughout your development cycle cross-check

PCI requirements. Avoid expensive mistakes. Involve a QSA at every major decision.

• Reach beyond PCI requirements for security. It is a baseline not your ultimate goal.


Service Oriented Architecture

*simplified


Other SoA Perks• SoA is the answer for mitigating PCI. We isolated

the paths where card holder data flows into small services that are easily audited.

• Each service should have their own security group• The less coupled things are the more granular your

security can become.• Our services are designed not to trust each other.


Our service philosophy• Services are their own fully isolated application with

an API.• API calls between services are fully authenticated.

Do not build god keys, admin keys, or backdoors between services.

• Any one of our services can be safely exposed to the internet and be useful by itself.


Our service philosophy• 1 service per EC2 instance• Services have their own database instances

(Amazon RDS). • Security groups are powerful. Use them. The more

services you have, the more specific you can make your security groups. Be paranoid.


Some more rules...• We never make changes to production instances• If a change needs to be made we build new

instances and terminate the old ones.• Our production instances can ONLY access the

network resources they need to do their job. They do not have internet access. We do not log into them.

• We accomplish the above by moving instances between “stages” as they are built.


Stage 0: Distribution AMI

1.Launch the upstream distribution AMI.2.Apply system updates3.Apply Puppet manifests for that role.4.Create AMI5. Terminate instance

(The birth of a production instance)


Stage 1: PaymentSpring Base AMI1.Launch our latest stage 1 AMI for the particular

service.2.Deploy code to instance and run tests3. Create AMI4.Terminate instance

(Add the application code)


Stage 2: Production-ready AMI1. Launch latest stage-2 AMI for service we’re

deploying.2.Add to Elastic Load Balancing

(Locked down and ready for production)


Security changes with each stage

Stage 0: Distribution AMI

•Has network access to repositories for installing updates•Has not yet been hardened



Stage 1: PaymentSpring Base AMI

•Has network access to download our code but no longer can talk to the package repositories•File integrity monitoring is now enabled on everything except the code



Stage 2: PaymentSpring Production

•Has network access to database servers and load balancers•File integrity monitoring is now enabled on the code as well•Extremely strict file integrity and intrusion detection monitoring.


You must be consistent to be secure• All it takes is one misconfigured machine to lose card

data.• Eliminate the human otherwise you will never be

consistent• Reconfigure and replace instances with new ones

from scratch instead of modifying them.• Use configuration management (we’re a puppet shop)


Meeting the requirements on AWS


Firewalls (security groups)• Firewall rules must be audited

–The AWS API allows you to audit every security group in seconds

• Firewall firmware must be updated–Not applicable on AWS

• Networks must be properly segmented–Segmentation can exist between instances inside the same subnet based on roles (services)


Networking (VPC)• Switches and router firmware must be updated

–Not applicable on AWS• Must not expose private ip addresses

–VPCs allow you to create private subnets in the ip range of your choice and use NAT to isolate your instances from the public internet


Intrusion detection and file integrity• Intrusion detection must be on every server

– Instance stages make your IDS effective and not annoying

• File integrity monitoring must be enabled–Instance stages make your file integrity effective and not annoying

• Alerts must be monitored and responded to–We don’t touch instances in production which all but eliminates false alerts.


Anti-Virus

• Must run anti-virus (Yes, even on Linux servers).–AWS allows you to scale up or reconfigure your environment so that the scans don’t impact service response


Key management• It’s a complicated problem to solve.

–AWS CloudHSM is an Amazon service that allows you to easily protect and manage your keys

Pro tip: Challenge your staff to imagine ways that a hacker could access your keys at rest, in memory, etc. If they can think of a way to decrypt a card number on their own your system is broken. Fix it.Remember that your application can decrypt data, a single flaw in it’s logic could defeat all of your key management strategies.


Other tips - Protect your application• Your application is what is exposed to the internet.

It’s the easiest vector for an attacker. You must constantly evaluate how well you’re protecting it.

• Code review, code review, code review. • Watch out for the libraries you use in your

application. This is often missed and there can be giant holes in them (injection issue in an ORM library, for example).


If you care about it or are audited on it, AUTOMATE IT


Automate everything• AWS provides an API for everything. An API means

you can automate it and automating it means you can eliminate the human error.

• In traditional data centers you pile on change after change and never truly know how things are configured. Your systems and your security rot.


Real security, smoother audits• With AWS you can verify your

infrastructure is for sure 100% configured as you intend.

• In traditional data centers there is no way to do that

• Source controlled configuration of your platform provides security you cannot get elsewhere


Think hard about handling card data


A credit card number is a liability• Ensure the benefit of touching the card number is

greater than the liability• Go beyond the DSS, be paranoid, ensure data is

always encrypted -- even in memory.• First and foremost, evaluate whether or not you can

eliminate the reasons that compliance is necessary.


Please give us your feedback on this presentation

As a thank you, we will select prize winners daily for completed surveys!

SEC206 Thank You

@[email protected]


navigating pci compliance in the cloud (sec206) | aws re:invent 2013

Technology

pci requirements

pci compliant gateway

pci environment

pci compliant cloudsfriday

levels of pci level

pci compliance easierfriday

navigating pci dss compliance

credit card data pci