WIXLIB

only3.2.3 Do not store the personal identificationnumber (PIN) or the encrypted PIN block afterauthorization.X3.3 Mask PAN when displayed (the first six and lastfour digits are the maximum number of digits to bedisplayed), such that only personnel with alegitimate business need can see more than thefirst six/last four digits of the PAN.Note: This requirement does not supersede stricterrequirements in place for displays of cardholderdata—for example, legal or payment card brandrequirements for point- of-sale (POS) receipts.X3.4 Render PAN unreadable anywhere it is stored(including on portable digital media, backup media,and in logs) by using any of the followingapproaches: One-way hashes based on strong cryptography,(hash must be of the entire PAN) Truncation (hashing cannot be used to replacethe truncated segment of PAN) Index tokens and pads (pads must be securelystored) Strong cryptography with associatedkey-management processes and procedures.Note: It is a relatively trivial effort for a maliciousindividual to reconstruct original PAN data if theyhave access to both the truncated and hashedversion of a PAN. Where hashed and truncatedversions of the same PAN are present in an entity’senvironment, additional controls must be in placeto ensure that the hashed and truncated versionscannot be correlated to reconstruct the originalPAN.XType BMerchantonly11 of 43

3.4.1 If disk encryption is used (rather than file- orcolumn-level database encryption), logical accessmust be managed separately and independently ofnative operating system authentication and accesscontrol mechanisms (for example, by not usinglocal user account databases or general networklogin credentials). Decryption keys must not beassociated with user accounts.Note: This requirement applies in addition to allother PCI DSS encryption and key- managementrequirements.X3.5 Document and implement procedures toprotect keys used to secure stored cardholder dataagainst disclosure and misuse:Note: This requirement applies to keys used toencrypt stored cardholder data, and also applies tokey-encrypting keys used to protectdata-encrypting keys—such key- encrypting keysmust be at least as strong as the data-encryptingkey.X3.5.1 Additional requirement for service providersonly: Maintain a documented description of thecryptographic architecture that includes: Details of all algorithms, protocols, and keys usedfor the protection of cardholder data, including keystrength and expiry date Description of the key usage for each key Inventory of any HSMs and other SCDs used forkey managementX3.5.2 Restrict access to cryptographic keys to thefewest number of custodians necessary.X12 of 43

3.5.3 Store secret and private keys used toencrypt/decrypt cardholder data in one (or more)of the following forms at all times: Encrypted with a key-encrypting key that is atleast as strong as the data- encrypting key, and thatis stored separately from the data-encrypting key Within a secure cryptographic device (such as ahardware (host) security module (HSM) orPTS-approved point-of-interaction device) As at least two full-length key components or keyshares, in accordance with an industry- acceptedmethodNote: It is not required that public keys be stored inone of these forms.X3.5.4 Store cryptographic keys in the fewestpossible locations.X3.6 Fully document and implement all keymanagement processes and procedures forcryptographic keys used for encryption ofcardholder data, including the following:Note: Numerous industry standards for keymanagement are available from various resourcesincluding NIST, which can be found athttp://csrc.nist.gov.X3.6.1 Generation of strong cryptographic keysX3.6.2 Secure cryptographic key distributionX3.6.3 Secure cryptographic key storageX3.6.4 Cryptographic key changes for keys that havereached the end of their cryptoperiod (for example,after a defined period of time has passed and/orafter a certain amount of cipher-text has beenproduced by a given key), as defined by theassociated application vendor or key owner, andbased on industry best practices and guidelines (forX13 of 43

