> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam/detect-investigate-and-respond-to-threats/investigation-and-response/analyze-and-resolve-cases/analyze-case-details/evidence.md). # Evidence Evidence consists of data generated by different sources to provide the how and why behind an issue. It provides the technical context necessary for effective action and remediation. By mapping these dependencies, you can pinpoint exactly how a threat entered your environment and identify the specific actions taken at each stage of the attack. This insight helps you move beyond seeing what happened to understanding the attacker's path, enabling you to implement more effective containment and remediation strategies. You can view evidence in the **Evidence** section of the case **Overview**, which provides a centralized, schema-based view of technical data and manual notes. You can also see issue specific evidence in the issue card. {% hint style="info" %} ### Note In multi-tenant environments, you can view child tenant evidence directly from a parent tenant for streamlined cross-tenant investigations. {% endhint %} ### **Types of evidence** The type of evidence displayed depends on the problem found and will differ between domain, asset types, scanners, and other parameters. The following is a list of the most common types of evidence: * **Causality chains:** Sequences tracing events from root cause to final activity to identify attacker paths and actions. {% hint style="info" %} ### Tip You can use the causality chain to identify unapproved AI activity, data risks, or malicious AI deployments. For more information, see [Causality view](/cortex-xsiam/detect-investigate-and-respond-to-threats/investigation-and-response/investigate-issues/causality-view.md). {% endhint %} * **Evidence events:** Individual security events that triggered or contributed to the issue. * **Standard evidence:** Engine-generated JSON payloads containing technical details and specific findings (e.g., process command lines, file hashes, or digital signatures). Within certain configuration issues, evidence highlights misconfigurations and often provides the expected configuration values to help you to remediate the issue. * **Timeline-based evidence:** You can mark any timeline record as evidence to centralize findings in the Evidence tab. This includes the following record types: * **System-generated records:** Specific events or signals captured automatically by the security engine. * **Manually created notes:** Your added observations, query results, and uploaded files—such as screenshots, logs, or reports—supporting various formats including images (PNG, JPG, GIF) and text-based files (TXT, CSV, JSON). * **Graph evidence:** Displays an interactive visual map of the connected assets, attributes, and path that triggered the issue. ### **Evidence lifecycle** The evidence lifecycle ensures that technical proof remains accurate and available from the moment an issue is identified until it is resolved and archived: * **Registration and refresh:** Evidence is registered at issue creation and refreshed at the same frequency as the issue to prevent data discrepancies. * **Resolution and retention:** Resolved issues retain a final snapshot of the evidence for auditing and data completeness. Evidence is a snapshot in time reflecting the state at the last update. * **Update behavior:** If a problem is fixed, the last snapshot is preserved; otherwise, evidence continues to update. ### **Using evidence in workflows and automation** Evidence is available for use in automated response and API-based retrieval. #### **Playbooks and quick actions** Use playbooks and quick actions to support your investigation: * **Extract data for logic:** Pull technical details directly into automated enrichment, containment, and decision-making workflows. * **Pass payloads to commands:** Use evidence data as input parameters for system commands to include technical proof in logs or external security tools. * **Filter by evidence type:** Request specific evidence categories to reduce processing overhead for targeted automation tasks. #### **Exporting and programmatic retrieval** You can export and retrieve evidence to support external analysis and compliance using the following methods: * **Direct download:** Manual attachments and files can be downloaded directly for offline use or specialized analysis. * **Table export:** Evidence and events can be exported via TSV or CSV formats from the console tables. #### **Evidence export use cases** Exporting evidence can support your investigation process: * **Confirm detections:** Use technical proof to resolve false-positive disputes and verify findings without manual endpoint logins (CWP). * **Provide audit trails:** Maintain a permanent, immutable record of the technical data and forensic context required for internal and external auditing. * **Support external analysis:** Export data to forensic tools to investigate events from multiple angles and generate post-incident reports. * **Centralize response:** Aggregate evidence across engines for a holistic, case-level view of security investigations. ### **Causality chain evidence** Issues include causality chains if they originate from endpoint data that allows tracking the specific processes. Causality chains are listed according to the Causality Group Owner (CGO), expand the CGO card you want to investigate. Each CGO card displays the CGO name, the following CGO event details, and the causality chain: * CGO name * Issue sources associated with the entire causality chain * Execution time of the causality chain * Number of issues that include the CGO according to severity. Expand the causality chain to further investigate in the full **Causality view**. For more information, see [Causality view](/cortex-xsiam/detect-investigate-and-respond-to-threats/investigation-and-response/investigate-issues/causality-view.md). ### Graph evidence Graph evidence provides a visual representation of interconnected assets, relationships, and findings that trigger a rule condition. Evaluated against the graph-based engine, it shows the exact path, assets, and attributes involved in an issue. #### Attack path vs. graph issues You can view connected asset paths on the interactive graph canvas for both issue types, but they differ based on who created the rule and how the issue is categorized:
* **Attack path issues:** Triggered by Out-of-the-Box (OOTB) Rules. They detail specific exploit trajectories, from entry points to sensitive targets. * **Graph issues:** Triggered by Graph Rules. They visualize cross-domain posture findings, asset dependencies, and custom graph queries. For more information, see [Create a graph rules](/cortex-xsiam/cloud-security/cloud-security-rules-and-policies/create-and-manage-cloud-security-rules/create-a-graph-rule.md). #### Locating & Reviewing Graph Evidence You can find Graph Engine issues in the Issues table using these filters:
* **Issue Domain:** Posture * **Detection Method:** Graph Engine * **Issue Category:** Attack Path (OOTB rules) or Cross Domain Detection (Custom rules)
Inspect evidence in the case's **Evidence** tab or on the Issue card:
* Interactive graph canvas: Select nodes to inspect asset details, metadata, and connected relationships. * Compliance Controls: Details specific configuration failures along the path (displayed only if compliance controls were defined on the rule). Fixing these violations breaks the path and resolves the issue. * Archived assets: If an asset is deleted from the tenant, basic details (Name and Type) remain visible for historical context, but side card drill-downs are disabled. #### Graph issue lifecycle An issue generated by the graph engine is automatically resolved if the corresponding graph route is no longer detected during the next scan cycle or if all assets within the evidence path are deleted. If a previously closed issue path is detected again in a subsequent scan, it is automatically reopened using path hash matching rather than generating a duplicate alert. #### Example The following example shows an attack path issue. n
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam/detect-investigate-and-respond-to-threats/investigation-and-response/analyze-and-resolve-cases/analyze-case-details/evidence.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.