3

I have customers in the financial services industry that insist that a SaaS hosted on public clouds like Amazon's are not as secure as colocation in a private data center. However, I can't find specific details of what those security shortcomings might be. I can only think of 2 differences:

  1. Physical access and security of machines.
  2. Security hardware (packet inspection, intrusion detection) from Cisco et al

For (1) AWS has been audited to ensure physical security of the hardware. I can encrypt all data at rest (hard drive and DB) and all data on the internal network (VPC).

For (2) Cisco and Barracuda offer virtual security appliances that run in AWS. I can run these in a layer in front of the web servers.

Is there some security feature a bank can use with their own data center that I can't replicate on AWS?

Thanks.

projectshave
  • 154
  • 5
  • There's a theoretical attack that will cross VM boundaries in EC2: http://arstechnica.com/security/2012/11/crypto-keys-stolen-from-virtual-machine/ People also feel better at fully controlling their hardware. If they're a financial institution, they will be less cash constrained to get that comfort level. – cjc Oct 06 '14 at 16:04
  • `I have customers in the financial services industry that insist that a SaaS hosted on public clouds like Amazon's are not as secure as colocation in a private data center` - If it were me I'd ask them to cite their sources so that you can look into it for yourself. – joeqwerty Oct 06 '14 at 16:06
  • @joeqwerty It's a widespread perception in the industry, but no one can explain exactly why. As cjc says above, people just feel better if they can control the hardware. – projectshave Oct 06 '14 at 21:06

3 Answers3

6

It may not be a technical issue of security, but more a question of full-control and the (interpretation) of regulatory requirements and compliance.

The Securities and Exchange Act of 1934 (as amended) contains Rules 17a-3 and 17a-4 that relate to the backup and archiving of electronic records. The Financial Industry Regulatory Authority also has rules about Third-Party Providers that basically say a Financial Services Provider can't relieve him or herself of compliance obligations and push them off on a Third-Party Provider.

So basically if Amazon (temporarily) loses (access to) their data, the financial institution is still fully liable and can't hide behind Amazon and their SLA. In that regards doing it yourself and remaining 100% in control is much more important for the regulated business of a financial institution.

A more-or-less unscheduled reboot by Amazon or for instance Rackspace on their schedule instead of your own, can be perceived as quite a large risk

A technical issue is that a lot of the core applications financial institutions use are classic applications, large monolithic databases and applications with large amounts of transactions requiring low latency that are simply not engineered to fit the mould that a successful cloud application requires.

Amazon's terms of service or not nearly as "bad" as some cloud providers, but they only offer to implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure and the customary disclaimer favoured by many: "NO REPRESENTATIONS OR WARRANTIES OF ANY KIND" should be expected...

HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • 1
    For a hedge fund, this compliance obligation would exist with all their vendors: brokers, clearing houses, custodians and many others. Whether the vendor runs on a cloud or not shouldn't matter. Ironically, your links are to FINRA, who recently announced they are moving their systems to AWS. :-) – projectshave Oct 06 '14 at 21:09
  • They are not the only regulator doing so. As I said it is also more the interpretation of the regulatory requirements than the letter. And what is good for the goose is good for the gander; not always the case with regulators and law makers versus the financial industry. – HBruijn Oct 07 '14 at 05:39
  • Do you know who else? My salesmen want some examples. Thanks for your help! – projectshave Oct 07 '14 at 17:17
  • E.g the [Dutch Regulator](http://www.computerweekly.com/news/2240202671/Dutch-banking-regulator-approves-use-of-AWS-public-cloud-in-the-financial-sector) is now allowing cloud, where before they required in-house (which is often in data centers obviously) equipment and solutions that could be inspected. http://www.fx-mm.com/32396/blog/dutch-regulator-takes-the-lead-for-migrating-banking-services-to-the-cloud/ – HBruijn Oct 08 '14 at 03:05
1

Just recently Amazon had to reboot parts of their infrastructure (they talked about less than 10%: http://aws.amazon.com/blogs/aws/ec2-maintenance-update/) due to a security vulnerability.
Details at the time were unknown as they were under embargo.
Now it is clear that this Xen vulnerability was the cause of it: http://xenbits.xen.org/xsa/advisory-108.html

Quote:

A buggy or malicious HVM guest can crash the host or read data
relating to other guests or the hypervisor itself.

As a customer you have no control over where your instances are running (as in: who your "neighbors" are).
A bank running their own datacenter or renting their own private cloud can rule out a compromise like this entirely.

This is obviously not trivial to exploit by an attacker.
Even if he is in possession of such a unknown exploit, targeting an individual site is almost impossible.
If avoiding the public cloud because of this makes sense for that institute is pretty much up to their own risk assessment.

faker
  • 17,496
  • 2
  • 60
  • 70
  • 3
    A private cloud will have vulnerabilities, too, and chances are you won't be on the pre-announcement lists like Amazon is. Also, Amazon **does** allow you to control who your neighbors are: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedicated-instance.html – ceejayoz Oct 06 '14 at 17:48
  • 1
    @ceejayoz Right, but a hypervisor breakout vulnerability on a private cloud is far less critical. Only your VMs are running there. If you cannot trust your own VMs, then, oh well. Also yes, they do that, and they call it VPC. Virtual *private* cloud. I thought we are talking *public* cloud here. – faker Oct 06 '14 at 17:52
  • Despite the name, a "VPC" is not what the OP is talking about (nor is it really considered a "private cloud" by most definitions - it's still Amazon's cloud offering). The question states "colocation in a private data center" as their intended definition of a private cloud. – ceejayoz Oct 06 '14 at 17:57
  • 1
    @ceejayoz fair enough. I can see how that is confusing. I read that differently as in they were discussing two options: 1/ public cloud 2/ private datacenter, no cloud at all. In any case, my concerns are only about truly public cloud instances (hardware is shared). Not private cloud instances (hardware is exclusive to customer). – faker Oct 06 '14 at 18:14
1

If you have physical access to a machine, you can compromise it, always.

With Amazon having this access you are one step further to being hacked than you are when you have your own servers in your own bunker .. I mean data center.

They still need to decrypt your data, but they can make a snapshot and do the decryption offline (and they have a huge data center waiting idle for some task) and in 5 years they know your biggest customer, how much money he has, how much he spends on your banking service, and so on.

That's not a problem with Amazon alone. Other players like for example Microsoft build a huge data center near Dublin, completely in the middle of nowhere, but right next to a huge "bread factory" of the same size. They are only baking bread there, true story! ;)

user246830
  • 21
  • 1
  • after reading my post i realzed i missed using the word "huge" a few times, please add where appropriate :p – user246830 Oct 06 '14 at 20:09