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

21 These challenges will impact a number f factrs related t hw PCI DSS cmpliance is managed, including hw segmentatin is implemented, hw PCI DSS assessments are scped, hw individual PCI DSS requirements are validated, and which party will perfrm particular validatin activities. At a high level, CSPs can be identified as thse that have been validated as meeting a particular level f PCI DSS cmpliance and thse that have nt. The recmmended practice fr clients with PCI DSS cnsideratins is t wrk with CSPs whse services have been independently validated as being PCI DSS cmpliant. 5.1 What des I am PCI cmpliant mean? Much stck is placed in the statement I am PCI cmpliant, but what des this actually mean fr the different parties invlved? Use f a PCI DSS cmpliant CSP des nt result in PCI DSS cmpliance fr the clients. The client must still ensure they are using the service in a cmpliant manner, and is als ultimately respnsible fr the security f their CHD utsurcing daily management f a subset f PCI DSS requirements des nt remve the client s respnsibility t ensure CHD is prperly secured and that PCI DSS cntrls are met. The client therefre must wrk with the CSP t ensure that evidence is prvided t verify that PCI DSS cntrls are maintained n an nging basis an Attestatin f Cmpliance (AOC) reflects a single pint in time nly; cmpliance requires nging mnitring and validatin that cntrls are in place and wrking effectively. Even where a clud service is validated fr certain PCI DSS requirements, this validatin des nt autmatically transfer t the client envirnments within that clud service. Fr example, a CSP s validatin may have included use f up-t-date anti-virus sftware n the CSP s systems; hwever, this validatin might nt extend t the individual client OS r VMs (such as in an IaaS service). Additinally, the client must still maintain cmpliance fr all f their wn peratins fr example, by ensuring anti-virus is installed and updated n all client-side systems used t cnnect int the clud envirnment. Similarly, a client s PCI DSS cmpliance des nt result in any claim f cmpliance fr the CSP, even if the client s validatin included elements f the service managed by the CSP. Regarding the applicability f ne party s cmpliance t the ther, cnsider the fllwing: a) If a CSP is cmpliant, this des nt mean that their clients are. b) If a CSP s clients are cmpliant, this des nt mean that the CSP is. c) If a CSP and the client are cmpliant, this des nt mean that any ther clients are. The CSP shuld ensure that any service ffered as being PCI cmpliant is accmpanied by a clear and unambiguus explanatin, supprted by apprpriate evidence, f which aspects f the service have been validated as cmpliant and which have nt. 5.2 Verifying Scpe f Validated Services and Cmpnents s shuld first verify that the service they are using is the ne that has been validated. CSPs that have validated PCI DSS cmpliance may be included n a list published by a payment card brand r they may nt; either way, the client will need t btain details f the CSP s cmpliance validatin in rder t determine whether the service they are using is whlly cvered. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

22 Cnsideratins fr the client may include: Hw lng has the CSP been PCI DSS cmpliant? When was their last validatin? What specific services and PCI DSS requirements were included in the validatin? What specific facilities and system cmpnents were included in the validatin? Are there any system cmpnents that the CSP relies n fr delivery f the service that were nt included in the PCI DSS validatin? Hw des the CSP ensure that clients using the PCI DSS cmpliant service cannt intrduce nncmpliant cmpnents t the envirnment r bypass any PCI DSS cntrls? CSPs shuld prvide their clients with evidence that clearly identifies what was included in the scpe f their PCI DSS assessment, as well as the specific PCI DSS requirements that the envirnment was assessed against, and the date f the assessment. All aspects f the clud service nt cvered by the CSP s PCI DSS assessment shuld als be identified and dcumented, as these will need t be validated either by the client r the CSP in rder fr a client s assessment t be cmpleted. The client must have a detailed understanding f any security requirements that are nt cvered by the prvider and are therefre the client s respnsibility t implement, manage, and validate as part f their wn PCI DSS cmpliance. CSPs that have undergne an independent PCI DSS assessment t validate their cmpliance will have the results summarized in an Attestatin f Cmpliance (AOC) and detailed in a Reprt n Cmpliance (ROC). The Executive Summary and Scpe f Wrk sectins f the ROC shuld detail the scpe f the assessment including the specific cmpnents, facilities, and services that were assessed. 5.3 Verifying PCI DSS Cntrls Managed by the Clud Prvider As with all hsted services in scpe fr PCI DSS, the client rganizatin shuld request sufficient evidence and assurance frm their CSP that all in-scpe prcesses and cmpnents under the CSP s cntrl are PCI DSS cmpliant. This verificatin may be cmpleted by the client s assessr (such as a QSA r ISA) as part f client s PCI DSS assessment. If the CSP has already undergne a PCI DSS assessment that was perfrmed by anther assessr, the client s assessr will need t verify that the CSP s validatin is current, that the assessment cvered all services prvided t r used by the client, and that all applicable requirements were fund t be in place fr the envirnments and systems in scpe. CSPs that have undergne PCI DSS cmpliance assessment and validatin shuld be able t prvide their clients with the fllwing: Prf f cmpliance dcumentatin (such as the AOC and applicable sectins frm the ROC), including date f cmpliance assessment Dcumented evidence f system cmpnents and services that were included in the PCI DSS assessment Dcumented evidence f system cmpnents and services that were excluded frm the PCI DSS assessment, as applicable t the service Apprpriate cntract language, if applicable The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

23 CSPs that have nt undergne a PCI DSS cmpliance assessment will need t be included in their client s assessment. The CSP will need t agree t prvide the client s assessr with access t their envirnment in rder fr the client t cmplete their assessment. The client s assessr may require nsite access and detailed infrmatin frm the CSP, including but nt limited t: Access t systems, facilities, and apprpriate persnnel fr n-site reviews, interviews, physical walkthrughs, etc. Plicies and prcedures, prcess dcumentatin, cnfiguratin standards, training recrds, incident respnse plans, etc. Evidence (such as cnfiguratins, screen shts, prcess reviews, etc.) t shw that all applicable PCI DSS requirements are being met fr the in-scpe system cmpnents Apprpriate cntract language, if applicable The client and CSP will need t agree upn which assessment activities can be perfrmed by the client and which testing is the respnsibility f the CSP. Fr example, in an IaaS/PaaS service, the client may wish t test within their wn envirnment and whatever else they can access, such as the bundaries between themselves and ther clients, r between themselves and the CSP s systems. Hwever, if such testing is nt permitted by the CSP, the client will have t rely n the CSP t perfrm and validate these requirements. In SaaS envirnments, the client will have limited r n visibility r permissin t perfrm testing, and will generally be reliant n the CSP fr all testing and validatin. Defined testing activities and their assciated cntrls and permissins shuld be detailed in the SLA. The CSP als needs t be able t prvide clients with specific details as applicable t the nging maintenance f PCI DSS cmpliance. Fr example, depending n the service prvided, the CSP may need t prduce cpies f lg files, patch update recrds, r firewall rule-sets that specifically apply t an individual client s envirnment. CSPs wishing t prvide a PCI DSS cmpliant service may wish t cnsider islating the PCI DSS cmpliant services frm their nn-pci cmpliant services. This may help t simplify the cmpliance validatin prcess fr bth the CSP and fr their individual clients. It may als help the CSP t standardize the PCI DSS cmpliant services being prvided t their clients. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

