Security Engineering / Tools / Abnormal Security

Tool 05 · Email security

Abnormal
Security A behavioural email platform that connects to Google Workspace by API rather than sitting in the mail path. It does not ask "does this message contain something bad?" — it asks "is this message consistent with how these people actually communicate?" That difference is the entire product.

needs → Email fundamentals4 tiersWorkspace context

Tier 0 · Groundthe model

Why API-based and behavioural

Module 0.1

Deployment architecture

Beside the mail flow, not in front of it

TRADITIONAL GATEWAY (SEG) ABNORMAL (API) internet internet │ │ ▼ ▼ [ SEG ] ← MX points here [ Google Workspace ] │ │ ▲ ▼ ▼ │ OAuth API [ Google Workspace ] inbox [ Abnormal ] reads mail, contacts, sign-ins, config, and remediates post-delivery

Consequences of that choice, both directions:

Because it is API-based…	Implication
No MX change	Deployment is low-risk and reversible; no mail outage possible from the product being down
Reads the whole tenant	Sees internal (lateral) mail that never traverses a gateway
Has historical context	Can baseline relationships, tone, timing, and normal sending infrastructure per person
Remediates after delivery	There is a window — usually seconds — where the message is in the inbox
Holds broad OAuth scopes	The integration itself is a high-privilege asset; treat its access and admin console accordingly

Layering with Workspace: Google's native filtering handles the commodity volume — spam, known malware, obvious phishing. Abnormal is layered to catch what content inspection structurally cannot: BEC, vendor fraud, account takeover and lateral phishing. Decide explicitly which quarantine is authoritative and where users report suspicious mail, or you will run two processes badly.

Module 0.2

What "behavioural baseline" actually means

The signals behind the verdict

The platform builds a model of normal for your organisation and then scores deviations. The signal families are worth knowing because they are what you will cite when explaining a verdict:

Identity and relationship — has this sender ever emailed this recipient? Do these two normally correspond? Is the display name associated with a different address than usual?
Sending infrastructure — is this sender arriving from their usual IPs, ASNs and authentication posture, or somewhere new?
Content and tone — financial-request language, urgency, secrecy, unusual phrasing for that sender.
Domain signals — registration age, lookalike similarity to known partners, first appearance in your environment.
Behavioural context — sign-in anomalies for internal accounts, new mail rules, unusual send volume: the account-takeover tells.
Payload analysis — links, attachments and redirect chains, as a supporting rather than primary signal.

The honest framing for a stakeholder: this catches attacks that contain nothing detectably malicious, which is precisely the category that costs FinTechs money. It is not a replacement for authentication hygiene — you still need DMARC at enforcement, because that is what stops your domain being used against your customers and suppliers.

Checkpoint 0I can explain API vs gateway deployment with its trade-offs, and name the six signal families behind a behavioural verdict.

Tier 1 · Operatethe console

Daily operation

Module 1.1

Console areas and what each is for

Where to go for which question

Area	Answers
Threat Log	What was detected and remediated, with the attack classification and the reasons behind the verdict
Search & Respond	Free-form search across all mail — the hunting surface, including messages never flagged
Abuse Mailbox	User-reported messages, auto-triaged with a verdict and bulk remediation
Accounts / Account Takeover	Compromised-account signals: sign-in anomalies, new rules, unusual sending
Cases	Grouped incidents requiring analyst attention
Posture / Configuration	Tenant configuration drift, privilege changes, third-party OAuth app inventory
Vendors / VendorBase	Risk view of the external domains you correspond with — compromised suppliers surface here
Detection settings	Sensitivity, safe/blocked senders, remediation behaviour per attack type

Search & Respond is the one to get fluent in. Typical queries: all mail from a domain in the last 30 days; every recipient of a given subject; messages containing a specific URL; mail from a sender whose display name matches an executive. Remediation from the result set is bulk — one action removes the campaign from every mailbox.

Module 1.2

Triage workflow

Including the part people skip

1Open the detection and read the reasons — which signals drove the score. This is also how you learn to predict its verdicts.

2Confirm remediation actually completed across all recipients, including any forwarded copies.

3Scope it in Search & Respond: same sender, same domain, same subject pattern, same URL — across a longer window than the detection covered.

