Response actions: mail platforms, gateways, identity, chat and paging

Response actions let a confirmed Email Security incident change something in Microsoft 365 or Entra ID without anyone leaving the console. You connect your tenant once, write rules that say which incidents trigger which action, and watch the log. Rules start in dry run, every action is recorded, and the reversible ones have Undo. Find it under Organisation → Response actions in the Email Security console.

What each integration lets you do#

Three outcomes are available on an Email Security incident. Stopping the sender keeps the same attacker out of every other mailbox, and in some systems pulls back what was already delivered. Containing the user ends the sessions and forces a password change for the person who reported or received the message, which matters when they entered credentials. Alerting and paging bring a person into the loop. The table lists which integration delivers which outcome and whether the action can be reversed from SafeToOpen.

Every connector below has the same parts: what it gives you, the vendor-side set-up, the console set-up, and the actions with scope and undo. Blocking a URL rather than a sender is a Browser Security action; see that console’s guide.

1. Connect Microsoft 365 and Entra ID#

What it gives you#

One Entra app registration lets a confirmed incident act on two layers of the tenant. On the mail layer: block the sender for the whole tenant through Microsoft’s own submission pipeline, so Exchange Online rejects their next message to anyone, and junk their mail in the affected mailbox or in every member’s mailbox. On the identity layer, when the person entered credentials: sign them out of every app and device, require a new password at the next sign-in, and mark the account compromised so risk-based Conditional Access policies (block, MFA, password reset) apply automatically. The same connector, with one extra permission, also blocks URLs and domains from the Browser Security console.

Before you start#

• A Global Administrator or Application Administrator to create the app registration and grant admin consent.
• For the password-change action, someone who can assign the app the User Administrator role.
• For the compromised-user action, Entra ID P2 and at least one risk-based Conditional Access policy; without a policy the flag is recorded but nothing enforces it.
• For the tenant-wide sender block, the Outlook add-in 8.1.1 or later, which attaches the message reference the submission needs.

Set-up#

1. Entra admin center → App registrations → New registration (any name, single tenant). Note the Application (client) ID and the Directory (tenant) ID.
2. Certificates & secrets → New client secret; copy the value, it is shown once.
3. API permissions → Add a permission → Microsoft Graph → Application permissions. Add only what you need, then Grant admin consent:

1. Console → Response actions → ＋ Microsoft 365 and Entra ID → tenant ID, client ID, secret → Add connector → Test. The test signs in and lists which permissions the token carries and which are missing; actions whose permission is missing fail with a clear message rather than silently.

2. Actions#

3. Google Workspace#

What it gives you#

A service account with domain-wide delegation lets a confirmed incident send the sender’s future mail to Spam in the affected mailbox or in every member’s mailbox, and, when the person entered credentials, end all their Google sessions and force a password change at the next sign-in. The same connector serves directory import (guide 4) if you give it the group scopes too.

Set-up#

1. Google Cloud console → IAM & Admin → Service Accounts → create one, then Keys → Add key → JSON. Keep the file.
2. Google Admin console → Security → Access and data control → API controls → Manage domain-wide delegation → Add new. Client ID: the service account’s. Scopes: https://www.googleapis.com/auth/gmail.settings.basic, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.user.security.
3. Console → Response actions → ＋ Google Workspace → the admin account to act as (a super admin or a delegated admin with user management rights) and the JSON key pasted whole → Add connector → Test.

4. Mimecast#

What it gives you#

A Blocked Senders policy that makes Mimecast reject every future message from the sender, or from the sender’s whole domain, to everyone in the organisation, before it reaches Microsoft 365 or Google. The same connector blocks URLs through URL Protect from the Browser Security console.

Set-up#

1. Mimecast Administration Console → Services → API and Platform Integrations → Your Application Integrations → Add API application. Give it the Blocked Senders Policy (create, delete) and Managed URL (create, delete) permissions. Create a client id and secret.
2. Console → Response actions → ＋ Mimecast → client id and secret → Add connector → Test.

5. Proofpoint TRAP#

1. Threat Response → Sources → New source → type JSON. TRAP generates an alert-source URL that contains a token; copy it.
2. In the source, map the incoming fields once. SafeToOpen sends sender, sender_domain, recipient, subject, message_hash, severity, verdict, kind, reasons, occurred_at, incident_id and incident_url.
3. Set the source’s match and response rules the way you already do for other alert sources (for example: quarantine matching messages from every mailbox and any later copies).
4. Console → Response actions → ＋ Proofpoint TRAP → paste the URL; choose whether to verify the appliance certificate → Add connector → Test. The test only checks the host is reachable from SafeToOpen; no alert is sent.

