PCI Compliance

A Merchant's PCI compliance is obtained by setting up the network and office policies in the appropriate manner and following a few simple rules (green in the diagram). This is required regardless of the software used to process credit cards and can generally be done at a reasonable cost.

The software or hardware provided by any vendor is only a portion of the merchant's ability to meet PCI compliance. Software provided by vendors must meet the prevailing PCI PA-DSS and PCI-SSF standards to assist the merchant to meet overall PCI compliance.

Please familiarize yourself with the definitions of key terms used by the PCI DSS, PA-DSS, and key terms used by PCI SSF set by the Security Standards Council. Full documentation can be downloaded from the Official PCI Security Standards Council Site.

Meeting compliance requires some due diligence and is determined by the PCI compliance level guideline your organization needs to attain.

Depending on how your venue processes transactions, your venue can be Schedule 'A', 'A-EP', 'B','C', or 'D'.

The life cycle of a standard provided by the PCI Security Standards Council is approximately every 2 to 3 years. Once approved at a standard, it is valid even though future standards are being worked on.

The following table illustrates a brief historical summary of Theatre Manager PCI compliance

Version Standard Status Action
11.0

PCI PA/DSS 3.2.1

SSF 1.1

Theatre Manager version 11 has been reviewed for its PCI PA/DSS 3.2.1 audit as part of the 3 year cycle. A new audit for Secure Software Framework (SSF) 1.1 was completed at the same time.

The onsite assessment audit took place November 7 - 10, 2022 and the final document was approved by the PCI Security Standard Council with an expiry date of October 4, 2026 for new installations. The image (above) is from the PCI Security Standards Council's website of validated applications. Search for Arts Management.

All vendors are required to tell you this.

All upgrade automatically occurs - no action required by venue
11.0 PCI PA/DSS 3.2.1 Theatre Manager version 11.0.zz has been reviewed for its PCI PA/DSS 3.2.1 audit as part of the 3 year cycle.

The audit took place in September 16 - 20, 2019 the final document was approved by the PCI Security Standards Council with an expiry date of October 28, 2022 for new installations. The image (above) is from the PCI Security Standards Council's website of validated applications. Search for Arts Management.

All vendors are required to tell you this.

Upgrade automatically occurs July 2020
10.06 PCI PA/DSS 3.1 Theatre Manager version 10.06.zz has been reviewed for its PCI PA/DSS 3.1 audit as part of the 3 year cycle.

The audit took place in October 2015 the final document was approved by the PCI Security Standards Council with an expiry date of October 28, 2019 for new installations. The image (above) is from the PCI Security Standards Council's website of validated applications. Search for Arts Management.

All vendors are required to tell you this.

Upgrade October 2015
10.02 PCI PA/DSS 2.0 Theatre Manager version 10.02 has been reviewed for its PCI PA/DSS 2.0 audit as part of the annual change cycle.

The audit took place in October 2014 the final document was approved by the PCI Security Standards Council.

All vendors are required to tell you this.

Upgrade October 2014
10.00 PCI PA/DSS 2.0 Theatre Manager version 10 has been reviewed for its PCI PA/DSS 2.0 audit as part of the 3 year cycle.

The audit took place in July 2013 the final document was approved by the PCI Security Standards Council in October 2013. The image to the left is from the PCI Security Standards Council's website of validated applications. Search for Arts Management.

All vendors are required to tell you this.

