Focus

Prisma Cloud Compute Edition Administrator’s Guide

Incident Explorer

Table of Contents

Incident Explorer

Incident Explorer elevates raw audit data to actionable security intelligence, enabling a more rapid and effective response to incidents. Rather than having to manually sift through reams of audit data, Incident Explorer automatically correlates individual events generated by the firewall and runtime sensors to identify unfolding attacks.

Audit events generated as a byproduct of an attack rarely occur in isolation. Attackers might modify a configuration file to open a backdoor, establish a new listener to shovel data out of the environment, run a port scan to map the environment, or download a rootkit to hijack a node. Each of these attacks is made up of a sequence of process, file system, and network events. Prisma Cloud’s runtime sensors generate an audit each time an anomalous event outside the allow-list security model is detected. Incident Explorer sews these discrete events together to show the progression of a potential attack.

Viewing incidents

To view incidents, go to Monitor > Runtime > Incident Explorer
. Click on an incident to examine the events in the kill chain. Clicking on individual events shows more information about what triggered the audit. After you have examined the incident, and have taken any necessary action, you can declutter your workspace by archiving the incident.

Only one incident from the same type (port scanning, altered binary, etc.) will be initiated for the same resource (container, host, etc.) every 24 hours. Further incidents from this type for the same resource will be automatically suppressed for 24 hours.

All the raw audit events that comprise the incident can be found in the audit data tab. To see the individual events and export the data to a CSV file, go to Monitor > Events > {Container audits | Host audits | App-Embedded audits}
.

Incident Explorer is organized to let you quickly access the data you need to investigate an incident. The following diagram shows the contextual data presented with each incident:

(1) Story
— Sequence of audits that triggered the incident.

(2) Image, container, and host reports
— Scan reports for each resource type. Scan reports list vulnerabilities, compliance issues, and so on.

(3) Connections
— Incident-specific radar that shows all connections to/from the container involved in the incident. Its purpose is to help you assess risk by showing you a connection graph for the compromised asset.

(4) Documentation
— Detailed steps for investigating and mitigating every incident type.

(5) Forensics
— Supplemental data collected and stored by Defender to paint a better picture of the events that led to an incident.

Forensics

Prisma Cloud Forensics is a lightweight distributed data recorder that runs alongside all the containers in your environment. Prisma Cloud continuously collects detailed runtime information to help incident response teams understand precisely what happened before, during, and after a breach.

Forensic data consists of additional supplemental runtime events that complement the data (audits) already captured by Prisma Cloud’s runtime sensors. It provides additional context when trying to root cause an incident. Each Defender collects and stores forensic data in a fixed-sized first-in-first-out log file on the host where it runs. Forensic data is only downloaded to Console when it’s needed for an incident investigation. This architecture enables Defender to store large amounts of data without any impact on network bandwidth or server processing (on the host where Console runs).

Forensics data is retrieved:

After Prisma Cloud detects an incident. A minute after an incident occurs, Prisma Cloud collects forensic data from the relevant Defenders, and archives the data in Console. By default, Console stores up to 100 incident snapshots, which are managed on a FIFO basis.

On-demand. Forensics data can be retrieved for review at any time from the Console UI.

Forensics event types

Containers
:

Process spawned — Process was run in the container. Fields: timestamp, container ID, PID, PPID, path, command, arguments.

Container started — Container was started. Fields: timestamp, container ID.

Binary created — Executable file or binary blob was created (file system event). Fields: timestamp, container ID, user, PID, path.

Listening port — Container is listening on a network port. Fields: timestamp, container ID, PID, path to executable that’s listening, listening start time, port.

Connection established — Connection was established (incoming or outgoing) between the container and another entity. Fields: timestamp, container ID, source, destination, destination port.

DNS query — DNS query was sent by the container. Fields: timestamp, container ID, domain name, domain type. Collecting DNS query events for container forensics depends on enabling DNS monitoring in the container runtime policy.

