Tool families

About 16 min read

On this page

One entry per tool family: the question it answers, what it sees, and where it goes blind. Start from the question on the Choosing tools pillar; come here for the family detail.

The fifteen families

The Uncover phase touches fifteen major tool families. Each section opens with the question that family answers, which is the same question the question-to-tool table on the Choosing tools pillar routes to it. The C.A.T. glossary carries the vendor detail.


SIEM

The SIEM (Security Information and Event Management) answers “did this happen anywhere else?” It holds normalized events from across the Infrastructure The systems, networks, and services that computing runs on. In triage the word points two directions: the organization's infrastructure is what alerts fire on, and attacker infrastructure is the set of C2 servers, domains, and staging hosts an adversary operates, which pivoting on indicators is meant to map. and is where cross-source joins run, for real-time detection and retrospective investigation alike. For Security Operations The people, processes and technology that monitor, detect, investigate and respond to threats day to day, usually organized as a SOC. ASSURED covers the triage slice, from an alert firing to a documented close or escalation. , it is the default query window.

Products in the C.A.T. glossary: SIEM, log pipelines and security data lakes. Query languages and schemas (KQL with ASIM, SPL with CIM, ES|QL and EQL with ECS, YARA-L with UDM, SQL over OCSF): query languages, rule formats and log schemas.

SIEM: key capabilities

  • Log collection and storage across firewalls, IDS/IPS, OS, auth services, cloud, applications.
  • Data analysis and alerting via rule-based and behavioral analytics.
  • Cross-source correlation exposes multi-stage attacks and coordinated activity.
  • Reporting and dashboards for compliance, threat hunting, and operational monitoring.

SIEM: common limitations

  • Retention constraints bounded by licensing and infrastructure capacity.
  • Coverage gaps when log sources are unsupported or misconfigured.
  • Silent parser failures: a field the parser never filled returns zero rows that look exactly like a clean result; run a control query first.
  • Ingest lag: forwarders batch and fall behind, so the newest events may not be searchable yet, and index time is not event time.

The SIEM is the first stop when the question crosses sources: “did this happen anywhere else?” or “what other systems did this User The identity behind activity on a system: the account that authenticated, launched the process, or received the email. In triage the user field names an account, not necessarily a person; whether the legitimate owner was actually behind the activity is exactly the question stolen credentials raise. touch?”. It is less useful for deep single-source Forensics The application of scientific methods to collect, preserve, and analyze digital evidence so that findings hold up to scrutiny: disk and memory images, log exports, mobile extractions, each with a documented chain of custody. In triage the forensic move is preservation: capture volatile evidence, and hash what you export, before containment changes the system. , which is where EDR and Digital Forensics Forensics applied to computers, networks, cloud services and mobile devices; in a SOC the two terms name the same discipline. See Forensics. earn their keep. For hands-on practice, Lab 5 of the telemetry labs runs Splunk searches over the BOTS v3 dataset, and the capstone pairs a SIEM with packet captures.


EDR

Endpoint A device that runs an operating system and applications and connects to the network: workstation, laptop, server, virtual machine, phone, tablet. Endpoints are where execution-based tradecraft (malware, scripts, hands-on-keyboard commands) shows up, which is why EDR exists. Identity, SaaS and cloud-control-plane attacks, and attacks on network appliances that cannot run EDR, may never touch one, so endpoint silence is not proof of absence. Detection and Response answers “what ran on this machine, and what did it touch?” It records high-fidelity Telemetry The event streams that endpoints, network sensors, identity providers, SaaS apps and cloud control planes emit about what happened on them. Triage can only see what was collected: when telemetry is missing for a host or time window, record it as a gap (unknown is not Low), not as clean. on user devices and servers (process Execution The ATT&CK tactic (TA0002) for running attacker-controlled code on a local or remote system: through command interpreters, user-run files and lures, scheduled tasks, WMI, or exploits. It rarely stands alone: attackers execute code to discover, steal, move or persist. , file system activity, memory use, and network connections) and can act on the host.

Products in the C.A.T. glossary: Endpoint detection and response / XDR.

EDR: key capabilities

  • Process monitoring: creation events, command-line parameters, parent-child lineage, runtime patterns.
  • Network monitoring: outbound connections, DNS, protocol behavior, detecting C2 and exfiltration.
  • File activity tracking: unauthorized modifications to system files and critical directories.
  • Response actions: endpoint isolation, live response and memory acquisition, process termination, automated remediation.

