Navigation

  • Home
  • 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_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.

    FieldDescription
    baseConfidenceStarting score (0–100) when all required conditions match.
    confidenceThresholdMinimum score needed to fire the rule.
    confidenceFactorsOptional 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

    60

    Threshold

    40

    // 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

    70

    Threshold

    50

    // 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

    75

    Threshold

    60

    // 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

    55

    Threshold

    40

    // 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

    50

    Threshold

    40

    // 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

    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

    1. When you click the enable toggle on a template rule, a configuration dialog opens instead of directly enabling the rule.
    2. The dialog highlights the fields that need your environment-specific values (e.g., a certificate subject name).
    3. After you enter your values and click Save & Enable, a custom copy of the rule is created for your tenant with your values applied.
    4. 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.