Adjusting default detections
Once you're familiar with Sophos Linux Sensor's (SLS) detections and have successfully added default detections to your environment, you can consider adjusting SLS's default detections to suit your environment. This guide will help you understand the adjustments you can use to do so.
Content groups
SLS detection content is grouped to support high-level management of detection groups (Detection Analytics and Smart Policy). To manage the content groups that can be enabled, the enabled_content_groups
configuration directive can be used in the host's configuration file (/etc/sophos/runtimedetections-rules.yaml
).
The default configuration for enabled_content_groups
is shown below:
enabled_content_groups:
- Detection Analytics
- Smart Policy
- Audit
This configuration enables all detections that are associated with the Detection Analytics and Smart Policy content groups.
Note
Please make sure to include 'Audit' in the message type as in the documentation here.
The grouping of detections is hierarchical, so that all or a subset of detections can be enabled. In the example configuration below, all Smart Policy detections are marked enabled, but only "System Exploitation" is enabled for Detection Analytics:
enabled_content_groups:
- Detection Analytics.System Exploitation
- Smart Policy
- Audit
This configuration effectively disables all Detection Analytics detections that were not related to System Exploitation.
Note
Some detections included in the SLS content package may be disabled by default at the individual detection level. This is due to the potential for the detection to impact performance, or because the detection may carry an increased risk of generating false-positive alerts. If an enabled content group includes one of these detections, that detection won't be enabled by default - it would need to be manually enabled. Further detail regarding configuring individual detections is covered in the following section.
Adjusting individual detections
While Content Groups provide an easy way to turn a group of detections on or off, sometimes a finer-grained approach is needed. SLS supports tuning the attributes of individual detection mechanisms in order to provide granular enable/disable controls, altering the priority of an alert, changing the response action, and more. Common attribute overrides and examples are included below.
Enabling a default-disabled detection
For a list of default-disabled detections, please refer to the List of Detection Categories and their Individual Detections. As one example, the New File Executed in Container
detection is included in SLS content packages, but is disabled by default. The tracking of the file telemetry that supports this detection can have an adverse effect on performance for some systems, hence why you must opt-in to using it.
To enable this detection, the following should be added to the host's configuration file (/etc/sophos/runtimedetections-rules.yaml
).
New File Executed in Container:
enabled: true
This overrides the enabled
attribute of the New File Executed in Container
detection. Restarting the sensor after making this change will enable the New File Executed in Container
detection.
Setting a detection to have a "kill" response
All detections provided by SLS are configured to alert by default, but most detections support additional response actions. A common use case for SLS is to set certain detections to an "enforcing" mode that will kill any processes that violate the detection rules.
For example, the Kernel Exploit
detection is a good candidate for enforcement, as the detection has a very strong degree of certainty (i.e. very low false positive rate). To enable the "enforcing" mode for Kernel Exploit
and kill offending processes in their tracks, override the responseActions
attribute for this detection by placing the following override snippet in the host's configuration file:
Kernel Exploit:
responseActions:
- kill
Restarting the sensor with this configuration will ensure that any processes that violate the Kernel Exploit
detection will be killed if the process generating the detection is still present.
Customizable attributes
Note
Not all properties are customizable as modification of some attributes would fundamentally change the nature of a detection. If the attributes in this list are insufficient for configuring detections, custom policies allow you to create customized detections for your environment. See Creating custom detection policies.
Detection Attribute | Customizable? |
---|---|
policy | no |
enabled | yes |
alertMessage | yes |
comments | yes |
priority | yes |
responseActions | yes |
dryRun | yes |
rules | no |
alertLabels | yes |
additionalCategories | yes |
alertDetail | yes |
contentGroups | yes |
List Attribute | Customizable? |
---|---|
type | no |
description | yes |
list | yes |
Where are detections located?
The SLS packaged content is installed in /var/lib/sophos/content/runtimedetections-content.yaml
, a single content file containing all detections with their default configurations. All of the detections and lists within this file can be overridden with customizations in the host's configuration file - /etc/sophos/runtimedetections-rules.yaml
. While the content file will be updated whenever the SLS content package is upgraded, the host's configuration file won't be modified by a SLS package and will retain any overrides and customizations across SLS content releases.
The location of the content file is controlled with the content_path
configuration directive, which can be applied in the host's configuration file. By default, the value of content_path
is set to /var/lib/sophos/content/runtimedetections-content.yaml
. Setting a custom content_path
will direct the sensor to read content from the specified location.
When a sensor starts up, it reads the packed content and then applies any overrides, the sensor writes a "reference" copy of the merger of the runtimedetections-content.yaml
with the runtimedetections-rules.yaml
to this location: /var/run/sophos/cache_analytics.yaml
. This cache yaml file represents the result of the merger, which you can inspect or save for debugging or auditing purposes.
Advanced configuration: adjusting allowlists and blocklists
For more information on adjusting allowlists and blocklists, see Advanced Topics: Lists.