Requirement 3: Protect stored cardholder data

Protect stored cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI DSS terms.

Section PCI Requirement Comments Provided by Artsman Cloud
3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all card holder data (CHD) storage:
  • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements
  • Specific retention requirements for cardholder data
  • Processes for secure deletion of data when no longer needed
  • A quarterly automatic or manual process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements
 Theatre Manager provides automatic retention and shredding capability which removes stale card information based on a retention period and/or usage for recurring transactions.

We generally recommend a maximum of 30 days for card retention, and this is only for future authorizations to supplement the original sales in case of changes. See below for post dated payments and/or which do not factor into the retention period.

There is an option to never store card information allowing a venue to implement either Schedule C or D compliance. For web Sales you can even implement Schedule A if using Moneris hosted payment.

Venues that occasionally refund to cancelled concerts do not need to store credit card data specifically for that purpose. All providers currently support linked refunds - meaning they refund to the same order and card using tokens, without needing card data stored in the database.

Post dated payments cause a card to be retained until the last automatic payment is processed, after which it is deleted.

Cloud only permits
  • Schedule A-EP - using Moneris Hosted Payments
  • Schedule C - keep no card data
  • Schedule D - with one day retention for post dated payments only
3.2 Do not store sensitive authentication data after authorization (even if it is encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process

Sensitive authentication data includes the data as cited in the following requirements 3.2.1 through 3.2.3

 Refer to PCI compliance statement on PAN etc.

Should the end user put credit card data into any text field (against recommended practice), Theatre Manager offers an option to search the database for possible entry of credit card numbers in non-payment text fields.

NO - Customer must occasionally search for end user entry errors
3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: in the normal course of business, the following data elements fro mthe magnetic stripe may need to be retained:

  • The cardholders name
  • Primary account number (PAN)
  • Expiration Date
  • Service Code
To minimize risk, store only these data elements as needed for business		 If a card is swiped, the only information retained from the swipe are the following
  • The cardholders name
  • Card number (PAN), encrypted
  • Expiration Date
Theatre Manager has NEVER stored CVV2, mag stripe, or pin block data per PCI requirements. 		N/A
3.2.2 Do not store the card-verification code or value (three-digit or four- digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization Theatre Manager does not store this data to disk under any circumstances - it is merely passed through to the credit card authorizer. N/A
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block. Theatre Manager does not support entry or storage of PIN. N/A
3.3

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personell with a legitimate busines need can see the full PAN.

Note: this requirement does not supercede stricter requirements in place for displays of cardholder data - for example, legal or payment card rand requirements for point-of-sale (POS) receipts

Theatre Manager follows these rules. Card numbers are displayed as last four digits only and is only revealed if employee has permission - in which case it is logged.

All reports and most windows mask PAN

External receipt printing or web interface uses a common routine to mask the PAN immediately upon retrieval from the database so that last 4 digits only are displayed per law in most states.

 N/A
3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
  • One-way hashes based on strong cryptography
  • Truncation (hashing cannot be used to replace the truncated segment of the PAN)
  • Index tokens and pads (pads must be securely stored)
  • Strong cryptography with associated key management processes and procedures
Note: it is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to the truncated and hashed version of a PAN.		 Theatre Manager uses secure high encryption for all keys and card data. N/A
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. Theatre Manager does not use Disk Encryption.

It uses field level encryption for PAN.

 N/A
3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.

Note: this requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data encrypting keys. Such key encrypting keys must be at least as strong as the data-encrypting key.

 Theatre Manager handles creation and hiding of keys automatically. The user never sees them and cannot input them.

Mechanisms exist for re-encryption of any currently encrypted cards in one of two ways:

  • By the user, on demand where they invoke a function to re-encrypt all card data with a new key (that they don't know)
  • By the system, if cards have not been re-encrypted within the mandated PCI time frame, Theatre Manager will start re-encrpyting them with a new key automatically

Key encryption keys use same cryptographic specification as the encryption keys.

 NO - Customer must protect user account passwords
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary
3.5.2

Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

  • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key
  • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device)
  • As at least two full-length key components or key shares, in accordance with an industry- accepted method
3.5.3

Store crpytographic keys in the fewest possible locations
3.6

Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data including the following:

refer to re-encryption of credit cards for discussion on keys, generation and re-encryption. Any upgrade will automatically perform this process if more than 300 days have elapsed since last re-encrption.

Split 'knowledge' of the keys is achieved by bringing together a key generated programmatically and another portion generated by the customers interfacing with the key creation screen in system preferences.

Both keys are required to generate the final encryption key. Arts Management never has knowledge of the customers portion of the key. The customer never knows the value of any key. A key valid for one database for a period of time will not work on any other database.

Old keys are securely deleted from the database by writing over the key value and then deleting it immediately after a new seed key is generated.

NO - Customer must protect user account passwords
3.6.1 Generation of strong cryptographic keys
3.6.2 Secure cryptographic key distribution
3.6.3 Secure cryptographic key storage
3.6.4

Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher- text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

3.6.5

Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.

3.6.6

If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control

for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key.
3.6.7 Prevention of unauthorized substitution of cryptographic keys
3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities

Venues do not know the cryptographic key.

However, they should have a form signed by the people/person responsible for key management that they reset the key once a year at a minimum or when suspected compromise occurs. Note it will be changed automatically on you during an upgrade if Theatre Manager detects it hasn't been changed for 300 days.
3.7

Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

  SPLIT
  • Artsman: This documentation and Artsman staff training
  • Customer: Training of own staff