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 software used to process credit cards and can generally be done at 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 standard to assist the merchant meet overall PCI compliance.

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', '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
10.06 PCI PA/DSS 3.1 Theatre Manager verison 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 Oct 2015 the final document was approved by the PCI council with an expiry date of Oct 28, 2019 for new installations. The image to the left is from the PCI council's web site of validated applications. Search for Arts Management.

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

The audit took place in Oct 2014 the final document was approved by the PCI council.

All vendors are required to tell you this.

Upgrade Oct 2014.
10.00 PCI PA/DSS 2.0 Theatre Manager verison 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 council in October 2013. The image to the left is from the PCI council's web site of validated applications. Search for Arts Management.

All vendors are required to tell you this.

Upgrade Oct 2013.
9 PCI PA/DSS 1.2 Meets the PCI PA/DSS 1.2 standard and approved by the PCI council in Dec 2010. Upgrade to version 9 ASAP
8 PABP 1.4 meets the PABP 1.4 standard and was certified in Oct 2008. Please refer to our certificate and approval by Visa - page 6.
7 **Self Assessed in 2006 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 council at the time). Version 7 has name security measures as version 8 and was simply renamed version 8 as part of the audit.
6 **Self Assessed in 2003 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. However, version 6 should not be considered PCI compliant.

** Please note: PCI requirements have changed over the years. At one time, the PCI security 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


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

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.

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

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 of 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 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 customers 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)


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 pin-pad using dial up or IP connectivity. 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 limited to 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 pin pad device that talks to the bank. 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, analytics as it is not subject to PCI scope
  • End of day is broken into web sales and 'other' payments for box office'




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 computeres used primarily for setup, reporting and analysis.

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


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

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. Advantages are no data enters the network and you can be PCI A compliant. Disadvantages come with 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 does 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 you PCI compliance requirements.


Risk Profile

Theatre Manager, the AMS Cloud, and POS terminals offers 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 simple 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. This is negligible risk as TLS 1.2 is not known to have been compromised like TLS 1.0 or and of the SSL protocols. If TLS 1.2 were ever compromised, every web site and browser is in trouble as it is all that is our there in 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 signalled intent to re-sign certificates every few months as additional cautions for commerce.

PCI UserId and Password Requirements

Theatre Manager implements fully PCI DSS compliant AES256 encrypted passwords per PCI DSS standard 8.1 and this feature cannot be changed or overridden.

In addition, Merchants must use PCI DSS compliant passwords to access to all system components (i.e. any computer, firewall, router, etc. on the network) and these passwords must be changed from any vendor supplied initial values per PCI standard 2.1.

Note: do not reduce the level of authentication complexity or compliance in these other system components if it will result in PCI non-compliance.

This means all login passwords must be:

  • reviewed and changed every 90 days. Theatre Manager will enforce password changes automatically. This must be manually done on those devices that do not force change of passwords like routers and firewalls. (PCI DSS 8.1.4)
  • 7 characters or more (PCI DSS 8.2.3)
  • mixed case consisting of at least uppercase and one lower case letter (PCI DSS 8.2.3)
  • contain at least one number and special character (PCI DSS 8.2.3)
  • cannot be the same as an previous 12 passwords (PCI DSS 8.2.5)
  • cannot have characters or numbers repeated together
Change all passwords from any vendor default password that might be used for installation per PCI DSS 2.1. For example, you must:
  • Change the Theatre Manager 'Master User' password when the system is installed.
  • Change the user and and password on any router from anything printed in the manufacturer's documentation
  • Make sure that accessing each computer requires a password and does not 'auto-login'
  • Ensure that screen savers are implemented that require passwords to be entered whenever the screen saver is activated. Screensavers (or some other mechanism for locking computers) must activate after 15 minutes of idle time or less on all workstations and servers. Theatre Manager also has an inactivity timeout that will log people out of the application. Using both features improves security. (PCI DSS 8.1.8)

Each user that has access to any systems in your network must have a unique user id and password per PCI-DSS standard 8.1.1

Never use the Master User account for daily operation. It should only be used when creating other accounts or for other very specialized needs as directed by Arts Management Systems.

If your network has 'master' domain server (or open directory on OSX) available that could control password authentication for all machines, please ensure that the security policies on the domain/directory server is set to enforce PCI/DSS passwords and that all machines in the network log in using authentication from the server.

If a domain/open directory server is not available to enforce password settings, then each machine/user must use PCI/DSS compliant passwords.

