Security in business lending: how to get the balance right

Robbing a bank is now digital

– so said Brad Drysdale, Field CTO at Kong, which provides API and microservice management.

He was speaking at a Trade Ledger panel on Security in business lending: how to get the balance right, and told the audience that it is now essential to use the ‘zero trust’ approach: “Don’t trust, by default, even if a person or service has been verified previously,” he said. Riccardo Pietri, VP, Cybersecurity, Risk & Compliance at Trade Ledger, the business lending platform provider, said that even if a secret, token, key or password ended up being revealed by mistake, for example in a plaintext file or hard-coded, the zero-trust approach is designed to catch it.

This stringent approach is essential, as data is increasingly shared across the financial services ecosystem, typically using APIs that can carry rich information between banks, apps, cloud accounting systems and so on.

‍

What is zero trust?

Security was once handled by firewalls, which are like a moat around a castle. The firewall protects the boundaries of a service by controlling who’s allowed to connect. Once inside the firewall, everyone is trusted.

But with the cloud, it’s hard to define the perimeter. Zero trust dispenses with the idea of the moat and castle and checks every request for access. It challenges connection requests with queries such as “Show me your ID. Who are you connecting with? Where are you going?” If you use Gmail you’ll be familiar with this – if you log in to your email from a new device, you get an alert, asking if it’s really you.

If a developer mistakenly saves a password in their code, zero trust is designed to catch anyone else who tries to use it. It will recognise the first time a different device attempts to use a username and password from a different device and challenge it.

‍

Security by design

Security must be baked into APIs at the design stage,” Brad said.

Ravneet Shah, CTO at Allica Bank, agreed. She said:

"We’re seeing more API security breaches, and we need to fix this further back in the design process – shift left.”

This refers to Agile development, where project phases are arranged left to right, with the earliest phase on the left – design, code, test, deploy.

Ravneet said that although people often think of security as being about external threats, internal threats too need to be well managed, since people can be subject to human error. Automated monitoring can help here. Riccardo gave the example of a developer who downloads 10 times the usual number of repositories to work on. This could be a warning flag – are they about to leave the organisation, are they stealing information, or has their account been compromised? “We need to react quickly – cut the access to avoid the threat,” he said. “Automation coupled with good monitoring and alerting reduces the response time.”

Continuous compliance

Rhys Evans, Head of Field Security at AWS Australia & New Zealand, highlighted continuous compliance. It can be tempting for security teams to wait until an audit is due before they assemble their compliance data, but this means they may be compliant only once or twice a year. A better approach is to monitor compliance continuously and use a dashboard to display the results. “Regulators are asking for this much more now,” he said.

Ravneet posed the question: “Are you writing your tests for security?” She recommended as best practice the use of checklists to review code, peer review, rotating keys, and educating developers.

How do you test services that are embedded into a third-party website?

Brad said that testing, and how it’s done, matters more than ever.

For banking apps, testing has tended to focus on usability, and this can be done end-to-end as the bank owns the app. But APIs play a far bigger role than surfacing data on a web page.”

APIs can feed banking data into third-party apps (such as ‘super apps’, which consolidate information from multiple sources, as mentioned in Trade Ledger Business Finance Predictions 2022). More significantly, they enable embedded financial services. Brad gave the example of booking a hot air ballooning weekend online. Insurance could be offered as part of the booking journey, with the insurance company transacting via the ballooning website – a third party. “You can imagine the testing required,” he said. “Look at the lifecycle of the API – it needs a lot of focus.”

Zero blame – as well as zero trust

Rhys warned against security theatre. “You could buy a lot of products from security vendors,” said Riccardo, “but it doesn’t make you compliant.”

Rhys talked about an AWS process that can be used by companies of any size. He said everyone coming into AWS is encouraged to raise a ticket if they see a potential security issue. “There’s no blame culture, and no consequence for reporting a potential security issue in error. Duplicates are great! Tickets, Tickets!”

Riccardo said that tickets provide evidence that could help track down a problem.

The approach is not to ask colleagues: ‘Why did you click on a link’, but to say: ‘It’s part of your job to click links – now let’s take a look at what happened’.”

Discover more about how to protect your business lending offering - get in touch today and let’s talk.

‍