example, NIST Special Publication 800-57).3.6.5 Retirement or replacement (for example,archiving, destruction, and/or revocation) of keysas deemed necessary when the integrity of the keyhas been weakened (for example, departure of anemployee with knowledge of a clear-text keycomponent), or keys are suspected of beingcompromised.Note: If retired or replaced cryptographic keysneed to be retained, these keys must be securelyarchived (for example, by using a key-encryptionkey). Archived cryptographic keys should only beused for decryption/verification purposes.X3.6.6 If manual clear-text cryptographickey-management operations are used, theseoperations must be managed using split knowledgeand dual control.Note: Examples of manual key- managementoperations include, but are not limited to: keygeneration, transmission, loading, storage anddestruction.X3.6.7 Prevention of unauthorized substitution ofcryptographic keys.X3.6.8 Requirement for cryptographic keycustodians to formally acknowledge that theyunderstand and accept their key-custodianresponsibilities.X3.7 Ensure that security policies and operationalprocedures for protecting stored cardholder dataare documented, in use, and known to all affectedparties.XRequirement 4: Encrypt transmission of cardholder data across open,public networks14 of 43

4.1 Use strong cryptography and security protocolsto safeguard sensitive cardholder data duringtransmission over open, public networks, includingthe following: Only trusted keys and certificates are accepted. The protocol in use only supports secure versionsor configurations. The encryption strength is appropriate for theencryption methodology in use.Examples of open, public networks include but arenot limited to: The Internet Wireless technologies, including 802.11and Bluetooth Cellular technologies, for example, Global Systemfor Mobile communications (GSM), Code divisionmultiple access (CDMA) General Packet Radio Service (GPRS) Satellite communicationsX4.1.1 Ensure wireless networks transmittingcardholder data or connected to the cardholderdata environment, use industry best practices toimplement strong encryption for authenticationand transmission.X4.2 Never send unprotected PANs by end- usermessaging technologies (for example, e- mail,instant messaging, SMS, chat, etc.).4.3 Ensure that security policies and operationalprocedures for encrypting transmissions ofcardholder data are documented, in use, andknown to all affected parties.XXRequirement 5: Protect all systems against malware and regularly updateanti-virus software or programs15 of 43

X5.1 Deploy anti-virus software on all systemscommonly affected by malicious software(particularly personal computers and servers).Type BMerchantonlyX5.1.1 Ensure that anti-virus programs are capableof detecting, removing, and protecting against allknown types of malicious software.5.1.2 For systems considered to be not commonlyaffected by malicious software, perform periodicevaluations to identify and evaluate evolvingmalware threats in order to confirm whether suchsystems continue to not require anti-virussoftware.Type BMerchantonlyXType BMerchantonly5.2 Ensure that all anti-virus mechanisms aremaintained as follows: Are kept current,X Perform periodic scans Generate audit logs which are retained per PCIDSS Requirement 10.7.Type BMerchantonly5.3 Ensure that anti-virus mechanisms are activelyrunning and cannot be disabled or altered by users,unless specifically authorized by management on acase-by-case basis for a limited time period.Note: Anti-virus solutions may be temporarilydisabled only if there is legitimate technical need,as authorized by management on a case-by-casebasis. If anti-virus protection needs to be disabledfor a specific purpose, it must be formallyauthorized. Additional security measures may alsoneed to be implemented for the period of timeduring which anti-virus protection is not active.XType BMerchantonlyX5.4 Ensure that security policies and operationalprocedures for protecting systems against malwareare documented, in use, and known to all affectedparties.Type BMerchantonly16 of 43

Requirement 6: Develop and maintain secure systems and applications6.1 Establish a process to identify securityvulnerabilities, using reputable outside sources forsecurity vulnerability information, and assign a riskranking (for example, as “high,” “medium,” or“low”) to newly discovered security vulnerabilities.Note: Risk rankings should be based on industrybest practices as well as consideration of potentialimpact. For example, criteria for rankingvulnerabilities may include consideration of theCVSS base score, and/or the classification by thevendor, and/or type of systems affected.Methods for evaluating vulnerabilities andassigning risk ratings will vary based on anorganization’s environment and risk- assessmentstrategy. Risk rankings should, at a minimum,identify all vulnerabilities considered to be a “highrisk” to the environment. In addition to the riskranking, vulnerabilities may be considered “critical”if they pose an imminent threat to theenvironment, impact critical systems, and/orwould result in a potential compromise if notaddressed. Examples of critical systems mayinclude security systems, public-facing devices andsystems, databases, and other systems that store,process, or transmit cardholder data.X6.2 Ensure that all system components andsoftware are protected from known vulnerabilitiesby installing applicable vendor- supplied securitypatches. Install critical security patches within onemonth of release.Note: Critical security patches should be identifiedaccording to the risk ranking process defined inRequirement 6.1.X17 of 43