EDR: common limitations

  • Visibility gaps on non-standard endpoints (IoT, ICS, specialized hardware).
  • Noise on legitimate admin work: benign true positives when a behavioral detection correctly flags authorized admin activity, and false positives when it misreads the activity.
  • Retention windows: console telemetry often spans days to weeks; older questions need the SIEM or lake archive.
  • Sensor tampering: an EDR killed, blinded, or cut off from its console by the attacker goes silent, and a silenced sensor looks exactly like a clean host. Check the sensor heartbeat before reading silence as clean (ATT&CK Defense Impairment, TA0112, including T1685 Disable or Modify Tools).

XDR

Extended Detection and Response platforms grow the EDR model outward: endpoint, identity, email, network, and cloud telemetry land in one console, and the vendor’s correlation logic stitches related events into a single incident before an analyst opens it. Where a SIEM joins whatever you feed it using rules you wrote, XDR ships pre-built joins across the telemetry the vendor controls.

Products in the C.A.T. glossary: Endpoint detection and response / XDR.

XDR: key capabilities

  • Cross-domain incident stitching: the phishing email, the process it spawned, and the sign-in it enabled arrive as one incident, not three alerts.
  • Unified query surface across endpoint, identity, and email telemetry without per-source query languages.
  • Coordinated response actions: isolate the host, revoke the session, and purge the email from one place.
  • Less swivel-chair triage because the joins the analyst would run by hand are pre-computed.

XDR: common limitations

  • Correlation quality tracks ecosystem coverage: strongest on the vendor’s own sensors, weakest on third-party sources.
  • Opaque stitching logic: the platform asserts that events belong together; the analyst still verifies the join keys before trusting the story.
  • Vendor lock-in deepens with every telemetry type routed through one platform.
  • SIEM overlap creates ambiguity about which system is authoritative for a given question.

XDR automates the join, not the judgment

An XDR incident is a machine-built version of the correlation this chapter teaches by hand: the same join keys, applied automatically. That makes it a head start, not a verdict. When the stitched incident matters to the outcome, check the joins the way you would check your own.


ITDR

Identity Threat Detection and Response answers “is someone abusing an identity, not a machine?” These tools watch the identity plane itself: directories, identity providers, and the credentials, tokens, and sessions they issue. As attacks shift from breaking endpoints to logging in, ITDR covers the tier where Token Theft Stealing an already-issued bearer credential that has passed MFA (browser session cookie, OAuth access or refresh token, Entra Primary Refresh Token, cloud CLI token) from browsers, disk caches, memory or an AiTM proxy, then replaying it from attacker infrastructure. Theft: T1539 Steal Web Session Cookie, T1528 Steal Application Access Token. Replay: T1550.004, T1550.001. Duplicating a Windows access token on an endpoint is the separate T1134.001 (see Token Impersonation). and Session Hijack Taking over an active session by stealing or guessing session tokens or cookies, bypassing authentication and MFA. live. EDR can see a process read a browser’s cookie store on the host; only the identity plane sees the stolen session replayed from somewhere else.

Products in the C.A.T. glossary: Identity, ITDR and privileged access.

ITDR: key capabilities

  • Directory attack detection: Kerberos Active Directory's default authentication protocol (TCP/UDP 88). The KDC on each domain controller issues a ticket-granting ticket (TGT) at logon, then service tickets for specific resources. Ticket theft (pass-the-ticket), offline cracking (Kerberoasting) and forgery (golden and silver tickets) all target this flow. Key events: 4768 (TGT), 4769 (service ticket). ticket abuse, DCSync-style replication requests, suspicious privilege grants.
  • Token and session anomalies: replayed tokens, impossible-travel sessions, MFA-bypass patterns at the IdP.
  • Attack-path mapping showing which identities and delegations lead from a foothold to the crown jewels.
  • Identity-native response: revoke sessions, force reauthentication, disable accounts at the provider.

ITDR: common limitations

  • Coverage bound to integrations: an IdP or directory the tool does not ingest is an identity blind spot.
  • Service-account noise in automation-heavy environments demands careful baselining.
  • Posture findings blur with live attacks: a risky delegation and an active abuse of it arrive in the same queue.
  • Revocation gaps: long-lived tokens already issued to third-party SaaS can outlive the response action.

Network analysis

