# Introduction to Audit Logs

The Audit Log is a specialized dataset within Log Management that records key operations performed within the Radiant platform. Unlike standard security alerts which track external threats, Audit Logs focus on internal activity, tracking who took action, what they changed, and when it happened.

{% hint style="info" %}
**Feature Note:** The Audit Log is an evolving capability. We are continuously expanding coverage to include more areas of the platform. Currently, the logs primarily capture Response Actions and specific system events, with additional event types (such as configuration changes and administrative activities) rolling out in upcoming updates.
{% endhint %}

This log source is designed to help users:

* Maintain a history of platform activity and track changes to configurations for security and compliance purposes.
* Verify if an automated command succeeded or failed.
* Audit analyst activity and case handling.

### Access Audit Logs

To switch from viewing standard security events to viewing the Audit Log:

1. Navigate to **Log Management** in the main menu.
2. Use the time range picker in the top-right toolbar to define your search window (e.g., *Last 24 Hours*).
3. Locate the view selector button (small list icon) immediately to the right of the time picker.
4. Select **Audit logs** from the dropdown menu.

<div align="left"><figure><img src="https://2439665791-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPsFulb2ZOtSPcRSc2rXE%2Fuploads%2F3zwoRNPand0oWVk9Je7b%2FAudit_Response_Actions_02.png?alt=media&#x26;token=4a8b9b0f-b4d6-4e79-bdf8-5193140cd9ec" alt="" width="296"><figcaption></figcaption></figure></div>

5. Click the **Run** button to view the audit activity.

### Audit Log Structure

Audit logs use a standardized schema to describe events, regardless of the action type. When reviewing these logs in the **Extracted Fields** sidebar, pay attention to these core fields:

<table><thead><tr><th width="227.923095703125">Field</th><th>Description</th></tr></thead><tbody><tr><td>action</td><td>The technical name of the remediation action executed (e.g., <code>enable_user</code>).</td></tr><tr><td>changedFrom</td><td>The state of the action <em>before</em> this specific log entry (e.g., <code>{"status":"pending"}</code>).</td></tr><tr><td>changedTo</td><td>The new state of the action recorded in this entry (e.g., <code>{"status":"inprogress"}</code>).</td></tr><tr><td>eventTimestamp</td><td>The Unix timestamp representing when the action actually occurred in the system.</td></tr><tr><td>logEntryTimestamp</td><td>The Unix timestamp representing when this specific log entry was created.</td></tr><tr><td>message</td><td>A human-readable summary describing the event, including the actor and the target (e.g., <em>"</em><code>John Doe</code> executed <code>Enable user</code> on...<em>"</em>).</td></tr><tr><td>rs_connectorType</td><td>The internal connector type used for logging (typically <code>rs_audit_logs</code>).</td></tr><tr><td>rs_fp</td><td>An internal fingerprint hash used for log integrity and deduplication.</td></tr><tr><td>rs_indexed</td><td>The timestamp when the log was indexed by the Radiant platform.</td></tr><tr><td>rs_received</td><td>The timestamp when the Radiant platform received the log data.</td></tr><tr><td>rs_timestamp</td><td>The primary timestamp used for sorting events in the timeline.</td></tr><tr><td>target</td><td>The specific identifier of the artifact being acted upon (e.g., <code>jdoe@jdoe@acmecorporation.com</code>).</td></tr><tr><td>targetType</td><td>The type of identifier used in the <code>target</code> field (e.g., <code>user_principal_name</code>, <code>ip_address</code>).</td></tr><tr><td>userEmail</td><td>The email address or name of the actor who initiated the action (e.g., <code>analyst@company.com</code> or <code>Radiant Security Platform</code>).</td></tr><tr><td>userID</td><td>The unique ID of the actor who initiated the action.</td></tr></tbody></table>

### What's Currently Logged

The Audit Log currently captures the following types of platform activity:

#### Account Notifications

Track changes to user notification preferences and alert settings.

{% tabs %}
{% tab title="Target Type" %}
Account Notifications
{% endtab %}

{% tab title="Common Use Cases" %}

* Verify notification delivery issues.
* Audit analyst alert preferences.
* Compliance documentation.
  {% endtab %}
  {% endtabs %}

