v12 dashboard: CrowdStrike Falcon

[kryonsx]

Part of: #2696 · Needs first: #2697 (click-through to the Log Explorer and the value/count table)
Related: #1794 (parsers and rules for this integration, owned by the detection team)

Goal

Ship a built-in CrowdStrike Falcon dashboard that shows, at a glance, how much CrowdStrike Falcon is sending, whether it is still sending, and what kinds of events they are. The heart of it is the list of CrowdStrike Falcon logs grouped by event types (widget W7): click one and the Log Explorer opens on exactly those logs.

Where the data comes from

Integration (catalog name)	CROWDSTRIKE
Data type	crowdstrike
How the logs arrive	The UTMStack CrowdStrike plugin opens the Falcon Streaming API with the API client of each config group and turns every streamed event (a JSON object with 'metadata' and 'event') into one log, unchanged.
Parser	definitions/filters/crowdstrike/crowdstrike.yaml
What dataSource holds	The name of the UTMStack config group (one Falcon API client and customer). Proof: plugins/crowdstrike/main.go sets dataSource: group.GroupName for each stream and processEvent passes it as DataSource; the parser never writes dataSource. So W6 is 'Logs by Falcon connection'; the endpoint is in origin.host.
Grouped by	log.metadataEventType (event types)

Why log.metadataEventType: Every Falcon stream event has metadata.eventType, which the parser renames to log.metadataEventType. It names the kind of record (detection, sign-in audit, console audit, incident, remote response session), has a few dozen values at most, and is readable. The detection's own title is in log.eventName (W9), and the audit operation in log.eventOperationName; neither exists on all events. Values below appear in real Falcon events (Elastic's CrowdStrike integration test data).

Typical values: EppDetectionSummaryEvent (endpoint detection), AuthActivityAuditEvent (console or API sign-in), UserActivityAuditEvent (console change), IncidentSummaryEvent (incident), RemoteResponseSessionStartEvent (remote response session opened), IdpDetectionSummaryEvent (identity protection detection)

Widgets

Standard layout from the parent issue; rows W2, W3 and W9 onward are specific to this integration.

#	Title	Shown as	Query	Why
W1	Total logs	number	logs: count	All Falcon stream events in the selected time range.
W2	Detections	number	logs: count; filter log.metadataEventType ends with DetectionSummaryEvent	Every detection summary type: EppDetectionSummaryEvent, DetectionSummaryEvent, IdpDetectionSummaryEvent, XdrDetectionSummaryEvent, MobileDetectionSummaryEvent, DataProtectionDetectionSummaryEvent and OverwatchGenericDetectionSummaryEvent.
W3	Detections not prevented	number	logs: count; filter log.eventPatternDispositionDescription starts with Detection	The sensor only reported the activity and did not block it ('Detection, ...'); blocked ones start with 'Prevention, ...'.
W4	Alerts	number	alerts: count	Alerts raised from CrowdStrike logs.
W5	Log volume over time	area chart	logs: count over time	Shows gaps in the stream and bursts of events.
W6	Logs by Falcon connection	bar chart	logs: top 10 values of dataSource	dataSource is the config group of the Falcon API client, so this shows which connection is busiest or silent.
W7	Top event types	value and count table	logs: top 25 values of log.metadataEventType; filter log.metadataEventType exists	The main list: Falcon stream event types by count; click one to open those logs.
W8	Event types over time (top 5)	line chart	logs: count over time, one line per value of log.metadataEventType (top 5); filter log.metadataEventType exists	When each of the five most common event types happened.
W9	Top detection names	bar chart	logs: top 10 values of log.eventName; filter log.eventName exists; log.metadataEventType ends with DetectionSummaryEvent	Most frequent detection titles (for example Known Malware, Suspicious Activity).
W10	Top hosts	bar chart	logs: top 10 values of origin.host; filter origin.host exists	Endpoints with the most detections.
W11	Top users	bar chart	logs: top 10 values of origin.user; filter origin.user exists	Endpoint users on detections and operators of remote response sessions.
W12a	Detections by severity	pie chart	logs: top 50 values of log.eventSeverityName; filter log.eventSeverityName exists; log.metadataEventType ends with DetectionSummaryEvent	Split of detections into Informational, Low, Medium, High and Critical (five values in real detection events).
W12b	Top tactics	bar chart	logs: top 10 values of log.eventTactic; filter log.eventTactic exists	Which attack tactics (or Falcon categories such as Malware) the detections map to.
W13	Alerts by rule	bar chart	alerts: top 10 values of name	Which CrowdStrike detection rules fire most.
W14	Alerts by severity	bar chart	alerts: top 50 values of severity	Split of CrowdStrike alerts into low, medium and high.
W15	Latest logs	table of latest logs	logs: latest 20 records; columns @timestamp, dataSource, log.metadataEventType, log.eventName, origin.host, origin.user, log.eventSeverityName, log.eventOperationName	The newest events; detections show name, host, user and severity, audit events show the operation.