Network analysis answers “where did this traffic go, and what did it carry?” Packet-level and flow-level tools observe communication patterns, which makes them the main source for detecting Lateral Movement Moving from the initial foothold to other hosts, identities or tenants to find sensitive data or reach higher-value targets (ATT&CK tactic TA0008). It usually rides legitimate remote-access protocols (RDP, SMB, WinRM, SSH) with stolen credentials, or replays a stolen session into a cloud or SaaS tenant, so the signal is an account authenticating where it does not normally go. Each hop widens the blast radius, and confirmed lateral movement is an escalation criterion. , Exfiltration The unauthorized transfer of data out of the environment (ATT&CK TA0010): over the C2 channel, to cloud storage or a file-sharing service, by email, or through DNS. Triage signals are volume and destination: outbound bytes far above the host's baseline, a first-seen upload destination, and staging (archives appearing in temporary folders) shortly before the transfer. Confirmed exfiltration is an escalation criterion, and when the data is regulated it can start notification clocks. , C2 Network Traffic The data moving between hosts on a network, observed as connections, flows, and packets. In triage, traffic metadata (who talked to whom, when, how much, and over which port and protocol) is often the fastest way to confirm or rule out command and control, exfiltration, or lateral movement. , and Protocol The agreed set of rules two systems use to communicate: HTTP, DNS, SMB, RDP. In triage the protocol tells you what a connection is capable of doing, and a mismatch between the protocol and the port it runs on is a classic tell for tunneling or evasion. misuse, especially in environments with unmanaged devices or systems that cannot support EDR. Lab 3 of the telemetry labs reads a packet capture in Security Onion, if you want to practice on real traffic.

Products in the C.A.T. glossary: Network, NDR and web security.

Network analysis: key capabilities

  • Traffic inspection for anomalies in behavior, volume, and flow direction.
  • Protocol decoding across DNS, HTTP, SMB, and others to uncover misuse.
  • Deep packet inspection for embedded threats, file transfers, encrypted tunneling.
  • Visualization tools for traffic patterns and threat propagation.

Network analysis: common limitations

  • Scalability challenges in high-volume environments that overwhelm capture infrastructure.
  • Protocol limitations with proprietary or encrypted communications.
  • Vantage point: a sensor sees only traffic that crosses it; east-west traffic and hosts off the corporate network without VPN never reach a perimeter sensor.
  • Short capture retention: full packets age out in hours or days; flow records last longer but carry no content.

Threat intelligence platforms

A threat intelligence platform (TIP) answers “has anyone seen this before, and what did it mean there?” TIPs consolidate external Threat Any circumstance or event with the potential to harm the organization's operations, assets, or people (NIST, from CNSSI 4009). The actor behind it is the threat actor; the weakness it uses is a vulnerability. Classical risk models multiply threat, vulnerability, and impact. ASSURED's RATM does not multiply. It scores threat actor intent and exploitation & scope as their own dimensions and lets them inform likelihood, which never rises above what the evidence supports. Risk is then read from the impact-by-likelihood matrix. data and give context for IOCs, attacker infrastructure, and adversary tactics, so triage can correlate internal events with known external Intelligence Information collected and analyzed to answer a decision-maker's question; in a SOC, usually threat intelligence. See Threat Intelligence for its levels and how to grade sources. . This is the platform view; the methodology for using what it serves is the threat-intelligence pillar, and the feed-as-evidence view is in telemetry sources.

Products in the C.A.T. glossary: Threat-intel platforms, research and knowledge bases.

Threat intelligence: key capabilities

  • Feed aggregation across commercial, OSINT, ISAC, and government sources.
  • IOC enrichment linking observed indicators to actors, campaigns, malware families.
  • TTP analysis mapped to MITRE ATT&CK for shared vocabulary.
  • Reporting and dashboards for strategic and tactical intelligence.

Threat intelligence: common limitations

  • Feed quality varies dramatically across vendors and OSINT sources.
  • Integration challenges with SIEM, EDR, and orchestration platforms.
  • Analyst workload from redundant data and insufficient context.
  • Stale indicators: infrastructure rotates, so an old IOC match can point at a shared host or a recycled IP; check the indicator’s age before weighting it.

Deception technologies

Deception answers “is someone exploring where nobody legitimate should be?” Deception platforms (Canary, Proofpoint Identity Threat Defense (formerly Illusive), Commvault ThreatWise (formerly TrapX)) flip the asymmetry. Decoy assets, fake credentials, deceptive files, and simulated services have no legitimate business use; interaction with them is high-confidence evidence of malicious activity.

Products in the C.A.T. glossary: Sandboxes, deception and adversary emulation.

