People assume that implementing the Payment Card Industry Data Security Standard (PCI DSS) on AWS is more difficult than in a traditional data center, but that's simply not true. Come learn how PaymentSpring implemented a PCI DSS level 1 compliant gateway running entirely on AWS. Learn how they designed the system to make PCI DSS validation easier, what they could depend on AWS to provide, and what they still had to take care of. The session covers some of the things PaymentSpring did to significantly reduce costs and increase the overall security of the system. But most importantly, learn why it's easier to maintain compliance over time. Jesse Angell, CTO of PaymentSpring, shares his first-hand experiences with implementing PCI DSS on AWS at his organization.
2. 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
Friday, November 15, 13
3. – 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.
Friday, November 15, 13
4. 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
Friday, November 15, 13
5. What is PCI and why do I care?
Friday, November 15, 13
6. 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.
Friday, November 15, 13
7. 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
Friday, November 15, 13
8. 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.
Friday, November 15, 13
9. 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.
Friday, November 15, 13
10. 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.
Friday, November 15, 13
11. 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!
Friday, November 15, 13
12. 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.
Friday, November 15, 13
13. 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.
Friday, November 15, 13
15. 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
Friday, November 15, 13
17. Traditional hosting
Pro
Con
•Our area of
•No local PCI
expertise
•Absolute
control
Friday, November 15, 13
compliant colo
•Physical audit
•Waste of our
talent
•Upfront cost
23. AWS
Pro
•End-to-End PCI
•Lowest cost PCI
compliant cloud
•Hosted services
save us tons of
time and shrinks
our PCI
environment
Friday, November 15, 13
Con
•No experience
on our team
•We were
worried about
instance
failures
•Small fish in
big ocean
24. 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
Friday, November 15, 13
26. 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.
Friday, November 15, 13
28. 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.
Friday, November 15, 13
29. 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.
Friday, November 15, 13
30. 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.
Friday, November 15, 13
31. 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.
Friday, November 15, 13
32. 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)
Friday, November 15, 13
33. 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)
Friday, November 15, 13
34. 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)
Friday, November 15, 13
35. Security changes with each stage
Stage 0: Distribution AMI
•Has network access to repositories for
installing updates
•Has not yet been hardened
Friday, November 15, 13
36. Security changes with each stage
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
Friday, November 15, 13
37. Security changes with each stage
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.
Friday, November 15, 13
38. 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)
Friday, November 15, 13
40. 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)
Friday, November 15, 13
41. 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
Friday, November 15, 13
42. 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.
Friday, November 15, 13
43. 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
Friday, November 15, 13
44. 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.
Friday, November 15, 13
45. 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).
Friday, November 15, 13
46. If you care about it or are audited
on it, AUTOMATE IT
Friday, November 15, 13
47. 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.
Friday, November 15, 13
48. 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
Friday, November 15, 13
49. 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
Friday, November 15, 13
51. 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.
Friday, November 15, 13
52. 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
Friday, November 15, 13