PCI DSS Cloud Computing Guidelines

Transcription

1 Standard: PCI Data Security Standard (PCI DSS) Versin: 2.0 Date: February 2013 Authr: Clud Special Interest Grup PCI Security Standards Cuncil Infrmatin Supplement: PCI DSS Clud Cmputing Guidelines

2 Table f Cntents 1 Executive Summary Intended Use Audience Terminlgy Clud Overview Deplyment and Service Mdels Clud Prvider / Clud Custmer Relatinships Understanding Rles and Respnsibilities Rles and Respnsibilities fr Different Deplyments Mdels Respnsibilities fr Different Service Mdels Nested Service-Prvider Relatinships PCI DSS Cnsideratins Understanding PCI DSS Respnsibilities PCI DSS Respnsibilities fr Different Service Mdels Security as a Service (SecaaS) Segmentatin Cnsideratins Scping Cnsideratins PCI DSS Cmpliance Challenges What des I am PCI cmpliant mean? Verifying Scpe f Validated Services and Cmpnents Verifying PCI DSS Cntrls Managed by the Clud Prvider Additinal Security Cnsideratins Gvernance, Risk and Cmpliance Facilities and Physical Security Data svereignty and Legal cnsideratins Data Security Cnsideratins Technical Security Cnsideratins Incident Respnse and Investigatin Cnclusin Appendix A: Sample PCI DSS Respnsibilities fr Different Service Mdels Appendix B: Sample Inventry Appendix C: Sample PCI DSS Respnsibility Matrix Appendix D: PCI DSS Implementatin Cnsideratins Acknwledgements References Abut the PCI Security Standards Cuncil The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace i i

3 1 Executive Summary Clud cmputing is a frm f distributed cmputing that is yet t be standardized 1. There are a number f factrs t be cnsidered when migrating t clud services, and rganizatins need t clearly understand their needs befre they can determine if and hw they will be met by a particular slutin r prvider. As clud cmputing is still an evlving technlgy, evaluatins f risks and benefits may change as the technlgy becmes mre established and its implicatins becme better understd. Clud security is a shared respnsibility between the clud service prvider (CSP) and its clients. If payment card data is stred, prcessed r transmitted in a clud envirnment, PCI DSS will apply t that envirnment, and will typically invlve validatin f bth the CSP s infrastructure and the client s usage f that envirnment. The allcatin f respnsibility between client and prvider fr managing security cntrls des nt exempt a client frm the respnsibly f ensuring that their cardhlder data is prperly secured accrding t applicable PCI DSS requirements. It s imprtant t nte that all clud services are nt created equal. Clear plicies and prcedures shuld be agreed between client and clud prvider fr all security requirements, and respnsibilities fr peratin, management and reprting shuld be clearly defined and understd fr each requirement. 1.1 Intended Use This dcument prvides guidance n the use f clud technlgies and cnsideratins fr maintaining PCI DSS cntrls in clud envirnments. This guidance builds n that prvided in the PCI DSS Virtualizatin Guidelines and is intended fr rganizatins using, r thinking f using, prviding, r assessing clud technlgies as part f a cardhlder data envirnment (CDE). This dcument is structured as fllws: Executive Summary Includes a brief summary f sme key pints and prvides cntext fr the remainder f the dcument. Clud Overview Describes the deplyment and service mdels discussed thrughut this dcument. Clud Prvider/ Clud Custmer Relatinships Discusses hw rles and respnsibilities may differ acrss different clud service and deplyment mdels PCI DSS Cnsideratins Prvides guidance and examples t help determine respnsibilities fr individual PCI DSS requirements, and includes segmentatin and scping cnsideratins. PCI DSS Cmpliance Challenges Describes sme f the challenges assciated with validating PCI DSS cmpliance in a clud envirnment. Additinal Security Cnsideratins Explres a number f business and technical security cnsideratins fr the use f clud technlgies. Cnclusin Presents recmmendatins fr starting discussins abut clud services. 1 NIST Guidelines n Security and Privacy in Public Clud Cmputing (SP SP ) The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 1 1