Deception: key capabilities

  • Decoy deployment tailored to mirror the organization’s unique assets.
  • Attack engagement capturing command execution, lateral movement, attacker tools.
  • Alert fidelity very high, because legitimate users have no reason to touch decoys. Expect benign hits from vulnerability scanners, EDR and antivirus sweeps, and backup and inventory tools, and exclude those sources at deployment.
  • Threat-actor profiling via collected behaviors and metadata.

Deception: common limitations

  • Deployment scope matters; sparse coverage lets sophisticated attackers route around the decoys.
  • Operational complexity to avoid disrupting legitimate operations.
  • Alert dependency: deception only fires when attackers engage decoys.
  • Maintenance overhead to keep decoys believable as production evolves.

Digital forensics

Digital forensics answers “what exactly happened on this system, in a form that will hold up?” The tools cover recovery, artifact extraction, timeline reconstruction, and chain-of-custody preservation. At triage depth the common move is targeted collection (for example Velociraptor or KAPE) rather than a full image, and super-timeline tools (Plaso, Timesketch) turn those artifacts into the timeline the correlation page describes. In the tier model this is specialist work, typically owned by Tier 3 or a dedicated forensics function once a case has escalated; the triage analyst’s forensics decision is usually narrower and earlier, preserving the evidence (image before reimage, capture memory before reboot) so that deep analysis stays possible. Preserve before you contain sets the order.

Products in the C.A.T. glossary: Forensics, triage collection and mobile forensics.

Digital forensics: key capabilities

  • Disk and memory analysis recovering deleted content, extracting artifacts, identifying injected DLLs and shellcode.
  • Timeline reconstruction via correlation across system logs, registry, file metadata, user activity.
  • Artifact extraction isolating browser history, auth events, persistence mechanisms.
  • Chain of custody via cryptographic verification and documentation rigorous enough for legal proceedings. Counsel and the forensics team set that bar when a case may go to court; it is not a default the triage queue carries.

Digital forensics: common limitations

  • Resource intensity requires significant computing resources and skilled personnel.
  • Retrospective by nature: built for reconstruction, not real-time detection.
  • Environmental constraints optimized for specific OSes and file systems.
  • Collection can destroy evidence: rebooting, reimaging, or running heavy tools on a live host overwrites memory and timestamps, so preservation comes first.

Sandbox and detonation

A sandbox answers “what does this file or link do when it runs?” Detonation services run a suspicious file or URL inside an instrumented, disposable environment and record everything it does: the process tree it builds, the domains it calls, the files and registry keys it writes. Sandboxing Detonating an unknown file or URL inside an isolated environment to observe what it does. Mature malware checks for sandbox-typical signals (small disk, brief uptime, no mouse activity, suspicious driver names) and stays dormant until it sees a real host. turns “is this attachment malicious?” from a signature lookup into an observed-behavior question, and its report feeds the timeline directly.

Products in the C.A.T. glossary: Sandboxes, deception and adversary emulation.

Sandbox: key capabilities

  • Behavioral verdicts on unknowns: samples with no signature history still reveal themselves by what they do.
  • IOC extraction: C2 domains, dropped-file hashes, and mutex names from the run become pivots back into the environment’s own telemetry.
  • Safe URL analysis for phishing triage without touching the link from a production machine.
  • Report artifacts (process trees, network captures, screenshots) that drop into the investigation record.

Sandbox: common limitations

  • Evasion is a built-in adversary feature: time delays, environment checks, and required user interaction exist precisely to beat detonation.
  • A clean run is weak evidence of benign. It means the sample did nothing in that environment during that window, nothing more.
  • Targeted samples keyed to the victim’s domain, language, or geography may refuse to run anywhere else.
  • Submission constraints: file-type and size limits, and data-handling policies for sensitive documents.
  • OPSEC: search by hash before uploading, and send sensitive or targeted samples only to a private sandbox. A public upload can tip off the adversary and disclose your data.

Vulnerability scanners

Vulnerability A defect in a system that can be turned into adversary capability if paired with an exploit and exposure: an unpatched CVE, a misconfiguration, a default credential, a logic flaw. Vulnerability without exposure or exploitability is latent; with both, it's a finding. scanners answer “was this system exposed to what the attacker used?” They assess systems, applications, and configurations for known weaknesses, so the analyst can check exploitability and correlate vulnerabilities with observed threat activity.

Products in the C.A.T. glossary: Asset inventory, exposure and vulnerability management.

