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.
- 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.
When viewing the audit log, you can choose which log rows to see by selecting the following options:
|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.|
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.|
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:
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