4Check whether anyone interacted before removal — replied, clicked, or opened. This is the step most often skipped and the one that determines whether it is an email event or an identity incident.

5If interaction occurred: pivot to identity — revoke sessions, check for new mail rules, forwarding, delegation, app passwords and OAuth grants; then check the endpoint.

6If a supplier domain is involved, treat their account as potentially compromised and notify them out of band. VendorBase context helps here.

Safe-sender lists are the dangerous screen. Allow-listing a domain because "their invoices keep getting flagged" removes exactly the protection you bought — and a compromised supplier account — vendor email compromise — is one of the highest-risk sources of fraudulent invoices. Prefer narrower tuning, record every entry with a reason and owner, and review the list quarterly.

Module 1.3

Abuse Mailbox and user reporting

Turning reports into a working loop

Users report suspicious mail; the platform auto-analyses, gives a verdict, remediates the malicious ones across the tenant, and replies to the reporter. The operational value is in the loop being closed: people who get an answer keep reporting, and reporting is a genuinely useful detection channel for the things behavioural scoring rated just below threshold.

Make reporting one click — a button in Gmail, not "forward to security@".
Track report-to-verdict time and the proportion of reports that turn out malicious; both are good programme health metrics.
Feed genuine misses back as tuning input rather than treating them as noise — a miss that a user caught is the most valuable signal you get.

Drill 1

An invoice from a long-standing supplier is flagged as suspicious. The domain is correct, SPF/DKIM/DMARC all pass, but the bank details differ from previous invoices. What is the most likely explanation?

Supplier account compromise. Authentication passing is the point: the message really did come from their infrastructure, so SPF, DKIM and DMARC are all satisfied. Only relationship and behavioural context — this is a change in payment details, inserted into a real thread — reveals it. Response: do not pay, verify out of band on a number held on file, notify the supplier through a separate channel, and search your tenant for other mail from that account in the same period.

Checkpoint 1I can triage a detection through to identity impact, scope a campaign in Search & Respond, run the abuse-mailbox loop, and justify every safe-sender entry.

Tier 2 · Engineerintegration

Fitting it into the stack

Module 2.1

Signals out, context in

The correlations worth building

To the SIEM: detections with attack type, sender, recipients, URLs and verdict; account-takeover signals; and configuration/posture changes. In UDM these land as EMAIL_TRANSACTION and related events.
Correlation to build first: phish delivered → recipient's proxy log shows the URL was visited (Netskope) → IdP shows a login from a new ASN → Workspace audit shows a new mail rule. That four-source chain is a confirmed takeover and should page, where any single element would not.
To SOAR / the MSSP: the case should arrive with the recipient list and interaction status already attached; that is what makes downstream identity response fast.
Workspace controls remain yours: DMARC enforcement, external-sender banners, attachment policies, third-party app restrictions, and the inbound gateway allow-list. Abnormal does not replace any of them — several of them are what keep its job manageable.

Module 2.2

Limits worth stating out loud

For design reviews and due diligence

Post-delivery window — messages exist in the inbox briefly. Fast, but not zero. A user with notifications on can act inside that window.
Baseline warm-up — new tenants, new joiners and brand-new supplier relationships have thinner context, which is where misses concentrate.
Channel scope — mail is not the only channel. The same social-engineering attack over Slack, WhatsApp or SMS is outside its view entirely, and increasingly common.
Explainability — verdicts are model-driven. Reasons are shown, but you cannot read a rule the way you can in a SIEM. That matters when an auditor asks how a decision was reached.
Integration privilege — broad OAuth scopes into your mail tenant. Include it in your third-party risk assessment as a high-criticality processor, with the residency, sub-processor and exit questions answered.

The control that actually stops the loss: for BEC, the decisive control is procedural — out-of-band verification of any bank-detail change, using contact details held on file rather than in the email, plus dual authorisation above a threshold. Say this plainly whenever email security is discussed as a purchase; the technology raises the bar, the process is what closes the gap.

Checkpoint 2I can specify the email telemetry the SIEM needs, describe the four-source takeover correlation, and state this product's limits in a due-diligence conversation.

Referencesearchable