<table><thead><tr><th width="204.23211669921875">Audited Actions</th><th>Description</th><th>What to Look For</th></tr></thead><tbody><tr><td>Enable/Disable</td><td>Activates or deactivates notification types (New Alert, Incident Assigned, Investigation Complete, Tagged in Comment, Weekly Report)</td><td>Users complaining about missing alerts may have disabled notifications</td></tr><tr><td>Modify Status Triggers</td><td>Changes alert status conditions that trigger notifications</td><td>Altered thresholds could explain why certain alerts aren't being sent</td></tr><tr><td>Modify Vendor Triggers</td><td>Updates vendor inclusion list for alert notifications</td><td>Verify analysts are notified about alerts from newly integrated tools</td></tr><tr><td>Modify Frequency</td><td>Adjusts notification frequency settings (e.g., <em>weekly</em> versus <em>monthly</em>)</td><td>Identify if reports stopped arriving due to frequency changes</td></tr></tbody></table>

#### Phishing Domains

Monitor domain management for phishing triage.

{% tabs %}
{% tab title="Target Type" %}
Domain
{% endtab %}

{% tab title="Common Use Cases" %}

* Troubleshoot missing phishing alerts
* Verify protected domains
* Audit domain coverage
  {% endtab %}
  {% endtabs %}

| Audited Action | Description                                               | What to Look For                                                                                |
| -------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Enable/Disable | Activates or deactivates monitoring for a specific domain | Disabled domains won't generate phishing alerts; check if recently acquired domains are enabled |

#### Automatic Closure of Cases

Track configuration of automated case closure policies.

{% tabs %}
{% tab title="Target Type" %}
Automatic closure of incidents
{% endtab %}

{% tab title="Common Use Cases" %}

* Investigate unexpected case closures
* Audit retention policies
* Troubleshoot workflow issues
  {% endtab %}
  {% endtabs %}

| Audited Actions  | Description                                            | What to Look For                                                                                               |
| ---------------- | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| Enable/Disable   | Activates or deactivates automatic case closure        | If cases are closing prematurely, verify this hasn't been enabled by mistake.                                  |
| Modify Frequency | Changes the time range for automatic closure (in days) | Shortened timeframes may close active investigations; review recent changes if cases are closing unexpectedly. |

#### Integration Credentials

Audit credential and integration management activities.

{% hint style="info" %}
**Note:** Integration configurations are redacted in audit logs for security.
{% endhint %}

{% tabs %}
{% tab title="Target Type" %}
Credential
{% endtab %}

{% tab title="Common Use Cases" %}

* Troubleshoot integration failures
* Investigate security incidents involving access changes
* Audit privileged access
  {% endtab %}
  {% endtabs %}

| Audited Actions | Description                                                  | What to Look For                                                                             |
| --------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| Create          | New credential added to the system                           | Correlate with new integration setup; verify authorization for credential creation           |
| Modify          | Existing credential updated (sensitive data masked with `*`) | Integration failures shortly after a modify event suggest incorrect credentials were entered |

{% hint style="info" %}
**Troubleshooting Tip:** If an integration stops working, search for recent `modify` events on the credential and verify the change was intentional.
{% endhint %}

#### Data Connectors

Track data connector lifecycle and status changes.

{% tabs %}
{% tab title="Target Type" %}
Data Connector
{% endtab %}

{% tab title="Common Use Cases" %}

* Diagnose missing logs
* Audit data source coverage
* Investigate compliance gaps
  {% endtab %}
  {% endtabs %}

| Audited Actions | Description                                        | What to Look For                                                                               |
| --------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Create          | New data connector configured                      | Verify expected data sources are sending logs after creation                                   |
| Enable/Disable  | Activates or stops data ingestion from a connector | Sudden drops in log volume often correlate with disable events; check for unauthorized changes |

{% hint style="info" %}
**Troubleshooting Tip:** If logs from a specific source disappear, run this search in the Log Manager Audit Log index to see if someone accidentally turned it off: `targetType:"Data Connector" AND action:"disable"`
{% endhint %}

#### Allow Lists

Monitor trusted entity management across multiple categories.

{% tabs %}
{% tab title="Target Type" %}
Allow List
{% endtab %}

{% tab title="Common Use Cases" %}

* Investigate false negatives (threats bypassing detection)
* Audit trust boundaries
* Detect unauthorized allowlist additions
  {% endtab %}
  {% endtabs %}

