Business email compromise: the controls that stop the wire

In our view, business email compromise is not, at its core, a technical attack. The question it puts to a company is an authorisation question: when an inbound message asks for money to move somewhere new, who is allowed to act on it, and what must they do before they do?

The answer should already exist in writing. Where it does not, that gap — rather than any clever piece of malware — is what business email compromise exploits.

The money leaves through the finance process

The FBI's Internet Crime Complaint Center describes the scheme plainly. "BEC is a sophisticated scam in which a criminal actor uses email to impersonate a business executive or other employee to request fraudulent payments or obtain access to employee payroll or W2 information." IC3's public service announcement notes that perpetrators impersonate "business executives, real estate industry representatives, HR staff, law firms, and trusted vendors to initiate or redirect wire transfers to overseas bank accounts."

Notice what is absent: no exploit, no ransomware, no encrypted server. Sometimes an attacker is inside a mailbox, sometimes they are simply running a convincing lookalike. Either way the loss happens when a person with payment authority does what the email asked.

NIST's glossary gives phishing, in the formulation drawn from NIST SP 800-115, as "a digital form of social engineering that uses authentic-looking—but bogus—e-mails to request information from users or direct them to a fake Web site that requests information." Authentic-looking is the operative word: the defence cannot be that staff recognise a fake, because the premise of the attack is that they will not.

A regulator has already put this in writing

Companies sometimes treat payment fraud as an operational embarrassment rather than a control failure. The SEC took the second view in an investigative report issued on 16 October 2018, "cautioning that public companies should consider cyber threats when implementing internal accounting controls."

The facts are worth reading slowly. The report was based on investigations of nine public companies, each of which lost at least $1 million; "two lost more than $30 million, and one lost more than $45 million." In total "the nine companies wired nearly $100 million as a result of the frauds, most of which was unrecoverable." The frauds "in some instances lasted months and often were detected only after intervention by law enforcement or other third parties." The release also states: "The FBI estimates fraud involving BECs has cost companies more than $5 billion since 2013."

Then the sentence that matters for anyone building controls:

"Public issuers subject to the internal accounting controls requirements of Section 13(b)(2)(B) of the Securities Exchange Act of 1934 must calibrate their internal accounting controls to the current risk environment and assess and adjust policies and procedures accordingly."

Separately, there is statutory text worth reading on its own terms. The U.S. Code section published at 15 U.S.C. § 78m, under the heading "Periodical and other reports," carries at subsection (b)(2) a requirement addressed to "Every issuer which has a class of securities registered pursuant to section 78l of this title and every issuer which is required to file reports pursuant to section 78o(d) of this title." Such an issuer must, at subparagraph (B), "devise and maintain a system of internal accounting controls sufficient to provide reasonable assurances that" — among other things — "transactions are executed in accordance with management's general or specific authorization."

Whether either provision reaches your company is a question for counsel. In our view, private companies should read that language anyway, because authorisation is the vocabulary the whole problem is written in, and it names the thing a payment control exists to establish: who was allowed to say yes, and on what evidence. The accounting side of a cyber loss is the subject of a breach is a financial reporting problem.

The control that carries the weight

In our view one control matters more than the rest, and it is unglamorous: nothing about where money goes changes on the strength of an inbound message alone.

IC3's recommendations are specific. "Ensure company policies provide for verification of any changes to existing invoices, bank deposit information, and contact information." "Contact requestors by phone before complying with e-mail requests for payments or personnel records." "Consider requiring two parties sign off on payment transfers."

CISA's guidance on social engineering adds the detail that matters: "If you are unsure whether an email request is legitimate, try to verify it by contacting the company directly. Do not use contact information provided on a website connected to the request; instead, check previous statements for contact information."

Read that as an instruction about which phone number you use. A callback to the number in the email signature verifies nothing. The number has to come from your own vendor record, and the verification has to be recorded — who called, which number, who confirmed, when.

Three failure modes worth checking in how the control is written:

• It applies only to new vendors. The expensive event is a change to an existing payee, because the relationship is already trusted and the invoice already expected.
• It has an urgency exception. An exception for urgency is the attack, written into your own policy. Pressure is the technique, not a coincidence.
• It is a norm rather than a step. If verification is a habit rather than a required field on the change request, it disappears the week its owner is on leave.

Two people, and the right two people

NIST's glossary defines separation of duty, drawing on NIST SP 800-192, as the principle that "no user should be given enough privileges to misuse the system on their own," with the illustration that "the person authorizing a paycheck should not also be the one who can prepare them."

Applied to payments: the person who can change a bank account in the vendor master is not the person who can release a payment to it.

Two notes, as this publication's view rather than anyone's rule. Set a threshold above which a second approver is mandatory, low enough that your largest routine payment is covered. And check that the two approvers are genuinely two people in the system, not one person holding two sets of credentials — the same question an auditor asks of any access population, covered in the access review an auditor will accept.

Make the email harder to fake, and the mailbox harder to hold

The payment controls are the backstop. The technical layer reduces how often they are tested.

The FTC's guidance for small business on email imposters starts with authentication: "When you set up your business's email, make sure the provider offers email authentication technology." It explains the point of that — "as a message passes from your company's server to a receiving server, there are behind-the-scenes ways to verify that it's really coming from you" — the mechanism that lets a receiving system treat a forged sender as suspect.

Two IC3 measures belong on a named person's list. "Frequently monitor your Email Exchange server for changes in configuration and custom rules" — mailbox rules that auto-forward or auto-delete are how an intruder stays invisible inside a thread. And "consider adding an email banner stating when an email comes from outside your organization," which is a cheap way to make a lookalike domain visible to the reader.