24 6 Additinal Security Cnsideratins While the use f clud services can prvide an attractive pprtunity fr rganizatins f all sizes t utsurce and utilize centrally-managed security resurces, rganizatins shuld als be aware f the risks and challenges assciated with a particular clud chice befre mving their sensitive data r services int the clud envirnment. This sectin explres sme f these additinal security cnsideratins. 6.1 Gvernance, Risk and Cmpliance One f the primary challenges with clud envirnments is that gvernance, cmpliance, and risk management are typically shared between the client and CSP. This shared delineatin f respnsibilities emphasizes the imprtance f a strng gvernance and risk-management structure. Withut a clear gvernance strategy, the client may be unaware f issues arising frm use f the clud service, and the CSP may be unaware f issues within the client envirnment that culd impact their service prvisin. A strategy fr shared gvernance and cmmunicatin shuld be established between client and CSP t enable clear cmmunicatin f all aspects f the relatinship frm peratinal perfrmance t security risk management and issue reslutin. Reprting and mnitring mechanisms shuld be made available t client rganizatins t prvide assurance that effective gvernance is applied by the CSP Risk Management Cnsistent with a risk-management apprach fr in-huse services, utsurced clud services shuld be assessed against an rganizatin s risk criteria with the intent f identifying critical assets, analyzing ptential vulnerabilities and threats t thse assets, and develping an apprpriate risk-mitigatin strategy (see PCI DSS Requirement ). Lack f physical cntrl f infrastructure, as ccurs when the envirnment is utsurced t a third-party CSP, renders a thrugh risk-management prcess all the mre imprtant. In traditinal envirnments, the physical lcatin f sensitive data can be restricted t dedicated systems, facilitating the identificatin and implementatin f effective risk-mitigatin cntrls. Hwever, the advent f new technlgies requires a reevaluatin f traditinal risk strategies. Fr example, data in clud envirnments is n lnger tied t a physical system r lcatin, reducing the effectiveness f traditinal security mechanisms t prtect data frm risk. Traditinal security appraches that build security cntrls arund sensitive data may therefre need t evlve t address this new risk envirnment. Similarly, traditinal frms f risk assessment might nt take int cnsideratin particular clud characteristics, such as a pay-as-yu g mdel r multi-tenancy (described in Sectin 6.5.7), and may therefre require new r mdified prcedures Due Diligence A CSP that stres, prcesses, r transmits cardhlder data n behalf f a client, prvides a security service fr the prtectin f a client s cardhlder data, r culd therwise impact the security f a client s cardhlder data, wuld be cnsidered a third-party service prvider f the client. As with all service prviders, clients shuld fllw a thrugh due-diligence prcess (see PCI DSS Requirement 12.8) prir The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

25 t engagement f the CSP. The specific due-diligence prcess and gals will vary fr each client rganizatin, hwever cmmn bjectives typically include: 1. Cnfirming the prvider has a histry f sund wrk practices and ethical behavir and is legitimately perfrming the services the client believes them t be 2. Verifying that the prvider is cmpatible with the client s business image and risk prfile 3. Identifying ptential risks r circumstances assciated with the prvider that may impact the client s peratins r business 4. Identifying elements f the service that need t be clarified, and that need t be included in cntracts r service agreements Due diligence is nt simply reading the prvider s marketing material r relying n a prvider s claims f PCI cmpliance r secure peratins. s shuld be sufficiently assured that they are engaging with a prvider that can meet their security and peratinal needs befre undertaking any such engagements. The scpe f the due-diligence exercise shuld cnsider, at a minimum, the tpics discussed thrughut this dcument, as applicable t a client s particular requirements Service Level Agreements (SLAs) The use f clud services includes the deplyment f a defined service mdel and shuld always be underwritten by cmprehensive service level agreements (SLAs). The secure delivery f any clud service is dependent n the CSP s persnnel, prcesses, and technlgies, while the secure usage f clud services remains the respnsibility f the client. Typically, clud-hsting agreements are cncerned with up-time and high availability, with little r n mentin r assurance f security. Hwever, the client is ultimately respnsible fr ensuring the service they re using meets their security requirements and cmpliance bligatins. SLAs and ther written agreements between the CSP and client shuld clearly identify the delineatin f respnsibilities between parties, including respnsibilities fr implementing and managing different security cntrls. These SLAs and agreements shuld be established as a prerequisite t any clud service implementatin. PCI DSS cmpliance validatin and testing activities (with the assciated cntrls, permissins, and schedules) shuld als be clearly detailed in the SLA. Failure t develp and agree upn apprpriate SLAs may result in issues fr the client if the clud service des nt meet the needs and demands f their business. SLAs shuld be established and agreed as part f any cntract and service negtiatins. Perfrmance, availability, integrity, and cnfidentiality shuld be cnsidered and SLAs agreed fr each service managed and/r perated by the CSP. Written agreements shuld als cver activities and assurances t be prvided by bth parties upn terminatin f the service prvisin Business Cntinuity Plans and Disaster Recvery Organizatinal requirements fr business-cntinuity plans (BCP) and disaster recvery (DR) apply t the client s utsurced envirnments as they d fr client-managed facilities. s shuld cnsider whether the CSP s cntinuity and recvery prcedures are sufficient t meet the client s rganizatinal requirements, and the PCI DSS scpe f the clud service shuld include any fail-ver sites and systems The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

26 that might be used t stre, prcess, r transmit cardhlder data in BCP r DR situatin, The ability t perfrm tests f the BCP and DR capabilities and/r t bserve results f the CSP s testing shuld als be cnsidered Human resurces Management f the CSP s human resurces is largely ut f the cntrl f the client. The client s duediligence prcesses shuld include an understanding f the CSP s human resurces and emplyee engagement practices, as inapprpriately r under-qualified persnnel may expse data t unnecessary risk. PCI DSS Requirement 12.7 prvides a basis fr assessing the recruitment prcess at the CSP. 6.2 Facilities and Physical Security Clud services are nly clud in cncept. In reality, clud services invlve physical resurces lcated at the CSP envirnment which are accessed remtely frm the client s envirnment. Similarly t ther third-party prviders, CSPs f public and shared cluds prvide services t multiple clients whse data and virtual cmpnents c-exist in the same physical lcatin and n the same physical systems as ther clients. Pr physical security cntrls at a CSP facility may expse many clients data t unnecessary risk, and pr envirnmental cntrls may impact the perfrmance and integrity f the service prvisin. In a private clud, the physical lcatin f all cmpnents is knwn and can be verified. When using a public clud, different elements f the envirnment, such as VMs, hypervisrs, virtual netwrk devices, etc., culd be frequently relcated accrding t the CSP s lad-balancing strategy. Verifying that apprpriate physical security is in place can be challenging in an envirnment where data and infrastructure can be in multiple different lcatins at different times. A client shuld seek assurance that their physical security requirements are cnsistently applied acrss all ptential lcatins. 6.3 Data svereignty and Legal cnsideratins Depending n the deplyment and service mdel adpted, and due t the dynamic nature f clud peratins, it may nt be knwn where particular infrmatin actually resides. This may result in cncerns ver data wnership and ptential cnflicts between dmestic r internatinal legal and regulatry requirements. Fr example, the CSP s infrastructure may result in data traversing r being stred in plitically r ecnmically unstable cuntries. Understanding the legal jurisdictins that apply t data in different cuntries r regins can be a challenge fr the client rganizatin. Fr example, clients subject t reginal laws restricting crss-brder flws f data will need t verify all lcatins and flws f their data t ensure their clud service is cmpliant with their legal bligatins. Other legal cnsideratins include requirements fr electrnic discvery, evidence preservatin and integrity, and data custdy. CSPs shuld have dcumented prcesses fr respnding t legal requests fr seizure f recrds, including data/audit lgs belnging t the CSP and their clients. s shuld understand the ramificatins f such laws in the cuntries where their data exists, as well as the prcesses that their CSP will engage in. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