4 The fllwing appendices are included t prvide additinal guidance: Appendix A: PCI DSS Respnsibilities fr different Service Mdels Presents additinal cnsideratins t help determine PCI DSS respnsibilities acrss different clud service mdels. Appendix B: Sample Inventry Presents a sample system inventry fr clud cmputing envirnments. Appendix C: PCI DSS Respnsibility Matrix Presents a sample matrix fr dcumenting hw PCI DSS respnsibilities are assigned between clud prvider and client. Appendix D: PCI DSS Implementatin Cnsideratins Suggests a starting set f questins that may help in determining hw PCI DSS requirements can be met in a particular clud envirnment. This dcument is intended t prvide an initial pint f discussin fr clud prviders and clients, and des nt delve int specific technical cnfiguratins. This dcument des nt endrse the use f any specific technlgies, prducts, r services. The infrmatin in this dcument is intended as supplemental guidance and des nt supersede, replace r extend PCI DSS requirements. Fr the purpses f this dcument, all references made are t PCI DSS versin Audience The infrmatin in this dcument is intended fr merchants, service prviders, assessrs and ther entities lking fr guidance n the use f clud cmputing in the cntext f PCI DSS. Fr example: Merchants The security and PCI DSS cnsideratins are applicable t all types f clud envirnments, and may be useful t merchants managing their wn clud infrastructure as well as thse lking t engage with a third party. Guidance fr wrking with third-party clud prviders and PCI DSS cmpliance challenges may als be useful. Clud service prviders The security and PCI DSS cnsideratins may prvide useful infrmatin fr CSPs t assist their understanding f the PCI DSS requirements, and may als help CSPs t better understand their clients PCI DSS needs. Guidance n CSP/client relatinships and PCI DSS cmpliance challenges may als be useful fr prviders. Assessrs The security and PCI DSS cnsideratins may help assessrs t understand what they might need t knw abut an envirnment in rder t be able t determine whether a PCI DSS requirement has been met. 1.3 Terminlgy The fllwing terms are used thrughut this dcument: CSP Clud Service Prvider. The CSP, r clud prvider, is the entity prviding the clud service. The CSP acquires and manages the infrastructure required fr prviding the services, runs the clud sftware that prvides the services, and delivers the clud services thrugh netwrk access. 2 Clud custmer r client The entity subscribing t a service prvided by a clud prvider. May include merchants, service prviders, payment prcessrs, and ther entities utilizing clud services. May als be referred t as a clud tenant. 2 NIST Clud Cmputing Reference Architecture (SP ) The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 2 2

5 2 Clud Overview Clud cmputing prvides a mdel fr enabling n-demand netwrk access t a shared pl f cmputing resurces (fr example: netwrks, servers, strage, applicatins, and services) that can be rapidly prvisined and released with minimal management effrt r clud prvider interactin. 3 Clud cmputing can be used t prvide clients with access t the latest technlgies withut a cstly investment in hardware and sftware. Due t the ecnmies f scale assciated with the delivery f clud services, CSPs can ften prvide access t a greater range f technlgies and security resurces than the client might therwise have access t. rganizatins withut a depth f technically-skilled persnnel may als wish t leverage the skills and knwledge prvided by CSP persnnel t securely manage their clud peratins. Clud cmputing therefre hlds significant ptential t help rganizatins reduce IT cmplexity and csts, while increasing agility. Clud cmputing is als seen as a means t accmmdate business requirements fr high availability and redundancy, including business cntinuity and disaster recvery. 2.1 Deplyment and Service Mdels Deplyment mdels are defined t distinguish between different mdels f wnership and distributin f the resurces used t deliver clud services t different custmers. Clud envirnments may be deplyed ver a private infrastructure, public infrastructure, r a cmbinatin f bth. The mst cmmn deplyment mdels, as defined by NIST, include: Private clud The clud infrastructure is perated slely fr a single rganizatin (client). It may be managed by the rganizatin itself r a third-party prvider, and may be n-premise r ff-premise. Hwever, it must be slely dedicated fr the use f ne entity. Cmmunity clud The clud infrastructure is shared by several rganizatins and supprts a specific cmmunity with shared requirements r cncerns (fr example, business mdel, security requirements, plicy, r cmpliance cnsideratins). It may be managed by the rganizatins r a third party, and may be n-premise r ff-premise. Public clud The clud infrastructure is made available t the general public r a large industry grup and is wned by an rganizatin selling clud services. Public clud infrastructure exists n the premises f the clud prvider. Hybrid clud The clud infrastructure is a cmpsitin f tw r mre cluds (private, cmmunity, r public) that remain unique entities but are bund tgether by technlgy t enable prtability. Hybrid cluds are ften used fr redundancy r lad-balancing purpses fr example, applicatins within a private clud culd be cnfigured t utilize cmputing resurces frm a public clud as needed during peak capacity times (smetimes called clud-bursting ). With respect t understanding rles and respnsibilities, this paper is largely fcused n public clud scenaris. Hwever, many f the cncepts discussed remain applicable t the ther deplyment mdels. 3 The NIST Definitin f Clud Cmputing (SP ) The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 3 3

