PCI Security Tab

The PCI Security tab allows the Master User to set the overall parameters of how Employees will log on to the database, the structure of their passwords, and important PCI Compliance considerations for managing retention of credit card data.

Employee Access Management

Logon Window Setting	Offers the option to have Employees login: As a List of Employees Using their Access ID and password
Minimum Length	Sets the minimum length of logon passwords. For PCI compliance, the minimum length is 7 characters.
Unique Passwords	The number of unique passwords required by the system. If set to zero, then passwords are not required to be unique. If set to 2, then the same password may be shared by two employees. If set to 3, then the same password may be shared by three employees.
Days til Change Allowed	The minimum number of days that a password must be used before it is allowed to be changed.
Days until Expiry	The maximum number of days that a password may be used. For PCI compliance, this must not exceed 90 days.
Attempts til Lockout	This determines how many incorrect attempts an employee may make before Theatre Manager will lock them out of the system and must be manually re-instated.
IP addresses that can accept cards	PCI documentation indicates that any machine that touches credit card information becomes within scope of PCI compliance requirements. If you identify which machines process credit cards (such as box office), then other machines on the network that are used for reporting, management, etc, can be taken out of scope for PCI compliance. To do so, you can indicate a white-list specific machines or subnet of machines that will process cards by: leaving the list blank to indicate ALL machines process cards Entering one or more specific ip address (eg 192.168.0.10) to indicate specific machines that accept cards Entering one or more subnet masks using CIDR format to indicate a range of machines. For example: 10.10.1.0/24 means all machines on the 10.10.1.x subnet. 10.100.0.0/16 means all machines on the 10.100.x.x subnet. Entering a combination of specific ip addresses or subnet masks Enter a specific IP address that is not on your network so that NO user workstations can accept credit cards anywhere If a machine is whitelisted to allow entering credit cards, then those payment methods appear on the payment window as normal. Machines that are not part of the whitelist, then the credit card payment methods are removed from the payment window and the user at that workstation will not be able to enter cards at all - they will need to go to another machine with permissions to process a credit card payment.
	Clicking this button changes options to the current PCI Standards for employee passwords and logon attempts.

Patron Access Management

Patron Password Complexity

You can set the required complexity of patron passwords in Theatre Manager to two levels:

Passwords must meet the minimum length only. This is the historical setting - and forces the passwords to be at least the same length as the employee PCI passwords. It does not enforce any other rules. Normally, this is sufficient and the web pages give a strength meter to people to indicate if the password is good enough, or not. The reason this is the default setting is because many people have complex enough passwords that they use with modification on various sites, simply by meeting the length criteria, but may not have a special character or some other element. It also helps avoid patron frustration.
Passwords used by patrons must meet the same PCI standards enforced on employees that are:
- At least one upper case character
- At least one lower case character
- At least one number
- At least one special character
- and minimum length as described in your employee password settings.

Credit Card Management

Theatre Manager can implement either Schedule "A-EP", "C" or "D" for the Self-Assessment Questionnaire (SAQ) - the choice is yours and is dependant on the merchant processor you've selected.

You can define a retention period for credit card information before it is 'shredded' per PCI DSS standard 3.1

Note: Users find ways to type credit card into note fields, more so when using Schedule 'C' compliance because the credit card storage capability has been disabled.

You can use a feature in the Patron List window to search and identify data that could be construed as clear text credit cards attached to patrons. That kind of data would be in violation of PCI guidelines.

A shredded card means that it will be stored in the database as '#### **** **** ####'. This renders the PAN useless for all purposes. However, given the first 4 and last 4 digits of any card, you can still search for the patron.

Converting from schedule D to Schedule C compliance will shred all cards currently in the database EXCEPT those set up for future post dated payments. Since that business already exists, those few cards will remain until the final post date payment is take for the patron. At that time, the card will be shredded immediately. This prevents disruption of existing commitments to patrons.

Generally, if you want to take post dated payments and retain the minimum card data in the database, use Schedule D with one day retention.