27 6.4 Data Security Cnsideratins Further t the data-svereignty cnsideratins mentined abve, public-clud prviders ften have multiple data strage systems lcated in multiple data centers, which may ften be in multiple cuntries r regins. Cnsequently, the client may nt knw the lcatin f their data, r the data may exist in ne r mre f several lcatins at any particular time. Additinally, a client may have little r n visibility int the cntrls prtecting their stred data. This can make validatin f data security and access cntrls fr a specific data set particularly challenging. It is recmmended that data-security needs are evaluated fr all types f infrmatin being migrated t a clud envirnment, nt nly cardhlder data. Fr example, peratinal data, security plicies and prcedures, system cnfiguratins and build standards, lg files, audit reprts, authenticatin credentials, cryptgraphic keys, incident respnse plans, and emplyee cntact details are just sme f the types f data with different security requirements that may need t be cnsidered. If data security prcesses are nt clearly defined and dcumented, the data may be unintentinally expsed r subject t unnecessary risk that culd result in lss r inapprpriate disclsure Data Acquisitin The client will ultimately determine hw and when the cardhlder data is acquired in the clud envirnment. End-t-end prcesses and data flws must be dcumented acrss bth client and clud prvider netwrks, s that it is clearly understd where cardhlder data is lcated and hw it is traversing the infrastructure (see PCI DSS Requirement 1.1.2). This will als help the client and CSP t identify where each entity acquires and relinquishes cardhlder data thrughut the prcess Data strage and persistence In additin t the knwn range f intended strage lcatins, data may als be present in ther CSP systems used fr maintenance f the clud infrastructure, such as VM images, backups, mnitring lgs, and s n. Cardhlder data stred in memry culd als be written t disk fr recvery r high availability purpses (fr example, in the case f virtual machine suspensin r snapsht). Such stred data may easily be frgtten and s nt prtected by data security cntrls. All ptential capture pints shuld be identified and managed as necessary t prevent unintended r unsecured strage r transmissin f sensitive data. Specialized tls and prcesses may be needed t lcate and manage data stred n archived, ff-line, r relcated images. Ptential hypervisr access t data in memry shuld als be taken int cnsideratin, t ensure that client-defined access cntrls are nt unintentinally bypassed by CSP administratr persnnel Data lifecycle management Fr all clud mdels, clear requirements fr data retentin, strage and secure dispsal shuld frm an integral part f the engagement prcess t ensure that sensitive data is: Retained fr as lng as needed, Nt retained any lnger than needed, Stred nly in apprpriate and secured lcatins, The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

28 Accessible nly t thse with a business need, and Handled in accrdance with the client s security plicy (See PCI DSS Requirements 3, 7, and 10.7) Because all envirnments utside the client-cntrlled envirnment culd ptentially be untrusted, clud services shuld supprt the secure transmissin f cardhlder data thrughut the clud infrastructure, between the client and clud envirnments, between client envirnments, and between the clud infrastructure and ther public netwrks. It is recmmended that sensitive data be encrypted fr all transmissins thrugh any clud envirnment that is nt entirely private and/r cntrlled by the client. Clud envirnments utside f the client-cntrlled envirnment shuld be treated as pen r public netwrks (see PCI DSS Requirement 4.1). In a distributed clud envirnment, verifying that all instances f cardhlder data have been securely deleted in accrdance with the client s data-retentin plicy is subject t the same challenges identified abve fr validating data security and access cntrls. Dispsal f cardhlder data must be cnducted using secure methds in accrdance with PCI DSS requirements, and all lcatins f cardhlder data frm within bth the client and CSP envirnments need t be included. The dispsal methd shuld ensure that data is nt recverable upn cmpletin f the dispsal prcess Data Classificatin Data classificatin and the management f data accrding t its classificatin will vary frm rganizatin t rganizatin. A defined data-classificatin system can help rganizatins identify data that is sensitive r cnfidential, and data with specific security needs. This in turn allws rganizatins t assign apprpriate prtectin mechanisms based n the security needs f different data types, and helps t prevent sensitive data frm being inadvertently mishandled r treated as nn-sensitive. Organizatins shuld ensure that their particular data security needs can be met by the clud service befre migrating that data int the clud envirnment. Cnsideratins shuld include hw string data types with different levels f sensitivity in the same virtual envirnment may impact the prtectin levels required fr each data type. Cardhlder data, user credentials and passwrds, and cryptgraphic keys are examples f sensitive data that must be prtected accrding t their individual needs Data Encryptin and Cryptgraphic Key Management In a public-clud envirnment, ne client s data is typically stred with data belnging t multiple ther clients. This makes a public clud an attractive target fr attackers, as the ptential gain may be greater than that t be attained frm attacking a number f rganizatins individually. Strng data-level encryptin shuld be enfrced n all sensitive r ptentially sensitive data stred in a public clud. Because cmprmise f a CSP culd result in unauthrized access t multiple data stres, it is recmmended that cryptgraphic keys used t encrypt/decrypt sensitive data be stred and managed independently frm the clud service where the data is lcated. At a minimum, key-management servers shuld be lcated in a separate netwrk segment and prtected with separate access credentials frm the VMs that are using the keys and the data encrypted with them. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

29 Only defined, authrized key custdians shuld have access t cryptgraphic keys. Because access t bth keys and encrypted data prvides the ability t decrypt the data, clients will need t verify wh has access t cryptgraphic keys, wh has access t the encrypted data, and wh has access t bth. If a client shares encryptin keys with the CSP, r engages the CSP as a key custdian, details f CSP access permissins and prcesses will als need t be reviewed and verified. This cnsideratin is particularly critical if cryptgraphic keys are stred r hsted by a third-party CSP that als hsts the encrypted data. If CSP persnnel have access t a client s keys and the client s encrypted data, the client may have unintentinally granted the CSP ability t decrypt their sensitive data. Any data that is decrypted in the clud may be inadvertently captured in clear text in prcess memry r VMs via clud maintenance functins (such as snapshts, backups, mnitring tls, etc.). T avid this risk, clients may chse t keep all encryptin/decryptin peratins and key management n their wn premises, and use a public clud nly fr strage f the encrypted data. Applicable cntrls must be applied t the encryptin, decryptin, and key-management prcesses t ensure data can nly be retrieved (decrypted) by thse wh are authrized with a defined business need. CSPs prviding cryptgraphic-key management services fr their clients shuld ensure that secret r private keys are nt shared amng clients each client shuld be prvided with a unique key r set f keys. Secure channels fr access t the clud envirnment als require prper key management. If the CSP uses images r clning fr prtecting VMs, it is strngly recmmended that keys nt be clned as part f the VM image each clne r VM instance shuld have its wn key(s) Decmmissining and Dispsal In additin t data dispsal, resurce decmmissining requirements shuld be defined t supprt clients future decisins t migrate t a new CSP, decmmissin their clud resurces, r mve ut f a clud envirnment altgether. The CSP shuld prvide data-dispsal mechanisms that prvide assurance t the client that all data has been securely remved and deleted frm the clud envirnment. Prcedures fr terminatin f service shuld be clearly defined and dcumented s may chse t ensure that all data is encrypted with strng cryptgraphy t reduce the risk t any residual data left behind n CSP systems. Hwever, clients shuld be aware that leaving ptentially unknwn quantities f encrypted data n CSP systems after their agreement has been terminated is likely t be a vilatin f their data-retentin plicy. 6.5 Technical Security Cnsideratins Technical security cnsideratins fr clud envirnments generally include all thse that apply t virtualizatin technlgies, as well as thse directly related t the different deplyment and service mdels Evlving Security Technlgies As mentined abve, virtualizatin security cnsideratins will als apply t clud envirnments. There are many industry resurces including the PCI DSS Virtualizatin Guidelines, available frm the PCI 7 The need fr unique hst keys has been well dcumented in a number f vendr technical papers. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