6 Service mdels identify different cntrl ptins fr the clud custmer and clud prvider. Fr example, SaaS custmers simply use the applicatins and services prvided by the CSP, where IaaS custmers maintain cntrl f their wn envirnment hsted n the CSP s underlying infrastructure. The three mst cmmnly used service mdels are described as fllws 4 : Sftware as a Service (SaaS) Capability fr clients t use the prvider s applicatins running n a clud infrastructure. The applicatins are accessible frm varius client devices thrugh either a thin client interface, such as a web brwser, r a prgram interface. Platfrm as a Service (PaaS) Capability fr clients t deply their applicatins (created r acquired) nt the clud infrastructure, using prgramming languages, libraries, services, and tls supprted by the prvider. Infrastructure as a Service (IaaS) Capability fr clients t utilize the prvider s prcessing, strage, netwrks, and ther fundamental cmputing resurces t deply and run perating systems, applicatins and ther sftware n a clud infrastructure. The main difference between service levels relates t hw cntrl is shared between client and CSP, which in turn impacts the level f respnsibility fr bth parties. It shuld be nted that, ther than in a truly private clud (n-premise) scenari, the client rarely has any cntrl ver hardware, and it is the degree t which virtual cmpnents, applicatins and sftware are managed by the different parties that differentiates the service mdels. As a general rule, SaaS prvides clients with the least amunt f cntrl, whereas IaaS ffers the mst cntrl fr the client. It s imprtant t nte that these descriptins fr deplyment and service mdels, althugh widely accepted by the industry, may nt be universally fllwed by clud prviders r reflect actual clud envirnments. Fr example, a CSP might be selling a private clud service that des nt meet the intent f private as it is described abve. Similarly, the details f what is and what is nt included in a particular service will prbably vary between CSPs, even if they each identify their service by the same term (IaaS, PaaS, r SaaS). The level f security respnsibility acrss the clud service mdels generally migrates twards the client as the client mves frm a SaaS mdel (least client respnsibility) t an IaaS mdel (mst client respnsibility). The greatest level f respnsibility fr the CSP t maintain security and peratinal cntrls is present in the SaaS service mdel. Figure 1 n the fllwing page shws hw cntrl is typically shared between the CSP and client acrss different service mdels. 4 Adapted frm The NIST Definitin f Clud Cmputing (SP ) The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 4 4

7 Figure 1: Level f cntrl/respnsibility fr client and CSP acrss different service mdels While clients may be attracted t the SaaS and PaaS mdels due t the resurce savings and reduced respnsibility fr administering the clud envirnment, they shuld be aware that these mdels als crrespnd t a greater lss f cntrl f the envirnment husing their sensitive data. Cntractual agreements and nging due diligence becme especially critical where cntrl is utsurced, t ensure that the required security measures are being met and maintained by the CSP fr the duratin f the agreement. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 5 5

8 3 Clud Prvider / Clud Custmer Relatinships 3.1 Understanding Rles and Respnsibilities The lines f accuntability and respnsibility will be different fr each service and deplyment mdel. Clear plicies and prcedures shuld be agreed upn between client and clud prvider fr all security requirements, and clear respnsibilities fr peratin, management and reprting need t be defined fr each requirement. 3.2 Rles and Respnsibilities fr Different Deplyments Mdels The entity perfrming the rle f CSP will vary accrding t the type f deplyment mdel. Fr example, the CSP rle may be assigned entirely t an external third party (as in a public clud), r the rle may be undertaken by an internal department r business functin (as in an n-premise private clud). Similarly, the rle f CSP may be assigned t mre than ne entity in a cmmunity r hybrid clud scenari. T understand hw respnsibilities are assigned in a particular deplyment mdel, cnsider the fllwing: Private clud Where a private clud is managed n-premise, the CSP rle may be undertaken within the client rganizatin. Fr example, the IT department culd take n the rle f CSP with varius peratinal departments as its clients. In this scenari, the client rganizatin retains full cntrl f their envirnment and its security and cmpliance. Dedicated, private cluds may als be prvisined ff-premise by a third-party CSP. In this case, the delineatin f respnsibility will als depend n the particular service mdel, as described in Sectin 3.3, Respnsibilities fr Different Service Mdels. Cmmunity clud The CSP culd be ne f the client rganizatins within the cmmunity r a separate third party. The delineatin f respnsibility fllws the particular service mdel implemented. Public clud The CSP is a third party that is an rganizatinally-separate entity t its clients. The clud is deplyed within a CSP s envirnment and respnsibility is delineated accrding t the particular service mdel, as defined by the CSP. Hybrid clud The CSP rle may be assigned t bth internal and third-party entities fr different elements f the verall clud infrastructure. Respnsibility will be assigned based n the cmbinatin f deplyment mdels and service mdels implemented. The respnsibility fr implementatin, peratin, and management f security cntrls will be shared differently within each f the clud mdels, and needs t be clearly understd by bth the client and CSP. The client als needs t understand the level f versight r visibility they will have int security functins that are utside their cntrl. If these security respnsibilities are nt prperly assigned, cmmunicated, and understd, insecure cnfiguratins r vulnerabilities culd g unnticed and unaddressed, resulting in ptential explit and data lss r ther cmprmise. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 6 6