CISA's performance goals treat phishing-resistant multifactor authentication as its own goal, with the outcome of adding "a critical, additional layer of security to protect assets accounts whose credentials have been compromised," and email security as a goal whose outcome is to "reduce risk from common email-based threats, such as spoofing, phishing, and interception."

Be clear about what MFA does: it raises the cost of taking over a mailbox, and does nothing about an impersonation that never touches your systems. Both routes end at the same payment process, which is why the payment process is the control of record.

The hour after it happens

Speed is the whole game once a payment has gone out. Write the sequence down before it is needed, not while someone is on hold.

CISA's guidance tells a victim to "contact your financial institution immediately and close any accounts that may have been compromised," to "report it to the appropriate people within the organization, including network administrators," and to "consider reporting the attack to the police, and file a report with the Federal Trade Commission." IC3 asks that victims file a complaint "regardless of the dollar loss or date of the incident."

The FTC's small business scams guide puts the ordinary invoice discipline in one line: "make sure procedures are clear for approving purchases and invoices and ask your staff to check all invoices closely."

This sequence belongs in the incident response plan rather than a document of its own — the incident response plan a mid-market company can run covers how to settle who may act before anyone is woken up.

What to do first

1. Write the payment-change rule on one page. Any change to bank details, for any payee, verified by callback to a number already held in your records, logged, and no exception for urgency.
2. Name the second approver and the threshold, and confirm in the system that the two roles cannot be held by one person.
3. Check your own mailboxes for forwarding rules, turn on the external-sender banner, and confirm which email authentication technologies are actually enforced on your domain.

If a payment has already gone out and you are working out what it means for your control environment, the breach aftermath control checklist walks it in order. For a ranked view of which gaps to close first, use the readiness scorecard.

This is general information, not audit, security or legal advice. Confirm what applies to you with your auditor or counsel.

Common questions

Is business email compromise a security problem or a finance problem?

Both, but the money leaves through the finance process. The FBI's IC3 describes BEC as a scam in which a criminal actor uses email to impersonate a business executive or other employee to request fraudulent payments. IC3's suggestions run across both sides of the house: alongside monitoring the email Exchange server for changes in configuration and custom rules, adding an external-sender banner and conducting end user education, they include ensuring company policies provide for verification of any changes to existing invoices, bank deposit information and contact information, contacting requestors by phone before complying with e-mail requests for payments, and considering requiring two parties sign off on payment transfers. In our view it is that second group that decides whether a single successful attempt costs you money.

Which control matters most against a fraudulent wire?

In our view, out-of-band verification of any change to payment instructions, using a phone number you already held rather than one supplied in the request. IC3 tells companies to ensure policies provide for verification of any changes to existing invoices, bank deposit information and contact information, and to contact requesters by phone before complying with email requests for payments.

Has a regulator actually said companies have to consider this risk?

The SEC issued an investigative report in October 2018, after investigating nine public companies that lost money to BEC frauds, saying that issuers subject to the internal accounting controls requirements of Section 13(b)(2)(B) must calibrate their internal accounting controls to the current risk environment and assess and adjust policies and procedures accordingly. Whether and how that applies to you is a question for counsel.

Will multi-factor authentication on email stop business email compromise?

It closes one route and not the other. MFA makes mailbox takeover considerably harder, and CISA lists phishing-resistant multifactor authentication as a performance goal whose outcome is to add a critical, additional layer of security to protect assets accounts whose credentials have been compromised. But an impersonation sent from a lookalike domain never touches your accounts at all, so MFA alone does not cover the vendor-change scenario.

What should we do in the first hour after a fraudulent payment goes out?

Contact the bank before anything else. CISA's guidance on social engineering tells victims to contact your financial institution immediately and close any accounts that may have been compromised, to report it to the appropriate people within the organization including network administrators, and to consider reporting the attack to the police. The FBI requests that BEC victims file a complaint with IC3 regardless of the dollar loss or date of the incident.

Does security awareness training stop this?

It helps and it is not the control you should rely on. IC3 recommends conducting end user education and training on the BEC threat, and CISA frames basic cybersecurity training as a goal whose outcome is that organizational users learn and perform more secure behaviors. In our view, training reduces how often the attempt succeeds, while the payment controls decide whether a single success costs you money.

Sources

1. SEC Investigative Report: Public Companies Should Consider Cyber Threats When Implementing Internal Accounting Controls (Press Release 2018-236) · U.S. Securities and Exchange Commission
2. 15 U.S.C. § 78m — Periodical and other reports, see subsection (b)(2)(B) · Office of the Law Revision Counsel, via the U.S. Government Publishing Office
3. Business Email Compromise Contributes To Large Scale Business Losses Nationwide (Public Service Announcement I-061118-PSA) · Internet Crime Complaint Center, Federal Bureau of Investigation
4. Avoiding Social Engineering and Phishing Attacks · Cybersecurity and Infrastructure Security Agency
5. Cross-Sector Cybersecurity Performance Goals (CPGs) · Cybersecurity and Infrastructure Security Agency
6. Cybersecurity for small business: Business email imposters · Federal Trade Commission
7. Scams and Your Small Business: A Guide for Business · Federal Trade Commission
8. Computer Security Resource Center Glossary — 'separation of duty' (definition drawn from NIST SP 800-192) · National Institute of Standards and Technology
9. Computer Security Resource Center Glossary — 'phishing' (definitions drawn from NIST SP 800-12 Rev. 1, NIST SP 800-115 and others) · National Institute of Standards and Technology