10 ms·

Technology, technology, blah blah blah. Tell me this: will Google indemnify you against all your losses proportional to the amount they are to blame? i.e. if

• occamrazor 6y ago
  The SLA normally covers only the cost of running the VM, or a small multiple thereof. You can negotiate a better SLA, but you’re unlikely to get it. A better alternative is insurance. There are many insurers that offer contingent business interruption coverage for failure of cloud infrastructure, among other causes.
• panarky 6y ago
  Will the bank indemnify you against all your losses if a thief breaks into your safe deposit box?
• sl1ck731 6y ago
  I've been thinking about this in regard to AWS. The encryption at rest for most things is completely transparent so the only thing your really protected against is someone walking into a data center and grabbing your drive somehow. Or improperly disposed drives. Maybe some kind of hypervisor or SAN exploit but I don't know much about that. AWS seems to have turned part of the cloud operating model they are supposed to be responsible for back onto the user and no one questions it.
  • WrtCdEvrydy 6y ago
    Sorry, here's your cloud fees back.
    • ape4 6y ago
      Self hosting (remember that) seems best for really confidential things.
      • ENOTTY 6y ago
        Self hosting is no longer realistic because all the data you actually want to compute on is now in the cloud. The egress costs of that data into your self hosted environment would destroy you. Imagine a world where the cloud produces more data at a rate that exceeds the pipes leaving the cloud. You are quite literally locked into computing within that same cloud.
        • roynasser 6y ago
          Its very realistic! Its being done at this moment! (amazing, isnt it?) lfmao... but jokes aside, the "cloud" is just series of datacenters with less choice of a brand, you do realize this? There is no such "cloud" as you say... Internet allows exactly for decentralized data (among cloud-1a-b1-c2 to cloud-2b-5x-3h is not all "in the cloud", its the same as datacenterA to datacenterB.... proximity still has an effect, as do all other network conditions...) Dont let the marketing sandcastle trap you in!
      • londons_explore 6y ago
        Except Google has a much much bigger budget for security engineers than you have...
        • thu2111 6y ago
          In this threat model that's a downside, not an upside. SEV is not, to me, a convincing security model. It was tried a long time ago, it doesn't work. SGX uses small enclaves for a reason. Hacking your average Linux box is quite easy already, which is why compromised passwords flow like water. With the SEV threat model the cloud provider is no longer on your side. They are no longer defending you against threats, they are a threat. That's why you want encrypted RAM. But you're being threatened by one of the world's most advanced security organisations, a company that literally pays a large team to do nothing but locate zero day exploits all day, every day. And they swap zero days with other major tech firms too. So they have access to bugs in your OS before you do, and this is structural, there's no fix for it. Worse, they recommend you use Google-controlled, 'hardened' OS images. But that makes no sense because you're trying to defend yourself against Google. Finally, it's very unclear to me that the Linux kernel is going to accept bug reports of the form "the hardware behaved in arbitrary incorrect ways because it was redefined by a malicious hypervisor on the fly". The kernel isn't designed to deal with a malicious hypervisor. It's not going to be checking the results of things that might be hypercalls to check the hypervisor didn't hand back invalid results. In the past this has caused big problems with userspace apps trying to run on malicious kernels: the kernel was able to break in to the encrypted memory space immediately because the kernel could manipulate syscall returns in ways the app didn't expect. But let's put OS hacking to one side. SEV has a very poor track record of security. There were dozens of bugs in their firmware in past revisions, ordinary C type buffer overflows. Then there were basic crypto bugs: you could send the firmware an invalid point on the elliptic curve and it wasn't checking for that, things like this. Perhaps Google has audited AMD's firmware now and have knocked out all these problems. Perhaps not. Who knows - they mention working with AMD on performance but not security. Moreover, SEV doesn't have anything to say on the topic of side channel attacks. And unlike with SGX, because the whole point of SEV is you use existing software and operating systems, there's also no fix for this problem. Normal kernels and apps aren't designed to resist a compromised hypervisor. SGX enclaves are designed for-purpose so you can argue that they're the smallest piece of app logic that needs to process your data and you can go to town on securing it, whilst the bulk of the app handling resource management, connections, scheduling, etc, is blinded by cryptography. Enclaves expect the host to attack them because they were written that way. They can do things in a less efficient but more side-channel proof way. With SEV this is theoretically an option (could run some specially written hardened OS), but, it's not how it's being advertised so nobody will do it.
  • gtsteve 6y ago
    There are other use-cases. For example, you can crypto-shred an unlimited amount of data just by deleting the key associated with it. You can also set up workflows such as your client owning the encryption key that encrypts data held by you and they can revoke it at any time. Slack has a similar system and I was asked by a large financial institution about the same. I expect to see this more in future.
    • aj3 6y ago
      > For example, you can crypto-shred an unlimited amount of data just by deleting the key associated with it. Sounds like a great target for ransomware crews!
      • gtsteve 6y ago
        Yes indeed! But you mark the key for deletion and there's a minimum time of 7 days before it is deleted and during that time you can't use it. You've got quite a while to realise there's a problem and fix it.
        • aj3 6y ago
          This sounds reasonable.
        • toomuchtodo 6y ago
          How many critical domains and TLS certs expire with many months of notice? In a proper shop, someone will be alerted. Most places are not on the ball, and that alert is going to go entirely unnoticed.
          • gtsteve 6y ago
            You'll probably notice your disks not mounting and your vms not starting up and your users not being able to take data etc. Or not, depends on how frequently accessed it is. We'd definitely notice.
  • acdha 6y ago
    AWS encryption at rest comes in two flavors: their managed keys protect against the threat you managed (which is still important for some compliance targets) but if you use customer-managed keys you can go further and protect against compromises in your accounts - server A only has access to encrypt, server B can only decrypt, role C in account D can encrypt data before transferring it, even the account root user can’t update the policy to break that, etc. It’s considerably more work but also more benefit.
    • aj3 6y ago
      Not sure what benefits are there in scheme you described. Which threat exactly is mitigated by using this tech?
      • acdha 6y ago
        Simple example: say I use S3 with the Amazon-managed key. Anyone who has a policy granting access to a bucket — and lots of people love to write bucket policies with Resource:* — can read or write objects in that bucket using that key. If you use a CMK, you can write custom policies which are both far more restrictive and shouldn't change as much as other resource types. That means that I could, say, have a policy which says the key-admin role/group/user is the only principal in the account which can update the key settings at all (even administrator can't do that then), the writer role is the only one with kms:Encrypt, and the reader role is the only one with kms:Decrypt. No matter what S3 access you have, if you aren't one of those roles you won't be able to use the encrypted data. This is probably also in a scenario something like “central group A provisions the KMS, devops group B creates lots of other resources using that key”. You can add conditions, too — “anyone in our account can encrypt, decrypt requests can only come from this IP address or VPC”, “only requests from this AWS service are accepted” (i.e. that compromised EC2 instance can't use it), “access to data encrypted with this key can only be done in the two regions we approve of that”, “this particular encryption value must be used on all requests”, etc. https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-example https://docs.aws.amazon.com/kms/latest/developerguide/key-po... https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html https://docs.aws.amazon.com/kms/latest/developerguide/policy... That adds an extra layer of defense: if I compromise a user, even one with some level of administrative access, who doesn't have the CMK access all I can get are errors or encrypted data rather than the raw data. If you're careful you can architect environments where a person can deploy code without direct access to secrets or a system can stream data through to an encrypted store (if you are storing PII, this can be a huge difference between “all of our users” and “only the ones who used the system during this time period”). In some cases these can be bypassed (i.e. a CMK might not allow Administrator to access it directly but they could possibly issue credentials for a user who does have access) but you're preventing generic attacks which just scrape up everything that compromised credentials have access to, and hopefully increasing both the level access required and the likelihood of producing an audit alert.
• theevilsharpie 6y ago
  Any contract worth its salt is going to limit its liability to the extent feasible. Unless Google Cloud specifically offers an insurance policy against security breaches (spoiler: they won't), the most you can expect is to be refunded your hosting fees. That being said, you can always buy your own insurance to protect against that kind of risk, and _the insurance provider_ may mandate using a technology like Confidential VM in order to qualify for insurance coverage.
• simonebrunozzi 6y ago
  You raise a very, very important (and debated) point. (disclosure: I was at AWS 2008-2014, and VMware's cloud business 2014-2016; opinions my own, no disclosure of secrets, etc etc) Most SLAs only indemnify you for the paltry infrastructure costs in relation to the downtime or accident. Few SLAs are more extensive, covering for example data loss. AFAIK, no SLA exists that extensively cover such type of loss. (perhaps with the exception of heavily customized contracts, sometimes part of a military contractor deal, where numbers are out of this world and there's huge margins for clauses and exceptions everywhere). They don't exist for two reasons, IMHO: 1) it's very complicated to define metrics related to the amount to be indemnified, and 2) it's hard to keep that amount current, based on how the data changes, or the architecture changes. It would be interesting to see an "insurance" for these kind of things. I once thought of such a product, just after I left AWS, and for a little while I entertained the idea of launching a startup to go after that market.
  • omk 6y ago
    Interesting. I wonder if a $1000/month insurance linked to a customer's subscription would be enough to provide a 1000x cover? Essential proving that the risk quotient is < 1/1000 subscriptions. Such an offering by a cloud provider might make a huge statement.
    • simonebrunozzi 6y ago
      The huge problem with this is that you are giving an economic incentive to the customer to "go down" for hours or days.
      • saagarjha 6y ago
        Yeah, but unplugging your servers does not count as "my provider is down".
        • simonebrunozzi 6y ago
          Hard to prove bad behavior, though.
• zeroxfe 6y ago
  Nobody does that -- it makes absolutely no business sense to a service provider. If you want your $50 million back, you buy insurance. :-) The best you can get from vendors/service providers are SLAs, where damages are meant to be mildly punitive (amount x number of affected customers can add up and hurt the provider.)
• taf2 6y ago
  I think what you are thinking of is called insurance... it’s different from an SLA... you can get insurance to help protect your business but it can be expensive
• vmception 6y ago
  Nice, time to launch Silk Road 4.0 I'm just kidding The Empire brand is so much bigger and more valuable