6.3 Develop internal and external softwareapplications (including web-based administrativeaccess to applications) securely, as follows: In accordance with PCI DSS (for example, secureauthentication and logging) Based on industry standards and/or bestpractices. Incorporating information security throughoutthe software-development life cycleNote: this applies to all software developedinternally as well as bespoke or custom softwaredeveloped by a third party.X6.3.1 Remove development, test and/or customapplication accounts, user IDs, and passwordsbefore applications become active or are releasedto customers.X6.3.2 Review custom code prior to release toproduction or customers in order to identify anypotential coding vulnerability (using either manualor automated processes) to include at least thefollowing: Code changes are reviewed by individuals otherthan the originating code author, and byindividuals knowledgeable about code-reviewtechniques and secure coding practices. Code reviews ensure code is developed accordingto secure coding guidelines Appropriate corrections are implemented prior torelease. Code-review results are reviewed and approvedby management prior to release.Note: This requirement for code reviews applies toall custom code (both internal and public-facing),as part of the system development life cycle.XCode reviews can be conducted by knowledgeable18 of 43

internal personnel or third parties. Public-facingweb applications are also subject to additionalcontrols, to address ongoing threats andvulnerabilities after implementation, as defined atPCI DSS Requirement 6.6.6.4 Follow change control processes andprocedures for all changes to system components.The processes must include the following:X6.4.1 Separate development/test environmentsfrom production environments, and enforce theseparation with access controls.X6.4.2 Separation of duties betweendevelopment/test and production environmentsX6.4.3 Production data (live PANs) are not used fortesting or developmentX6.4.4 Removal of test data and accounts fromsystem components before the system becomesactive / goes into production.X6.4.5 Change control procedures must include thefollowing:X6.4.5.1 Documentation of impact.X6.4.5.2 Documented change approval by authorizedparties.X6.4.5.3 Functionality testing to verify that thechange does not adversely impact the security ofthe system.X6.4.5.4 Back-out procedures.X6.4.6 Upon completion of a significant change, allrelevant PCI DSS requirements must beimplemented on all new or changed systems andnetworks, and documentation updated asapplicable.X19 of 43

6.5 Address common coding vulnerabilities insoftware-development processes as follows: Train developers at least annually in up- to-datesecure coding techniques, including how to avoidcommon coding vulnerabilities. Develop applications based on secure codingguidelines.Note: The vulnerabilities listed at 6.5.1 through6.5.10 were current with industry best practiceswhen this version of PCI DSS was published.However, as industry best practices forvulnerability management are updated (forexample, the OWASP Guide, SANS CWE Top 25,CERT Secure Coding, etc.), the current bestpractices must be used for these requirements.X6.5.1 Injection flaws, particularly SQL injection.Also consider OS Command Injection, LDAP andXPath injection flaws as well as other injectionflaws.X6.5.2 Buffer overflowsX6.5.3 Insecure cryptographic storageX6.5.4 Insecure communicationsX6.5.5 Improper error handlingX6.5.6 All “high risk” vulnerabilities identified in thevulnerability identification process (as defined inPCI DSS Requirement 6.1).X6.5.7 Cross-site scripting (XSS)X6.5.8 Improper access control (such as insecuredirect object references, failure to restrict URLaccess, directory traversal, and failure to restrictuser access to functions).X6.5.9 Cross-site request forgery (CSRF)X20 of 43

