However, if you need to set up firewalls on computers themselves, 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.

• Artsman: Web sales and database
• Customer: Workstations

Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.

Note: An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

• Artsman: Web sales and database
• Customer: Workstations

• Artsman: Web sales and database
• Customer: Workstations

(For example, block traffic originating from the internet with internal source addresses).

• Artsman: Web sales and database
• Customer: Workstations

• The web server should be on its own machine or VM so that it can, in effect, be sacrificed if hacked. It should have really tight firewall rules managing traffic into the device and out to ONLY the web lsitener on specific ports
• The database and web listeners could be on the same machine as long as access to each is carefully managed with appropriate firewall rules and they are not exposed to traffic from the the main firewall appliance directly

Note: Methods to obscure IP addressing may include, but are not limited to:

• Network Address Translation (NAT)
• Placing servers containing cardholder data behind proxy servers/firewalls or content caches
• Removal or filtering of route advertisements for private networks that employ registered addressing
• Internal use of RFC1918 address space instead of registered addresses.

Firewall configurations include:

• Specific configuration settings are defined for personal firewall software
• Personal firewall software is actively running
• Personal firewall software is not alterable by users of mobile and/or employee-owned devices.

• Artsman: YES
• Customer: Enable Firewall on Workstations

This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocl (SNMP), community strings, etc.

Change the Master User password when setting up the system.

Change any other vendor supplied passwords as described.

Sources of industry-accepted system hardening standards may include, but are not limited to:

• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST)

• Artsman: Web sales and database
• Customer: Workstations

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

• Artsman: Web sales and database
• Customer: Workstations

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Note: SSL, TLS 1.0 and TLS 1.1 are not considered strong cryptography and cannot be used as a security control after June 30, 2016.

Effective immediately, new implementations must use TLS 1.2 or later.

POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

The NGINX Server config disables all SSL protocols and enables only TLS 1.2

Theatre Manager will connect to service providers using the latest TLS that they support and have been verified to connect via TLS 1.2 when available.

• Artsman: Web sales and database
• Customer: Workstations

• Artsman: Web sales and database
• Customer: Workstations

We suggest that customer use RDC, Teamviewer or equivalent internally for remote access management.

• the database unless using the PCI 'C' setting
• TM server
• all workstations that can accept cards. Workstations can be taken out of scope with a setting in company preferences which limits the machines that can take credit cards.

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements
• Specific retention requirements for cardholder data
• Processes for secure deletion of data when no longer needed
• A quarterly automatic or manual process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements

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

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

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

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

• Schedule A-EP - using Moneris Hosted Payments
• Schedule C - keep no card data
• Schedule D - with one day retention for post dated payments only

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

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

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

• The cardholders name
• Primary account number (PAN)
• Expiration Date
• Service Code

• The cardholders name
• Card number (PAN), encrypted
• Expiration Date

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

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

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

All reports and most windows mask PAN

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

