July 12, 2023
29 min read

Decrypt with Evervault: Meet your hosts

Liz Moy

Developer Advocate Lead

Transcript:

Liz Moy:

Hey everyone, I'm Liz and I am a Developer Advocate at Evervault.

Shane Curran:

Hey, I'm Shane, Founder of Evervault.

Liz Moy:

Shane, it's so good to be chatting with you on the show today. I'm really excited to just talk a little bit about our vision for the show and why we're doing it and kind of how it fits into our mission at Evervault.

Shane Curran:

Likewise. Yeah, the show's been a long time in the work, so excited to get it out the door.

Liz Moy:

So I'm sure you've been asked this question a million times, but I would love to hear from you, why you started Evervault?

Shane Curran:

I think the real answer is just frustration. So my background is software engineering. I was building a bunch of tools and products that were handling all sorts of sensitive data, so everything from libraries, keeping track of books, to labs, keeping track of experiments and inventory and so on. And this was sort of early 2010s when things like sending an SMS message had been abstracted for a developer where it was super easy. Things like charging a credit card were really easy as well, and a couple lines of code using services like Stripe. But encryption was something that I've become very fond of because all these people were trusting me with their data and I had no idea how to keep it secure. And at the time I thought I was probably the only person that didn't know how to keep it secure, but having spoken with a bunch of other developers, it seemed pretty obvious that nobody was really thinking about this.

And if you wanted to use encryption, which I think is the best tool for solving data breaches, you had to go spend months reading academic papers, spend a bunch of time learning how it works, learning how to implement it, and frankly, developers just don't have that sort of attention span. So Evervault really came about from the perspective of trying to take all that great work that was happening in academia, but making it super accessible for developers. So anybody who's building a piece of software can just integrate simple SDKs or APIs into their software, encrypt all the sensitive data that they have, and still do stuff with it, so that if they do get breached or all their data was published on a billboard, it wouldn't actually be a huge deal as opposed to a bunch of other security companies.

And I think most of the cybersecurity industry in general, which are trying to prevent data breaches, we just took the stance that data breaches have already happened in your company or in your, you just assume your software has already been breached and just focus on what would happen and how you would mitigate the risk of the data being breached. And encryption is probably the best way of doing that.

Liz Moy:

A funny side note is that you were studying law for a bit, right?

Shane Curran:

I think that was probably to be somewhat contrarian, definitely sort of computer science by background, but law was pretty interesting because it was just the polar opposite of computer science and it just kind of threw people off guard a little bit. But I did enjoy it, I think especially as it relates to, I mean it's kind of like software for humans a little bit. Instead of programming computers and creating all these rules, it was just sort of the equivalent but managed by judges and courts and contracts and so on. So there's actually a surprising amount of overlap, but the people who study law and the people who study computer science tend to be polar opposites. I'm obviously generalising there, but I think for the most part it's true.

Liz Moy:

Yeah, definitely. So when you decided then law was not going to be the way, you were going to focus more on software and particularly on APIs for encryption and for security, how did you decide what was important? How did you outline what you wanted the focus of this to be?

Shane Curran:

I'd read a bunch about different companies and how they structured their mission and how they were going to align the company around building a particular product. So for us, it was kind of two things. I wanted to keep the mission really simple. So our mission is to encrypt the web. Three words is pretty hard to forget and it's sort of both actionable and easy to understand and also somewhat ambitious as well, which is, I think, generally quite hard to do in three words. So once that was kind of decided and it sort of created a direction for us to build software in. The other thing that I did, I think before we'd even hired the first people on the team, was to create what we call the Encryption Manifesto, which is basically a set of eight rules that, at the time and even still today, are kind of aspirational for our product, but it's kind of basically setting out eight points where in an ideal world, this is what software to solve encryption or solve privacy or security would look like.

And we can then track ourselves over time as we build the product, and hopefully other companies, if they're building products in the same space or building encryption tooling or whatever, can use this as a base for what good encryption looks like. So there's a bunch of different themes that kind of run throughout the Encryption Manifesto, and you can take a look at it on our blog as well. But the kind of core idea is having the best possible encryption, but also the huge focus on developer experience and ease of integration, just being pragmatic about how the software can be integrated because companies don't have to encrypt their data.

