Rightscale Webinar: PCI in Public Cloud
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,321 views
Over the past few years, PCI compliance in the public cloud has been a growing topic of concern and interest. Like us, you probably have heard assertions from both sides of the topic - some stating that one can be a PCI compliant merchant using public IaaS cloud, others stating that it is impossible. Join us in this webinar as our Director of Security and Compliance, Phil Cox, addresses these concerns and demonstrates how PCI compliance in the public IaaS cloud is indeed possible. In this webinar we’ll discuss: - Foundational principles and mindsets for PCI compliance - How to determine system/application scope and requirement applicability - Top-level PCI DSS (Data Security Standard) requirements and how to meet them in the public IaaS cloud This webinar is perfect for those who are searching for solid answers on security in the public cloud. Our goal with this webinar is to educate you with the information you need to have confidence and make the most of your public cloud, while dispelling any myths surrounding the topic of security and the public cloud.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Rightscale Webinar: PCI in Public Cloud
Ähnlich wie Rightscale Webinar: PCI in Public Cloud (20)
Mehr von RightScale
Mehr von RightScale (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Rightscale Webinar: PCI in Public Cloud
- 1. PCI in Public Cloud It can be done September 20, 2012 Watch the video of this webinar #rightscale
- 2. 2# Your Panel Today Presenting • Phil Cox, Director, Security and Compliance, RightScale • Brian Adler, Professional Services Architect, RightScale Q&A • Ryan Geyer, Cloud Solutions Engineer, RightScale • Greg Goodwin, Account Manager, RightScale Please use the “Questions” window to ask questions any time! #rightscale
- 3. 3# Agenda • Who I am and why am I speaking about this? • Brief introduction to the PCI-DSS • Working premise for my PCI environment • Core foundations to PCI in Public Cloud • Overview of the 12 Requirements and how they apply in the Public Cloud #rightscale
- 4. 4# Introduction • A follow on to the blog (http://blog.rightscale.com/pci) • Practical advice from years of experience as a QSA, now a merchant • Major contributor to PCI Virtualization supplement • Member of PCI Cloud SIG #rightscale
- 5. 5# PCI DSS Background • Card brands wanted consistency • Payment Card Industry Security Standards Council (PCI SSC) was created • Develop the Data Security Standard (DSS) • 12 Top Level Requirements • https://www.pcisecuritystandards.org/documents/PCI%20SSC%20- %20Getting%20Started%20with%20PCI%20DSS.pdf • Each of the card brands have “validation” requirements • 3rd party assessments (QSA) • Self Assessment Questionnaire #rightscale
- 6. 6# PCI DSS Summary Goals PCI DSS Requirements Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program 5. Use and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures 7. Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data 10. Track and monitor all access to network resources and cardholder data Regularly Monitor and Test Networks 11. Regularly test security systems and processes Maintain an Information Security Policy 12. Maintain a policy that addresses information security for all personnel #rightscale
- 7. 7# PCI & Public Cloud: What’s the big deal? • There is no clear guidance from the PCI SSC as to how the 12 Requirements and subsequent controls are to be met and validated in cloud environments • The Virtualization Guidance gave us some basis, but did not address everything • Many folks still unclear not only about “IF” but “HOW” when it comes to running a PCI compliant environment on a public cloud #rightscale
- 8. 8# Working Premise • Systems that Store, Process, or Transmit cardholder data are located in a public cloud provider • No other managed hosting or physical system in the design • The application is structured into 3 tiers: • Load balancer • App server • DB server. • Development and test are separate (i.e., isolated) and have NO cardholder data • The design only deals with production systems #rightscale
- 9. 9# Foundation • Public cloud provider • Assessor • Application design • Harden the systems #rightscale
- 10. 10# Public Cloud Provider • Is on “Approved Service Providers” list (i.e., completed level 1) *OR* has done a Level 2 assessment and can show you their validation results • Many providers go through the rigor of ensuring compliance internally, but not the cost of hiring an external QSA • Do not dismiss a potential partner because they are not on the list. If you are going to dismiss them, do it because they are not transparent. • Will sign a contract that states they must protect CHD in accordance with PCI DSS to the extent it applies to them #rightscale
- 11. 11# Assessor • About the Qualified Security Assessor (QSA), you need to find one … that knows cloud technology • A good default choice is the QSA who did the assessment for your provider • If you don’t want/need to use an external auditor, then …determine if you have the knowledge internally • You need to make sure you have the depth of knowledge on the PCI DSS, as you will likely get it wrong if they do not #rightscale
- 12. 12# Application Design • Your ability to achieve PCI compliance in the public cloud is primarily based on how much forethought you gave to the application in its design • Most providers, and all cloud-based operating systems can be PCI compliant. The same cannot be said for all applications • Ask the following questions: • What data am I storing? Why? Can I get away without it? • Do I know the communication flow of the application? Can I restrict communications to specific system roles? • Am I using well-known, public vetted cryptography standards? #rightscale
- 13. 13# Application Guidelines • Here are guidelines I have used to ensure an application is “securable” from a PCI perspective: 1. Do not store the Primary Account Number (PAN) if you do not need it. • Many payment processors have mechanisms for recurring billing or credits. Depending on your situation, it is highly likely that you do not need to store the PAN, thus making your life significantly easier from a PCI DSS compliance standpoint. 2. If you are going to store PAN, then the design of crypto mechanism and, more importantly, the key management of data in the DB, is critical • This is really not a “cloud” thing, and is dealt with in any PCI application that stores CHD. #rightscale
- 14. 14# Application Guidelines (cont.) 3. Terminate SSL/TLS at the load balancer and run all other traffic over the private interface/network • This assumes that the “private” interfaces have been designed to meet the definition of “non-public” as far as PCI DSS • This is the case with Amazon Web Services. Traffic between the private IP addresses can be considered a private network and not require encryption. This does not mean that you can’t or shouldn’t do it, just that you do not have to in order to meet PCI DSS requirements. 4. Validate all user input • While this is not a “cloud” issue, it is THE main intrusion vector Yep, that’s pretty much it: Protect it in transit/at rest (if needed) & Test for bad code • It is not rocket science, but most folks don’t do these right #rightscale
- 15. 15# Harden the Systems • Protect the system • Firewalls (remember ingress and egress) • Change defaults • Install patches • Watch the system for odd behavior or changes • Shout out to CloudPassage • Manage the firewall rules and separation of duty that PCI DSS requires, and will make achieving compliance much easier. • I recommend using a public cloud management solution. Trying to do this by hand is error-prone. #rightscale
- 16. 16# Determining Scope • I use the Open PCI Scoping Toolkit as the framework • It is the work of 50+ experts in the PCI field • It is NOT endorsed by the PCI SSC, but they have provided no alternative to the tough questions it answers • Get it at http://itrevolution.com/pci-scoping-toolkit/ #rightscale
- 17. 17# Decision Tree #rightscale
- 18. PCI DSS Requirements #rightscale
- 19. 19# PCI and Cloud Snapshot • Those that need special consideration because of cloud: 1, 3, 9, 10, 11, 12 (orange) • Those that are more about HOW than WHAT: 2, 4, 5, 6, 7, 8 (blue) #rightscale
- 20. 20# Cloud Provider Responsibility • Everything up to and including the hypervisor • All physical aspects of the remote systems #rightscale
- 21. 21# Requirement 1: Firewalls • Design the application and communications flows so they can be secured • The state of networking features in cloud have an affect on how you provide isolation for scoping • Review/audit regularly to make sure design and implementations have not changed • One nice aspect of the cloud is that since automation is part of the DNA, automation of these reviews is easier #rightscale
- 22. 22# Requirement 2: Defaults • Make sure to change the vendor supplied defaults • RightScale ServerTemplates™ are a great way to enforce this, as well as provide version control of configurations • The cloud actually helps you: Have to plan • There is not “throw in the CD, plug in the cable, and leave it” • Cloud should give you a leg up in this area, as this is part of Cloud DNA so to speak #rightscale
- 23. 23# Requirement 3: Protect CHD • Gets down to: • Do not store what you don’t need • Good crypto selection • Proper key management • For non-DB-based encryption, use of a third party like TrendMicro SecureCloud (or similar) is a big help here • Note: Cloud really is not an issue here, as you have many of the same concerns in a managed hosting environment. The main difference is between owned or third-party infrastructure. #rightscale
- 24. 24# Stored PAN Tangent • Assume you store PAN in the DB • Not tokenized, truncated, or hashed • For most of us, you need to mask on display • Per Requirement 3 if you store CHD, then you must encrypt • Does your DB support it? If not, then have to do in App • Use encrypted filesystem on block storage in addition • Inject keys at instance launch • Management of encryption keys is the big issue • Rotation – You need to plan on how to do this! • Storage – In memory is best, restricted filesystem is next best #rightscale
- 25. 25# Requirement 4: Encrypt transmission • No huge difference between cloud or hosted here • Biggest item is determining private vs. public networks • SSL/TLS is the defacto way to do this #rightscale
- 26. 26# Requirement 5: AV and Malware • Not much specific to a “cloud” deployment • Servers come and go more frequently, so you need to make sure the AV solution is operating correctly • If I had Windows systems for servers, I’d be using RightScale ServerTemplates to make sure things were configured correctly • Nice aspect of the cloud is that since automation is part of the DNA, automation of this should actually make it easier to meet the requirements #rightscale
- 27. 27# Requirement 6: Development & System Admin • The “what” (securing systems) is not really a “cloud” specific problem, but the “how” is • Need to deploy hardened systems • RightScale ServerTemplates and built in versioning makes it easy and provides change tracking. You can choose how you want to do it, just do it • Nice aspect of the cloud is that since automation is part of the DNA, automation of these should actually make it easier to meet the requirements #rightscale
- 28. 28# Requirements 7 & 8: Restrict Access & Users • Again, not the “What to do” that is the issue, but “How to do it” • Make sure you enforce it on EVERY system • Role-Based Access Control (RBAC) and ServerTemplate features of RightScale and a strict provisioning policy to get this done. You can choose any method that works • I use a combination of RightScale, policies, and regular audits. You can choose any method that works • Really no different than a hosted environment #rightscale
- 29. 29# Requirement 9: Physical • You need to worry about user systems and any hard copy • Really no different than a hosted environment #rightscale
- 30. 30# Requirement 10: Logging & Tracking • Basically need host-based tools • The lack of transparency into some of the devices you don’t have access to (e.g., hypervisor logs) needs to be taken into account • I use RightScale to configure systems and send local system and application logs to central log server • You can choose any method that works for you • Use of a 3rd party is a BIG WIN here #rightscale
- 31. 31# Requirement 11: Testing • Coordination with the CSP when doing testing may be something that is new and require modification of your process • “Internal” testing becomes a bit tricky • I recommend: • Automated tools - Continuous • Internal experts – Monthly or more • 3rd party testing – Annually • While you can use a Web App Firewall (WAF), I prefer testing • Use both if you can #rightscale
- 32. 32# Requirement 12: Governance • The policies need to exist with or without the cloud. The biggest difference here is ensuring appropriate language is included in contracts • Biggest issues I run into: • Ensure that if you share CHD with others, contracts state they must protect CHD in accordance with PCI DSS • Have an incident response plan and make sure it works! #rightscale
- 33. 33# Contact RightScale Conclusion (866) 720-0208 sales@rightscale.com • You CAN be PCI-compliant in a public cloud www.rightscale.com • You need validation of your partners: • Onto the list of PCI approved Service Providers *OR* • Be transparent and willing to work with you to document their compliance adherence • Management of cloud systems should be better than traditional • You get lazy with what you know • Tools can help, and IMO, RightScale is best of breed tool for this #rightscale
Hinweis der Redaktion
- Just touch on these, we’ll cover them in the following slides
- I have been doing security for 20+ years. But the reason I FEEL QUALIFEID TO speak on this issue is that I have spent the last 6 years arm-pit deep in PCI as a QSA for the first 4 ½. Then as a Merchant for the last 1 ½ year or so.I was on the PCI Virtualization and Scoping Special Interest Groups, and am currently part of the PCI Cloud SIG.{PAUSE for new thought flow}As a QSA and SIG member, I developed a detailed understanding of the PCI DSS as it is written, as well as the knowing what the original intent was: Protect Cardholder DataAs a Merchant, I know what it means to comply with the PCI-DSS, and in this context, comply with PCI-DSS in a PURELY PUBLIC CLOUD environment
- I want to cover some basics for those that may not be familiar with the Payment Card Industry Data Security Standard, form now on referred to as the “PCI DSS”Briefly comment on each of the bullet points, NEXT SLIDE COVERS THE 12 REQUIREMENTS, SO DON’T DO THAT HEREDO state: PCI-DSS applies ONLY if the Primary Account Number (PAN) is STORED, PROCESSED, or TRANSMITTED. From the PCI-DSS: {READ IT VERBATIM}The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. HOWEVER, you should have adequate “governance” for any payment services you use: You will need the right language in contracts and monitoring of those who process on your behalf. Not PCI driven, but reasonable!VALIDAITON – there is a difference between validation and compliance, and MANY FOLKS GET THESE CONFUSEDEveryone has to be 100% compliant at all timesDepending on the Card Brand you accept, your role in the payment flow (Merchant or Service provider), the number of transactions and their type (ecomerce, MailOrder-TelephoneOrder), you will fall into 1 of 4 validation levels: 1,2,3,4Basically 1’s have to have external assessors do the validation. New Internal Security Assessors (ISA) can fulfill the role of QSAThen 2-4 get to do SELF-ASSESSMENTS, which is then split out into different Self Assessment Questionnaires (SAQ D-A)THE DETAILS OF THIS ARE BEYOND THE SCOPE OF THIS, suffice to say: ONE COMPLIANCE LEVEL MANY VALIDATION LEVELS
- The 12 high level requirements are listed here {READ THEM, BUT DON’T COMMENT – BECAUSE WE’LL COVER THEM MORE IN DEPTH LATER}THE 12 HIGH LEVEL requirements are grouped logically into the “GOALS” of the PCI DSS – Ultimate goal is to make sure cards are not compromised and used for fraud
- There are almost 500 folks registered for this webinar, and there is a single reason: THERE IS NO CLEAR GUIDANCE ON DOING THIS IN CLOUD (be it public or private)NOTE: The Cloud SIG is working on it! But for now, we (the community of QSAs, Merchants, and Service Providers) are left to interpret based on the information that is out there. Primarily the Virtualization Supplement, and the “Navigating the PCI-DSS” document.Let me state here that I eagerly await the formal guidance coming from the PCI Cloud SIG, but until then, I will champion this cause.
- Now that we have a foundation for the PCI-DSS, lets talk about 2 key assumptions/prerequisites/qualifications/etc.First, that I am not hiding anything in a co-lo or on-premise system. It is ALL in the Public Cloud. Now that I said that, the end user systems that may be used to access the actual systems are obviously not part of the cloud, but all the “server infrastructure” is.Second, is that there is no need to have your dev and test systems as part of the scope. Isolate them, and don’t user real card numbers! REMEMBER NO PAN NO PCI-DSS
- With that basic premise, we’ll cover 4 KEY FOUNDATIONAL items that you need to deal with if you want to be able to do this right.These range form conceptual items to actual implementation thoughts, so I encourage you to “think” about the objective and maybe not the specific words I say. Understanding the concepts are much more important that the specific detail. If you get the concept, the detail will follow.With that, let’s go …
- The GIST of this page is that part of your compliance relies on the compliance of your provider, and they have 2 ways to “prove” that: Be on the list, or be willing to prove it to you at a level you are satisfied with.Note, that in the letter of the law, you would need to perform due diligence on those listed as well. MEANING, JUST BECAUSE THEY ARE LISTED DOES NOT GIVE YOU A GET OUT OF JAIL FRE CARD IF YOU ARE COMPROMISED.You must feel comfortable with your providers security. In reality, the level 2 who is willing to work with you may be a better fit. But it is up to you, just remember, they do NOT HAVE TO BE ON THE LIST!
- Key here is an assessor that knows cloud. There are WAY TOO MANY WHO DO NOT!
- Your DESING IS KEY … if you don’t design it right, you are hosed. But that goes for any environment, not just cloud.
- Note on “Not storing the PAN”, use one of these:One-way hashes based on strong cryptography (hash must be of the entire PAN) Truncation (hashing cannot be used to replace the truncated segment of PAN)Index tokens and pads (pads must be securely stored)Strong cryptography with associated key-management So you have options to encryption. As a matter of fact, encryption is the hardest to do correctly.It has been my experience that MOST folks who keep the PAN do NOT need it. THIS IS THE MOST CRITICAL DECISION YOU WILL MAKE, AND IT HAS A DIRECT AFFECT ON THE EASE OF PCI COMPLIANCE
- This is really about deploying secure systems. From where I stand, it should be no different than any other system you deploy: It should be built secure.The one advantage of Cloud is meeting the “1 systems 1 service” rule. Given the characteristics of Cloud, doing the 1:1 is much simpler.
- This is more of a HELPFUL HINT, AND IS NOT CLOUD SPECIFIC. This has been one of the most frustrating parts of PCI compliance. Well, for me it is now much easier.
- Just a graphic
- A snapshotOrange: In general these have special considerations for CloudBlue: In general, Cloud does not alter what you do significantlyWe’ll hit these more in the next sldies{IF SHORT ON TIME, MAKE THESE BRIEF AND REFERENCE THE BLOG AND ASSOCIATED PDF}
- BIGGEST issue here is the maturity of the networking, and the fact that you need to use host based firewalls on all instances. It is just a different way of doing things than most are acustom. It is however that way that Cloud works.NOTE: If you use a Virtual Private Cloud or something like that, this is a bit different. Remember everything I am talking about is Public.
- This is “Change the things a hacker read in an install or setup guide to break into your systems”
- If you use file- or column-level database encryption, then you are golden as long as it is based on public crypto and has great key managementIf you used Disk level encryption, the encryption method cannot have: A direct association with the operating system, orDecryption keys that are associated with user accounts So TrendMicro SecureCloud is a solution that you can use.
- 3rd party:CloudPassageSPLUNKTrendMicro Deep SecuritySumo LogicAny SIEM