If a user tries more than 6 times to gain access to the system, Theatre Manager automatically resigns the user - which means that they are locked out permanently until manually re-instated per PCI-DSS standard 8.1.6 and 8.1.8

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 www.techsoup.com 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 OSX, do no manage the built in firewall via System Preferences on servers - instead, consider using a tool like Murus Firewall to unlock the power of the OSX 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.

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


depends yes* 5432 from any 192.168.1.x
all to 192.168.1.x
37 to NTP server
2 Remote Box Office via VPN
(terminal server)
yes yes* as needed from internet all to internet
3 Web Services yes yes* 443
from (nginx server)
80, 443, 8111 to (web server)
5432 to (postgres)
53 for DNS, MX lookup
37 to NTP server
443 to www2.artsman.com
80 to maps.googleapis.com/maps/api/geocode

25 to SMTP server
110 to pop server for Facility Mgt

** Add 443 outgoing to credit card provider

4 Box Office Workstations yes yes* all from 192.168.1.x 80, 443, 8111 to (web server)
5432 to (postgres)
53 for DNS, MX lookup
37 to NTP server
443 to www2.artsman.com
80 to maps.googleapis.com/maps/api/geocode

80 to www.google.com/maps/api/staticmap
80 to help.theatremanager.com

** Add 443 outgoing to credit card provider

5 Ticket Printer no n/a 10001 from 192.168.1.x all to 192.168.1.x
6 Web Server yes yes* 80, 443 from internet port 443 to Web Services (if using TM 10.06 and later w/nginx)
7 Outside of Firewall no n/a 80,443 from internet
xxxx from internet
forward 80,443 to (Web Server)
forward xxxx to (Term Server)
8 Internal Wireless Router no n/a all from all to
9 Venue Lan computers not handling credit cards
no yes all from as needed to
10 wireless ticket scanners no n/a   n/a: communicates to outside of firewall on port 443

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

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 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 OSX, 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 OSX PF firewall.

This section describes the components of the Office Lan.

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.

Web Services

The ports that need to be opened for web services depends on which of the following you are using for loadbalancing:
  • Simple Setup - most venues with one or more machines doing web services
  • Custom Setup - multi outlet venues and high load setup

In all cases, you specify the ports to talk to listeners within the httpd-balance.conf configuration file.


Simple Setup for Load Balancing

In the simple setup situation, you just need to open port 5000 to each second generation listener and turn off the use of 'mod_tm' in the director. When any message is received by the second gen listener 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 Apache 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 apache server for high performance throughput -or-
    • a combination of the above, although load balancing the same listeners both internally and from apache might cause some side effects.
  • Classic Listener (only if mod_tm load balancing is enabled)
    • Open ports 5111-511x for classic services.
    • You need to open one port for each outlet running on that machine
The ports cannot be changed.

Multiple web servers/listeners can be set up to talk to apache. If you wish to restrict specific machines to be web listeners, enter the IP addresses of those machines in the Apache configuration.

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

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.

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.

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 WPA2 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 MC55 ticket scanners support WPA2 and can be used in either configuration.

The MC50 scanners only support WEP so they must be put on an external network connected directly to the internet to avoid being subject to the scope of PCI.

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 before accessing the office network or any part of the network where credit card information is stored.

The DMZ (NGINX Server)

The NGONX 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:
  • AES128 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 SSL 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.

Note: if installing on terminal server 2003, you may need to switch it between 'execute' and 'install' mode to actually install Theatre Manager.

If you are using remote box office and ticket scanning for access control at the same venue, it is advisable to set up the wireless access point to talk to the VPN router and send all data through the VPN tunnel as a point of extra security.

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 for access (the Symbol MC55 device supports WPA2)

The setup and functioning of the symbol MC55 wireless device is described in a separate document.

When you need to enter in the IP address, you can use tickets.yourvenue.org/TheatreManager/1 if you have set up a DNS or you can use the static IP address of the outside router.

You can also specify port 80 or 443 (or some other port if you wish to do address redirection within the router for additional security).

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.

Microsoft Remote Access

If you are using remote access, you need to set up 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)

Windows 2003/2008 Server

When connecting from any workstation to 2003/2008 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.



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


Windows 2000 Server

When connecting from any workstation to 2000 server, the server setting workstation is allowed to specify the security level and, unfortunately, it defaults to the lowest security level. You need to make some changes to the settings to connect at the high security level.

Step Purpose Installation instructions or link
1. Set up Terminal Server Settings

The Encryption Levels settings in Terminal Server should be set to High for the Remote Desktop Protocol. Refer to the tech note on the Microsoft web site for the proper procedure.

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

