13.11 Hardening Against BEC

Hardening Against BEC

BEC prevention requires both technical controls and business process controls. Technical controls reduce the attack surface. Business process controls break the fraud execution — even when technical controls fail.

Recommendation 1: Verbal Verification Policy for Bank Detail Changes

What it does: Mandates that any vendor bank detail change request is verified via phone call to a known number (from the vendor master file, NOT from the email requesting the change) before being processed.

Why it matters: This single control would have prevented the £47,000 fraud in INC-2026-0315-002. If a.patel had called Meridian’s known accounts department number, Meridian would have confirmed they did not request a bank detail change.

Blast radius: Affects the accounts payable workflow. Adds 5-10 minutes per bank detail change request for the verification call. Process-level impact — no technical deployment.

Cost impact: £0. This is a policy change, not a technology purchase.

Rollback: Revert the policy. Not recommended.

Compliance mapping: NIST CSF PR.AT-1 (All users are informed and trained). ISO 27001 A.5.10 (Acceptable use of information). SOC 2 CC6.1 (Logical and physical access controls — extends to process controls for financial authorisation).

Recommendation 2: External Email Warning Banner

What it does: Adds a visible banner to all emails from external senders: “[EXTERNAL] This email originated outside Northgate Engineering. Exercise caution with links, attachments, and financial requests.”

Execute:

1
2
3
4
5
6

// PowerShell — create external email warning transport rule
// New-TransportRule -Name "External Email Warning Banner"
//   -FromScope NotInOrganization
//   -ApplyHtmlDisclaimerLocation Prepend
//   -ApplyHtmlDisclaimerText '<div style="background:#fef3c7;border:1px solid #d97706;padding:8px;margin-bottom:12px;font-size:13px;color:#92400e;"><strong>[EXTERNAL]</strong> This email originated outside Northgate Engineering. Exercise caution with links, attachments, and financial requests.</div>'
//   -ApplyHtmlDisclaimerFallbackAction Wrap

Blast radius: All incoming external email displays the banner. Internal email is unaffected. The banner is visible in Outlook desktop, OWA, and Outlook mobile. Tenant-wide for external email.

Cost impact: £0. Transport rules are included in all Exchange Online plans.

Rollback: Disable or remove the transport rule. Banner disappears from new email immediately (existing emails retain the banner).

Why it matters for BEC: In the Northgate scenario, the fraudulent email from the lookalike domain would have displayed [EXTERNAL]. If a.patel expected the Meridian vendor to be an external sender, the banner alone may not have prevented the fraud. But if the attacker sent the email from the compromised internal mailbox (appearing as internal), the ABSENCE of the banner would have been a trust signal — and the presence of a banner on a “Meridian” email would indicate it is NOT from Meridian’s real domain.

Recommendation 3: Block External Inbox Rule Forwarding

Same as M11.12 Recommendation 3. Prevents attackers from configuring inbox rules that forward email to external addresses.

Blast radius: Tenant-wide. All external forwarding via inbox rules is blocked. Cost impact: £0. Compliance mapping: NIST CSF PR.DS-5 (Data leakage protections). ISO 27001 A.8.12 (DLP).

Recommendation 4: Dual Authorisation for Payments Above Threshold

What it does: Requires two authorised individuals to approve any payment above £10,000 (or a threshold appropriate for the organisation). The second approver independently verifies the bank details.

Why it matters: Even if the first approver (a.patel) is deceived, the second approver provides an independent check. The probability of both approvers being deceived by the same BEC email is significantly lower — especially if the second approver uses the verbal verification policy (Recommendation 1).

Blast radius: Affects the payment approval workflow. Adds processing time for payments above the threshold. Process-level impact.

Cost impact: £0 for the policy. May require workflow changes in the finance system (adding an approval step).

Compliance mapping: ISO 27001 A.5.3 (Segregation of duties). SOC 2 CC6.3 (Segregation of duties).

Recommendation 5: Lookalike Domain Monitoring

What it does: Monitor for newly registered domains that are similar to your organisation’s domain (northgateeng.com) and your key vendors’ domains. Alert when a lookalike domain is registered.

Implementation options: Commercial services (e.g., Recorded Future, DomainTools) or open-source tools (dnstwist) that generate domain permutations and check registration status.

Cost impact: Free with open-source tools (manual effort). £500-2,000/year for commercial monitoring with automated alerting.

Why it matters: Proactive detection of attacker infrastructure before the BEC email is sent. If you detect meridian-precisi0n.co.uk being registered, you can preemptively block it and alert the vendor.

Recommendation priority matrix

Subsection artifact: The BEC hardening checklist with technical and process controls, blast radius, cost, and GRC mapping. This is distinct from the AiTM hardening checklist (M12.12) — BEC requires process controls that AiTM does not.

Knowledge check

Implementing the verbal verification policy

The verbal verification policy is the most impactful BEC prevention control — but it only works if it is actually followed. Implementation requires more than a policy document.

Step 1: Draft the policy. “Any request to change vendor bank details, payment instructions, or wire transfer destinations must be verified via telephone call to the vendor’s known contact number before processing. The contact number must be obtained from the vendor master file or the organisation’s records — NOT from the email requesting the change. No exceptions for urgency, seniority, or any other claimed justification.”

Step 2: Communicate to all finance staff. In-person briefing (not email — the irony of announcing an anti-BEC policy via the channel BEC exploits should not be lost). Explain the BEC scenario that prompted the policy. Show the Northgate Engineering example — the fraudulent email that looked identical to a legitimate vendor communication. The goal: every finance team member understands WHY the policy exists, not just that it exists.

Step 3: Create the verification log. Every verbal verification should be logged: date, vendor name, contact number called, person spoken to, change verified (yes/no), and verifier name. This log serves as: evidence that the policy is being followed (for auditors), a record of legitimate bank detail changes (for finance), and defence against social engineering attempts that target the policy itself (“I already verified by phone last week — just process it”).

Step 4: Test the policy. Within the first month, conduct a simulated BEC test: send a realistic bank detail change email to the finance team (coordinated with HR and the CFO). Track who follows the verbal verification policy and who processes the change without calling. Use the results for targeted training — not punishment. The goal is compliance, not gotcha.

Step 5: Annual refresh. Review the policy annually. Update the vendor master contact list. Re-brief the finance team with any new BEC examples from threat intelligence or from your own investigation experience.

Compliance mapping for the verbal verification policy: ISO 27001 A.5.10 (Acceptable use of information), A.5.37 (Documented operating procedures). SOC 2 CC6.1 (Logical and physical access controls — extends to process controls for financial authorisation). NIST CSF PR.AT-1 (All users are informed and trained). This single process control satisfies requirements across all four frameworks.