The action “Send to Proofpoint TRAP for auto-pull” posts one alert per incident. TRAP does the pull; nothing is undone from SafeToOpen. If the appliance is on-premises, allow inbound HTTPS from plus.safetoopen.com or expose it through your usual reverse proxy.

6. Other email gateways#

Each is its own connector with a Test. Confidence varies with how stable the vendor API is; start every rule in dry run and check the first real result.

Check Point Harmony Email & Collaboration#

1. Infinity Portal → Global Settings → API Keys → New, service Harmony Email & Collaboration. Note the client id and access key, and your portal region.
2. Console → ＋ Check Point Harmony Email & Collaboration → region, client id, access key → Test.
3. Action “Quarantine every message from the sender (last 7 days)”: searches Microsoft 365 emails from the sender and quarantines them. Undo restores them.

Cisco Secure Email Threat Defense#

1. Threat Defense console → Administration → API Clients → create a client; note the region.
2. Console → ＋ Cisco Secure Email Threat Defense → region, client id, secret → Test.
3. Action “Move every message from the sender to Junk (last 7 days)”: searches delivered messages from the sender and remediates them to Junk. Undo moves them back to the Inbox.

Barracuda Email Gateway Defense#

1. Barracuda Cloud Control → Apps → API → create an OAuth application; note the account id and, if the policy should be per domain, the domain id from the Domains page.
2. Console → ＋ Barracuda Email Gateway Defense → client id, secret, account id, domain id → Test.
3. Action “Block the sender (sender policy)”: creates a block policy for the address or the whole domain. Undo deletes the policy.

FortiMail#

1. Create an admin with REST API access on the FortiMail unit and make its HTTPS address reachable from plus.safetoopen.com (a public hostname or a reverse proxy).
2. Console → ＋ FortiMail → address, username, password, certificate verification → Test.
3. Action “Block the sender (system block list)”: adds the address, or *@domain, to the system block list. Undo removes it.

7. Okta#