TeamViewer Remote Support

Theatre Manager uses TeamViewer for remote support. This is designed to never be active, unless the user contacts Arts Management and permits the technical staff to have access to their machine for the purpose of diagnosing a problem on a one time basis.

Remote access is to be

Theatre Manager never requires permanent access to your networks for any reason.

Remote Access/Support

The process for actual access to the remote machine is as follows:

  • The customer must initiate a support request that involves a phone conversation
  • In that phone conversation, it is determined that a timely resolution involves connecting remotely to provide assistance
  • Arts Management confirms the identity to the customer by providing the customer with the case number they created to continue with support (PCI requirement for second authentication).
  • The customer then starts the remote assistance software by clicking the Remote Support button from within the Theatre Manager application. Since you must have logged into Theatre Manager to activate remote support, It is not active by default.
  • The customer uses the remote assistance software to generate two keys: an ID and a random generated 8 character password (containing numbers and letters and, unique to the session). Both of these are conveyed to the AMS support representative.
  • Arts Management Support activates remote assistance manager and enters both keys to gain remote access
When Remote Access is disconnected, another remote support session requires a new set of keys to be provided. The customer is in complete control of the session at all times with a visual indicator showing the connection status.

How does it work?

TeamViewer uses SSH for authentication and brokering of session keys. It communicates with the master cluster through DNS names, which delegates the brokering of the session to the TeamViewer servers. Connection to the routing server and KeepAlive server is done directly via IP addresses.

The servers are spread across the globe and located at large data centers; their IP addresses are not organized in common subnets or IP ranges. TeamViewer continuously top scales the server network as the number of TeamViewer users grows, so it is not possible to have a fixed set of IP addresses, because this list would very soon be outdated.

Communication is done to URLs of the format:

  • *.teamviewer.com
  • *.dyngate.com
By default TeamViewer uses only the outgoing port 80 (HTTP) so that no firewall configuration is necessary. Alternatively you can open port 5938 (TCP) for outgoing connections if you wish to block port 80.

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 SSL/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 implementing programs to prevent vulnerabilities PCI requirement 6.2

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
  • 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.
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 OS X has a software update feature for the operating system. As of Mountain Lion, Apple is encouraging a number of developers to deploy using the App Store to help keep you up to date. If you have a number of utilities, this may be useful for you.
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 SSL Labs Use this to bverify if an SSL is setup right and if system scans are looking for new vulnerabilities

Apache PCI Update Notices

Periodically, we learn of new issues that may prevent a PCI scan from completing at a venue. These will be listed here as things you may need to do in response to emerging issues. Please be sure to implement all of them.

The date in front of the web pages below indicate approximately when the fix was released.

When we learn of one, you should upgrade Apache to the latest version to simply eliminate some PCI scan messages (see links below). Each advisory is incorporated into the latest installs where possible.

The latest Apache installers have fixes for all advisories and following the upgrade instructions for Apache should suffice to meet all identified vulnerabilities below.

Apache/Open SSL security Notices

Date Vulnerability Description Action
2012-06-14 CVE-2012-3499 Various XSS flaws due to unescaped hostnames and URIs HTML output in mod_info, mod_status, mod_imagemap, mod_ldap, and mod_proxy_ftp.

Upgrade Apache to 2.4.4 or later

