Implementing Auditing

This topic contains recommendations for implementing auditing in a Siebel Business Applications deployment so that suspicious activities are detected. It contains the following topics:

• "Operating System Auditing"

• "Database Auditing"

• "Siebel Business Applications Event Logging"

• "About Siebel Audit Trail"

Operating System Auditing

Implement the following operating system auditing recommendations:

• Use platform-level auditing to audit login and logout events, access to the file system, and failed object access attempts.

• Back up log files and regularly analyze them for signs of suspicious activity.

• Secure log files by using restricted access control lists, and relocate system log files away from their default locations to make sure attackers cannot cover their tracks.

For more information on operating system auditing, see your operating system documentation.

Database Auditing

Implement the following database auditing recommendations:

• Enable Siebel Audit Trail to audit access to specific data fields or objects in the Siebel database. Enabling Siebel Audit Trail produces a log file of all the events that have occurred, which allows the Siebel database administrator to review the events and detect any suspicious activities. For further information, see "About Siebel Audit Trail".

• You can also implement database auditing that is included with all supported databases. All vendors support high levels of audits: B3 or C2 Orange book levels. Database auditing requires a security person to review the audit information.

For more information on configuring database auditing, see your database vendor documentation.

Siebel Business Applications Event Logging

Configure event logging for the Siebel Server and server components to monitor the internal operation of Siebel Business Applications. You can specify the type and extent of the information logged for a specific Siebel Server or component event by choosing a log level for the event, for example, you can choose to only log error messages or to log detailed information relating to an event.

Table C-3 shows Siebel Server and component event log levels. The log level determines the amount of information that is written to the log file and the severity of the event logged. For example, if you set the log level to a low number, then only information relating to the most severe events is logged. If you set the log level to a high number, then less severe events are also logged and more information is written to the log for each event.

Table C-3 Event Log Levels

Event Log Level	Description
0	Fatal events are logged.
1	Error messages and fatal events are logged.
2	Warning messages are logged in addition to error messages and fatal events.
3	Informational messages are written to the log files in addition to all the messages logged for log levels 0-2.
4	Detailed information is written to the log files for all items logged for log levels 1-3.
5	Diagnostic information is written to the log files as well as all the information logged for log levels 1-4.

Implement the following recommendations when configuring event logging:

• Verify that Siebel Business Applications do not log excessive or sensitive information by default, for example, session IDs.

• In a production environment, do not set event log levels for Siebel Server components to verbose levels; the recommended log levels are 2 (Warnings) or 3 (Informational). Do not log sensitive information at the maximum logging settings.

Event logging is configured using the Siebel Administration - Server Configuration screens or the srvrmgr command-line interface. For detailed information on setting event logging for Siebel Server and server component events, see Siebel System Monitoring and Diagnostics Guide.

About Siebel Audit Trail

Siebel Audit Trail creates a history of the changes that have been made to data in Siebel Business Applications. Audit Trail functionality is enabled in Siebel Business Applications by default.

Siebel Business Applications support various degrees of auditing:

• At the simplest level, each data record contains the following fields, which store the date and time of each change made to the record, and values identifying the user who made the change:

  • CREATED

  • CREATED_BY

  • LAST_UPD

  • LAST_UPD_BY

  With additional configuration, you can generate an activity for additional levels of auditing. This configuration is best used when there are limited needs for auditing, for example, just a few areas to track.

  
  

  Note: If Siebel Enterprise Application Integration (EAI) implements anonymous logins, then Siebel Audit Trail cannot relate a change to the specific user who made the change.

  
  

• Siebel Business Applications can maintain an audit trail of information that tells when business component fields have been changed, who made the change, and the value of the field before and after the change. It is also possible to maintain an audit trail of when the business component fields have been viewed or exported and who viewed or exported the fields.

  You can also configure Siebel Audit Trail to determine the scope of the audit. You can choose to audit all activity, or to limit the scope of auditing to those operations performed by certain responsibilities, positions, or employees.

• Using Siebel Workflow, you can configure workflow processes to save information on changes to specific business components.

• You can also attach scripts to the business component Write_Record event and save information about the transaction.

Note: Be aware that enabling high levels of auditing, for example, log level 5, can have an adverse impact on performance.

Restrict access to the audit records, and archive and delete audit records regularly. For information on configuring and using Siebel Audit Trail, see Siebel Applications Administration Guide.