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 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 whitelist security model is detected.
Incident Explorer sews these discrete events together to show the progression of a potential attack.
To learn more about the challenges of incident response in cloud native environments, and how Prisma Cloud can help, see this webinar recording.
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.
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
.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 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).
For containers, the following event types can be found in a forensic data set:
- 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.
- Runtime profile — Runtime action was whitelisted 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).
For hosts, Defender collects all raw process events:
- 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.
- Runtime profile — Runtime action was whitelisted 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).
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.
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.
If enabled, you can specify the amout of storage space allocated to each Defender.
At minimum, Defender requires 100 MB for container forensics and 10 MB for host forensics.
You can specify 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 mananges 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.
Note that if you configure to 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.
- Open Console, and go toMonitor > Runtime > Incident Explorer.
- In theActivetab, select an incident.
- Click onView forensic 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 toMonitor > Runtime > Container Models.
- In the table, click the microscope icon for the container of interest.
Events are displayed in a coordinated timeline-table interface.
Viewing host forensic data
To retrieve and view the forensic data for a host:
- Open Console, and go toMonitor > Runtime > Host Models.
- Click theHosttoggle button.
- In the table, click the microscope button for the host of interest.