30 SSC website that discuss security cnsideratins fr the use f virtual technlgies. Sme f these cnsideratins include: It is difficult t maintain up-t-date, secure cnfiguratins n virtual machines when they are being activated and deactivated in rapid cycles virtual machines that are drmant fr any perid f time may be imprperly secured r intrduce security vulnerabilities when activated. Security and mnitring slutins fr virtual netwrks are still evlving and are nt as mature as thse available fr physical netwrks. Additinally, traditinal security sftware and security device functins ften d nt scale well t a clud envirnment. Fr example: Management f VM-t-VM traffic that des nt pass thrugh traditinal netwrk-based security cntrls may require the use f additinal hst-based security cntrls t mnitr and cntrl the traffic. Traditinal agent-based sftware security slutins that are nt designed fr virtualized envirnments may cause peratinal issues. Fr example, sftware agents, such as thse ften used fr anti-virus, each use a small percentage f memry and prcessing resurces; this can result in a large verhead when multiple agents are installed n multiple VMs n the same hst. Scheduled scans r updates ccurring simultaneusly acrss multiple VMs may result in an extreme lad n the underlying system and reduce verall perfrmance f all hsted VMs Identity and Access Management Individual user identificatin and authenticatin fr bth CSP and client persnnel is essential fr access cntrl and accuntability (see PCI DSS Requirements 7 and 8). Shared credentials (such as user accunts and passwrds) shuld nt be used in the CSP envirnment fr example, fr system administratin and maintenance nr shuld generic r shared accunts be assigned t r used by clients. The use f a single client credential that cvers multiple clud services fr that client is als a ptential cncern. Fr example, let s say a CSP issues a client with a user accunt and passwrd that has administratr privilege in ne envirnment and user-level privilege fr a separate, unrelated clud service. Cmprmise f the client s user-level accunt in the secnd envirnment culd therefre result in the attacker gaining administratr-level access t the first envirnment. accunts and passwrds shuld be unique fr each service, and any accunt with elevated privilege (such as administratr) shuld be restricted fr a specific service r functin, and nt used fr activities r access that d nt require such privilege Lgging and Audit Trails CSPs shuld be able t segregate lg data applicable fr each client and prvide it t each respective client fr analysis withut expsing lg data frm ther clients. Additinally, the ability t maintain an accurate and cmplete audit trail may require lgs frm all levels f the infrastructure, requiring invlvement frm bth the CSP and the client. Fr example, the CSP culd manage system-level, perating-system, and hypervisr lgs, while the client cnfigures lgging fr their wn VMs and The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

31 applicatins. In this scenari, the ability t assciate varius lg files int meaningful events wuld require crrelatin f client-cntrlled lgs and thse cntrlled by the CSP Hypervisr Access and Intrspectin In large clud envirnments it can be difficult t keep track f which hypervisrs are running which VMs, as VMs can be dynamically assigned acrss a pl f hypervisrs based upn lad balancing needs. Hypervisr cnfiguratin and access is particularly imprtant as it prvides a single pint f entry t all its VMs, and can ptentially be used t gain access t sensitive data and resurces n separate VMs. An additinal cnsideratin is the degree t which the hypervisr is used t deliver security functinality t the VMs. Fr example, a simple, hardened hypervisr may be very secure but ffer limited security capabilities, whereas a mre cmplex, security-capable hypervisr with imprved functinality culd ptentially present a greater risk if cmprmised 8. Functinality that allws the hypervisr t cntrl and mnitr individual VM activity frm utside the VMs is knwn as intrspectin 9. Hypervisr intrspectin expands the functinality f the hypervisr t allw a deeper analysis f the data being prcessed by the VM, and typically includes visibility int stred data files as well as mnitring f netwrk traffic, memry and prgram executin, and ther elements f the VM. Depending n the particular technlgy implemented, intrspectin can prvide the CSP with a level f real-time auditing f VM activity that may therwise be unattainable. This can help the CSP t mnitr fr and detect suspicius activity within and between VMs. Additinally, intrspectin may facilitate cludefficient implementatins f traditinal security cntrls fr example, hypervisr-managed security functins such as malware prtectin, access cntrls, firewalling and intrusin detectin between VMs. Tw ptential challenges with intrspectin are that it can bypass rle-based access cntrls and it can be used withut leaving a frensic audit trail within the VM itself. Fr example, t view a data file, a user typically authenticates t the VM, resulting in an authenticatin audit trail and ensuing the user s access is cntrlled accrding t their defined permissins. If file-access lgging is enabled in the VM and the user views a file, the access is recrded t shw what was accessed by whm and when. With intrspectin, files can be accessed frm within the privileged state f the hypervisr. As n authenticatin t the VM itself is required, file access leaves n audit trail n the VM and the VM cntains n evidence that the file was accessed. In this example, the access wuld need t be lgged via the intrspectin tl itself, which wuld typically nt be in the client s cntrl. While this may be less f an issue within a private clud envirnment, it is an imprtant cnsideratin fr clients f public clud services. Additinally, since intrspectin is designed t have full visibility int each VM, it may be difficult t restrict such access t nly specific files r prgrams in memry. Any persnnel (fr example, CSP emplyees r pssibly ther hsted clients) with access t the intrspectin functin culd ptentially have access t data and prcesses n any VM running n that hypervisr. Intrspectin access must therefre be carefully managed, cntrlled and mnitred t ensure that rle-based access and segregatin f duties 8 Dn t Blat the Hypervisr! What t knw abut Intrspectin (Webinar), Tim Mather A Virtual Machine Intrspectin Based Architecture fr Intrusin Detectin, Tal Garfinkel, Mendel Rsenblum The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

32 is maintained. Fr example, the ability t cnfigure intrspectin auditing shuld nt be available t persnnel with the ability t access hsted VMs via the intrspectin tl. CSPs using intrspectin shuld be able t prvide their clients with all applicable intrspectin lgs fr that client s envirnment including, but nt limited t, authenticatin details, disk and memry access requests, and API calls. All intrspectin activity shuld be mapped t the individual user accunt perfrming the activity, and lgs shuld be reviewed n a cntinual basis t ensure the integrity and cnfidentiality f client data has been maintained. Where intrspectin is used by a third-party CSP, the clients may wish t cnsider implementing datalevel security cntrls (such as strng cryptgraphy with all key strage and encryptin/decryptin peratins external t the clud service) t avid expsing sensitive data t the enhanced mnitring features that intrspectin prvides Security f Interfaces and APIs Applicatin prgramming interfaces (APIs) and ther sftware interfaces are an integral cmpnent f clud cmputing, supprting interperability and rapid delivery f clud services. APIs can be cnfigured t prvide access t a variety f functins, allwing clients and CSPs t interact and manage their interactins within the clud service. As web services and APIs are by nature publicly accessible, their security is critical t the security f the resurces they prvide access t. If nt prperly develped, managed, and secured, these interfaces can be explited r cmprmised, resulting in unexpected behavir and ptentially unauthrized access. Fr example, a prly-cded API culd result in weak authenticatin prtcls, pr access cntrls, and limited auditing capability. Such weaknesses culd lead t the expsure f authenticatin credentials and ther sensitive data. If the APIs are nt prperly secured, they culd als be explited r altered by an attacker t redirect data flws r alter applicatin behavir. APIs and ther public interfaces shuld be designed t prevent bth accidental misuse and malicius attempts t bypass security plicy. Strng authenticatin and access cntrls, strng cryptgraphy, and real-time mnitring are examples f cntrls that shuld be in place t prtect these interfaces Security f Systems systems used t access the clud envirnment shuld nt be verlked, as they culd ptentially becme a weak pint in a client s clud security strategy. rganizatins need t ensure their systems and internal prcesses d nt prvide unauthrized access t the clud envirnment. Fr example, if a client wrkstatin r ther device is cmprmised, an attacker may be able t use legitimate credentials and an authrized channel t gain access t the clud envirnment frm the cmprmised client system. The client will therefre need t ensure their client-side devices are apprpriately secured and prtected frm unauthrized physical and lgical access. -side systems used t access cardhlder data in the clud wuld als be in scpe fr all applicable PCI DSS requirements. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

