Skip to Content

Policies

Policies are custom IF-THEN rules that monitor your attack surface for specific changes and trigger actions when conditions are met. Use policies to enforce security standards, detect unexpected changes, and route alerts to the right teams.

How Policies Work

Each policy consists of a trigger condition and one or more actions. When Surface Monitoring detects a change to your attack surface that matches the trigger condition, the configured actions execute automatically.

Policies are evaluated continuously as new discovery data comes in. There is no delay between detection and policy evaluation beyond the normal discovery cycle times.

Trigger Conditions

Policies can trigger on the following types of attack surface changes:

Open Ports

Trigger when a new port is detected on any of your IP addresses, or when a port matches specific criteria.

Examples:

  • Alert when any port outside 80 and 443 is detected open
  • Alert when database ports (3306, 5432, 27017) are found open
  • Alert when any port is detected on a production IP range

Technology Changes

Trigger when new technologies are detected or when technology versions change on your assets.

Examples:

  • Alert when an end-of-life PHP version is detected
  • Alert when a non-approved CMS is found on any subdomain
  • Alert when jQuery below version 3.5 is detected

Hosting Provider Changes

Trigger when an asset’s hosting provider or IP address changes, indicating infrastructure migration or potential DNS hijacking.

Examples:

  • Alert when any asset moves to an unapproved cloud provider
  • Alert when a production domain’s IP changes unexpectedly
  • Alert when assets are detected outside your primary cloud accounts

DNS Record Types

Trigger based on DNS record changes, additions, or removals.

Examples:

  • Alert when a new CNAME record is created pointing to an external service
  • Alert when MX records change for your primary domain
  • Alert when TXT records are modified (potential SPF/DKIM changes)

Domain Names

Trigger when new subdomains are discovered matching specific patterns.

Examples:

  • Alert when subdomains containing “dev”, “staging”, or “test” are discovered
  • Alert when any new subdomain is discovered under a specific root domain
  • Alert when subdomains matching a naming convention are found

Creating a Policy

  1. Navigate to Surface Monitoring > Policies
  2. Select Create policy
  3. Choose your trigger condition type
  4. Configure the specific criteria for the trigger
  5. Add one or more actions (notification channel, severity level)
  6. Name the policy and optionally add a description
  7. Select Save

Actions

When a policy triggers, the following actions are available:

  • Email notification — Send an alert to specified email addresses
  • Integration notification — Send alerts to connected channels (Slack, Microsoft Teams, PagerDuty, OpsGenie)
  • Webhook — POST event data to a custom URL for workflow automation
  • Severity assignment — Tag the event with a severity level for prioritization

Policy Management

Enabling and Disabling

Policies can be enabled or disabled without deleting them. Disabled policies retain their configuration but do not evaluate triggers or execute actions.

Policy History

Each policy maintains a history of trigger events, showing when the policy fired and what change caused it. Use this history to tune policies that trigger too frequently or to verify that policies are working as expected.

Best Practices

  • Start broad, then narrow: Begin with general policies and refine based on alert volume
  • Use severity levels: Assign higher severity to policies monitoring production assets
  • Combine triggers: Create multiple policies for different aspects of the same concern
  • Review regularly: Audit your policies quarterly to ensure they remain relevant as your infrastructure evolves

Next Steps

  • Configuration — Set up integrations for policy notifications
  • Discovery — Understand what changes policies can detect
  • Results — View findings generated by vulnerability assessments
Last updated on