You are here

Home › Newsletters › ams

PA DSS 3.2.1 Documentation Index

Subscribe to Syndicate
The following table is a cross reference between the Arts Management documentation and the PA DSS 3.2.1 audit for ease of finding it.
During the development process, and especially changes that may affect PCI related fields and procedures, refer to the documentation, testing procedures and authorization procedures that are pertinent below.

PCI Audit Security Policy/Standards Requirement Location in Documentation
1.0 Do Not Retain Mag Stripe or CVV2 Data  
  1.1.4a Securely delete any sensitive auth. data stored by prev. versions
  Verify PADSS Implemetation guide includes instructions for merchants on how to securely remove historical non PCI compliant authentication data stored by previous versions of the software. Include detailed procedure and/or tools to be used to securely remove historical data.  Document should note this is necessary for full PCI compliance. There has never been historical non-compliant authentication data.
  1.1.5a Documentation of Vendor Procedures for customer troubleshooting
  Documented procedures must include 1) directive to collect sensitive data only when needed to solve specific problem, 2) Storage of data in secure known location with limited access, 3) Collect only the data that is necessary to solve the problem, 4) Encrypt sentitive data on vendor systems while stored, 5) Secure deletion process to be done immediately after use. AMS Data Policies
  1.1.5c Customer/Reseller Procedures for Troubleshooting
  Verify PADSS Implemetation guide includes instructions for resellers/integrators on collecting, storing, handling, encryption and deleting sensitive debug or troubleshooting files (see PADSS 1.1.5c Testing Procedures for specifics). Theatre Manager has no resellers.
2.0 Protect Stored Cardholder Data
  2.1.a Process for secure purging of data after retention period
  Verify PADSS Implemetation guide includes the  instructions for purging cardholder data that exceeds the customer-defined retention period.  Guide must state this is a necessary requirement for PCI compliance. Maintain a list of all locations where the payment application stores cardholder data that will eventually need to be purged.  See Schedule C/D compliance and shredding credit cards
  2.7.a Securely delete any crypt keys stored by prev. versions
  Verify PA DSS Implementation guide includes instructions for merchants on how to securely remove historical non PCI compliant crypto keys stored by previous versions of the software.  Document should note this is necessary for full PCI compliance. How to re-encrypt historic data with new keys. All encryption keys are completely unknown to the customer. They are generated randomly and are at least 40 characters long, mixed case, with numerics etc. and never ever displayed to the customer. One key is encrypted in the database, the second in the application. Both are needed to access stored data.

Theatre Manager supports:

  • Manual Re-encryption: a customer can invoke re-encryption credit cards at any time should they suspect compromise
  • Major Version Upgrades: generates new crypto keys and destroys old by using the same process above.
  • Periodically: if there are no major version upgrades, a server process will automatically re-encrypt data periodically and without customer intervention - currently 150 days
3.0 Provide Secure authentication Features
  3.1c Application should require unique user ID and secure authentication
  Verify customers and resellers/integrators are advised against using (default) administrative accounts for application logins Refer to section on passwords
  Documentation should advise customers to assign secure authentication to default accounts, disable or do not use the accounts.
  Documentation should also advise customers and resellers/integrators to assign secure authentication for payment applications and systems whenever possible.
  Documentation should advise customers and resellers/integrators how to create PCI DSS-compliant secure authentication to access the payment application (per PCI-DSS 8.5.8 - 8.5.15).
  Documentation should advise customers and resellers/integrators are advised that changing “out of the box” installation settings for unique user IDs and secure authentication will result in non-compliance with PCI DSS. It is not possible to reduce password settings in Theatre Manager. Customers are advised not to reduce settings in other components
  3.2 Access should require unique username and password
  Verify customers and resellers/integrators are advised to control access to any systems in the cardholder network, via unique username and CISP-compliant complex passwords. refer to passwords and adjusting security settings
4.0 Log application activity
  4.2 Automated audit trail to track and monitor access
  Verify that customers and resellers/integrators are instructed on how to set CISP-compliant log settings, per PCI Data Security Standard 10.2 and 10.3. And that disabling the logs will result in PCI non-compliance.  NOTE: Documentation wording must specifically address PCI-DSS 10.2.1 - 10.2.7 and 10.3.1 - 10.3.6. refer to PCI Audit log settings
5.0 Develop secure applications (Internal vendor documentation, not customer documentation)
  5.1 Vendor Software Development Life Cycle Documentation
  Verify software development processes are based on industry standards for software development and that security is included throughout the development life cycle. Arts Management uses the Agile Software Development Process as defined in numerous Wikipeida and numerous books on the subject.
  Verify all changes to existing code or additions of new code are tested before release. Includes all security patches and software changes. See that documented process includes all points noted in PA-DSS 5.1.1.x. Detail the process that must be followed to document that these tests have been performed (steps for traceablity and accountability). All code changes are tested and built into developer releases following the developer coding cycle. An integral portion of that is testing, especially security testing where appropriate.
  Require separate development, test, and build envrionments Refer to AMS Product Development Process separation of environments
  Require separation of duties between development, test, and build functions Refer to development coding cycle in the Product Development Process
  Require that live PAN data is not used in development or testing. The Product Development Process refers to the AMS Data Policy.   Refer also to TM coding practices and testing practices
  Require the removal of all test accounts and data from application before release Refer to Product Development Process . The final build process removes all comments, which includes any commented security information.
  Require internal code reviews of all new or modified code in the payment application (both internal and web applications). Must be reviewed by qualified individual other than code originator (internal or 3rd party) using manual or automated proceses .  Corrections must be implemented and management must approve code review results before release. Code reviews must be tracked in the change mangement control procedures. Refer to Product Development Process peer reviews
  Verify that documentation includes process for training of developers on secure coding techniques (OWASP, etc.). See AMS product Development Process on secure testing and OWASP Refer also to TM coding practices for protecting sensitive information in the code and protected classes
  Testing of all web based applications (internal or externally exposed) must be conducted and application checked for common web vulnerabilities.  Testing process should at minimum attempt to exploit vulnerabilties noted in PA-DSS 5.2.1-5.2.10. Refer to AMS Product Development Process, section on security testing
  Verify the existance of a documented change control process that tracks changes to the application, customer impact, management signoff, functionality testing, and back-out (see PA-DSS 5.3.x). Change control is managed through: Once a release is approved, the backout process is easily reversible.