2012-08-21 CVE-2012-4558 XSS in mod_proxy_balancer manager interface. Upgrade Apache to 2.4.4 or later This is used for the second generation listener
2012-01-19 CVE-2012-0883 Fix insecure handling of LD_LIBRARY_PATH that could lead to the current working directory to be searched for DSOs. Upgrade to Apache 2.4.3 or later to prevent listing of items
2011-12-07 CVE-2012-0053 Fix an issue in error responses that could expose "httpOnly" cookies when no custom ErrorDocument is specified for status code 400 Upgrade to Apache 2.4.1 or later
2011-12-07 CVE-2012-0021 Fix segfault (crash) when the '%{cookiename}C' log format string is in use and a client sends a nameless, valueless cookie, causing a denial of service. The issue existed since version 2.2.17 and 2.3.3. Upgrade to Apache 2.4.0 or later
2012-05-10 CVE-2012-2333 Sanity check record length before skipping explicit IV in TLS 1.2, 1.1 and DTLS to avoid DoS attack. Upgrade to OpenSSL 1.0.1c
2012-04-19 CVE-2012-2110 Check for potentially exploitable overflows in asn1_d2i_read_bio BUF_mem_grow and BUF_mem_grow_clean. Refuse attempts to shrink buffer in CRYPTO_realloc_clean Upgrade to OpenSSL 1.0.1a
2012-03-12 CVE-2012-0884 Fix MMA (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) weakness in CMS and PKCS7 code. When RSA decryption fails use a random key for content decryption and always return the same error. Note: this attack needs on average 2^20 messages so it only affects automated senders. The old behaviour can be reenabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag: this is useful for debugging and testing where an MMA defence is not necessary. Upgrade to OpenSSL 1.0.0g
2012-01-18 CVE-2012-0050 Fix for DTLS DoS issue introduced by fix for CVE-2011-4109 Upgrade to 1.0.0f
2012-01-04 CVE-2011-4108 Nadhem Alfardan and Kenny Paterson have discovered an extension of the Vaudenay padding oracle attack on CBC mode encryption which enables an efficient plaintext recovery attack against the OpenSSL implementation of DTLS. Their attack exploits timing differences arising during decryption processing. A research paper describing this attack can be found at: http://www.isg.rhul.ac.uk/~kp/dtls.pdf Upgrade to 1.0.0e
2012-01-04 CVE-2011-4576 Clear bytes used for block padding of SSL 3.0 records Upgrade to 1.0.0e

2010-01 Improve Cipher Suite security

Edit the extra/httpd-ssl.conf file and look for the line of code that pertains to SSLCihperSuite. Then make changes as below. You will end up commenting the existing line and adding two lines in bold.

note: this change is included in the latest install of apache. Older sites will need to make this change.

# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
# Updated the following Apache Core Features for PCI Compliance reasons
# Refer to: http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslprotocol
# Refer to: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html
# Synopsis : The remote service supports the use of medium strength SSL ciphers.
# Description : The remote host supports the use of SSL ciphers that offer medium
# strength encryption, which we currently regard as those with key lengths
# at least 56 bits and less than 112 bits.
# Solution: Reconfigure the affected application if possible to avoid use of medium
# strength ciphers.
SSLProtocol -all +TLSv1 +SSLv3

2010-01 Prevent Trace and directory listings

If you are doing compliance scans and using windows as an Apache Server, then you may want to update to the Apache 2.2.15 (or later) if your scans are failing.

Edit the httpd.conf file and add changes as below at the end of the file. They address some recent items that PCI security scans now look for.

# ---------------------- to tighten security in browser ----------
# Updated the following Apache Core Features for PCI Compliance reasons
# Disable the TRACE/TRACK command
# refer to: http://httpd.apache.org/docs/1.3/mod/core.html#traceenable
TraceEnable Off