Schedule C: Shred cards immediately after use	Using an online payment gateway and the Schedule "C" setting means that cards will not be stored in the database. The PAN is sent to the processor to get the authorization code and token from the merchant provider. Those are stored in TM (not the card itself) and the merchant token is what is used for voiding cards. It puts the workstation in scope of a PCI device, but not the database.
Schedule D: Encrypted credit card data	Schedule "D" compliance with about 120 days of retention is sufficient for most venues, especially if you are using post dated payments or may have to deal with refunds for cancelled events.
Retention Period	The number of days credit card information will be retained before it is shredded in a Schedule D environment. Normally 90 days will handle most business cases, and the recommended maximum is 365 days. If you set it to one day, then all cards are shredded right away, except those that are saved for post dated payments.
Schedule D: Post Dated Payments	This option allows storage of encrypted cards for post dated or recurring payments only. Once the last payment is authorized, the card is shredded. It effectively, is the same as the above option with 1 day retention, except that it is far more restrictive in when Theatre Manager will try to make a stored card. This should result is a venue having vastly reduced exposure risk for stored cards under PCI.
	Generates a completely random 60 character key to use as part of the encryption key process that will be unique to the venue and re-encrypt all cards in the database.
	Immediately shreds credit cards longer than the Retention Period as noted above.

Diataxis:

Reference

Search Patron Data for Credit Card Information

Mask PAN when displayed; the first six and last four digits are the maximum number of digits you may display. Not applicable for authorized people with a legitimate business need to see the full PAN. Does not supersede stricter requirements in place for displays of cardholder data such as on a point-of-sale receipt. PCI DSS standard 3.3.

Use this feature to identify where there may be data attached to patrons that could be construed as a possible clear text credit card in violation of PCI DSS standard 3.3.

When using this search option, patrons will be listed that have a series of 3 or 4 numbers repeated 4 times. This means that anything with at least 12 contiguous digits in the various search fields might result in a match (note: it may not be a credit card).

Searching for at least 13 contiguous digits might find things like 4500 000 000 000 or 5200 0000 0000 0000. It doesn't matter if there are one or more spaces between the numbers or not. Data that will not be found are phone numbers like 518-444-5555. However, it may find conditions where numbers are separated by something other than spaces.

	When searching for card information, the prospective full credit card number is subjected to the same LUHN test the bank uses to identify if it is a card. If the string of numbers do not pass the LUHN text, it will not be identified as a credit card
	A full PCI scan on the raw files in machine with a TM database on it COULD provide FALSE POSITIVES, if you are using SVG maps and pick your own seats. The vector information for points in a map contain a lot of numbers which consistently fool disk level PCI scan's into thinking they are credit cards.

Fields searched for possible card data are:

Patron
- general notes, volunteer notes, donor notes, household notes, and the three customizable note fields on the notes tab
- marketing field #5
- donor publication name
- Special Needs Notes
- GST/HST numbers
- Client asset notes entered on the client asset setup in the 'donor' tab on the patron window.
- These could be entered on the various tabs in the patron window.
Donation
- Donation notes, custom fields, donation publication name, tax receipt name and other donation text fields.
- These would be seen on the donation window.
Order
- Internal and external order notes and ticket comments
- The order PO number
- These would be seen on an order payment window and can also be seen in a list of orders
Subscriptions
- The subscription seat change requests
Credit card
- comments or name on card
- These would be seen on the credit card tab on the patron window.
Task/Project notes
- on the task comments window or the project description
Staff/Volunteer History
- Notes on the Activity setup window
- Notes on the history evaluation and duties fields

Fields not searched for any card data