<table><thead><tr><th width="132.92120361328125">List Type</th><th width="138.9071044921875">Audited Actions</th><th width="293.99462890625">Target Type</th><th width="221.758544921875">Example</th><th width="157.078857421875">Security Impact</th></tr></thead><tbody><tr><td><strong>Trusted Domains</strong></td><td>Create, Delete</td><td><code>Allow List: Trusted Domain</code></td><td><code>www.acme.corp.com</code></td><td>Emails/traffic from trusted domains bypass phishing detection</td></tr><tr><td><strong>Trusted IPs</strong></td><td>Create, Delete</td><td><code>Allow List: Trusted IP</code></td><td><code>1.1.1.1</code></td><td>Network connections from trusted IPs may skip threat analysis</td></tr><tr><td><strong>Trusted Senders</strong></td><td>Create, Delete</td><td><code>Allow List: Trusted Sender</code></td><td><code>jdoe@acmecorp.com</code></td><td>Emails from trusted senders bypass email security checks</td></tr><tr><td><strong>Shared Accounts</strong></td><td>Create, Delete</td><td><code>Allow List: Shared Account</code></td><td><code>it@acmecorp.com</code></td><td>Shared account activity won't trigger impossible travel alerts</td></tr><tr><td><strong>Public Object Storage</strong></td><td>Create, Delete</td><td><code>Allow List: Public Object Storage</code></td><td><code>radiantsecurityS3bucket</code></td><td>Access to whitelisted storage won't escalate data exfiltration alerts</td></tr><tr><td><strong>Trusted Applications</strong></td><td>Create, Delete</td><td><code>Allow List: Trusted Application</code></td><td><code>salesforce</code></td><td>OAuth grants to trusted apps bypass suspicious app alerts</td></tr></tbody></table>

{% hint style="info" %}
**Security Alert:** Regularly review `create` actions on allow lists. Attackers who compromise admin accounts often add malicious infrastructure to allowlists to evade detection.
{% endhint %}

#### Deny Lists

Track blocked entities for security enforcement.

{% tabs %}
{% tab title="Target Type" %}
Deny List
{% endtab %}

{% tab title="Common Use Cases" %}

* Verify threat intelligence updates
* Audit block effectiveness
* Document threat mitigation for compliance
  {% endtab %}
  {% endtabs %}

<table><thead><tr><th>List Type</th><th>Audited Actions</th><th width="257.5821533203125">Target Type</th><th width="189.00927734375">Example</th><th width="171.276611328125">Enforcement Impact</th></tr></thead><tbody><tr><td><strong>Malicious Domains</strong></td><td>Create, Delete</td><td><code>Deny List: Malicious Domain</code></td><td><code>malware.com</code></td><td>Blocks access to malicious sites at DNS/proxy level</td></tr><tr><td><strong>Malicious IPs</strong></td><td>Create, Delete</td><td><code>Deny List: Malicious IP</code></td><td><code>1.1.1.1</code></td><td>Blocks network connections to/from malicious IPs at firewall</td></tr><tr><td><strong>Malicious Senders</strong></td><td>Create, Delete</td><td><code>Deny List: Malicious Sender</code></td><td><code>malicious@test.com</code></td><td>Automatically quarantines emails from known malicious senders</td></tr></tbody></table>

{% hint style="info" %}
**Best Practice:** Cross-reference deny list additions with threat intelligence feeds to measure coverage of known threat actors.
{% endhint %}

#### VIP Users

Manage high-priority user designations for enhanced monitoring.

{% tabs %}
{% tab title="Target Type" %}
VIP User
{% endtab %}

{% tab title="Common Use Cases" %}

* Audit executive protection coverage
* Verify VIP monitoring
* Compliance reporting for high-value targets
  {% endtab %}
  {% endtabs %}

| Audited Actions | Description              | What to Look For                                                                                        |
| --------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- |
| Create          | Designates a user as VIP | Verify newly hired executives are promptly added; VIP users get enhanced monitoring and faster response |
| Delete          | Removes VIP designation  | Confirm deletions correspond to role changes or departures; former VIPs revert to standard monitoring   |

#### Alert Filtering Rules

Track default rule filter configurations for data processing.

{% tabs %}
{% tab title="Target Type" %}
Default Rule Filter
{% endtab %}

{% tab title="Common Use Cases" %}

* Troubleshoot missing alerts
* Audit detection coverage
* Diagnose over-filtering
  {% endtab %}
  {% endtabs %}

| Audited Actions | Description                            | What to Look For                                                                                  |
| --------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Create          | New filter rule defined                | Verify new filters don't inadvertently suppress legitimate alerts                                 |
| Enable/Disable  | Activates or deactivates a filter rule | Sudden increase in alert volume may indicate a filter was disabled                                |
| Modify          | Updates filter query or conditions     | Changed filter logic could explain gaps in detection; review `changedFrom` and `changedTo` fields |

