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:

Log option	Description
Event	Select what kind of event to see. For example, Administrators logged in, CA related activities, certificate related activities, End Entity related activities, activities that caused error etc.
CA	Select to view all the logs related to a specific CA.
Module	Select to view all the logs related to a specific module, for example, CA, RA, Public Web, Hard Token, Approval, Service.
Username	Select to view all the logs related to a specific username.
Certificate	Select to view all the logs related to a specific certificate. The certificate is specified by its serial number written in hexadecimal format.
Administrator Certificate	Select to view all the logs created by a specific administrator. The administrator is specified by his certificate serial number written in hexadecimal format.
Comment	Select to view all the logs created with a specific comment.
Administrator details	Select to view all the logs created by a specific type of administrator, his or her IP address or the hexadecimal serial number of the administrator certificate used. There are six types of administrators: An administrator who logs in with a certificate. Typically an administrator who logs into the Admin GUI to perform tasks that need administrator privileges. An administrator who logs in with a certificate is logged with their certificate's serial number and subject DN. An administrator who logs into the public web using only username and password. An administrator who logs into the public web is logged with their IP address. An RA user. The RA user is logged with his IP address. An administrator performing administrative tasks through command line. An administrator performing administrative tasks through batch command line. An internal user performing tasks within EJBCA.

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
Export a specific view from the Audit Log page in CA UI to a signed CMS (Cryptographic Message Syntax)

Signing Exported Log Files

The exported log file can be signed by a specific signing certificate of a certificate authority. This will generate a binary (DER) format CMS/PKCS#7 MIME Message (p7m) file.

Specific CMS compatible tools are needed to validate the signature and to 'strip' it off as to allow importing into other tools such as a text editor.

Below is an example using OpenSSL; ca.pem is the PEM format CA certificate and logexport.p7m is the file downloaded from the logging interface.

$ openssl smime -verify -nodetach -CAfile ca.pem -inform DER -in logexport.p7m -out logexport.xml
Verification successful

Audit Log Overview