SafeToOpen Browser Security
Incidents, alerts and integrations
What becomes an incident, severities, alert cadence, and feeding events to ticketing and SIEM tools
1. What becomes an incident#
| Kind | Source | Severity |
|---|---|---|
| User report | The person clicked Report in the panel | High |
| User report (false positive) | The person disputed a verdict | Low |
| Auto-forwarded by policy | Auto-forward policy sent a Dangerous message to the report inbox | High |
| Dangerous verdict | Scan score in the dangerous band | Critical when the score is very low, otherwise High |
| Suspicious verdict | Scan score in the caution band | Medium |
| Executive impersonation | Deeper Analysis alert zone on an Executive seat | Critical |
| Executive review | Deeper Analysis review zone | Medium |
The same message seen again within 24 hours updates the existing incident rather than creating a second one. When automatic Deeper Analysis is enforced, the quick scan and the analysis produce one merged incident. Incidents carry the sender, subject, reasons and workspace, never the message body; the original email is not stored.
2. Alerts#
- Settings → Incident alerts: recipients, cadence (real time, daily, weekly) and minimum severity for the organisation.
- Workspaces → a workspace → Alert recipients to route that workspace’s alerts elsewhere, for example to an MSP client contact.
- Alert emails link to the incident in the console; analysts open it directly.
3. Responding to a confirmed incident#
Every incident detail ends with a Response panel. Once a Microsoft 365 connector exists (guide 7), the panel shows which actions will run when you click Confirm issue, offers each action for a one-off manual run, and lists what has already been done with an Undo where the action is reversible. Typical rules: on Confirm at severity high, junk the sender in the affected mailbox; for executive impersonation, junk the sender for every member; where the person clicked through and entered credentials, sign them out everywhere and require a password change.
4. Integrations#
Console → Integrations (Email Security) offers the same three routes as Browser Security, scoped to Email Security events: pull with an export token, push with a signed webhook, and email-to-ticket via the alert recipients. Event type email_security.flagged_event; formats JSON, OCSF, ECS and CEF; STIX indicators for sender addresses and domains; write-back of triage status from your ticketing tool.
- Tokens and webhooks created on the Email Security Integrations page carry only Email Security events; Browser Security ones stay separate, so one SIEM can consume both with distinct sources.
- Signature verification, polling, field reference and error codes are documented once in the Browser Security integration reference; the payload differs only in the event type and the email-specific fields (sender, subject, verdict, kind, workspace).
Reference: https://plus.safetoopen.com/docs/browser-security/integrations/reference.html.
The Browser Security side has the same response framework plus a hosted blocklist for firewalls; see https://plus.safetoopen.com/docs/browser-security/integrations/response-actions.html.