Logging🔗
Logging is controlled by several configuration keys. The configuration is stored at /etc/cryptosense-analyzer/config on each AQtive Guard VM.
For more configuration information, refer to the Configuration Key reference.
Important
It is strongly recommended to use identical configuration settings for all AQtive Guard machines in a high-availability setting.
Logging Configuration Keys🔗
| Key | Required? | Description |
|---|---|---|
| LOG_LEVEL | Yes | Minimal level of logs appearing in the output. Possible values: debug, info, warning, error, critical |
| LOG_FILE | No | If present, write logs to a file instead of journalctl. |
| LOG_ROTATE_DAILY | No | Requires LOG_FILE to be set. If set ‘true’, a new log file is created every day. Defaults to ‘false’. |
| LOG_ROTATE_MAX | No | Requires LOG_ROTATE_DAILY. Sets the maximum amount of log files that are kept. Old files are automatically deleted. |
| LOG_LEVEL_AUDIT | No | Defaults to “info”. Minimal level of audit logs. |
| LOG_FILE_AUDIT | No | If present, write audit logs to a file instead of journalctl. |
| LOG_ROTATE_DAILY_AUDIT | No | Requires LOG_FILE_AUDIT. Enables log rotation for audit logs. |
| LOG_ROTATE_MAX_AUDIT | No | Requires LOG_ROTATE_DAILY_AUDIT. Sets the maximum amount of audit log files. |
Logging output🔗
Every VM running AQtive Guard generates its own logs and they are not transferred to another machine or centralized.
By default, logs are written to journalctl, but an option can be enabled to write them to
a file instead.
- This option can be enabled separately for the different types of logs produced.
- The log level can be controlled separately for every type of log.
- Make these configurations using the configuration file on every VM.
All logs contain the fields and data specified in the following sections.
Structured logs schema🔗
Audit logs are structured into JSON objects. They are serialized into strings and logged in journalctl or the specified files.
The structure of the logs is a flat key-value object. The specific keys and their content depend on the type of log.
All logs have a baseline of required fields:
| Field | Description |
|---|---|
| id | Unique ID, generated using UUIDv4 |
| created_at | UTC timestamp |
| hostname | Hostname of the machine |
| level | From lowest to highest, debug, info, warning, error or critical |
| log_type | audit, web, application, analysis or tanium |
| pid | PID of the process generating the log |
In addition, all logs may have additional fields:
| Field | Description |
|---|---|
| request_id | Unique ID, generated using UUIDv4, of the incoming request. Several logs may share this value |
| user_id | User ID of the logged-in user |
| user_name | Username of the logged-in user |
| stacktrace | Formatted stack trace of the exception(s) encountered |
Audit logs🔗
Login attempts🔗
| Field | Description |
|---|---|
| action | “login_attempt” |
| access_granted | True if the login attempt was successful. |
| client_ip | IP address of client sending login request. |
| forwarded_for_client_ip | Original client IP address if behind proxy. |
User activity🔗
| Field | Description |
|---|---|
| action | “access”, “create”, “update”, “remove”, “export_jira” |
| access_granted | True if the action was allowed. |
| access_denied_reason | If the action was not allowed, contains the explanation. |
| element | The type of element that is being acted upon. |
| element_id | The ID of the element that is being acted upon. |
| client_ip | IP address of client sending action request. |
| forwarded_for_client_ip | Original client IP address if behind proxy. |
Setting changes🔗
| Field | Description |
|---|---|
| action | “setting_change” |
| access_granted | True if the change was allowed. |
| setting | The name of the setting that is being changed. |
| old_value | Value before the change. |
| new_value | Requested new value. |
| access_denied_reason | If the action was not allowed, contains the explanation. |
| element_id | Additional ID if applicable to the specific setting. |
| client_ip | IP address of client sending setting change request. |
| forwarded_for_client_ip | Original client IP address if behind proxy. |
API Request🔗
| Field | Description |
|---|---|
| action | “api_request” |
| access_granted | True if the request was allowed. |
| access_denied_reason | If the action was not allowed, contains the explanation. |
| api_key | Present only if the API key was invalid. |
| client_ip | IP address of client sending api request. |
| forwarded_for_client_ip | Original client IP address if behind proxy. |
Web Logs🔗
Web Activity🔗
| Field | Description |
|---|---|
| method | Method of the query |
| path | URL that was queried |
| status_code | HTTP return code |
Analysis Logs🔗
| Field | Description |
|---|---|
| memory_mb | Memory usage of the analyzer process, in MB |
| module | Internal |
| message | Logged message |
Application Logs🔗
This is a generic log for uncategorized messages.
| Field | Description |
|---|---|
| message | Logged message |
Tanium Logs🔗
Operations of the Tanium integration generate a dedicated type of logs.
| Field | Description |
|---|---|
| computer_group | (optional) The ComputerGroup targeted by the operation. |
| endpoint_id | (optional) The Endpoint ID targeted by the operation. |
| message | Logged message |
Tanium API Requests🔗
API requests made to the Tanium server generate logs with the general Tanium fields, and the following additional fields:
| Field | Description |
|---|---|
| target | Tanium Server that the request is sent to. |
| path | URL that is being requested. |
| status_code | (optional) HTTP response code of the request. |
| error | (optional) Error description if no response is received. |