Creating custom detection policies
You can create Sophos Linux Sensor (SLS) policies 'from scratch', allowing expert users to craft their policies as they see fit. However, creation of custom policies require expert knowledge of SLS, Linux systems, and Linux security.
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.
Once you've selected your policy type, the next step is to determine whether you prefer to
default match or
default ignore. You must specify a default action before adding custom rules:
|default match||Operates as an allow-list. The policy will alert on all events that meet the behavior criteria, unless the event satisfied a previous ignore rule.|
|default ignore||Operates 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
ignore keyword, followed by predicates combined with event fields. A policy may have any number of
ignore rules. If a policy has multiple rules, SLS evaluates the rules in the order shown beginning from the top of the list.
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 configuration.
For instance, if you know that your developers frequently spawn interactive shells
ssh as part of their work, you should use the
parentProgramName == "ssh" event field plus the
ignore action to ensure your developers' legitimate behaviors don't generate alerts.
Let's walk through a Program Execution Policy configuration to see rule creation in practice. We'll start with the following policy configuration, which will alert on any program executing.
Program Execution Policy Example: policy: program enabled: true alertMessage: Unauthorized Program Executed comments: Example using the program policy priority: High rules: - default match
Let's say we want to only receive alerts on programs named
test.sh, regardless of file path. We would modify the rules to specify that we want to filter
test.sh, and to ignore any programs that don't match that filter:
rules: - match programName == "test.sh" - default ignore
However, let's say we now want to restrict alerts to only trigger when
test.sh is run from the
/tmp/ directory. We would modify our rules to include the path as well:
rules: - match programName == "/tmp/test.sh" - default ignore
Now, we decide we want to alert on any execution that contains the argument "malicious," as well (in the case of not-so-sneaky attackers). We can use the
programArguments event field to indicate we want to see any arguments containing
rules: - match programArguments == "* *malicious*" - match programName == "/tmp/test.sh" - default ignore
Finally, we realize that we also want to ignore any execution that originates from a bash shell, perhaps because we know that there's legitimate bash shell usage within our environment. We can create an
ignore rule, using the
parentProgramName event field and specifying
rules: - ignore parentProgramName == "bash" - match programArguments == "* *malicious*" - match programName == "/tmp/test.sh" and programArguments == "/tmp/test.sh arg1 arg2" - default ignore
Rules are evaluated strictly in the order shown, beginning from the top of the list. Running
ls malicious within a bash shell won't generate an alert. However, if we switched the order of the first two rules, an alert is generated if we run
ls malicious from within a bash shell, as it matches on the
programArguments rule before the
ignore bash rule is applied.
For more information on lists, see Advanced topic: lists.
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 precisely the data needed to conduct your triage and investigations. See Alert configuration templates.
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, quarantining a file, and deleting a file. See Getting started with automated response.
If alert volume is a concern, alert batching may be turned on at a policy level to limit the number of alerts which 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 then emit one batched alert which summarizes all the suppressed alerts.
Continuing with our earlier program policy example - perhaps we find that after deploying it, we have a tool that runs
/tmp/test.sh arg1 arg2 many times in quick succession, resulting in an excess number of alerts. We can use alert batching to group these, reducing the number of alerts produced. Consider the alert batching configuration below:
alertBatching: enabled: true tolerance: 1 duration: 10s
This turns on alert batching as soon as a single match occurs, and will batch all matches in the 10-second window. If we added the above to our Program Execution Policy example, and then ran our
/tmp/test.sh script 20 times within 10 seconds, we'd see two alerts:
- One alert as soon as the first match was seen.
- A second alert at the end of the 10-second window, which would note that the same alert had fired 19 additional times during that window.