Vulnerability scanner: key capabilities

  • Asset discovery and fingerprinting for comprehensive inventory.
  • Vulnerability identification against CVE databases and misconfiguration checks.
  • Risk scoring and prioritization using CVSS (v4.0 where available) plus exploitation signals (CISA KEV, EPSS) and asset criticality.
  • Remediation tracking via dashboards and verification of applied patches.

Vulnerability scanner: common limitations

  • False positives: common in complex or customized environments.
  • Disruption risk from active scans against sensitive systems.
  • Limited detection of unknowns (zero-days, novel misconfigurations).
  • Uneven freshness: agentless network scans are point-in-time; agent-based assessment is continuous, but only where agents run.

SOAR

SOAR (Security Orchestration, Automation, and Response) answers “what can run the same way every time, so the analyst does not have to?” These platforms wire tools, data sources, and response actions into playbooks, which makes handling faster and repeatable. SOAR platforms increasingly embed LLM agents alongside deterministic playbooks; those agents fall under the admission gate on the AI-assisted triage page.

Market note (2026): Gartner’s 2024 Hype Cycle for Security Operations rated standalone SOAR “obsolete before plateau”. Its playbook and case-management functions increasingly ship inside SIEM and XDR platforms and no-code workflow tools, and AI SOC agents now run many enrichment steps (see AI-assisted triage). The capability matters more than the product category: whatever runs the playbook, its actions belong in the case record.

Products in the C.A.T. glossary: SOAR, case management and automation.

SOAR: key capabilities

  • Playbook automation for triage, enrichment and pre-authorized containment, and for auto-closing known-benign patterns under the governed automation conditions (logged, and still counted toward entity risk).
  • Tool integration aggregating SIEM, EDR, threat intel, ticketing, and network tools.
  • Case management with collaboration, task assignment, and evidence tracking.
  • Real-time response for host isolation, firewall changes, account suspension.

SOAR: common limitations

  • Playbook maintenance burden as tools and processes evolve.
  • Machine closes need governance: a playbook may close a case only when all six conditions hold: a pattern entry flagged for machine close, discriminators evaluated by code, the eligibility gate enforced, human QA sampling, tracked reversal and miss rates, and a tested kill switch with a named owner.
  • Alert fidelity dependency on incoming alert quality.
  • Analyst overreliance risking erosion of situational awareness.

CSPM

Cloud Security Posture Management answers “what could go wrong here?” from configuration. CSPM tools continuously assess AWS, Azure, and GCP environments for misconfigurations, policy violations, and compliance risks across dynamic, multi-account cloud infrastructure.

Market note (2026): CSPM is now commonly sold as one module of a CNAPP (cloud-native application protection platform), which bundles posture (CSPM), workload protection (CWPP), entitlement management (CIEM), and often CDR in one console. The distinction on this page is about the question each capability answers, not the product you bought.

Products in the C.A.T. glossary: Cloud detection, audit and posture.

CSPM: key capabilities

  • Misconfiguration detection across IaC, runtime configs, and account settings.
  • Compliance mapping against CIS Benchmarks and control frameworks such as NIST SP 800-53 and ISO/IEC 27001, with dashboards.
  • IAM analysis highlighting privilege escalation paths and public exposure.
  • Drift detection alerting on unauthorized configuration changes.

CSPM: common limitations

  • Blind spots in proprietary services and ephemeral assets (containers, lambdas).
  • Overwhelm from low-severity issues requiring triage to avoid fatigue.
  • Configuration is not activity: a finding says an exposure existed, not that anyone used it; pair it with CDR or the audit log before it enters the timeline.
  • Cloud-specific tuning as APIs and services differ across providers.

CDR

Cloud Detection and Response answers “what is going wrong right now?” from activity, which CSPM cannot see. Where CSPM reads static configuration, CDR watches the control plane ( AWS CloudTrail Records API activity in an AWS account: the audit trail for security and forensic work. Management events are on by default (90 days in Event history); data events such as S3 object reads and Lambda invokes must be enabled on a trail or event data store. , Azure Activity Log and Entra audit logs, Google Cloud Audit Logs) and workload runtimes for attacks in progress: unusual API sequences, role chaining, containers spawning shells they never spawn.

Products in the C.A.T. glossary: Cloud detection, audit and posture.

CDR: key capabilities

  • Control-plane anomaly detection: API-call sequences, role assumptions, and key usage that break the account’s baseline.
  • Workload runtime sensors for container and serverless behavior that agentless posture tools never see.
  • Identity-to-workload correlation tying a suspicious role session to the resources it actually touched.
  • Cloud-native response: revoke keys and sessions, quarantine workloads, snapshot disks for forensics before the evidence recycles.

