pci_dss_v1-2 (Статьи, стандарты, спецификации), страница 12

Be prepared torespond immediately to a systembreach.In PlaceNot inPlaceTarget Date/Comments12.9Obtain and examine the Incident Response Planand related procedures and perform the following:(12.9 continued on next page)PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 56PCI DSS RequirementsTesting Procedures12.9.1 Create the incidentresponse plan to be implemented inthe event of system breach. Ensurethe plan addresses the following, ata minimum:ƒ Roles, responsibilities, andcommunication and contactstrategies in the event of acompromise includingnotification of the paymentbrands, at a minimumƒ Specific incident responseproceduresƒ Business recovery andcontinuity proceduresƒ Data back-up processesƒ Analysis of legal requirementsfor reporting compromisesƒ Coverage and responses of allcritical system componentsƒ Reference or inclusion ofincident response proceduresfrom the payment brands12.9.1 Verify that the Incident Response Plan includes:ƒRoles, responsibilities, and communicationstrategies in the event of a compromise includingnotification of the payment brands, at a minimumƒSpecific incident response procedures,ƒBusiness recovery and continuity procedures,ƒData back-up processesƒAnalysis of legal requirements for reportingcompromises (for example, California Bill 1386which requires notification of affected consumersin the event of an actual or suspectedcompromise for any business with Californiaresidents in their database)ƒCoverage and responses for all critical systemcomponentsƒReference or inclusion of incident responseprocedures from the payment brands12.9.2 Test the plan at leastannually.12.9.2 Verify that the plan is tested at least annually.12.9.3 Designate specificpersonnel to be available on a 24/7basis to respond to alerts.12.9.3 Verify through observation and review of policies,that there is 24/7 incident response and monitoringcoverage for any evidence of unauthorized activity,detection of unauthorized wireless access points, criticalIDS alerts, and/or reports of unauthorized critical systemor content file changes.12.9.4 Provide appropriate trainingto staff with security breachresponse responsibilities.12.9.4 Verify through observation and review of policiesthat staff with security breach responsibilities areperiodically trained.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCIn PlaceNot inPlaceTarget Date/CommentsOctober 2008Page 57PCI DSS RequirementsTesting Procedures12.9.5 Include alerts from intrusiondetection, intrusion-prevention, andfile-integrity monitoring systems.12.9.5 Verify through observation and review ofprocesses that monitoring and responding to alerts fromsecurity systems including detection of unauthorizedwireless access points are covered in the IncidentResponse Plan.12.9.6 Develop process to modifyand evolve the incident responseplan according to lessons learnedand to incorporate industrydevelopments.12.9.6 Verify through observation and review of policiesthat there is a process to modify and evolve the incidentresponse plan according to lessons learned and toincorporate industry developments.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCIn PlaceNot inPlaceTarget Date/CommentsOctober 2008Page 58Appendix A: Additional PCI DSS Requirements for Shared Hosting ProvidersRequirement A.1: Shared hosting providers must protect the cardholder data environmentAs referenced in Requirement 12.8, all service providers with access to cardholder data (including shared hosting providers) must adhere to thePCI DSS.

In addition, Requirement 2.4 states that shared hosting providers must protect each entity’s hosted environment and data. Therefore,shared hosting providers must additionally comply with the requirements in this Appendix.RequirementsA.1Protect each entity’s (that ismerchant, service provider, or otherentity) hosted environment and data,per A.1.1 through A.1.4:A hosting provider must fulfill theserequirements as well as all otherrelevant sections of the PCI DSS.Note: Even though a hosting providermay meet these requirements, thecompliance of the entity that uses thehosting provider is not guaranteed.Each entity must comply with the PCIDSS and validate compliance asapplicable.A.1.1 Ensure that each entity onlyruns processes that have access tothat entity’s cardholder dataenvironment.Testing ProceduresIn PlaceNot inPlaceTarget Date/CommentsA.1Specifically for a PCI DSS assessment of a sharedhosting provider, to verify that shared hosting providersprotect entities’ (merchants and service providers) hostedenvironment and data, select a sample of servers(Microsoft Windows and Unix/Linux) across arepresentative sample of hosted merchants and serviceproviders, and perform A.1.1 through A.1.4 below.A.1.1 If a shared hosting provider allows entities (forexample, merchants or service providers) to run theirown applications, verify these application processes runusing the unique ID of the entity.

For example:ƒ No entity on the system can use a shared webserver user ID.ƒ All CGI scripts used by an entity must be createdand run as the entity’s unique user ID.PCI DSS Requirements and Security Assessment Procedures, v1.2Appendix A: Additional PCI DSS Requirements for Shared Hosting ProvidersOctober 2008Page 59RequirementsA.1.2 Restrict each entity’s accessand privileges to own cardholderdata environment only.Testing ProceduresIn PlaceNot inPlaceTarget Date/CommentsA.1.2.a Verify the user ID of any application processis not a privileged user (root/admin).A.1.2.b Verify each entity (merchant, serviceprovider) has read, write, or execute permissions onlyfor files and directories it owns or for necessary systemfiles (restricted via file system permissions, accesscontrol lists, chroot, jailshell, etc.).

