Crowdstrike Resource Triage

CrowdStrike Resource Triage

Analyze supplied artifacts locally and produce an evidence-based triage report. Treat every SVE as a security-impacting candidate for human review; never configure Falcon or apply an exclusion.

Workflow

1. Determine whether the case uses offline artifacts, live Advanced Event Search, or both.

2. For offline artifacts, identify the case folder or archive and run the deterministic analyzer:

   python "<skill-dir>\scripts\analyze.py" "<case-path>" --output "<report.md>" --json-output "<evidence.json>"
   

3. Read the generated report and JSON evidence.

4. Before every live search, ask the user for all of the following:

   • exact start timestamp;
   • exact end timestamp;
   • timezone;
   • affected host AID;
   • LogScale base URL;
   • repository or view name;
   • confirmation that a repository/view-scoped data-read token is configured.

5. Never infer or silently default the live-search timeframe. Require timezone-aware absolute timestamps.

6. Read api-access.md and aes-queries.md. Run the query runner with --dry-run first:

   python "<skill-dir>\scripts\run_aes.py" --mode logscale-token --base-url <url> --repository <name> --aid <aid> --start <timestamp> --end <timestamp> --timezone <zone> --query discovery --output-dir <protected-case-folder> --dry-run
   

7. Review the generated plan for the exact endpoint, query names, AID, and time window. If correct, rerun without --dry-run. Run discovery queries 1 and 2 first. Run lineage query 3 only with explicit parent and child values supported by those results.

8. Combine live-search evidence with offline evidence. Do not guess lineage or claim that API data proves host CPU causation by itself.

9. Read decision-policy.md before interpreting or expanding any SVE candidate.

10. Explain:

• what the offline evidence proves;
• what it merely suggests;
• what evidence is missing;
• which remediation should precede or accompany an SVE;
• how to validate and roll back any approved change.

Analyzer behavior

Accept a directory or archive. Support nested ZIP, TAR, TAR.GZ, TAR.BZ2, and TAR.XZ packages using Python’s standard library. Extract only to a temporary directory, reject unsafe archive paths, and leave the supplied artifacts unchanged.

Parse these sources when present:

• falcon-cstel_um.log: cumulative Falcon message counters, process uptime, and dropped-event counters.
• perf_stats.txt: short-window sched_process_exec count and elapsed time.
• perf_sched_report.txt: executable frequency and event totals.
• ps-agxz.txt: point-in-time parent and descendant relationships.
• hardware_statistics.txt or top.txt: CPU snapshots.
• lscpu.txt: logical CPU count.

Always report missing sources. Do not convert absence of evidence into a clean bill of health.

Interpretation rules

• Prefer measurements reproduced from the supplied bundle over historical case commentary.
• Keep cumulative and short-window execution rates separate.
• Treat a large set of short-lived utilities (date, cut, rev, basename, dirname, and similar) as evidence of script-like activity, not proof of a particular parent.
• Require parent/child lineage before naming a service or script as the cause.
• Treat bash, sh, interpreters, schedulers, and system-wide daemons as broad, high-risk exclusion targets.
• Distinguish a script path from its process image. If invoked as bash script.sh, Falcon sees the interpreter as the image; do not claim that a script-path SVE will match.
• Prefer reducing loops, invocation frequency, subprocess counts, or workload misconfiguration over permanent visibility loss.
• Never reuse exclusions from an older case as a universal allowlist.
• Never state that Falcon is defective or healthy solely from high CPU.

Required response

Lead with a concise conclusion and confidence. Include:

• evidence completeness;
• sensor and host CPU observations;
• cumulative and short-window executions per minute;
• top executed programs;
• parent/descendant evidence;
• candidate SVE targets, each labeled candidate—not approval;
• security scope and uncertainty;
• AES queries needed to close gaps;
• workload-remediation alternatives;
• pre/post metrics, observation window, and rollback conditions;
• an explicit statement that no Falcon changes were made.

Do not output secrets, customer identifiers, IP addresses, usernames, case numbers, or command-line credentials unless the user explicitly needs them. Redact them from summaries by default.

Never ask the user to paste an API client secret or token into chat. Accept credentials only through the documented environment variables or an approved secret manager. Never place credentials on a command line, in a query plan, in a report, or in a result file.

Never use a Falcon OAuth client carrying NGSIEM: WRITE, or any other Falcon WRITE scope. If a repository/view-scoped LogScale data-read token is unavailable, ask the user to run the AES queries in Falcon and supply an export for offline analysis.

Confidence

Use:

• High: two independent sources support the same mechanism and lineage identifies the responsible parent.
• Medium: the offline snapshot shows a substantial parent tree, but temporal correlation with the CPU interval is incomplete.
• Low: only executable frequency or a CPU snapshot exists without lineage.
• Insufficient evidence: required artifacts are absent or contradictory.

An offline-only candidate must not exceed Medium confidence.