A Holistic View of Online Banking Security
In reality, criminals do not care about a user's ID/password any more than they would care about the ignition in your car when they attempt to steal it. Sure, they need to know how to work it, but it is the means to an end. The same holds true for user credentials. Criminals do not want your ID; they want your cash. The ID is simply the means to the end.
Many attacks have initially centered on wire transfers, and for good reason; a lot of money can move very quickly. However, something as simple as a dual approval makes wire transfer fraud dramatically more difficult to commit. With dual approval -- something that has been around since nearly the inception of online cash management - a criminal must figure out how to coordinate an attack to compromise two credentials from the same business customer. This is an awful lot of work when there are much easier targets available.
The transaction to worry about is not wire transfer - it's ACH
Wires can also be protected with technology: out-of-band authentication, "enhanced" One-Time Passwords (OTPs) that include pieces of transaction data, fraud analytics and behavior analysis, etc. All of these do an effective job at combating wire fraud; it is relatively easy to protect against one singular fraud transaction. Think back to the days of fax wires and call-backs: wire room receives a wire, the authorized signer is called to verify the wire info, and - voila -- all of the technology needed to protect against hacking wire transfers is implemented. However, there is more than one way to move money electronically.
ACH has become a very appealing target for criminals. The very nature of ACH makes it very difficult to protect. It is often a large amount of information with minimal changes in between transmissions. The creation of an ACH batch is most often performed using a table of information -- for example, direct deposit information for employees. However, for each transmission, the originator very rarely verifies any of the information in that table (if ever). Therefore, it would be quite simple for an attacker to gain access to the information, alter pieces of it (say changing your account and routing numbers to theirs - NOT changing the amount) and save the data back in the table. Then wait for the user to log in and transmit the batch, using incorrect data, but with the expected totals that are most often used for verifying a correct batch.
ACH attacks are predicated on a few factors:
- The attacker can [relatively] easily bypass things like OTPs or analytics and then not perform a transaction.
- The attacker alters data at rest; waiting for the proper user to initiate and properly authenticate the attacker's transaction(s).
- The attacker leverages that it is not practical or perhaps not even possible to verify every transaction in an ACH batch at each submission (imagine verifying every employee's direct deposit info every pay period)
- The attacker also leverages that the totals verified in an ACH batch are simply that -- representations of the sum of the parts.
Securing ACH transactions and the data that comprises them is more akin to protecting a document, a database or both, than an individual bank transaction. The data must be protected when it is entered and while it is at rest, and alteration of that data must call for a new authentication request. This means a potentially dramatic increase in the number of instances of verification on the part of the user. Consider again the payroll example: For hourly employees, a user would have dozens of authentication requests, if not more, per origination. Consequently, the authentication solution must be easy to use.
The ACH fraud solution will need to be technologically advanced yet user-friendly. It must protect data at rest, as well as protecting the ACH batch itself. The same solution must protect wire transfers, batch wires, tax payments, debits or any other type of online cash management function. It must also protect the user credential, which is the door to the vault. The user experience must also be consistent across all of these uses, or they will be prone to social engineering and confusion. The experience for authenticating the user at login should be the same as at wire release and at ACH data entry, batch creation and anything else.
In short, it is imperative that financial institutions consider all transaction types when deploying security. Attack vectors are constantly shifting to the point of weakness, and ACH is becoming that easy target. Deploying a security solution that only protects wire transfers will be, in all likelihood, 100% effective at preventing wire fraud; because the criminals will simply shift focus to ACH.