33 6.5.7 Multi-tenancy In a multi-tenant clud envirnment, client rganizatins generally have n knwledge f the ther clients with whm they share resurces (fr example, virtual infrastructure, data stres, etc.), r hw ther clients are securing (r nt securing) their envirnments that access the shared resurces. Whether unsavry clients can pse a risk t ther clients using the same prvider will largely depend n the cntrls the CSP has in place t segregate clients frm ne anther, and t mnitr and detect suspicius activity n the shared infrastructure and between client envirnments. Befre engaging with a CSP, clients shuld cnsider hw the CSP verifies that their clients are wh they say they are, and hw the CSP detects ptentially suspicius behavir nce the clients are nbard. s shuld als ask the CSP what cntrls they have in place t ensure that the security psture f ne client cannt affect the security psture f anther client. 6.6 Incident Respnse and Investigatin s need t knw when an issue, incident, r breach has ccurred and the impact t their envirnment and/r t their data. Issues, incidents, and data breaches shuld be cmmunicated by the CSP in a timely manner. s shuld cnsider whether their CSP requires all clients t immediately ntify the CSP f ptential breaches in their envirnments, allwing the CSP t respnd mre quickly t cntain the breach and minimize its impact t ther clients. Definitins f what cnstitutes a breach r incident requiring ntificatin between client and clud prvider shuld be agreed. Ntificatin prcesses and timelines shuld be included in SLAs, and incident respnse plans shuld include ntificatin requirements. The ptential fr client data t be captured by third parties during a breach investigatin shuld als be clearly understd. Investigating ptential breaches in clud envirnments brings additinal challenges. Fr example, cmprmised VM instances may be deactivated befre anyne is aware that a breach ccurred. It may be nearly impssible t prperly investigate a breach when the surce f the breach is n lnger in use r even exists. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

34 7 Cnclusin In additin t the business and risk cnsideratins, the implementatin f security cntrls in a clud envirnment may require specialized technical knwledge and skills. It is therefre crucial that prir t migrating payment card peratins int a clud envirnment, an rganizatin engages their technical, legal, due diligence, infrmatin security, and cmpliance teams t wrk tgether t define the client s needs and evaluate ptential clud service fferings against thse needs. Regarding third-party r public cluds, clients shuld cnsider that while they can utsurce the day-t-day peratinal management f the data envirnment, they retain respnsibility fr the data they put in the clud. s are encuraged t shp arund until they find a CSP wh can prvide the level f security and assurance they require. Ptential clients are encuraged t: UNDERSTAND yur risk and security requirements first. CHOOSE a deplyment mdel that aligns with yur security and risk needs. EVALUATE different service ptins. KNOW what yu want frm yur CSP. COMPARE prviders and service fferings. ASK questins f the CSP and verify the respnses, fr example: What des each service cnsist f exactly, and hw is the service delivered? What des the service prvide with respect t security maintenance, PCI DSS cmpliance, segmentatin, assurance, and what is the client respnsible fr? Hw will the CSP prvide nging evidence that security cntrls cntinue t be in place and are kept up t date? What will the CSP cmmit t in writing? Are ther parties invlved in the service delivery, security, r supprt? DOCUMENT everything with yur prvider in written agreements fr example, SLAs / Terms f Service cntracts, etc. REQUEST written assurances that security cntrls will be in place and maintained. REVIEW the service and written agreements peridically t identify if anything has changed. CSPs are encuraged t wrk with their clients t understand their security and cmpliance needs. Bth parties shuld be willing t maintain pen cmmunicatin and mnitring t avid any misunderstandings r gaps in security respnsibilities. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

35 Appendix A: Sample PCI DSS Respnsibilities fr Different Service Mdels This Appendix expands n Figure 3 (in Sectin 4), and prvides examples 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. The descriptins in this table are intended t reflect the CSP s respnsibilities with respect t the services it prvides, and d nt cnsider the CSP s respnsibilities fr its internal infrastructure and peratins nt directly invlved in prviding services t their clients. Similarly, client respnsibilities d nt include cnsideratin fr the client systems used t access the clud service, r fr any client systems in scpe fr PCI DSS that are utside f the clud service. PCI DSS Requirements Requirement 1: Install and maintain a firewall cnfiguratin t prtect cardhlder data. Cmmn Cnsideratins IaaS: Typically, netwrk security is a shared respnsibility: the client is respnsible fr securing netwrks within and between their wn envirnments, while the CSP prvides netwrk security at the clud perimeter and between the CSP s clients. The CSP manages firewalls n the CSP-managed netwrk and any infrastructure firewalls nt visible t the clud custmer. Any firewalls abve the infrastructure layer may be the respnsibility f the clud custmer. The CSP-managed firewalls culd als be shared by multiple clud custmers. Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS PaaS: Firewalls abve the infrastructure layer may be the respnsibility f the clud custmer r CSP. The clud custmer culd be directly respnsible fr implementing and managing firewalls n the prvided platfrm, and/r they may define firewall and CSP and CSP CSP cnfiguratins, which the CSP then implements fr the custmer s envirnment. The CSP-managed firewalls culd als be shared with ther clud custmers. SaaS: The netwrk is whlly wned and managed by the CSP, and cnsequently, all firewall functins are typically managed by the CSP. In all scenaris, the client may still need t define, apprve and/r peridically review the services, prtcls, and prts permitted int their envirnment, even if the CSP is managing the firewalls in questin. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 33

36 PCI DSS Requirements Cmmn Cnsideratins Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS Requirement 2: IaaS: Secure cnfiguratin f OS and applicatins is typically respnsibility f the client D nt use vendr-supplied defaults fr system passwrds and ther security parameters while secure cnfiguratin f underlying devices is the respnsibility f CSP. There may als be virtual devices that custmer is respnsible fr maintaining. PaaS: The OS is ften cntrlled by CSP but sme services may include a level f client access t OS bth parties will need t clarify which entity is applying secure cnfiguratin and hardening at the OS level. Applicatins and sftware abve the OS are likely t be cntrlled by the client. Secure cnfiguratin f netwrk devices will be and CSP and CSP CSP managed by the CSP. SaaS: The CSP typically manages cnfiguratin and hardening f all devices, OS and applicatins. Requirement 3: IaaS and PaaS: The client is generally respnsible fr the manner in which infrmatin Prtect stred cardhlder data is secured (such as the use f encryptin mechanisms) and in what frmat fr example, flat files, databases entries etc. Physical lcatins f the infrmatin stres might be unknwn t the client, and strage lcatins may need t be identified. Data retentin is defined by the client; hwever the CSP cntrls the actual strage areas. The use f cntrls t prevent unintended r additinal retentin (fr example, via snapshts, backups, etc.) als needs t be cnsidered. and CSP and CSP CSP SaaS: Typically cntrlled and managed by the CSP as part f the predefined service. The CSP may als define the retentin perids. s may have very little t n cntrl ver hw r where their data, including CHD, is stred. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 34

37 PCI DSS Requirements Cmmn Cnsideratins Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS Requirement 4: IaaS and PaaS: Mechanisms fr transmissin are typically cntrlled by the client while Encrypt transmissin f cardhlder data acrss pen, public netwrks the underlying technlgy is managed by the CSP; hwever, this will depend n the technlgies in use. Cntrls t prevent unintended transmissin f data utside f client envirnment are generally maintained by the CSP, depending n the particular service. The client shuld be aware f hw data is transmitted between cmpnents in rder t ensure data is encrypted fr all transmissins ver nn-private channels. This may include transmissins within the client s wn envirnment (fr example, between client VMs). and CSP CSP SaaS: The CSP retains full cntrl ver transmissin mechanisms. The client has little t n cntrl ver hw r where data is transmitted within the clud envirnment. The client is respnsible fr ensuring clear-text data is nt passed t the CSP fr transmissin t public netwrks r untrusted envirnments (such as ther clud clients). Requirement 5: IaaS: Prtectin f the OS and client VMs is typically the respnsibility f client. Anti- Use and regularly update anti-virus sftware r prgrams virus updates apply t the hst OS as well as any VMs in the client envirnment running their wn OS. There may als be virtual devices that the client is respnsible fr keeping up t date. Anti-malware prtectin fr underlying devices/infrastructure remains the respnsibility f the CSP. PaaS: Generally managed by whever cntrls the OS; sme PaaS services include and CSP CSP client respnsibility fr OS maintenance. Anti-virus updates will apply t the underlying OS as well as any VMs in the client envirnment running their wn OS. SaaS: The CSP typically manages the security and anti-virus fr the envirnment. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 35