6.0 Protect wireless transmissions
  6.1 Wireless transmissions of cardholder data must be secure.
  Verify that customers and resellers/integrators are instructed, if wireless is used in their network, to install a firewall per PCI DSS Requirement 1.2.3.) Theatre Manager does not require wireless within the lan. However, clients will user them and the Network Diagram illustrates proper usage. Configuration is also explained
  6.2 Wireless technology must implement strong encryption
  Verify customers and resellers/integrators are instructed on PCI DSS-compliant wireless settings, per PCI DSS Requirements 1.2.3, 2.1.1 and 4.1.1. refer to Venue Lan setup
7.0 Test applications to address vulnerabilities (Internal vendor documentation, not customer documentation)
  Vendor process documentation should detail how new vulnerabilities may affect the payment application. Identify outside sources to be used for vulnerability information. Process should include requirement to test code against newly discovered vulnerabilities. Refer to the coding practices documentation and vulnerability/awareness training
  Vendor process documentation should detail how security patches or software upgrades are deployed.  The process must cover all bullets of PA-DSS requirement 7.2a (timely development, chain-of-trust, maintaining and testing integrity of the patch). The Upgrade Process requires customers to 'pull' down an update (they are never 'pushed') and indicates the delivery process. The integrity of the installer is maintain automatically. It if it not complete, it will not run.
8.0 Facilitate secure network implementation (No PADSS Documentation Requirements)
9.0 Cardholder data must never be stored in the DMZ
  9.1b Application does not require web and DB server to be the same box.
  Verify customers and resellers/integrators are told not to store cardholder data on Internet-accessible systems (e.g., web server and database server should not be on same server.) Refer to TM Server Nginx Installation and Network Diagram
10.0 Facilitate secure remote software updates
  Verifiy documentation contains instructions regarding useage of secure remote access methodologies (if applicable), per PCI Data Security Standard 12.3.9 Refer to Team Viewer Remote Support which is ordinarily used for support only. However, customers can use it so that we could perform the standard upgrade process on their behalf.
  Recommend customers/resellers/integrators use a personal firewall product if computer systems obtaining or sourcing updates are connected via VPN or other high-speed connection, to secure these connections, per PCI Data Security Standard 1. References are:
11.0 Facilitate secure remote access to application
  11.2 If the payment app can be accessed remotely, verify doc contains instructions regarding secure remote access to the network, including the use of two-factor authentication. Refer to remote access.
  11.3b Internal Vendor documentation (for customer service, etc.) must provides instruction to internal teams  on all bullets of 11.3b if vendor resources gain access to customer systems using remote access.  Be sure that IG enumerates all of the referred PCI-DSS requirements (e.g. - 8.5.8-8.5.15).  Need specific wording in IG that cover all references. refer to Exceptional Customer support and remote support
  11.3b Verify vendor provides instruction in the implementation guide to customer on all bullets of 11.3b. Be sure that IG enumerates all of the referred PCI-DSS requirements (e.g. - 8.5.8-8.5.15).  Need specific wording in IG that cover all references. refer to passwords, remote access in the installation guide.
12.0 Encrypt sensitive traffic over public networks
  12.1 Use strong cryptography and encryption techniques
  Verify the vendor includes directions for customers and resellers/integrators to use secure encryption transmission technology (for example, IPSEC, VPN or TLS). All credit card service providers supported by TM use https. TM requires use of TLS 1.2 or greater and will fail the connection otherwise
  12.2 App should not send cardholder information via unencrypted messaging technologies  
If app allows or facilitates sending card data by end user messaging technology, verify the vendor recommends use of strong encryption for sending sensitive card data over a public network using any messaging technologies (e-mail IM, etc.). Theatre Manager does not do this. See Misc PCI Requirements
13.0 Encrypt all non-console administrative access
13. Use technology like SSH, or TLS for web-based management
  Verify vendor recommends use of SSH or TLS for secure non-console administrative access.  Theatre manager does not provide web management tools. Use RDC or teamviewer internally for remote access management.
14.0 Maintain instructional documentation and training programs
14.1  Disseminate instructional docs to all relevant application users
Verify the PADSS Implementation Guide covers all related requirements in the PADSS requirements The guide is 100% online and is referred to in this document. The postgres installer opens this the main install web page. Inside Theatre Manager is a 'help' function that takes people to the main online help web page and the install instructions are clearly first. All upgrades refer to the help.
Verify the PADSS Implementation Guide is reviewed and updated on an annual basis This web site is used to push RSS notifications to customers on new versions as per the main page which refers to news and updates. it is updated frequently (at least annually for each attestation for the PCI SSC) - with changes tracked by Drupal.
14.2 Develop installation training for resellers, etc.
Verify the training materials cover all items noted in the PADSS Implementation Guide There are no resellers
    Verify training materials are updated on an annual basis or when new versions of software are released