Introduction to Audit Logs

Review system activity and maintain accountability.

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.

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.

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.

1. 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:

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

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.

Target Type

Account Notifications

Common Use Cases

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

Phishing Domains

Monitor domain management for phishing triage.

Target Type

Domain

Common Use Cases

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.

Target Type

Automatic closure of incidents

Common Use Cases

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.

Note: Integration configurations are redacted in audit logs for security.

Target Type

Credential

Common Use Cases

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

Troubleshooting Tip: If an integration stops working, search for recent modify events on the credential and verify the change was intentional.

Data Connectors

Track data connector lifecycle and status changes.

Target Type

Data Connector

Common Use Cases

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

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"

Allow Lists

Monitor trusted entity management across multiple categories.

Target Type

Allow List

Common Use Cases

List Type	Audited Actions	Target Type	Example	Security Impact
Trusted Domains	Create, Delete	Allow List: Trusted Domain	www.acme.corp.com	Emails/traffic from trusted domains bypass phishing detection
Trusted IPs	Create, Delete	Allow List: Trusted IP	1.1.1.1	Network connections from trusted IPs may skip threat analysis
Trusted Senders	Create, Delete	Allow List: Trusted Sender	[email protected]	Emails from trusted senders bypass email security checks
Shared Accounts	Create, Delete	Allow List: Shared Account	[email protected]	Shared account activity won't trigger impossible travel alerts
Public Object Storage	Create, Delete	Allow List: Public Object Storage	radiantsecurityS3bucket	Access to whitelisted storage won't escalate data exfiltration alerts
Trusted Applications	Create, Delete	Allow List: Trusted Application	salesforce	OAuth grants to trusted apps bypass suspicious app alerts

Security Alert: Regularly review create actions on allow lists. Attackers who compromise admin accounts often add malicious infrastructure to allowlists to evade detection.

Deny Lists

Track blocked entities for security enforcement.

Target Type

Deny List

Common Use Cases

List Type	Audited Actions	Target Type	Example	Enforcement Impact
Malicious Domains	Create, Delete	Deny List: Malicious Domain	malware.com	Blocks access to malicious sites at DNS/proxy level
Malicious IPs	Create, Delete	Deny List: Malicious IP	1.1.1.1	Blocks network connections to/from malicious IPs at firewall
Malicious Senders	Create, Delete	Deny List: Malicious Sender	[email protected]	Automatically quarantines emails from known malicious senders

Best Practice: Cross-reference deny list additions with threat intelligence feeds to measure coverage of known threat actors.

VIP Users

Manage high-priority user designations for enhanced monitoring.

Target Type

VIP User

Common Use Cases

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.

Target Type

Default Rule Filter

Common Use Cases

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

Troubleshooting Tip: If expected alerts aren't appearing, check for recently created or modified filters that may be excluding them.

Outgoing Webhooks

Monitor webhook configurations for external integrations.

Note: Webhook URLs are encrypted in audit logs for security.

Target Type

Outgoing Webhook

Common Use Cases

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

Troubleshooting Tip: If a webhook integration suddenly stops working, filter by the webhook target (name) and look for recent modify or disable events.

Example query: target:"Microsoft linkback" AND action: "Disable"

Alert Verdicts

Track alert status changes and outcomes throughout the investigation lifecycle.

Target Type

Alert Verdict

Target Format

Common Use Cases

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.

Target Type

Varies by action (e.g., user_principal_name, email_address, hostname, ip_address, file_hash)

Common Use Cases

Note: Response action logs capture the full lifecycle: in progress → completed/failed. Use the changedTo field to filter by status.

Category	Audited Actions	Example Targets	When to Review
User Accounts	Enable/Disable User, Reset Password, Revoke Session, Force MFA Re-enrollment	[email protected]	Compromised account investigations, insider threat cases, offboarding audits
Email Security	Delete Email, Quarantine Email, Release from Quarantine	<[email protected]>	Phishing campaigns, malware distribution, accidental data leaks
Endpoint Protection	Isolate/Unisolate Endpoint, Kill Process, Delete File, Collect Forensic Artifacts	DESKTOP-12345, malware.exe	Malware infections, ransomware incidents, forensic investigations
Network Security	Block IP, Block URL/Domain, Allow IP, Allow URL/Domain	192.168.1.100, malicious.com	C2 communication blocking, lateral movement prevention, threat containment

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:

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:

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:

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