• One-way hashes based on strong cryptography
• Truncation (hashing cannot be used to replace the truncated segment of the PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key management processes and procedures

It uses field level encryption for PAN.

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

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

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

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

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

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

Store crpytographic keys in the fewest possible locations

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

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

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

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

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

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

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

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

for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key.

Venues do not know the cryptographic key.

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

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

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

• Only trusted keys and certificates are accepted.
• The protocol in use only supports secure versions or configurations.
• The encryption strength is appropriate for the encryption methodology in use

Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

• The Internet
• Wireless technologies including 802.11 and Bluetooth
• Global System for Mobile communications (GSM)
• General Packet Radio Service (GPRS).
• Satellite communications

Theatre Manager uses TLS 1.2 wherever possible to connect to credit card authorization servers for one time authorization and only allows TLS 1.2 or later for incomming web sales.

Theatre Manager does not use any wireless communication methodologies of any form.

Theatre Manager does not transmit any credit card information across public networks for any reason except in the process of authorization

• Artsman: Uses TLS 1.2 and TLS 1.3, when available.
• Customer: Must ensure that all workstations support TLS 1.2+

Note: The use of WEP as a security control is prohibited.

You will need write a policy on how you manually save CC data, how you track who has access to it, how you store it in a safe and/or behind locked doors.

Make sure the policy also includes that you never email card data in entirety and card data on paper is only kept as long as you need it.

Theatre Manager handles all transmission of data via TLS 1.2 or better (it only users the latest transmission security protocols as mandated by PCI.)

• PostgreSQL Server
• NGINX Server
• TM Server
• Workstations
• Remote Box Office

• Artsman: Web sales and database
• Customer: Workstations

• Artsman: Web sales and database
• Customer: Workstations

For Theatre Manager database and TM server, ensure those processes are the only thing running on the machine. Keep them separate from a domain server to limit who can actually log in to the server.

Check with the vendor of other systems in use.

• Artsman: Process isolation is used extensively and services are continuously monitored
• Customer: Workstations must be audited

• Are kept current
• Perform periodic scans
• Generating audit logs which are retained per PCI DSS Requirement 10.07

• Artsman: Web sales and database
• Customer: Workstations

Note: Anti-virus solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.

• Artsman: Web sales and database
• Customer: Workstations

• Artsman: This documentation and staff training
• Customer: Own staff training

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected.

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization's environment and risk- assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a "high risk" to the environment. In addition to the risk ranking, vulnerabilities may be considered "critical" if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data.

• Artsman: Web sales and database
• Customer: Workstations

Note: Critical security patches should be identifies according to the risk ranking process defined in requirement 6.1

• checking daily for updates to TM processes and/or
• automatically update affected components (optional).

Refer to the list of past and present issues to assist you updating your own vulnerability assessment.

We regularly review Postgres, NGINX & OpenSSL to provide the latest patches in each version our installers.

• Artsman: Web sales and database
• Customer: Workstations

• in accordance with PCI DSS (for example, secure authentication and logging)
• based on industry standard and/or best practices.
• Incorporating information security throughout the software development life cycle.

Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

• Artsman: Web sales and database
• Customer: Workstations

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices
• Code reviews ensure code is developed according to secure coding guidelines
• Appropriate corrections are implemented prior to release
• Code-review results are reviewed and approved by management prior to release

• Artsman: Theatre Manager applications, web sales and database
• Customer: Workstations

• Train developers in secure coding techniquies, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory
• Develop applications based on secure coding guidelines

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

• Artsman: Applications and default web page templates
• Customer: Customized web page templates

• Reviewing public-facing Web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
• Installing an automated technical solution that detects and prevents web-based attacks (for example web-application firewall) in front of public-facing web applications, to continually check traffic

AMS updates NGINX builds as needed (and config settings) to respond to newly reported threats.

AMS uses SPI for all web traffic internally.

• Artsman: This documentation and staff training
• Customer: Own staff training

• System components and data resources that each role needs to access for their job function
• Level of privilege required (for example, user, administrator, etc.) for accessing resources

This access control system must include the following:

• Enabled only during the time period needed and disabled when not in use.
• Monitored when in use.

There is a longer timeout in Company Preferences->Reports where you can specify when an idle user will be forced log off the system.

The process is:

• After 15 minutes, lock the screen and require a only a password to continue. This means any sales in progress or reports on screen will not be closed and are available once you enter your password after 15 minutes
• After the longer timeout, quit Theatre Manager completely.

• Something you know, such as a password or passphrase
• Something you have, such as a token device or smart card, specific IP, key access to a locked room
• Something you are, such as a biometric

User Passwords are stored in the database in encrypted format and established in PostgreSQL as a hash of that encrypted value.

When a user logs in, the password is converted to the salted hash and that is used to login. All communication to the PostgreSQL Database is over a secure connection, currently TLS 1.2 or better.

• Require a minimum length of at least seven characters.
• Contain both numeric and alphabetic characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

• Minimum 7
• One upper
• One lower
• One numeric
• One Special
• No repeated characters

Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

Examples of two-factor tehcnologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens, and other technologies that facilitate two-factor authentication.

• The user must start the application manually (it is not active by default)
• A unique Id must be provided to Artsman by the customer
• A single use token must be provided to ArtsMan that cannot be reused.

• Guidance on selecting strong authentication credentials
• Guidance for how users should protect their authentication credentials
• Instructions not to reuse previously used passwords
• Instructions to change passwords if there is any suspicion the password could be compromised.

• Generic user IDs are disabled or removed.
• Shared user IDs do not exist for system administration and other critical functions.
• Shared and generic user IDs are not used to administer any system components.

Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

• Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
• Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

• All user access to, user queries of, and user actions on databases are through programmatic methods.
• Only database administrators have the ability to directly access or query databases.
• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

Access to the db is controlled by the pg_hba.conf file and it is set so that all users must log in to read data.

The user's id for the database is set by the application and not known.

The password in postgres is set by the application and stored encrypted. Thus, the user cannot access the database even knowing their user ID and password because it is not the same as plain-text.

Cloud database access for users is managed through an access broker system (with revokable tokens) followed by customer user id/password

Note: "Sensitive areas" refers to any data center, server room or any area trefers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of- sale terminals are present, such as the cashier areas in a retail store.

For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks.

• Identifying onsite personnel and visitors (for example, assigning badges)
• Changes to access requirements
• Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).