Fields used and where they come from

• log.metadataEventType: Falcon stream event type. Examples: EppDetectionSummaryEvent, AuthActivityAuditEvent, UserActivityAuditEvent. Source: json step on raw (top-level key 'metadata'), then rename log.metadata.eventType -> log.metadataEventType.
• log.eventName: Detection title (endpoint detections). Examples: Known Malware, Suspicious Activity, NGAV. Source: rename log.event.Name -> log.eventName.
• origin.host: Endpoint host name of the detection. Examples: dave-win10-3, linux-vm. Source: rename log.event.Hostname -> origin.host.
• origin.user: User on the endpoint (detections) or remote response operator. Examples: win10_user3, Administrator, first.last@company.com. Source: rename log.event.UserName -> origin.user.
• log.eventSeverityName: Falcon severity name. Examples: Informational, Low, Medium, High, Critical. Source: rename log.event.SeverityName -> log.eventSeverityName.
• log.eventPatternDispositionDescription: What the sensor did: 'Prevention, ...' when it blocked, 'Detection, ...' when it only reported. Examples: Prevention, process killed., Detection, standard detection., Detection, process would have been blocked if related prevention policy setting was enabled.. Source: rename log.event.PatternDispositionDescription -> log.eventPatternDispositionDescription.
• log.eventTactic: MITRE ATT&CK tactic or Falcon category of the detection. Examples: Malware, Execution, Falcon Overwatch. Source: rename log.event.Tactic -> log.eventTactic.
• log.eventOperationName: Audit operation (sign-in and console events). Examples: twoFactorAuthenticate, streamStarted, detection_update. Source: rename log.event.OperationName -> log.eventOperationName.
• actionResult: Outcome of audit events. Examples: success, failed. Source: add 'success'/'failed' from log.eventSuccess true/false, or from statusCode 200-399 / >= 400.

Watch out for

• Field coverage differs by event type. Current endpoint detections (EppDetectionSummaryEvent) fill log.eventName, origin.host, origin.user, log.eventSeverityName, log.eventTactic and the disposition. The legacy DetectionSummaryEvent keeps ComputerName, DetectName and DetectDescription unrenamed (under log.event.), so those detections are missing from W9 and W10. Incident, firewall, identity, IOC and remote response events keep most of their fields nested under log.event. (for example the remote response host is log.event.HostnameField).
• W2 uses 'ends_with DetectionSummaryEvent' (the store ignores case) so it covers all seven detection summary types seen in real Falcon data; IdentityProtectionEvent and IncidentSummaryEvent are incidents, not detections, and are not counted.
• W3 relies on Falcon's disposition text starting with 'Detection' (reported only, for example 'Detection, process would have been blocked if related prevention policy setting was enabled.') or 'Prevention' (blocked or killed). Events without a disposition are not counted.
• Severity names are title case on all detection types in real Falcon data ('Informational', 'Low', 'Medium', 'High', 'Critical'); identity incident events use capitals ('LOW', 'INFO') and are left out of W12a by its filter. The parser does not normalize them or fill the standard severity column.
• actionResult exists only on sign-in and console audit events (from Success or the HTTP status code), so it is not used for detections.
• Console users of audit events stay in log.eventUserId, not origin.user, so W11 shows endpoint users and remote response operators only.
• dataSource is the config group of the Falcon API client, so W6 shows one bar per connection.
• Time charts use the time UTMStack received the event (the plugin sets @timestamp to the receive time); the event time stays in log.metadataEventCreationTime (epoch milliseconds).
• No field used here depends on the engine's underscore rule: only the top-level keys 'metadata' and 'event' go through key cleanup, and nested keys are kept as they are. The replay gave the same result with both rules.
• Checked with a step-by-step replay of this filter over 50 real Falcon stream events from Elastic's public CrowdStrike integration test data plus 8 samples prepared earlier.