Transaction card number field (T_CARD_NO) is not validated as it contains reference numbers for other payments (e.g. check #'s). If somebody used any payment method that is not of type credit card -- but they typed a valid card number in the field -- there is not much Theatre Manager can do. Since there is no way to manually place an edit check on check number field to verify that it is an actual check number (that look like credit cards) after the fact in Theatre Manager because that leads to audit issues; such as changing past information which Theatre Manager doesn't allow. If there are credit card numbers in the check # field, then it's a manual task for Arts Management Support to find them and clear them. Please contact Arts Management Support directly if this applies to your specific situation.
Theatre Pricing map SVG data - which can be false positive

To search the database for credit card information, you perform the following steps:

Select Setup->Batch Functions->Check Patron Fields For PCI Data
Refer to the menu selection to the right

A window opens that allows the search to begin. Follow the instructions:
- Click the search button on the upper right side of the window to begin
- Wait a while as the system is checking many fields and many database records. It might take up to a minute on larger databases
After clicking the Search button.
Any patrons who have a 13 digit or longer string stored in any of the fields indicated will be displayed.
You can now go through and manually remove the data.
Double click on each line and it will take you to the window where Theatre Manager suspects the issue to be

Click the icon to download the checklist.

Shredding Credit Cards

In Theatre Manager, 'shredding' credit cards means removing the middle 8 digits of a credit card number so that what is stored in the database is only the first four and last four digits of the number: 1234-xxxx-xxxx-1234. Cards stored in this manner cannot be accessed for use (because those 8 digits aren't masked - they really no longer exist). Users can still search the database for a credit card using the first four and last four digits for reporting and transaction history.

There are two choices for 'Shredding' Credit Cards. The first method, Shredding Unused Credit Cards, allows a venue to set the number of days a credit card is stored in the usual encrypted format in the database (and is therefore available for use as a payment method for post-dated payments or in the patron's credit card tab), and then after that period, a card is considered "unused" and is shredded of its middle 8 digits.

The second method, setting the database to Schedule C: Shred Immediately, will shred cards and never store them in the database. This is rarely used, as it may prevent some common or desirable business functions (and maintaining Schedule D: Encrypted Credit Card data, the default PABP/PCI Compliant method will not prevent those functions).

Shredding Unused Credit Cards

this action cannot be undone!

The simplest solution for venues to have a higher degree of security in their database, than that allowed by the PABP/PCI compliant data encryption of the credit card numbers, is to "shred" unused or old credit cards in patron records.

"Shredding" removes the middle 8 digits of the number and renders the card information unusable (as it is stored - you can still swipe or enter the card again in the future with no problem).

To do "shred" a credit card, you perform the following steps:

Open the PCI Security Tab in Setup > System Preferences.
Under Credit Card Management, click the Shred Unused Credit Cards button.
A dialogue opens, asking for a retention period during which cards are considered active (and therefore, not "unused"). We recommend at least 90 days, 365 as the longest.
Click Shred Cards to immediately shred cards that have not been used in a number of days greater than that set as the retention period.

Schedule C Shred When Used

All the credit card data in theatre Manager is stored using AES256 encryption with rotating keys. An independant company has auditied the safety of the information and practices in theatre Manager to ensure it meets PCI PA/DSS 2.0 storage requirements. Visa has approved Theatre Manager as an application that can accept credit card payments using best practices.

A venue may choose to shred cards immediately after use for added security. This means that full card data is never stored in the database. Voids can only be done using the merchant providers internal token if you have not yet done end of day. After end of day is completed, refunds require you to input the card number again.

Shredding Credit Cards stores only the first and last 4 digits of a credit card number for informational purposes. For example:

When you shred yoiur credit card date the following business capabilities and functions are impacted:

You cannot process post dated payments
You will not be able to refund using the original payment/credit card number. You will have to ask the patron to give you the number again.
You may not be able to refund an entire event using the card used for purchase
You will be unable to process automatic season renewal.
All existing payment / credit card information within the system is now unavailable.

The above are only a few functions that will be impacted.

If your venue wants to shred credit cards after use, you perform the following steps:

Make a complete backup of your Theatre Manager Database just in case you want to change your mind later. Click here for more information on Backing up.
Chose main menu item Setup >> System Preferences.

The System Preferences window opens.
Click the PCI Security tab.
In the Credit Card Management section, change the radio button to Schedule C: Shred cards immediately after use.

The first Warning dialog opens.
Click the Yes button.
The second Warning dialog opens.
Click the Yes button.
The third Warning dialog opens.
Click the Yes button.
The fourth Warning dialog opens.
Click the Yes button.
The Confirmation the data has been shredded data dialog opens.
Click the Yes button.

Changing the Cryptography for Credit Cards

Credit cards stored in a database must be encrypted using a key that is distinct to the venue per PCI DSS standard 3.6. This must occur:

Immediately after the initial implementation and data conversion has taken place
on a minimum of an annual basis. If the procedure is not invoked manually, it will be done automatically during any upgrade.
if there is any suspected security breach at the organization

To change the cryptography of credit card information at any time:

Log in as Master User
Go to the System Preferences->Security Tab
Click 'Change Card Encryption key' button at the bottom left

You will see a dialog similar to the one below that asks you to confirm the step and the reasons why the step is required. Click 'Yes' to continue.

Some notes about this process:

Theatre Manager will generate a completely random a 40 character key to use as half of the encryption key process that will be unique to the venue and re-encrypt all cards in the database.
This encryption key will not be known to the user and will not be known to Arts Management
You can still use theatre manager while this process occurs to sell tickets and take credit cards.
This process should be performed at least annually.
- A venue will be reminded to do it after 350 days
- If it is not done, within the required time frame, then it will automatically occur during any upgrade that occurs 350 days since the last time the venue's encryption key was changed
It should be performed at any time you suspect a security breach to any part of your network (make sure you also address whatever the security breach might have been).