Hacker News new | ask | show | jobs
by andrewstuart 1535 days ago
Should banking really be on a cloud platform?

I do believe AWS is likely far more secure than any DIY computing environment but even so, should banking be on cloud infrastructure? I'm not saying I think this is a bad idea but it came to mind when I read this.

Also, is it really a good idea for a bank to be talking openly about its security strategy? Isn't an important part of security not to let on anything that might be used against you? For example if determined hackers know your systems then they can keep an eye out long term for vulnerabilities in those technologies and be ready to strike. Does this sort of thing matter or not?

7 comments

On the first point, I don't see any particular reason why banking shouldn't go with cloud. Obviously banking has regulatory hurdles and things like availability are important so it'll require a specific architecture to help achieve that, but in general shouldn't be a problem.

On the second point, I'd say it depends on the level of granularity and detail. Here they're describing general mechanisms and they're not saying that this is all they do, so I think it's a good thing.

In general relying on obscurity for your security is a bad idea, as attackers will often find a way to get that information. That said I wouldn't give attackers a complete schematic of my env. and every protection, no sense in making things easy for them :)

All you need is a single disgruntled ex-employee to be bribed by hackers to reveal your complete security design.
Social engineering is likely the easiest way to get through security systems.
I don’t see why banking shouldn’t be on a cloud platform, you’re not really giving any reason why we should question it either.

As to your second point, security through obscurity is generally believed to not be worthwhile.

> As to your second point, security through obscurity is generally believed to not be worthwhile.

Security only through obscurity - sure.

But obscurity as an additional layer, as part of a defence in depth strategy, still has some value.

It’s rare for any large org to publicly discuss any details of its security design, let alone a bank. Monzo must be supremely confident in their system to go public with this information, or judge that the marketing/recruitment benefit outweighs any potential risk.

What about you are now exposing yourself to additional risks from e.g. a malicious employee at the cloud provider, or jurisdictional risk from FISA requests to the CP?
Why is risk from malicious employer in cloud provider somehow different from risk from malicious employer in colocation, or even private data center?
Because now you have risk from malicious employees at two organisations, your own AND the cloud provider, instead of just one. Furthermore, you have very little visibility into the cloud provider's security practices. And for anyone saying that cloud providers are inevitably more secure than your own organisation, have a look at the Azurescape vulnerability.
You can, and indeed must, mitigate risks from employees. These are part of regulations around financial services, which starts with PCI-DSS for payments and becomes more encompassing as you move up the service ladder. The types of cloud providers who can tick those regulatory boxes for you naturally wants to pass those costs to someone.
>> I don’t see why banking shouldn’t be on a cloud platform

What if AWS gets cracked/hacked/compromised?

I know it's not happened yet, but it's not impossible.

I guess there are two important questions:

* For individual banks and their customers, is it more likely that an AWS-wide exploit will compromise an AWS-hosted bank, or is it more likely that a self-hosting-specific exploit will compromise a self-hosted bank?

* For society, is it better that security efforts are concentrated in on centralised providers like AWS, or is it better that security efforts are distributed, on individual hosting entities?

That's more or less the same question as "what if the data center/servers operated by the bank gets compromised".

In reality it's always about tradeoffs: who to delegate to and who to trust.

>That's more or less the same question as "what if the data center/servers operated by the bank gets compromised".

The difference is that cloud relies on public services, which once compromised (e.g. via social engineering), allow for lateral attacks resulting in much bigger impact (e.g. Lapsus$) across the complete customer base. This makes social engineering much more attractive in cost vs impact. The resulting monoculture in not only the software, but the infrastructure and configuation also increase the impact on technical attacks on specific exploits.

> The difference is that cloud relies on public services

What are the public services that AWS relies on, and how are they different from a bank's server farm, or a bank renting out space in a datacenter?

The same, really, applies to all other concerns.

Route 53, CloudFront, AWS Console, AWS IAM, etc.

All of these services are hosted by AWS in a multi-tenant fashion, sharing not only the code, but infrastructure and configuration patterns.

>> security through obscurity is generally believed to not be worthwhile

Is not advertising your security architecture "security through obscurity"?

How else would you scale to meet peak demand without being wasteful?

Banking has a fairly predictable usage pattern, but there will be black swan financial events that cause 100-1000x load. On top of that, how else could you serve customers around the globe with reasonable latencies?

These are genuine questions. I’ll admit I’m an engineer whose entire career has been during the cloud era. I don’t see how cloud’s advantages of scaling and worldwide “edge” locations can be replicated by the average bank’s tech team.

> How else would you scale to meet peak demand without being wasteful?

I can only speak to the banks I've have the opportunity to work with who stayed on prem or built their own internal cloud infra; what you call waste, they consider a premium/cost of business for security and resilience. I'm sure a lot of folks would've said the same thing about JIT supply chains (that had been squeezed to be as efficient as possible) until they unraveled.

> I don’t see how cloud’s advantages of scaling and worldwide “edge” locations can be replicated by the average bank’s tech team.

As always, "what are your requirements and what are you optimizing for?" Most folks don't need web scale nor edge locations [1] [2], they'll get by just fine with a CDN and some API endpoints [3].

[1] https://news.ycombinator.com/item?id=19576092

[2] https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

[3] http://mcfunley.com/choose-boring-technology

Are there many examples of companies (today) building 1000x the infrastructure they normally need? I can see how it could be necessary for some companies.

> Most folks don't need web scale nor edge locations [1] [2], they'll get by just fine with a CDN and some API endpoints [3]

Isn’t using a CDN using cloud?

When cloud computing started, our banking clients said ‘never’ to the cloud. Now it is fairly normal depending on the region. In some countries in Asia and the Middle East, it is not allowed yet.
I think a lot of newer banks will be "cloud native" and there are companies such as Thought Machine that are developing cloud-native core banking systems (https://thoughtmachine.net/vault)

For legacy banks, it will be much harder to move a mainframe based core banking system to the cloud, or migrate from a mainframe system to a new cloud system.

To say it with the words of some guys in management why they picked alicloud: it was cheap :)
I am still confused about the potential GDPR issues of using an American company cloud service and the potential American law of needs of the cloud provider to grant access to data. Wasn't this an issue in the EU with Microsoft?