9 3.3 Respnsibilities fr Different Service Mdels In all deplyment mdels, and particularly in public clud envirnments, it is imprtant fr all parties t understand the specific elements f the service mdel used and its assciated risks. Any clud deplyment mdel that is nt truly private (n-premise) is by nature a shared respnsibility mdel, where a prtin f respnsibility fr the clud service falls under the realm f the CSP, and a prtin f respnsibility als falls t each client. The level f respnsibility that falls t the CSP r the client is determined by the clud service mdel being utilized that is, IaaS, PaaS, r SaaS. Clear delineatin f respnsibilities shuld be established as a prerequisite t any clud service implementatin t prvide a baseline fr the clud peratin. Figure 2 n the fllwing page illustrates hw cntrl f the different technical layers is ften shared acrss different service mdels. Fr illustratin purpses, different layers f the clud stack are described as fllws: Layer Applicatin Prgram Interface (API) r Graphical User Interface (GUI) Applicatin Slutin stack Operating systems (OS) Virtual machine (VM) Virtual netwrk infrastructure Hypervisr Prcessing and memry Data Strage Netwrk Physical facility Descriptin The interface used by the client r their custmers t interact with the applicatin. The current mst cmmn API is RESTful HTTP r HTTPS. The current mst cmmn GUI is an HTTP r HTTPS based Web site. The actual applicatin being used by ne r mre clients r their custmers. This is the prgramming language used t build and deply applicatins. Sme examples include.net, Pythn, Ruby, Perl, etc. In a virtualized envirnment, the OS runs within each VM. Alternatively, if there is n underlying hypervisr present, the perating system runs directly n the strage hardware. The virtual cntainer assigned fr client use. Fr cmmunicatins within and between virtual machines When virtualizatin is used t manage resurces, the hypervisr is respnsible fr allcating resurces t each virtual machine. It may als be leveraged fr implementing security. The physical hardware that supplies CPU time and physical memry. The physical hardware used fr file strage. This can be a physical r virtual netwrk. It is respnsible fr carrying cmmunicatins between systems and pssibly the Internet. The actual physical building where the clud systems are lcated. Appendix B illustrates a sample inventry fr clud cmputing systems, as guidance fr hw CSPs and their custmers can dcument the different layers f the clud envirnment. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 7 7

10 Figure 2: Example f hw cntrl may be assigned between CSP and clients acrss different service mdels. CSP Clud Layer Service Mdels IaaS PaaS SaaS Data Interfaces (APIs, GUIs) Applicatins Slutin Stack (Prgramming languages) Operating Systems (OS) Virtual Machines Virtual netwrk infrastructure Hypervisrs Prcessing and Memry Data Strage (hard drives, remvable disks, backups, etc.) Netwrk (interfaces and devices, cmmunicatins infrastructure) Physical facilities / data centers Nte: This table prvides an example f hw respnsibilities might be assigned accrding t cmmn descriptins f the different service mdels. Hwever, it s imprtant t nte that the technlgy layers and their crrespnding lines f respnsibility may be different fr each CSP, even if they use the same terminlgy t describe their service, and the individual service fferings may r may nt align with the respnsibly assignments indicated abve. Sme CSPs ffer multiple ptins fr their services fr example, a CSP may have ne IaaS ffering that includes a client-cntrlled hypervisr and a separate IaaS ffering with n client access t the hypervisr. It s imperative that clients and CSPs clearly dcument and understand where the bundaries are in their particular relatinship rather than assuming that any particular respnsibility mdel applies t them. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 8 8

11 Even where a client des nt have cntrl ver a particular layer, they may still have sme respnsibility fr the cnfiguratins r settings that the CSP maintains n their behalf. Fr example, a client may need t define firewall rules and review firewall rule-sets fr thse firewalls applicable t the prtectin f their envirnment, even thugh the CSP actually cnfigures and manages the firewalls. Similarly, clients may be respnsible fr apprving and reviewing user access permissins t their data resurces, while the CSP cnfigures the access accrding t client needs. The allcatin f respnsibility fr managing security cntrls des nt exempt a client frm the respnsibility f ensuring that their cardhlder data is prperly secured. 3.4 Nested Service-Prvider Relatinships Nested service-prvider relatinships are nt uncmmn in clud scenaris, as CSPs smetimes rely n ther third-party cmpanies t deliver their services. Fr examples, sme CSPs use third-party strage prviders as part f their clud service ffering, while sme might partner with ther CSPs fr redundancy r fail-ver as part f their clud-delivery strategy. Identifying all third-party relatinships that the CSP has in place is imprtant in rder t understand the ptential ramificatins t a client s envirnment. The existence f multiple nested relatinships fr example, where there is a chain f vendrs and/r ther prviders required fr delivery f a clud service will als add cmplexity t bth the CSP s and the client s PCI DSS assessment prcess. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace 9 9