Upgrade October 2013
9 PCI PA/DSS 1.2 Theatre Manager meets the PCI PA/DSS 1.2 standard and approved by the PCI Security Standards Council in December 2010. Upgrade to version 9 ASAP
8 PABP 1.4 Theatre Manager meets the PABP 1.4 standard and was certified in October 2008. Please refer to our certificate and approval by Visa - page 6. Install 2008
7 **Self Assessed in 2006 Theatre Manager implements the standards required of PABP 1.4 (as of 2006), including 3DES high encryption of cards, and does not store any track II or CVV2 information. However, this version is neither audited nor certified by an external vendor (not a requirement from the PCI Security Standards Council at the time). Version 7 has the same security measures as version 8 and was simply renamed version 8 as part of the audit. CD's Sent
6 **Self Assessed in 2003 Theatre Manager implements almost all PCI security features in effect at the time (early 2000's). Card encryption is DES and it does not track CVV2 information. Version 6 can be considered PCI compliant. Diskettes Sent

** Please note: PCI requirements have changed over the years. At one time, the PCI Security Standards Council required that vendors of software 'self assess' that they have followed the guidelines. At Arts Management, we have always taken card security and privacy of information seriously and implemented many PCI features before there were published rules. That is why we felt able to meet the self assessment criteria in force at the time. However, there is a much greater need for security than ever before and we encourage merchants to fulfill their obligations to merchant agreements and upgrade to the 'certified' versions of Theatre Manager - which have been audited by external companies as meeting all the rules in effect at the time of the audit.

Network Diagram for PCI Compliance

The block diagram below explains the general setup of a network that is required to implement Theatre Manager in a PCI compliant manner.

Feel free to print this setup document. If any part of the network setup cannot be made to comply with the diagram, you will need to address that at a later date to become PCI compliant. Some sample machine requirements are in the table in the picture, or you can view descriptive information on sample computer specs (Click to enlarge as a pdf)

PCI compliance requirements for Credit Card authorization

Overview

There are 7 parts to the basic network in the diagram above that are described in more detail in the following sections. The firewall is the glue that connects them all together, yet protects each part from the other (also see firewall rules). Only 4 parts are in PCI scope, the others are simply illustrations of how customers, volunteers, actors and other devices interact with your network.

 

In PCI Scope (inside the firewall) if they touch credit card info:

  1. The main firewall
  2. the DMZ - contains only the Apache server and restricts what can be accessed from the internet.
  3. OFFICE Lan - all wired devices in the office. Computers that access any Credit Card information should always be hardwired, or access via a secure VPN
  4. Remote box office

 

Out of PCI Scope

  1. You can exclude ranges of workstations if you've told TM that they cannot process cards by creating a subnet mask that focuses on only those that can in the System Preferences->PCI Tab
  2. You can exclude the database server if you set TM to be PCI Schedule 'C' compliance in the System Preferences->PCI Tab and sue P2PE decides and hosted payments for online.
  3. Outside the firewall - basically the internet and customers purchasing online
  4. VENUE Lan - any staff, volunteers, or actors using wired or wireless devices and who are not capable of processing or looking at credit cards.
  5. Ticket scanners used at the venue
  6. P2PE devices like Moneris P400 which do not share PCI related data with Theatre Manager. Theatre Manager simply activates the P2PE device, which is outside PCI scope as there is no direct connection to the device from Theatre Manager.
If you are attempting to meet Schedule 'C' compliance for Theatre Manager, the database and a number of workstations can be taken out of scope. Credit cards will never pass through the database and most workstations can be denied the ability to process cards. Doing this effectively limits PCI scope to very few machines.
You can also whitelist computers or blacklist a network segment to prevent any computer from taking credit cards -- which also takes it out of scope as credit cards never pass through the user workstation.
The diagram shows servers as separate machines per PCI requirement 2.2.1. This can be implemented either as physical or virtual machines to achieve the goal of one primary function per server to mitigate security level differences in the purpose of the machine.

AMS Private Cloud Diagram for PCI A, B, or C

Venues using Theatre Manager can take computers out of PCI scope as per the diagram below. A device is in scope if a credit card touches or passes through it. Devices are out of PCI scope if they can never see any credit card information pass through at any time. AMS Cloud causes most things to be out of scope and you can limit it further. It is possible to implement the same PCI scope within your own environment if desired.

AMS cloud allows a merchant to target the possible compliance levels to Schedule 'A', 'B', or 'C'. Since most venues have face-to-face or phone orders, the default is Schedule 'C' but you may wish to reduce the number of machines in scope to the minimum. If can take all machine out of scope in the office environment using dial up or IP pinpads, you may be able to achieve Schedule 'B' (very much dependent on your bank).

Possibilities for PCI compliance

  • Schedule A for merchants using only e-commerce transactions and Moneris Hosted Payment Page. All e-commerce authorizations occur at Moneris, and card data never enters the network
  • Schedule B Merchants using only: Imprint machines with no electronic cardholder data storage; and/or Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels
  • Schedule B-IP for Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage (Moneris P400). Not applicable to e-commerce channels.
  • Schedule 'C' Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels. All Merchant Providers
  • Schedule 'A-EP' Merchants using hosted payments for web sales like Moneris

Even if you take all machines out of scope and use only dial up or IP terminals, if you are part of a large university or municipality, your Bank may force you to be schedule 'D'. This can happen if the Bank chooses to consider all your other merchant activities outside the venue (eg bookstore, admissions, dog tag sales, etc as part of the overall business). One way around that might be e-commerce and Moneris hosted payment page.

PCI Scope Diagram - AMS Cloud

The legend shows machines and network segments:

  • Organizational Areas:
    • that will never see credit cards (GREEN)
    • where a credit card passes through the machine while in flight to the bank during an authorization and is immediately gone (PURPLE). Cards in these zones are:
      • transmitted via TLS 1.2 and higher, and
      • live for an instant in time, and
      • are NEVER stored in a database.
    • where the card data is outside the boundaries of the organization. Examples are in the customer's hands (or wallet) or at your bank or service provider (who are required to perform their own PCI compliance) (RED)
  • TCP/IP Traffic
    • RED ARROWS - traffic where there is absolutely NO card data ever transmitted
    • BLUE ARROWS - traffic where card data travels (encrypted and via TLS) while it is IN FLIGHT for an authorization. This means that a message is sent for credit card authorization and the card resides only in memory (and is never stored in any disk file)

Components

Local Workstations

There are three options for workstations within a venue's physical environment.

Option Goal Steps Pro Possible PCI Levels
1 WORKSTATION OUT OF SCOPE and use a POS pin pad device

This takes a workstation out of PCI scope and allows the workstation to use any software on it that can reach the internet (eg email and web browsing). Credit Card authorization is via a P2PE pin-pad using

  • Dial up or IP connectivity that is completely independent of Theatre Manager and not connected in any way -or-
  • Using a device like the Moneris P400 where Theatre Manager talks to Moneris cloud to activate the pin pad. There is no direct connection between Theatre Manager and the P400
If all workstations are subject to this rule, then Schedule 'B' compliance may be possible (subject to your Bank's ruling). Risk of card being part of TM components is ZERO. Risk of any data breach is limited to the person hacking the standalone POS terminal.
  • Indicate to TM that a workstation cannot authorize credit cards by indicating a CIDR subnet that is outside scope of the network
  • Use a stand-alone P2PE pin pad device that talks to the bank without connecting to the Theatre Manager Workstation. These must be purchased from your bank or service provider and come in many varieties such as wireless, dialup, ethernet connected, accept apple pay, chip and pin cards, etc.
  • Can still authorize credit cards for walk up and phone sales via external terminal.
  • Workstation can be used for any purpose such as email, web, and analytics as it is not subject to PCI scope
  • End of day is broken into web sales and 'other' payments for box office'

'B'

'B-IP'

'C'

2 WORKSTATION OUT OF SCOPE and no credit card authorization at all

This option should definitely be used for all non-box office computers or computers used primarily for setup, reporting, and analysis.

  • Workstation can be used for any purpose such as email, web, and analytics as it is not subject to PCI scope
  • Only web sales will have a settlement for credit cards
'B'
3

DEFINED WORKSTATIONS IN SCOPE

The workstation is defined as one of those that may accept credit cards entered into the system so that it does

  • since Theatre Manager does the authorization, it can also do a void or refund. Depending on the credit card provider, it can be as long as a year after (Bambora using authorization token
  • Authorization will use higher level TLS transport encryption if supported by merchant services provider
'C'
4

TM Servers

NGINX and TM Server

can be in or out of scope depending on processor choices
To take the servers out of scope, you will need a merchant provider for Moneris Hosted Payment Page. The advantages are no data enters the network and you can be PCI A compliant. Disadvantages come with the inability to use post dated payments, and perhaps processing refunds. Under Moneris hosted payment page processing, TM does not see any card data - just the authorization, allowing for PCI A.

Hosted payments do not support the feature of post dated payments online.

'C' or 'A'

AMS Private Cloud

Credit card data can never be stored on the AMS Cloud, taking the database server out of scope.

Credit card data can pass through the firewalls and security appliances on the way to your Service Provider for authorization. It is transferred via TLS 1.2 and is subject to SPI (Stateful Packet Inspection), DOS detection, rate limitation, etc. to ensure security and privacy.

Bank/Service Provider

This is the merchant provider you selected out of those supported by Theatre Manager. The bank is not in scope of your PCI compliance requirements.

 

Risk Profile

Theatre Manager, the AMS Cloud, and POS terminals offer a very low PCI risk profile (almost negligible) for the following reasons:

  • Card data never enters your network - no risk
  • Cards are authorized using standalone pin pad terminals sold by the bank. This represents a negligible risk as only the physical device, sold and certified by the bank, could ever be compromised. Even if it were, it is not part of your network and has no communication with TM
  • Card data is never stored on disk. Having no card data in the database means no risk and no PCI exposure even if the entire database was given into the wrong hands. There simply is no card data in it.
  • Card data is transmitted from the user to the bank via TLS 1.2 (transport layer security) which is the highest form of security for sending data on the web.
  • Card data lives on the AMS network only for that instant in time needed to get to the service provider. TLS 1.2 cannot be sniffed by bad guys - very low risk
  • The TLS certificate can be reissued as often as you want to ensure that your key strings are secure. Google signaled intent to re-sign certificates every few months as additional cautions for commerce.

Main Firewall

You will need a router (with DMZ and VLAN and SPI capability) and two subnets are required within the office to implement PCI compliance. These can be reasonably priced such as the easily configurable SG-2440 pfSense router (approx $500 in 2015 prices) which has a lot of features. Please check techsoup.org if you are a not for profit organization as they have full cisco routers that you may be eligible to purchase at a discount.

We only recommend a router/firewall that has the ability to isolate the apache computer (i.e. designate an ip address for the DMZ).

Your firewall need to restrict connections between untrusted networks and any system components in the card holder environment PCI requirement 1.2.
  • Routers be a dedicated device, preferably a hardware router. If it is a software router such as one built on linux, then it must only be used only for this purpose and contain no other services.
  • It should be configured to shut down all incoming and outgoing ports except those required for business as per the following:

When you need to set up firewalls on computers, the built in firewall on windows is very flexible. On macOS, do not manage the built in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the macOS PF Firewall.

Firewall/Router Rules

The main router/firewall is protection from the outside world. If the router has DMZ capability, please set up the DMZ IP address to have the same subnet range as the office LAN. This will make it easier to scale up web listeners that talk to the Web Server.

This diagram identifies which traffic is required for Theatre Manager to work in the card holder environment per PCI requirement 1.2.1

Any traffic not required should be denied - and the router should be set to 'deny all' unless explicit permission is given.

All traffic is TLS 1.2 or better, including to and from:
  • database and internal workstations
  • patrons using internet browsers and NGINX
  • NGINX and web listeners
  • Web Listeners and database
  • credit card providers

In the example below, we'll refer to IP addresses

  • in the office VLAN as 192.168.1.x
  • in VLAN2 (containing wireless devices and/or machines not subject to PCI) as 192.168.2.x
  • and use 192.168.1.10 as the inside address of the DMZ where the Web Server resides, protected on both sides by firewall rules. The outside IP address (internet) also authenticated and verified using an TLS Certificate.

  • The lighter red arrows on the diagram represent places where you could place restrictive rules from specific machines to specific machines. Those rules are outlined in the table below the diagram.
  • The number in the first column of the table refers to the same number on the diagram to give an idea what kind of rules are required for each component. If you combine some services on to the same machine, you will need to aggregate the rules.
  • All ports in the table are TCP
  • Rules are for INITIATED connections (outbound connections). Meaning a machine starts the connection.
  • If an inbound message occurs on an approved port, then ANY port can be used for outgoing response. (i.e. do not block responses to approved inbound messages.

    For example: Item #1, the postgres server, only needs port 5432 incoming to that device. You would turn on the personal firewall on the machine so that it only opens that port.

If you prefer to view the firewall rules from the perspective of specific ports, please refer to ports used by Theatre Manager

Item Machine and Purpose Subject to PCI Virus S/W Inbound Port Rules Outbound Port Rules
1 PostgreSQL server

database

depends no*
  • 5432 from any 192.168.1.x (note: traffic to DB will be using TLS 1.2)
  • all to 192.168.1.x
  • 37 to NTP server
2 Remote Box Office via VPN
(or terminal server)
yes yes*
  • as needed from internet
  • all to internet
  • 5432 to 192.168.1.2 (Postgres Server)
3 Web Services (TM Listener) yes no*
  • 443 from 192.168.1.10 (NGINX server)
  • 8111 from other TM listeners if they exist
  • any from 192.168.1.2 (Postgres server)
  • any to 192.168.1.10 (NGINX web server)
  • 5432 to 192.168.1.2 (Postgres)
  • 53 for DNS, MX lookup
  • 37 to NTP server
  • 443 to
    • www2.artsman.com and
    • downloads.artsman.com
  • 80 to maps.googleapis.com/maps/api/geocode
  • 25 (or 465 or 587) to SMTP server (as required)
  • 110 to pop server for Facility Mgt
  • 443 outgoing to credit card provider
  • 443 outgoing to ippos.moneris.com if using a P400 EMV device from Moneris
4 Box Office Workstations yes yes*
  • all from 192.168.1.x
  • 80, 443, 8111 to 192.168.1.10 (web server)
  • 5432 to 192.168.1.2 (postgres)
  • 53 for DNS, MX lookup
  • 37 to NTP server
  • 443 to
    • www2.artsman.com and
    • downloads.artsman.com
  • 80 to maps.googleapis.com/maps/api/geocode
  • 80 to www.google.com/maps/api/staticmap
  • 80 to help.theatremanager.com
  • 443 outgoing to credit card provider
  • 443 outgoing to ippos.moneris.com if using a P400 EMV device from Moneris
5 Ticket Printer no n/a
  • 10001 from 192.168.1.x (or whatever port the printer is set on
  • all to 192.168.1.x
6 Web Server (NGINX) yes yes*
  • 80, 443 from internet
  • port 443 to 192.168.1.9 (Web Services TM Listener)
7 Outside of Firewall no n/a
  • 80,443 from internet
  • xxxx from internet or Term Services
  • forward 80,443 to 192.168.1.10 (NGINX Web Server - which automatically escalates to 443 using TLS 1.2 or later)
  • forward xxxx to 192.168.1.4 (Term Server)
8 Internal Wireless Router no n/a
  • all from 192.168.1.1
  • specific to 192.168.2.1 as required
9 Venue Lan computers not handling credit cards
no yes
  • all from 192.168.2.1
  • as needed to 192.168.1.1
10 wireless ticket scanners no n/a  
  • Ticket scanning occurs through the internet via tickets.yourvenue.org and port 443. Open ports to allow scanning traffic to the outside of the router

Ports used by Theatre Manager

The table below describes which ports various components in Theatre Manager uses. With few exceptions, it is possible to change the ports that are being used if you wish. The only ports that should not (or cannot) be changed are:
  • ports 80 & 443 externally for web sales.
  • Outgoing port 443 for credit card authorizations
  • port 37 for a time server
  • port 53 for MX record lookup via a DNS server

If you prefer to view the firewall rules from the perspective of specific machines, please refer to ports used by each machine

Port Meaning Use Security Note
25 (or 465 or 587) SMTP Outgoing TM Server uses this for email for web sales, eblasts and meeting scheduling. note: Workstations do not send emails and do not require access to SMTP server.

Alternate SMTP ports can be used as TM supports (startTLS and other security)

You may wish to place a small SMTP server (like Exchange) within your network so that TM talks to it and allow it to relay to the internet. This also controls outgoing access.

37 NTP Time Server Outgoing OSX and Windows machines use this to syncronize clocks. All machines should be able to synchronize with an NTP server so that transactions and audit logs are accurately recorded when the happen per PCI 10.4 compliance
53 DNS and MX lookup. Outgoing This is used to verify email and web domains during the data entry process to improve data quality
80 HTTP Incoming and Outgoing Incoming is only required to the Web server.

Outgoing for workstations to communicate to:

  • help.theatremanager.com
  • teamviewer
Teamviewer can go out on ports 80 and/or 5938
443 HTTPS Incoming and Outgoing Incoming is required for web sales.

Outgoing is required for TM Server and TM Workstations for

  • Credit Card Authorization
  • www2.artsman.com for autoupdates
  • TM Server for REST API access if enabled
110 (or 993) POP3 Outgoing Facility Management module only: TM has a scheduling function that lets users set up calendar event and send the invitations to users, patrons and volunteers.

The port is used by TM workstation and Server, and only email with valid outlook or iCal attachements are read. All others are discarded. No user checks this email address.

Theatre Manager supports alternate POP3 ports if you prefer.

5000 Web Services Internal The Web Server load balancer communicates to Theatre Manager Web Services on port 5000
8111 Web Template Server Internal This internal port on the web server is a Virtual host used by web services to obtain the custom web page templates from the htdocs folder for merging. It is also used by workstations to obtain web page templates used to send double out-in confirmations as per CASL (Canada's Anti Spam Law).
8201 Cache Server Internal This internal port is used for caching data shared between web service processes.
5432 Postgres Internal This is the standard port for the Postgres database server and is only used within the LAN. Postgres's pg_hba.conf configuration file specifies the IP address ranges (or specfic IP's) that can communicate with the database server. If a machine is not permitted to talk, postgres will does not respond.

Traffic from workstations to Postgres is via TLS 1.2

10001 Ticket Printer Internal Workstations send a string of characters to print a ticket. The printer responds with status requests as need be.

No outside machine needs access to a ticket printer.

xxxx Terminal Server & Remote Access Incoming A secure connection from the remote box office to the firewall is recommended for security purposes. RDC and Terminal Services establish secure connections. VPN is additional security.

PostgreSQL Server

Postgres listens on 5432 by default (see firewall rules for postgres).

Only this port needs to be open on this server. All other inbound ports can be closed in the operating system. The port can be changed by editing the Postgresql.conf file, or during the install.

Misc Recommendations

  • File and email services for the network must be placed on a separate machine from the database server.
  • Turn off windows auto updater. Instead, perform regular maintenance at a time of your choosing (every second Monday for example, more often if the news reports critical viruses) to download and install updates. For 24/7 web sales service, it is important that the Postgresql server run constantly and only be updated at a time of your choosing.
  • On OSX, turn off Software Update and run regular maintenance every second week, similar to Windows Environment. There is far less risk on unix based systems for virus attack vectors.

Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and file servers. PCI requirement 5.1

Since postgres is implemented on a stand alone machine (per PCI requirement 2.2.1), we recommend that you DO NOT install virus software on the PostgreSQL Server. If you must, then do it under very controlled circumstances..

Never allow the virus scanner to scan the actual postgres database directories for traffic because virus scanners severely affect performance when many files are changed rapidly (as in a stand alone database server).

If you absolutely must scan all files, scan the database folder at very off peak hours.

TM Listener - Web Services

The ports that need to be opened for web services depends on which you are using for load balancing

In all cases, you specify the ports to talk to listeners within the TM Director interface.

 

Simple Setup for Load Balancing

In the simple setup situation, you just need to open port 5000 to each TM listener. When any message is received by the second gen listener externally on port 5000, it load balances internally on ports local to the machine (5001-5010, 5111, 5201-5210).

Each second generation listener machine needs to be able to talk to the designated TM Web Listener machine to retrieve web pages.

 

Custom Setup for Load Balancing

In the custom setup, the web processes can listen on

  • Second Generation Listener:
    • port 5000 (like the simple setup for load balancing) -or-
    • ports 5001-500x where you specify the load balancing on the TM Web server for high performance throughput -or-

Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and servers PCI requirement 5.1

You can install anti virus software on the TM Server - but may need to exclude the TheatreManagerServer program directory and all traffic to port 5432 on the postgres server. Since the web services run as a service, there is limited need to log into the machine. It should not be used for any other purpose and listens only to the API's from the TM server, so you may only need periodic file scanning at night if you do not join a domain and/or limit people who can access it.

Venue LAN

Machines in your office that generally do not need access to Theatre Manager can be in a separate VLAN so that they do not accidentally compromise credit card data. Rules should be put in place so that these VLANs cannot talk to the servers in the Office VLAN per PCI requirement 1.2.3

It may be a good practice to have one or more VLANs beside the primary office network, especially if you have wireless access points, public WI-FI in your lobby, green room access for Actors, etc. (per the network diagram). Separating those kinds of users from the office LAN is beneficial from a security and bandwidth management point of view. Network segments not dealing with cardholder information are not subject to PCI rules (although it's a good idea to protect them too!).

Theatre Manager does not require use of wireless networks to operate.

However, if you do require that some computers access cardholder data over a wireless network, you must use strong encryption technology for authentication and transmission of data such as hidden SSID, specified MAC addresses, and WPA2 or better on a separate VLAN than other wireless access points and change vendor supplied passwords per PCI requirement 2.1.1.

You must never transmit card information over a network with WEP encryption per PCI requirement 4.1.1.

Office LAN

The office LAN should be set up to isolate computers that may access credit cards from other general purpose machines. These machines should be hardwired to ethernet hubs and routers. Generally, this just means putting it on a different VLAN than the rest of the office to provide maximum cardholder security PCI requirement 1.2.1.

For example, if there is an area that provides free wireless in the lobby or access to the internet for actors in the green room. Those access points should be part of the 'Venue Lan' and not part of the 'Office Lan' (per the network diagram) to separate the segment of the network containing credit cards (office) from wireless part of the network.

You should not be able to access the internet from the database server or any machine that contains credit card information except as required to authorize the card or update system components. PCI requirement 1.3.2 to 1.3.5

Ports that should be open are defined in the section about firewall rules

When you need to set up firewalls on computers, the built-in firewall on windows is very flexible. On macOS, do not manage the built-in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the macOS PF firewall.

This section describes the components of the Office LAN.

Box Office Admin Computers

Office computers can be classified in two categories:
  • those where credit card data is typed or entered into the system (with or without credit card swipes)
  • and those computer where credit card information is not typed into the machine.

Computers accepting Credit Card Data

Any computer where credit card information is entered or that has an attached credit card swipe is effectively a point of sale device and needs to be protected from a particularly nasty form of virus called 'Bots'.

These are especially prevalent on PC's and if a computer were to become infected, this type of virus scans keystrokes at the computer and sends those key strokes to the 'bad guys' outside the network. Preventing this involves closing most ports and providing very limited access to the outside world, especially for mail and web browsing.

For this reason, on those computers, you should:

  • Close down all outgoing ports except those specified in firewall rules for workstations.
  • Disallow general internet access via the web browser to prevent the most common source of infection. You can allow people to access help.theatremanager.com for online help.
  • install virus protection software on these machines and regularly run it and update the software. There are a number of good alternatives from freeware like Avast! to Symantec (our least favourite)
Deploy anti-virus software on all systems commonly affected by malicious software, particularly personal computers and servers. PCI requirement 5.1

If these computers are using Theatre Manager, you may need to exclude the 'Theatre Manager' program files directory, depending on your virus software. Exclude all network traffic to port 5432 on postgres server.

Computers that do not accept Credit Card Information

Machines that are not entering credit card numbers may have general internet access. You can ensure that these workstations cannot enter cards into Theatre Manager by setting up specific workstations or network segments that can accept payments and excluding these workstations.

If those computers are on the same network segment as the machines accepting card numbers then they fall into the scope of a PCI assessment for the venue. This means those machines would need all of the anti-virus and anti-malware software as well as file integrity monitoring, log management, access control, etc. just like the machines that accept the cards.

To reduce the scope of the venue's PCI assessment needs, the venue should consider placing those machines (back office or manager machines usually) on a separate network segment with just the necessary ports between them and the cardholder data network open. Refer to the network diagram and firewall rules to separate the computers with card access from those without onto separate VLAN's within your network.

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers) PCI requirement 5.1

If these computers are using Theatre Manager, you may need to exclude the 'Theatre Manager' program files directory, depending on your virus software. Exclude all network traffic to port 5432 on postgres server.

Wireless Access Points

Theatre Manager does not require use of any wireless network for operation as all workstations and servers are to be connected via ethernet cabling.

Since many venues use wireless networks in the lobby for customers and green rooms for actor, or volunteer use, it is important to ensure that wireless routers are separated from the cardholder network and are on their own VLAN and all default settings are changed from factory. PCI requirement 1.2.3 and PCI requirement 2.1.1

The following must also be changed every time somebody with knowledge of the security changes positions or leaves the company. PCI requirement 4.1.1

Configuration of these should include:

  • Turn off all SSID broadcasting
  • Enter the MAC addresses (00:00:xx:xx:xx:xx) of the scanners into the acceptable list of devices at the remote site and only allow those devices to gain access to the network
  • Use strong encryption such as WPA2 (also sometimes called IEEE 802.11i) or better for access control.
  • Update the router to the latest firmware
  • Change the default user ID and password for the router to be different than the manufacturer-supplied defaults.
  • Change all wireless default encryption keys and SNMP community strings

Ticket Scanners

Wireless ticket scanners do not transmit any cardholder data at all so wireless ticket scanning can be implemented one of two ways. The scanners can be
  • part of a VLAN that is inside your main router/firewall and connected to the other parts of your network. This is known as the Venue LAN according to the network diagram. Scanners using this configuration are subject to PCI regulations to the extent that the firewall must be in place to regulate traffic.
  • completely outside the main firewall and directly connected to the internet via the ISP. In this situation, the ticket scanner is considered not part of your network and is out of scope of PCI compliance.

Wireless Scanners in the Venue Lan

If the ticket scanners are within your firewall and part of a VLAN connected to the Office LAN, you must implement TLS 1.2 or better security and firewall rules between the venue LAN and the office LAN per the network diagram. Refer to PCI 4.1.1

You can use a direct IP in the scanner to access the Apache server directly (e.g. 192.168.1.x), or you can refer to the server via the domain name (like tickets.yourvenue.org).

Wireless Scanners connected to the Internet

If the wireless scanners are connected to a router that is on the internet (and not connected in any way to the internal trusted networks) then you do not need any security on the scanners. Since the scanners simply send HTTP requests to the Apache Server, you can use the external DNS name like tickets.yourvenue.org.

The Linea Pro and iPhone/iPod combination support the latest required encryption technologies from end to end

Wireless Computer Access

If you permit wireless access to your network within your office, PCI compliance states that these computers should go through at least one router or firewall before accessing the office network or any part of the network where credit card information is stored.

The DMZ (NGINX Server)

The NGINX server is the only part of the Theatre Manager system placed within the DMZ per the network diagram.

Note that card holder data should never be stored or placed on the NGINX server for any reason. Theatre Manager does not require it. PCI requirement 1.3.7

Best Practices for setting up the NGINX Server

  • NGINX should be on a standalone machine in the DMZ
  • NGINX must be protected by the main firewall rules. You should turn on the built-in firewall on the machine (OS X or Windows) and should only need to open ports 80 and 443
  • NGINX is a service so it will automatically start as a service upon reboot.
    • This means nobody needs login at all.
    • Do not allow anybody to access this machine except under controlled circumstances
    • However, configure the screen saver to require a password after it is activated.
  • Turn off Windows Update or OS X Software Update
    • Instead, perform regular maintenance at a time of your choosing (every second Monday for example, more often if the news reports critical viruses) to download and install updates.
    • For 24/7 web sales service, it is important that the NGINX server run constantly and only be maintained at a time of your choosing.
  • Remove access to Outlook and/or other mail clients on the machine
  • Make sure that accessing the internet through Internet Explorer or another browser on that machine is limited to certain URLs
  • Virus protection should be implemented on this machine:
    • This machine is only responding to requests from the internet via NGINX, it is not actively accessing anything on the internet using a browser or reading email - so the risk if is acquiring viruses is very minimal.
    • If you put a virus scanner on it, set it to scan the hard drive once or twice a day, preferably early morning or at a time of day when online sales is expected to be at its minimum. Some antivirus software applications are CPU-intensive and have the potential to severely slow down the NGINX response time to web requests.
    • Don't scan incoming requests from the internet to NGINX on port 80 or 443 - because those are the working ports for NGINX.
Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and file servers) PCI requirement 5.1

Policy Manual

PCI compliance requires some additions to your policy manuals, some of which are described below and relate to safeguarding your network and the credit card information. We recommend making these additions immediately.

Refer to Section 12 in the PCI DSS implementation guide for complete information

Policy Description
1. Credit Card information must not be stored on any machine that is in the DMZ.

This generally means laptops that connect to the network wirelessly should be examined for files that contain card information and that information must be deleted.

2. Do not transport credit card information outside the secure firewall without:
  • AES256 or better encryption of each card or the complete file containing any cards (never auto de-encrypt the file when starting a machine)
  • transporting the data in a secure password protected device -or-
  • sending via TLS or over a VPN if doing remote backups electronically to a secure site
3. Never email a credit card number to anyone.
4. Never read back an entire credit card to a patron if they call in asking for one. Always have the patron tell you the card and confirm it only if it right. You can confirm a card number that the patron just told you in entirety.

Remote Box Office

Depending on the remote access solution you use (Citrix, Terminal Services, Teamviewer, logmein), you may need to open the appropriate ports on your router(s) and server for this feature:
  • On the firewall built into this machine
  • On the main firewall protecting the office with forwarding to the appropriate ports on this machine.

Access to the terminal server from outside the main network should include VPN or packet encryption. Windows 2008 Server and later use secure access by default.

If the remote box office solution permits the feature, you should also set it up so that only specific applications can be launched and the user cannot get to the desktop. For example, Citrix provides a web interface under ISA services that allows you to only permit Theatre Manager to run. With Terminal Server, you can also force it to start Theatre Manager automatically. With 2012 Terminal server, you can limit to only Theatre Manager application to run.

Always disable outgoing web access within the Citrix or Terminal Server so that people cannot browse the internet on the Terminal Server Machine (this will prevent all viruses). You can enable web access on the local machine.

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and file servers) PCI requirement 5.1

Remote Ticket Selling

In most cases, the best way to do remote box office is to set up a Terminal Services server inside your network and provide a VPN solution from the remote site to the router.

An inexpensive Linksys VPN router will provide adequate router to router VPN services at a good price - or will provide remote VPN software for computer-to-router VPN. More expensive routers like Cisco have VPN software that accompanies the router as well.

In all cases, remote box office or work at home should be set up using a VPN connection.

If you are using remote box office and ticket scanning for access control at the same venue, you just need to connect the ticket scanner to your ticketing web site. It can use the VPN, but does not have to. so connecting to any wifi point with external access is fine.

Remote Ticket Scanners

If your venue uses wireless ticket scanners for remote venues, you will need to set up a wireless access point at the remote venue to connect to the internet. These devices only confirm a ticket was used or a person exits the venue, through a very controlled API on the scanner.

The setup of the wireless access point should be:

  1. turn off all SSID broadcasting
  2. Enter the MAC addresses (00:00:xx:xx:xx:xx) of the scanners into the acceptable list of devices at the remote site
  3. use WPA2 passwords

The setup and functioning of the Linea Pro wireless device is described in a separate web page.

When you need to enter in the IP address, use [tickets.yourvenue.org]/TheatreManager/1 where [tickets.yourvenue.org] is your ticket website URL.

All data traffic is done over HTTPS using secure sockets and TLS 1.2 or better transport layer encryption.

Even if you are scanning tickets at your local venue, it is often a simple matter of setting up a small hub in front of your main router so that the access points are connected to it - and they would be outside the firewall for security.

Remote Access

Remote access for Theatre Manager usually means situations for remote box office or work at home. There are a number of tools that can be used, such as Remote Desktop Connection (RDP), LogMeIn, Go To My PC, and more.

In all cases of remote access for box office, you should implement either a VPN tunnel and/or SSH access - where the communication and session has strong encryption or is a private connection per PCI DSS 4.1.

There may be additional setup consideration as described in the following sections based on the software you use. Your IT person should ensure that whichever software is used, that it employs VPN or SSH.

PCI compliance requires that remote access have a user ID and password, and an additional authentication factor that includes, but is not limited to, items such as a smart card, token, PIN, biometrics, VPN, etc.
For people with remote access, you must establish passwords according to PCI DSS requirements 8.1, 8.2, 8.4 and any requirements of all sections of 8.5. In other words, the requirements for remote access passwords and authentication are exactly the same as for access to your office LAN.

 

Common remote access mechanisms that we use

While there are many vendors of remote access software, the ones that we see used most often are:

  • Using a VPN and local copy of TM for full and secure network access - best used when internet connections are fast
  • Using Microsoft Remote Access (RDP) and Terminal Server for full managed access to TM - best used when internet is marginal/poor or you need to control internal network access
  • Using a remote access tool like TeamViewer, LogMeIn, or similar to simply access your own machine from a remote location. Best when no remote ticket printing is required.

Using a VPN

The best way to access your own network from a remote location is to set up a VPN between your work location and the office router.
Your office router must be able to support VPN connections. It is generally a feature of a more expensive router, and some low cost routers may have the capability. Check with your IT support if this is an option for you.

 

Your routers and using TM over a VPN service

If your venue's routers support a VPN service to your network:

Initial, first time only setup steps

  • Ask to have the VPN Client software set up on your home computer.
  • Find the IP address of your database server It is on the lower part of the login screen while using TM in the office. In the example to the right, the address is circled in red (the sample shows 127.0.0.1)
  • Download and run the latest 64 bit version of Theatre Manager for:

 

Each Time you Connect to the Office

  • Establish your VPN connection from your laptop to your office first
  • Start Theatre Manager and wait for the login screen. Note: the first time you will be asked to find the database. Use the IP address located as outlined in the Initial Setup steps above.
If you are using IP based ticket printers at your remote location, you will need to set up a ticket printer device that has an IP address on the remote network.
If you are in a different local time zones from your office, you will need to provide the LocalTimeZone parameter in the Theatre Manager preferences file. This is only needed if your time zone does not match the time zone setting in the company preferences->Report/Misc tab

Microsoft Remote Access

If you are using remote access, you need to set up a terminal server to use high-security access for Remote Desktop and it should be set to disconnect or lock the terminal after a period of inactivity. (PCI requirement 12.3)
This typically needs a copy of Windows STANDARD Server version or better (not the windows OFFICE server version). If you bought a standard server under the Techsoup donated software program, you will likely have two CAL licences for the terminal server and may need to add some additional licences.

 

Windows 2012/2016/2019/2022 Terminal Server

Terminal Server is a great way to allow access from any location to your office. It has the benefits of:

  • allowing restricted access to your internal LAN by only allowing access to specific services or programs for a user.
  • working in conditions where internet connection bandwidth is poor since it is a screen-scraper technology and optimizes only transmission of screen changes
  • allows report printing to ticket printers on LPT ports

When connecting from any workstation to the current versions of Terminal Server, the server defaults to high encryption. It is good practice to verify that the setting has not been lowered.

Step Purpose Installation instructions or link
1. Verify Terminal Server settings The following links detail the security settings in Windows Server 2003. Server 2003 defaults to High encryption, but it is a good practice to make sure it hasn't been lowered accidentally.

support.microsoft.com/kb/814590

Terminal Server 2008/2012/2016/2019 and 2022 should default to high encryption.

2. Verify RDP settings RDP should be set to always prompt for a password.

TeamViewer Remote Support

Artsman uses TeamViewer for remote support. This is designed to only run if the user launches the application, contacts Artsman and permits the support team to have access to their machine for the purpose of diagnosing a problem on a one time basis.

Remote access is to be

Outside the Firewall (the internet)

The internet is everything that occurs outside your firewall perimeter and represents everything that is beyond your control to protect.

This is where your customers will be.

Customer Access

Customers buying on the web need to be able to access the Apache web server through ports 80 and 443 in the DMZ. The web server sends cookies back to them.

Web Page Design Considerations

  • Your main web site should direct links to the Apache server via HTTPS so that the majority of access to online ticket sales is secure.
  • If a customer tries to access tickets.yourvenue.org through port 80, the first thing that the index page does is redirect them to a secure port.
  • If a customer does alter the URL and tries to access a page via port 80, the Theatre Manager web listener always responds back with a secure page and the next interaction will be through port 443
  • Ultimately, if you only wish secure access through the DMZ, you can turn off port 443 and customers will be forced to access via HTTPS. This is quite an aggressive approach and has some marketing implications - the safeguards above ensure that people are moved to HTTPS after hitting the web site for the first time.

What a customer needs to do (nothing)

A customer has zero configuration to do on their machines, other than to allow cookies from your site if they cannot browse the web pages. The Theatre Manager Web Listener will alert them to turn on cookies as it detects people trying to move through pages without cookies enabled.

PCI Audit Logs

PCI DSS sections 10.2 and 10.3 require that Theatre Manager maintain audit logs for certain system events. These primarily deal with who has seen or could have seen credit card information.

The transaction logs in Theatre Manager deal with all these requirements because Theatre Manager has always maintained an 'audit log' of certain system events that tracks the events required in PCI section 10.2 and the minimum required data elements for PCI section 10.3.

PCI DSS section 10.5 requires centralization of all system related logs in a common log management process in a protected manner. The intent from the PCI council is that you could view access to login/out and card data in Theatre Manager along with firewall access changes or admin access to a machine or server in a consolidated view.

You can export the logs from Theatre Manager in Excel or tab delimited format and move them to your centralized logging mechanism.

Accessing the Audit Log

All financial and access audit log transactions are kept forever. Transactions for Login, Logout, Invalid Access, and Viewing Complete Card Data are kept in perpetuity. Transaction types are 'coded' and 'dated' for easy finding and sorting.

Access to the audit log is from the Setup Menu.

This will bring up a screen similar to the one below which is a sample of an audit log that is contained within the transaction records in Theatre Manager.

Exporting Audit Logs to External Logger

PCI DSS compliance section 10.5 requires centralization of logs in a common log management process. The intent from the PCI council is that you could view access to login/out and card data in Theatre Manager along with firewall access changes or admin access to a machine or server in a consolidated view.

You can export the logs from Theatre Manager in Excel or tab delimited format and move them to your centralized logging mechanism.

Audit logs are kept forever as part of the database. You can search for any past history and re-export them if you desire. Database backups will contain the logs in existence at time of backup.

Once you have accessed the Audit log and are viewing on the screen as per the sample below, to obtain the logs for a specified period of time:
  • Search the logs by transaction date for all new logs since the last export
  • Click the Export Button on the top of the screen and select export to Excel or tab format as required
  • Provide a file name as a place to save the logs
  • Import those into your centralized logging mechanism

Audit Log Description

PCI Std. Requirement Theatre Manager Implementation
10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual accesses to cardholder data Theatre Manager creates an 'AC' transaction to track whenever a user sees the entire credit card number. By default, Theatre Manager displays masked card numbers in all windows and reports. Only in specific places will Theatre Manager display card information to those who have specific authorization to see cards. Therefore, you should expect to see very little information in the audit log if you minimize who has access to see full card data.

The act of accepting a credit card at the box office is tracked with a PT audit transaction - i.e. the actual payment - and can be tracked by the user that way. Since this is a normal business act (accepting a card from a patron and typing it in), it is not necessary to also create an audit log.

None of these transactions can be purged.

10.2.2 All actions taken by any individual with root or administrative privileges An administrative user is subject to the same rigorous requirements as all other users.
10.2.3 Access to all audit trails Theatre Manager does not track who views audit trails because they cannot be changed, manipulated or altered by the user in any way. We believe that when users know this information is tracked for PCI compliance, it acts as an additional deterrent. None of the logs ever display sensitive data.
10.2.4 Invalid logical access attempts Theatre Manager tracks who accesses Theatre Manager and when they log in or out via the 'ALI' and 'ALO' transactions.

'ALX' transactions track invalid login attempts (after 3 mistyped passwords), or when the user account is locked out.

These transactions cannot be purged.

10.2.5 Use of identification and authentication mechanisms Theatre Manager uses login and authentication mechanisms. All users of the application must log in.
10.2.6 Initialization of the audit logs The audit logs can never be 'initialized' by the user, nor can be they be cleared except under programmatic control. The minimum retention time is 365 days for audit transactions with the default being forever. Payment logs indicating who took the actual payment are retained forever and cannot be deleted.
10.2.7 Creation and deletion of system-level objects  
10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification yes - see log example in the user column.
10.3.2 Type of event yes - see log example for the specific transaction codes, expanded description and details about the specific activity.
10.3.3 Date and time yes - see log example
10.3.4 Success or failure indication yes - see log example. Failure logs show when a user tries to log in and forgot their password.
10.3.5 Origination of event yes - see log example for the IP address of the machine that created the event and the user
10.3.6 Identity or name of affected data, system component, or resource yes - see log example - this illustrates an example where a user viewed a specific credit card in full. The patron's name is displayed in the first and last name column.

Compliance Statement required by PCI Council

The PCI council represents the credit card companies. They dictate to vendors that products must be assessed, certified, and approved by them in order to appear on the list of 'Accepted Products'. In the fine print that is part of their processes, the PCI council has a specific clause we must relay to you.

It is repeated verbatim below so that there can be no mistaking what we have been instructed to do.

Vendor shall comply with, and communicate (in a reasonably manner determined by Vendor) to all purchasers and other licensees of Vendor Products that have been Accepted under any of the Programs, the following statement:

“Acceptance and/or listing of a given product by the PCI Security Standards Council, LLC (PCI SSC) only applies to the specific version of that product that was reviewed by an assessor or test laboratory qualified by PCI SSC (Assessor) and subsequently accepted and listed by PCI SSC (the “Accepted Version”), and only while such acceptance and listing are in effect. If any aspect of a product or version thereof is different from that which was reviewed by the applicable Assessor and accepted and listed by PCI SSC – even if the different product or version (the “Alternate Version”) conforms to the basic product description of the Accepted Version – then the Alternate Version should not be considered accepted by PCI SSC, nor promoted as such. The authoritative lists of products currently accepted by PCI SSC can be found on the PCI SSC website at www.pcisecuritystandards.org. Please notify PCI SSC if you believe that any product purportedly accepted by PCI SSC does not appear on these lists.

No vendor or other third party may refer to a product as “PCI Approved” or “PCI SSC Approved”, and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or part, accepted or approved any aspect of a vendor or its services or products, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a corresponding letter of acceptance provided by PCI SSC. All other references to PCI SSC’s approval or acceptance of a product or version thereof are strictly and actively prohibited by PCI SSC, should be reported to PCI SSC, and constitute a breach of applicable PCI SSC program requirements.

When granted, PCI SSC acceptance is provided to signify the Assessor’s determination that the product has demonstrated achievement of certain security and operational characteristics important to the security of payment card data, but such acceptance does not under any circumstances include or imply any endorsement or warranty by PCI SSC regarding the product vendor, the product, or the functionality, quality, or performance of the product or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement, all of which are expressly disclaimed by PCI SSC. To the extent any rights or remedies regarding products or services that have received acceptance from PCI SSC are provided, those rights and remedies shall be provided by the party providing such products or services, and not by PCI SSC or any of its payment brand members.”

Misc PCI Requirements

The following section documents some of the final miscellaneous additional PCI compliance requirements that merchants will need to know or be aware of. These are presented here as 'things to do or know about' because they are not relevant in other parts of the installation guide.

Please use these as ticklers to yourself.

If card data is to be transmitted over a public network (i.e. outside your firewall), it must be sent using secure encryption technology like IPSEC, VPN or via TLS per PCI DSS 4.1.
Do not send any credit card data 'in the clear' such as pasting a card number into an email, or into an IM per PCI DSS 4.2 unless you are using secure encryption with these messaging technologies. Do not encourage customers to send card numbers, CVV2 numbers, name, expiry dates, or any other such data to you via the same technologies.

Theatre Manager does not provide this feature due to PCI compliance and only presents the final 4 characters to users for this reason.

If you are upgrading from a prior system that might have had unencrypted credit card information, you must throw that data into the trash and secure erase it with a tool like ERASER (free) on the PC or use File Menu -> Secure Erase on Mac.

Card Flow Across System

This diagram indicates the flow of card information in the various parts of the LAN segments described in the network architecture.

(Click to enlarge as a PDF)

Vulnerability Identification and Assessment

PCI requires that a venue establish a listing of security vulnerabilities and track them in a database as well as implement programs to prevent vulnerabilities PCI requirement 6.2.

Common Vulnerabilities and Exposures (CVE) vulnerabilities are reviewed at least monthly. As standard practice, Arts Management considers all CVE's to be a high priority for the software we incorporate. As such, these will be implemented using the auto deployment processes (regardless if they really affect Theatre Manager or not) under the principle of better to be safe than sorry. The release notes may mention any important fixes felt to be applicable.

We provide a list of vulnerabilities & patches specific to Theatre Manager and its components and update our installers regularly to address known issues.

Addressing PCI compliance and preventing most security issues is as simple as:

  • Keeping Theatre Manager up to date with the latest version (this occurs automatically via the auto deployment systems)
  • Updating all operating systems to current updates from the vendor
  • Having current anti-virus software in place

However, this is only one aspect of protecting your network. It is far more likely that vulnerabilities will arise from other programs. Here are some links that might be of interest to you to help maintain the health of your computers and networks.

Item Purpose
NIST.gov This web site has a list of recent security issues from the government web site. It is useful for seeing if there is something pertinent to your software suite. This is worth searching on a periodic basis.
NIST.org This web site has a summary of common security fixes and patches distilled from the government web site.
Secunia
PC only
PC's are vulnerable in a number of ways. Secuia is a free tool (for personal use) that inspects your PC and tells you about any vulnerabilities you may have on your PC that you are unaware of, and will automatically update versions of other software.

Note: Never forget to have anti-virus software on your machine.

Software Update Mac Only macOS has a software update feature for the operating system. For workstations, we recommend automatically applying security patches.
OSVDB This is an open source vulnerabilities database. We look at this periodically to see if there is anything that might affect tools that we supply to you. Apache and Postgres are both open source, so this is of interest to us. You may find other information, especially if you are using many open source tools.
QUALYS Labs Use this to verify if a TLS Certificate is setup right and if system scans are looking for new vulnerabilities

NGINX Vulnerability List

Nginx is auto deployed with each version of TM server.

It will always have the latest vulnerabilities mitigated per release notes and all attempts are made to deliver it within the mandated PCI time frame of 30 days of release (subject to testing and evaluation of other fixes).

Typical time to deployment is within 15 days.

Postgres Vulnerability List

The Theatre Manager postgres installers are always updated to the most recent version of postgres as soon possible after the postgres version it is released, ensuring any vulnerabilities are addressed by Arts Management as soon as a fix is released by the Postgres foundation.

Postgres vulnerabilities are monitored on the Postgres Security web site.

Those immediately relevant to Theatre Manager are listed with the release notes for that version of Theatre Manager and may require a forced update to the database server before an update to Theatre Manager will allow connection to the server.

OWASP and Theatre Manager

The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Their mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of the materials are available under a free and open software license.

The OWASP Top 10 for 2021 is interesting reading for application developers, web site builders, and end users. The internet has many good features, but it is not a safe place if you are not aware.

Each year, the Arts Management team reviews the top 10 and, for those that are applicable, ensures that the web sales module provides a defence against the top 10 per PCI standard 6.5. Requirements are posted here. Merchants should also be aware of these.
In addition, please be aware that IFRAMES are disabled in NGINX due to possibility of a Click-Jacking attack. An iframe has typically been used by people (like MOGO Interactive) selling marketing pixels to include their code in your web site. PCI council checks for Click Jacking opportunity - so we have disabled this in our standard web Server Setup.

2021 Top 10 List

  Description Theatre Manager Implementation

2021A01

2017A05

Broken Access Control Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits

2021A02

2017A03

2015A06

2013A06

Cryptographic Failures Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

Theatre Manager handles encryption of the key card information and recommends shredding of unused data after a period of time. All credit card information is re-encrypted on a periodic basis per PCI compliance and the only information retained is per PCI standards.

Theatre Manager web services use TLS for all traffic, which means using port 443 to the NGINX server, and having a valid TLS certificate.

Ensuring the TLS certificate is current is a responsibility of the monthly PCI scan process, and we contact customers when they are ready to expire.

Users are encouraged to define a card retention period where TM will automatically shred cards based on their policy.

2021A03

2017A01

2015A01

2013A01

Injection Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

OWASP's preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface.

In Theatre Manager, all web pages access the web listener using a parameterized API (generally html form) and each parameter is scrubbed on the way to the web listener for specific values. Only acceptable parameters are verified. Unacceptable parameters are rejected and ignored.

2021A04

Insecure Design Insecure design is a broad category representing different weaknesses, expressed as "missing or ineffective control design."

2021A05

2017A06

2015A05

2013A05

Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

The primary preventative measure for this is PCI security scans and upgrading of Theatre Manager components on a regular basis and following any implementation notes.

Users are encouraged to install operating system upgrades as they are made available and to turn on automatic checking on all workstations. On servers, the practice is to verify weekly for updates and install on a controlled basis.

Theatre Manager regularly offers the latest updates to web servers and TLS security patches when they are made available. Configuration files are hardened as vulnerabilities are detected (example: preventing directory listings is the default browser config).

2021A06

2017A09

2015A09

2013A09

Vulnerable and Outdated Components Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

Theatre Manager is designed to detect the version of significant components and will not start if the database version, web server version, or other significant components are insufficiently current.

Most importantly, TM Web Servers are regularly updated with security patches.

2021A07

2017A02

2015A02

2013A02

Identification and Authentication Failures Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

Theatre Manager uses cookies for session management. All data in the cookie is AES256 encrypted, along with a date and time.

If the web listener notices that the cookie comes back and contains an unexpected date and time setting, then it discards the request and resets the user.

There are no session IDs in any URL.

2021A08

Software and Data Integrity Failures Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations.

2021A09

2017A10

Security Logging and Monitoring Failures Security Logging and Monitoring Failures is to help detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected.

2021A10

Server-Side Request Forgery (SSRF) SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).

------- Historical References --------

2021MGD

2017A04

XML External Entities (XXE)

2021 merged with A05-Security Misconfiguration

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

2021MGD

2017A07

2015A03

2013A03

Cross-Site Scripting (XSS)

2021 merged into A03-Injection

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

OWASP's preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into.

Theatre Manager looks for any attempt to put Javascript and other characters into a form and simply removes them. We have determined that there is no valid need to have words like <script> in enterable fields like name or address.

2021MGD

2017A08

Insecure Deserialization

2021 merged into A08-Software and Data Integrity Failures

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

2017MGD

2015A04

2013A04

Insecure Direct Object References

2017 merged into A05-Broken Access Control

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Theatre Manage does not allow direct access to any object in the database through the use of an API. Users cannot retrieve data in an unauthorized way as all queries are done via a controlled API.

2017MGD

2015A07

2013A07

Missing Function Level Access Control

2017 merged into A05-Broken Access Control

Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

This does not directly apply to Theatre Manager's web services due to the APIs used to control access to the system -AND- the very limited number of pages in the WebPages directory which are used exclusively for the singular function of web sales.

Accessing the limited number of web pages in the WebPages directory in a direct manner does nothing unless they are processed by a web service.

2017n/a

2015A08

2013A08

Cross-Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Theatre Manager does not allow access to the database except via API. It also forces a timeout for inactivity and injects a unique form token key for each HTTP POST request.

The cookie is time sensitive and is unique for each request sent from the server and back from the client. It is encrypted and contains other non-visible data that must be verified upon receipt back at the server. Failure to meet the verification requirements causes rejection of the request and the process to start over. Absence of a properly formatted and encrypted cookie rejects the request and starts over.

The form token is a unique encrypted time-sensitive field that is placed into each web page by the server. When a form is submitted, the server checks the form token with what was sent out. If it does not match, the patron is sent to a 'safe' landing page. Currently, Theatre Manager sends patrons who are logged in to the 'home' page and those that are browsing anonymously to the 'event listing' page. No form can be submitted twice.

2017n/a

2015A10

2013A10

Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

Theatre Manager does not use redirects to any unknown source in any commerce web page. All URLs returned by the server are specific to each API. Requests for APIs that do not exist return a proper 404 HTTP response (not found)