lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAH8yC8mY5e2LsMPiHpyFhEw1XycLWCNbm0YZJtEW=RRYOk=DkQ@mail.gmail.com> Date: Sat, 9 Nov 2013 16:05:14 -0500 From: Jeffrey Walton <noloader@...il.com> To: Yvan Janssens <ik@...nj.me> Cc: Full Disclosure List <full-disclosure@...ts.grok.org.uk> Subject: Re: Cloud Questions > The first problem is TCO. Cloud services are easy to set up (both as a > vendor and as a user), and have little to no "hard" start-up costs. > (costs that initially are billed as startup costs, before the service > payments start). Also see http://www.gossamer-threads.com/lists/openstack/dev/32772, where some are considering charging you for the I/O to securely delete a VM! Jeff On Sat, Nov 9, 2013 at 9:50 AM, Yvan Janssens <ik@...nj.me> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello, > > I will split my answer in two parts, as they represent both views I > regularly experience. They aren't all related to security. > > The first problem is TCO. Cloud services are easy to set up (both as a > vendor and as a user), and have little to no "hard" start-up costs. > (costs that initially are billed as startup costs, before the service > payments start). This results in decisions which aren't really thinked > throughly about in a lot of cases, resulting in poor setups both by > the vendor and by the end-user/customer. Being able to ship fast also > means that you can make mistakes fast - several providers have been > caught in the past while I was using them on blatant mistakes. > > Another problem is that you trust a service to a third party provider, > which has full access to the data. I know, there are ways to prevent > this/make this difficult, but in the end it will not be feasible on > the long term to employ such techniques. Targeted attacks will always > succeed, but are easier on cloud services to my opinion. Support > services are useful sources for social engineering (check some of the > last cases of DNS hijacking), since they are used to handle requests > for all customers, and not only internal employees. > > The other problem is that you share a physical computer with someone > you don't know and cannot trust. Information leakage techniques have > been discovered [1] and it wouldn't be the first time that someone > finds a clever way to break out of the VM. [2] > > It is also more feasible to DoS your application if the physical > hardware is shared with others if they aren't trustworthy. Most > providers monitor extensive resource usage, but try a cheap one, put a > VM on full RAM capacity, disk I/O requests and CPU usage and see how > long it takes to get a notice to ask you to inspect the machine. > > There is also a huge thing to tell about stuff which used to be > conspiracy theories about surveillance, but this is out of scope for > this response to avoid indulging trolling. To my opinion cloud > services are good for a temporarily burst of CPU resources, not to > store data, and not to be used permanently nor as a SPOF. I sometimes > use cloud services to launch a build of a large source tree, and then > dispose the machine, but I would never put ownCloud on it to store PGP > private keys without a password or my credit card numbers and bank PINs. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists