Akamai Technologies Inc. Responsibility Matrix PCI-DSS 3.0 Requirement 12.8.2
Table of Contents Purpose... 2 Overview... 2 Disclaimer... 2 Responsibility Matrix... 3
Purpose Akamai provides below a detailed matrix of PCI DSS controls, including the description of responsibility for each individual control. Overview Akamai s Secure Content Delivery Network (SCDN) delivers TLS content to end-users on behalf of Akamai's customers. It has been assessed by a Qualified Security Assessor (QSA) from Neohapsis, Inc, against the Payment Card Industry Data Security Standard (PCI DSS) 3.0. This document outlines whether a PCI DSS requirement is handled by Akamai, the customer, a joint responsibility, or not applicable. It is intended to enable Akamai customers to communicate requirements to their own PCI QSA when performing an assessment of their environment, per section 12.8.2. https://www.pcisecuritystandards.org/documents/pci_dss_v3.pdf. Disclaimer This document addresses only data transmitted using Akamai SCDN services. Data held on customer systems and data transmissions that do not involve Akamai s SCDN servers are not Akamai's responsibility to protect. Customers are responsible for meeting all PCI DSS compliance requirements on their own servers and networks.
Responsibility Matrix 1.1 Establishandimplementfirewall androuterconfigurationstandards 1.1.1 thatincludethefollowing: Aformalprocessforapprovingand testingallnetworkconnections andchangestothefirewalland 1.1.2 routerconfigurations Currentdiagramthatidentifiesall networks,networkdevices,and systemcomponents,withall connectionsbetweenthecdeand othernetworks,includingany wirelessnetworks 1.1.3 Currentdiagramthatshowsall cardholderdataflowsacross systemsandnetworks 1.1.4 Requirementsforafirewallateach Internetconnectionandbetween anydemilitarizedzone(dmz)and theinternalnetworkzone 1.1.5 Descriptionofgroups,roles,and responsibilitiesformanagementof networkcomponents
1.1.6 Documentationandbusiness justificationforuseofallservices, protocols,andportsallowed, includingdocumentationof securityfeaturesimplementedfor thoseprotocolsconsideredtobe insecure. Examplesofinsecureservices, protocols,orportsincludebutare notlimitedtoftp,telnet,pop3, IMAP,andSNMPv1andv2. 1.1.7 Requirementtoreviewfirewall androuterrulesetsatleastevery sixmonths 1.2 Buildfirewallandrouter configurationsthatrestrict connectionsbetweenuntrusted networksandanysystem componentsinthecardholder dataenvironment. Note:An untrustednetwork is anynetworkthatisexternaltothe networksbelongingtotheentity underreview,and/orwhichisout oftheentity'sabilitytocontrolor manage. 1.2.1 Restrictinboundandoutbound traffictothatwhichisnecessary forthecardholderdata environment,andspecificallydeny allothertraffic. 1.2.2 Secureandsynchronizerouter configurationfiles.
1.2.3 Installperimeterfirewallsbetween allwirelessnetworksandthe cardholderdataenvironment,and configurethesefirewallstodeny or,iftrafficisnecessaryfor businesspurposes,permitonly authorizedtrafficbetweenthe wirelessenvironmentandthe cardholderdataenvironment. 1.3 Prohibitdirectpublicaccess betweentheinternetandany systemcomponentinthe cardholderdataenvironment. 1.3.1 ImplementaDMZtolimitinbound traffictoonlysystemcomponents thatprovideauthorizedpublicly accessibleservices,protocols,and ports. 1.3.2 LimitinboundInternettraffictoIP addresseswithinthedmz. 1.3.3 Donotallowanydirect connectionsinboundoroutbound fortrafficbetweentheinternet andthecardholderdata environment. 1.3.4 Implementanti]spoofingmeasures todetectandblockforgedsource IPaddressesfromenteringthe network. (Forexample,blocktraffic originatingfromtheinternetwith aninternalsourceaddress.)
1.3.5 Donotallowunauthorized outboundtrafficfromthe cardholderdataenvironmentto theinternet. 1.3.6 Implementstatefulinspection,also knownasdynamicpacketfiltering. (Thatis,only established connectionsareallowedintothe network.) 1.3.7 Placesystemcomponentsthat storecardholderdata(suchasa database)inaninternalnetwork zone,segregatedfromthedmz andotheruntrustednetworks. 1.3.8 DonotdiscloseprivateIP addressesandroutinginformation tounauthorizedparties. Note:MethodstoobscureIP addressingmayinclude,butare notlimitedto: ]NetworkAddressTranslation (NAT) ]Placingserverscontaining cardholderdatabehindproxy servers/firewalls, ]Removalorfilteringofroute advertisementsforprivate networksthatemployregistered addressing, ]InternaluseofRFC1918address spaceinsteadofregistered addresses.
1.4 Installpersonalfirewallsoftware 1.5 onanymobileand/oremployee] owneddevicesthatconnecttothe Internetwhenoutsidethenetwork (forexample,laptopsusedby employees),andwhicharealso usedtoaccessthenetwork. Firewallconfigurationsinclude: ]Specificconfigurationsettingsare definedforpersonalfirewall software. ]Personalfirewallsoftwareis activelyrunning. ]Personalfirewallsoftwareisnot alterablebyusersofmobileand/or employee]owneddevices. Ensurethatsecuritypoliciesand operationalproceduresfor managingfirewallsare documented,inuse,andknownto allaffectedparties. 2.1 Alwayschangevendor]supplied defaultsandremoveordisable unnecessarydefaultaccounts beforeinstallingasystemonthe network. ThisappliestoALLdefault passwords,includingbutnot limitedtothoseusedbyoperating systems,softwarethatprovides securityservices,applicationand systemaccounts,point]of]sale (POS)terminals,SimpleNetwork ManagementProtocol(SNMP) communitystrings,etc.).
2.1.1 Forwirelessenvironments connectedtothecardholderdata environmentortransmitting cardholderdata,changeall wirelessvendordefaultsat installation,includingbutnot limitedtodefaultwireless encryptionkeys,passwords,and SNMPcommunitystrings. 2.2 Developconfigurationstandards forallsystemcomponents.assure thatthesestandardsaddressall knownsecurityvulnerabilitiesand areconsistentwithindustry] acceptedsystemhardening standards. Sourcesofindustry]accepted systemhardeningstandardsmay include,butarenotlimitedto: ]CenterforInternetSecurity(CIS) ]InternationalOrganizationfor Standardization(ISO) ]SysAdminAuditNetworkSecurity (SANS)Institute ]NationalInstituteofStandards Technology(NIST).
2.2.1 Implementonlyoneprimary 2.2.2 functionperservertoprevent functionsthatrequiredifferent securitylevelsfromco]existingon thesameserver.(forexample, webservers,databaseservers,and DNSshouldbeimplementedon separateservers.) Note:Wherevirtualization technologiesareinuse,implement onlyoneprimaryfunctionper virtualsystemcomponent. Enableonlynecessaryservices, protocols,daemons,etc.,as requiredforthefunctionofthe system. 2.2.3 Implementadditionalsecurity featuresforanyrequiredservices, protocols,ordaemonsthatare consideredtobeinsecure for example,usesecuredtechnologies suchasssh,s]ftp,ssl,oripsec VPNtoprotectinsecureservices suchasnetbios,file]sharing, Telnet,FTP,etc. 2.2.4 Configuresystemsecurity parameterstopreventmisuse. 2.2.5 Removeallunnecessary functionality,suchasscripts, drivers,features,subsystems,file systems,andunnecessaryweb servers.
2.3 Encryptallnon]console 2.4 administrativeaccessusingstrong cryptography.usetechnologies suchasssh,vpn,orssl/tlsfor web]basedmanagementandother non]consoleadministrativeaccess. Maintainaninventoryofsystem componentsthatareinscopefor PCIDSS 2.5 Ensurethatsecuritypoliciesand operationalproceduresfor managingvendordefaultsand othersecurityparametersare documented,inuse,andknownto allaffectedparties. 2.6 Sharedhostingprovidersmust protecteachentity shosted environmentandcardholderdata. Theseprovidersmustmeet specificrequirementsasdetailed inappendixa:additionalpcidss RequirementsforSharedHosting Providers.
3.1 Keepcardholderdatastoragetoa minimumbyimplementingdata retentionanddisposalpolicies, proceduresandprocessesthat includeatleastthefollowingforall cardholderdata(chd)storage: ]Limitingdatastorageamountand retentiontimetothatwhichis requiredforlegal,regulatory,and businessrequirements ]Processesforsecuredeletionof datawhennolongerneeded ]Specificretentionrequirements forcardholderdata ]Aquarterlyprocessfor identifyingandsecurelydeleting storedcardholderdatathat exceedsdefinedretention. 3.2 Donotstoresensitive authenticationdataafter authorization(evenifencrypted). Ifsensitiveauthenticationdatais received,renderalldata unrecoverableuponcompletionof theauthorizationprocess.itis permissibleforissuersand companiesthatsupportissuing servicestostoresensitive authenticationdataif:]thereisa businessjustificationand]the dataisstoredsecurely. Sensitiveauthenticationdata includesthedataascitedinthe followingrequirements3.2.1 through3.2.3:
3.2.1 Donotstorethefullcontentsof anytrack(fromthemagnetic stripelocatedonthebackofa card,equivalentdatacontainedon achip,orelsewhere).thisdatais alternativelycalledfulltrack,track, track1,track2,andmagnetic] stripedata. Note:Inthenormalcourseof business,thefollowingdata elementsfromthemagneticstripe mayneedtoberetained: ]Thecardholder sname ]Primaryaccountnumber(PAN) ]Expirationdate ]Servicecode Tominimizerisk,storeonlythese dataelementsasneededfor business. 3.2.2 Donotstorethecardverification codeorvalue(three]digitorfour] digitnumberprintedonthefront orbackofapaymentcard)usedto verifycard]not]present transactions.
3.2.3 Donotstorethepersonal identificationnumber(pin)orthe encryptedpinblock. 3.3 MaskPANwhendisplayed(the firstsixandlastfourdigitsarethe maximumnumberofdigitstobe displayed),suchthatonly personnelwithalegitimate businessneedcanseethefullpan. Note:Thisrequirementdoesnot supersedestricterrequirementsin placefordisplaysofcardholder data forexample,legalor paymentcardbrandrequirements forpoint]of]sale(pos)receipts.
3.4 RenderPANunreadableanywhere itisstored(includingonportable digitalmedia,backupmedia,and inlogs)byusinganyofthe followingapproaches: ]One]wayhashesbasedonstrong cryptography,(hashmustbeofthe entirepan) ]Truncation(hashingcannotbe usedtoreplacethetruncated segmentofpan) ]Indextokensandpads(pads mustbesecurelystored) ]Strongcryptographywith associatedkey]management processesandprocedures. Note:Itisarelativelytrivialeffort foramaliciousindividualto reconstructoriginalpandataif theyhaveaccesstoboththe truncatedandhashedversionofa PAN.Wherehashedandtruncated versionsofthesamepanare presentinanentity senvironment, additionalcontrolsshouldbein placetoensurethatthehashed andtruncatedversionscannotbe correlatedtoreconstructthe originalpan.
3.4.1 Ifdiskencryptionisused(rather thanfile]orcolumn]leveldatabase encryption),logicalaccessmustbe managedseparatelyand independentlyofnativeoperating systemauthenticationandaccess controlmechanisms(forexample, bynotusinglocaluseraccount databasesorgeneralnetworklogin credentials).decryptionkeysmust notbeassociatedwithuser accounts. 3.5 Documentandimplement procedurestoprotectkeysusedto securestoredcardholderdata againstdisclosureandmisuse: Note:Thisrequirementappliesto keysusedtoencryptstored cardholderdata,andalsoapplies tokey]encryptingkeysusedto protectdata]encryptingkeys suchkey]encryptingkeysmustbe atleastasstrongasthedata] encryptingkey. 3.5.1 Restrictaccesstocryptographic keystothefewestnumberof custodiansnecessary.
3.5.2 Storesecretandprivatekeysused toencrypt/decryptcardholder datainone(ormore)ofthe followingformsatalltimes: ]Encryptedwithakey]encrypting keythatisatleastasstrongasthe data]encryptingkey,andthatis storedseparatelyfromthedata] encryptingkey ]Withinasecurecryptographic device(suchasahostsecurity module(hsm)orpts]approved point]of]interactiondevice) ]Asatleasttwofull]lengthkey componentsorkeyshares,in accordancewithanindustry] acceptedmethod Note:Itisnotrequiredthatpublic keysbestoredinoneofthese forms. 3.5.3 Storecryptographickeysinthe fewestpossiblelocations. 3.6 Fullydocumentandimplementall key]managementprocessesand proceduresforcryptographickeys usedforencryptionofcardholder data,includingthefollowing: Note:Numerousindustry standardsforkeymanagementare availablefromvariousresources includingnist,whichcanbefound athttp://csrc.nist.gov.
3.6.1 Generationofstrongcryptographic keys 3.6.2 Securecryptographickey distribution 3.6.3 Securecryptographickeystorage 3.6.4 Cryptographickeychangesforkeys thathavereachedtheendoftheir cryptoperiod(forexample,aftera definedperiodoftimehaspassed and/orafteracertainamountof cipher]texthasbeenproducedby agivenkey),asdefinedbythe associatedapplicationvendoror keyowner,andbasedonindustry bestpracticesandguidelines(for example,nistspecialpublication 800]57).
3.6.5 Retirementorreplacement(for example,archiving,destruction, and/orrevocation)ofkeysas deemednecessarywhenthe integrityofthekeyhasbeen weakened(forexample,departure ofanemployeewithknowledgeof aclear]textkeycomponent),or keysaresuspectedofbeing compromised. Note:Ifretiredorreplaced cryptographickeysneedtobe retained,thesekeysmustbe securelyarchived(forexample,by usingakey]encryptionkey). Archivedcryptographickeys shouldonlybeusedfor decryption/verificationpurposes. 3.6.6 Ifmanualclear]textcryptographic key]managementoperationsare used,theseoperationsmustbe managedusingsplitknowledge anddualcontrol. Note:Examplesofmanualkey] managementoperationsinclude, butarenotlimitedto:key generation,transmission,loading, storageanddestruction. 3.6.7 Preventionofunauthorized substitutionofcryptographickeys.
3.6.8 Requirementforcryptographickey custodianstoformally acknowledgethattheyunderstand andaccepttheirkey]custodian responsibilities. 3.7 Ensurethatsecuritypoliciesand operationalproceduresfor protectingstoredcardholderdata aredocumented,inuse,and knowntoallaffectedparties.
4.1 Usestrongcryptographyand securityprotocols(forexample, SSL/TLS,IPSEC,SSH,etc.)to safeguardsensitivecardholder dataduringtransmissionover open,publicnetworks,including thefollowing: ]Onlytrustedkeysandcertificates areaccepted. ]Theprotocolinuseonlysupports secureversionsorconfigurations. ]Theencryptionstrengthis appropriatefortheencryption methodologyinuse. Examplesofopen,publicnetworks includebutarenotlimitedto: ]TheInternet ]Wirelesstechnologies,including 802.11andBluetooth ]Cellulartechnologies,for example,globalsystemformobile communications(gsm),code divisionmultipleaccess(cdma) ]GeneralPacketRadioService (GPRS). ]Satellitecommunications.
4.1.1 Ensurewirelessnetworks transmittingcardholderdataor connectedtothecardholderdata environment,useindustrybest practices(forexample,ieee 802.11i)toimplementstrong encryptionforauthenticationand transmission. Note:TheuseofWEPasasecurity controlisprohibited. 4.2 NeversendunprotectedPANsby end]usermessagingtechnologies (forexample,e]mail,instant messaging,chat,etc.). 4.3 Ensurethatsecuritypoliciesand operationalproceduresfor encryptingtransmissionsof cardholderdataaredocumented, inuse,andknowntoallaffected parties. 5.1 Deployanti]virussoftwareonall systemscommonlyaffectedby malicioussoftware(particularly personalcomputersandservers). 5.1.1 Ensurethatanti]virusprograms arecapableofdetecting, removing,andprotectingagainst allknowntypesofmalicious software.
5.1.2 Forsystemsconsideredtobenot 5.2 commonlyaffectedbymalicious software,performperiodic evaluationstoidentifyand evaluateevolvingmalwarethreats inordertoconfirmwhethersuch systemscontinuetonotrequire anti]virussoftware. Ensurethatallanti]virus mechanismsaremaintainedas follows: ]Arekeptcurrent, ]Performperiodicscans ]Generateauditlogswhichare retainedperpcidssrequirement 10.7. 5.3 Ensurethatanti]virusmechanisms areactivelyrunningandcannotbe disabledoralteredbyusers,unless specificallyauthorizedby managementonacase]by]case basisforalimitedtimeperiod. Note:Anti]virussolutionsmaybe temporarilydisabledonlyifthere islegitimatetechnicalneed,as authorizedbymanagementona case]by]casebasis.ifanti]virus protectionneedstobedisabledfor aspecificpurpose,itmustbe formallyauthorized.additional securitymeasuresmayalsoneed tobeimplementedfortheperiod oftimeduringwhichanti]virus protectionisnotactive.
5.4 Ensurethatsecuritypoliciesand operationalproceduresfor protectingsystemsagainst malwarearedocumented,inuse, andknowntoallaffectedparties. 6.1 Establishaprocesstoidentify securityvulnerabilities,using reputableoutsidesourcesfor securityvulnerabilityinformation, andassignariskranking(for example,as high, medium, or low )tonewlydiscovered securityvulnerabilities. 6.2 Ensurethatallsystemcomponents andsoftwareareprotectedfrom knownvulnerabilitiesbyinstalling applicablevendor]supplied securitypatches.installcritical securitypatcheswithinonemonth ofrelease. Note:Criticalsecuritypatches shouldbeidentifiedaccordingto theriskrankingprocessdefinedin Requirement6.1.
6.3 Developinternalandexternal softwareapplications(including web]basedadministrativeaccess toapplications)securely,as follows: ]InaccordancewithPCIDSS(for example,secureauthentication andlogging) ]Basedonindustrystandards and/orbestpractices. ]Incorporatinginformation securitythroughoutthesoftware] developmentlifecycle Note:thisappliestoallsoftware developedinternallyaswellas bespokeorcustomsoftware developedbyathirdparty. 6.3.1 Removedevelopment,testand/or customapplicationaccounts,user IDs,andpasswordsbefore applicationsbecomeactiveorare releasedtocustomers.
6.3.2 Reviewcustomcodepriorto releasetoproductionorcustomers inordertoidentifyanypotential codingvulnerability(usingeither manualorautomatedprocesses) toincludeatleastthefollowing: ]Codechangesarereviewedby individualsotherthanthe originatingcodeauthor,andby individualsknowledgeableabout code]reviewtechniquesand securecodingpractices. ]Codereviewsensurecodeis developedaccordingtosecure codingguidelines ]Appropriatecorrectionsare implementedpriortorelease. ]Code]reviewresultsarereviewed andapprovedbymanagement priortorelease. Note:Thisrequirementforcode reviewsappliestoallcustomcode (bothinternalandpublic]facing), aspartofthesystemdevelopment lifecycle. Codereviewscanbeconductedby knowledgeableinternalpersonnel orthirdparties.public]facingweb applicationsarealsosubjectto additionalcontrols,toaddress ongoingthreatsandvulnerabilities afterimplementation,asdefined atpcidssrequirement6.6.
6.4 Followchangecontrolprocesses andproceduresforallchangesto systemcomponents.the processesmustincludethe following: 6.4.1 Separatedevelopment/test environmentsfromproduction environments,andenforcethe separationwithaccesscontrols. 6.4.2 Separationofdutiesbetween development/testandproduction environments 6.4.3 Productiondata(livePANs)arenot usedfortestingordevelopment 6.4.4 Removaloftestdataandaccounts beforeproductionsystems becomeactive
6.4.5 Changecontrolproceduresforthe implementationofsecurity patchesandsoftware modificationsmustincludethe following: 6.4.5.1 Documentationofimpact. 6.4.5.2 Documentedchangeapprovalby authorizedparties. 6.4.5.3 Functionalitytestingtoverifythat thechangedoesnotadversely impactthesecurityofthesystem. 6.4.5.4 Back]outprocedures.
6.5 Addresscommoncoding vulnerabilitiesinsoftware] developmentprocessesasfollows: ]Traindevelopersinsecurecoding techniques,includinghowtoavoid commoncodingvulnerabilities, andunderstandinghowsensitive dataishandledinmemory. ]Developapplicationsbasedon securecodingguidelines. Note:Thevulnerabilitieslistedat 6.5.1through6.5.10werecurrent withindustrybestpracticeswhen thisversionofpcidsswas published.however,asindustry bestpracticesforvulnerability managementareupdated(for example,theowaspguide,sans CWETop25,CERTSecureCoding, etc.),thecurrentbestpractices mustbeusedforthese requirements. 6.5.1 Injectionflaws,particularlySQL injection.alsoconsideros CommandInjection,LDAPand XPathinjectionflawsaswellas otherinjectionflaws.
6.5.2 Bufferoverflows 6.5.3 Insecurecryptographicstorage 6.5.4 Insecurecommunications 6.5.5 Impropererrorhandling
6.5.6 All highrisk vulnerabilities identifiedinthevulnerability identificationprocess(asdefined inpcidssrequirement6.1). 6.5.7 Cross]sitescripting(XSS) 6.5.8 Improperaccesscontrol(suchas insecuredirectobjectreferences, failuretorestricturlaccess, directorytraversal,andfailureto restrictuseraccesstofunctions). 6.5.9 Cross]siterequestforgery(CSRF) 6.5.10 Brokenauthenticationandsession managementnote:requirement 6.5.10isabestpracticeuntilJune 30,2015,afterwhichitbecomesa requirement.
6.6 Forpublic]facingwebapplications, 6.7 addressnewthreatsand vulnerabilitiesonanongoingbasis andensuretheseapplicationsare protectedagainstknownattacks byeitherofthefollowing methods: ]Reviewingpublic]facingweb applicationsviamanualor automatedapplication vulnerabilitysecurityassessment toolsormethods,atleastannually andafteranychangesnote:this assessmentisnotthesameasthe vulnerabilityscansperformedfor Requirement11.2. ]Installinganautomatedtechnical solutionthatdetectsandprevents web]basedattacks(forexample,a web]applicationfirewall)infront ofpublic]facingwebapplications, tocontinuallycheckalltraffic. Ensurethatsecuritypoliciesand operationalproceduresfor developingandmaintainingsecure systemsandapplicationsare documented,inuse,andknownto allaffectedparties.
7.1 Limitaccesstosystemcomponents andcardholderdatatoonlythose individualswhosejobrequires suchaccess. 7.1.1 Defineaccessneedsforeachrole, including: ]Systemcomponentsanddata resourcesthateachroleneedsto accessfortheirjobfunction ]Levelofprivilegerequired(for example,user,administrator,etc.) foraccessingresources. 7.1.2 Restrictaccesstoprivilegeduser IDstoleastprivilegesnecessaryto performjobresponsibilities. 7.1.3 Assignaccessbasedonindividual personnel sjobclassificationand function.
7.1.4 Requiredocumentedapprovalby authorizedpartiesspecifying requiredprivileges. 7.2 Establishanaccesscontrolsystem forsystemscomponentsthat restrictsaccessbasedonauser s needtoknow,andissetto deny all unlessspecificallyallowed. Thisaccesscontrolsystemmust includethefollowing: 7.2.1 Coverageofallsystem components 7.2.2 Assignmentofprivilegesto individualsbasedonjob classificationandfunction. 7.2.3 Default deny]all setting. 7.3 Ensurethatsecuritypoliciesand operationalproceduresfor restrictingaccesstocardholder dataaredocumented,inuse,and knowntoallaffectedparties. 8.1 Defineandimplementpoliciesand procedurestoensureproperuser identificationmanagementfor non]consumerusersand administratorsonallsystem componentsasfollows: 8.1.1 AssignallusersauniqueIDbefore allowingthemtoaccesssystem componentsorcardholderdata.
8.1.2 Controladdition,deletion,and modificationofuserids, credentials,andotheridentifier objects. 8.1.3 Immediatelyrevokeaccessforany terminatedusers. 8.1.4 Remove/disableinactiveuser accountsatleastevery90days. 8.1.5 ManageIDsusedbyvendorsto access,support,ormaintain systemcomponentsviaremote accessasfollows: ]Enabledonlyduringthetime periodneededanddisabledwhen notinuse. ]Monitoredwheninuse. 8.1.6 Limitrepeatedaccessattemptsby lockingouttheuseridafternot morethansixattempts. 8.1.7 Setthelockoutdurationtoa minimumof30minutesoruntilan administratorenablestheuserid.
8.1.8 Ifasessionhasbeenidleformore than15minutes,requiretheuser tore]authenticatetore]activate theterminalorsession. 8.2 Inadditiontoassigningaunique ID,ensureproperuser] authenticationmanagementfor non]consumerusersand administratorsonallsystem componentsbyemployingatleast oneofthefollowingmethodsto authenticateallusers: ]Somethingyouknow,suchasa passwordorpassphrase ]Somethingyouhave,suchasa tokendeviceorsmartcard ]Somethingyouare,suchasa biometric. 8.2.1 Usingstrongcryptography,render allauthenticationcredentials(such aspasswords/phrases)unreadable duringtransmissionandstorageon allsystemcomponents. 8.2.2 Verifyuseridentitybefore modifyinganyauthentication credential forexample, performingpasswordresets, provisioningnewtokens,or generatingnewkeys.
8.2.3 Passwords/phrasesmustmeetthe following: ]Requireaminimumlengthofat leastsevencharacters. ]Containbothnumericand alphabeticcharacters. Alternatively,the passwords/phrasesmusthave complexityandstrengthatleast equivalenttotheparameters specifiedabove. 8.2.4 Changeuser passwords/passphrasesatleast every90days. 8.2.5 Donotallowanindividualto submitanewpassword/phrase thatisthesameasanyofthelast fourpasswords/phrasesheorshe hasused.
8.2.6 Setpasswords/phrasesforfirst] timeuseanduponresettoa uniquevalueforeachuser,and changeimmediatelyafterthefirst use. 8.3 Incorporatetwo]factor authenticationforremotenetwork accessoriginatingfromoutsidethe networkbypersonnel(including usersandadministrators)andall thirdparties,(includingvendor accessforsupportor maintenance). Note:Two]factorauthentication requiresthattwoofthethree authenticationmethods(see Requirement8.2fordescriptions ofauthenticationmethods)be usedforauthentication.usingone factortwice(forexample,using twoseparatepasswords)isnot consideredtwo]factor authentication.examplesoftwo] factortechnologiesincluderemote authenticationanddial]inservice (RADIUS)withtokens;terminal accesscontrolleraccesscontrol system(tacacs)withtokens;and othertechnologiesthatfacilitate two]factorauthentication.
8.4 Documentandcommunicate 8.5 authenticationproceduresand policiestoallusersincluding: ]Guidanceonselectingstrong authenticationcredentials ]Guidanceforhowusersshould protecttheirauthentication credentials ]Instructionsnottoreuse previouslyusedpasswords ]Instructionstochangepasswords ifthereisanysuspicionthe passwordcouldbecompromised. Donotusegroup,shared,or genericids,passwords,orother authenticationmethodsasfollows: ]GenericuserIDsaredisabledor removed. ]ShareduserIDsdonotexistfor systemadministrationandother criticalfunctions. ]SharedandgenericuserIDsare notusedtoadministeranysystem components.
8.5.1 Additionalrequirementforservice providers:serviceproviderswith remoteaccesstocustomer premises(forexample,forsupport ofpossystemsorservers)must useauniqueauthentication credential(suchasa password/phrase)foreach customer. Note:Thisrequirementisnot intendedtoapplytoshared hostingprovidersaccessingtheir ownhostingenvironment,where multiplecustomerenvironments arehosted. Note:Requirement8.5.1isabest practiceuntiljune30,2015,after whichitbecomesarequirement.
8.6 Whereotherauthentication 8.7 mechanismsareused(for example,physicalorlogical securitytokens,smartcards, certificates,etc.),useofthese mechanismsmustbeassignedas follows: ]Authenticationmechanismsmust beassignedtoanindividual accountandnotsharedamong multipleaccounts. ]Physicaland/orlogicalcontrols mustbeinplacetoensureonlythe intendedaccountcanusethat mechanismtogainaccess. Allaccesstoanydatabase containingcardholderdata (includingaccessbyapplications, administrators,andallotherusers) isrestrictedasfollows: ]Alluseraccessto,userqueriesof, anduseractionsondatabasesare throughprogrammaticmethods. ]Onlydatabaseadministrators havetheabilitytodirectlyaccess orquerydatabases. ]ApplicationIDsfordatabase applicationscanonlybeusedby theapplications(andnotby individualusersorothernon] applicationprocesses).
8.8 Ensurethatsecuritypoliciesand operationalproceduresfor identificationandauthentication aredocumented,inuse,and knowntoallaffectedparties. 9.1 Useappropriatefacilityentry controlstolimitandmonitor physicalaccesstosystemsinthe cardholderdataenvironment. 9.1.1 Usevideocamerasand/oraccess controlmechanismstomonitor individualphysicalaccessto sensitiveareas.reviewcollected dataandcorrelatewithother entries.storeforatleastthree months,unlessotherwise restrictedbylaw.note: Sensitive areas referstoanydatacenter, serverroomoranyareathat housessystemsthatstore, process,ortransmitcardholder data.thisexcludespublic]facing areaswhereonlypoint]of]sale terminalsarepresent,suchasthe cashierareasinaretailstore.
9.1.2 Implementphysicaland/orlogical 9.1.3 controlstorestrictaccessto publiclyaccessiblenetworkjacks. Forexample,networkjacks locatedinpublicareasandareas accessibletovisitorscouldbe disabledandonlyenabledwhen networkaccessisexplicitly authorized.alternatively, processescouldbeimplemented toensurethatvisitorsareescorted atalltimesinareaswithactive networkjacks. Restrictphysicalaccesstowireless accesspoints,gateways,handheld devices, networking/communications hardware,andtelecommunication lines. 9.2 Developprocedurestoeasily distinguishbetweenonsite personnelandvisitors,toinclude: ]Identifyingnewonsitepersonnel orvisitors(forexample,assigning badges) ]Changestoaccessrequirements ]Revokingorterminatingonsite personnelandexpiredvisitor identification(suchasidbadges).
9.3 Controlphysicalaccessforonsite 9.4.x personneltothesensitiveareasas follows: ]Accessmustbeauthorizedand basedonindividualjobfunction. ]Accessisrevokedimmediately upontermination,andallphysical accessmechanisms,suchaskeys, accesscards,etc.,arereturnedor disabled. Implementprocedurestoidentify andauthorizevisitors. Proceduresshouldincludethe following: 9.4.1 Visitorsareauthorizedbefore entering,andescortedatalltimes within,areaswherecardholder dataisprocessedormaintained. 9.4.2 Visitorsareidentifiedandgivena badgeorotheridentificationthat expiresandthatvisibly distinguishesthevisitorsfrom onsitepersonnel. 9.4.3 Visitorsareaskedtosurrenderthe badgeoridentificationbefore leavingthefacilityoratthedateof expiration.
9.4.4 Avisitorlogisusedtomaintaina 9.5 physicalaudittrailofvisitor activitytothefacilityaswellas computerroomsanddatacenters wherecardholderdataisstoredor transmitted. Documentthevisitor sname,the firmrepresented,andtheonsite personnelauthorizingphysical accessonthelog. Retainthislogforaminimumof threemonths,unlessotherwise restrictedbylaw. Physicallysecureallmedia. 9.5.1 Storemediabackupsinasecure location,preferablyanoff]site facility,suchasanalternateor backupsite,oracommercial storagefacility.reviewthe location ssecurityatleast annually. 9.6 Maintainstrictcontroloverthe internalorexternaldistributionof anykindofmedia,includingthe following: 9.6.1 Classifymediasothesensitivityof thedatacanbedetermined. 9.6.2 Sendthemediabysecuredcourier orotherdeliverymethodthatcan beaccuratelytracked. 9.6.3 Ensuremanagementapprovesany andallmediathatismovedfroma securedarea(includingwhen mediaisdistributedtoindividuals).
9.7 Maintainstrictcontroloverthe storageandaccessibilityofmedia. 9.7.1 Properlymaintaininventorylogsof allmediaandconductmedia inventoriesatleastannually. 9.8 Destroymediawhenitisnolonger neededforbusinessorlegal reasonsasfollows: 9.8.1 Shred,incinerate,orpulphard] copymaterialssothatcardholder datacannotbereconstructed. Securestoragecontainersusedfor materialsthataretobedestroyed. 9.8.2 Rendercardholderdataon electronicmediaunrecoverableso thatcardholderdatacannotbe reconstructed. 9.9 Protectdevicesthatcapture paymentcarddataviadirect physicalinteractionwiththecard fromtamperingandsubstitution. Note:Theserequirementsapplyto card]readingdevicesusedincard] presenttransactions(thatis,card swipeordip)atthepointofsale. Thisrequirementisnotintended toapplytomanualkey]entry componentssuchascomputer keyboardsandposkeypads. Note:Requirement9.9isabest practiceuntiljune30,2015,after whichitbecomesarequirement.
9.9.1 Maintainanup]to]datelistof devices.thelistshouldincludethe following: ]Make,modelofdevice ]Locationofdevice(forexample, theaddressofthesiteorfacility wherethedeviceislocated) ]Deviceserialnumberorother methodofuniqueidentification. 9.9.2 Periodicallyinspectdevicesurfaces todetecttampering(forexample, additionofcardskimmersto devices),orsubstitution(for example,bycheckingtheserial numberorotherdevice characteristicstoverifyithasnot beenswappedwithafraudulent device). Note:Examplesofsignsthata devicemighthavebeentampered withorsubstitutedinclude unexpectedattachmentsorcables pluggedintothedevice,missingor changedsecuritylabels,brokenor differentlycoloredcasing,or changestotheserialnumberor otherexternalmarkings.
9.9.3 Providetrainingforpersonnelto beawareofattemptedtampering orreplacementofdevices.training shouldincludethefollowing: ]Verifytheidentityofanythird] partypersonsclaimingtoberepair ormaintenancepersonnel,priorto grantingthemaccesstomodifyor troubleshootdevices. ]Donotinstall,replace,orreturn deviceswithoutverification. ]Beawareofsuspiciousbehavior arounddevices(forexample, attemptsbyunknownpersonsto unplugoropendevices). ]Reportsuspiciousbehaviorand indicationsofdevicetamperingor substitutiontoappropriate personnel(forexample,toa managerorsecurityofficer). 9.10 Ensurethatsecuritypoliciesand operationalproceduresfor restrictingphysicalaccessto cardholderdataaredocumented, inuse,andknowntoallaffected parties. 10.1 Implementaudittrailstolinkall accesstosystemcomponentsto eachindividualuser. 10.2 Implementautomatedaudittrails forallsystemcomponentsto reconstructthefollowingevents: 10.2.1 Allindividualuseraccessesto cardholderdata
10.2.2 Allactionstakenbyanyindividual withrootoradministrative privileges 10.2.3 Accesstoallaudittrails 10.2.4 Invalidlogicalaccessattempts 10.2.5 Useofandchangesto identificationandauthentication mechanisms includingbutnot limitedtocreationofnew accountsandelevationof privileges andallchanges, additions,ordeletionstoaccounts withrootoradministrative privileges 10.2.6 Initialization,stopping,orpausing oftheauditlogs 10.2.7 Creationanddeletionofsystem] levelobjects 10.3 Recordatleastthefollowingaudit trailentriesforallsystem componentsforeachevent: 10.3.1 Useridentification 10.3.2 Typeofevent 10.3.3 Dateandtime 10.3.4 Successorfailureindication 10.3.5 Originationofevent 10.3.6 Identityornameofaffecteddata, systemcomponent,orresource.
10.4 Usingtime]synchronization technology,synchronizeallcritical systemclocksandtimesand ensurethatthefollowingis implementedforacquiring, distributing,andstoringtime. Note:Oneexampleoftime synchronizationtechnologyis NetworkTimeProtocol(NTP). 10.4.1 Criticalsystemshavethecorrect andconsistenttime. 10.4.2 Timedataisprotected. 10.4.3 Timesettingsarereceivedfrom industry]acceptedtimesources. 10.5 Secureaudittrailssotheycannot bealtered. 10.5.1 Limitviewingofaudittrailsto thosewithajob]relatedneed. 10.5.2 Protectaudittrailfilesfrom unauthorizedmodifications. 10.5.3 Promptlybackupaudittrailfilesto acentralizedlogserverormedia thatisdifficulttoalter. 10.5.4 Writelogsforexternal]facing technologiesontoasecure, centralized,internallogserveror mediadevice.
10.5.5 Usefile]integritymonitoringor change]detectionsoftwareonlogs toensurethatexistinglogdata cannotbechangedwithout 10.6 generatingalerts(althoughnew databeingaddedshouldnotcause analert). Reviewlogsandsecurityeventsfor allsystemcomponentstoidentify anomaliesorsuspiciousactivity. Note:Logharvesting,parsing,and alertingtoolsmaybeusedtomeet thisrequirement. 10.6.1 Reviewthefollowingatleastdaily: ]Allsecurityevents ]Logsofallsystemcomponents thatstore,process,ortransmit CHDand/orSAD,orthatcould impactthesecurityofchdand/or SAD ]Logsofallcriticalsystem components ]Logsofallserversandsystem componentsthatperformsecurity functions(forexample,firewalls, intrusion]detection systems/intrusion]prevention systems(ids/ips),authentication servers,e]commerceredirection servers,etc.).
10.6.2 Reviewlogsofallothersystem componentsperiodicallybasedon theorganization spoliciesandrisk managementstrategy,as determinedbytheorganization s annualriskassessment. 10.6.3 Followupexceptionsand anomaliesidentifiedduringthe reviewprocess. 10.7 Retainaudittrailhistoryforat leastoneyear,withaminimumof threemonthsimmediately availableforanalysis(forexample, online,archived,orrestorable frombackup). 10.8 Ensurethatsecuritypoliciesand operationalproceduresfor monitoringallaccesstonetwork resourcesandcardholderdataare documented,inuse,andknownto allaffectedparties.
11.1 Implementprocessestotestfor 11.1.1 thepresenceofwirelessaccess points(802.11),anddetectand identifyallauthorizedand unauthorizedwirelessaccess pointsonaquarterlybasis.note: Methodsthatmaybeusedinthe processincludebutarenotlimited towirelessnetworkscans, physical/logicalinspectionsof systemcomponentsand infrastructure,networkaccess control(nac),orwirelessids/ips. Whichevermethodsareused,they mustbesufficienttodetectand identifybothauthorizedand unauthorizeddevices. Maintainaninventoryof authorizedwirelessaccesspoints includingadocumentedbusiness justification. 11.1.2 Implementincidentresponse proceduresintheevent unauthorizedwirelessaccess pointsaredetected.
11.2 Runinternalandexternalnetwork vulnerabilityscansatleast quarterlyandafteranysignificant changeinthenetwork(suchas newsystemcomponent installations,changesinnetwork topology,firewallrule modifications,productupgrades). Note:Multiplescanreportscanbe combinedforthequarterlyscan processtoshowthatallsystems werescannedandallapplicable vulnerabilitieshavebeen addressed.additional documentationmayberequiredto verifynon]remediated vulnerabilitiesareintheprocessof beingaddressed. ForinitialPCIDSScompliance,itis notrequiredthatfourquartersof passingscansbecompletedifthe assessorverifies1)themost recentscanresultwasapassing scan,2)theentityhasdocumented policiesandproceduresrequiring quarterlyscanning,and3) vulnerabilitiesnotedinthescan resultshavebeencorrectedas showninare]scan(s).for subsequentyearsaftertheinitial PCIDSSreview,fourquartersof passingscansmusthaveoccurred.
11.2.1 Performquarterlyinternal vulnerabilityscansandrescansas needed,untilall high]risk vulnerabilities(asidentifiedin Requirement6.1)areresolved. Scansmustbeperformedby qualifiedpersonnel. 11.2.2 Performquarterlyexternal vulnerabilityscans,viaan ApprovedScanningVendor(ASV) approvedbythepaymentcard IndustrySecurityStandards Council(PCISSC).Performrescans asneeded,untilpassingscansare achieved. Note:Quarterlyexternal vulnerabilityscansmustbe performedbyanapproved ScanningVendor(ASV),approved bythepaymentcardindustry SecurityStandardsCouncil(PCI SSC). RefertotheASVProgramGuide publishedonthepcisscwebsite forscancustomerresponsibilities, scanpreparation,etc.
11.2.3 Performinternalandexternal scans,andrescansasneeded,after anysignificantchange.scansmust beperformedbyqualified personnel.
11.3 Implementamethodologyfor penetrationtestingthatincludes thefollowing: ]Isbasedonindustry]accepted penetrationtestingapproaches (forexample,nistsp800]115) ]Includescoveragefortheentire CDEperimeterandcriticalsystems ]Includestestingfrombothinside andoutsidethenetwork ]Includestestingtovalidateany segmentationandscope]reduction controls ]Definesapplication]layer penetrationteststoinclude,ata minimum,thevulnerabilitieslisted inrequirement6.5 ]Definesnetwork]layer penetrationteststoinclude componentsthatsupportnetwork functionsaswellasoperating systems ]Includesreviewand considerationofthreatsand vulnerabilitiesexperiencedinthe last12months ]Specifiesretentionofpenetration testingresultsandremediation activitiesresults.note:thisupdate torequirement11.3isabest practiceuntiljune30,2015,after whichitbecomesarequirement. PCIDSSv2.0requirementsfor penetrationtestingmustbe followeduntilv3.0isinplace.
11.3.1 Performexternalpenetration testingatleastannuallyandafter anysignificantinfrastructureor applicationupgradeor modification(suchasanoperating systemupgrade,asub]network addedtotheenvironment,ora webserveraddedtothe environment). 11.3.2 Performinternalpenetration testingatleastannuallyandafter anysignificantinfrastructureor applicationupgradeor modification(suchasanoperating systemupgrade,asub]network addedtotheenvironment,ora webserveraddedtothe environment). 11.3.3 Exploitablevulnerabilitiesfound duringpenetrationtestingare correctedandtestingisrepeated toverifythecorrections.
11.3.4 Ifsegmentationisusedtoisolate thecdefromothernetworks, performpenetrationtestsatleast annuallyandafteranychangesto segmentationcontrols/methodsto verifythatthesegmentation methodsareoperationaland effective,andisolateallout]of] scopesystemsfromin]scope systems. 11.4 Useintrusion]detectionand/or intrusion]preventiontechniquesto detectand/orpreventintrusions intothenetwork.monitorall trafficattheperimeterofthe cardholderdataenvironmentas wellasatcriticalpointsinthe cardholderdataenvironment,and alertpersonneltosuspected compromises. Keepallintrusion]detectionand preventionengines,baselines,and signaturesuptodate.
11.5 Deployachange]detection mechanism(forexample,file] integritymonitoringtools)toalert personneltounauthorized modificationofcriticalsystem files,configurationfiles,orcontent files;andconfigurethesoftwareto performcriticalfilecomparisonsat leastweekly.note:forchange] detectionpurposes,criticalfiles areusuallythosethatdonot regularlychange,butthe modificationofwhichcould indicateasystemcompromiseor riskofcompromise.change] detectionmechanismssuchasfile] integritymonitoringproducts usuallycomepre]configuredwith criticalfilesfortherelated operatingsystem.othercritical files,suchasthoseforcustom applications,mustbeevaluated anddefinedbytheentity(thatis, themerchantorserviceprovider). 11.5.1 Implementaprocesstorespondto anyalertsgeneratedbythe change]detectionsolution.
11.6 Ensurethatsecuritypoliciesand operationalproceduresfor securitymonitoringandtestingare documented,inuse,andknownto allaffectedparties. 12.1 Establish,publish,maintain,and disseminateasecuritypolicy. 12.1.1 Reviewthesecuritypolicyatleast annuallyandupdatethepolicy whentheenvironmentchanges. 12.2 Implementarisk]assessment processthat: ]Isperformedatleastannually anduponsignificantchangesto theenvironment(forexample, acquisition,merger,relocation, etc.), ]Identifiescriticalassets,threats, andvulnerabilities,and ]Resultsinaformalrisk assessment. Examplesofrisk]assessment methodologiesincludebutarenot limitedtooctave,iso27005and NISTSP800]30.
12.3 Developusagepoliciesforcritical 12.3.1 technologiesanddefineproper useofthesetechnologies. Note:Examplesofcritical technologiesinclude,butarenot limitedto,remoteaccessand wirelesstechnologies,laptops, tablets,removableelectronic media,e]mailusageandinternet usage. Ensuretheseusagepoliciesrequire thefollowing: Explicitapprovalbyauthorized parties 12.3.2 Authenticationforuseofthe technology 12.3.3 Alistofallsuchdevicesand personnelwithaccess 12.3.4 Amethodtoaccuratelyandreadily determineowner,contact information,andpurpose(for example,labeling,coding,and/or inventoryingofdevices) 12.3.5 Acceptableusesofthetechnology 12.3.6 Acceptablenetworklocationsfor thetechnologies 12.3.7 Listofcompany]approved products 12.3.8 Automaticdisconnectofsessions forremote]accesstechnologies afteraspecificperiodofinactivity
12.3.9 Activationofremote]access technologiesforvendorsand businesspartnersonlywhen neededbyvendorsandbusiness partners,withimmediate deactivationafteruse 12.3.10 Forpersonnelaccessing cardholderdataviaremote]access technologies,prohibitthecopying, moving,andstorageofcardholder dataontolocalharddrivesand removableelectronicmedia, unlessexplicitlyauthorizedfora definedbusinessneed. Wherethereisanauthorized businessneed,theusagepolicies mustrequirethedatabe protectedinaccordancewithall applicablepcidssrequirements. 12.4 Ensurethatthesecuritypolicyand proceduresclearlydefine informationsecurity responsibilitiesforallpersonnel. 12.5 Assigntoanindividualorteamthe followinginformationsecurity managementresponsibilities: 12.5.1 Establish,document,and distributesecuritypoliciesand procedures. 12.5.2 Monitorandanalyzesecurityalerts andinformation,anddistributeto appropriatepersonnel.
12.5.3 Establish,document,and distributesecurityincident responseandescalation procedurestoensuretimelyand effectivehandlingofallsituations. 12.5.4 Administeruseraccounts, includingadditions,deletions,and modifications. 12.5.5 Monitorandcontrolallaccessto data. 12.6 Implementaformalsecurity awarenessprogramtomakeall personnelawareofthe importanceofcardholderdata security. 12.6.1 Educatepersonneluponhireand atleastannually. Note:Methodscanvarydepending ontheroleofthepersonneland theirlevelofaccesstothe cardholderdata. 12.6.2 Requirepersonneltoacknowledge atleastannuallythattheyhave readandunderstoodthesecurity policyandprocedures.
12.7 Screenpotentialpersonnelpriorto 12.8 hiretominimizetheriskofattacks frominternalsources.(examples ofbackgroundchecksinclude previousemploymenthistory, criminalrecord,credithistory,and referencechecks.) Note:Forthosepotential personneltobehiredforcertain positionssuchasstorecashiers whoonlyhaveaccesstoonecard numberatatimewhenfacilitating atransaction,thisrequirementisa recommendationonly. Maintainandimplementpolicies andprocedurestomanageservice providerswithwhomcardholder dataisshared,orthatcouldaffect thesecurityofcardholderdata,as follows: 12.8.1 Maintainalistofserviceproviders.
12.8.2 Maintainawrittenagreementthat 12.8.3 includesanacknowledgementthat theserviceprovidersare responsibleforthesecurityof cardholderdatatheservice providerspossessorotherwise store,processortransmiton behalfofthecustomer,ortothe extentthattheycouldimpactthe securityofthecustomer s cardholderdataenvironment. Note:Theexactwordingofan acknowledgementwilldependon theagreementbetweenthetwo parties,thedetailsoftheservice beingprovided,andthe responsibilitiesassignedtoeach party.theacknowledgementdoes nothavetoincludetheexact wordingprovidedinthis requirement. Ensurethereisanestablished processforengagingservice providersincludingproperdue diligencepriortoengagement. 12.8.4 Maintainaprogramtomonitor serviceproviders PCIDSS compliancestatusatleast annually. 12.8.5 Maintaininformationaboutwhich PCIDSSrequirementsare managedbyeachserviceprovider, andwhicharemanagedbythe entity.
12.9 Additionalrequirementforservice providers:serviceproviders acknowledgeinwritingto customersthattheyare responsibleforthesecurityof cardholderdatatheservice providerpossessesorotherwise stores,processes,ortransmitson behalfofthecustomer,ortothe extentthattheycouldimpactthe securityofthecustomer s cardholderdataenvironment. Note:Thisrequirementisabest practiceuntiljune30,2015,after whichitbecomesarequirement. Note:Theexactwordingofan acknowledgementwilldependon theagreementbetweenthetwo parties,thedetailsoftheservice beingprovided,andthe responsibilitiesassignedtoeach party.theacknowledgementdoes nothavetoincludetheexact wordingprovidedinthis requirement. 12.10 Implementanincidentresponse plan.bepreparedtorespond immediatelytoasystembreach.
12.10.1 Createtheincidentresponseplan 12.10.2 tobeimplementedintheeventof systembreach.ensuretheplan addressesthefollowing,ata minimum: ]Roles,responsibilities,and communicationandcontact strategiesintheeventofa compromiseincludingnotification ofthepaymentbrands,ata minimum ]Specificincidentresponse procedures ]Businessrecoveryandcontinuity procedures ]Databackupprocesses ]Analysisoflegalrequirementsfor reportingcompromises ]Coverageandresponsesofall criticalsystemcomponents ]Referenceorinclusionofincident responseproceduresfromthe paymentbrands. Testtheplanatleastannually. 12.10.3 Designatespecificpersonneltobe availableona24/7basisto respondtoalerts. 12.10.4 Provideappropriatetrainingto staffwithsecuritybreachresponse responsibilities.
12.10.5 Includealertsfromsecurity monitoringsystems,includingbut notlimitedtointrusion]detection, 12.10.6 intrusion]prevention,firewalls,and file]integritymonitoringsystems. Developaprocesstomodifyand evolvetheincidentresponseplan accordingtolessonslearnedand toincorporateindustry developments. A.1 Protecteachentity s(thatis, merchant,serviceprovider,or otherentity)hostedenvironment anddata,pera.1.1througha.1.4: Ahostingprovidermustfulfill theserequirementsaswellasall otherrelevantsectionsofthepci DSS. Note:Eventhoughahosting providermaymeetthese requirements,thecomplianceof theentitythatusesthehosting providerisnotguaranteed.each entitymustcomplywiththepci DSSandvalidatecomplianceas applicable. A.1.1 Ensurethateachentityonlyruns processesthathaveaccesstothat entity scardholderdata environment. A.1.2 Restricteachentity saccessand privilegestoitsowncardholder dataenvironmentonly.
A.1.3 A.1.4 Ensureloggingandaudittrailsare enabledanduniquetoeach entity scardholderdata environmentandconsistentwith PCIDSSRequirement10. Enableprocessestoprovidefor timelyforensicinvestigationinthe eventofacompromisetoany hostedmerchantorservice provider.