38 PCI DSS Requirements Requirement 6: Develp and maintain secure systems and applicatins Cmmn Cnsideratins IaaS: Patching and maintenance f OS and applicatins are typically the respnsibility f the client, while patching and maintenance f underlying devices remains the respnsibility f the CSP. There may als be virtual devices that the client is respnsible fr maintaining. Secure cding is typically the client s respnsibility (they may either use their wn applicatins r chse secure cmmercial applicatins). Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS PaaS: Patching and maintenance f underlying devices remains the respnsibility f the CSP. OS patching and maintenance may als be cntrlled by CSP; hwever, sme PaaS services include client respnsibility fr OS maintenance entities will need t determine which party is respnsible fr applying patches/updates. If the CSP prvides patching, the client shuld verify that patches are deplyed in a timely manner. Patching f applicatins is typically managed by the client, depending n the service and and CSP and CSP and CSP agreements. Secure cding f applicatin is the respnsibility f whever develps/cntrls the applicatins, which may be either the client r the CSP, and may vary fr different applicatins. SaaS: The client may cntrl r manage the APIs r they may share respnsibility with the CSP. The CSP typically manages patching and updates f all devices, OS, and applicatins, and is als respnsible fr secure cding f sftware; hwever, the client shuld verify that patches are deplyed in a timely manner. Requirement 7: IaaS and PaaS: Generally the client is respnsible fr defining access t their data files. Restrict access t cardhlder data by business need t knw Physical lcatin f the infrmatin stres might be unknwn t the client and may need t be identified. The CSP cntrls the physical strage areas, and CSP-managed access cntrls are ften cumulative t the client-defined cntrls. The use f cntrls t prevent unintended access t data (fr example, t data captured via snapshts, backups, etc.) shuld als be cnsidered. and CSP and CSP and CSP SaaS: The client defines data access needs fr their wn persnnel; hwever, access t data is ultimately cntrlled by CSP. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 36

39 PCI DSS Requirements Requirement 8: Assign a unique ID t each persn with cmputer access Cmmn Cnsideratins IaaS and PaaS: The client is respnsible fr ensuring all accunts under their cntrl use unique IDs and strng authenticatin. The CSP is respnsible fr ensuring strng authenticatin is used fr the underlying infrastructure. Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS Cmpared t the IaaS mdel, the CSP retains significant administrative access rights In SaaS and PaaS mdels. SaaS: The CSP has ultimate cntrl f accunts at all levels. Depending n the and CSP and CSP and CSP particular service, the client may have the ability t create user-level accunts within the applicatin r service, r they may be assigned user accunts that the CSP maintain n their behalf. The client is respnsible fr ensuring all the accunts they use have strng passwrds. Requirement 9: Restrict physical access t cardhlder data All service mdels: Generally managed by the CSP fr all service mdels. The client rarely has any physical access t clud systems; and the CSP might nt permit nsite visits r client audits. This will depend n the particular CSP as well as the distributin f data acrss different lcatins; the clients may nt knw which lcatin huses their data. CSP CSP CSP Requirement 10: IaaS and PaaS: The CSP typically manages mnitring and lgging fr underlying Track and mnitr all access t netwrk resurces and cardhlder data devices and infrastructure, including hypervisrs, while the client is respnsible fr mnitring and lgging within their wn virtual envirnments. The ability t assciate varius lg files in rder t recnstruct events may require crrelatin between clientcntrlled lgs and thse cntrlled by the CSP. Sme mnitring activities may be built int the service agreement fr the CSP t manage n behalf f clients. Details f what data will be captured and what will be made and CSP and CSP CSP available t the client will need t be defined. SaaS: The client typically relies n the CSP fr all mnitring and lgging, but may have limited applicatin-level lgging such as user lgn/lgff, accunt management, and basic reprting. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 37

40 PCI DSS Requirements Cmmn Cnsideratins Example respnsibility assignment fr management f cntrls IaaS PaaS SaaS Requirement 11: IaaS and PaaS: Testing is generally managed by whever has cntrl f the particular Regularly test security systems and prcesses aspect f the envirnment. Hwever, CSPs may prhibit client testing, in which case clients may need t rely n the CSP. If the CSP is perfrming scans, the client needs t verify which instances/vms are cvered. IDS/IPS may nt be prvided by the CSP. Generally the client can use FIM t mnitr their wn virtual envirnments (including data, applicatins, and lgs), while mnitring f system/device files is managed by the and CSP and CSP CSP CSP. SaaS: The client desn t have visibility r permissin t perfrm scans and typically relies n the CSP fr all scans, testing, and mnitring. Requirement 12: All service mdels: While the CSP and client may define agreed-upn prcedures (fr Maintain a plicy that addresses infrmatin security fr all persnnel example, in the SLA), each party maintains their wn security plicies and internal prcedures. Defined rles and respnsibilities, training, and persnnel security requirements are the respnsibility f each party fr their respective persnnel. s shuld ensure that the CSP plicies and prcedures are apprpriate fr the and CSP and CSP and CSP client s risk and security needs. Incident respnse in particular requires awareness and crdinatin between bth parties. Appendix A: Additinal PCI DSS Requirements fr Shared Hsting Prviders The requirements fr shared hsting prviders t ensure separatin between clients apply t third-party prvided clud services. CSP CSP CSP The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 38

41 Appendix B: Sample Inventry This appendix prvides an example inventry fr cmpnents used in clud envirnments. Use f an inventry can help t identify the types f cmpnents invlved in delivery f the service and respnsibly fr securing them. This example is nt intended t be applicable t any particular scenari, and is intended t prvide a starting pint fr scping discussins between clients and CSPs. When preparing an inventry, cnsider the fllwing: The type f infrmatin cllected shuld be relevant fr the client s business needs as well as the CSP s The level f detail cllected shuld be apprpriate fr bth parties t reach a clear understanding f the cmpnents invlved, their use, and wh manages/secures them. Type/Layer Cmpnent Descriptin/Purpse Type f Cmpnent Number f cmpnents Implementatin Ntes Respnsibility fr securing cmpnent Nte: Actual layers will vary Fr example: Fr example: Number f cmpnents Defined usage, lcatin, Fr example: depending n structure f Firewall, OS, applicatin, Is cmpnent physical, used in relatin t client s etc., as applicable CSP nly, client nly, CSP service fferings web server, hypervisr, lgical r virtual? service r shared ruter, database, etc. Static r dynamic? Data Interfaces APIs/GUIs Applicatins Prgramming stack Operating Systems Virtual Machines Virtual netwrking Hypervisrs The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 39

42 Type/Layer Cmpnent Descriptin/Purpse Type f Cmpnent Number f cmpnents Implementatin Ntes Respnsibility fr securing cmpnent Nte: Actual layers will vary Fr example: Fr example: Number f cmpnents Defined usage, lcatin, Fr example: depending n structure f Firewall, OS, applicatin, Is cmpnent physical, used in relatin t client s etc., as applicable CSP nly, client nly, CSP service fferings web server, hypervisr, lgical r virtual? service r shared ruter, database, etc. Static r dynamic? Prcessing/Memry Data Strage Netwrk devices Physical facilities Nte: This is intended as a general example nly. It may be necessary t rerganize the different technlgy layers r define additinal cmpnent characteristics as applicable t a particular envirnment. Additinally, entities may wish t identify respnsibilities fr each system cmpnent in greater detail than prvided fr here. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 40

