3 ms·

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, securi

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.

andrewstuart 5y ago
>> 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.
- tome 5y ago
  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?
- dmitriid 5y ago
  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.
  - starfallg 5y ago
    >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.
    - dmitriid 5y ago
      > 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.
      - starfallg 5y ago
        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.
andrewstuart 5y ago
>> security through obscurity is generally believed to not be worthwhile Is not advertising your security architecture "security through obscurity"?
anonymousDan 5y ago
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?
- KptMarchewa 5y ago
  Why is risk from malicious employer in cloud provider somehow different from risk from malicious employer in colocation, or even private data center?
  - xorcist 5y ago
    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.
  - anonymousDan 5y ago
    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.
jl6 5y ago
> 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.

andrewstuart 5y ago

>> 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.

tome 5y ago
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?
dmitriid 5y ago
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.
- starfallg 5y ago
  >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.
  - dmitriid 5y ago
    > 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.
    - starfallg 5y ago
      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.

andrewstuart 5y ago

>> security through obscurity is generally believed to not be worthwhile Is not advertising your security architecture "security through obscurity"?

anonymousDan 5y ago

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?

KptMarchewa 5y ago
Why is risk from malicious employer in cloud provider somehow different from risk from malicious employer in colocation, or even private data center?
- xorcist 5y ago
  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.
- anonymousDan 5y ago
  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.

jl6 5y ago

> 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.