# To enforce or deny complete folder listing
# refer to: http://httpd.apache.org/docs/1.3/mod/mod_autoindex.html#indexignore
IndexIgnore *

    2010-04 .DS_STORE files flagged as issues

    If you navigate the Apache htdocs folder using a Macintosh, it will leave hidden files with the name '.DS_STORE' in the directories. Those files are used by the OSX file system to remember how the window was opened and what view they should be in - a fairly convenient feature.

    The PCI guardians have determined that they do not like any hidden files in the htdocs directory as they view it as a possible attack vector - and if a PCI compliance scan finds these, it will flag you as non-compliant.

    As of Apache installer 2.4.4 for TM version 9.23 we have replaced some apache configuration settings that should just allow you to pass. If you are not passing your PCI scan, make sure you are at the latest version of apache. Alternately, follow the procedure below:

    • OSX Apache: We have created a script for you that you can run daily using cronnix that will clean out these files automatically. You will find this in the /Users/Shared directory called 'TMApachePCIScan.php'.
    • Use Cronnix to create a daily job on your apache machine to run this script. Cronix is installed as part of the Apache installer into your Applications folder. The setup is similar to below. (if you cannot find it, click on the google source forge link to download)

    • Windows Apache: use find files to find all ".DS_STORE" files on your machine and delete them.

    Note: The installation process removes these files for you automatically, but they will come back if your web designer edits any web pages on a Mac by virtue of opening any folder inside the htdocs directory.

    2010-11 FileEtag

    If you are getting messages about FileEtag in your compliance scan, you may need to add the following to your httpd.conf file. This is provided with the latest TM installers.

    Edit the httpd.conf file and add changes as below at the end of the file. They address some recent items that PCI security scans now look for.

    # To remove Inode information from ETag
    FileETag MTime Size

    2011-11 OpenSSL < version 1.0.0e on OSX

    This assumes that your PCI scan is failing on your OSX apache server verison 2.2.17 or later. Normally Apple updates operating system components but in the case of OpenSSL, it is compiled right into the Apache server.

    The latest version of our apache installers for OSX include openssl 1.0.0e and all you need do is upgrade to the latest version of Apache.

    2012-01 Open SSL 1.0.0g on Windows

    We have been hearing that recent Security Metrics PCI scans have identified a vulnerability in OpenSSL version 0.9.8. There is a new version of OpenSSL 1.0.0g that should be installed on MS Windows Apache server. Normally this comes as part of Apache and is installed automatically but Apache Software Foundation has not released a version as of yet.

    The remedy is to download and install an another flavor of Apache and upgrade that version of Apache to use OpenSSL 1.0.0g or higher from Apache Haus

    NOTE: Apache 2.2.22 and OpenSSL 1.0.0g are the most recent versions available as of updating this web page on Jan 31, 2012. The respective organizations who maintain the installers for Apache and OpenSSL may release new updates at any time. It is your organizations responsibility to check that they are installing the most recent version at the time of update.

    Your options are:

    • Wait until Apache Software Foundation releases a version with OpenSSL 1.0.0g or higher
    • Install the version of Apache as outlined below
    • Have Arts Management install the version of Apache as outlined below
    • Leave things as they are for a while, knowing that a PCI test 'may' continue to indicate that the OpenSSL needs to be upgraded. After you have evaluated the risk assessment from the PCI report, you can choose to address it at sometime in the future - or - accept the risk and not upgrade at this time.

    There is a bit of work to do to perform this and takes approximately 1 hour worth of time. Web sales will need to be taken offline for approximately 5 minutes during the process -- meaning you can do this upgrade during a time when there is minimal web sales activity.

    • On the computer running as the Apache server, download:
      • STEP 1 - Install Apache 2.2.22
      • If required, install the Microsoft Visual C++ 2008 Redistributable Package and Service Packs
      • Extract the httpd-2.2.22-ssl-x86.zip files
      • Review the two "readme_first.html" files located within the respective extracted folder
      • Move the httpd-2.2.22-ssl-x86.zip extracted files and place in the root c:\ level and called c:\Apache22
      • Delete all files in the c:\Apache22\htdocs folder
        STEP 2 - Update to the most recent version of OpenSSL
        NOTE: Skip these next 4 steps as Apache 2.2.22 contains the most recent version of OpenSSL 1.0.0g
      • If required, install the Microsoft Visual C++ 2008 Redistributable Package and Service Packs
      • Extract the openssl-1.0.0d-update-sni-x86.zip files
      • Review the two "readme_first.html" files located within the respective extracted folder
      • Move the openssl-1.0.0d-update-sni-x86.zip extracted files and replace the respective files in the c:\Apache22 folder
        STEP 3 - Move your existing Theatre Manager Web Sales Setup Information
      • From the existing copy of Apache in the c:\Program Files\Apache Software Foundation\Apache2.2 folder, copy over to the c:\Apache2.2 folder:
        • \data (the entire folder)
        • \modules\tm_mod.so
        • \htdocs (the entire folder)
        • \conf\server.crt and place into the \conf\ssl folder
        • \conf\server.key and place into the \conf\ssl folder
        • \conf\server.csr (this file may not exist) and place into the \conf\ssl folder
        • \conf\ca-bundle.crt (this file may not exist) and place into the \conf\ssl folder
      • Update (DO NOT COPY) c:\Apache22\conf\httpd.conf with the required Theatre Manager information from c:\Program Files\Apache Software Foundation\Apache2.2\httpd.conf
      • Update (DO NOT COPY) c:\Apache22\conf\extra\httpd-ssl.conf with the required Theatre Manager information from c:\Program Files\Apache Software Foundation\Apache2.2\extra\httpd-ssl.conf
      • Review the httpd.conf and httpd-ssl.conf files for any additional PCI update/requirements that may need to be added or adjusted as per Theatre Manager's release notes and Theatre Manager's Apache setup configuration guide
      • Stop Theatre Manager's Web Listener(s)
      • De-install the existing application of Apache2.2 via Windows "Add/Remove Programs"
      • Install c:\Apache22 as a service (as each Windows OS is unique, refer to your local IT support for assistance)
      • Go into Windows Services Window and start the Apache service
      • Start Theatre Manager's Web Listener(s)
      • Update Windows Startup folder to have it automatically start Apache Monitor upon login
      • Delete the c:\Program Files\Apache Software Foundation folder
      • Update FileZilla User settings for Theatre Manager's eblast home folder to be c:\Apache22\htdocs

      Then try your PCI scan again. We understand from the PCI council that you have approximately 30 days from identification of the problem at your venue to resolution. Select a slow day to do the upgrade as it should only take approximately 1+/- hours to complete. (as this may be your first and perhaps only time doing it, we would recommend that you allocate 2+/- hours just in case)

      If you wish to have Arts Management perform the above upgrades to your copy of Apache, please let us know and we will schedule a date/time with you. It typically takes approximately 1+/- hours to complete and is deemed a billable service.

      Some of the gotcha's you may encounter along the way are:

      • On the Apache Server, you must first install the Visual C++ 2008 Redistributable Packages
      • If you have a x64 bit machine, you still must install the x86 Visual C++ 2008 Redistributable Packages
      • If you have a x64 bit machine, you still must install the x86 version of Apache2.2
      • When editing the /conf/extra/httpd-ssl.conf file, you must also update the ServerName and ServerAdmin parameters
      • The placement of the SSL certificate location is different and is located in the c:\Apache22\conf\ssl folder
      • When attempting to install Apache as a service, if you receive "unauthorized access errors", go back and start the Command console again by Right-clicking on it and selecting "Run as Administrator"
      • When attempting to install Apache as a service, if you receive "side-by-side errors", go verify if you have installed the Visual 2008 C++ Redistributable Packages

      We have tried the following OpenSSL links, however they did not prove to be successful when using the OpenSSL 1.0.0.d upgrade with the standard installation of Apache 2.2.17

    2012-11 Browsable Web Directories

    Browsable Web Directories indicate the scan can reach the numeric folder within the htdocs folder. Although it cannot see any of the files or folders within this folder, accessing the folder causes the scan to fail. This Failure has only been seen on Windows machines where Apache is installed. This does not limit it to this platform however the steps below reference the paths within the windows environment.

    • Open the c:\Apache24\htdocs folder.
    • Select the index.html page.
    • Right click on the index.html page and select the copy options.
    • Open the c:\Apache24\htdocs\1 folder.

      Please note the number 1 references the outlet number. It is possible the Outlet number for an organization may be something other then 1. If this is the case open the numeric folder. If there are multiple outlets the steps below will need to be repeated for each Outlet.

    • Right click within the folder.
    • Select Paste.

      The index.html page will be added to the folder. This will resolve the Browsable Web Directories error in the Security Metrics Scan.

    Note: this setup is part of all future web page installations on mac and windows platforms.

    2013-03 Apache 2.4.4/OpenSSL 101e

    Apache 2.4.4 was released in Feb 25, 2013 along with Open SSL 1.0.1e. If you receive a failing scan highlighting these components, you will need to upgrade them.

    There are some notes about Apache 2.4.4

    • For OSX: the installers are 64 bit and for OSX 10.6.8 or later. This means you require a core 2 duo machine (circa 2007 or later)
    • For windows: apache is still 32 bit and has been tested on windows 2000 through Windows 8. It should run on all platforms

    2014-04 CVE-2014-0160 Heartbleed bug

    What is the CVE-2014-0160?

    CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by the MITRE. Due to co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned to us, should not be used, since others independently went public with with the CVE-2014-0160 identifier.

    For more info, please refer to heartbleed bug documentation. This site explains it reasonably well.

    Fixed in Apache 2.4.9 download

    2014-08 Apache 2.4.10 Openssl 1.0.1i

    There is an update to Openssl to address recently discovered vulnerabilities in OpenSSL 1.0.1. Updating should be relatively easy to update if you already have apache 2.4.9 or later

    CVE-2014-3512 Fix SRP buffer overrun vulnerability. Invalid parameters passed to the SRP code can be overrun an internal buffer. Add sanity check that g, A, B
    CVE-2014-3511 A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate TLS 1.0 instead of higher protocol versions when the ClientHello message is badly fragmented. This allows a man-in-the-middle attacker to force a downgrade to TLS 1.0 even if both the server and the client support a higher protocol version, by modifying the client's TLS records.
    CVE-2014-3510 OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are subject to a denial of service attack. A malicious server can crash the client with a null pointer dereference (read) by specifying an anonymous (EC)DH ciphersuite and sending carefully crafted handshake messages.
    CVE-2014-3507 By sending carefully crafted DTLS packets an attacker could cause openssl to leak memory. This can be exploited through a Denial of Service attack.
    CVE-2014-3506 An attacker can force openssl to consume large amounts of memory whilst processing DTLS handshake messages. This can be exploited through a Denial of Service attack.
    CVE-2014-3505 An attacker can force an error condition which causes openssl to crash whilst processing DTLS packets due to memory being freed twice. This can be exploited through a Denial of Service attack.
    CVE-2014-3509 If a multithreaded client connects to a malicious server using a resumed session and the server sends an ec point format extension it could write up to 255 bytes to freed memory
    CVE-2014-5139 SL client with a null pointer dereference (read) by specifying an SRP ciphersuite even though it was not properly negotiated with the client. This can be exploited through a Denial of Service attack.
    CVE-2014-3508 A flaw in OBJ_obj2txt may cause pretty printing functions such as X509_name_oneline, X509_name_print_ex et al. to leak some information from the stack. Applications may be affected if they echo pretty printing output to the attacker.

    2014-10 OpenSSL 1.0.1j

    please read the openssl release info more detailed information. The latest Apache2.4.10/openssl 1.0.1j installers for your platform includes all fixes.

    SRTP Memory Leak (CVE-2014-3513)

    Severity: High

    A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected.

    2014-10 POODLE Attack (CVE-2014-3566)

    The POODLE Attack is restricted to the SSL v3 protocol used by older browsers and is described as a man-in-the middle attack that can be hard to do unless the intruder in within your wifi network.

    It may prevent older browsers on windows XP like IE 6 from being able to use your web site, but thats a small part of the market these days.

    Disabling SSLv3 is straightforward. In the /conf/extras/httpd-balance.conf file, look for the following line:

    SSLProtocol ALL -SSLv2

    and change it to

    SSLProtocol ALL -SSLv2 -SSLv3

    After making the change:

    • restart apache
    • Verify your servers protection standing. using the SSL Labs test page if you wish.

    2015-02 Apache 2.4.12


    CVE-2014-3583 (cve.mitre.org) mod_proxy_fcgi: Fix a potential crash due to buffer over-read, with response headers' size above 8K.
    CVE-2014-3581 (cve.mitre.org) mod_cache: Avoid a crash when Content-Type has an empty value. PR 56924.
    CVE-2014-8109 (cve.mitre.org) mod_lua: Fix handling of the Require line when a LuaAuthzProvider is used in multiple Require directives with different arguments. PR57204.
    CVE-2013-5704 (cve.mitre.org) core: HTTP trailers could be used to replace HTTP headers late during request processing, potentially undoing or otherwise confusing modules that examined or modified request headers earlier. Adds "MergeTrailers" directive to restore legacy behavior.

    2015-03 OpenSSL 1.0.2a

    On March 19 2015 , some vulnerabilities were announced by the openssl organization.

    We have updated our apache installers to 2.4.12 with openssl 1.0.2a to provide the latest for people. Refer to the Upgrade Instructions or ask support for assistance.

    2015-06 Apache 2.4.16 OpenSSL 1.0.2d TLS 1.2 and CLickjacking

    The latest installers include updates to apache and OpenSSL 1.0.2d to address announced security vulnerabilities.

    The Apache configuration has been changed to limit access using TLS 1.2 (TLS 1.0 and TLS 1.1 have been disabled). This will limit older version of internet explorer from connecting to the commerce site.

    Also added a setting in httpd.conf is a setting to prevent click-jacking by disabling use of iFrames within the web site.

    2015-12 Apache 2.4.17 OpenSSL 1.0.2e

    Upgrading is recommended

    Major changes between OpenSSL 1.0.2d and OpenSSL 1.0.2e [3 Dec 2015]

    • BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193)
    • Certificate verify crash with missing PSS parameter (CVE-2015-3194)
    • X509_ATTRIBUTE memory leak (CVE-2015-3195)
    • Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs
    • In DSA_generate_parameters_ex, if the provided seed is too short, return an error

    2016-01 Apache 2.4.18 OpenSSL 1.0.2f

    The open ssl foundation released an update to OpenSSL and issued an OpenSSL advisory. At the same time, we have updated the apache installers to version 2.4.18.

    PCI compliance section 6.2 requires that we make these available to you as soon as possible.

    CVE-2016-0701 [High severity] 28th January 2016

    Historically OpenSSL usually only ever generated DH parameters based on "safe" primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server's private DH exponent if it's reusing the private DH exponent or it's using a static DH ciphersuite. OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk. OpenSSL before 1.0.2f will reuse the key if: - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not set. - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is an undocumted feature and parameter files don't contain the key. - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. It will not reuse the key for DHE ciphers suites if: - SSL_OP_SINGLE_DH_USE is set - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the callback does not provide the key, only the parameters. The callback is almost always used like this. Non-safe primes are generated by OpenSSL when using: - genpkey with the dh_rfc5114 option. This will write an X9.42 style file including the prime-order subgroup size "q". This is supported since the 1.0.2 version. Older versions can't read files generated in this way. - dhparam with the -dsaparam option. This has always been documented as requiring the single use. The fix for this issue adds an additional check where a "q" parameter is available (as is the case in X9.42 based parameters). This detects the only known attack, and is the only possible defense for static DH ciphersuites. This could have some performance impact. Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default and cannot be disabled. This could have some performance impact. Reported by Antonio Sanso (Adobe).

    Fixed in OpenSSL 1.0.2f (Affected 1.0.2e, 1.0.2d, 1.0.2c, 1.0.2b, 1.0.2a, 1.0.2)

    Read the following link for making a dhparam file

    CVE-2015-3197 [Low severity] 28th January 2016

    A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2. Reported by Nimrod Aviram and Sebastian Schinzel.

    Fixed in OpenSSL 1.0.2f (Affected 1.0.2e, 1.0.2d, 1.0.2c, 1.0.2b, 1.0.2a, 1.0.2)

    2016-03 Apache 2.4.18 OpenSSL 1.0.2g

    The open ssl foundation released an update to OpenSSL and issued an OpenSSL advisory. The majority of the changes affect openssl v2 which we turned off long ago in our Apache installers.

    PCI compliance section 6.2 requires that we make these available to you as soon as possible.

    CVE-2016-0800 [High Severity] Cross-protocol attack on TLS using SSLv2 (DROWN)

    A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800).

    Recovering one session key requires the attacker to perform approximately 2^50 computation, as well as thousands of connections to the affected server. A more efficient variant of the DROWN attack exists against unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below).

    Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they've not done so already. Disabling all SSLv2 ciphers is also sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers.

    OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN:

    SSLv2 is now by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of:

    SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
    SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

    as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available.

    In addition, weak ciphers in SSLv3 and up are now disabled in default builds of OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers.

    OpenSSL 1.0.2 users should upgrade to 1.0.2g
    OpenSSL 1.0.1 users should upgrade to 1.0.1s

    This issue was reported to OpenSSL on December 29th 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Viktor Dukhovni and Matt Caswell

    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.

    mod_tm apache plugin

    The latest apache installers always have the latest mod_tm.so included and following the upgrade instructions for apache address al issues.

    Note: the need to use of this module is slowly being phased out as the TM Server (second generation) handles load balancing within the web services with the easy setup. As of version 10.06, it is no longer required.

    Mod_tm.so is a load balancer module for apache design specifically for the classic web listeners. This section indicates when issues were found and the resolution for the issues.

    1012-02 mod_tm 1.4.2 may crash apache

    The 1.4.2 version of the Apache Module is known to cause Apache to restart resulting in Theatre Manager's web listener crashing. This issue can be addressed by upgrading the version of the Apache Module to 1.4.7 or higher.

    2012-07 mod_tm 2.0.0 released for 64bit

    this version is identical in functionality to version 1.4.7 with two exceptions:
    • It was built for Apache 2.4.4 using apache 2.4.4 headers. (1.4.7 is for Apache 2.2.x)
    • it has been tested to run under 64 bit apache for OSX and windows

    Upgrading to apache 2.4.x will automatically install the most recent version of mod_tm.so.

    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 2013 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 Apache due to possibility of a ClickJacking attack. An iframe has typically been used by people 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.

    2015 Top 10 list (unchanged from 2013)

      Description Thestre Manager Implementation
    A1 SQL 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.

    A2 Broken Authentication and Session Management 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.

    A3 Cross-Site Scripting (XSS) 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.

    A4 Insecure Direct Object References 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.

    A5 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 SSL security patches when they are made available. Configuration files are hardened as vulnerabilities are detected (example: prevent directory listings is the default browser config).

    A6 Sensitive Data Exposure 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 SSL for all traffic, which means using port 443 to the Apache server, and having a valid SSL certificate.

    Ensuring the SSL 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.

    A7 Missing Function Level 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 Apache directory which are used exclusively for the singular function of web sales.

    Accessing the limited number of web pages in the htdocs directory in a direct manner does nothing unless they are processed by a web services. Further, all requests are sent through a specialized Apache module that adds additional tokens not known visible in the browser and reroutes the URL and does some NAT translation of its own.

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

    A9 Using Known Vulnerable 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, Apache is regularly reviewed and updated with security patches.

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