12 4 PCI DSS Cnsideratins 4.1 Understanding PCI DSS Respnsibilities The respnsibilities delineated between the client and the CSP fr managing PCI DSS cntrls are influenced by a number f variables, including but nt limited t: The purpse fr which the client is using the clud service. The scpe f PCI DSS requirements that the client is utsurcing t the CSP. The services and system cmpnents that the CSP has validated within its wn peratins. The service ptin that the client has selected t engage the CSP (IaaS, PaaS r SaaS). The scpe f any additinal services the CSP is prviding t practively manage the client s cmpliance (fr example, additinal managed security services). The client needs t clearly understand the scpe f respnsibility that the CSP is accepting fr each PCI DSS requirement, and which services and system cmpnents are validated fr each requirement. Fr example, PCI DSS Requirements 6.1 and 6.2 address the need fr vulnerabilities t be identified, ranked accrding t risk, and deplyed in a timely manner. If nt prperly defined, a client culd assume that the CSP is managing this prcess fr the entire clud envirnment, whereas the CSP culd be managing vulnerabilities fr their underlying infrastructure nly, and assuming that the client is managing vulnerabilities fr perating systems and applicatins. 4.2 PCI DSS Respnsibilities fr Different Service Mdels As a general rule, the mre aspects f a client s peratins that the CSP manages, the mre respnsibility the CSP has fr maintaining PCI DSS cntrls. Hwever, utsurcing maintenance f cntrls is nt the same as utsurcing respnsibility fr the data verall. Clud custmers shuld nt make assumptins abut any service, and shuld clearly spell ut in cntracts, memrandums f understanding, and/r SLAs exactly which party is respnsible fr securing which system cmpnents and prcesses. Figure 3 n the fllwing page prvides an example f hw respnsibilities fr PCI DSS requirements may be shared between clients and CSPs acrss the three service mdels. There will f curse be exceptins and variatins acrss each individual service, and this table is prvided as a guideline fr clients and CSPs t help plan discussins and negtiatins. Respnsibilities have been identified as fllws: Generally each client will retain respnsibility fr maintaining and verifying the requirement. CSP Generally the CSP will maintain and verify the requirement fr their clients. Bth Generally respnsibility is shared between the client and the CSP. This may be due t the requirement applying t elements present in bth the client envirnment and the CSP-managed envirnment, r because bth parties need t be invlved in the management f a particular cntrl. Appendix A includes additinal cnsideratins fr determining hw PCI DSS respnsibilities may be assigned fr each service mdel. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

13 Figure 3: Example f hw PCI DSS respnsibilities may be shared between clients and CSPs. CSP BOTH and CSP PCI DSS Requirement Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS 1: Install and maintain a firewall cnfiguratin t prtect cardhlder data Bth Bth CSP 2: D nt use vendr-supplied defaults fr system passwrds and ther security parameters Bth Bth CSP 3: Prtect stred cardhlder data Bth Bth CSP 4: Encrypt transmissin f cardhlder data acrss pen, public netwrks Bth CSP 5: Use and regularly update anti-virus sftware r prgrams Bth CSP 6: Develp and maintain secure systems and applicatins Bth Bth Bth 7: Restrict access t cardhlder data by business need t knw Bth Bth Bth 8: Assign a unique ID t each persn with cmputer access Bth Bth Bth 9: Restrict physical access t cardhlder data CSP CSP CSP 10: Track and mnitr all access t netwrk resurces and cardhlder data Bth Bth CSP 11: Regularly test security systems and prcesses Bth Bth CSP 12: Maintain a plicy that addresses infrmatin security fr all persnnel Bth Bth Bth PCI DSS Appendix A: Additinal PCI DSS Requirements fr Shared Hsting Prviders CSP CSP CSP Nte: The sample respnsibilities illustrated in this table d nt include cnsideratin fr any activities r peratins perfrmed utside f a hypthetical clud service ffering. This table prvides an example f hw PCI DSS respnsibilities might be assigned fr different service mdels. Hwever, each CSP ultimately defines their wn service, and particular service fferings may r may nt be cnsistent with thse illustrated abve. s and CSPs shuld clearly dcument their respnsibilities as applicable t their particular agreement. The cncept f shared r jint respnsibility can be a particular tricky path t navigate. While sme services and functins will be relatively straightfrward t scpe and establish bundaries, many services and functins will verlap if nt clearly demarcated at the utset f the service relatinship. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

14 Where the CSP maintains respnsibility fr PCI DSS cntrls, the client is still respnsible fr mnitring the CSP s nging cmpliance fr all applicable requirements. CSPs shuld be able t prvide their clients with nging assurance that requirements are being met, and where the CSP is managing requirements n behalf f the client, they shuld have mechanisms in place t prvide the custmer with the applicable recrds fr example, audit lgs shwing all access t client data. s are still required t validate their cmpliance in accrdance with payment brand prgrams. Appendix C illustrates a sample PCI DSS Respnsibly Matrix, as guidance fr hw CSPs and their custmers can dcument PCI DSS respnsibility assignments. Appendix D includes Implementatin Cnsideratins fr PCI DSS Requirements. 4.3 Security as a Service (SecaaS) Security as a Service, r SecaaS, is smetimes used t describe the delivery f security services using a SaaS-based delivery mdel. SecaaS slutins nt directly invlved in string, prcessing, r transmitting CHD may still be an integral part f the security f the CDE. As an example, a SaaS-based anti-malware slutin may be used t update anti-malware signatures n the client s systems via a clud-delivery mdel. In this example, the SecaaS ffering is delivering a PCI DSS cntrl t the client s envirnment, and the SecaaS functinality will need t be reviewed t verify that it is meeting the applicable requirements. 4.4 Segmentatin Cnsideratins Outside f a clud envirnment, individual client envirnments wuld nrmally be physically, rganizatinally, and administratively separate frm each ther. s utilizing a public r therwise shared clud must rely n the CSP t ensure that their envirnment is adequately islated frm the ther client envirnments. In additin t enfrcing separatin between client envirnments, segmentatin may als be desired within a client s envirnment t islate their CDE cmpnents frm nn-cde cmpnents in rder t reduce their wn PCI DSS scpe. Segmentatin n a clud-cmputing infrastructure must prvide an equivalent level f islatin as that achievable thrugh physical netwrk separatin. Mechanisms t ensure apprpriate islatin may be required at the netwrk, perating system, and applicatin layers; and mst imprtantly, there shuld be guaranteed islatin f data that is stred. envirnments must be islated frm each ther such that they can be cnsidered separately managed entities with n cnnectivity between them. Any systems r cmpnents shared by the client envirnments, including the hypervisr and underlying systems, must nt prvide an access path between envirnments. Any shared infrastructure used t huse an in-scpe client envirnment wuld be in scpe fr that client s PCI DSS assessment. A segmented clud envirnment exists when the CSP enfrces islatin between client envirnments. Examples f hw segmentatin may be prvided in shared clud envirnments include, but are nt limited t: Traditinal Applicatin Service Prvider (ASP) mdel, where physically separate servers are prvided fr each client s cardhlder data envirnment. Virtualized servers that are individually dedicated t a particular client, including any virtualized disks such as SAN, NAS r virtual database servers. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

