Monitoring your systems for unwanted activity requires defining the unwanted activity. Capsule8’s strategies provide you with deep insight into your systems’ behaviors, from program monitoring detecting exploitation attempts to granular policy enforcement based on program, user, network, or file activity.
Once a strategy is created, it will begin generating alerts when it encounters system activity violating its specified configuration. You can also output alerts for your team to digest into third party services (e.g. SIEMs, Slack, or PagerDuty), or other custom endpoints via Webhooks.
Triggered strategies can also take automated response actions, which can shut down unwanted activity as soon as it is detected. These actions will also appear in the alert details for a triggered strategy.
Get started with Capsule8 strategies:
- Configure your strategies
- Set up your strategies to send custom alerts
- Add automated response actions to strategies
|Strategy||An “engine” that monitors for a subset of system behavior. These can be thought of as core detection and analysis mechanisms - the system behavior you want to monitor.|
|Strategy Type||The name of an underlying strategy, for use when configuring strategy instances. This has previously also been known as a policy type.|
|Strategy Instance||An instance of a strategy comprised of rules and any strategy-specific parameters. Instances determine how that data collected and analyzed by a strategy should be acted upon. Multiple instances can exist for a given strategy.|
|Strategy Category||The high-level category/categories, based on MITRE’s ATT&CK framework, in which a strategy falls. This helps inform detection coverage across the attack lifecycle.|
|Rules||Each strategy exposes a set of valid fields that can be used for the construction of higher-level rules in strategy instances. In each strategy instance definition, the rules define how an alert will be generated upon the receipt of an event.|
|Alert Label||Alert labels are user-defined labels for a strategy that will be propagated to any alerts generated by the strategy. An alert label is a key-value pair and a strategy may define any number of labels.|
Capsule8 provides monitoring capabilities through modular components called strategies. We call them strategies because they work towards specific detection goals rather than detecting specific vulnerabilities or exploits – covering attack categories and entire vulnerability classes by detecting the low-level behaviors required to carry out an exploit or other security violation.
Strategies are designed to provide diverse, overlapping layers of system security monitoring to cover the many facets of an attack. Use our default strategies to begin your monitoring journey, or configure strategies to meet your specific needs, such as for file integrity monitoring (FIM), access control, or other policies to preserve the health of your Linux production environment.
How strategies work
- Define a strategy category and set of rules for the strategy (in a YAML configuration file)
- Monitoring begins on a certain set of behaviors based on the strategy configuration
- Alerts are generated if any behaviors violate the configured rules (one alert per violation)
Let’s walk through an example of creating a strategy to detect any interactive shell started by
sshd (the OpenSSH daemon).
Pick a name for your strategy instance. Let’s call this one
SSH Audit Trail. This will be the top-level element for the YAML snippet we’re creating.
Define the strategy type. In this case, we want to configure an interactive shell strategy, so we would use the directive
Strategy instances can be toggled off-and-on with the
enabledboolean keyword - so lets set
enabled: trueto ensure that our new policy will be used.
Create the rules for the strategy instance. Because we want to alert on shells started by
sshd, we need to specify
sshdas the parent program. We also want to ensure that only shells spawned by
sshdgenerate alerts, meaning we want to ignore shells generated by any other programs. This is what such a rule set would look like:
rules: - match parentProgramName == "/usr/sbin/sshd" - default ignore
Specify the priority level of the alert. In this case, we will define it as
priority: Low- administrators log into hosts regularly, so we don’t want to cause huge alarm every time they do so.
Create a message to describe the alert that would be generated, such as
alertMessage: SSH Session Started.
Finally, there’s a field for you to leave comments about the strategy instance. These comments will be sent with every alert by default, and they can provide some context for the team or process consuming alerts. For our example, lets go with
comments: Alerts whenever a new interactive shell is started by SSH, for audit purposes.
All together, our brand new strategy instance appears as follows:
SSH Audit Trail: policy: interactiveShell enabled: true alertMessage: SSH Session Started priority: Low rules: - match parentProgramName == "/usr/sbin/sshd" - default ignore comments: Alerts whenever a new interactive shell is started by SSHD, for audit purposes
Create multiple strategies of the same policy type to get granular control of alerts – ensuring all potential system contexts are covered. For example, an unexpected outbound connection to an internal subnet could raise a lower-priority alert than an outbound connection to an unknown host on the internet. You could also create a different version of the SSH Audit Trail policy that raises a high-priority alert if a privileged user (e.g.
root) logs in via SSH - a bad practice that often violates an organization’s security directives.