Parser problems found while designing this

These are not dashboard work, but they limit what the dashboard can show. They belong to #1794; raise them there rather than working around them in the dashboard.

• The legacy DetectionSummaryEvent keys ComputerName, DetectName and DetectDescription are not renamed, so those detections have no origin.host or log.eventName.
• The sign-in client address is deleted: the final delete removes log.event.UserIp and log.event.Attributes.user_ip without renaming them first, so console and API sign-ins have no origin.ip (and no geolocation).
• No severity normalization: SeverityName stays in log.eventSeverityName with mixed case ('High', 'LOW'), and the standard severity column is empty.
• The event time (metadata.eventCreationTime, event.UTCTimestamp) is not mapped to deviceTime.
• Many event types (incidents, firewall matches, identity protection, remote response, IOC events) are left almost entirely under log.event.*, including host names such as HostnameField, so per-host views miss them.
• Does not affect this dashboard: several renames are duplicated (log.event.Message, log.event.ServiceName, log.event.Attributes.trace_id appear twice).

How to build it

Before you start: parser field names are changing while the parsers are updated for the engine's new underscore handling (see "Field names are about to move" in #2696). Check every field in this issue against the v12 parser at that moment and against real logs, and build against what you find.

1. Add definitions/dashboards/integration-crowdstrike.yaml. Keep it in the top folder: the test that checks shipped dashboards (TestEveryShippedDashboardDefinitionIsValid) only reads the top folder.
2. Start from the file below; it follows the table above and passes the same checks as the backend (domain.Spec.Validate).
3. W7 is a value/count table: a category query shown with chart type table. It already renders; v12 dashboards: groundwork for integration dashboards (click-through to the Log Explorer, value/count table, Agents dashboard fix) #2697 makes its rows clickable and its headers readable.
4. Load real logs from this technology on a v12 test server (or replay samples) and check every widget before opening the pull request.

Starting dashboard file

