Detection rules › Panther
Databricks Workspace-Level Configuration Changes
Detects configuration changes at the Databricks workspace level. Workspace-level changes affect a single workspace and include settings like cluster configurations, notebook settings, and workspace-specific security controls.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1098 Account Manipulation |
Rule body yaml
AnalysisType: rule
Filename: databricks_config_changes_workspace_level.py
RuleID: "Databricks.Audit.ConfigChangesWorkspaceLevel"
DisplayName: "Databricks Workspace-Level Configuration Changes"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Persistence
Reports:
MITRE ATT&CK:
- TA0003:T1098 # Account Manipulation
Severity: Info
Description: >
Detects configuration changes at the Databricks workspace level. Workspace-level changes
affect a single workspace and include settings like cluster configurations, notebook
settings, and workspace-specific security controls.
Runbook: |
1. Query audit logs for all workspace configuration changes in the 24 hours around this event
2. Check if the workspace behavior changed based on cluster activity or user actions in the 6 hours after the configuration change
3. Find all configuration changes for this workspace in the past 30 days to establish baseline
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/configuration_changes_workspace_level.py
Tests:
- Name: Workspace Config Edit
ExpectedResult: true
Log:
timestamp: 1234567890000
auditLevel: "WORKSPACE_LEVEL"
serviceName: "workspace"
actionName: "workspaceConfEdit"
workspaceId: "1234567890123456"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
workspaceConfKeys: "defaultClusterVersion"
workspaceConfValues: "12.2.x-scala2.12"
response:
statusCode: 200
- Name: Workspace Settings Updated
ExpectedResult: true
Log:
timestamp: 1234567890000
auditLevel: "WORKSPACE_LEVEL"
serviceName: "workspace"
actionName: "updateWorkspaceSettings"
workspaceId: "1234567890123456"
userIdentity:
email: "admin@example.com"
requestParams:
setting: "enableNotebookGit"
value: "true"
response:
statusCode: 200
- Name: Account-Level Change
ExpectedResult: false
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "updateAccountSettings"
userIdentity:
email: "admin@example.com"
- Name: Non-Config Action
ExpectedResult: false
Log:
timestamp: 1234567890000
auditLevel: "WORKSPACE_LEVEL"
serviceName: "workspace"
actionName: "createNotebook"
workspaceId: "1234567890123456"
userIdentity:
email: "user@example.com"
Detection logic
Condition
auditLevel eq "WORKSPACE_LEVEL"
serviceName eq "workspace" or serviceName eq "accounts" or serviceName eq "ssoConfigBackend"
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 |
|---|---|---|
auditLevel | eq |
|
serviceName | eq |
|
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 |
|---|---|
workspaceId | |
email | userIdentity.email |
actionName |