Documentation

Analyze Rules

Analyze Rules define when and why the agent flags an issue during enrollment. Each rule evaluates events collected during the session and produces a confidence score. If the score reaches the configured threshold the rule fires, creating a finding that appears in the session timeline and the analysis summary.

How scoring works

Every rule starts with a Base Confidence value (0–100). Confidence Factors are optional conditions that add or subtract points when matched. The final score is compared to the Confidence Threshold. The rule fires only if base + factors ≥ threshold.

Conditions

Conditions define what events or data the rule looks for. All required conditions must match for the rule to proceed to scoring. Optional conditions are used only as confidence factors.

Source: event_type

Checks whether a specific event type was emitted during the session. The most common condition type.

Signal

A label for this condition (e.g., app_failed)

Event Type

The exact event type to look for (e.g., app_install_failed)

Operator

exists — the event occurred at all

Example — detect any app installation failure

Signal: app_failed · Source: event_type · Event Type: app_install_failed · Operator: exists

Source: event_data

Inspects a field inside the data payload of a specific event type. Use this to match on values like error codes or app names.

Important: The available data fields depend on which collector type produced the event. Structured collectors (Registry, WMI, JSON, XML) expose individual named fields.Command collectors produce only raw text — use dataField: "output" with contains or regex to search the command output. See the Data fields by collector type table in the Gather Rules section for a full reference.

Operators

equals — exact match
contains / not_contains — substring match
regex / not_regex — regular expression match
gt / lt / gte / lte — numeric comparisons
exists / not_exists — field presence check

Common data fields

errorCode — Win32 / HTTP error code
appName — application name
exitCode — process exit code
phase — enrollment phase name
output — command stdout (Command collector)
error_output — command stderr (Command collector)

Example — detect error code 0x80070002

Source: event_data · Event Type: app_install_failed · Data Field: errorCode · Operator: equals · Value: 0x80070002

Example — check command output for a certificate subject

Source: event_data · Event Type: gather_machine_cert_store · Data Field: output · Operator: not_contains · Value: CN=MyCertificate

Confidence Factor: gather_machine_cert_store.error_output exists → +10 (command had errors)

Source: event_data_array

Iterates an array field inside a single event and tests a sub-field on each element. The condition matches when any element satisfies the operator. Use this when one event carries a list (e.g. all detected provisioning packages) and you want to react per item — without needing one event per item.

Data Field

The array to iterate (e.g. artifacts)

Item Field

Sub-field on each element to test (e.g. identity). Leave empty to test scalar elements.

Operator / Value

Same operators as event_data; applied to each element

Allow-list pattern: pair not_regex with an allow-list regex in Value. The condition then fires only for elements not on the list — every allow-listed element is ignored. Evidence carries the first non-matching item (under the item-field name, so {{identity}} interpolates) plus a matchCount.

Example — flag a provisioning package not on the allow-list

Source: event_data_array · Event Type: provisioning_package_scan · Data Field: artifacts · Item Field: identity · Operator: not_regex · Value: ^(?:Power\.Settings|SecureStart\.Settings)\b

Anchor the allow-list with ^ (start) and \b (boundary) — an unanchored substring pattern would also allow-list an impostor like Contoso.Power.Settings.Backdoor.

Source: event_count

Checks how many times a specific event type occurred. Use with count_gte or gt to detect repeated failures.

Example — detect 3 or more app failures

Source: event_count · Event Type: app_install_failed · Operator: count_gte · Value: 3

Source: phase_duration

Measures how long a specific enrollment phase took (in seconds). Use with gt or gte to detect phases that run too long.

Example — detect App Installation phase > 1 hour

Source: phase_duration · Data Field: AppsDevice · Operator: gt · Value: 3600

Source: event_correlation

Joins two event types on a shared field within a time window. Useful for detecting causal relationships — e.g., a network error that precedes a download failure.

Extra fields

Correlate Event Type — the second event to join with
Join Field — field that must match on both events
Time Window (s) — max seconds between the two events
Event A Filter — optional filter on the first event

Example — network error before download failure

Event Type A: network_error

Correlate Event Type: app_download_failed

Join Field: sessionId

Time Window: 120 seconds

Trigger Types

Single

Evaluates each matching event independently. The rule fires once for every event that satisfies all required conditions.

Correlation

Uses event_correlation conditions to join two event streams. Fires when matching pairs are found within the time window.

Confidence Scoring

The confidence model lets rules express uncertainty. A rule can fire with lower confidence when only partial evidence is present, and higher confidence when multiple corroborating signals align.

Field	Description
baseConfidence	Starting score (0–100) when all required conditions match.
confidenceThreshold	Minimum score needed to fire the rule.
confidenceFactors	Optional conditions that add or subtract points from the base score when matched.

Tip: Start with baseConfidence: 50 and confidenceThreshold: 40. Add confidence factors for additional signals (e.g., +20 if a specific error code matches, -10 if the app subsequently succeeded).

Example Rules

Example 1 — Repeated App Install Failure

Detect when three or more app installations fail in the same session

Category

apps

Severity

high

Base Confidence

Threshold

// Condition 1 (required)

source: "event_count" eventType: "app_install_failed" operator: "count_gte" value: "3"

