Attacks on the business payment cycle leverage the nature of its fragmented silos to successfully conduct fraudulent activities. There are multiple stages in the B2B payment cycle, from the initial vendor onboarding through the final release of funds, each of which can fall prey to an adversary that works to divert the payment from the intended recipient. This makes the need for contextual awareness and risk analysis across each one of these steps an imperative. Any solution that doesn’t address the challenges and risks of each step leaves the process vulnerable. If there are gaps in protection anywhere within the process, it won’t really be secure—when there’s a hole in the bottom of the boat it matters little that all other parts of it are intact. In this post we’ll examine why protecting the entire process is a fundamental requirement for any solution looking to secure business payments, rather than a solution that only provides protection in one or two areas.

Partial Protection of Business Payments Falls Short

The business payment cycle comprises various stages including but not limited to: vendor onboarding, sending and invoice for services or goods, uploading the invoice to the ERP system, processing and instructing the bank to transfer the payment, and the actual payment itself.  This cycle involves multiple systems and stakeholders, belonging to different organizational units with little or no interaction between them. Furthermore, there is little to no visibility between steps in the process and between systems and people within the process. An attack on the payment cycle can start as early in the cycle as the first email between the vendor and the organization or as late as the payment transfer.  This effectively makes securing the B2B payment cycle an all or nothing proposition. As an attacker plans their attack and tests where the vulnerabilities lie, they will poke and prod the defenses until they find an unprotected part of the process to infiltrate. ‍

‍

Protecting The Top of The Process: Business Email Compromise

Business email compromise (BEC) is a critical component of a successful B2B payment cycle attack.  In fact, it is one of the most common attack surfaces. Solutions that defend against BEC excel at detecting harmful emails and blocking them before ever appearing in the user’s inbox.  In the context of payment cycle security, BEC solutions can address social engineering, which manipulates employees to perform illicit actions.  BEC solutions can also spot email messages with false payment claims and can detect fraudulent email attachments. However, by focusing on a single component – email – the BEC solution doesn’t solve the whole problem and doesn’t protect against attacks across every step of the process.

We’ve discussed before that the main challenge in securing the payment cycle stems from the silos within the process, where little to no information is shared between different parties and systems involved in the payments workflow.  Email is one siloed component within the process, and even the most comprehensive BEC solution won’t catch or stop fraudulent activities that take place later in the B2B payment workflow.

‍

Where a BEC Only Solution Fails

Let’s consider the following scenario. An adversary sets out to target an organization. Following their initial reconnaissance, they identify the perfect vendor to impersonate. They send an email to the organization that they know works with this vendor, attaching a fake invoice.  They urge the contact at the organization to pay the invoice ASAP.  If there’s a BEC protection solution in place, it will spot the fake email and block the message. Once the email is blocked, the BEC protection solution has done its job and offered the protection it is supposed to.  

Here’s the problem: none of the information about the impersonation email and social engineering attempt is shared beyond this point to other stakeholders within the B2B payment process.  No one else knows that this vendor was being impersonated or that there is a risk of BEC, or that there is a bad actor out there trying to break in and hijack funds.

So what happens next? The attacker realizes that the emails are not going through and as a result, they change their tactics and search for another weak link later in the chain. If BEC doesn’t work, they can find other ways to hack another vendor’s email or directly attack the organization’s ERP, vendor management system, or other systems.  

There are two gaps present when relying on a solution that addresses only one part of the cycle. In the case of BEC, a solution dedicated to this attack surface doesn’t apply to other components of the payment cycle. More importantly, the BEC solution doesn’t share the blocked attack data with others in the payment cycle. Neither the targeted employee, nor the finance team member that would have processed the invoice and managed the payment to the vendor, have the slightest clue that an adversary has put them on their radar.  

This same example holds true for any other solution that only secures vendor onboarding, or only manages the vendor lifecycle, or secures only the payment approval process, or only enforces controls on processes across systems.  

Getting the full context

Circling back to the attack scenario above, let’s examine what could have happened if there was a single security layer with full visibility across the entire payment cycle and could connect all the dots across systems to uncover every part of the attack. Once the fraudulent email is detected and blocked, alerts can be sent out to let the vendor know someone is impersonating them.  Furthermore, everyone at the organization could also be alerted that this social engineering attempt is happening. Any other company working with that vendor, should they be part of a broader network like the Trust Network, could also be alerted. In this way, all activities with this vendor can be monitored more closely to ensure the attacker isn’t trying to hijack the process through another weak point. By leveraging AI, a tool that sits across the process will scrutinize all invoices ensuring that ones from this vendor that come through are, in fact, real and not forged. Any change requests in bank account information will be flagged if there are other indications that suggest the attacker has gained a foothold within the process. The targeted employee may be more closely monitored, and their actions checked to ensure that future attacks didn’t successfully steal their credentials to access internal systems. However, an organization can’t respond in this way with a solution that protects just one part of the process. For 100% protection, the solution must have a broader view of the entire context within the process.

The number of attack surfaces that need protection is not endless and can be mapped and addressed with one comprehensive solution. Implementing a holistic and contextual approach can be the start of combatting bad actors successfully.  It’s necessary to have a solution with integrated context of the entire process—a solution that connects all the dots, if you will.

If you’d like to learn how Trustmi connects the dots with data, get in touch today and we’ll show you how we’ve pieced together the entire story behind B2B payment attacks, from the BEC and social engineering, to the bank account change requests and forged invoices.