Understanding Rulesets

Rulesets are the building blocks of policy evaluation in AttackLens. Each ruleset defines one or more security checks that verify whether an asset meets a specific requirement.

What Is a Ruleset?

A ruleset is a reusable, self-contained set of checks that evaluates a specific security configuration on an asset. Rulesets are assigned to policies and produce findings when evaluated.

For example, a ruleset titled "Ensure password minimum length is configured" might check that the minLen property in the SecurityPolicy inventory dataset is greater than or equal to 14.

Ruleset Structure

A ruleset contains the following components:

Component	Description
Title	A descriptive name for the ruleset (e.g., "Ensure SSH root login is disabled")
Description	Detailed explanation of what this ruleset checks and why
Impact	Description of the security impact if this check fails
Solution	Recommended remediation steps to resolve a failing check
Rule Type	The evaluation mode: Automated, Hybrid, or Manual
Active / Inactive	Whether the ruleset is currently evaluated
Tags	Labels for categorization and filtering (e.g., "ssh", "access-control", "cis-benchmark")
References	External URLs or document references (e.g., CIS Benchmark section numbers, NIST controls)
Variables	Named parameters that can be used within check expressions
Prerequisites	Conditions that must be true before the ruleset is evaluated
Checks	The actual security checks that produce Pass/Fail/Error results

Rule Types

Type	Description
Automated	Fully automated evaluation using inventory data collected by sensors or adapters. No manual intervention required.
Hybrid	Partially automated. Some checks run automatically, but the final determination may require human review.
Manual	Requires manual evaluation by a security analyst. AttackLens tracks the finding but does not automatically determine the result.

INFO

The rule type is shown in the ruleset list as a tag next to each entry. Most built-in rulesets are Automated.

Built-in vs Custom Rulesets

Built-in Rulesets

AttackLens delivers built-in rulesets through the feed system. These are maintained by AttackLens and automatically updated when new versions are available. Built-in rulesets cover common security benchmarks and compliance requirements.

Custom Rulesets

You can create custom rulesets to check organization-specific requirements. Custom rulesets have full flexibility: you define the checks, prerequisites, variables, and metadata.

Checks (The Evaluation Logic)

Checks are the core of a ruleset. Each check defines a specific condition to evaluate against an asset's inventory data.

Check Node Structure

A check node contains:

Field	Description
Title	A description of what this individual check verifies
Dataset Type	The inventory dataset to evaluate (e.g., SecurityPolicy, InstalledPackage, RunningService)
Resource Type	Alternatively, a cloud resource type for adapter-collected data
Filter	Optional filter to narrow the dataset records (e.g., only records matching a specific key)
Property Path	The specific property within the dataset to evaluate (e.g., normalizedData.minLen)
Operator	The comparison operator
Expected Value	The value the property must match

Comparison Operators

Operator	Description	Example
equals	Exact match	Password length equals 14
notEquals	Does not match	Root login not equals "yes"
contains	String contains	Cipher list contains "aes256"
notContains	String does not contain	Config does not contain "disable"
greaterThan	Numeric comparison	Min password length greater than 8
greaterThanOrEqual	Numeric comparison	Max login attempts >= 5
lessThan	Numeric comparison	Session timeout less than 900
lessThanOrEqual	Numeric comparison	Password age <= 90
exists	Property is present	MFA configuration exists
notExists	Property is absent	Default password not exists
matches	Regular expression match	Hostname matches pattern
in	Value is in a set	Protocol in ["TLS1.2", "TLS1.3"]
notIn	Value is not in a set	Cipher not in deprecated list

Condition Nodes (AND/OR Logic)

Checks can be combined using logical condition nodes:

• AND: All child checks must pass for the condition to pass
• OR: At least one child check must pass for the condition to pass

Condition nodes can be nested to create complex evaluation logic.

AND
  Check: SSH protocol version equals 2
  OR
    Check: SSH cipher contains "aes256-ctr"
    Check: SSH cipher contains "aes256-gcm"
  Check: SSH root login equals "no"

Prerequisites

Prerequisites are conditions evaluated before the ruleset's checks. If prerequisites are not met, the ruleset is skipped for that asset (no finding is generated).

Prerequisites use the same check node structure as checks. Common use cases:

• OS family check: Only evaluate on Linux or Windows
• Software presence check: Only evaluate if a specific service is installed
• Resource type check: Only evaluate on specific cloud resource types

TIP

Use prerequisites to prevent false positives. A ruleset checking SSH configuration should have a prerequisite verifying that SSH is installed on the target asset.

Variables

Variables allow you to parameterize checks. Instead of hardcoding expected values, you can define named variables and reference them in check expressions.

Field	Description
Name	The variable identifier (e.g., min_password_length)
Type	The data type: string, bool, int, float, or entry
Value	The default value for this variable

Variables make rulesets more reusable. You can clone a ruleset and adjust variable values without modifying the check logic.

Evaluation Engine Types

The ruleset list shows Rule Types tags indicating which evaluation engines the ruleset uses. These are determined automatically based on the dataset types and operators used in the checks.

Related Pages

• Create a Ruleset: Step-by-step guide to creating a custom ruleset
• Manage Rulesets: View, edit, and manage ruleset lifecycle
• Understanding Policies: How policies use rulesets
• Understanding Findings: Evaluation results from rulesets