43 Appendix C: Sample PCI DSS Respnsibility Matrix A PCI DSS respnsibility matrix may help t clarify and cnfirm hw respnsibilities fr maintaining PCI DSS requirements are shared between the client and CSP. Respnsibilities shuld always be defined in written agreements. Cnsideratins fr each PCI DSS requirement include: Des the CSP perfrm/manage/maintain the required cntrl? Hw is the cntrl implemented, and what are the supprting prcesses? (E.g., prcess fr patch updates wuld include details f testing, scheduling, apprvals, etc.) What layers f the clud architecture are cvered by the CSP fr the requirement? What layers f the architecture are nt cvered by the CSP and are specifically the respnsibility f the client? Hw will the CSP prvide nging assurance and/r evidence t the client that cntrls are met? (Fr example, peridic reprts, real-time ntificatins, results f testing, etc.) PCI DSS Requirement Respnsibility (CSP nly, client nly, r shared) Specific cverage/ scpe f client respnsibly Specific cverage/ scpe f CSP respnsibility Hw and when CSP will prvide evidence f cmpliance t 1.1 Establish firewall and ruter cnfiguratin standards that include the fllwing: A frmal prcess fr apprving and testing all netwrk cnnectins and changes t the firewall and ruter cnfiguratins A frmal prcess fr apprving and testing all netwrk cnnectins and changes t the firewall and ruter cnfiguratins Current netwrk diagram with all cnnectins t cardhlder data, including any wireless netwrks The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 41

44 PCI DSS Requirement Respnsibility (CSP nly, client nly, r shared) Specific cverage/ scpe f client respnsibly Specific cverage/ scpe f CSP respnsibility Hw and when CSP will prvide evidence f cmpliance t Requirements fr a firewall at each Internet cnnectin and between any demilitarized zne (DMZ) and the internal netwrk zne Descriptin f grups, rles, and respnsibilities fr lgical management f netwrk cmpnents 1.2 Build firewall and ruter cnfiguratins that restrict cnnectins between untrusted netwrks and any system cmpnents in the cardhlder data envirnment. Nte: An untrusted netwrk is any netwrk that is external t the netwrks belnging t the entity under review, and/r which is ut f the entity's ability t cntrl r manage Restrict inbund and utbund traffic t that which is necessary fr the cardhlder data envirnment Secure and synchrnize ruter cnfiguratin files. And s n. Nte: This is intended as an example nly t prvide a starting pint fr discussins between clients and CSPs. It is nt intended as a requirement r an extensin f PCI DSS cmpliance respnsibilities. Hwever, it may prvide a useful tl t help t clarify respnsibilities in agreements between clients and prviders. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 42

45 Appendix D: PCI DSS Implementatin Cnsideratins The questins in this appendix are intended as suggestins t help start cnversatins between clients and CSPs in rder t understand the characteristics f a particular clud envirnment, which may in turn help determine if and hw PCI DSS requirements can be met in that envirnment. These questins alne will nt determine whether r nt applicable PCI DSS requirements can be met, hwever, they may be a useful additin t questins directly related t specific PCI DSS requirements. Infrmatin in this table incrprates guidance frm the fllwing surces: CSA Cnsensus Assessments Initiative Questinnaire ENISA Infrmatin Assurance Requirements Please als refer t the PCI DSS Virtualizatin Guidelines fr additinal PCI DSS cnsideratins fr virtualizatin technlgies. PCI DSS Requirement Build and Maintain a Secure Netwrk 1: Install and maintain a firewall cnfiguratin t prtect cardhlder data 2: D nt use vendr-supplied defaults fr system passwrds and ther security parameters Hw is separatin between tenants assured? Cnsideratins fr Clud Envirnments Hw are bundaries enfrced between trusted (internal t the client) netwrks and untrusted netwrks (such as CSP, ther client, r public-facing netwrks)? Are physical r virtual firewalls used? Wh manages and audits firewall cnfiguratins? Hw are changes t firewall and netwrk cnfiguratins tracked and managed? What technlgies are used in the prvisin f the clud service e.g., hardware, sftware, virtual technlgies? Is there a current list f all hardware and sftware cmpnents in the envirnment? Can the actual cmpnents used by a particular client be identified? Hw are cnfiguratin standards assured n different cmpnents f the infrastructure? Are API interfaces standardized? What is the prcess fr prvisining new cmpnents? Are virtual images hardened befre being enabled? Are hardened images prtected frm unauthrized access? Hw are systems with high security classificatins segregated frm systems with lw security classificatins? Hw are shared resurces (such as prcessing, memry, and strage) managed t ensure they cannt be manipulated fr example by verlading in rder t gain access t ther client envirnments r data? The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 43

46 PCI DSS Requirement Prtect Cardhlder Data 3: Prtect stred cardhlder data 4: Encrypt transmissin f cardhlder data acrss pen, public netwrks Maintain a Vulnerability Management Prgram 5: Use and regularly update antivirus sftware r prgrams 6: Develp and maintain secure systems and applicatins Cnsideratins fr Clud Envirnments Where are the knwn data strage lcatins? Where are data centers lcated? Which legal jurisdictin(s) applies t client data? Des the CSP have any business, legal r regulatry requirements that culd impact retentin f client data? Hw is access t client data restricted t nly that client s users and applicatins? Hw are VM images, snapshts, and backups managed t prevent unnecessary capture f sensitive data? Hw is data securely deleted frm memry and stred images? Will data remnants exist in terminated VMs? If cryptgraphic keys are prvided by CSP, are unique keys generated fr each client? Where are encryptin/decryptin prcesses being perfrmed? Wh cntrls each prcess? Where are cryptgraphic keys stred, and wh cntrls the keys? Are data-encryptin keys stred and managed separately frm the data they prtect? Where is encrypted data stred, and wh has access t the keys and encrypted data? Hw is security and access defined fr the virtualized resurces used fr generatin f cryptgraphic keys? What prcess is fllwed in the event f a suspected key cmprmise? Is all client data securely purged frm all CSP systems upn terminatin f the agreement? Hw are cmmunicatins secured between client and ther envirnments? Hw are cmmunicatins secured within the clud itself? Are APIs cnfigured t enfrce strng cryptgraphy and authenticatin? Is mutual authenticatin implemented between CSP and client systems? Are VMs prtected frm within the VM r frm the hypervisr? Hw are VM images (including inactive and replicated VMs) ensured t have up-t-date anti-malware and patches befre they are enabled fr use? Hw are patches managed (e.g., priritized, tested, apprved, and deplyed), fr bth underlying CSP systems and prvisined client envirnments? What is the prcess fr each layer f the clud service e.g., physical netwrk devices, hst perating systems, hypervisrs, virtualized cmpnents (including VMs, virtual netwrk devices), applicatins, etc.? Hw are APIs and web services prtected frm vulnerabilities? Are standardized interfaces and cding languages used? Hw are develpment/test systems and data prevented frm being inadvertently migrated int prductin envirnments, and vice versa (e.g., thrugh virtual replicatin, imaging in r snapsht mechanisms)? The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 44

47 PCI DSS Requirement Implement Strng Access Cntrl Measures 7: Restrict access t cardhlder data by business need t knw 8: Assign a unique ID t each persn with cmputer access 9: Restrict physical access t cardhlder data Hw is user authenticatin applied at different levels? Cnsideratins fr Clud Envirnments Hw are layers f access cntrls managed t ensure the aggregate access is nt mre than intended? Which CSP persnnel have ability t access client data? Hw are CSP privilege assignments reviewed and mnitred? Hw is segregatin f duties maintained (fr example, between administrative and auditing functins)? Is administrative access t systems r hypervisr separate frm access t client VMs and data stres? Are separate credentials used fr different security functins? Hw are least-privilege and need-t-knw determined fr CSP persnnel? Hw are credentials de-prvisined? Des de-prvisining apply acrss all gegraphically distributed lcatins? Culd de-prvisined credentials be retained in ffline images? Is remte access fr CSP persnnel permitted frm untrusted netwrks? Are cntrls in place t prevent the capture f passwrds in active memry, and t ensure that virtualized images d nt cntain authenticatin credentials? Is tw-factr authenticatin required fr client access? Des the CSP use any shared passwrds (e.g., fr maintenance)? Des the CSP maintain direct wnership and cntrl ver all data strage systems and facilities? Wh has physical access t data centers and systems? Hw are data-strage systems prtected frm physical r direct cnsle access? Hw are backups f VMs and data secured? Hw is physical media inventried, secured, mnitred, and tracked? Is media re-used? Hw is data permanently remved frm end-f-life r reusable media? The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 45

