Dan Barton
Director of Software Development & Integrations
LEVEL8 recently announced our recertification to the ISO 27001 standard, as well as exploring how we achieved it and why we submit ourselves to the rigorous process related to certification.
As a demonstration to our clients of our commitment to data security, we believe it’s hard to beat. But we also understand that data security is a living thing, not just a stamp of approval.
So, in this article, I want to drill down further by focusing on how this commitment translates into the software and integrations we build, the specific issue of file transfers and what it means for our clients’ sensitive financial data.
The hidden risk in routine file transfers
A pay run is processed and a payfile needs to go to the bank. A bank statement is issued and needs pulling into the finance system. These are everyday scenarios but that routineness is precisely what makes them a risk when it comes to file transfers.
Financial files are high-value targets. A payfile intercepted in transit could expose sensitive data for a business, its suppliers and its employees. A tampered bank statement could corrupt financial records without anyone realising. Unlike a data breach that triggers an immediate alert, an attack on a file transfer can be completely invisible until the damage is done.
This is why we don’t treat file transfers as an afterthought. They are a critical component of how we approach security within our software development teams.
Why standard FTP isn’t good enough
Legacy File Transfer Protocol (FTP) transmits every bit of data in plain text openly across the network. It has long been accepted that this is an unacceptable level of exposure for most data transfers, let alone sensitive financial data.
Secure File Transfer Protocol (SFTP) addresses this by wrapping the entire session in an encrypted Secure Shell (SSH) tunnel. Data in transit cannot be read by anyone intercepting the connection, and authentication is enforced before any transfer takes place.
Our integrations use SFTP as the transport layer for all data exchanges. Using the case of bank file transfers as an example again, both pushing payfiles outbound and pulling statements inbound.
However, we don’t view this use of SFTP alone as sufficient. It secures and protects the pipe that the data is transferred over BUT it doesn’t provide an adequate defence for the files concerned.
OpenPGP: Protecting the actual data
OpenPGP operates at the file level, independently of the transfer mechanism. We apply two distinct operations to every file: encryption and digital signing. These are complementary but separate protections, each addressing a different threat.
Encryption uses asymmetric key cryptography. The sender encrypts the file using the recipient’s public key; it can only be decrypted by the holder of the corresponding private key. Even if a payfile were intercepted mid-transfer, it would be entirely unreadable to anyone other than the intended bank. Meaning confidentiality is guaranteed at the file level.
Digital signing protects the party sending a file and can identify whether it’s been altered. The sender signs using their private key; the recipient verifies using the sender’s public key. This supports data integrity (any modification causes verification to fail), authentication (the signature cannot be forged), and non-repudiation (the sender cannot later deny having sent it).
Used together, they deliver what is known as a defence-in-depth approach. Simultaneously defeating the SFTP transport security, the OpenPGP encryption, and the digital signature is near impossible and renders anything but the most sophisticated of attacks essentially infeasible.
What do I mean by ‘most sophisticated’? Well, I believe it’s fair to say that nothing short of nation state-level resources and expertise could even contemplate such an enterprise. And even then, I think most security professionals would agree that it would still present a major challenge, most likely destined for failure.
What this looks like for our clients
For organisations using our Unit4 Financials by Coda software additions, such as PPS (Payment Processing System) and SMS (Statement Matching System), this translates directly into day-to-day protection:
- Outbound files (such as payfiles) are encrypted before transmission and only the intended bank can read them
- Every file carries a cryptographic signature the receiving party can independently verify
- Inbound files (such as statements) are subject to the same verification, so data entering your finance system is exactly what your bank sent
- The SFTP connection adds transport-level protection on top
None of this is visible during normal operation and that’s exactly the point. We develop our software solutions with both data security and usability in mind. Our clients go about their daily operations, secure in the knowledge that their data is fully protected.
Beyond the certificate
As mentioned in our recent announcement, achieving ISO 27001 recertification was something we’re hugely proud of. But we also touched on the fact that it only really means something if the underlying processes and procedures are actively adhered to.
The file transfer security I’ve described here is one example of what that looks like in practice: security measures and techniques grounded in established standards, built directly into the software our clients rely on.
If you’d like to understand how these principles, our approach and LEVEL8’s software offerings could relate to your specific environment, we’d be happy to talk it through!
