detection.wiki

Detection rules › Panther

Databricks Terms of Service Changes

Status
Experimental
Severity
informational
Log types
Databricks.Audit
Tags
Databricks, Compliance
Reference
https://github.com/andyweaves/system-tables-audit-logs/blob/main/resources/queries_and_alerts.json
Source
github.com/panther-labs/panther-analysis

Detects Terms of Service acceptance or distribution events for compliance tracking. These events should be monitored for audit and governance purposes.

Rule body yaml

AnalysisType: rule
Filename: databricks_terms_of_service_changes.py
RuleID: "Databricks.Audit.TermsOfServiceChanges"
DisplayName: "Databricks Terms of Service Changes"
Enabled: true
Status: Experimental
LogTypes:
  - Databricks.Audit
Tags:
  - Databricks
  - Compliance
Severity: Info
Description: >
  Detects Terms of Service acceptance or distribution events for compliance tracking.
  These events should be monitored for audit and governance purposes.
Runbook: |
  1. Query audit logs for all TOS-related events in the past 90 days to establish baseline
  2. Check if this TOS acceptance aligns with expected onboarding or policy update timelines
  3. Find all TOS events for this user to verify compliance history
Reference: https://github.com/andyweaves/system-tables-audit-logs/blob/main/resources/queries_and_alerts.json
Tests:
  - Name: TOS Accepted
    ExpectedResult: true
    Log:
      timestamp: 1704067200000
      serviceName: "accounts"
      actionName: "acceptTos"
      userIdentity:
        email: "newuser@example.com"
      sourceIPAddress: "198.51.100.1"
      response:
        statusCode: 200
  - Name: TOS Sent
    ExpectedResult: true
    Log:
      timestamp: 1704067200000
      serviceName: "accounts"
      actionName: "sendTos"
      userIdentity:
        email: "admin@example.com"
      response:
        statusCode: 200
  - Name: Different Action
    ExpectedResult: false
    Log:
      timestamp: 1704067200000
      serviceName: "accounts"
      actionName: "login"
      userIdentity:
        email: "user@example.com"

Detection logic

Condition

actionName in ["acceptTos", "sendTos"]

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

FieldKindValues
actionNamein
  • acceptTos
  • sendTos

Output fields

Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.

FieldSource
emailuserIdentity.email