48 PCI DSS Requirement Regularly Mnitr and Test Netwrks 10: Track and mnitr all access t netwrk resurces and cardhlder data 11: Regularly test security systems and prcesses Cnsideratins fr Clud Envirnments Hw are activities traced back t individual client persnnel r individual CSP persnnel? Can the specific system cmpnents used by a client at a particular time be identified? What types f events are recrded in audit lgs? Hw are audit lgs crrelated between client envirnments (such as a VM image) and CSP infrastructure (such as the hypervisr r underlying system)? Hw are audit lgs mnitred and reviewed? Hw are clcks synchrnized between virtual instances and underlying systems/hardware? Hw is testing fr wireless technlgies perfrmed and managed? Hw are all variatins f VM images (including inactive VMs) scanned fr vulnerabilities? What defenses are in place t prtect against internal attacks (riginating frm CSP s r ther client netwrk) and external attacks (riginating frm the Internet r ther public netwrk)? Is penetratin testing perfrmed acrss different layers f the envirnment (e.g., between VMs and the CSP s management netwrk, r between clients n shared infrastructure)? Hw is security testing managed fr CSP infrastructure vs. client envirnments? What testing are clients allwed t perfrm n their internet-facing systems? Hw are clients prevented frm perfrming penetratin testing n ther clients envirnments? The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 46

49 PCI DSS Requirement Maintain an Infrmatin Security Plicy 12: Maintain a plicy that addresses infrmatin security fr all persnnel Appendix A: Additinal PCI DSS Requirements fr Shared Hsting Prviders Hw des the CSP identify ptential risks? Cnsideratins fr Clud Envirnments Are clients ntified upn changes t the CSP s security and/r privacy plicies? Des the CSP have mechanisms in place t ensure secure peratinal prcedures are fllwed? Hw des the CSP screen persnnel? Are different levels f screening used fr different rles r regins? Des screening cver all persnnel with physical access t data centers at all lcatins? Des the CSP utsurce any aspect f the clud service t ther prviders (e.g., data strage, security services, etc.)? What measures are taken t ensure that the CSP s security plicies are maintained by their third-party prviders? What prcesses are in place t detect, assess, escalate, and respnd t ptential breaches? What mechanisms are in place fr clients t reprt a suspected breach? What criteria are used t define whether an incident r a breach has actually ccurred? What ntificatins are prvided and when? Hw wuld a breach at ne client impact ther clients n the same infrastructure? Hw is evidence cllected, managed, and shared? What happens t client data in the event f a breach t CSP systems? Can a client s data be cllected as part f anther client s (r CSP s) breach investigatin (either by authrities r third party investigatrs)? Are disaster-recvery prcesses, systems and facilities implemented with the same security cntrls as prductin envirnments? Hw is islatin maintained acrss different layers, including between virtual machines, physical machines, netwrks, strage systems (e.g., strage area netwrks), management netwrks and supprt systems? What cntrls are in place t prevent data leakage between clients, and between client and CSP? Are resurce-islatin mechanisms in place? The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace r supersede requirements in any PCI SSC Standard 47

50 Acknwledgements PCI SSC wuld like t acknwledge the cntributin f the Clud Special Interest Grup (SIG) in the preparatin f this dcument. The Clud SIG cnsists f representatives frm the fllwing rganizatins: Accuvant, Inc. Acertig AG Anitian Enterprise Security Assurant, Inc. AT&T Cnsulting Inc. Bank f America Glbal Infrmatin Security PCI Adherence BrightLine CPAs & Assciates Inc. BT Plc. Capita Plc. Citi CludPassage Calfire Cmputer Services, Inc. Cmsec Cnsulting Ltd. Crwe Hrwath LLP DataPipe Delitte New Zealand Diebld, Inc. Direct Insite Crp. Dllar Thrifty Autmtive Grup, Inc. Equinx Payments, LLC FishNet Security, Inc. Frt Cnsult A/S (Denmark) Habif, Argeti & Wynne LLP HP Infrmatin Security UK Ltd Hytrust, Inc Infrmatin Risk Management Plc. Integralis Ltd Internatinal Cards Prcessing Services Internet Security Auditrs IOActive, Inc. IQ Infrmatin Quality Kilrush Cnsultancy Ltd. Kingstn Smith Cnsulting LLP Knwit Secure AB KPMG, LLP Layered Tech Liaisn Technlgies Inc. McGladrey LLP Market America, Inc. Merchant Link Micrsft Natinwide Building Sciety PathMaker Grup PayPrs PricewaterhuseCpers LLP Privity Systems Inc. Prtiviti Retalix RightScale Ryal Bank f Sctland SecurityMetrics, Inc. Sense f Security Pty Ltd. Specsavers Structured Cmmunicatins Systems, Inc. Tesc Plc. Thales e-security Trend Micr Inc. TrustNet Trustwave The UK Cards Assciatin University f Nrth Carlina at Chapel Hill Vanguard Integrity Prfessinals Venda VendrSafe Technlgies, LLC. VeriFne UK & Ireland Services Ltd. Verizn Enterprise Slutins Verizn Wireless WEX Inc. Wlwrths Limited The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

51 References This dcument draws the fllwing additinal surces f reference. These surces are recmmended as additinal guidance n securing clud-cmputing envirnments. Surce 10 Clud Security Alliance (CSA) Eurpean Netwrk and Infrmatin Security Agency (ENISA) Natinal Institute f Standards and Technlgy (NIST) Infrmatin Cmmissiners Office (ICO) ISACA ISC2 Internatinal Infrmatin Systems Security Certificatin Cnsrtium, Inc., The Open Web Applicatin Security Prject (OWASP) Clud Cmputing Security Research Library PCI SSC Reference Security Guidance fr Critical Areas f Fcus in Clud Cmputing v3.0 Hw t d PCI DSS in the Clud (Curseware) Tp Threats t Clud Cmputing V1.0 Cnsensus Assessments Initiative Questinnaire v1.1 Hypervisr vs. Hst Based Security Clud Cmputing Benefits, risks and recmmendatins fr infrmatin security The NIST Definitin f Clud Cmputing (S P ) Clud Cmputing Synpsis and Recmmendatins (SP ) Guidelines n Security and Privacy in Public Clud Cmputing (SP ) NIST Clud Cmputing Reference Architecture (SP ) Guidance n the use f clud cmputing Clud Cmputing Management Audit/Assurance Prgram Meeting PCI DSS When Using a Clud Service Prvider Security in the Skies Clud cmputing security cncerns, threats, and cntrls OWASP Clud-10 Prject Rbert Zigweid Webinars: Cllisin Curse: PCI Data and the Clud Security Rle Play: Merchants and Clud Service Prviders Tls t Assess PCI Cmpliance in Clud Technical Guide n Cmpliance and Clud Security PCI DSS Virtualizatin Guidelines Webinar / varius surces Dn t Blat the Hypervisr. What t knw abut Intrspectin (Webinar Links t third party websites are subject t change The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace

52 Abut the PCI Security Standards Cuncil The PCI Security Standards Cuncil is an pen glbal frum that is respnsible fr the develpment, management, educatin, and awareness f the PCI Data Security Standard (PCI DSS) and ther standards that increase payment data security. Funded in 2006 by the majr payment card brands American Express, Discver Financial Services, JCB Internatinal, MasterCard Wrldwide, and Visa Inc., the Cuncil has ver 600 Participating Organizatins representing merchants, banks, prcessrs, and vendrs wrldwide. T learn mre abut playing a part in securing payment card data glbally, please visit: pcisecuritystandards.rg. The intent f this dcument is t prvide supplemental infrmatin. Infrmatin prvided here des nt replace