Capsule8 Docs
Capsule8 Docs
Help

Configuring Strategies

Strategies can be configured based on your environment and risk profile. You can change the strategy’s rules to precisely specify what events trigger alerts by customizing the type of action and event fields, with the ability to define lists for even greater control. Each strategy’s generated alert output is also configurable, as is the ability to enable automated responses to take specific action upon detection.

Configuring Strategy Rules

To begin, start by selecting what type of strategy you want to configure. We recommend exploring strategies by Capsule8 category or MITRE ATT&CK category to determine what behavior you want to monitor at which point of the attack lifecycle.

Rule Actions

Once you’ve selected your strategy 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 a whitelist. The strategy will alert on all events that meet the behavior criteria, unless the event satisfied a previous ignore rule.
default ignore Operates as a blacklist. The strategy 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 strategy may have any number of match or ignore rules. If a strategy has multiple rules, all rules are evaluated in order beginning from the top of the list.

Event Fields

Each strategy 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 strategy’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 Strategy to see rule creation in practice. We will start with the following strategy configuration, which will alert on any program executing.

Program Execution Strategy Example:
  policy: program
  enabled: true
  alertMessage: Unauthorized Program Executed
  comments: Example strategy 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 filepath. 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 like ".*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 like ".*malicious.*"
    - match programName == "/tmp/test.sh" and programArguments == "/tmp/test.sh arg1 arg2"
    - default ignore

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

Strategy rules can use lists for even more control over when and how alerts should be fired. Lists are particularly useful for configuring strategies to blacklist or whitelist certain behavior. Capsule8 supports four data types for lists: names, hosts, paths, and numbers (along with an experimental lineage type).

Alerts

Each strategy’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 strategy 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. We recommend enabling dry runs to gain confidence in your strategy’s automated responses before enabling actions to be taken on your systems.