15 Envirnments where clients run their applicatins in separate lgical partitins using separate database management system images and d nt share disk strage r ther resurces. The PCI DSS assessr must validate the effectiveness f the segmentatin t ensure it prvides adequate islatin. If adequate segmentatin is prvided between clients, the client envirnment and the CSP-managed envirnment and prcesses wuld be in scpe fr a client s PCI DSS assessment. If adequate segmentatin is nt in place r cannt be verified, the entire clud envirnment wuld be in-scpe fr any ne client s assessment. Examples f nn-segmented clud envirnments include but are nt limited t: Envirnments where rganizatins use the same applicatin image n the same server and are nly separated by the access cntrl system f the perating system r the applicatin. Envirnments where rganizatins use different images f an applicatin n the same server and are nly separated by the access cntrl system f the perating system r the applicatin. Envirnments where rganizatins data is stred in the same instance f the database management system s data stre. Withut adequate segmentatin, all clients f the shared infrastructure, as well as the CSP, wuld need t be verified as being PCI DSS cmpliant in rder fr any ne client t be assured f the cmpliance f the envirnment. This will likely make cmpliance validatin unachievable fr the CSP r any f their clients Segmentatin Challenges Segmentatin in traditinal hsted envirnments can be applied via separate physical servers and security measures applied using knwn methds. The difference in a clud envirnment is that there are cmmn shared layers (such as hypervisrs and virtual infrastructure layers), which can present a single pint f entry (r attack) fr all systems abve r belw thse shared layers. The security applied t these layers is therefre critical nt nly t the security f the individual envirnments they supprt, but als t ensure that segmentatin is enfrced between different client envirnments. Once any layer f the clud architecture is shared by CDE and nn-cde envirnments, segmentatin becmes increasingly cmplex. This cmplexity is nt limited t shared hypervisrs; all layers f the infrastructure that culd prvide an entry pint t a CDE must be included when verifying segmentatin. In a private clud envirnment, ne apprach that may help reduce the cmplexity f segmentatin effrts culd be t lcate all CDE virtual cmpnents n a dedicated CDE hypervisr, and ensure all nn-cde virtual cmpnents are lcated n separate hypervisrs, adequately segmented frm the CDE hypervisr. The need fr adequate segmentatin f client envirnments in a public r shared clud is underscred by the principle that the ther client envirnments running n the same infrastructure are t be cnsidered untrusted netwrks. The client has n way f cnfirming whether ther client envirnments are securely cnfigured, patched apprpriately t prtect against attack, r that they are nt already cmprmised r even designed t be malicius. This is particularly relevant where a CSP ffers IaaS and PaaS services, as the individual clients have greater cntrl and management f their envirnments. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

