Skip to content

Overview of Sophos Linux Sensor Alerts

This article provides an overview of the different elements within an alert produced by Sophos Linux Sensor (SLS).


The JSON section contains the detailed raw incident alert data. Use the JSON to obtain information about the incident. The raw alert is split into the below categories.

Understanding elements in a JSON alert

The following list explains the purpose of the different fields.

Field Description
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.
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 Sophos 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 won't 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.


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.

Field Description
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.
Back to top