Secure > Overview: WebSphere Commerce and the PCI Data Security Standard > Address the PCI Data Security Standard within WebSphere Commerce
Requirement 10: Track and monitor all access to network resources and cardholder data
10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.All access to system components should be through individual IDs issued by a network administrator.
10.2 Implement automated audit trails for all system components to reconstruct the following events:
WebSphere Commerce business auditing records the information about the execution of business logic, such as the command, data bean, Web service, request, response, command context, and other information.
Business auditing at a level of detail appropriate to the PCI-DSS is not enabled by default.
To comply with the PCI-DSS, enable business auditing for the orders component, by following these steps:
- Open the WC_EAR/xml/config/BusinessAuditDataCapture.xml file in a text editor.
- Search for the following XML element:
<EventType name="ORD" enabled="false" eventFactory="com.ibm.commerce.event.businessaudit.eventfactory.BusinessAuditCommandExecutionAdminEventFactory">
- Change enabled="false" to enabled="true".
- Save the changes.
Remember: Back up the BUSAUDIT table before starting up server to ensure the audit trail is archived.
For more information about business auditing see the following topics:
10.2.1 All individual accesses to cardholder data
After you have enabled the WebSphere Commerce system for business auditing, the system is set to audit a large set of commands, including all commands that access cardholder data.
You can further customize which commands you want audited (such as the own custom commands) by configuring the BusinessAuditDataCapture.xml file, which determines what commands should be audited and what parameters need to be captured during an audit. You can enable commands that are disabled, add new commands, or remove existing ones.
To configure business auditing:
Configure event types and commands for business auditing
10.2.2 All actions taken by any individual with root or administrative privileges
When you view the business audit report, you can filter the report by LogonID, thus enabling you to see all events (that are being audited) for a particular user.
10.2.3 Access to all audit trails
If you modify a parameter in the audit trail, it is detectable – the BUSAUDIT.SIGNATURE column (which is a hash of the parameters) will not match the parameters.
Additionally, monitor the BUSAUDIT table to prevent tampering with the data in the BUSAUDIT. Use one of the following methods provided by the database software provider:
- The DB2 audit facility.
To audit the BUSAUDIT table, run the following DB2 statements:
CREATE AUDIT POLICY SENSITIVEDATAPOLICY CATEGORIES EXECUTE STATUS BOTH ERROR TYPE AUDIT COMMIT AUDIT TABLE BUSAUDIT USING POLICY SENSITIVEDATAPOLICY COMMIT
- Oracle auditing.
To audit the BUSAUDIT table, run the following Oracle statements:
AUDIT SELECT, INSERT, DELETE ON BUSAUDIT BY ACCESS WHENEVER SUCCESSFUL
10.2.4 Invalid logical access attempts
Invalid logical access attempts can be logged by turning on access logging.
IBM recommends that you set the logAllRequests value to "false" for performance reasons. This will ensure that only requests resulting in access violations are logged.
To enable access logging:
10.2.5 Use of identification and authentication mechanisms
WebSphere Commerce identification and authentication mechanisms use commands and thus can be recorded with business auditing.
10.2.6 Initialization of the audit logs
WebSphere Commerce does not initialize the audit logs. This can be done only by a database administrator. Refer to the statements in 10.2.3 for details on audit log initialization.
10.2.7 Creation and deletion of system-level objects.
All creation and deletion of business objects is performed through commands, and thus recorded in business auditing.
10.3 Record at least the following audit trail entries for each event, for all system components:
The business audit feature records the audit train entries as described in the following subsections.
10.3.1 User identification
LogonID is recorded.
10.3.2 Type of event
Event Type is recorded. It is configurable by mapping it to a set of commands that are called.
10.3.3 Date and time
Date and time are recorded.
10.3.4 Success or failure indication
The value of the BUSAUDIT.OCCURENCE field indicates whether it is a successful exit or an exception. Every command has two audit records, one for attempt and the other for result. The column has a value to indicate an exception. The possible OCCURENCE values are:
EXIT = 0;
EXCEPTION = 1;
ENTRY = 2;
EXECUTION = 3;
10.3.5 Origination of event
The command class name is recorded.
10.3.6 Identity or name of affected data, system component, or resource.
The event type can be configured to capture specific data (for example, OrderID). Additionally, the parameters of the command are recorded.
10.4 Synchronize all critical system clocks and times.
Verify the operating system clocks on all the WebSphere Commerce servers are synchronized.
10.5 Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a job-related need
Audit trails are secured in the WebSphere Commerce database, and are authenticated – whether accessed via the database directly, or through the WebSphere Commerce Accelerator.
10.5.2 Protect audit trail files from unauthorized modifications
Audit trails are protected, because they are stored in the WebSphere Commerce database.
Furthermore, if you modify a parameter in the audit trail, it is detectable; the signature will not match the parameters.
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter
Your database administrator should already be performing regular database backups.
10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.
The choice of wired or wireless networks is immaterial to WebSphere Commerce.
10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).
Whenever the logs are tampered with (as determined by the SIGNATURE field) an error is generated if the signature does not match the parameters in the SystemOut.log.
Depending on the database server you are using, you can also set up custom events with an activity monitor to alert you to any access to the BUSAUDIT table. The business audit feature performs only database INSERT statements. So any UPDATE after INSERT would be evidence of tampering, and any database administrator can write a trigger to detect this.
10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).
Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6
To view business audit reports, see this topic:
In addition to audit logs, you should be reviewing the Web server logs (consult the Web server documentation) or the WebSphere Application Server logs.
For more information on the application server logs:
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).
Business audit trails are by default not removed from the database. Your database administrator can remove entries from this table according to the audit trail retention policy.
Previous topic: Requirement 9: Restrict physical access to cardholder data
Next topic: Requirement 11: Regularly test security systems and processes