How to Monitor Encrypted Messages for Regulatory Compliance

SWIFT CSP’s mandatory controls get more numerous and stringent with every yearly release, and it can be difficult for even the most tech-savvy banks to keep pace. Beginning in July 2020, for instance, self-attestations will require independent audit assessments that cover at least the mandatory controls. This audit can be conducted by an internal or external team, but SWIFT seems to be pushing for (and in some instances requiring) outside assessors to help banks understand their own compliance pictures.

As financial institutions continue to grapple with more and more complex IT ecosystems—which are themselves designed around fighting more and more complex instances of fraud—it’s easy to understand why banks would feel like they had to solicit outside help. At the same time, it’s no substitute for taking real control over your own compliance and gaining a better handle on the ins and outs of your own complex ecosystem.

At the end of the day, these measures are all designed to stem the rising tide Bangladesh-style bank heists—a feat that can’t be accomplished without banks taking ownership over security.

How Audit Logs Factor into Cybersecurity Best Practices

Even outside the context of SWIFT’s CSP guidelines and mandates, the ability to audit activity that touches your network (including financial messages bound for and coming from SWIFT servers) is critical for your overall cybersecurity posture. For antifraud and anti-money-laundering regulations, banks need ways of keeping tabs on what’s often a particularly high volume of traffic—from which it can be difficult to draw useful insights by eye. Hence the rise of the sorts of heavy and difficult anti-spam and anti-fraud IT solutions that are becoming prevalent in back-office systems. These solutions are often configured with AI algorithms that help banks to spot fraud and money-laundering—thus, by going through a full audit of financial messages the applications can begin to extract the kind of information that actually protects a bank.

Applications like these can be useful, but for certain types of attacks or concerns they can also be overkill. SWIFT fraud, for instance, can be held off by the simple addition of end-to-end encryption for financial messages. By ensuring the any given message is encrypted and signed after its origination and stays encrypted in transit until it actually reaches the SWIFT network, you can ensure the confidentiality, integrity, and authenticity of every message that gets sent (i.e. you can be sure that the message can’t be read by anyone else, can’t be altered in transit, and can’t have come from anyone but the supposed originator). In this way, it becomes impossible for someone to innocuously change the contents of a financial message to reroute a payment to their own account. If they attempted it, the encryption signature would be broken, and the message would immediately be suspect.

Why SWIFT CSP Compliance Requires Encryption

Right now, message encryption at banks and financial institutions isn’t quite universal. And yet, from the brief description above it should be pretty obvious how much of a difference it can make. One of the reasons that the Bangladesh Bank heist was able to occur was that both banks involved were relying on humans to catch any sort of errors. Miraculously, someone at the NY Fed did catch the errors on the fraudulent SWIFT messages (because a word was misspelled), but that was in the middle of the attack. Though the employee prevented hundreds of millions of additional dollars from being stolen, the bank had already paid out $80 million to attacker-controlled accounts. We can hardly call that a victory.

Meanwhile, if the messages had been encrypted and signed, the attack could have been stopped before any money had been paid into the attacker’s accounts. Since the messages had been altered in transit (very likely they were the victims of a man-in-the-middle attack), their encryption signatures would have been broken, their integrity would be called into question, and they would sent back without the transactions ever being processed. This process can even be automated, in order to minimize the possibility of user error. The only potential area for manual intervention in the process is the comparing of trust words via a command line tool to establish a secure and trusted connection with the recipient. Thus, an entire attack vector closes up instantaneously.

The Challenge: Managing Audit Logs for Encrypted Messages

Okay, if you accept that end-to-end encryption for financial messages in transit is the best and easiest way to prevent SWIFT fraud, your next question should be: How can you make that work in practice? In other words, how can you implement encryption (ideally automated encryption) in such a way that doesn’t interfere with your existing back office IT infrastructure—specifically your ability to monitor your message flows in order to maintain regulatory compliance?

This problem is, on its face, potentially thorny. Why? Because the entire point of encrypting and signing messages is to ensure that they can’t be read or altered in transit, as well as making sure that it’s obvious whether or not they’ve been read during that time—but regulatory monitoring and audit controls essentially require that you be able to read everything that’s coming into or out of your system. If you need to break your encryption in order to audit what’s happening on your network, then what’s the point of encrypting in the first place?

Luckily, this is not, in fact, an intractable problem. Indeed, it’s not even a problem that requires an encryption backdoor (which would also jeopardize the value of your encryption by introducing an unnecessary vulnerability). Rather, it requires a read only key and proxy server.

The p≡p Solution: Read Only Keys and Proxy Servers

At p≡p Security, we’re offering the first fully-automated, turnkey encryption solution for banks that use the SWIFT network or any other financial messaging network. Our software automatically encrypts messages—without requiring any action from the admin—as soon as they enter transit, and automatically decrypts them as soon as they reach the SWIFT network. The encryption is opportunistic, uses tunneling rather than routing, and automatically generates a signature to ensure integrity on all messages.

This prevents attackers from reading or altering messages in transit—but we enable the banks themselves to read messages for regulatory monitoring purposes via a documented encryption “front door,” which comes in the form of a read-only key. For simply monitoring the flow of messages as part of your day-to-day operations, we that make it possible to read messages without breaking the encryption. In this way, you’re able to monitor message flows even though attackers and fraudsters can’t. The encryption itself obviously helps move you into compliance with SWIFT CSP, but this takes it one step further, providing you the transparency you need to be in full compliance.

As a result of this technology, you can easily add encryption protections to any IT ecosystem, no matter how complex. From there, you can function as you normally would—just a couple of quick configuration and installation steps, and you’re ready to go back to business as usual, but with one crucial distinction: now, privacy and security are the defaults. Once p≡p’s installed at the end-points that touch the SWIFT network, our API lets you generate read only keys and access the logs as needed.

Thus, the mechanisms of conducting business and achieving compliance look and feel mostly the same, but the activities themselves are smarter and more secure. Right now, most banks have few protections that would stop a Bangladesh-style heist, but even more are at a complete loss to even identify whether or not an attack has been attempted. This puts banks—and SWIFT—in a situation where it’s difficult to assess the full scale and scope of the threat. Likewise, it’s difficult to say whether attempts have increased or decreased across the board (though it really seems to be the former).

With p≡p for SWIFT, you can not only prevent attacks, you can even visualize any attempts that have been made. Using the proxy server to monitor the financial message flow, you can see any messages that p≡p has flagged as having a broken signature. In this way, you can begin to get a much clearer sense of how many attacks are actually being attempted on your system—bringing you that much closer to gaining a full understanding of the problem. From there, you can become much smarter and more deliberate about your security protocols and spending.

In this way, p≡p for SWIFT can act not just as a solution for message security—offering confidentiality, integrity, and authenticity for all financial messages at the push of a button—but also a catalyst for you to comply more easily

Contact Us for More Insights

Contact Us