{% hint style="info" %}
**Troubleshooting Tip:** If expected alerts aren't appearing, check for recently created or modified filters that may be excluding them.
{% endhint %}

#### Outgoing Webhooks

Monitor webhook configurations for external integrations.

{% hint style="info" %}
**Note:** Webhook URLs are encrypted in audit logs for security.
{% endhint %}

{% tabs %}
{% tab title="Target Type" %}
Outgoing Webhook
{% endtab %}

{% tab title="Common Use Cases" %}

* Troubleshoot missing notifications in external systems
  {% endtab %}
  {% endtabs %}

| Audited Actions | Description                                | What to Look For                                                                    |
| --------------- | ------------------------------------------ | ----------------------------------------------------------------------------------- |
| Create          | New webhook endpoint configured            | Verify successful delivery to external system after creation                        |
| Enable/Disable  | Activates or stops webhook notifications   | Ticketing system not receiving updates? Check if webhook was disabled               |
| Modify          | Updates webhook URL, triggers, or settings | Integration breaks often follow modify events with incorrect URLs or authentication |

{% hint style="info" %}
**Troubleshooting Tip:** If a webhook integration suddenly stops working, filter by the webhook `target` (name) and look for recent `modify` or `disable` events.&#x20;

Example query: `target:"Microsoft linkback" AND action: "Disable"`
{% endhint %}

#### Alert Verdicts

Track alert status changes and outcomes throughout the investigation lifecycle.

{% tabs %}
{% tab title="Target Type" %}
Alert Verdict
{% endtab %}

{% tab title="Target Format" %}
Alert UUID
{% endtab %}

{% tab title="Common Use Cases" %}

* Audit investigation outcomes
* Measure analyst performance
* Compliance reporting on incident handling
  {% endtab %}
  {% endtabs %}

| Audited Action | Description                                                        | What to Look For                                                                           |
| -------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| Create         | Initial verdict assigned to an alert                               | Track time from alert creation to first triage action (MTTI - Mean Time to Investigate)    |
| Modify         | Verdict updated (e.g., from "investigating" to "confirmed threat") | Measure investigation progression; frequent verdict changes may indicate unclear playbooks |

#### Response Actions

All remediation actions executed through the platform across integrated security tools.

{% tabs %}
{% tab title="Target Type" %}
Varies by action (e.g., `user_principal_name`, `email_address`, `hostname`, `ip_address`, `file_hash`)
{% endtab %}

{% tab title="Common Use Cases" %}

* Verify containment actions
* Troubleshoot failed remediations
* Audit response effectiveness
* Incident timeline reconstruction
  {% endtab %}
  {% endtabs %}

{% hint style="info" %}
**Note:** Response action logs capture the full lifecycle: `in progress` → `completed`/`failed`. Use the `changedTo` field to filter by status.
{% endhint %}

<table><thead><tr><th>Category</th><th>Audited Actions</th><th width="236.55908203125">Example Targets</th><th>When to Review</th></tr></thead><tbody><tr><td><strong>User Accounts</strong></td><td>Enable/Disable User, Reset Password, Revoke Session, Force MFA Re-enrollment</td><td><code>jdoe@acmecorp.com</code></td><td>Compromised account investigations, insider threat cases, offboarding audits</td></tr><tr><td><strong>Email Security</strong></td><td>Delete Email, Quarantine Email, Release from Quarantine</td><td><code>&#x3C;message-id@acmecorp.com></code></td><td>Phishing campaigns, malware distribution, accidental data leaks</td></tr><tr><td><strong>Endpoint Protection</strong></td><td>Isolate/Unisolate Endpoint, Kill Process, Delete File, Collect Forensic Artifacts</td><td><code>DESKTOP-12345</code>, <code>malware.exe</code></td><td>Malware infections, ransomware incidents, forensic investigations</td></tr><tr><td><strong>Network Security</strong></td><td>Block IP, Block URL/Domain, Allow IP, Allow URL/Domain</td><td><code>192.168.1.100</code>, <code>malicious.com</code></td><td>C2 communication blocking, lateral movement prevention, threat containment</td></tr></tbody></table>

#### Alert Notes

Track note deletions on alerts to maintain an audit trail of removed investigative context.

{% tabs %}
{% tab title="Target Type" %}
Alert note
{% endtab %}

{% tab title="Target Format" %}
Alert ID
{% endtab %}

