Navigating PCI Compliance in the Cloud (SEC206) | AWS re:Invent 2013

Navigating PCI DSS Compliance in the Cloud
Jesse Angell
November 14, 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.
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
jesse.angell@paymentspring.com


– 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.


What is this about?
This is the real story of how PaymentSpring built a
level 1 PCI compliant gateway entirely on AWS.
• Why we chose AWS
• How we architected our systems
• How AWS makes PCI compliance easier


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 asking yourself this question. It’s
likely going to apply to you

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.


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 DSS
2.Write policy and create processes to address each
requirement
3.Audit that you are operating per your policy.


Where do I begin?
0. Can I get out of this?
1.Download the PCI DSS
2.Write policy and create processes to address each
requirement
3.Audit that you are operating per your policy.


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
Pro

Con

•Our area of

•No local PCI

expertise
•Absolute
control


compliant colo
•Physical audit
•Waste of our
talent
•Upfront cost

Traditional hosting
•Give it some

time and this is
what will happen
•Audit that


PCI Compliant “Clouds”
Pro

•Local company


Con

•Expensive,

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

ElasticSearch
Cassandra
MogileFS

Memcached
Queue
service
Nagios
Relational
Load
Database
Balancer


No hosted
services

AWS
Pro

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

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

AWS

My fears were unfounded

•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

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 updates
3.Apply Puppet manifests for that role.
4.Create AMI
5. Terminate instance
(The birth of a production instance)


Stage 1: PaymentSpring Base AMI
1.Launch our latest stage 1 AMI for the particular
service.
2.Deploy code to instance and run tests
3. Create AMI
4.Terminate instance
(Add the application code)


Stage 2: Production-ready AMI
1. 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

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

Thank You

@jesseangell

jesse.angell@paymentspring.com

Navigating PCI Compliance in the Cloud (SEC206) | AWS re:Invent 2013

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie Navigating PCI Compliance in the Cloud (SEC206) | AWS re:Invent 2013

Ähnlich wie Navigating PCI Compliance in the Cloud (SEC206) | AWS re:Invent 2013 (20)

Mehr von Amazon Web Services

Mehr von Amazon Web Services (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Navigating PCI Compliance in the Cloud (SEC206) | AWS re:Invent 2013