Alert Configuration Overview

Sophos Linux Sensor (SLS) lets you decide which data best serves your workflows. As such, we support custom formatting of Alerts through Alert Templates.

Default alert formatting

By default, Alerts are UTF-8 encoded JSON strings that are newline-delimited. They arrive one at a time, regardless of the output destination. For example, stdout, webhook, and so on.

Default limits

It's important to note that some log ingestion systems, such as Splunk, ELK, and syslog, have default limits on the number of bytes that a single log entry can contain. In some cases, truncated alerts can lead to alerts appearing on multiple lines or not being parsed correctly as valid JSON.

It's possible to ingest a smaller Alert by turning off certain Alert information or ingesting only a portion of the Alert to work around these limits. You can do this by setting the configuration of features like process lineage or cloud metadata to "off," by the post-processing of Alerts written to a blob storage bucket with a cloud function, or using Alert Templates to alert the Alert format from within SLS itself.

Metadata

Alerts contain a metadata field with information about the node on which SLS was running, such as the hostname and OS.

In many cloud environments, you can enrich this field with optional instance metadata from the instance's local metadata service. These services are local HTTP servers that return information about the running instance. For more information about these services, see the following pages:

To configure the cloud metadata feature, run the sensor with the CLOUD_META environment variable or set the cloud_meta key in the runtimedetections.yaml config file based on your platform:

AWSGCPAzureVMWare

For AWS, set cloud_meta to auto, ec2, or ec2_with_tags. If you set ec2_with_tags, it also retrieves the EC2 tags for the instance running the sensor but requires you to set ec2:DescribeTags for this instance.

For GCP, set cloud_meta to auto, gcp, or gcp_with_labels. If you set gcp_with_labels, it also retrieves the compute instance labels but requires you to set a role with the compute.instances.get permission.

For Azure, set cloud_meta to azure. Azure automatically gathers instance tags and requires no additional permissions.

For VMWare vSphere, set cloud_meta to vmware. The sensor retrieves the VM UUID and shows it in the metadata as node_uuid.

Timeout

SLS attempts to gather metadata from cloud environments for a short time before timing out. If SLS can't gather metadata, it still logs events and generates alerts without the optional metadata fields. You'll also see a warning message in the logs.

Example

5       [2024-11-06T13:06:20.568Z]   DEBUG [0000000000] runtimedetections <> cloud_meta set to auto 
5       [2024-11-06T13:06:20.568Z]    INFO [0000000000] runtimedetections <> fetching metadata 
5       [2024-11-06T13:06:20.568Z]   DEBUG [0000000000] runtimedetections <> determining run mode 
5       [2024-11-06T13:06:20.568Z]   DEBUG [0000000000] runtimedetections <> fetching labels metadata 
5       [2024-11-06T13:06:20.568Z]   DEBUG [0000000000] runtimedetections <> fetching network metadata 
6       [2024-11-06T13:06:20.568Z]   DEBUG [0000000000] runtimedetections <> fetching host metadata 
6       [2024-11-06T13:06:20.568Z]    WARN [0000000000] runtimedetections <> Timed out gathering optional metadata, some optional metadata won't be available
6       [2024-11-06T13:06:20.568Z]    INFO [0000000000] runtimedetections <> fetched metadata

You can adjust the timeout value by changing the optional_metadata_gathering_timeout value in the runtimedetections.yaml config file. This sets the metadata timeout value for all cloud environments in seconds. The default is 15 seconds.

Example

send_labs_telemetry: true
# Set your customer id:
customer_id: "unique_sophos_central_id"
endpoint_telemetry_enabled: true
alert_output:
outputs:
- type: stdout
    enabled: true
    template: 'Alert triggered: {{ .StrategyName}}'
- type: file
    enabled: true
    name: /var/log/sophos-alerts.json

debug: false

cloud_meta: auto
optional_metadata_gathering_timeout: 5s

Process lineage

Alerts contain a lineage field with the full process lineage of the process that triggered the Alert going back to the process that launched that process.

The process lineage often ends with an init process or system, such as systemd or dockerd. This can be useful for creating fine-grained allow lists and block lists.

While process lineage details provide useful context, they can considerably increase the size of an Alert. To turn it off, set the RUNTIMEDETECTIONS_PROCESS_LINEAGE_IN_ALERT environment variable to false or add process_lineage_in_alert: false to the runtimedetections-rules.yaml config file.

Removing Process Lineage

If you don't want process lineage in standard JSON Alerts, you can turn it off by setting the RUNTIMEDETECTIONS_PROCESS_LINEAGE_IN_ALERT environment variable to false, or by adding process_lineage_in_alert: false to your runtimedetections-rules.yaml config file.