IMPORTANT: Anentity’s files may not be shared by group.A.1.2.c Verify an entity’s users do not have writeaccess to shared system binaries.A.1.2.d Verify that viewing of log entries is restrictedto the owning entity.A.1.2.e To ensure each entity cannot monopolizeserver resources to exploit vulnerabilities (for example,error, race, and restart conditions, resulting in, forexample, buffer overflows), verify restrictions are inplace for the use of these system resources:ƒ Disk spaceƒ Bandwidthƒ Memoryƒ CPUA.1.3 Ensure logging and audittrails are enabled and unique toeach entity’s cardholder dataenvironment and consistent withPCI DSS Requirement 10.A.1.3.a Verify the shared hosting provider hasenabled logging as follows, for each merchant andservice provider environment:ƒ Logs are enabled for common third-partyapplications.ƒ Logs are active by default.ƒ Logs are available for review by the owningentity.ƒ Log locations are clearly communicated to theowning entity.A.1.4 Enable processes to providefor timely forensic investigation inthe event of a compromise to anyhosted merchant or serviceprovider.A.1.4Verify the shared hosting provider has writtenpolicies that provide for a timely forensics investigationof related servers in the event of a compromise.PCI DSS Requirements and Security Assessment Procedures, v1.2Appendix A: Additional PCI DSS Requirements for Shared Hosting ProvidersOctober 2008Page 60Appendix B: Compensating ControlsCompensating controls may be considered for most PCI DSS requirements when an entity cannot meet arequirement explicitly as stated, due to legitimate technical or documented business constraints, but hassufficiently mitigated the risk associated with the requirement through implementation of other, orcompensating, controls.Compensating controls must satisfy the following criteria:1.

Meet the intent and rigor of the original PCI DSS requirement.2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensatingcontrol sufficiently offsets the risk that the original PCI DSS requirement was designed to defendagainst. (See Navigating PCI DSS for the intent of each PCI DSS requirement.)3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCIDSS requirements is not a compensating control.)When evaluating “above and beyond” for compensating controls, consider the following:Note: The items at a) through c) below are intended as examples only.

All compensatingcontrols must be reviewed and validated for sufficiency by the assessor who conducts the PCIDSS review. The effectiveness of a compensating control is dependent on the specifics of theenvironment in which the control is implemented, the surrounding security controls, and theconfiguration of the control. Companies should be aware that a particular compensatingcontrol will not be effective in all environments.a) Existing PCI DSS requirements CANNOT be considered as compensating controls if they arealready required for the item under review. For example, passwords for non-consoleadministrative access must be sent encrypted to mitigate the risk of intercepting clear-textadministrative passwords.

An entity cannot use other PCI DSS password requirements (intruderlockout, complex passwords, etc.) to compensate for lack of encrypted passwords, since thoseother password requirements do not mitigate the risk of interception of clear-text passwords. Also,the other password controls are already PCI DSS requirements for the item under review(passwords).b) Existing PCI DSS requirements MAY be considered as compensating controls if they are requiredfor another area, but are not required for the item under review.

For example, two-factorauthentication is a PCI DSS requirement for remote access. Two-factor authentication from withinthe internal network can also be considered as a compensating control for non-consoleadministrative access when transmission of encrypted passwords cannot be supported. Twofactor authentication may be an acceptable compensating control if; (1) it meets the intent of theoriginal requirement by addressing the risk of intercepting clear-text administrative passwords;and (2) it is set up properly and in a secure environment.c) Existing PCI DSS requirements may be combined with new controls to become a compensatingcontrol.

For example, if a company is unable to render cardholder data unreadable perrequirement 3.4 (for example, by encryption), a compensating control could consist of a device orcombination of devices, applications, and controls that address all of the following: (1) internalnetwork segmentation; (2) IP address or MAC address filtering; and (3) two-factor authenticationfrom within the internal network.4.

Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirementThe assessor is required to thoroughly evaluate compensating controls during each annual PCI DSSassessment to validate that each compensating control adequately addresses the risk the original PCIDSS requirement was designed to address, per items 1-4 above. To maintain compliance, processes andcontrols must be in place to ensure compensating controls remain effective after the assessment iscomplete.PCI DSS Requirements and Security Assessment Procedures, v1.2Appendix B: Compensating ControlsOctober 2008Page 61Appendix C: Compensating Controls WorksheetUse this worksheet to define compensating controls for any requirement where compensating controlsare used to meet a PCI DSS requirement.