Appearance
Understanding Policies
Policies are the foundation of compliance management in AttackLens. A policy defines a set of security requirements that your assets must satisfy, organized into logical sections and backed by automated rulesets.
What Is a Policy?
A policy is a structured document that groups related security checks (rulesets) under a common compliance objective. Each policy targets a specific framework, standard, or internal security requirement, and evaluates your assets against the rules it contains.
For example, an "ISO 27001 Access Control" policy might contain rulesets that verify password complexity, multi-factor authentication enforcement, and session timeout configurations across all your servers.
When AttackLens evaluates a policy against an asset, it produces findings: one for each ruleset check: that record whether the asset passed or failed each requirement.
Policy Structure
A policy in AttackLens has the following components:
| Component | Description |
|---|---|
| Name | A descriptive title for the policy (e.g., "GDPR Data Protection Controls") |
| Description | An explanation of what the policy covers and its purpose |
| Active / Inactive | Whether the policy is currently being evaluated |
| Prerequisites | Conditions checked against inventory data before the policy runs (e.g., "only evaluate Linux servers") |
| Sections | Hierarchical groupings of rulesets that organize the policy into logical areas |
| Version | An auto-incremented version number tracking changes to the policy |
Sections
Sections provide organizational structure within a policy. Each section has:
- A title and optional description
- A key (auto-generated slug used internally)
- One or more rulesets assigned to it
- Optional child sections for deeper nesting
For example, an ISO 27001 policy might have sections like "A.9 Access Control", with child sections "A.9.1 Business Requirements" and "A.9.2 User Access Management", each containing the relevant rulesets.
Prerequisites
Prerequisites are conditions that must be true before a policy is evaluated on an asset. They use the same check node structure as rulesets and operate against inventory data.
INFO
If no prerequisites are defined, the policy runs on all targeted assets. Prerequisites are useful for restricting evaluation to specific operating systems, software configurations, or asset categories.
Built-in vs Custom Policies
AttackLens ships with built-in policies that cover major compliance frameworks:
- GDPR: General Data Protection Regulation
- ISO 27001: Information Security Management System
- SOC 2: Service Organization Control Type 2
- CIS Benchmarks: Center for Internet Security Benchmarks
- NIST CSF: Cybersecurity Framework
- PCI DSS: Payment Card Industry Data Security Standard
Built-in policies are marked as Read-only and cannot be edited or deleted. They are automatically updated through the feed system. To customize a built-in policy, use the Clone action to create an editable copy.
Custom policies are policies you create from scratch. You have full control over their structure, rulesets, prerequisites, and lifecycle.
How Policy Evaluation Works
Policy evaluation follows this sequence:
- Prerequisite check: AttackLens checks whether the target asset meets the policy's prerequisites using inventory data. If prerequisites are not met, the policy is skipped for that asset.
- Ruleset evaluation: Each ruleset in the policy's sections is evaluated against the asset's inventory data. The ruleset's own prerequisites and applicability conditions are checked first.
- Finding creation: For each ruleset evaluated, a finding is created or updated with the result: Pass, Fail, or Error.
- Posture scoring: AttackLens calculates a posture score (percentage of passing rules) for the asset against this policy.
TIP
Evaluation runs automatically when new inventory data is collected by sensors or adapters. You can also trigger evaluation manually from the policy status page.
Policy Lifecycle
| State | Description |
|---|---|
| Active | The policy is included in posture evaluations. New findings are generated when inventory changes. |
| Inactive | The policy is excluded from evaluations. Existing findings remain but are not updated. |
Deactivating a policy does not delete its historical findings. You can reactivate it at any time to resume evaluation.
Compliance Frameworks
Policies map directly to compliance frameworks. A single framework may be covered by one or more policies, depending on how you organize your controls.
WARNING
Built-in framework policies provide broad coverage but may not satisfy every requirement of a given standard. Review your organization's specific compliance obligations and create custom policies to fill any gaps.
Related Pages
- Create a Policy: Step-by-step guide to creating a new policy
- Manage Policies: View, edit, delete, and manage policy lifecycle
- Evaluate a Policy: Trigger evaluation and review results
- Policy Status: Understand the policy status dashboard
- Understanding Rulesets: Learn about the rulesets that power policies
- Understanding Findings: Learn about evaluation results