Unknown: Hello, and welcome to the Data Engineering podcast, the show about modern data management.
When you're ready to build your next pipeline, you'll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 40 gigabit network, all controlled by a brand new API, you've got everything you need to run a bulletproof data platform.
Go to data engineering podcast.com/linode
today to get a $20 credit and launch a new server in under a minute. And go to the data engineering podcast.com
Unknown: website to subscribe to the show, sign up for the mailing list, read the show notes, and get in touch. Your host is Tobias Macy, and today I'm interviewing Ellison Ann Williams about Envail, a pioneering data security company protecting data in use. So could you start by introducing yourself? Yeah. So Elison Ann Williams, I'm the CEO and founder of a company called Enveil.
And do you remember how you first got involved in the area of data security? Yeah. Absolutely. So I originally started as a mathematician.
Unknown: So a pure mathematician went through and got a PhD.
At that time, when I was completing the PhD, the the job,
possibilities were somewhat limited for a pure mathematician. So you could take a postdoc,
which I had several opportunities to do. You could go into our research lab, or you could go work for the National Security Agency, which is the largest employer of mathematicians in the world. So I decided to go into NSA,
and, of course, at that point, got very involved in security in general, data security in particular.
Unknown: And in your time at the NSA, you ended up doing some work on protecting data in use, which, you then ended up commercializing
in NVAIL. So can you discuss a bit about your mission with Envail
Unknown: and how the company itself got started? So Envail secures data when it's being used or processed
exclusively
as opposed to focusing on the other 2 more traditional areas of the data security triad, which are securing data at rest on the file system. So that's your standard file based encryption or securing it in transit when it's moving through the network. So that encompasses all of your transport security. So those 2 areas of the data security triad are what you most often see productized or solutioned
across the commercial space.
So the last gap in data security when it's being used or processed is where we focus completely. So if you think about it, the way people most often meaningfully
use or process data is by running a search or an analytic over it. So we're concerned with the security posture of that search of that analytic
as it's being performed. So what does that mean? It means that we can take a search or an analytic that folks want to perform over data and we can encrypt that. And then we can run that encrypted search or analytic, which could contain all kinds of sensitive indicators
around things like PII,
PHI, EU resident identifiers under GPR,
IP,
competitive advantage types of information,
and we can take that encrypted search analytic and run it over massive amounts of data without ever decrypting anything.
So we never decrypt that search or analytic
itself. And if that underlying data happens to be encrypted, we don't have to decrypt it
either. So we're able to really achieve a never decrypt
security posture for the processing of data and really close that last gap in data security, which is securing it when it's being used or processed.
Unknown: And
so when the query or analytical
request is sent
to the back end for running against the encrypted data. You say that that process gets encrypted, so I'm assuming thinking about it in terms of
how the computation occurs is that the process that's executing that search or the analysis against the data
at some level has
a a clear text view of what that information is, but that it never leaves
the server
Unknown: or the sort of memory space where it's being accessed. Is that an accurate sort of way to think about that, or am I completely off base on that? So we are far more secure and powerful than that. So our security assumptions of that processing environment, in other words, where the data is that's being used or processed, are com completely 0. So we assume that it's completely untrusted, completely had. There's an attack or someone with malicious intent able to see every single bit of operation in memory and on disk in that environment.
So because our security assumptions are 0
of that data space and of that processing environment, we never decrypt anything
during processing.
So when we encrypt that search and go run it over data, that data could be unencrypted data. So think in the case of utilizing
a third party data services or data in a shared data lake or it could be encrypted data. Either way, we never decrypt anything during the processing.
So that math magic,
is powered by a special type of encryption that we leverage called homomorphic encryption.
Makes all of that
impossible,
Unknown: really possible. And can you discuss a bit further
what the principles are that are involved in homomorphic encryption that allows for being able to process the underlying encrypted information without
exposing the actual
individual records to any any of the processes involved along the way. So homomorphic encryption
Unknown: is not a new area of encryption. It's been around 30 or so years. If people have heard of it, they've often heard a couple of things about it. So the first is that it's often considered to be the holy grail of crypto because
it allows you to perform operations on encrypted data or more importantly from a technical perspective in ciphertext space
as if it's unencrypted or plain text. That's that holy grail aspect of it. The second thing that people have heard, about this type of encryption, if they've heard anything, is that over its lifespan for the last 30 or so years, it's been very computationally intensive.
In other words, slow. So possible just not practical. That's the crux of the major breakthrough that we had in this arena,
moving that kind of technology from the realm of the computationally intensive and an extremely slow into the practical and commercially viable.
Unknown: And for people who want to learn more about some of the principles involved in homomorphic encryption, I'll ask you to add some links to the show notes that they can follow-up with. And in terms of being able
to scale the capabilities
of running workloads against,
this encrypted data using homomorphic encryption. I'm wondering what some of the challenges
therein happen to be in your experience.
Unknown: So our applications of homomorphic encryption are extremely scalable. That's where our breakthrough,
came in. You know, we had developed the core of our technology within the US
government, the US intelligence community,
and then we're able
to bring that out, greatly expand and mature it and commercialize it into the products that Envail provides today. So in terms of scalability,
we are extremely
flexible. So we are able to process,
data in a in a completely encrypted capacity over very small form factors.
We're able to do so in highly distributed environment such as Hadoop architectures.
So the crux of that is that the algorithms that, really power our capabilities are linearly scalable.
They can scale vertically. They can scale horizontally,
which, like I mentioned, makes us extremely scalable and flexible to leverage all kinds of compute platforms.
Unknown: And for people who are interacting
with your platform,
is there any special tooling or
capabilities necessary
in the,
way that they're interacting with the encrypted data, or are they able to just use common off the shelf tools that they might already be using to run these analytical workloads against the data that you're protecting on your platform? Yeah. So we're designed to be minimally intrusive
Unknown: plug and play in the environment. So we really function as a proxy layer to secure the usage of junk data. That means that from a user experience perspective,
it's transparent to that end user that what's really happening to those operations that they're performing over the data or the usage of data is that it's it's occurring in a completely encrypted
fashion. So part of being a proxy layer means that we're completely API based. So for example, we don't build a user interface. So we're designed to plug into the back end of the existing user interfaces or application workflows in the environment.
Being API based, we implement,
most of the, you know, common APIs. After that, we're pretty opportunistic.
API dev is easy. We put in place whatever we need to to be as plug and play as possible into the system. We also don't require people to change the way that they store their technology, the format of it, their ingest or ETL processes in any way, shape, or form. So we sit above the data storage layers in the system. We sit above the compute layers in the system, in order to perform this encrypted processing over data. And so for somebody who's starting to use your product, is it something where they would have a license and then deploy your technology into their environment, and it serves as sort of a proxy layer over existing data storage, or would they ship data off to your platform to be encrypted and protected
Unknown: using your own infrastructure?
Unknown: So they would deploy us in their environment on top of the way that they currently store and manage their data today. So we focus exclusively on that usage piece, which means we are going to be complementary
to to this other 2 pillars that I talked about before, the usage and of the at rest, functionality of the data as well as the transport functionality of the data. So we are not going to ask people to change the way that they store their data, the way that they currently encrypt their data, or to trust us to productize that in any way, shape, or form. So they can continue encrypting their data the way that they do today and layer us on top to make sure that when they go use that data, it can be processed in an encrypted state. Also recall that very powerful application for us is performing encrypted computation over unencrypted
data, which has a whole different set of use cases associated with it. But in which case,
that underlying data at rest is is not encrypted, and we are streaming plain text into our algorithms that are processing that encrypted search over it. And so in practice,
Unknown: there is no information available
from either direction of either the person
sending a request as far as what the underlying data might be or the person receiving a given request as to what the
given request as to what the workload is actually trying to do so that it allows for a, 0 trust interface between
the party storing the data and the person trying to analyze it, which,
in the process of researching for this podcast, I saw that you had mentioned that this unlocks some possibility of data brokerage where you can share data assets
across organizations without having to worry about
revealing things like PII or trade secrets to and then but still allowing other people to, gain value from that data. So I'm wondering if you can talk a bit more about that
Unknown: and some of the other use cases that are unlocked by this, sort of 0 trust interface. Correct. So in the case of a data lake or a shared pool of data, what we enabled is really securing private multi tenant usage of that data within that shared space. So for example,
you could have, a shared data lake within a public cloud environment.
You could have multiple parties accessing it. In other words, running searches or analytics over it. And because those searches or analytics are being executed in a completely
fashion. There's no risk of exposing
what each individual party is doing in using that data in that environment.
So other types of use cases that, open up for the NBL capabilities are things like, what we've called crown jewel data protection. So protecting the subset of most sensitive data within an organization,
within their internal data lakes most often.
We see cloud as a huge 1, you know, beyond data lake, allowing people to really
process their most sensitive workloads out in completely public cloud environments. So there's a there there's no shortage of folks that want to utilize the public cloud for the storage of their data. The problem comes in, what happens when you go process it there? So even if you do a fantastic job of encrypting the data at rest in that public cloud environment, and there are a variety of mechanisms to do that, It's not protected when you go use it. So, for example, you take your data, you encrypt it, you put it out in the cloud. Now you wanna run a search over it. So it's very easy
for you to encrypt that search as it travels through the network with transport security, say, TLS
from your environment out into the public cloud space.
However, when it reaches that public cloud environment, the transport security terminates that TLS is gonna be stripped off. So that search that you worked so hard to protect in transit
as it moved from your environment through the network out into the public cloud is now exposed. And, of course, that search itself could contain all kinds of,
sensitive indicators that would be risk inducing or liability inducing for that organization. In order to process that search that's now exposed in plain text in that environment, the data that's sitting in the file system, perhaps encrypted at rest, must be decrypted into memory. So at this point, everything that you've worked so hard to protect at rest on the file system and in transit as it moves through the network is now completely exposed in the memory or processing layer out in the public cloud. So that becomes the point of least resistance for an attacker. So if I'm an attacker, I'm not gonna try to steal your data at rest as it's encrypted off of the file system because then I've gotta break the crypto, and that's hard to do. I'm also not gonna try to steal the data out of your search or analytic process as it's moving through the network because it's protected under transport security encryption. I'm, again, have to break the encryption, and that's hard to do. Instead, I'm gonna sit and wait out in that public cloud platform until you go process that data, and then everything is freely available to me in memory, and all I have to do is take it from that environment. So we completely flip that on its head because we can keep both the data encrypted
in that public cloud environment as it's being processed as well as the search itself. So if the attacker were to steal the contents of memory using Enveil, they only obtain encrypted information. Therefore, everything is completely protected as it's processed out in the cloud. That opens the door for organizations to now move these very sensitive workloads out to the public cloud for processing. So cloud is a big 1 for us. We all see also see a lot of implication around compliance and regulations, specifically with GDPR,
around use cases such as third party risk,
as well as insider threat. And so when somebody deploys
Unknown: your
data use protection layer into their environment,
so say, for example, that they're working on a Hadoop system, is it an additional binary that gets installed on the same set of servers
that the Hadoop processes are running on so that it can be invoked as part of the layer that's loading the data from disk, or is it deployed as a standalone server and relies on things like TLS
for encrypting the information as it travels from the Hadoop cluster
to the processing layer and then also receiving the data from the TLS encrypted network call to that processing layer? So the in the data environment,
Unknown: we deploy our Infail server application. It's simply a lightweight app, in a containerized setting. You could think about it like a Docker container. It can deploy outside of Docker natively on the OS. So it simply functions
as a brain in that space to understand how to take those encrypted searches, for example, and process them over the data to which it's been granted access without ever decrypting anything. It sits above the data storage technology layer as well as the compute, So it doesn't store or process any data itself.
It's going to be configured to understand various storage technologies and mechanisms
in that environment as well as
to leverage environmental compute, which could be anything. So in the case that you have a Hadoop architecture
and you, would like to leverage that, to perform the compute, then, that Hadoop architecture,
is often configured to understand how to read various, data sources out of different kind of storage technologies in the system. So you could have, for example, Spark, understanding how to read data out of Elastic
search. So in that situation,
we're going to then, kick off, say, a Spark job in the system if that's what we're it's available to us, and that Spark job will understand how to read that data that's appropriate for the search out of that storage technology, and then we can process it from there. So we're going to,
sit on top of the way that the compute and the storage technology currently interact with each other and leverage it as it exists in the system. And as you mentioned,
Unknown: the primary
attack vector right now for people who are trying to intercept data
in a system is to wait for it to be decrypted in memory. And so by virtue of not having to do that when using Enveil, it eliminates that particular
vector. So I'm wondering what are some of the remaining ways that people should be looking out for data compromise when they are using Envail? Yep. So a multitude of attack factors available for,
Unknown: the usage of data and for really compromising data when it's being used or processed.
The vulnerability really lies in a processing layer or in the memory component
of the environment in which it's being processed. So all different kinds of attack vectors are possible there. Any would think from, you know, RAM scraping,
any kind of frequency analysis side channel attack, you know, just breaking into the external fence of the organization. So any kind of perimeter fencing attacks if we brought it broaden it out a little bit more, and this has become far more prevalent,
with all of the,
Unknown: vulnerability releases around factor and meltdown, for example. And 1 of the other cases where data can be inadvertently
leaked,
even if it's maybe potentially,
never revealed that the individual record layer
is by, sort of, implicitly
deriving
information
from the aggregate records.
So,
an example might be
having
geolocation data, being able to then reconstruct the locations that an individual is going to, and then from that, extrapolate who that person might be,
or in health records, being able to maybe see the frequency of visits and then correlate that with somebody's geolocation data from another source. So I'm curious,
what are,
some of the ways
that people who are using Envail to protect the actual queries and the data, also some of the additional considerations that they should have to help mitigate,
information leaking?
Unknown: So for us, you know, because we are encrypting that search or that query as you described, there's there's a whole host of sensitive information contained
in the search itself,
from an interest and intention
potential trade before executing it without ever tipping their hand. Yeah. That's a very simple example
of interest and intention that could be revealed in the content
of a search or a whole host of other examples along the lines of what you mentioned with different geographic identifiers, etcetera. So because that search is encrypted, that identifier is never revealed outside of the environment of the origination point.
Meaning, you type in that search, it gets encrypted within your walls, and then it's sent out to the 3rd parties to process. So because it's never encrypted in that environment, there's no risk of exposure
of that identifier outside of that space.
So, really, it completely removes
the attack and threat vectors around processing and utilizing third party data outside of your walls
and puts that back internal to the organization with standard security postures.
Unknown: And so
1 of the areas that people often run into
businesses aware of how important it is to have some of these various security postures versus the amount of effort required to enact them. So I'm wondering what you have found to be
some of the,
common misunderstandings
or issues that you've had to overcome in the process of raising awareness of the work that you're doing at Envail or onboarding customers onto the platform? So security is not an all or nothing proposition.
Unknown: So we really make sure that people understand that
the different elements of data security
at rest in transit and use should be complementary
to 1 another, not all encompassing.
So there should be a diffusion of trust there. So for example,
we leverage the enterprise's
trusted
KMS or key management system, not only for key storage, but also for key generation purposes.
We sit on top of whatever their trusted mechanisms are today
for securing their data at rest, securing it in transit.
So truly driving home that it should be a complimentary approach to data security.
Unknown: And what are some of the plans that you have for the future of Enveil, whether in your current products or any products that you are considering developing in addition to what you already offer? Yeah. So what we've encountered,
Unknown: in Envail is a whole range of, risk tolerance
within the commercial space in various verticals. So we are broadening some of our product lines and offering a multitude of ways for people to dial up and down their risk profile
as it as it pertains to the usage of data. So you'll see new product lines coming out, leveraging things like the Intel SGX
and other types of capabilities
where
there is a little bit more risk tolerance in in the environment.
Unknown: And in the process
of building
and growing
the business
and the technological capabilities
of Envail, what have you found to be some of the biggest challenges
or unexpected
obstacles
or,
unexpected things that you've learned in the process of doing that? So for us,
Unknown: we've
had to do a lot of education
around,
what it means to secure data when it's being used or processed, and the fact that
technology is now available, capabilities are now available to make that practical that have never been available
before.
So previously,
you could only really address data security from a practical perspective in 2 forms at restaurant and transit. As I've described. There's really no practical way to deal directly with securing the usage of data. People were working around the space.
Unknown: So really opening up, the conversation and and introducing new capabilities to directly address that. So for anybody who wants to follow the work that you're up to or get in touch, I'll have you add your preferred contact information to the show notes. And as a final question, I'd like to get your perspective
Unknown: on what you see as being the biggest gap in the tooling or technology for data security today. Of course, from an Inveil perspective, it's the usage. So many, many solutions exist for the other 2 areas of the data security triad.
It's it's become a more commodity space,
but the the big gap,
and where all the attackers are going, once you close off those other 2 spaces are in that usage
Unknown: layer. So that's what we see as the largest gap right now in data security. Alright. Well, thank you very much for taking the time today to talk about your work at Enveil
and some of the uses for homomorphic encryption and use cases that it enables. So I appreciate that and I hope you enjoy the rest of your day. Thanks so much.
Unknown: Much.