And the only way Evervault will really work is if the barrier to entry and the ease of integration is smooth enough that it's all of the things being equal. It's as easy to build an application with encrypted data as it is to build an application with plain text data, and the Encryption Manifesto sort of creates a roadmap to get there. I think we're not there yet, and I don't know if any companies that are, but it's a really nice way to track ourselves.

Liz Moy:

From what I've gathered from my time at Evervault, and when I was starting to look more into this space, is also that it's just fairly nascent. It's something people have been thinking about for a long time, but actually having things in production that developers can use is kind of a pretty new thing. And I'm curious to hear your thoughts, since you have been thinking about this for a while, how have you seen the mindset change or what things have you seen in the industry and in the market that are sort of a dramatic shift toward focusing on this?

Shane Curran:

I think the biggest thing that's different about encryption, relative to a bunch of other spaces like looking at AI and large language models and so on today, is that encryption is just not glamorous at all, which means that people are naturally not drawn to it. If you're 22 and coming straight out of college, the last thing you generally would want to do is start working in encryption, because in some ways you can think of security as a tax on creating new software and building new tooling. If you want to create new things, you just want to get the thing out the door and security can just sometimes slow you down. But I think one of the main trends is just that developers are kind of increasingly responsible for the security of their own software.

Historically, in a company that was starting up, for example, they might have product engineers built the products, sign their first hundred users or a thousand users or whatever, and once they start having issues closing deals because of security, and they'll hire somebody whose title is head of security, they'll buy a bunch of external software and then they'll sort of get a SOC 2 report or something that says they're secure. But the best companies and the best security teams we've seen have sort of basically flipped that on its head and made software engineers responsible for the security of the code that they're writing and deploying. So that's a pretty exciting trend, and it makes complete sense. It's just up until now, the tooling hasn't really existed for encryption.

So that's really what we're trying to do, we're trying to take what is kind of a foreign concept to most software engineers but just distil it down to a really accessible API. And we think that by doing that, your average developer will start thinking about this more and more, and that tailwind is already starting, but yeah, I think it's our job to make sure it happens quicker. And the easiest way to do that is by just focusing and obsessing over developer experience.

Liz Moy:

I think some of those abstractions, that you mentioned earlier, were really focused around how do we take this problem that's kind of annoying to do or solve and just make it really easy for developers. And I think now, because there are so many different libraries and tools and just everything that go into actually building something, when something has a really great developer experience, it stands out a lot, especially if you're using a bunch of different other ones and you can very clearly see, as a developer, the experience for this is terrible and I really hate using it, versus the experience for this is really nice.

And ideally for a lot of them, it's kind of set it and forget it, right? You just want to set it up and you want it to just work. But if in that process of setting it up it's really seamless and beautiful, then you have such a strong association with that. And I think you're also, from the dev role perspective, I think a developer's much more likely to recommend that to a friend or a colleague than when they talk to somebody who's trying to solve the same problem as them.

Shane Curran:

The great thing about building a tool for developers in general is just that software developers are really good at finding the shortest path to achieve something. So if they know they need to implement security or implement payments or whatever, they'll firstly figure out what the best way of doing it is, but they'll always take the easiest path, which means that they kind of guide you in the direction of what a good developer experience looks like. But it's just really important to focus on that from the early days because security, historically, has just been honestly very kind of marketing and messaging led, and the technologies themselves don't really get analysed by software engineers.

But when you've got somebody who really cares about the purity of the infrastructure that they're putting in their stack in the form of software engineer deciding what way they want to do their data encryption or just secure their infrastructure in general, you can't get away with big marketing messages that sound great in theory, but in practise don't actually make any sense. So yeah, I think that's why building for developers just forces you to create the simplest and sharpest way to communicate and integrate your product.

Liz Moy:

I know we've talked about this before that it shouldn't just be building for regulation. There are those regulation measures that obviously need to be followed, but many times that's not enough.

Shane Curran:

One of the things that regulation has done is that it's made people think about it. But the problem is that in some ways, especially when you think about things like GDPR or CCPA, it just invites more questions than there were beforehand. Historically, a developer just had to think about, how do I secure the data that I'm collecting on behalf of my customers? But now you have to think about the security of the data you're collecting on behalf of your customers, both from a legal perspective and from a technical perspective. And you have to do everything from making sure that you have a cookie banner on your website to having a list of all the sub-processors in your privacy policy. So it basically means that more people are thrown into the mix when, our view is that privacy is fundamentally a technology problem. We're very supportive of all these regulations coming in just because, frankly, the progress towards building more secure software or more privacy preserving software just wouldn't happen in its absence.