16 4.4.2 Segmentatin Respnsibilities Ultimately, the CSP needs t take wnership f the segmentatin between clients and verify it is effective and prvides adequate islatin between individual client envirnments, between client envirnments and the CSP s wn envirnment, and between client envirnments and ther untrusted envirnments (such as the Internet). Applicable PCI DSS cntrls fr the segmentatin functins wuld als be the CSP s respnsibility (fr example, firewall rules, audit lgging, dcumentatin, reviews, etc.). The client is respnsible fr the prper cnfiguratin f any segmentatin cntrls implemented within their wn envirnment (fr example, using virtual firewalls t separate in-scpe VMs frm ut-f-scpe VMs), and fr ensuring that effective islatin is maintained between in-scpe and ut-f-scpe cmpnents. s wishing t implement segmentatin within their clud envirnment als need t cnsider hw the CSP s envirnment and prcesses may impact the effectiveness f the segmentatin. Fr example, CSP systems culd be prviding cnnectivity between the client s wn VMs that is nt visible t the client. s shuld als cnsider hw the CSP manages ffline r drmant VMs, and whether in-scpe and ut-f-scpe VMs culd ptentially be stred tgether by the CSP withut active segmentatin cntrls Segmentatin Technlgies Traditinal netwrk segmentatin technlgies cnsist f hardware devices such as firewalls, switches, ruters, and s frth. These physical cmpnents culd be used t separate VMs hsted n the same r multiple hypervisrs similar t the manner in which systems culd be segmented in a physical netwrk. This wuld require hypervisrs with multiple netwrk interfaces and PCI DSS cmpliant cnfiguratins fr the varius types f netwrk hardware. Additinally, virtual cunterparts f firewalls, switches and ruters nw exist and can be incrprated int a virtual envirnment. As mentined abve, a key cnsideratin is hw secure the cmmn layers (such as hypervisrs and shared physical cmpnents) are, and whether they represent a ptential attack surface between znes r clients. The answer is that yes, they d; hwever the assciated risks are still nt well understd. Examples f cntrls t be cnsidered when evaluating segmentatin ptins include, but are nt limited t: Physical firewalls and netwrk segmentatin at the infrastructure level Firewalls at the hypervisr and VM level VLAN tagging r zning in additin t firewalls Intrusin-preventin systems at the hypervisr and/r VM level t detect and blck unwanted traffic Data-lss-preventin tls at the hypervisr and/r VM level Cntrls t prevent ut-f-band cmmunicatins ccurring via the underlying infrastructure Islatin f shared prcesses and resurces frm client envirnments Segmented data stres fr each client Strng, tw-factr authenticatin Separatin f duties and administrative versight Cntinuus lgging and mnitring f perimeter traffic, and real-time respnse The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

17 4.5 Scping Cnsideratins Merchant r ther rganizatins lking t stre, prcess, r transmit payment card data in a clud envirnment shuld clearly understand the impact that extending their CDE int the clud will have n their PCI DSS scpe. Fr example, in a private-clud deplyment, an rganizatin culd either implement adequate segmentatin t islate in-scpe systems frm ther systems and services, r they culd cnsider their private clud t be whlly in scpe fr PCI DSS. In a public clud, the client rganizatin and CSP will need t wrk clsely tgether t define and verify scpe bundaries, as bth parties will have systems and services in scpe. Appendix D includes Implementatin Cnsideratins fr PCI DSS Requirements. Recmmendatins fr minimizing and simplifying PCI DSS scpe in a clud envirnment include: Dn t stre, prcess r transmit payment card data in the clud. This is the mst effective way t keep a clud envirnment ut f scpe, as PCI DSS cntrls are nt required if there is n payment card data t prtect. Implement a dedicated physical infrastructure that is used nly fr the in-scpe clud envirnment. The scping prcess will be simplified if all in-scpe peratins are limited t a knwn, defined set f physical and virtual system cmpnents that are managed independently frm ther cmpnents. Once defined, the client will be reliant n the CSP s ability t ensure scpe bundaries are maintained fr example, by ensuring that all segmentatin cntrls are perating effectively and that any new cmpnents cnnected t the in-scpe envirnment are immediately brught int scpe and prtected accrdingly. Minimize reliance n third-party CSPs fr prtecting payment card data. The mre security cntrls the CSP is respnsible fr, the greater the scpe f the CDE will ptentially be, thereby increasing the cmplexity invlved in defining and maintaining CDE bundaries. Ensuring that clear-text accunt data is never accessible in the clud may als assist t reduce the number f PCI DSS requirements applicable t the clud envirnment. As an example, let s say the client perfrms all encryptin and decryptin peratins and all key-management functins 5 in their wn data center and uses a third-party clud nly t stre r transmit encrypted data. In this scenari, clear-text data wuld never exist in the clud envirnment nt even temprarily r in memry. Additinally, the clud envirnment wuld never have access t cryptgraphic keys r key-management prcesses. It shuld be nted that the encrypted data is still in scpe fr PCI DSS (generally fr the entity that cntrls r manages the encrypted data and/r the cryptgraphic keys 6 ) t ensure that applicable cntrls are in place. Hwever, by keeping all encryptin/decryptin and key-management peratins islated frm the clud, the number f PCI DSS requirements that the CSP is required t maintain may be reduced, as these requirements will instead be applicable t the client s wn envirnment and persnnel. The CSP will still be in scpe fr any PCI DSS requirements it manages n behalf f the client fr example, access cntrls managed by the CSP will need t be verified t ensure that nly authrized persns (as determined by the client) have access t the encrypted data, and that access is nt granted t unauthrized persns. 5 In accrdance with PCI DSS Requirements 6 Refer t FAQ Is encrypted cardhlder data in scpe fr PCI DSS? n PCI SSC website fr additinal guidance. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

