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

3,755 views
3,426 views

Published on

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.

Published in: Technology, Economy & Finance
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,755
On SlideShare
0
From Embeds
0
Number of Embeds
241
Actions
Shares
0
Downloads
99
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

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

  1. 1. 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
  2. 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. 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. 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. 5. What is PCI and why do I care? Friday, November 15, 13
  6. 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. 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. 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. 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. 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. 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. 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. 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
  14. 14. We need a host Friday, November 15, 13
  15. 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
  16. 16. Our options vs Friday, November 15, 13 vs
  17. 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
  18. 18. Traditional hosting •Give it some time and this is what will happen •Audit that Friday, November 15, 13
  19. 19. Traditional hosting •Give it some time and this is what will happen •Audit that Friday, November 15, 13
  20. 20. PCI Compliant “Clouds” Pro •Local company Friday, November 15, 13 Con •Expensive, was quoted 4 times AWS •2-3 days to turn up a new instance
  21. 21. PCI Compliant “Clouds” Friday, November 15, 13
  22. 22. PCI Compliant “Clouds” ElasticSearch Cassandra MogileFS Memcached Queue service Nagios Relational Load Database Balancer Friday, November 15, 13 No hosted services
  23. 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. 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
  25. 25. We designed for PCI Friday, November 15, 13
  26. 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
  27. 27. Service Oriented Architecture *simplified Friday, November 15, 13
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  39. 39. Meeting the requirements on AWS Friday, November 15, 13
  40. 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. 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. 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. 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. 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. 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. 46. If you care about it or are audited on it, AUTOMATE IT Friday, November 15, 13
  47. 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. 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. 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
  50. 50. Think hard about handling card data Friday, November 15, 13
  51. 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. 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

×