• Access must be authorized and based on individual job function.
• Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

Procedures should include the following:

Document the visitor's name, the firm represented, and the onsite personnel authorizing physical access on the log.

Retain this log for a minimum of three months, unless otherwise restricted by law.

Note: These requirements apply to card- reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

• Make, model of device
• Location of device (for example, the address of the site or facility where the device is located)
• Device serial number or other method of unique identification.

Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

• Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.
• Do not install, replace, or return devices without verification.
• Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
• Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

The Theatre Manager logs can be exported to your common logging tools. Refer to exporting logs to see how to accomplish this.

Note: One example of time synchronization technology is Network Time Protocol (NTP).

Theatre Manager uses the time at the postgres server as the single time source for transactions across all workstations. All data istimestamped with now(), making time diferences on workstations irrelevant.

Regardless, an alert is given to a user if their workstation does not match the server to within 30 seconds.

Effectively, if the postgres server is set according to an NTP server; all workstations transactions are synced with the postgres server to create a unified approach to time.

• All security events
• Logs of all system components that store, process, or transmit CHD and/or SAD
• Logs of all critical system components
• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)

Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.

Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

Alternately, inspect each device that is within the card portion of the network and make sure wireless is off.

Note: on AMS cloud servers, all network connections are physical wiring - there are no possible WIFI access points.

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies

1. the most recent scan result was a passing scan,
2. the entity has documented policies and procedures requiring quarterly scanning, and
3. vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred.

Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.

Scans must be performed by qualified personnel.

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
• Includes coverage for the entire CDE perimeter and critical systems
• Includes testing from both inside and outside the network
• Includes testing to validate any segmentation and scope-reduction controls
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
• Defines network-layer penetration tests to include components that support network functions as well as operating systems
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
• Specifies retention of penetration testing results and remediation activities results.

Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
• Identifies critical assets, threats, and vulnerabilities, and
• Results in a formal, documented analysis of risk.

Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

Ensure these usage policies require the following:

• Artsman support is trained to only ask for one time access if needed and disconnect when done.
• The customer is required to provide the access and quit Teamviewer when a session is over.

Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.

Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include th

• Theatre Manager provides technology to manage data securely in PCI context but does not enter or use card data, nor maintain any merchant accounts on behalf of the customers.
• Each customer is solely responsible for engaging a merchant provider, processing all card (using Theatre Manager to assist). deciding on card data retention requirements, and maintaining policies for managing their data and merchant relationship.

• Roles, responsibilities and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
• Specific incident response procedures
• Business recovery and continuity procedures
• Data backup processes
• Analysis of legal requirements for reporting compromises
• Coverage and responses of all critical system components
• Reference or inclusion of incident response procedures from the payment brands