Capsule8 policies may be created ‘from scratch’, allowing experts to craft their policies as they see fit. However creation of custom policies require expert knowledge of Capsule8 Protect, linux systems, and linux security. Capsule8 has created a ‘Capsule8 Strategy Guide’ which is a reference for access to the ‘atomic’ elements that Capsule8 calls strategies. Please contact your Capsule8 technical representative for a copy.
Configuring Policy Rules
To begin, start by selecting what type of policy you want to configure. We recommend exploring policies by Capsule8 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, 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:
action | description |
---|---|
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 will not 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, all rules are evaluated in order beginning from the top of the list.
Event Fields
Each policy has its own set of valid event fields, which can include 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 using the program ssh
as part of their work, you should use the parentProgramName == "ssh"
event field plus the ignore
action to ensure alerts aren’t generated by your developers’ legitimate behaviors.
Example
Let’s walk through the configuration of a Program Execution Policy to see rule creation in practice. We will 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 programName
for 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 case of not-so-sneaky attackers). We can use the programArguments
event field to indicate we want to see any arguments containing *malicious*
.
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 is legitimate bash shell usage within our environment. We can create an ignore
rule, using the parentProgramName
event field and specifying bash
:
rules: - ignore parentProgramName == "bash" - match programArguments == "* *malicious*" - match programName == "/tmp/test.sh" and programArguments == "/tmp/test.sh arg1 arg2" - default ignore
Rules are evaluated in strict order from from top to bottom. If we execute ls malicious
within a bash shell, an alert will not be generated. However, if we switched the order of the first two rules, an alert would be generated if we executed ls malicious
from within a bash shell, as it would match
on the programArguments
rule before the ignore
bash rule was applied.
Lists
For more information on lists, see here.
Alerts
Each policy’s generated alerts can be configured 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.
Automated Responses
Each policy can be configured 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. More detail on configuring automated response is available at Getting started with automated response.
Alert Batching
/tmp/test.sh arg1 arg2
many times in quick succession, and this is resulting in an excess of alerts. We can use alert batching to group these together, 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 would 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.
Comments
0 comments
Please sign in to leave a comment.