CDR: common limitations

  • Ephemeral evidence: the container that ran the payload may be gone in minutes; capture has to be part of the detection path.
  • Provider API coverage gaps in newer or niche services limit what can be observed at all.
  • Multi-cloud inconsistency: detection depth varies by provider, so identical attacks surface differently.
  • Noisy baselines in environments where infrastructure legitimately changes constantly.

CSPM vs CDR in one line

CSPM answers “what could go wrong here?” from configuration. CDR answers “what is going wrong right now?” from activity. An Uncover investigation of a cloud alert usually needs the second and consults the first for context.


Security data lakes

A security data lake answers “what happened months ago, at a volume the SIEM cannot afford to keep?” These are centralized repositories for large volumes of structured and unstructured security data. By consolidating logs, alerts, network flows, endpoint telemetry, and Threat Intelligence Evidence-based knowledge about existing or emerging threats, including context, mechanisms, indicators, implications, and actionable advice (after Gartner's widely cited definition). It is consumed at strategic, operational, and tactical levels. Before acting on it, weigh the source's reliability, the information's credibility (the Admiralty code is one common scheme), and its age. , data lakes enable cross-source correlation and long-term retention for investigations that reach back months.

Products in the C.A.T. glossary: SIEM, log pipelines and security data lakes.

Data lake: key capabilities

  • Scalable ingestion and storage for diverse formats (JSON, CSV, XML, binary).
  • Schema-on-read flexibility without upfront schema definition. Normalization schemas (OCSF, ECS, ASIM, UDM) give the same entity the same field name across sources, which is what makes the join keys on the correlation page work at scale.
  • ML and analytics integration for anomaly detection and behavior modeling.
  • Cross-source correlation across endpoint, network, cloud, and external feeds.
  • Historical retention for retrospective analysis and compliance reporting.

Data lake: common limitations

  • Data normalization challenges requiring engineering resources.
  • Query performance variability without proper indexing.
  • Management complexity for governance, security, access control, cost.
  • Kept is not parsed: raw data that was retained but never normalized cannot join; check that the fields you need were extracted for the period you are querying.

AI assistants and agents

AI assistants and agents answer “what does this mean, and what should I query next?” faster than a person can type it. Most SOC platforms now embed them: they draft summaries, enrich indicators, turn a question into a query, and in agentic form run multi-step enrichment on their own. The methodology treats them as tools under the admission gate on the AI-assisted triage page. Accountability is never delegated. Execution may be, at Level 0 parity. Above that line an assistant is advisory: it drafts and recommends, and an analyst decides. Governing automated triage covers the gate owner’s side.

Products in the C.A.T. glossary: AI assistants and triage agents.

AI assistants: key capabilities

  • Drafting: case summaries, handoff text, and timeline narratives from evidence already gathered.
  • Enrichment at speed: indicator lookups, prevalence checks, and context pulls run in parallel.
  • Query generation: a plain-language question turned into SPL, KQL, or SQL, with the query shown for review.
  • Agentic triage steps: multi-step enrichment that adapts to what the previous step returned.

AI assistants: common limitations

  • Confabulation: a fluent, confident answer can cite a field, event, or join that does not exist; verify every claim against the raw evidence.
  • Prompt-injection exposure: attacker-controlled text (email bodies, filenames, web pages) can steer an assistant that reads it.
  • Silent model changes: a vendor update can change behavior with no version you can pin; re-run your checks after changes.
  • Verification cost: checking an agent’s joins can take as long as running them, so count that time before counting the time saved.

Check an agent's join the way you check XDR's

An agent that reports “these events are related” has made the same claim an XDR stitch makes. Name the join key, check the window, and re-run the decisive query yourself before the claim enters the timeline.


Also in the toolkit

Four more families appear in the worked examples and earn a place in the analyst’s map, even where the methodology covers them as data sources rather than tools:

  • Email security and message trace: gateway verdicts, URL click records, and the trace that says who received what. Two of the four Uncover worked examples pivot through it.
  • Identity provider consoles and sign-in logs: the authoritative record of who authenticated, from where, with what factor, and which session or token resulted.
  • Data loss prevention (DLP): content-aware controls at egress and on the endpoint that answer whether sensitive data left and by which path.
  • SSPM and CASB: SaaS posture management and cloud access security brokers, where consented third-party apps, their scopes, and risky SaaS sessions show up.

Technical details verified . Product names, defaults and retention change; check your own tenant.

Edit this page on GitHub Report a correction