Detection rules › Panther
Databricks High Priority Configuration Changes
Detects high-priority security configuration changes including audit logging modifications, IP access list changes, and security-critical workspace settings. Severity is elevated for successful changes to high-risk settings.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1098 Account Manipulation |
| Stealth | T1562.008 Impair Defenses: Disable or Modify Cloud Logs |
Rule body yaml
AnalysisType: rule
Filename: databricks_config_changes_high_priority.py
RuleID: "Databricks.Audit.ConfigChangesHighPriority"
DisplayName: "Databricks High Priority Configuration Changes"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Defense Evasion
- Persistence
Reports:
MITRE ATT&CK:
- TA0005:T1562.008 # Impair Defenses: Disable Cloud Logs
- TA0003:T1098 # Account Manipulation
Severity: Medium
Description: >
Detects high-priority security configuration changes including audit logging modifications,
IP access list changes, and security-critical workspace settings. Severity is elevated for
successful changes to high-risk settings.
Runbook: |
1. Query audit logs for all configuration changes by the actor in the 24 hours before and after this critical change
2. Check if this configuration change has been performed by this actor in the past 90 days to establish legitimacy
3. Find all other high-risk configuration changes (IP access lists, audit settings) across all workspaces in the past 7 days
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/configuration_changes_high_priority.py
SummaryAttributes:
- actor
- config_key
- change_category
Tests:
- Name: Audit Logging Disabled - Handled By Dedicated Rule
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "workspaceConfEdit"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
workspaceConfKeys: "enableVerboseAuditLogs"
workspaceConfValues: "false"
response:
statusCode: 200
- Name: Audit Logging Enabled
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "workspaceConfEdit"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
workspaceConfKeys: "enableVerboseAuditLogs"
workspaceConfValues: "true"
response:
statusCode: 200
- Name: IP Access List Deleted
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "deleteIpAccessList"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
listId: "acl-123"
response:
statusCode: 200
- Name: IP Access List Created
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "createIpAccessList"
userIdentity:
email: "admin@example.com"
requestParams:
ipAddresses: ["10.0.0.0/8"]
response:
statusCode: 200
- Name: MFA Enforcement Changed
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "workspaceConfEdit"
userIdentity:
email: "admin@example.com"
requestParams:
workspaceConfKeys: "enforceMFA"
workspaceConfValues: "false"
response:
statusCode: 200
- Name: Non-Critical Config Change
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "workspaceConfEdit"
userIdentity:
email: "admin@example.com"
requestParams:
workspaceConfKeys: "displayName"
workspaceConfValues: "Production Workspace"
Detection logic
Condition
actionName in ["createIpAccessList", "updateIpAccessList", "deleteIpAccessList"]
This rule also runs imperative logic the parser cannot express as a filter; the conditions above are the structured part it could extract.
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.
| Field | Kind | Values |
|---|---|---|
actionName | in |
|
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.
| Field | Source |
|---|---|
actionName | |
email | userIdentity.email |