Introduction to Stacked Rulesets


Getting Started with Stacked Rulesets

This article provides a detailed playbook for developing and using Threat Stack's new feature, Stacked Rulesets. The goal of this article is to:

  1. Set expectations on what Stacked Rulesets are, and what they are not. Particularly on how Stacked Rulesets will help Threat Stack customers manage the events and alerts generated by the application.

  2. Provide customers with best practices on how to use Stacked Rulesets to optimize their Threat Stack workflows.

  3. Provide recommend workflows on how to work with the various types of alerts Stacked Rulesets enable.


How to stack rule sets :

  1. Configuration (say you want to add Base Ruleset and Custom Ruleset : cloudsight setup --deploy-key {{key}} --ruleset="Base Rule Set,Custom Ruleset"`
  2. UI:Servers: Server configuration -> assign existing rulesets and add select the rule sets.

What are Stacked Rulesets?

What is it: Stacked Rulesets helps users to apply rule sets (which are groups of rules) to multiple assets. This is a significant enhancement that resolves the previous limitation of only allowing users to apply one rule set / policy to an asset.

How will it help: With Stacked Rulesets, users can not only apply rules (and corresponding suppressions) globally but also surgically apply rules (and corresponding suppressions) locally to specific servers, thereby easily managing the events to get alerted on only events (or group of events) that need action.

What isn’t it?: Stacked Rulesets are not a ‘set it and forget it’ solution for Threat Stack users. Users need to spend some time to understand the events that are coming out of their servers and write rule sets for alerts. The time it would take to develop rule sets is significantly less.

User Goals and Expectations 

The goal of Stacked Rulesets is to enable our users to:

  1. Get alerted when workload processes behave abnormally.
  2. Review alerts and events for user access and actions on servers.
  3. Get alerted on abnormal behaviors of in-bound and out-bound socket connections and corresponding process activity.
  4. Monitor changes and access to sensitive configuration and credential files.

Understanding Severities and Workflows

The following are the definitions of alerts and corresponding user actions

  • Sev 1 - Alerts that the user needs to act on as soon as possible.
  • Sev 2 - Alerts that the user needs to review.
  • Sev 3 - Alerts that need to be triaged.

On-Going Workflow for Alerts :

  • Sev 1 - The user will configure the application to send emails on sev 1 alerts.
  • Sev 2 - The users would review all sev 2 alerts weekly.
  • Sev 3 - The users would review sev 3 alerts on a frequent basis (on the order of couple of hours every week or 20 mins every day) to either completely suppress or ignore them, or make a sev 1 or 2 alert out of them.

The rest of the document will go through best practices, examples, and use cases for developing rule sets.


Best Practices for Developing Rule Sets

Organize Servers and Alerts

The user needs to first organize the servers either by application type or operating system. The goal of this exercise is to group servers by their workload behaviors (process, user, network, and file activity behaviors). The following are examples of server groups.

  • By Application
    • Elastic Search servers
    • Cassandra servers
  • By OS
    • Ubuntu servers
    • Amazon Linux servers

Developing Rule Sets

The goal for the user is to develop two types of rule sets: global rule sets and local rule sets. Global rule sets are groups of rules that apply for most machines in the environment and local rule sets are groups of rules that apply to only specific set of machines, based on the applications or roles of those machines.

General Heuristics for Developing Global and Local Rules

The following are the general heuristics:

  • If the user wants to get alerted on a particular behavior globally, at any place in the environment, include the rule in the global rule set.
  • If a behavior is valid for a particular application only, then the user should include the rule for that behavior in the local rule set.
  • If it’s easy to develop suppression rules for a particular behavior, include it in a global rule.
  • Any alert rule that tries to catch a global behavior should have no contradiction with local behavior. In such cases the user might want to duplicate suppression rules at the global and local level.
  • In general, suppress the behavior that occurs most often and create sev 3 alerts (to review) on behavior that is not occurring frequently.

The following is the summary of guidelines for making global and local rule sets:

Once the user starts developing the preliminary rule sets they can apply multiple global and local rule sets to servers or groups of servers. The users then can continue to add to the rule sets as they learn more about their environments, spotting suspicious process and user behaviors.

The rest of the document goes through examples in detail:

Global Process Rules

Processes making abnormal connections or accepting incoming connections are a typical indication of command and control channels or data leaks. The below set of alerts and corresponding suppressions for known process connecctions are examples of such rules and suppressions.

  • Example for Accepts (sev2): Alert when any process accepts connections other than the below suppressions. Suppression examples are based on processes, users (accepts other than these processes and users), and IP addresses and ports (accepts other than these IP addresses and ports).

  • Binds (sev 2): Alert when any process binds to a port other than the below suppressions. Suppression examples are based on processes, users (accepts other than these processes and users), and IP addresses and ports (accepts other than these IP addresses and ports).

  • Connects (sev 1): This happens when a process connects to another endpoint. Create the rule based on the destination port.

  • connect
  • Kernel modules (Sev 1)

Local Process Rules

Surgical rules based on processes start and stop events would make sense for locally applied rules.

  • Ex - Tell me when mongodb is run by any user other than mongodb

Global User Actions

User actions that need to monitored across all servers, such as

  • User actions without a uuid
  • Root actions on all accounts (sev 3)

Local User Actions

User actions that are applicable for specific set of servers, such as

  • Alert when any user logs into any of the web servers
  • File copy activity
  • User privilege escalations, such as sudo (sev 3)
  • User activity on jump hosts

Global File Rules

Track file activity for files that exists on most servers

  • SSHD configs
  • Global system file

Local File Rules

Use local file rules for application specific stuff such as mongo configuration or chef configuration



Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Article is closed for comments.