// Confidence Factor (+20 if error code indicates timeout)

signal: "timeout_code" condition: "errorCode contains 0x800704C7" weight: 20

Example 2 — App Installation Phase Too Long

Fire when the Apps (Device) ESP phase exceeds 45 minutes

Category

esp

Severity

warning

Base Confidence

Threshold

// Condition (required)

source: "phase_duration" dataField: "AppsDevice" operator: "gt" value: "2700"

Example 3 — Network Error Preceding Download Failure

Correlate a network drop with a subsequent app download failure within 2 minutes

Trigger

correlation

Category

network

Base Confidence

Threshold

// Correlation condition

source: "event_correlation" eventType: "network_error"

correlateEventType: "app_download_failed" joinField: "sessionId" timeWindowSeconds: 120

Example 4 — Specific App Blocked by Disk Space

Detect a download stall caused by low disk space for a named application

Category

apps

Severity

critical

Base Confidence

Threshold

// Condition 1 — app failure occurred

source: "event_type" eventType: "app_install_failed" operator: "exists"

// Condition 2 — error code is disk-full (0x80070070)

source: "event_data" eventType: "app_install_failed" dataField: "errorCode" operator: "equals" value: "0x80070070"

// Confidence Factor (+30 if disk space event also fired)

signal: "disk_event" condition: "event_type disk_space_low exists" weight: 30

Example 5 — Analyze Command Output (Gather Rule)

Check if a certificate subject is missing from certutil output

Gather Rule: certutil -store My → outputs as event type gather_machine_cert_store

Category

identity

Severity

warning

Base Confidence

Threshold

// Condition 1 — certutil data was gathered

source: "event_type" eventType: "gather_machine_cert_store" operator: "exists"

// Condition 2 — certificate subject not found in command output

source: "event_data" eventType: "gather_machine_cert_store" dataField: "output" operator: "not_contains" value: "CN=MyCert"

// Confidence Factor (+20 if command produced no output at all)

signal: "no_output" condition: "gather_machine_cert_store.output not_exists" weight: 20

// Confidence Factor (+10 if command had errors)

signal: "cmd_error" condition: "gather_machine_cert_store.error_output exists" weight: 10

Example 6 — Unexpected Provisioning Package (array + allow-list)

Fire for any provisioning package (PPKG) that is not on an allow-list — from the scan event(s) that list them all

The agent emits a provisioning_package_scan event whose artifacts array lists every PPKG it found (each with an identity). This rule iterates that array instead of expecting one event per package. On devices with very many packages the array is split across several provisioning_package_scan events (chunkIndex/chunkCount) — event_data_array evaluates across all of them, so nothing is missed. (A separate built-in rule, ANALYZE-SEC-007, flags the rare case where a per-source collection cap was hit.)

Category

security

Severity

warning

Base Confidence

Threshold

// Condition (required) — any artifact identity NOT on the allow-list

source: "event_data_array" eventType: "provisioning_package_scan"

dataField: "artifacts" itemField: "identity" operator: "not_regex"

value: "^(?:Microsoft\.Windows\.Cosa|Power\.EnergyEstimationEngine|Power\.Settings|SecureStart\.Settings)\b"

// Explanation can reference the offending item: "Unexpected package: {{identity}}"

The allow-list above covers the Windows OS-inbox packages that ship on every device, so a clean machine stays quiet. The pattern is anchored (^(?:…)\b), so to allow your own vendor/recovery packages insert a new alternative inside the group, before the closing ) — e.g. …|SecureStart\.Settings|Acme\.Recovery)\b (appending after the ) won't match). The built-in rules ANALYZE-SEC-005 (always on) and ANALYZE-SEC-006 (template, customizable allow-list) use exactly this pattern.

Template Rules

Some community rules contain placeholder values that must be customized for your environment before they can work correctly. These rules are marked with a Requires Setup badge.

How template rules work

When you click the enable toggle on a template rule, a configuration dialog opens instead of directly enabling the rule.
The dialog highlights the fields that need your environment-specific values (e.g., a certificate subject name).
After you enter your values and click Save & Enable, a custom copy of the rule is created for your tenant with your values applied.
The original template rule remains disabled. Your custom copy is fully editable — you can adjust conditions, confidence, or other settings as needed.

Note: If you delete the custom copy, the template rule becomes available again and you can re-configure it. Centrally updated templates (via reseed) do not affect your existing custom copies.

Example — No Machine Certificates Found

Template rule that checks for a specific certificate subject in the local machine store

This rule ships with the placeholder CN=YOUR-CERTIFICATE-SUBJECT. When you enable it, you are prompted to enter your actual certificate subject (e.g., CN=Contoso Root CA). The system creates a custom rule with your value automatically substituted into the condition.

Rule ID

ANALYZE-ID-001

Variable

Certificate Subject

Placeholder

CN=YOUR-CERTIFICATE-SUBJECT

Custom Copy ID

ANALYZE-ID-001-CUSTOM

JSON editing

The Analyze Rules editor supports a JSON mode accessible via the Form / JSON toggle in the top-right of the create and edit panels. Use JSON mode to author complex rules with multiple conditions, confidence factors, remediation steps, and event_correlation properties that go beyond what the form UI exposes.