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 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

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.

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.

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.

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.

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

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

• 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.

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

This is where your customers will be.

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.”

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.