6.5.10 Broken authentication and sessionmanagementX6.6 For public-facing web applications, address newthreats and vulnerabilities on an ongoing basis andensure these applications are protected againstknown attacks by either of the following methods: Reviewing public-facing web applications viamanual or automated application vulnerabilitysecurity assessment tools or methods, at leastannually and after any changesNote: This assessment is not the same as thevulnerability scans performed for Requirement11.2. Installing an automated technical solution thatdetects and prevents web- based attacks (forexample, a web- application firewall) in front ofpublic- facing web applications, to continuallycheck all traffic.X6.7 Ensure that security policies and operationalprocedures for developing and maintaining securesystems and applications are documented, in use,and known to all affected parties.XRequirement 7: Restrict access to cardholder data by business need toknow7.1 Limit access to system components andcardholder data to only those individuals whosejob requires such access.X7.1.1 Define access needs for each role, including: System components and data resources that eachrole needs to access for their job function Level of privilege required (for example, user,administrator, etc.) for accessing resources.X7.1.2 Restrict access to privileged user IDs to leastprivileges necessary to perform job responsibilities.X21 of 43

7.1.3 Assign access based on individual personnel’sjob classification and function.X7.1.4 Require documented approval by authorizedparties specifying required privileges.X7.2 Establish an access control system for systemscomponents that restricts access based on a user’sneed to know, and is set to “deny all” unlessspecifically allowed.This access control system must include thefollowing:X7.2.1 Coverage of all system componentsX7.2.2 Assignment of privileges to individuals basedon job classification and function.X7.2.3 Default “deny-all” setting.X7.3 Ensure that security policies and operationalprocedures for restricting access to cardholder dataare documented, in use, and known to all affectedparties.XRequirement 8: Identify and authenticate access to system components8.1 Define and implement policies and proceduresto ensure proper user identification managementfor nonconsumer users and administrators on allsystem components as follows:X8.1.1 Assign all users a unique ID before allowingthem to access system components or cardholderdata.X8.1.2 Control addition, deletion, and modificationof user IDs, credentials, and other identifierobjects.X8.1.3 Immediately revoke access for anyterminated users.X22 of 43

8.1.4 Remove/disable inactive user accounts atleast every 90 days.X8.1.5 Manage IDs used by third parties to access,support, or maintain system components viaremote access as follows: Enabled only during the time period needed anddisabled when not in use. Monitored when in use.X8.1.6 Limit repeated access attempts by locking outthe user ID after not more than six attempts.X8.1.7 Set the lockout duration to a minimum of 30minutes or until an administrator enables the userID.X8.1.8 If a session has been idle for more than 15minutes, require the user to re-authenticate tore-activate the terminal or session.X8.2 In addition to assigning a unique ID, ensureproper user-authentication management fornon-consumer users and administrators on allsystem components by employing at least one ofthe following methods to authenticate all users: Something you know, such as a password orpassphrase Something you have, such as a token device orsmart card Something you are, such as a biometric.X8.2.1 Using strong cryptography, render allauthentication credentials (such aspasswords/phrases) unreadable duringtransmission and storage on all systemcomponents.X8.2.2 Verify user identity before modifying anyauthentication credential—for example,X23 of 43

performing password resets, provisioning newtokens, or generating new keys.8.2.3 Passwords/passphrases must meet thefollowing: Require a minimum length of at least sevencharacters. Contain both numeric and alphabetic characters.Alternatively, the passwords/ passphrases musthave complexity and strength at least equivalent tothe parameters specified above.X8.2.4 Change user passwords/passphrases at leastevery 90 days.X8.2.5 Do not allow an individual to submit a newpassword/phrase that is the same as any of the lastfour passwords/phrases he or she has used.X8.2.6 Set passwords/phrases for first time use andupon reset to a unique value for each user, andchange immediately after the firstX8.3 Secure all individual non-console administrativeaccess and all remote access to the CDE usingmulti-factor

The PCI Responsibility Matrix is intended to provide Volusion merchants a reference for those requirements within the PCI Data Security Standard (PCI DSS) which they bear responsibility and those which are the responsibility of Volusion as a PCI registered service provider. It is designed to meet Requirement 12.8.5 of the PCI DSS.