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: its repeat count and last-seen time are bumped (shown as a ×N badge in the console), and no second alert email, webhook or response action is raised. 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#
Times in alert emails and digests are shown in the organisation time zone set under Settings; it defaults to the zone the owner’s extension reports. The console itself shows every time in the viewer’s browser zone, with a personal override under Browser Security → Settings → Display times in, and the UTC value in the tooltip.
- 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.