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