WebSphere Commerce on premise not applicable for Commerce on Cloud offering

Requirement 10: Track and monitor all access to network resources and cardholder data

The detailed requirements in this section are relevant to WebSphere Commerce. Review each point carefully.

10.1 Implement audit trails to link all access to system components 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, you must enable business auditing for the orders component, by following these steps:
  1. Open the WC_eardir/xml/config/BusinessAuditDataCapture.xml file in a text editor.
  2. Search for the following XML element:
    <EventType name="ORD" enabled="false"
    eventFactory="com.ibm.commerce.event.businessaudit.eventfactory.BusinessAuditCommandExecutionAdminEventFactory">
  3. Change enabled="false" to enabled="true".
  4. Save your 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 user 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 your 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:

Configuring 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, you must monitor the BUSAUDIT table to prevent tampering with the data in the BUSAUDIT. Use one of the following methods provided by your database software provider:
  • DB2The Introduction to 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
  • OracleOracle 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.

It is recommended 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:

Enabling access logging

10.2.5 Use of and changes to identification and authentication mechanisms--including but not limited to creation of new accounts and elevation of privileges--and all changes, additions, or deletions to accounts with root or administrative privileges

WebSphere Commerce identification and authentication mechanisms use commands and thus can be recorded with business auditing.

10.2.6 Initialization, stopping, or pausing 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 all system components for each event:

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 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
Note: One example of time synchronization technology is Network Time Protocol (NTP).

10.4.1 Critical systems have the correct and consistent time.

10.4.2 Time data is protected.

10.4.3 Time settings are received from industry-accepted time sources.

Ensure that the operating system clocks on all your WebSphere Commerce servers are synchronized and protected with an industry-accepted time synchronization technology such as NTP.

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

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 secure, centralized, internal log server or media device.

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 easily write a trigger to detect this.

10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.
10.6.1 Review the following at least daily:
  • All security events
  • Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of 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.).

10.6.2 Review logs of all other system components periodically based on the organization's policies and risk management strategy, as determined by the organization's annual risk assessment.

10.6.3 Follow up exceptions and anomalies identified during the review process.

To view business audit reports, see this topic:

Viewing a business audit report

In addition to audit logs, you should be reviewing your Web server logs (consult your Web server documentation) or your WebSphere Application Server logs.

For more information on the application server logs:

Application server log files

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

Business audit trails are by default not removed from the database. Your database administrator can remove entries from this table according to your audit trail retention policy.

10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.

The merchant is responsible for documenting and communicating the security policies and operational procedures to all affected parties.