Welcome to Responses

A Response is how the Secure60 platform connects to external systems and sources.

Responses can be as simple as an email or could be an HTTP request to an API endpoint to trigger a specific action.

A Response is an Object in the Secure60 platform that is triggered by a Rule

Response Types

There are 2 main types of Response action within Secure60

• Email
  • Allows you to send an email to a user or group
  • Supports two delivery modes: real-time (one email per matching threat) and digest (a single grouped email per recipient on a schedule). See Email Send Mode: Real-time vs Digest below.
• Webhook
  • Allows you to connect to any internet facing HTTP endpoint
  • This enables a wide range of integration scenarios:
    • Slack and other chat platforms
    • Firewall APIs - To allow blocking of IPs
    • Active Directory and other user systems - To disable users
    • Ticketing and Support platforms
      

Response Scope, Severity and Overrides

Scope

A response by default has a scope which indicates whether the Response should fire on a matching Rule.

The scope can be All, SIGNAL or THREAT.

This allows for Responses to only be executed for Theats for example.

Severity

A response has a severity (default INFO) which indicates whether the Response should fire based on the Severity level of a Threat.

severity valid values are: INFO, LOW, MEDIUM, HIGH.

This allows for Responses to only be executed for Theats of a specific level of importance / risk for example. This allows different teams or workflows to handle Threats of varying criticality.

Overrides

Organisations often need to be more specific about how and when a response should be executed, Common scenarios include:

• Alerting the team of “Linux Admins” when a Rule within a Rule Group called “Linux” triggers
• Triggering a Reesponse whenever a Threat is created EXCEPT if the Rule or Rule Group is a specific item
• Creating Responses that are active across the full hierarchy of sub organisations

Response Overrides offer a solution to all of these scenarios and more.

Once a Response has been created you may add Overrides to fine tune the execution scenarios

Example Response Overrides:

Response templating

Within the content of every Response we allow templating. This enables the insertion of dynamic content into the Response data that is sent.

Scenarios where this is useful include:

• Adding Threat, Rule or Event specific information into the email that is sent
  • The allows for links to the specific Threat Detail pages to be created for example
• Sending specific entity information via HTTP to external APIs
• This allows for disabling of specific user objects or IP addresses in remote systems

Response templating syntax

Within response fields we support a templating system that gives access to the data related to the rule, signal or threat that generated the response.

Key syntax details:

• If the content of the response field contains {{fieldname}} we will insert the value found in the data for this item
  • There is a fallback text option if the field doesnt exist in the format: {{fieldname | fallback text}}
• The templating process is active against all fieldnames, especially useful for:
  • subject (email Response Type)
  • content (email Response Type)
  • uri (webhook Response Type)
  • request_payload (webhook Response Type)
• Fields available in the template include:
  • rule_id
  • name
  • group_id
  • status
  • project_id
  • organisation_id
  • threat_id
  • signal_id
  • ALL fields from the response object (Event, Signal or Entity) that triggered the Rule

Email Send Mode: Real-time vs Digest

An email Response operation has a Send Mode that decides how matching threats are delivered to recipients.

Real-time

Each matching threat produces one email per recipient immediately — this is the original Response behaviour, suitable for low-volume high-priority alerting (a single critical rule, a specific IoC list, etc.).

• Uses the configured Subject, Body, and Content Type template fields.
• All response-template variables ({{threat_id}}, {{name}}, etc.) apply.
• Recipients are defined by Email Recipients (Custom Email List or Send to All Organisation Users).

Use real-time when you want every matching threat to generate its own email — for example a named “CRITICAL vuln watch” response that pages an on-call email alias.

Digest (default for new email operations)

Matching threats are queued and delivered as a single grouped email per recipient on a schedule.

This is the right default for most Responses — particularly anything that can match tens or hundreds of threats in a short time window (vulnerability scanner output, bulk IoC matches, noisy rule groups). Without digest mode, a single vulnerability scan across a new host can fire thousands of emails to the same recipient.

Controls available in Digest mode

• Digest Cadence — how often a digest email is sent per recipient: HOURLY, DAILY (default), or WEEKLY.
• Always send immediately for severity ≥ — a bypass: threats at or above the chosen severity skip the queue and fire a real-time email using the configured Subject/Body template. Default NONE (nothing bypasses). Options: NONE, LOW, MEDIUM, HIGH.

In digest mode the Subject, Body, and Content Type fields are hidden. The subject and body are auto-generated from the Response name and the list of findings. If you flip back to Real-time later the stored template values are restored — your customisations aren’t lost.

What the digest email looks like

• Header: “Secure60 Digest — {Response Name} — {N} findings”.
• Findings grouped by category (Vulnerability Management / Threat Intelligence / Rules) — collapsed to a single group when only one category matches.
• Within each category, grouped by host with severity counts in the heading (e.g. “web-prod-01 — 12 HIGH · 20 MEDIUM · 15 LOW”).
• Up to 10 threats per host, each shown as two lines: SEVERITY · CVE · package, then a one-line recommendation snippet and a View link into the Portal.
• An overflow line appears when more threats exist: "+ 17 more — view all on web-prod-01".

When digest emails fire

The response-digest cron runs every hour on the hour (UTC). For each queued (response, recipient) pair, the cron decides whether to fire based on the configured cadence and the recipient’s Time Zone (set on the User record — see User Management):

• HOURLY — fires every hourly tick where the last digest was more than 60 minutes ago. Timezone-agnostic.
• DAILY — fires once per recipient-local day at the first hourly tick where local time is 08:00 or later. A user in Sydney gets their digest at 08:00 Sydney; a user in London at 08:00 London.
• WEEKLY — fires on the recipient’s local Monday at 08:00.

If a recipient’s email address doesn’t map to a User record, or the User has no Time Zone set, scheduling falls back to UTC. See User Management → Digest Emails and Timezones for the full model.

Choosing the right mode for a Response

Goal	Use
Alert one or two on-call emails about every critical detection	Real-time, optionally filter severity down to HIGH on the Response itself
Notify a team about bulk vulnerability/threat-intel findings without flooding them	Digest, DAILY, bypass NONE
Same as above but escalate HIGH severity immediately	Digest, DAILY, bypass HIGH
Time-sensitive review cadence (e.g. every hour during an incident)	Digest, HOURLY
Weekly summary for a stakeholder who doesn’t triage day-to-day	Digest, WEEKLY