18 Alternatively, if clear-text accunt data is present (fr example, in memry) in the clud envirnment, r the ability t retrieve accunt data exists (fr example, if decryptin keys and encrypted data are present), all applicable PCI DSS requirements wuld apply t that envirnment Scping Examples fr Different Deplyment Mdels Fr private clud envirnments, segmentatin effrts are fcused n islating CDE cmpnents frm nn-cde cmpnents t reduce the number f systems in scpe fr PCI DSS. In public r shared clud envirnments, segmentatin between clients is critical fr the security f the entire client envirnment, and is additinal t any segmentatin managed by the client within their envirnment fr the purpses f scping. A number f simple scping examples are presented here t prvide guidance. Scenari Envirnment descriptin PCI DSS scping guidance Case 1: Private Clud hsted and cntrlled by entity seeking PCI DSS cmpliance, with segmentatin. Case 2: Private Clud hsted and cntrlled by entity seeking PCI DSS cmpliance, n segmentatin. All CDE VMs are hsted n a single, dedicated hypervisr; nn-cde VMs are hsted n a separate hypervisr(s). Validated segmentatin f CDE systems frm nn-cde systems using a cmbinatin f physical and lgical cntrls All VMs are hsted n ne r mre hypervisrs; sme VMs are cnsidered part f the CDE and sme are nt. N segmentatin f CDE systems frm nn-cde systems. The CDE hypervisr and VMs, and all clud cmpnents that are nt segmented are in scpe (segmentatin must be validated as prviding effective islatin) The entire clud envirnment and all cnnected systems are in scpe and cnsidered part f the CDE (similar t a flat netwrk). The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

19 Scenari Envirnment descriptin PCI DSS scping guidance Case 3: Third-party CSP hsting a PCI DSS cmpliant public clud supprting multiple clients, with validated segmentatin fr client envirnments. Case 4: Third-party CSP hsting a PCI DSS cmpliant public clud supprting multiple clients, n client segmentatin. VMs may be n ne r multiple hypervisrs, all hypervisrs and VMs are cnfigured by CSP t supprt PCI DSS requirements. Multiple clients hsted n each hypervisr. Validated segmentatin f client envirnments using a cmbinatin f physical and lgical cntrls. VMs may be n ne r multiple hypervisrs, all hypervisrs cnfigured by CSP t supprt PCI DSS requirements. Multiple clients hsted n each hypervisr, VM cnfiguratin managed by each client. Segmentatin between client envirnments is nt verified. The CSP is respnsible fr cmpliance f all elements f the clud service prvided. Each client s scpe wuld include their wn envirnment (fr example, VMs, applicatins etc.) and any ther elements nt managed by the CSP. Segmentatin must be validated as prviding effective islatin between clients as part f the CSP s validatin, and may require additinal validatin as part f each client s validatin. Entire clud service and all client envirnments are in scpe. Nte that validating PCI DSS cmpliance may be intractable and infeasible as every client envirnment wuld need t be included in the assessment. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

20 5 PCI DSS Cmpliance Challenges String, prcessing, r transmitting cardhlder data in the clud brings that clud envirnment int scpe fr PCI DSS, and it may be particularly challenging t validate PCI DSS cmpliance in a distributed, dynamic infrastructure such as a public r ther shared clud. Fr example, it can be difficult t identify which system cmpnents are in scpe fr a particular service, r identify wh is respnsible fr particular PCI DSS cntrls. Sme f the technical cntrls and auditing prcesses traditinally used t attain a measurable level f assurance in static envirnments (fr example, in-huse data strage servers) are nt designed fr rapidlychanging clud envirnments and prcesses (fr example, clud bursting, cntinual deplyment and retirement f virtual machines, dynamic IP addressing, and s n). Additinally, clients and assessrs ften can t see and tuch CDE systems as they wuld in a traditinal envirnment (fr example, by visiting the data center). The distributed architectures f clud envirnments add layers f technlgy and cmplexity that challenge traditinal assessment methds. Fr example, hw des an assessr determine an apprpriate sample size fr a dynamic clud envirnment in which systems can appear and disappear in minutes? Examples f cmpliance challenges include but are nt limited t: s may have little r n visibility int the CSP s underlying infrastructure and the related security cntrls. s may have limited r n versight r cntrl ver cardhlder data strage. Organizatins might nt knw where cardhlder data is physically stred, r the lcatin(s) can regularly change. Fr redundancy r high availability reasns, data culd be stred in multiple lcatins at any given time. Sme virtual cmpnents d nt have the same level f access cntrl, lgging, and mnitring as their physical cunterparts. Perimeter bundaries between client envirnments can be fluid. Public clud envirnments are usually designed t allw access frm anywhere n the Internet. It can be challenging t verify wh has access t cardhlder data prcessed, transmitted, r stred in the clud envirnment. It can be challenging t cllect, crrelate, and/r archive all f the lgs necessary t meet applicable PCI DSS requirements. Organizatins using data-discvery tls t identify cardhlder data in their envirnments, and t ensure that such data is nt stred in unexpected places, may find that running such tls in a clud envirnment can be difficult and result in incmplete results. It can be challenging fr rganizatins t verify that cardhlder card data has nt leaked int the clud. Many large prviders might nt supprt right-t-audit fr their clients. s shuld discuss their needs with the prvider t determine hw the CSP can prvide assurance that required cntrls are in place. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace