Getting Started with Automated Response
Summary
Introduction to setting up automated response actions.
Overview
In order to provide customers with resilient defense mechanisms, Sophos Linux Sensor (SLS) Policies can be configured with the ability to dynamically respond to attacks in real-time, effectively disrupting exploitation and preventing damage to your production environment.
For policies covering program behavior, a response action can suspend or kill the offending process. For policies covering containers, a response action can kill the container associated with the alert. For policies covering file activity, a response action can delete the file associated with the alert. Response actions are not available for every policy type. At this time, only one response action per individual policy is supported.
Response actions are set through the policy's responseActions
sub-key. When SLS produces an alert where a response action was taken, the alert's notifications
field will include a new alert notification whose message_fields
detail the response action taken and the status of the response action.
Warning
Configuring automated response lets Sophos Linux Sensor dynamically respond to attacks. This includes options to perform preventative actions such as suspending or killing processes and containers, which can impact host functionality. Sophos strongly recommends testing automated responses using dry runs before turning them on in a production environment. See dry runs.
Prerequisites
In order to enable response actions, SLS must be run in the host's process namespace. If you are running SLS outside a container, no further steps are necessary to enable response actions. Inside a container that is not running in the host's process namespace, not all response actions work or will be available.
Kubernetes
Set the hostPID: true
in your DaemonSet's template spec. See Installation.
Docker
Set --pid="host"
in your docker run
command when starting the SLS container. See Run the Sensor container.
Dry runs
Before enabling automated response, we recommend enabling dry runs to become comfortable with how response actions would impact your environment. For any policy supporting response actions, specify dryRun: true
in its configuration to enable dry runs.
The following example demonstrates this applied to a Program Policy:
Enforced Wget Blocklist:
policy: program
responseActions:
- kill
- alert
dryRun: true
alertMessage: Unauthorized execution of wget
comments: This policy detects and kills instances of wget running
priority: High
enabled: true
rules:
- match programName == "/usr/bin/wget"
- default ignore
The following JSON is a truncated example alert demonstrating a successful "dry run" result:
"notifications": [
{
"timestamp": "2019-04-17T01:48:37.995942203-04:00",
"name": "Enforced Wget Blacklist",
"uuid": "7fe1b7b5-aca0-40e5-a5b8-fc0b6fe55ca9",
"message": "The program \"/usr/bin/wget\" was executed, which violated the \"Enforced Wget Blacklist\" Program Policy.",
"message_fields": {}
},
{
"timestamp": "2019-04-17T01:48:37.995942203-04:00",
"name": "Enforced Wget Blacklist",
"uuid": "7fe1b7b5-aca0-40e5-a5b8-fc0b6fe55ca9",
"message": "Would have taken responseAction: kill",
"message_fields": {
"action_type": "kill",
"action_target_type": "process",
"action_result": "dry run"
}
}
],