But it doesn't mean that you actually solve all the problems just by spinning up really fancy and ornate privacy policies. But yeah, all that's to say developers should be given tools that sort of abstract away all this legalese. GDPR has 99 articles, which very few people have read, and maybe a handful of privacy lawyers, developers just want that distilled down into infrastructure that's mostly compliant with it. And because of how broad GDPR is, it's really hard to solve everything in one tool. And we certainly don't claim to do that, and I think very few companies do, but you can make a meaningful headway to being compliant with all these regulations just by focusing on the actual security of the data, because compliance is sort of a secondary effect of having good security. It's not security that's a secondary effect of having compliance, at least in a well-run security team or security engineering team.

Liz Moy:

Yeah, definitely. So I'm curious, between when you started Evervault and today, what's something that surprised you? What's something that when you started Evervault, you never would've thought it would be something that you'd have to pay attention to or integrate into the product?

Shane Curran:

The surprising thing is how long it takes for very early stage companies to factor in security into their product development processes. And not to say that a two-person startup has a very mature product development process in general, but it's interesting to see the change in your framing about how companies think about security from maybe a two or three-person company that might only have a handful of customers through to even a 20 or 30-person company that might have a hundred customers or something like that. There's a very sudden shift, and there's actually a surprisingly large gulf between those two-person startups and 20-person startups. The two-person startups just want to get their first customers in the door and they're happy to beg, borrow, or steal to make sure that they get them using the product. And security is surprisingly just not something that they think about too much.

And I'm sure if a customer asked them about it, they'd have a big story to tell, and they talk about all the encryption at rest that they do and so on. But it takes a surprisingly long time for companies to think about security in a kind of mature way. Not to say that it's only Fortune 500 companies or growth stage venture-backed tech companies, it's sort of around this point where companies have 50 to a hundred customers, but my guess at the very start was that everybody cared about security, and the only reason they didn't do anything about it was because the tooling was bad. But there was a pretty large cohort of very early stage companies that just don't spend too much time on it, with the exception of the top 1% who just know that they're sort of optimistic and confident in their product's growth trajectory.

And they know that if they're going to be growing, doubling month over month or whatever, that security's going to become a problem in six months, so they might as well do it now versus in six months. But a lot of the time, not thinking about security from day one is sort of almost a pessimistic loser's mindset where you're just not confident in your own product's growth trajectory and you just think you'll never get there if you do waste time on, or from their perspective, waste time on implementing security tooling.

Liz Moy:

I think that there's kind of an opposite end of the spectrum problem as well. My first job as a software engineer, I remember one of the tasks that they gave me was just going through and fixing all of these SQL injection vulnerabilities. I was like 500, it was so many, because we had this code base that had been written quite a while before and people were maintaining it here and there, but it was always getting passed off to different people, so it just lacked consistency. And then someone realised, I don't know, somebody pen tested it and they were like, oh my gosh, we have to fix these immediately.

So it's interesting because I think it's bad if you don't think about it from the beginning and then you have to do it later. And it's also bad if you are maintaining something that has all these flaws that you're not aware of. And there is something to be said for doing it from the beginning if you can, because that's sort of the easiest way to catch it and stop it from being an issue later down the line.

Shane Curran:

Yeah, I think particularly your software matures. A lot of companies just don't even know what data they have. They've databases everywhere. They just keep adding more and more tools on over the years, and you need a whole team that's responsible for even understanding what your architecture looks like. And that just gets really messy. There's a bunch of software in late stage companies that I think should just be burnt to the ground, but it's just very hard to make a business case for it because I think especially if you look at something like security. Unlike, say, sales tooling where you can say, for every thousand dollars that we spend on this tooling, we're going to generate $2,000 in incremental revenue.

You can make a very similar argument for security, it's just way harder to quantify. So it's a very binary thing. It's either we do get breached or we don't get breached. If we do get breached, it's a huge deal and our business is probably ruined for years to come, but there's a chance that we don't get breached and we don't get caught. So it becomes easier for these things to slip through the cracks just because they're not as attributable as a sales and marketing tooling, for example.

Liz Moy:

I'm wondering, I know we talked about, and we'll talk a little bit more about why we're doing the show and what listeners can expect from it, but one of the questions that we talked about having guests answer is, what's a really difficult or interesting sort of incident that you've had to deal with? So wondering if there's any of those that stick out for you, either that you've sort of dealt with firsthand or helped a customer out with or just seen out in the wild?

Shane Curran:

There's sort of varying degrees. I would say from a personal perspective, the first ever kind of software tool that I launched was a library management system. And to your point about SQL injections, it was the first time I'd ever used SQL in practise, so even just knowing to escape apostrophes and so on, that was definitely a lesson I learned further down the line once other people had to look at this worst code and they were like, oh, you should probably fix this. So thankfully nothing bad came of that. But I guess somewhat masochistically, my favourite breach that I've kind of read about recently is the Capital One breach, just because it's so simple.

A publicly exposed S3 book containing PDFs of everything from credit scores to mortgage applications for millions of US citizens. People expect that all these data breaches are these hugely complex attacks where people are installing ransomware and malware and so on. Sometimes people just accidentally leave things publicly accessible, the internet, and somebody just has to guess the domain name or even just type into Google, Capital One documents, and these things come out. So that one's particularly scary just because of how simple it was and how easily avoidable it was, but without those checks in place, and even just having good hygiene around what infrastructure you're exposing to the web, it's just really hard for organisations of that size to prevent.

Liz Moy:

I definitely have a lot of empathy now for S3 bucket builders and maintainers because I was working on something recently to upload encrypted files to S3, and I actually didn't realise sort of all the configuration bits that you have to get right for it to work properly. And when I was doing it it's like for a demo, so I was definitely doing some workarounds, allowing any host to make a request, that type of thing. But I was thinking as I was doing it, it would be so easy to do what I did, just be like, oh, I'm just going to do this to get it working, and I'll go back later and fix it. But everybody's busy. Everybody's got a million different things they need to do, and it's one of those things that's just so easy to forget to go back and fix or go back and reconfigure.

Shane Curran:

Yeah, later never comes 99% of the time. I think there's some great things that AWS have been doing just on S3 bucket security in general, where I think, in fact a couple of months ago, they sort of disabled public access by default on all new buckets that are created, but there's still millions or billions of existing S3 buckets that don't have any of that configuration. So yeah, it's not particularly difficult to just even go to Google or one of those tools and type in a company's name and figure out what they have publicly exposed in the internet. Yeah, it's quite surprising how much of it is just exposed.

Liz Moy:

I want to talk a little bit too about how we use AWS, how we're using Nitro Enclaves. I think one of the technologies that I'm the most excited about is Confidential Containers and running data in use securely. So would love to just hear about what that journey was like for you of deciding to take things in that direction.

Shane Curran:

The simple distillation of why encryption over the last 20 years or even more hasn't really solved all the problems it should, is that to actually do stuff with encrypted data, you have to decrypt it again, which means you're effectively back to square one. And sure, you can de-risk particular databases or particular S3 buckets or whatever that might store sensitive data, but fundamentally, the code that you're building to process the sensitive data still needs to have the key and it still needs to decrypt the sensitive data. So I've always been fascinated about how you can solve this sort of data and use problem, where if you think about it as a triangle where you've got encryption in transit, encryption at rest, and encryption in use, those things are now possible with things like confidential competing and unsecured enclaves specifically. So as a high-level overview of what secure enclaves are, they're effectively isolated virtual machines in the case of AWS, where AWS a test the integrity of the code that you're running inside them.

So if you have a Docker image or some sort of application that you want to deploy inside a secure enclave, you can basically sign it, deploy it to the enclave, and then before you send it any sensitive data, you can prove that the code that's running inside it hasn't been tampered with and is the code that you've signed. So if you've got some open source tooling and other people can verify it and so on, it provides very strong security guarantees. But the challenge is it's just really difficult to re-architect applications to fit into secure enclaves. So we were sort of a design partner for AWS Nitro Enclaves as they were being kind of rolled out into beta, and we launched Cages as a result. And what Cages is, is basically a really easy way to take any existing Docker file that hasn't been designed to be deployed in a secure enclave. You basically just build it using our CLI, deploy it to Evervault, and we just give you a domain name.

