Overview of Capsule8 Alerts

This article provides an overview of the different elements within an alert produced by the Capsule8 sensor. 

Viewing alerts in the Capsule8 Console

When viewing an alert in the Capsule8 Console, you will be presented with the following initial information to when viewing an alert:

Summary: The summary message provides an immediate and high level overview of which policy has been violated and what triggered the alert. 

Location information

Host: Describes general host information used to identify where the policy violation occurred.

• Hostname: The hostname refers to the node hostname and should be used to identify which node the policy violation occurred on.
• IP Addresses: The ip addresses describe the host’s networking interfaces.
• Operating System: The operating system field contains the underlying host’s kernel version.
• Booted: Booted displays how long the host has been running since the last boot.

Container: Contains information on which specific container the policy violation occurred in.

• Image: The image field contains the name of the container image from which the container was created.
• Image ID: The image ID is the image’s SHA256 hash of its corresponding image manifest. 
• Container:  The name of the container responsible for the policy violation.
• Container ID: The unique string associated with the container that is responsible for the policy violation.
• Namespace: The name of the container runtime’s namespace for which the container responsible for the policy violation is in.
• Pod: The name of the pod the container responsible for the policy violation is in.

Process Lineage

Process lineage presents a hierarchical list of Process Information objects for the associated processes which led to the policy violation. The Process Information objects provide the incident responder with the context they need to determine how to proceed with the incident:

• The first/top entry (gray box) in the Process Lineage is the Process Information for the process that caused this alert to be generated.
• Each following entry (gray box) contains the Process Information for the next parent process. This is tracked all the way back to the system init process (PID 1), providing a full history of which users and processes resulted in the alert.

Process Information Fields

• PID: The PID is the unique process ID number associated with the program responsible for the policy violation. This number should be used to identify the specific process. 
• Program: The program field is the name of the program that caused the policy violation.
• Arguments: The arguments field contains any arguments supplied to the process which caused the policy violation.
• Working Directory: The working directory for the program causing the policy violation.
• User: The user ID(UID) and username associated with the program responsible for the policy violation. The UID can be used to identify the owner of the process and determine what permissions the process has.
• Group: The group ID(GID) and group name associated with the program responsible for the policy violation. The GID can be used to identify the process group and determine what permissions the process has.

JSON

The JSON section contains the detailed raw incident alert data with additional fields not displayed in the immediate console dashboard. Use the JSON to obtain any additional information about the incident. The raw alert is split into the below categories.

Understanding elements in a JSON alert

Only a subset of the fields in an alert are used when representing alerts in the Capsule8 Console. The following list explains the purpose of the different fields.

• uuid: The alert-specific unique identifier.
• scope: The scope is intended to identify the "blast radius" of an attack, which aims to act as guidance for the amount of remediation or forensic response required. It can be: Process, RootProcess, Container, Node, and Other.
  • Process: Exploitation involving non-root processes.
  • RootProcess: Exploitation involving root processes.
  • Container: Exploitation affecting the whole container.
  • Node: Exploitation affecting the whole node (usually kernel-level).
• lineage: As described in the above section on lineage, this field contains a list of all the process events which lead to the policy violation.
• comments: A description of the policy that caused this alert. This field can be manually overridden in the policy definition.
• location: The location field is a dictionary containing information about where the alert came from. The field contains: image_id, node_name, sensor_id, image_name, container_id, container_name, kubernetes_pod, kubernetes_namespace. This is useful in an investigation because you can trace to the alert back to the exact container, node, or pod that it came from which minimizes unnecessary probing if you're deployed across multiple containers/nodes/pods.
• metadata: the metadata field is a dictionary containing the system metadata from the alerting process’ host.
• priority: The alert priority. Can be: High, Medium, Low, Info.
• timestamp: The Unix timestamp for when the alert was generated. Useful for determining when a policy violation occurred.
• categories: This field is a list containing the Capsule8 and MITRE categories this alert belongs to. This is useful for determining how to classify a policy violation.
• confidence: The confidence the alert is not a false positive. Can be: High, Medium, Low.
• description: The high-level alert message or title of the alert.
• incident_id: Unique incident id number. All alerts that contribute to the same incident will have the same incident_id.
• policy_type: Specifies the type of policy that was violated.
• alert_labels: Alert labels can be added in a policy definition. They allow the user to add a label and a description to more efficiently search for alerts.
• matched_rule: The policy rule that was matched that caused the alert. This is useful in an investigation in case you have many rules configured, this shows the rule that is enabled which caused the alert to be triggered.
• process_info: A dictionary of values containing information about the process that generated the alert. This is useful for gathering more context around the offending process. Note that process_info fields will not be present for alerts for which there is no associated process.
• strategy_name: The name of the policy that was violated.
• alert_group_id: The alert group to which this alert belongs, in case alert grouping is performed.
• audit_group_id: The audit alert group to which this alert belongs, in case audit grouping is performed.
• matched_objects: A list of objects that were matched in the rule that caused the alert. Empty in the case of `default match`. For example, it could contain `matched_value` which could be a path to a suspicious program being run that triggered the alert.

Notifications

The information in the notifications field contains more detailed information about what action was taken and when. In the case of a default alert notification, this is the initial reason that an alert was created.

• name: The name of the policy that had been violated.
• uuid: Notification-specific unique identifier
• message: The message text of the notification, most commonly for describing the specific details of an alert.
• timestamp: The Unix timestamp for when the policy violation occurred.
• message_fields: A dictionary of information containing the recorded information which led to the violation.