{% tab title="Common Use Cases" %}

* Audit removed investigation notes for compliance.
* Verify whether critical context was deleted before a verdict change.
* Investigate potential evidence tampering during incident review.
  {% endtab %}
  {% endtabs %}

{% hint style="info" %}
**Note:** When a note is deleted, the `changedFrom` field captures the full note content and note ID. The `changedTo` field is set to `{}`, following the standard deletion pattern. Use this to recover deleted note content during audits or investigations.
{% endhint %}

<table><thead><tr><th>Audited Action</th><th width="236.55908203125">Description</th><th>What to Look For</th></tr></thead><tbody><tr><td>Create</td><td>A note is added to an alert. The <code>changedTo</code> field captures the full note content and note ID.</td><td>Verify that investigation notes are being documented consistently. System-generated notes show <code>userEmail: "Radiant Security Platform"</code>.</td></tr><tr><td>Delete</td><td>A note is removed from an alert. The <code>changedFrom</code> field preserves the full content of the deleted note.</td><td>Deleted notes before verdict changes may indicate an attempt to remove investigative context. Review <code>changedFrom</code> to recover the original note content. |</td></tr></tbody></table>

### **Key Fields for Response Actions**

* **changedFrom/changedTo:** Track action progression (e.g., `{"status":"pending"}` → `{"status":"completed"}`)
* **userEmail:** Distinguish manual actions (analyst email) from automated playbooks (`Radiant Security Platform`)
* **message:** Human-readable summary with full context of what was done and to what target

### Special Considerations

* Automated platform actions show `userEmail: "Radiant Security Platform"`
* Credentials and webhook URLs are masked/encrypted for security
* All timestamps in Unix epoch format (seconds)
* Empty `{}` in `changedFrom` = creation; empty `{}` in `changedTo` = deletion

### Practical Use Cases

Here are real-world scenarios where Audit Logs provide immediate value to security and compliance teams:

#### Detect Unauthorized Security Control Disablement

**Scenario**: A data connector suddenly stops sending logs to your platform, or critical security alerts stop appearing. You suspect someone may have disabled security controls, either accidentally or maliciously.

**How to use Audit Logs**:

* Search for `action:"Disable"` across critical security components (data connectors, filter rules)
* Exclude automated platform actions to focus on human-initiated changes
* Review the `userEmail` field to identify who disabled the control
* Check the `eventTimestamp` to see if the action occurred during suspicious hours (nights, weekends)
* Investigate whether the user had authorization to make such changes

**Example Query**:

```jsx
action:"Disable" AND (
  targetType:"Data Connector" OR
  targetType:"Default Rule Filter"
) AND NOT userEmail:"Radiant Security Platform"
```

#### Compliance and Audit Reporting

**Scenario**: Your organization undergoes a SOC 2 or ISO 27001 audit, and auditors request evidence of who performed specific remediation actions during a security incident.

**How to use Audit Logs**:

* Filter by date range covering the incident timeline
* Search for specific actions like `disable_user` or `isolate_endpoint`
* Examine logs showing the `userEmail`, `action`, `target`, and `eventTimestamp` fields
* Demonstrate clear attribution and timeline of remediation steps

**Example Query**:

```jsx
action:"disable_user" AND eventTimestamp:[2024-01-15 TO 2024-01-17]
```

#### Troubleshooting Failed Response Actions

**Scenario**: A user ran a single-click action to **find & soft delete** malicious emails, but users report they're still receiving suspicious messages.

**How to use Audit Logs**:

* Search for the specific action type (e.g., `find_and_soft_delete_email`)
* Filter by `changedTo` containing `"status":"failed"` or `"status":"error"`
* Review the `message` field for error details
* Identify patterns (e.g., all failures targeting a specific email domain or occurring after a certain time)
* Use this information to understand if there are credential or permission issues

#### Monitoring Allow/Deny List Changes

**Scenario**: An unusual domain appears on your trusted domain list, potentially allowing phishing emails to bypass detection.

**How to use Audit Logs**:

* Search for `targetType:"Allow List: Trusted Domain"` with `action:"create"`
* Review when the domain was added and by whom
* Cross-reference with change management tickets
* If unauthorized, delete the entry and investigate the user account for compromise

**Example Query**:

```jsx
targetType:"Allow List: Trusted Domain" AND 
action:"create" AND 
target: "www.bsf.org.il"
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.radiantsecurity.ai/log-management/audit-logs/introduction-to-audit-logs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.