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.
- Open the WC_eardir/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"toenabled="true". - Save your changes.
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:
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.
The 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
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.
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:
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.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.
- 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:
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.