# Dashboard version v1.0.0
#
# System-owned default dashboard for the CrowdStrike Falcon integration, seeded by
# backend/modules/dashboards/repository/dashboard_bootstrap.go.
# Field names come from definitions/filters/crowdstrike/crowdstrike.yaml.
# Verify every widget against real logs before shipping.
name: "CrowdStrike Falcon"
description: "What CrowdStrike Falcon is sending: volume, event types, and the activity worth a look."
widgets:
  - layout: { x: 0, y: 0, w: 3, h: 2 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: metric
      metric:
        agg: count
    config:
      __builder:
        chartType: metric
        title: "Total logs"

  - layout: { x: 3, y: 0, w: 3, h: 2 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: metric
      metric:
        agg: count
      filters:
        - field: "log.metadataEventType"
          op: ends_with
          value: "DetectionSummaryEvent"
    config:
      __builder:
        chartType: metric
        title: "Detections"

  - layout: { x: 6, y: 0, w: 3, h: 2 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: metric
      metric:
        agg: count
      filters:
        - field: "log.eventPatternDispositionDescription"
          op: starts_with
          value: "Detection"
    config:
      __builder:
        chartType: metric
        title: "Detections not prevented"

  - layout: { x: 9, y: 0, w: 3, h: 2 }
    spec:
      dataset: alerts
      dataType: "crowdstrike"
      chart: metric
      metric:
        agg: count
    config:
      __builder:
        chartType: metric
        title: "Alerts"

  - layout: { x: 0, y: 2, w: 8, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: time
      metric:
        agg: count
    config:
      __builder:
        chartType: area
        title: "Log volume over time"

  - layout: { x: 8, y: 2, w: 4, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "dataSource"
      limit: 10
    config:
      __builder:
        chartType: bar
        title: "Logs by Falcon connection"

  - layout: { x: 0, y: 6, w: 6, h: 6 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "log.metadataEventType"
      filters:
        - field: "log.metadataEventType"
          op: exists
      limit: 25
    config:
      __builder:
        chartType: table
        title: "Top event types"

  - layout: { x: 6, y: 6, w: 6, h: 6 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: time
      metric:
        agg: count
      dimension: "log.metadataEventType"
      filters:
        - field: "log.metadataEventType"
          op: exists
      limit: 5
    config:
      __builder:
        chartType: line
        title: "Event types over time (top 5)"

  - layout: { x: 0, y: 12, w: 4, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "log.eventName"
      filters:
        - field: "log.eventName"
          op: exists
        - field: "log.metadataEventType"
          op: ends_with
          value: "DetectionSummaryEvent"
      limit: 10
    config:
      __builder:
        chartType: bar
        title: "Top detection names"

  - layout: { x: 4, y: 12, w: 4, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "origin.host"
      filters:
        - field: "origin.host"
          op: exists
      limit: 10
    config:
      __builder:
        chartType: bar
        title: "Top hosts"

  - layout: { x: 8, y: 12, w: 4, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "origin.user"
      filters:
        - field: "origin.user"
          op: exists
      limit: 10
    config:
      __builder:
        chartType: bar
        title: "Top users"

  - layout: { x: 0, y: 16, w: 6, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "log.eventSeverityName"
      filters:
        - field: "log.eventSeverityName"
          op: exists
        - field: "log.metadataEventType"
          op: ends_with
          value: "DetectionSummaryEvent"
    config:
      __builder:
        chartType: pie
        title: "Detections by severity"

  - layout: { x: 6, y: 16, w: 6, h: 4 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "log.eventTactic"
      filters:
        - field: "log.eventTactic"
          op: exists
      limit: 10
    config:
      __builder:
        chartType: bar
        title: "Top tactics"

  - layout: { x: 0, y: 20, w: 6, h: 4 }
    spec:
      dataset: alerts
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "name"
      limit: 10
    config:
      __builder:
        chartType: bar
        title: "Alerts by rule"

  - layout: { x: 6, y: 20, w: 6, h: 4 }
    spec:
      dataset: alerts
      dataType: "crowdstrike"
      chart: category
      metric:
        agg: count
      dimension: "severity"
    config:
      __builder:
        chartType: bar
        title: "Alerts by severity"

  - layout: { x: 0, y: 24, w: 12, h: 6 }
    spec:
      dataset: logs
      dataType: "crowdstrike"
      chart: table
      metric:
        agg: count
      limit: 20
      columns: ["@timestamp", "dataSource", "log.metadataEventType", "log.eventName", "origin.host", "origin.user", "log.eventSeverityName", "log.eventOperationName"]
    config:
      __builder:
        chartType: table
        title: "Latest logs"

Done when

• definitions/dashboards/integration-crowdstrike.yaml is merged to release/v12.0.0 and go test ./modules/dashboards/... passes in backend/.
• With CrowdStrike Falcon logs flowing on a v12 test server, every widget shows data. A widget that stays empty while logs arrive means a wrong field or value: fix it, don't ship it.
• Clicking a row, bar or line point opens the Log Explorer on the same logs, and the Log Explorer count matches the widget.
• A time range with no logs shows empty states, not errors.
• A screenshot of the finished dashboard is attached to this issue.