Audit Log Overview

The Security Audit Log specifies in detail what it logs, and does not log any other events. Examples of important events logged by the Security Audit Log are: "Certificate issued", "Certificate Profile edited", "Administrator accessed resource".

One of the most important aspects to consider is that the Security Audit Log does not log things that do not happen, for example invalid requests that the system rejects or downloading a CRL, because the PKI system did not perform any important auditable event.

The main purpose of the Security Audit Log is to provide information to an auditor, and the auditor wants to know what the system has done, what certificates were issued etc, but is not interested in what the system did not do. The Security Audit Log is designed to fulfill audit logging requirements for Common Criteria certification (Certificate Issuing and Management Components Protection Profile), as well as ETSI/CWA and WebTrust audits.

Services, Modules, Events and Status 

The security audit events are divided into Services, Modules, Events according to from where it originates. The full list of the different Service, Module and Event types and a short explanation for each type can be found in JavaDoc format of the API. Since EJBCA is built around the CESeCore project, to see all possible event types that EJBCA can generate both EventTypes and EjbcaEventTypes in the API doc needs to be considered.

An example of how such an event would look like in the server log using the Log4jDevice is the event that the application is starting:

... INFO  [Log4jDevice] 2015-03-20 12:47:51+01:00;EJBCA_STARTING;SUCCESS;SERVICE;EJBCA;StartServicesServlet.init;;hostname;;msg=Init, EJBCA 6.3.1Alpha (working copy) startup.

and the same kind of event using IntegrityProtectedDevice that writes the log entry to the database:

mysql> select * from AuditRecordData where eventType='EJBCA_STARTING' ... \G
               pk: 24861ebf7f00010106e5a024d82c694d
additionalDetails: ...  Init, EJBCA 6.3.1Alpha (working copy) startup.  ...
        authToken: StartServicesServlet.init
         customId: NULL
      eventStatus: SUCCESS
        eventType: EJBCA_STARTING
           module: SERVICE
           nodeId: hostname
    rowProtection: 1:2:123:4d2f6...
       rowVersion: 0
    searchDetail1: hostname
    searchDetail2: NULL
   sequenceNumber: 17640195
          service: EJBCA
        timeStamp: 1426205614754

This should be interpreted as the following:

• Service is EJBCA (not shown in the Admin GUI): The event originates from the part of the application that not part of the core shared with other projects.
• Module is SERVICE: This event was generated from a module in EJBCA that is responsible for background services.
• Event is EJBCA_STARTING: The application EJBCA is starting up.
• Status (named Outcome in the Admin GUI) is SUCCESS: In the context of the event, this should be interpreted as no error were detected during the EJBCA startup.
• Additionally there is an event specific message with additional information telling us (in this case) the version of EJBCA that was started.

Also note that the time in the log entry itself is the time of the event and might differ from the time when this was written to the server log.

Other references:

• Security information about the Database Integrity Protection. For more information, see EJBCA Security.
• Local Database CLI to verify protection and export/import data.
• For information about the security features and possibilities to repair gaps, see EJBCA Security.

Log Fields

When viewing the audit log, you can choose which log rows to see by selecting the following options:

The log can be displayed on the screen or be exported as an XML file

Security Audit Events

The security audit events are divided into Columns, Services, Modules, Status, and Events according to from where it originates. For more information, see Security Audit Events.

Integrity Protecting the Audit Log

The rows of the audit log can be individually signed in order to make sure that an intruder with database access can't edit or remove rows to hide signs of wrongdoing. For more information, see Integrity Protected Security Audit Log.

Exporting Audit Logs

All installations have their specific requirements for how audit logs should be handled. There are a number of ways to Export Audit Logs:

• Rotate system log files (including the audit log) and archive/process the rotated log files
• Use a SYSLOG appended to send the System log (including the Audit log) to a central log server that performs monitoring functions
• Export the database audit log using the Local Database CLI
• Export the database audit log using database tools
• Export a specific view from the Audit Log page in CA UI to an XML file