Creating custom detection policies

You can create custom policies for Sophos Linux Sensor (SLS). This allows expert users to adjust detections to suit their environment.

Before you start

The SLS content package is installed in /var/lib/sophos/content/runtimedetections-content.yaml, a single content file containing all detections with their default configurations. We don't recommend changing the contents of this file because it's overwritten when you update the content package.

You can create custom detections and lists by creating and editing the /etc/sophos/runtimedetections-rules.yaml configuration file. When the content package is updated, /var/lib/sophos/content/runtimedetections-content.yaml is overwritten but /etc/sophos/runtimedetections-rules.yaml is not. This keeps any custom detection content you've created for your environment.

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.

Configuring policy rules

Start by selecting what type of policy you want to configure. We recommend exploring policies by Alert category or MITRE ATT&CK category to determine what behavior you want to monitor at which point of the attack life-cycle.

Rule actions

Once you've selected your policy type, You must specify a default action before adding custom rules. You can select default match or default ignore:

• default match: Acts as an allow list. The policy alerts on all events that meet the behavior criteria unless the event satisfied a previous ignore rule.
• default ignore: Acts as a block list. The policy won't alert on any events that meet the behavior criteria unless the event satisfied a previous match rule.

Custom rules begin with either the match or ignore keyword, followed by predicates combined with event fields. A policy may have any number of match or ignore rules. If a policy has multiple rules, SLS evaluates the rules in the order shown starting from the top of the list.

Event fields

Each policy has its own set of valid event fields, including metadata related to containers, images, programs, ports, files, users, groups, and more. When deciding which event fields to include from the policy's range of valid event fields, we recommend starting with basic "known good" or "known bad" resources so you can become more familiar with configuring them.

For example, if you know that your developers frequently spawn interactive shells ssh as part of their work, you can use the parentProgramName == "ssh" event field plus the ignore action to ensure your developers' legitimate behaviors don't generate alerts.

Example

Here's an example of a Program Execution Policy configuration so you can see rule creation in practice. Start with the following policy configuration, which will generate an alert for any program that starts.

Program Execution Policy Example:
  policy: program
  enabled: true
  alertMessage: Unauthorized Program Executed
  comments: Example using the program policy
  priority: High
  rules:
    - default match

That will generate many alerts. Limiting the alerts to specific programs is best. You can change the rules to specify that you want to filter programName for test.sh, regardless of the file path, and ignore any programs that don't match that filter. See the following example.

rules:
  - match programName == "test.sh"
  - default ignore

If you want to restrict alerts to only trigger when test.sh is run from the /tmp/ directory, you can change your rules to include the path as well. See the following example.

rules:
  - match programName == "/tmp/test.sh"
  - default ignore

You can further change the rules to alert when a program starts with certain arguments. In this case, you can use *malicious* as an argument. Add the programArguments event field and update it to alert when /tmp/test.sh starts with the argument *malicious*.

rules:
  - match programArguments == "* *malicious*"
  - match programName == "/tmp/test.sh"
  - default ignore

You may also want to ignore any program that originates from a Bash shell because you know there's legitimate Bash shell usage in your environment. You can create an ignore rule using the parentProgramName event field and specify bash.

rules:
  - ignore parentProgramName == "bash"
  - match programArguments == "* *malicious*"
  - match programName == "/tmp/test.sh" and programArguments == "/tmp/test.sh arg1 arg2"
  - default ignore

SLS evaluates rules in the order shown, starting at the top of the list. Running ls malicious within a Bash shell won't generate an alert. However, if you switch the order of the first two rules, SLS will generate an alert if ls malicious is run from within a Bash shell, as it matches the programArguments rule before the ignore Bash rule.

Lists

For more information on lists, see Advanced topic: lists.

Alerts

You can configure each policy's generated alerts using alert templates to contain specific or custom information. For teams with established processes, alert customization helps you receive only the data needed to conduct your triage and investigations. See Alert configuration templates.

Automated responses

You can configure each policy to trigger automated responses upon alert. Valid automated response actions include stopping a process, killing a process, killing a container, and deleting a file. See Getting started with automated response.

Alert batching

If alert volume is a concern, alert batching may be turned on at a policy level to limit the number of alerts a policy may emit within a given time frame. A policy may specify a tolerance and duration for alert batching, and the number of alerts generated by that policy within that duration won't exceed the given tolerance. Once the duration expires, the policy will emit one batched alert summarizing all the suppressed alerts.

Continuing the earlier program policy example, perhaps we have a tool that runs /tmp/test.sh arg1 arg2 often in quick succession, resulting in excessive alerts. We can use alert batching to group these, reducing the number of alerts produced. Consider adding alert batching to your configuration. Alert batching starts when a single match occurs and combines all matches in the 10-second window. Add the following example to your Program Execution Policy and run the /tmp/test.sh script 20 times in 10 seconds.

alertBatching:
  enabled: true
  tolerance: 1
  duration: 10s

You see only two alerts: one when the first match occurs and a second at the end of the 10-second window, which notes that the same alert was triggered 19 more times within that time window.

More resources

• Adjusting individual detections
• Download a custom profile from Sophos Central