Dashboard Categories

The seven built-in dashboard categories in Spyderbat: Security, User Tracking, Policy, Operations, Network, Inventory, and Kubernetes. Includes the full list of default cards in each category.

Spyderbat organizes default dashboard cards into seven categories. Each category groups cards by monitoring objective — security detections, user activity, policy violations, network traffic, and so on.

The card selection in each default category is fixed. You can't add, remove, or modify cards in built-in categories. If you need a different set of cards, create a custom dashboard. Users with appropriate permissions can create custom dashboards and organize them into custom categories. See how to create custom dashboards for instructions.

The Security dashboard category showing five cards: Recent Spydertraces with Score > 50, Suppressed Spydertraces, Recently Observed Listening Sockets, Recent Critical and High Severity Security Flags, and Processes Executed Out of /tmp

Security

The Security category surfaces detections and suspicious activity relevant to SecOps workflows. It contains five cards:

  • Recent Spydertraces with Score > 50 — Spydertraces are causal graphs of related activity on a monitored node or container. This card shows traces where the aggregate risk score exceeds 50, indicating a combination of detections worth investigating.

  • Suppressed Spydertraces — Spydertraces that matched a Guardian policy and were suppressed rather than alerted on. Useful for confirming expected behavior is being correctly ignored, or for auditing suppression coverage.

  • Recently Observed Listening Sockets — Open ports and listening sockets across monitored hosts. Exposed services are a common attack surface, particularly when misconfigured or unpatched.

  • Recent (Critical and High Severity) Security Flags — Point-in-time detections generated from MITRE ATT&CK scenarios, Spyderbat's analytics, and any third-party sources you've configured (such as Falco).

  • Processes Executed Out of /tmp — The /tmp directory is world-writable and frequently targeted by malware that needs to write and execute files without requiring elevated permissions.

User tracking

The User Tracking category focuses on interactive user activity, which is often a signal of either legitimate privileged access or an active threat. It contains four cards:

  • Interactive User Spydertraces — Causal traces of activity started by a foreground process under user control in a terminal session.

  • Interactive User Sessions — Interactive processes and the effective users that triggered them.

  • Interactive User Sessions with Privilege Escalation — Interactive sessions where the effective user changed (for example, via sudo or su) at any point in the activity chain.

  • Interactive Shell Inside a Container — An interactive shell in a container is an anti-pattern in production environments. Its presence can indicate unauthorized access or an active intrusion.

Policy

circle-info

This category requires Guardian policies to be configured and active on your monitored workloads. See Guardian policies for setup instructions.

The Policy category shows Guardian findings — deviations from expected behavior as defined by your applied policies. It contains three cards:

  • Container Policy Deviation Spydertraces — Causal traces of activity triggered by a policy violation inside a monitored container.

  • Container Policy Deviation Flags — Individual point-in-time detections from policy violations in containers.

  • Linux Service Policy Deviation Flags — Individual detections from policy violations on Linux VMs, scoped to background services.

Operations

The Operations category currently contains one card:

  • Operations Flags — Infrastructure management and uptime events, such as a pod not running, memory management features being disabled, or critical resource thresholds being exceeded.

Network

The Network category provides visibility into connection activity across monitored hosts. It contains five cards:

  • Long Lived (> 60 mins) Egress Connections — Outbound connections that remain active for more than an hour. Persistent connections to unexpected destinations can indicate beaconing or data staging.

  • Egress Connections with Large (>1MB) Data Transfer — Outbound connections with significant data volume. Useful for detecting accidental or intentional data exfiltration.

  • Cross Machine Connections — Connections between monitored machines. Unusual lateral movement between hosts is a common indicator of compromise.

  • Connections to DNS — DNS activity across monitored hosts. Anomalous DNS queries can indicate command-and-control communication, network reconnaissance, or malware downloads.

  • Connections Initiated by an SSH Process — Outbound SSH connections. While SSH is a legitimate protocol, connections to unexpected destinations or made by unexpected processes are worth reviewing.

Inventory

The Inventory category lists the assets currently observed in your monitoring scope. It contains five cards:

  • Recently Observed Systems — Linux hosts running the Nano Agent.

  • Recently Observed Kubernetes Clusters — Kubernetes clusters within your monitoring scope.

  • Recently Observed Kubernetes Nodes — Nodes across monitored clusters.

  • Recently Observed Pods — Pods across monitored clusters.

  • Recently Observed Containers — Containers across monitored clusters.

Each card links to asset metadata and lets you pivot into activity for that asset within a selected time range. If you deploy the Nano Agent as part of your base image or Kubernetes automation, new machines appear here as soon as they come online. See Nano Agent installation for deployment options.

Kubernetes

The Kubernetes category extends the inventory view with additional resource types and command activity. It contains ten cards:

  • Recently Observed Clusters

  • Recently Observed Kubernetes Nodes

  • Recently Observed Pods

  • Recently Observed Containers

  • Recently Observed Services

  • Recently Observed Deployments

  • Recently Observed Replicasets

  • Recently Observed Daemonsets

  • Executed "Kubectl delete" Commandskubectl delete commands run against monitored clusters within the selected time range.

  • Executed "Kubectl apply" or "Kubectl create" Commandskubectl apply and kubectl create commands run against monitored clusters. Review these to confirm that cluster changes are authorized and expected.

Last updated

Was this helpful?