[HN Gopher] Evervault
___________________________________________________________________
Evervault
Author : omarfarooq
Score : 90 points
Date : 2021-12-17 14:02 UTC (8 hours ago)
(HTM) web link (evervault.com)
(TXT) w3m dump (evervault.com)
| theamk wrote:
| Previous discussion on the implementation of their technology:
| https://news.ycombinator.com/item?id=28127961
| redwood wrote:
| "Never have a data breach" is the kind of statement that can
| cause you to lose credibility with security pros
| arcurn wrote:
| Thanks for the comment -- I understand the sentiment, but we
| invest a lot more effort in trying to persuade security pros
| and cryptographers through the technical and security features
| of the product itself.
|
| The people making the decision to use a product like Evervault
| isn't always a technical/security audience, so it's a tricky
| balance to navigate. We want both engineers and non-engineers
| to understand why using Evervault is important, so sometimes we
| fall short. This feedback is much appreciated though, and we'll
| definitely keep it in mind next time we do a website revamp
| (soon!). Thank you!
| raesene9 wrote:
| If I can make a couple of suggestions for winning over that
| crowd.
|
| 1) As OP said, dial back "never" statements, there's no such
| thing as perfect security :)
|
| 2) When I look at a solution like this which essentially
| requires a lot of trust from customers (if your servers get
| hacked or your code is insecure, that's going to be a bit hit
| for your customers), I look for 3rd party validation.
| Something like a published 3rd party audit from a reputable
| consultancy, using good named consultants, with a clearly
| stated scope of work is likely to help allay fears about
| trusting a third party with a solution like this.
|
| 3) Talk some more about the experience of your team. What
| you're doing is hard to do well, so explaining where your
| team has experience of doing things like this in the past,
| will help.
| tailspin2019 wrote:
| Great comments. Completely agree. Third party validation
| for something like this really goes a long way.
| arcurn wrote:
| This is very helpful -- thank you!
|
| On #2, we have carried out security audits with Cure53[0]
| and others, which we are happy to share. We also have a
| root of trust which is provably embedded in the AWS Nitro
| System[1]
|
| #1 and #3 are great suggestions which we will implement in
| our next website revamp. Thanks!
|
| [0]: https://cure53.de/ [1]: https://evervault.com/blog/e3
| tailspin2019 wrote:
| > we have carried out security audits with Cure53[0] and
| others
|
| You need to be shouting about this on your new security
| summary page :)
|
| It all builds a story of trustworthiness.
|
| It seems like you have quite a lot of info captured in
| your blog, but the "blog" section is definitely not where
| I go first when I'm doing a quick scout of a
| company/service to size them up (from a "can I trust
| these guys?" perspective).
| redwood wrote:
| That's fair it's always a tough balance maybe "Industry-
| leading data breach protection" or something
| ohyeshedid wrote:
| and what metrics are we using to claim "industry-leading"
| here?
| [deleted]
| rdl wrote:
| This looks pretty cool (particularly that it's easy to use). If
| you're already using AWS you could just use nitro enclaves to do
| this directly, but this makes it easier to use, and easier to use
| if you're not using AWS but trust AWS (+ evervault, particularly
| for availability). It's cool to see this for something other than
| just payment card info vaulting.
|
| Biggest problem I could see with applications is that if you were
| using this inside a larger application, someone with control of
| the application could just change the less-secure application to
| bypass Evervault entirely. Wouldn't compromise historical/data-
| at-rest data already inside evervault, but would bypass it for
| new submissions. That doesn't mean this isn't useful, but it
| would be a concern in some use cases.
| atonse wrote:
| If someone has control of the application, aren't all bets off
| at that point?
|
| At some point, your application has to decrypt the data to work
| with it. The person with control of the application would
| exfiltrate data that way.
| arcurn wrote:
| This is mostly true, but even if somebody manages to get
| access to an application runtime there won't be a major data
| leakage issue using Evervault because all data has been
| encrypted using a key that our customers don't host.
|
| All plaintext data processing happens on Evervault's
| infrastructure, so our customers don't have any runtimes that
| handle sensitive data in plaintext.
| tomc1985 wrote:
| So basically all I have to do is hack someone's DNS settings to
| undo all this encryption stuff?
| encryptluks2 wrote:
| From their ToS:
|
| "You provide User Data and Personal Data to Evervault with the
| understanding that any security measures we provide may not be
| appropriate or adequate for your business, and you agree to
| implement Security Controls (as defined below) and any additional
| controls that meet your specific requirements. In our sole
| discretion, we may take any action, including suspension of your
| Evervault Account, to maintain the integrity and security of the
| Services or Data, or to prevent harm to you, us, customers, or
| others. You waive any right to make a claim against us for losses
| you incur that may result from such actions. You are solely
| responsible for the security of any Data on your website, your
| servers, in your possession, or that you are otherwise authorised
| to access or handle."
|
| Yeah, no. You either practice what you preach in your advertising
| or don't advertise what you won't commit to.
| scubbo wrote:
| I don't see anything objectionable in here. What do you take
| issue with? There's always an onus on customers to ensure that
| the service being provided will actually meets their needs.
| [deleted]
| ohyeshedid wrote:
| It doesn't align with their marketing terms: "Never have a
| data breach", "Core benefits: Zero Data Breaches", etc.
|
| Promises like that, with liability waivers in the fine print,
| are always worthy of suspicion.
| MrWiffles wrote:
| Generally speaking, I agree with you in principle, but I
| think the aim here is to basically be able to escape a big
| lawsuit if a company uses them but screws up the
| implementation and doesn't follow directions, then faces a
| loss, then sues Evervault to get their money back. It's not
| Evervault's fault if you can't follow simple directions, in
| other words. It's also not their fault if you use them for
| 99% of things but your dev team just slips up and forgets
| to integrate some piece with Evervault at some point along
| the way, thus creating a vector for data leakage and/or
| attack. Can't fix stupid :-)
|
| But yeah I see your point too - you don't go by "what I
| think they intend", what gets argued in court is the LETTER
| of the law, not necessarily its intent. Both sides have a
| point here.
| arcurn wrote:
| Thanks for pointing this out. I agree that the tone here
| doesn't align with what we want to commit to with our
| customers.
|
| We'll do some work on improving this (probably removing the
| entire clause around waiving a right to claim) and ship the
| changes ASAP.
| MrWiffles wrote:
| Chiming in real quick to say: NICE! I really like how the home
| page gets right to the point of what it is and shows you a code
| sample, not a bunch of loosey-goosey executive-targeted buzzword
| copy written by an English major without a clue of what they're
| talking about or some GPT-generated garbage. It's fantastic that
| you guys get to the point of WHAT THE DAMN THING IS - and that
| makes me want to use it in the next project where this might be a
| good fit.
|
| Bookmarked in Raindrop for future reference. Next time I need to
| encrypt data in an app, I'll see if this is a good fit. Thanks
| for sharing!
| rodorgas wrote:
| Pardon my ignorance, but isn't HTTPS already encrypted? What's
| the difference here? Maybe by using this, stored data will also
| be encrypted?
| arcurn wrote:
| We encrypt data at the field level so your infrastructure
| (including code and database) never handles sensitive data in
| plaintext. We also help you manage the decryption keys, so
| rogue developers or data breaches are as close to
| inconsequential as they can possibly be.
| xori wrote:
| > we can't decrypt your data.
|
| But I thought the point of the cages, is that _do_ decrypt the
| data. And any government mandated backdoors would then go into
| that process. You're not doing any homomorphic encryption here.
|
| I guess my issue, is that you see both the keys _and_ data, not
| just one.
| anshublog wrote:
| @xori, homomorphic has scale challenges. curious what you think
| of it and have you seen it in production? also, have you heard
| of polymorphic?
|
| (BYOK is an extremely important feature for this category.)
| carlosdp wrote:
| This is a really nice implementation! Looks really simple to use.
| I think a lot of devs these days would _love_ to not have to be
| responsible for sensitive data these days, especially with GDPR.
| scandox wrote:
| I had a bit of struggle to understand precisely how this works. I
| haven't had a need to use similar technology...But at least one
| mechanism seems to be:
|
| 1. Data submitted by end user
|
| 2. Intercepted by an Evervault Server and encrypted
|
| 3. Hits my Application where I utilize the encrypted data without
| being able to see it
|
| 4. Submit it to some other service (Twilio say)
|
| 5. Relay intercepts request and decrypts required fields before
| data is sent on to Twilio.
|
| 6. Presumably response from Twilio is also encrypted? Or it's
| optional?
|
| I'd be interested to hear from anybody who has implemented these
| kinds of flows to better understand uses cases and the
| complications etc...
| anshublog wrote:
| I have seen fully encrypted end to end flows to Twilio. You got
| it 99% right here.
|
| (There's some nuance around re-encryption proxies and how that
| is handled.)
| theginger wrote:
| Why does this website feel really familiar to me? The styling
| makes me feel like it's a product of a company i've used before
| with exactly the same website, i thought maybe it was hashicorp
| but a quick look and thier styling isn't quite the same.
|
| It is a common template ? Where else might i have seen it ?
| maicro wrote:
| Kinda feels like Parsec (https://parsec.app ), but honestly
| there are so many websites in that format these days...And
| yeah, this one even has a free tier and a paid tier, and a nice
| convenient "Pricing" link up top... Though to be clear, I'm not
| against valuable services getting paid; and this one at least
| makes it fairly clear what they _do_ on the front page...
| js4ever wrote:
| I wonder how large is the submarket of developers aware of the
| need to encrypt data ... And also OK to bring a third party like
| evervault into the deal.
| anshublog wrote:
| I am founder & CEO of Skyflow PII data privacy vault. We are
| vaguely similar but our product line is focused on offering
| "PII database as a service" - and not really relays and cages.
| Happy to answer any questions.
|
| To answer your question: "market for encrypting data" is
| infinite but in reality that's not really a market since
| encryption is a concept and not really a product.
|
| The markets that do exist are: * GDPR & CCPA compliance (think
| OneTrust) * Data Residency (think Cloudflare) * Data Security
| as a Service (think Okta/Auth0) * Customer Data Management
| (think CRM)
| arcurn wrote:
| Hi! Founder of Evervault here.
|
| You're totally right in saying the number of developers who are
| actively integrating encryption is pretty small as of today.
| What we're trying to do is improve developer experience to a
| point where encrypting all sensitive data is a no-brainer.
| Still early days here, but we're expending a lot of energy to
| make this happen.
|
| Re: third-party dependency -- we think the same way at
| Evervault. We bring third-party vendors into the mix if we
| think they can build something better than we could do
| ourselves, which is why we partnered with AWS on their Nitro
| Enclaves[0] product. Our root of trust is the AWS Nitro System.
| For customers who still aren't comfortable with us managing
| their security posture, we also offer on-prem and in-VPC
| options.
|
| [0]: https://evervault.com/blog/e3
| taylorhughes wrote:
| Really appreciate the plain "how it works" section just below
| the fold on the homepage. So many security products offer
| fluffy marketing pages -- it's clear what this does from an
| implementation perspective right away.
| ignoramous wrote:
| > _I wonder how large is the submarket..._
| large enough to warrant a crypto-currency:
| https://build.scrt.network/
| anshublog wrote:
| By that definition, everything is a trillion dollar market.
| :)
| ithkuil wrote:
| Perhaps it's not as small as you think. It all depends on who
| is the adversary in your threat model.
|
| If you have applications that run in the field, and need to
| perform computation on data you don't want to be seized if the
| adversary gets hold of the device itself (state or private
| agents), then this may be a relatively low cost way to address
| this concern.
|
| If you search for a solution for all possible threat models,
| well homomorphic encryption would all the boxes except it's too
| slow for doing anything practical with it.
| tmikaeld wrote:
| If someone has access to the physical device, that device
| need to be able to display the actual data = the device has
| the "secret" information already.
| ithkuil wrote:
| if you need to output the secret, then you have no use for
| offloading computation on encrypted data.
|
| There are scenarios where you can compute on encrypted data
| and produce a result that doesn't leak the entire data.
| tmikaeld wrote:
| That is a use case, sure, but this service doesn't
| provide computations, only management of keys.
| ithkuil wrote:
| I don't know; I just read what's written on their home
| page: Evervault Cages Process
| the data you encrypt with Relay or our SDK by deploying
| your code in Cages -- isolated serverless functions
| hosted on Evervault. Cages automatically
| decrypt your data in an isolated environment, so you can
| still process data without handling it in plaintext.
|
| perhaps I misunderstood what that feature is; if that's
| true I suspect it's not entirely my fault, but there is
| something misleading in the product description.
| kodah wrote:
| > There are scenarios where you can compute on encrypted
| data and produce a result that doesn't leak the entire
| data.
|
| I believe what you're referring to is homomorphic
| encryption.
| ithkuil wrote:
| Yes I did mention that technique in my comment upthread.
| But there is a more simple stupid way: just perform the
| computation somewhere else, on some server you own, one
| some server you rent, on some service you rent... From
| the POV of the device in the field it doesn't really
| matter.
| tailspin2019 wrote:
| Yeah I would definitely be wary about this. A self-hosted
| option, even if not open sourced, _seems_ like a no-brainer to
| me. Nothing wrong with providing it as a SaaS as well.
|
| Also being in the EU the first thing I look at is where the
| company is based and/or where they host my data, but I've
| trawled through this site and cannot seem to find a company
| address anywhere or details of their hosting setup? Nor is
| there a single "Security" page which outlines their credentials
| and security measures. I feel like these are critically
| important for a business like this which needs to build trust
| with potential customers.
|
| The website design looks superb though and the product is
| definitely interesting.
|
| EDIT: Ah noticed on the jobs page that they're in Ireland, but
| looks like their app front-end is hosted on Vercel and (per
| below) backend on AWS.
|
| EDIT: And further confusion from the "Evervault Inc" in the
| footer and "Evervault Ltd" on Privacy Policy page. I'm not
| clear if this is an Irish company (and therefore covered by EU
| law) or a US company? These details are important for potential
| European customers.
| tmikaeld wrote:
| They use AWS and their security enclaves called Nitro [0][1]
|
| [0] https://aws.amazon.com/ec2/nitro/
|
| [1] https://evervault.com/blog/e3
| tailspin2019 wrote:
| Thanks! Well I did ask for detail and [1] certainly
| delivers that...!
|
| Definitely still needs an exec summary "Security" page
| though with a callout to relevant blog articles if
| necessary.
| arcurn wrote:
| This is a great suggestion, thank you! We'll get to work
| creating this.
| tmikaeld wrote:
| Was thinking the same thing, there's a reason encryption and
| auth software is open source and run internally (like
| hashicorps Vault).
|
| Is it easier to use than setting up a Vault cluster? Yes,
| without a doubt, so for building new things as a single
| developer, it definitely has a market.
|
| It would be more difficult on larger businesses though, since
| they have internal processes & certifications, that now need to
| rely on a 3rd party.
| yardstick wrote:
| > Encrypting cardholder data with Relay means that your system
| does not handle cardholder data, making Evervault your Cardholder
| Data Environment.
|
| Does this mean Evervault is a PCI DSS service provider? Do you
| have an AOC yourselves and are you audited annually by a QSA? I
| had a quick look but couldn't find PCI specifics on the site.
| ShaneCurran wrote:
| Yes! We have a page coming soon, but Evervault is a QSA-audited
| service provider and we can reduce your PCI compliance scope to
| the simplest form (SAQ-A)
| MrWiffles wrote:
| A thought occurs to me: how would you envision this working for
| healthcare data governed under HIPAA? As you're probably aware,
| the requirement is to have PHI "encrypted at rest" and that I'm
| not supposed to share or transmit the data outside of my
| infrastructure or to that of partner companies who've signed a
| BAA.
|
| My understanding of the regulatory parts of the law here is
| probably flawed in some way, so I apologize for that in advance,
| but could you go into a little detail about how that might work
| from a business-to-business/contracts standpoint? Like, do you
| guys sign BAAs at all, or are you outright going to be refusing
| healthcare related business/processing of PHI for some reason?
|
| (Either answer is fine, I just want to know if this is a decent
| fit for HIPAA-governed data, that's all.)
| ShaneCurran wrote:
| Yes! We have and will enter into BAAs under HIPAA for
| healthcare use cases, and are independently audited for HIPAA
| controls
___________________________________________________________________
(page generated 2021-12-17 23:01 UTC)