Runtime profile — Runtime action was allowed for the container image while it was in learning mode. Fields: timestamp, container ID, user, PID, PPID, path, command.

Runtime audit — Event occurred in a container that violates your runtime policy (model + runtime rules). Fields: timestamp, container ID, user, audit message, attack type, effect (alert or block).

Incident — Incidents detected in a container that violates your runtime policy. Fields: timestamp, container ID, audit message, Category.

App-Embedded
:

Process spawned — Process was run in the container. Fields: timestamp, PID, PPID, path, command, arguments.

Container started — Container was started. Fields: timestamp.

Binary created — Executable file or binary blob was created (file system event). Fields: timestamp, container ID, user, PID, path.

Listening port — Container is listening on a network port. Fields: timestamp, PID, path to executable that’s listening, listening start time, port.

Connection established — Connection was established (incoming or outgoing) between the container and another entity. Fields: timestamp, source, destination, destination port.

DNS query — DNS query was sent by the container. Fields: timestamp, container ID, domain name.

Runtime audit — Event occurred in a container that violates your runtime policy (runtime rules). Fields: timestamp, user, audit message, attack type, effect (alert or prevent).

Incident — Incident detected in a container that violates your runtime policy. Fields: timestamp, audit message, category.

Hosts
:

Process spawned — Process was run on the host. Fields: timestamp, hostname, path, PID, parent PID, parent path, user, command, interactive (true or false), program name.

Binary created — Executable file or binary blob was created (file system event). Fields: timestamp, app, user, PID, path.

DNS query — DNS query was sent from the host. Fields: timestamp, domain name, domain type. Collecting DNS query events for host forensics depends on enabling DNS monitoring in the host runtime policy.

Runtime profile — Runtime action was allowed for an app while it was in learning mode. Fields: timestamp, app, user, capabilities, command.

Runtime audit — Event occurred in a container that violates your runtime policy (model + runtime rules). Fields: timestamp, app, user, audit message, attack type, effect (alert or block).

Configuring data collection

To configure Forensics, go to Manage > System > Forensics
. By default, forensic data collection is enabled.

With forensic data collection enabled, Defender requires an additional 1 MB of memory and 110 MB of storage space (100 MB for containers forensics and 10 MB for host forensics). If enabled, you can specify the desired amount of storage space allocated to each Defender, see the suggested values below:

Container forensics, 100 MB per Defender

Host forensics, 10 MB per Defender

App-Embedded forensics, 10 MB per Defender. Note that each AWS Fargate task has one Defender that monitors all the task’s containers.

You can specify a minimum of 10 MB and a maximum of 1000 MB for each category.

Several settings dictate what type of data is collected and for how long:

Max number of incident snapshots Console can store
— After an incident occurs, Prisma Cloud collects and saves the relevant forensic data set in Console. To control the amount of data Console stores, Prisma Cloud caps the number of data sets and manages them on a FIFO basis.

Collect network snapshots
— When this option is enabled, the forensic package that you can download from Console includes a netstat-style snapshot of the current connections.

Collect network firewall snapshots
— When this option is enabled, the forensic data includes the Connection established event type, which shows incoming and outgoing connection details, including source IP, destination IP, and destination port.

Viewing forensic data

Forensic data is associated with incidents.

Open Console, and go to Monitor > Runtime > Incident Explorer
.

In the Active
tab, select an incident.

Click on View forensic data
.

If you configure Prisma Cloud to send out alerts on channels, such as email or Slack, when incidents occur, the alert messages will contain a direct link for downloading the forensics data.

Viewing container forensic data

While Incident Explorer presents forensic data relevant to specific incidents, you can also view all available forensic data at anytime outside the scope of an incident.

For containers, forensic data is collected on a per-model basis. To retrieve and review the forensic data for a container:

Open Console, and go to Monitor > Runtime > Container Models
.

In the table, click the microscope icon for the container of interest.