1. Okta Admin console → Security → API → Tokens → Create token, from an admin who can manage the users concerned (or a custom admin role scoped to them).
2. Console → Response actions → ＋ Okta → org URL (for example https://yourcompany.okta.com) and the token → Add connector → Test.

The affected member’s email is used as the Okta login. Use Okta actions instead of the Entra or Google ones when Okta is the identity provider in front of Microsoft 365 or Google Workspace.

8. Slack and Microsoft Teams incident cards#

What it gives you#

An incident card in the channel your team already watches, the moment a high-severity incident arrives, with three buttons: Open incident, Confirm issue & respond (marks it confirmed and runs your on-Confirm rules) and No issue. Incoming webhooks are one-way, so the buttons open the console signed in and act after one prompt, which puts the analyst’s name on the action instead of a shared bot.

Slack set-up#

1. Open https://api.slack.com/apps → Create New App → From scratch → name it “SafeToOpen” → pick your workspace → Create App.
2. In the app’s left menu → Incoming Webhooks → switch Activate Incoming Webhooks to On.
3. Scroll down → Add New Webhook to Workspace → choose the SOC channel → Allow. Copy the Webhook URL (it starts with https://hooks.slack.com/services/).
4. Console → Response actions → ＋ Slack → paste the URL → Add connector → Test. A “SafeToOpen connected” card appears in the channel.

Microsoft Teams set-up#

Teams receives cards through a Workflows webhook (Power Automate, included with Microsoft 365). The older Office 365 Connectors “Incoming Webhook” has been retired by Microsoft; existing legacy URLs still work in the connector but new ones should be Workflows.

1. In Teams, open the channel that should receive cards → click the ⋯ next to the channel name → Workflows. (If you do not see Workflows, open the Workflows app from the left rail and choose Create.)
2. Search the templates for “webhook” and choose “Post to a channel when a webhook request is received”.
3. Give the flow a name such as “SafeToOpen incidents”, make sure it is signed in as you, click Next.
4. Choose the Team and the Channel the cards should post to → Add workflow.
5. The final screen shows the webhook URL (it starts with https://….logic.azure.com:443/workflows/… or https://….webhook.office.com/…). Copy it → Done.
6. Console → Response actions → ＋ Microsoft Teams → paste the URL → Add connector → Test. A “SafeToOpen connected” card appears in the channel, posted by the Workflows bot.

Rules#

1. Add a rule: connector Slack or Teams → action “Post an incident card” → Automatically when the incident arrives → minimum severity high (or critical for a quieter channel) → kinds blank → dry run off; a card is not a change you need to rehearse.
2. Optionally a second rule on the same connector, On Confirm at any severity, so the channel sees who confirmed and what the on-Confirm rules did.

The card shows severity, kind, sender, subject, mailbox, trust score, workspace, time and the top reasons, with three buttons: Open incident, Confirm issue & respond, No issue. The buttons open the console signed in and act after one confirmation prompt, so the action carries the analyst’s name and Confirm runs the on-Confirm rules. Incoming webhooks cannot call back into SafeToOpen, which is why the buttons go through the console rather than acting inside the chat.

9. PagerDuty and Opsgenie paging#

1. PagerDuty: Services → Service Directory → the service that should own these incidents → Integrations → Add an integration → Events API V2 → Add. Open it and copy the Integration Key (32 characters). Note whether your account is US or EU (EU accounts sign in at eu.pagerduty.com).
2. Opsgenie: Teams → the team → Integrations → Add integration → API → name it “SafeToOpen” → tick Create and Update Access and Read Access → Save integration. Copy the API key. Note US or EU (EU accounts sign in at app.eu.opsgenie.com).
3. Console → ＋ PagerDuty (region, integration key) or ＋ Opsgenie (region, API key, optional responder team) → Add connector → Test. PagerDuty’s test sends a resolve for a non-existent key, so nobody is paged.
4. Add an automatic rule at severity critical with the action “Page the on-call”. One page per incident; Undo resolves or closes it, and marking the incident “no issue” does the same automatically.

Severity maps critical → PagerDuty critical / Opsgenie P1, high → error / P2, medium → warning / P3. The page carries the sender, mailbox, subject, workspace, trust score and a console link.

10. Rules#

A rule is: connector, action, when it runs, minimum severity, optional incident kinds, and dry run. Two triggers:

• On Confirm: runs when an analyst clicks Confirm issue on the incident. The incident view says in advance what will run.
• Automatic: runs the moment an incident of that severity is recorded, with nobody in the loop. Good for junking a sender; think twice before automating identity actions.

Kinds are matched by substring against the incident kind: user_report, user_report_false_positive, auto_forward, scan_dangerous, scan_suspicious, exec_impersonation, exec_review. Leave blank for any kind.

11. Working an incident#

1. Open the incident. The Response panel at the bottom lists what Confirm will run, offers each available action as a button, and shows actions already taken.
2. Click Confirm issue. The Confirm rules run and their results appear in the same click; dry-run rules log what they would have done.
3. Use the buttons for one-off actions with no rule, for example junking a sender for all members when the rule only covers the affected mailbox.
4. Undo an action from the panel or from the Response actions log; the log keeps the original result and who undid it.

12. Gateway and EDR blocking: where it lives#

SafeToOpen can also push confirmed URLs and domains to Defender for Endpoint, Cisco Umbrella, Zscaler Internet Access, Netskope, Cloudflare Zero Trust, CrowdStrike Falcon and to a hosted blocklist that firewalls pull. Those connectors appear in the Browser Security console, not here, for one reason: an Email Security incident records the sender and the verdict, never the message body or its links, so there is no URL to block. When someone clicks a link in a flagged message, Browser Security sees the page and records its own incident with the URL; that is where the gateway and EDR rules fire.

• Run both products: Email Security junks the sender and contains the user; Browser Security blocks the destination in your gateways and endpoints when the link is opened.
• The Microsoft connector is shared in spirit but configured per product; enter the same app registration in both consoles. Defender for Endpoint needs the extra Ti.ReadWrite.All permission and is used from the Browser Security side.
• Sender-domain blocking in web gateways is deliberately not offered: a sender’s domain is rarely the phishing site, and blocking it would cut legitimate mail-related browsing.

Details for each gateway and EDR connector: https://plus.safetoopen.com/docs/browser-security/integrations/response-actions.html.

13. Safety and audit#

• Every action appears in the Activity log and in the Response actions log with trigger, actor (analyst email or auto-rule), target and result.
• The same action never runs twice on one incident, so an automatic rule and a Confirm rule on the same action do not double up.
• Manual actions are limited to 120 per hour per organisation.
• The client secret is encrypted at rest and never shown again. Graph tokens are cached briefly and scoped to the permissions you granted.