Overview of Sophos Linux Sensor Alerts

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

JSON

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 full extent of an attack and acts 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 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. For example, it could contain `matched_value` which could be a path to a suspicious program being run that triggered the alert. In the case of `default match`, this will be empty. See Creating custom detection policies.

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 event that triggered the alert.

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.