So we make it really easy to build, deploy, and scale secure enclaves powered by AWS Nitro Enclaves, and any data that you encrypt with any of the other Evervault tools is fully decryptable and processable within one of these AWS Nitro Enclaves. So it's technology that I'm very excited about, and I think it's only a matter of time before it gets adopted by everybody just because it makes complete sense. You instantly, out-of-the-box, get way more sort of rigorous and just stronger security guarantees that you wouldn't get elsewhere. So yeah, that's been our kind of journey in confidential computing in general.

Liz Moy:

We had this little internal hackathon maybe a month ago where the developers from Evervault built different use cases with Cages, and it was so awesome to see. I was actually so impressed by just the different things that people came up with. And I'm wondering, is there any particular use case or application that you're especially excited about when it comes to this technology?

Shane Curran:

I don't want to lean too much into hype and buzz right now, but I think when it comes to things like large language model training, Nvidia have new chips that have effectively secure enclaves built in. So if you want to train a model and a real sensitive data set, you can attest that the data is only being decrypted by an Nvidia GPU when it's kind of going through the training cycles. You can then basically take that model, have it fully encrypted and deploy it inside a secure enclave to do all your inference. And the secure enclaves on something like an Nvidia GPU could very easily be connected to the secure enclave on an AWS Nitro Enclave or one of the other chip technologies with a fully attestable chain.

And what that means is basically all these concerns that people have about your third party providers for large language models like OpenAI, building ChatGPT or whatever, where you just have to send all your sensitive data off to a third party server, it's only a matter of time before you can host these things internally, get guarantees that none of the data that you're sending to them is leaking anywhere. And it means that we'll see a bunch more exciting use cases beyond tell me more about the celebrity, it'll kind of move much more towards sensitive patient data, financial records, and a bunch of other use cases that just large businesses will just get huge value from.

Liz Moy:

Yeah, definitely. Let's talk a little bit about this show and why we're doing this. I can speak to my side of it because I noticed, when I started working as an advocate here, that there were different developers that were already in our community that were doing some really incredible work, and I wanted to just kind of chat with them informally about what they were working on and then in those conversations I was like, well, actually, I think it would be cool if we recorded this because I think a lot of this is knowledge that is helpful for everyone. And we recently open source Cages. I think we're really moving toward that model of wanting to share knowledge, wanting to share information, and this seemed like a really natural fit for sticking with that mindset of just making knowledge open and accessible for anyone who might be looking for it. But would also love to hear from you about what your vision for the show is and what you're excited about?

Shane Curran:

I think for the show in general, it's just a case of having conversations with people that are very forward-thinking in security. And I think a lot of the conversations that I'll be having are with basically security leaders that are forward-thinking and actually doing interesting new stuff. I think one of the interesting things that's happened over the last maybe five or 10 years is that security leaders have just become much more technical, so instead of coming from maybe a compliance background, they tend to come much more from engineering backgrounds now. And as a result, they're sort of just approaching security through or from a very different perspective when compared to security leaders of maybe 20 years ago, but a lot of them just aren't particularly outspoken.

So a bunch of calls that we've had with and meetings that we've had with these people I've learned a bunch from, and a lot of their kind of opinions and ideas have informed a lot of our product roadmap. So I think it's just really important that we have these conversations so that people can hear what the best security leaders are doing. And if you're a two-person startup or a 20-person startup, being able to learn from some of the best security leaders on how you can improve your security, I think that's just really important. And hopefully someone else comes up with a new synthesis of other great ideas just from listening to a couple of the episodes.

Liz Moy:

Fully agree. Is there anything else that you wanted to share or talk about?

Shane Curran:

I think recently we've been very active about new updates and our product security on things like Twitter and Discord and so on. All the updates will be shared pretty openly on places like there. But yeah, really looking forward to reeling this show out and hopefully having it up and running for hundreds or thousands of episodes.

Liz Moy:

Yeah, and hopefully when we cut this together, we'll have a song from you, Shane, to include for the intro and the outro. Shane was an almost-lawyer and is a side gig music producer from when he is not running Evervault.

Shane Curran:

Yeah, very mediocre, I must say. I've published a handful of pieces, but every time I listen to them I get more and more annoyed at how bad the music is, but someday there'll be a good song in there.

Liz Moy:

Thanks Shane. It was great chatting to you today.

Shane Curran:

Likewise. Thanks, Liz.