pci_dss_v1-2 (1027411), страница 5
Текст из файла (страница 5)
Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. Forexample, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is notneeded, and not sending PAN in unencrypted e-mails.Please refer to the PCI DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms.PCI DSS RequirementsTesting Procedures3.1Keep cardholder data storage toa minimum. Develop a data retention anddisposal policy. Limit storage amountand retention time to that which isrequired for business, legal, and/orregulatory purposes, as documented inthe data retention policy.3.1Obtain and examine the company policies andprocedures for data retention and disposal, and perform thefollowingVerify that policies and procedures include legal,regulatory, and business requirements for dataretention, including specific requirements forretention of cardholder data (for example,cardholder data needs to be held for X period for Ybusiness reasons)Verify that policies and procedures includeprovisions for disposal of data when no longerneeded for legal, regulatory, or business reasons,including disposal of cardholder dataVerify that policies and procedures includecoverage for all storage of cardholder dataVerify that policies and procedures include aprogrammatic (automatic) process to remove, atleast on a quarterly basis, stored cardholder datathat exceeds business retention requirements, or,alternatively, requirements for a review, conductedat least on a quarterly basis, to verify that storedcardholder data does not exceed businessretention requirementsPCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCIn PlaceNot inPlaceTarget Date/CommentsOctober 2008Page 20PCI DSS Requirements3.2Do not store sensitiveauthentication data after authorization(even if encrypted).Sensitive authentication data includes thedata as cited in the following Requirements3.2.1 through 3.2.3:3.2.1 Do not store the full contents ofany track from the magnetic stripe(located on the back of a card, containedin a chip, or elsewhere).
This data isalternatively called full track, track, track1, track 2, and magnetic-stripe data.Note: In the normal course of business,the following data elements from themagnetic stripe may need to be retained: The cardholder’s name, Primary account number (PAN), Expiration date, and Service codeTo minimize risk, store only these dataelements as needed for business.Testing ProceduresIn PlaceNot inPlaceTarget Date/Comments3.2If sensitive authentication data is received anddeleted, obtain and review the processes for deleting thedata to verify that the data is unrecoverable.For each item of sensitive authentication data below,perform the following steps:3.2.1 For a sample of system components, examine thefollowing and verify that the full contents of any track fromthe magnetic stripe on the back of card are not storedunder any circumstance:Incoming transaction dataAll logs (for example, transaction, history,debugging, error)History filesTrace filesSeveral database schemasDatabase contentsNote: See PCI DSS Glossary of Terms,Abbreviations, and Acronyms foradditional information.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 21PCI DSS RequirementsTesting Procedures3.2.2 Do not store the cardverification code or value (threedigit or four-digit number printed onthe front or back of a paymentcard) used to verify card-notpresent transactions.Note: See PCI DSS Glossary ofTerms, Abbreviations, andAcronyms for additionalinformation.3.2.2 For a sample of system components, verify thatthe three-digit or four-digit card-verification code or valueprinted on the front of the card or the signature panel(CVV2, CVC2, CID, CAV2 data) is not stored under anycircumstance:Incoming transaction dataAll logs (for example, transaction, history,debugging, error)History filesTrace filesSeveral database schemasDatabase contents3.2.3 Do not store the personalidentification number (PIN) or theencrypted PIN block.3.2.3 For a sample of system components, examine thefollowing and verify that PINs and encrypted PIN blocksare not stored under any circumstance:Incoming transaction dataAll logs (for example, transaction, history,debugging, error)History filesTrace filesSeveral database schemasDatabase contents3.3Mask PAN when displayed(the first six and last four digits arethe maximum number of digits to bedisplayed).Notes: This requirement does not apply toemployees and other parties witha legitimate business need to seethe full PAN. This requirement does notsupersede stricter requirements inplace for displays of cardholderdata—for example, for point-ofsale (POS) receipts.In PlaceNot inPlaceTarget Date/ Comments3.3Obtain and examine written policies and examinedisplays of PAN (for example, on screen, on paper receipts)to verify that primary account numbers (PANs) are maskedwhen displaying cardholder data, except for those with alegitimate business need to see full PAN.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 22PCI DSS RequirementsTesting Procedures3.4Render PAN, at minimum,unreadable anywhere it is stored(including on portable digital media,backup media, in logs) by using anyof the following approaches: One-way hashes based onstrong cryptography Truncation Index tokens and pads (padsmust be securely stored) Strong cryptography withassociated key-managementprocesses and proceduresThe MINIMUM account informationthat must be rendered unreadable isthe PAN.Notes: If for some reason, a company isunable render the PANunreadable, refer to Appendix B:Compensating Controls. “Strong cryptography” is definedin the PCI DSS Glossary ofTerms, Abbreviations, andAcronyms.3.4.a Obtain and examine documentation about thesystem used to protect the PAN, including the vendor, typeof system/process, and the encryption algorithms (ifapplicable).
Verify that the PAN is rendered unreadableusing one of the following methods:One-way hashes based on strong cryptographyTruncationIndex tokens and pads, with the pads beingsecurely storedStrong cryptography, with associated keymanagement processes and procedures3.4.1 If disk encryption is used(rather than file- or column-leveldatabase encryption), logicalaccess must be managedindependently of native operatingsystem access controlmechanisms (for example, by notusing local user accountdatabases). Decryption keys must3.4.1.aIf disk encryption is used, verify that logicalaccess to encrypted file systems is implemented via amechanism that is separate from the native operatingsystems mechanism (for example, not using local useraccount databases).3.4.1.b Verify that cryptographic keys are storedsecurely (for example, stored on removable media that isadequately protected with strong access controls).In PlaceNot inPlaceTarget Date/ Comments3.4.b Examine several tables or files from a sample ofdata repositories to verify the PAN is rendered unreadable(that is, not stored in plain-text).3.4.c Examine a sample of removable media (forexample, back-up tapes) to confirm that the PAN isrendered unreadable.3.4.d Examine a sample of audit logs to confirm that thePAN is sanitized or removed from the logs.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 23PCI DSS Requirementsnot be tied to user accounts.3.5Protect cryptographic keysused for encryption of cardholderdata against both disclosure andmisuse:Testing ProceduresNot inPlaceTarget Date/ Comments3.4.1.cVerify that cardholder data on removable mediais encrypted wherever stored.Note: Disk encryption often cannot encrypt removablemedia, so data stored on this media will need to beencrypted separately.3.5 Verify processes to protect keys used for encryption ofcardholder data against disclosure and misuse byperforming the following:3.5.1 Restrict access tocryptographic keys to the fewestnumber of custodians necessary.3.5.1 Examine user access lists to verify that access tokeys is restricted to very few custodians.3.5.2 Store cryptographic keyssecurely in the fewest possiblelocations and forms.3.5.2 Examine system configuration files to verify thatkeys are stored in encrypted format and that keyencrypting keys are stored separately from dataencrypting keys.3.6Fully document andimplement all key-managementprocesses and procedures forcryptographic keys used forencryption of cardholder data,including the following:In Place3.6.a Verify the existence of key-management proceduresfor keys used for encryption of cardholder data.Note: Numerous industry standards for key managementare available from various resources including NIST, whichcan be found at http://csrc.nist.gov.3.6.b For service providers only: If the service providershares keys with their customers for transmission ofcardholder data, verify that the service provider providesdocumentation to customers that includes guidance on howto securely store and change customer’s keys (used totransmit data between customer and service provider).3.6.cExamine the key-management procedures andperform the following:3.6.1 Generation of strongcryptographic keys3.6.1 Verify that key-management procedures areimplemented to require the generation of strong keys.3.6.2 Secure cryptographic keydistribution3.6.2 Verify that key-management procedures areimplemented to require secure key distribution.3.6.3 Secure cryptographic keystorage3.6.3 Verify that key-management procedures areimplemented to require secure key storage.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 24PCI DSS RequirementsTesting Procedures3.6.4 Periodic cryptographic keychangesAs deemed necessary andrecommended by theassociated application (forexample, re-keying);preferably automaticallyAt least annually3.6.4 Verify that key-management procedures areimplemented to require periodic key changes at leastannually.3.6.5 Retirement or replacementof old or suspected compromisedcryptographic keys3.6.5.a Verify that key-management procedures areimplemented to require the retirement of old keys (forexample: archiving, destruction, and revocation asapplicable).In PlaceNot inPlaceTarget Date/ Comments3.6.5.b Verify that the key-management procedures areimplemented to require the replacement of known orsuspected compromised keys.3.6.6 Split knowledge andestablishment of dual control ofcryptographic keys3.6.6 Verify that key-management procedures areimplemented to require split knowledge and dual control ofkeys (for example, requiring two or three people, eachknowing only their own part of the key, to reconstruct thewhole key).3.6.7 Prevention of unauthorizedsubstitution of cryptographic keys3.6.7 Verify that key-management procedures areimplemented to require the prevention of unauthorizedsubstitution of keys.3.6.8 Requirement forcryptographic key custodians tosign a form stating that theyunderstand and accept their keycustodian responsibilities3.6.8 Verify that key-management procedures areimplemented to require key custodians to sign a formspecifying that they understand and accept their keycustodian responsibilities.PCI DSS Requirements and Security Assessment Procedures, v1.2Copyright 2008 PCI Security Standards Council LLCOctober 2008Page 25Requirement 4: Encrypt transmission of cardholder data across open, public networksSensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
