Ep. #13, Curiefense with Tzury Bar Yochay and Justin Dorfman of Reblaze

Marc Campbell: Hi. This week, we're going to talk to one of the newest CNCF Sandbox projects called Curifense.

If you haven't seen this project yet, don't worry.

We're going to be digging in and spending the whole episode talking about this project.

So joining me, we have two great guests from Reblaze, Tzury Bar Yochay and Justin Dorfman.

Let's start with some intros.

Tzury, do you want to introduce yourself and your background?

Tzury Bar Yochay: Well, thank you, Marc.

So I'm Tzury Bar Yochay, a founder and CTO for Reblaze company which we founded back in 2011, 2012.

And since we provide application security platform on a cloud--

Well, application security basically means, the comprehensive platform that provides a client with a web application firewall, comprehensive biometric-based bot management, DDoS protection, and so on and so forth.

The beginning of last year, January 2020 we started working on this project Curifense, which is a newer version of our product which we decided to release as open source.

And I believe we will discuss further about this project today.

Marc: Yeah, for sure. And then Justin, so you're an open-source program manager at Reblaze?

Justin Dorfman: That is correct. I started around a little over two months ago.

I'm basically responsible for the fostering and adoption of the project, Curifense, in the cloud native space.

So yeah, it's been a really nice ride so far, and I'm really excited to be in a new space, the cloud native space.

It's a really cool community.

Marc: Great, awesome.

So let's dig into Curifense.

Tzury, you mentioned a few terms like web application firewall, DDoS protection and Curifense being an open source implementation.

Can you just describe what Curifense is?

Tzury: So Curifense is a product that provides you, whether you are a user, developer, site reliability engineer or DevOps engineer, whoever you are, an easy way to protect your applications, APIs, services, microservices and so on, from all sort of attacks.

Curifense works heavily based on profiling, meaning there is intelligent process profiling each and every incoming request, as well as profiling sessions.

And based on profiling, you can apply policies and define risk levels and reactions to base on the context and the content and behavior and so on. The system is a comprehensive one.

So it's not just a web application firewall, I would say a classic one which one would expect to protect against SQL injection, XSS, cross-site request forgeries and so on.

Rather, a comprehensive one that at least based on profiling, so whether is automatic bot, or scanning tools, or a hacker manually trying to work through to an application and finding vulnerabilities and exploiting vulnerabilities, SQL injection, obviously always top 10, always top 20.

But above all the behavior analysis that we provide gives automatic detection against--

In most of the cases, automated attacks such as brute force login, account takeover, credit card frauds, and so on and so forth.

And the project is open source.

Right now, it's available as an Envoy HTTP filter, and more to come, meaning other proxies and integrations will come down the road.

Marc: Cool. Some interesting stuff there to dig into.

There's lots of different protection that it sounds like I get. SQL injection, XSS, bot detection--

Do I just install Curifense and I get all of that? Or how much configuration and rules--

You mentioned policies, help me understand how that all works together.

Tzury: Yeah. So you can go just curifense.io and just get at .com/curifense, and just get started from there.

So Docker Composed, Katacoda.

We have Helm Charts, so you can deploy Helm Kubernetes cluster to play with the Curifense.

Basically, you attach Curifense to your Envoy proxy whether ingres gateway in form of a service mesh or in a sidecar.

And that HTTP filter simply each and every request will route through the Curifense.

As requests arrives, the Curifense gets through a profiling process.

Within a fraction of milliseconds, we compare the request against all sorts of lists of rules within the system.

Lists came be external threat intelligence rules lists such as a IP repetition , commercial ones that you as a user has access to, or open source ones and so on.

Lists also can be policy and definition and profiling such as API discovery.

So Curifense come with preloaded set of rules and lists, some which we updated daily such as Google crawlers, Facebook crawlers, social media, and all those white-listed bots, search engines and so on.

So traffic, as it arrives, it's already been profiled.

And pretty much, Curifense already is quiet precise rank for the incoming traffic.

Or is behind a VPN to our anonymous store or the other anonymous proxies and so on and so forth.

And that requests get tagged. And from that point on, tags are used all over the place.

Whether with a session on control flow, meaning there is certain sessions, certain flow within an application that you expect standard users to follow through, while attackers probably will not follow that flow.

I would say, super advanced rate-limiting, and you got to use it just to see what I'm talking about.

It's not just by the-- everybody's familiar with, and those all work with tags.

So meaning, you can do a rate-limiting for unauthorized user and then different rate-limiting for authorized users.

You can white list affiliates, make exceptions for a variety of levels and layers of security and rate-limiting.

You can escalate the reaction of the system based on the behavior.

So if rate-limiting gets violated, at the beginning the system will react a certain way.

And then if the user is the attacker for that matter continues hammering the system, then it will get banned for an extended amount of time.

So all those layers are built into the system. Further down the road, there is the ACL. Meaning, simple access control list, who is allowed, what is allowed, what is not based on source, based on content, based on profiling. What sessions are allowed, even though human is not verified, or only for verified humans.

For example, login forms, which is UI, user interface meant to be working with users rather than bots.

So you may want to apply deny bots.

In Curifense terminology, deny bot for those interfaces.

Harder there is the web application firewall engine, which look into each header key and value each cookie, and each argument within the post-argument-- , and compare those payloads against signature set or rule, which is maintained by Curifense community.

And us, obviously, as the makers of the project. And all of that happens within a fraction of a millisecond. Imagine that.

Marc: Yeah, obviously performance is probably a critical goal.

Nobody wants to a WAF that's going to add hundreds of milliseconds to requests.

Tzury: Yeah, yeah.

Marc: So that's cool.

So the tagging that happens, I'd love to understand that a little bit more.

I understand that the tags are used to help make intelligent decisions by Curifense, but do they pass all the way through to my application?

Like if I want to see some tags, can I access them in my runtime code also?

Tzury: Yeah. So all the tags actually goes into the logs, which by the way, will be within your Elasticsearch or your pathway SQL, or your BigQuery, or your DynamoDB.

You can choose where you want logs to be stored.

And more than that, you can definitely define all the tags to be sent to your app stream, say, in the form of headers, for example.

So we can add additional custom header, all the tags are there so you can see all the tags.

Marc: Got it.

Tzury: Tags are pretty powerful because you can instantly say deny bot and deny bot for Google SEO, and all the SEO stuff related, and so on and so forth.

You just put a tags in, then everything is taken care of by the system.

Marc: Yeah, that's great.

I mean, we've had a web application firewall running on our system since the beginning, and there's like this level of comfort you have when you have a really good WAF running with bot detection and it's dynamic rules, where you wake up in the morning and you have an alert that says, "We blocked the following attacks last night."

You're like, "That's good."

I don't know what would happen if I didn't have web application firewall.

Tzury: Yeah, I'm glad that you mentioned this term, dynamic rules, which is one I believe we were the first one to use back in 2012 in our product.

Let's say now it started come more in the industry.

By the way, I just want to mention that Curifense, even though it's open source and just was released several weeks ago, nevertheless, we're bringing into Curifense over a decade of experience within Reblaze.

And Reblaze, right now, we process over 12 to 15 billion HTTP requests per day.

So our routine, prior to Reblaze, obviously was experience in the field.

So we bring in dozens of years of experience into the field.

And Curifense by itself is pretty solid, used by companies such as Cisco and others in production.

And we're very excited about the development of this open source project.

Marc: I'd love to chat about that for a little bit.

So you have a commercial, product you've been around since 2011, 2012, working on this space.

And now you you've taken, it sounds like the core part of what your business was, and released it as an open source project.

And even more than just open source, but donated the application to the CNCF.

Can you help me understand the thought process there and how you think about what goes into open source and what stays in the commercial offering as you move forward?

Tzury: Sure. So I would rather answer the last question and then go back to the early one if I may.

Marc: Great.

Tzury: So what goes into the open source? I would say almost everything.

What do I mean by that? So when we-- actually, it was me to be honest.

When I came to the board with this bold idea of open source, I was like a child growing up in willing to fulfill his childhood's roots. Right?

I'm a great fan of open source being open source for almost all my professional life.

And I needed to build a case. So I was told, I was given some ideas.

People talking to you and already you just come up with something.

People already come to with ideas and what they think, their opinions and so on.

Okay. So we're going to put these start ups, say, out of 10, let's put like six, seven features for free, and then the remaining will be commercial.

But what we chose to do here, we've chosen completely different way.

What do I mean by that? Feature wise, capability wise, functionality wise, Curifense will be a complete product.

Meaning, we provide you with all the tools that you need to get full protection for your application, for your platform.

We don't take some features of security, core security features and say, "You pay, you get it."

No. You get it for free. That's the idea.

On open source product, in order for it to be successful, it must fill in its space.

Cannot do like 70% of the job.

Just like Envoy does everything you need it to do as a proxy, just like Nginx did it and still does it, just like MySQL and Postgres.

So every successful open source product you look at.

The open source product, the successful one, usually cover and fill in its space. So that's the idea.

Now, what we do here is basically challenging the competition in a way we say, "Okay, so product wise, feature wise, functionality wise, capability wise, we provide the same, and if not better than competitors for free."

All right. So without even starting counting a dollar for you to get what you need to be secure.

What will come into Curifense that will be commercial will be management tools that we believe you will need as you will protect larger environments and more complex Kubernetes deployments.

And what I mean by that?

So we talked about those tagging and rules and signatures and all sort of mechanism.

I think we had like six or seven different mechanisms that works in conjunction for each and ever request.

You can get things done pretty quickly for, I would say, one, two, three, whichever number of Kubernetes deployments that you have depending on how many applications within each and services within each and every deployment.

But certain point of time, you'll find that those repetitive work are quite time consuming and there is automation that could have saved you some time digging into the logs and eliminating the possibilities for false positive and so on and so forth. So here's where we comes and provide you what we call, it's internally right now, security automation.

So based on data analysis, based on your log analysis, the system will provide you recommendations for how to refine rules which already define rules for the system believes are missing, or recommending applying this and that.

All sort of recommendation and improvements on helping you managing complex large-scale off Kubernetes deployments.

And that's where we're looking at starting the commercial part.

The other part of the commercial would be our mobile listed key, which right now is part of our Reblaze commercial product, which is an SDK for Android and iOS developers, is to integrate these etiquette into their applications.

All requests performed by the application towards the API servers, the backend services and so on, are authenticated by Curifense and verify that actual user holding the device and it's not an emulator mimicking a device.

It's not just API calls, it's actual device.

And we do that by simply hooking into the device metrics and signals and sensors and gyros and so on and so forth.

It's all in the website. So all this information.

Marc: So a normal web application firewall is inspecting the traffic that comes in, but by integrating that SDK, you're able to have data on both sides and code executing on both sides of it.

Tzury: Yeah. Right. I mean, for the web browsers we already provide it as part of Curifense, as part of the free.

So for web applications, runs in your browser, we provide you within Curifense a verification of that's a real browser and not a headless browser, and not a Selenium or any others, Chrome or Firefox in headless mode.

We provide you the verification that it's not just an API call with the proper user agent, whether it's a actual, real, visible, interactive web browser interacting with your application.

But only by your metric part, meaning a user is clicking and moving their mouse, scrolling, touching and all this stuff is part of that client-side verification.

But the automation analysis and the machine learning and the AI we have on top of it, that will be part of the commercial.

Marc: So just to go all the way up to the top layer here for a minute, the whole goal then is by all of the work that you've done for years and years, and now it's in Curifense, says that I can know that the only requests that get to my server, my API, are actual legitimate requests by actual users of the application that I want to be interacting with the app.

And other bots and anything else that might be happening, they go somewhere else. They get rejected with some HTTP error code?

Tzury: Yeah. I mean, you can choose error code.

You can choose redirect them. I mean, some of our customers, what they do with scrapers is simply providing like fake data, for example.

So if the system detects a bot which is attacking or attempting to attack an API, instead of blocking them, meaning they will not go and change your IP address, change your techniques and so on.

You simply feed them with fake response, meaning with junk data that looks real, looks good.

But for the attacker, as long as they don't know they are being detected, they will not change their attack.

So this is also a possibility. So it's all built in the system.

You can control and define and customize your custom response, such as block code.

You can respond with a block code like 403, 503, whichever one you choose.

Sometime you can redirect, you can provide other content, you can provide notification, you can do whatever you want.

Marc: I'm assuming that there's ways to integrate this into different monitoring tools and alerting tools. Right?

So if there's a flood of attacks on my system, I can hook it into existing functionality?

Tzury: That is correct.

So the build team that we provided from day one, it was important for us, is setting all the metrics to permit to use.

That is our Grafana, dashboarding, alerts and so on.

And as well as for ROWLOCKs, we provide support for PostgreSQL, Elasticsearch and Google BigQuery.

So as you monitoring incoming traffic, whether on the log level, and the logs are basically comprehensive records of all the data, the entire request with all the arguments, cookies, headers and all the attributes and all the tags and all that additional information and all the process and all the flow on the Curifense took to prior to forwarding the request to the abstract.

So either you're monitoring the logs, or your OEN 00:20:23, or you're monitoring your permit use Grafana.

That's where you can get all the alerts.

And let alone, just to say that within the commercial product that we also provide support for other SIEM and SOC integrations.

So like commercial SIEM products from IBM, HP and so on and so forth.

Marc: Great. Yeah, this is a cool project.

I want dig in a little bit more, maybe go a little bit deeper in the weeds on session profiling.

You mentioned that you can make intelligent decisions based on the session data.

So if I want to integrate Curifense into my application and I'm passing a JSON web token, a JWT token back to the backend, how much work does it take for me to be able to provide Curifense information or the intelligence, the instructions, for how to decode that JWT token and figure out what to do?

Tzury: All right. No, it's actually a very good point.

So this is what we are not going to do within Curifense, at least in the foreseeable roadmap.

In other words, as it comes to API security, one of the things we not planning to do, because it's crowded and everybody else is doing it within the API gateways and API product within Kubernetes and outside of the Kubernetes ecosystem, it is API authentication and JWT, or whatever mechanism off integration, whichever methodology used for authentication, right?

So Curifense will not look into authenticating and say, "This API is key."

Talk in provided is authenticated valid or invalid.

That's not what we are looking at doing, because we assuming you already have it by other tools.

But Curifense we're looking to the overall API behavior, in addition to pair request.

So it's important to mention.

Within Curifense you have three layers of observability and control.

First one is that each and every request, pair request, right?

So the request itself by itself, where it come from, the IP, this number, the content, the headers, the data, the decoding, encoding, whatever.

Whatever there is, that's been inspected, deep packet inspection, by all means.

And top of it, there is a session monitoring.

So based on your choice, we may build within Redis, which by the way, provided by Curifense as you deploy, or you can just point Curifense to use an existing Redis cluster that you have.

But within Redis we build all sorts of data structures that monitor our session.

Session basically are segments of requests and responses.

So those are within real-time protection with session overview.

Meaning not just be a single request rather a whole sequence of requests.

For example, suppose you have a web form, simple landing page with a sign up form.

The sign up form, when a user click on the button submit or register or sign up.

Behind the scenes there is a security post request exploits a JXN, submit data, permeate the from to complete their registration or just sign up operation.

In that case, if you monitor just to post for sign-ups, right?

As you can get some level of protection by monitoring each and every post, and running from one post to another what seems to be legitimate, what's not.

But if you look at the overall session, meaning, the user downloaded the page first to their browser before submitting the post.

Meaning, there was a get for that URL prior to the post, and when was the get, and when was the post?

I know that within my sign up page, I have this and that request and signals and pixels that downloaded to the browser, was that taking place.

So all those signals that tells us up there in Curifense, on a service side, that whatever happens to the client side seems to be legit, the sequence or in order and everything seems to be in place, in intact.

Versus just post sign ups that they send over and over again, either from different IPs, but being sent on their own without any prior interaction with the system.

So that's another level of session protection and session monitoring essentially in Curifense.

But this is not the end.

Above that, there is the log based processing, the data analysis we do on the database, on the logs.

And that's usually we'll go over longer timeframes and different sessions and different applications.

Usually a user within an application will interact with multiple services, while simply using log into the application, clicking on that module and products and orders and different models.

Different models represent usually different microservices in our backend.

So by looking at the data, the overall data of a session, of a user, then you can learn what the actual user was doing, how legitimate it is, and detect anomalies, and detect malicious activity and an intention even.

Marc: So does Curifense start to learn what's normal behavior?

Outside of like, "Hey, that's unexpected and anomalous behavior in the way that we would expect a generic HTTP requests to behave," but does it start to understand how users of my application interact with my application and start to detect weird patterns there?

Tzury: Right. But that I'll emphasize, those parts, the machine learning stuff, that is part of the commercial, not on the free open source.

Data machine learning, data processing based on previous and prior behavior and so on and so forth.

And one thing I'd like to mention here Marc, off topic, but not so much.

I mentioned we process dozens of billions of requests per day, and our clients, current one, we provide our solution today, even outside of Curifense, as a single tenent SaaS.

So should customer of Reblaze runs on their own isolated environment.

And that is a complete self-contained environment that we would deploy automatically for each and every client, just for the principle that we do not believe that a multi tenancy security based cloud SaaS solution can even be considered as a good way to go, as a good solution, good architecture.

I would say acceptable architecture, in our opinion.

And over the years people, investors and opinionators ask us, "How come you're not..."

I mean, competitors, when they have this massive database of all their users and all their users in same platform, they can share data and they can learn from one to another and so on and so forth.

Fact is that most of the attacks, sure enough, more sophisticated attacks, you cannot learn one and reuse that on other applications, even within the same client.

Each and every application is it's an organism, its own way of behaving in usage and so on and so forth. So that is for what you asked.

It is indeed learning what's normal, what's acceptable, what is good, what is, I would say within the boundaries of a regular usage of your application, of your service and will apply rules and policies and thresholds within automatically. Will also adapt as things change.

So you're releasing your version of your API, all of a sudden microservice of it so far, is it seven API calls, all of a sudden it does only three, for example.

The system is adoptive, is learning that the legitimate has changes form and will react accordingly.

Marc: What I'm hearing is, the value in multi-tenant SaaS of that deployment model, the risk doesn't make sense because there's not massive value in the learnings inside each of these.

You're treating them all individual.

So if I sign up and I'm using Reblaze, you're looking at my application in itself, you're not sharing that data, the learnings with other apps, and also not applying other learnings that may not actually really be that applicable to my application traffic.

Tzury: That is correct. I mean, there is some information which we can learn and adopt, such as a new rotation that we build.

So if all of a sudden we see like a bunch of IP attacking certain targets and then attacking another one.

So per se, for those IPs for a given amount of time, for a given time window, we will consider them as malicious and we'll publish this information across different clients, because it makes sense.

I would say, anomaly detection must be done based on the application anatomy, which is different from each and every application. Every application is built differently, just like human beings.

Marc: Yeah, yeah.

Tzury: Yeah. So you can't treat them all in the same way.

Marc: Great. Let's dig into rate-limiting for a little bit, because I think that's super interesting in a problem that, whether you realize it or not, every application has.

Like if you have a forgot password button, you should put a rate-limit on that.

Otherwise, there's the OWASP security model and rate-limiting is a critical part of that.

So you mentioned that Curifense can handle pretty advanced rate-limiting rules. What can I do?

Tzury: Okay. So let's go step by step.

Level one, how many times a given IP you think would be legitimate for doing the page you submit and create account or login request within given timeframe.

That's a bi-dimensional classic rate-limiting that you could say that from a given IP, you're not expecting to receive more than say five login requests per five minutes, for example.

All right? So that's basic straightforward, everybody has it. Not a biggie.

But let's say, that's based on IP alone, it's not that, I mean, powerful let alone correct.

Because we know that gateways such as mobile carrier, Wi-Fi gateways and so on, they will serve multiple users.

So you're on the airport and using airport Wi-Fi.

All 15,000 people within the airport are using the same public IP when they go into the internet.

So within the system, all 15,000 users are using the same IP.

So in that case, you can say, "Okay, I'm going to look not into the IP address, I'm going to look into also the user ID, the email address that you submit within the login," for example.

So that means now you changed a rule, not count unique IPs, rather to count unique user IDs.

But we're still looking at user ID within a given timeframe.

With Curifense, what you can do easily, so you can do all the above.

But more than that, you can also say that by looking into unique ID, say email address or username or whatever it is within the application, you can just choose header, cookie, arguments, session ID cookie, or argument, whatever.

You can also look and say, "How distributed would you allow these ID to be?"

And what I mean by that? So what if we receive your, say, marc@gmail.com, we're suited for one IP.

And then within a few second receive it from a different IP, and then another IP.

How many unique IPs should be an given ID submitted in a given timeframe is still considered legitimate?

One example, what if those IP are within completely different countries?

So I see Marc trying to log in from United States, all of a sudden he's trying to log in from United Kingdom, and then from Canada.

So what's going on? So obviously what we seeing here is a attacker of which aware of IP base rate-limiting, and what they do?

They distributed their attempt across distributed network of botnets.

So as the user is roaming and hopping between different IPs, all of a sudden you see unique IPs and unique IDs.

So all those different cases of your ID being submitted across different countries, different numbers, different internet vendors, ISPs and different IPs and so on, this also can be controlled within Curifense with few clicks, literally, or one single API call for that matter.

So just what I'm saying, it's quite powerful, and this is not just single rule that you can apply on your login to put that.

You can layer them, as I said, multiple rules by IP, by distribution and so on and so forth.

And also their reaction. If somebody performs say five times within a minute, it will give a reaction.

But then if they do 15 within three minutes, meaning they're still trying, then you may want to ban them for a few hours and so on.

All this already built into Curifense.

So you can simply escalate the reaction of the system to all those attempt.

Marc: And you mentioned the API or the web UI, Curifense is running in my Kubernetes cluster, so can I define the rules and the policies and the actions, the bands, all that stuff, and then just deploy it through a GitOps tool like Argo CD or Flux?

Tzury: Well, that's a great-- I'm really happy you ask this question, Marc.

Because Curifense storage engine is basically a Git repository.

Everything you can do within the API or the UI ends up in a commit within a Git repository that holds all the rules and all the configurations, and all whatnot, within the system.

So every change you do is on your commit.

Now, that gives you the ultimate GitOps experience. And what I mean by that?

You can manage files on your laptop, commit and push to the repository configured by Curifense to look at, and from that point on every time you'll push to that, based on tags or based on the branch name, up to the way you like to do things and get things done, that will update the system automatically.

More than that, if somebody made a mistake, you can roll back either as an API or the UI, or just within the Git.

You can roll back to any revision that you believe more stable, and get things fixed and reversed immediately.

Not only that, you publish from a branch to a target. Meaning, if you like prod, test, Q&A stage and so on and so forth, you can all of a sudden grab or publish the prod to your Q&A if you want to do some testing, for example, and check why certain things happening within your system and you don't need to touch your production up until you figure out things on a testing environment that then you can push changes and back and forth.

So it's pretty safe to make changes within Curifense, pretty safe to roll back and roll forward.

And more than that, it's fairly easy to integrate with any GitOps tools out there because it's simply Git by definition.

Marc: Right. Yeah. That's awesome.

I think that's the best benefit of GitOps deployment.

It's like all of the existing tools that we know, and the workflows we know, and how to--

We're developers, we know how to revert a commit.

And it turns out, I don't need a different process to revert a deployment.

Look, that's the same thing. Let's just leverage that. So that's amazing.

Tzury, one more question on the product itself.

I'm looking at the repo, and we've talked a lot about the product architecture and how it works, but let's talk about the tech stack.

What are the languages that you built it in and how's it built?

Tzury: That's a great one, Marc.

You want to go through the history of the languages we used? Or you want just define the one?

Marc: Yeah, I think all of our projects look a little bit like that. But yeah.

Tzury: All right. So a fun story. So we started writing Curifense in Go. Why Go?

Because at the beginning, on implementation the first iteration that we thought the MVP would be, is still MIXER plugin.

And by that, that means writing it and Go.

However, the customer we work with, which is Cisco by the way, and thank you, Cisco, for supporting this project from the very beginning.

Without you, Curifense probably would not be what it is today.

It still was going through changes and from one X to one Y, whatever the exact number they decided that would be best from MIXER will be taken to the sidecar and the gateway and so on.

So we realized that there was no future writing in Go MIXER plugin.

And quick enough, we decided to switch gears and build it on top of Envoy.

Now, building on top of Envoy a given timeframe that we had, just rewrites of a product with an ongoing development, and there is a deadline for releases and so on.

So we started with Lua. We saw that Envoy supports Lua, so let's write it in Lua.

And we simply was not fit for Lua. We have written in C and integrated into Lua.

So that how we started.

But sure enough, when we finalized what we believe was alpha version of the Curifense, and then we look into performance, that was a problem.

As I said, we process a lot before we started looking into the headers and the cookies and the actual body of the request.

So we start writing Curifense in Rust.

So basically, there is a Rust code base that is now taking more and more chunks from the Lua and migrated to Rust.

And our Rust is compiled as short object, C short object that expose to the Lua.

So basically, the Lua is just the glue between Envoy and the Rust, which is safe, as we know.

Memory safe and performance and so on and so forth.

So that would be one version of Curifense which is the Rust compiled and the Lua the glue in between the proxies.

That is great because the next step in this case we're touching roadmap.

Next version of Curifense, probably early next quarter, which is effectively next month, we will announce full support for Nginx.

So we're using Envoy more Nginx.

Same product, same configuration, same policy.

You can use mix and match with both and we had the same.

So if you have a Kubernetes that some parts of the community is the Envoy and other parts is in Nginx, not a problem.

Same applies and it works the same in both cases.

And there are more, we say we're looking into with Lyft, actually the teams from Lyft and then other Envoy maintainers to work on a deeper integration.

But for that, I will rather discuss when things will be more mature.

And obviously, those are not written in Rust or a Lua.

Marc: Is the Nginx implementation easier or possible because of Nginx's Lua module?

Or is that totally irrelevant and you had to kind of build Nginx from the beginning?

Tzury: No, no. So that would be Nginx with Lua module.

Again, the Lua will be the glue between the proxy, in this case Nginx, and the Curifense which is the Rust implementation, compiled as a studied short object.

Marc: That all makes sense. The only part that I didn't quite get was why Rust and not Go?

You started off with Go, you're looking at Go, but you ended up with Rust.

Was it for performance, type safety, just easier with Rust or what was the reason?

Tzury: Yeah, I would say that the type system for Rust and the safety.

It was chosen by the team, they really liked that one more than Go in the terms of capability, of compiling it also.

And either for-- there was--

We were looking into WebAssembly, the possibility of using all WebAssembly, even though we're not using WebAssembly.

Because WebAssembly is Sandbox and quite limited to what you can do within the Sandbox.

We do a lot more than right now is available.

But the team chose Rust over Go. I think they liked the type system of Rust more than the Go.

However, we do use Go all over the place, don't get me wrong, I mean.

So parts are written in Go, some parts are written in Rust, some parts are written in Python and some in Lua.

Multilingual project, but fun to work with.

Marc: Use the right tool for the right thing, don't try to fit everything into the framework.

Tzury: Yeah.

Marc: Justin, I'd love to pull you back into the conversation here.

Justin: Sure.

Marc: Curifense is a CNCF Sandbox project and relatively new.

Towards the end of 2020, were you involved in the process of submitting it and getting it accepted?

Can you walk through what that was like?

Justin: Yeah. So I was, and the reason I joined Reblaze is because this was an opportunity, and it was always something that I was just always wanting to be involved with the Linux Foundation and CNCF.

So it was just a great opportunity. And I told Tzury I'd only join Reblaze if we went ahead with the CNCF.

So it was cool because before I even joined the company, I had a call with the CEO and the VP of marketing and I'm like, "Do you understand what happens when we give this, when we donate this project? It's no longer ours."

And they both were on board with it.

And I was like, "This is the right company. I got to join them."

I mean, really, we donated it because we believe the best way to sustain an open source project is that the project is part of a foundation.

And since Curifense extends Envoy, we thought this was probably the best fit for Curifense.

And another reason for joining the CNCF is we remove a lot of legal and governance obstacles, so we can get more users and more contributors. And they, the CNCF, makes sure that we adhere to their standards, which are very, very high. And we liked that.

Just joining the CNCF really does ensure users and adopters that Curifense won't bait and switch on a non-OSD open source definition compliant license, like the SSPL, the service side public license, or the business source license that we've seen many other projects that a company is behind have done.

And we want to ensure that Reblaze doesn't have those intentions.

Marc: Yeah. I mean, I think it's super important.

Reblaze can continue to exist with a commercial offering and making money is important, because it gives us the opportunity to do this, but donating it into the CNCF, especially something like Curifense, which I want to integrate in at a pretty critical layer in my infrastructure.

So I want some kind of guarantees around longevity, the project's going to be around for awhile.

I think, to me, it makes sense that as a CNCF project, you kind of check a lot of boxes by default.

It's not some open source project that may swap the license out two years down the road.

Justin: Right. Well, I mean, there's some really great projects that we've been looking over.

Tzury and I, pretty much on a weekly basis, look at linkerd.io and we say, "Okay, what is William Morgan doing?"

Because they've done a really, really amazing job at community and also showing that, "Hey, this project is by Buoyant, the company that is sponsoring the project for doing a majority of the investment, but it's also owned by the CNCF."

So we really, really enjoyed, number one, that podcast that you did with William, it was a really great podcast.

But we also really were very heavily inspired by what Linkerd is doing.

How they've gone from Sandbox to almost graduation.

And we want to basically follow that playbook, and put our own spin on it.

But still, it's really great to just see other CNCF projects and how they've evolved and also find ways to get a return on investment.

Because a lot of time, money and people hours is going into getting Curifense.

It's not just like a bunch of volunteers yet. You know?

Marc: Right.

Justin: So it's just important to us to know that there is light at the end of the tunnel to get a return on investment, and we're going to do that with the inspiration from other CNCF projects like Linkerd.

Marc: Yeah. That's great. Yeah. I mean, standing on the shoulders of giants, as they say, right?

Justin: Yup.

Marc: Like being able to see people who have blazed this trail ahead of you.

Justin: Exactly. And it's really helped me. Because the CNCF is relatively new.

It's like 2014, 2015 they launched.

So it's hard to go-- I've been a part of many open source projects, but this is a lot different.

This is, you can't just make up your own rules and go gung-ho and say, "Hey, you know what? I'm just going to do this."

Everything's got governance and standards that you have to adhere to, and being able to look and reach out like I have a meeting with William later this month, and get to ask him like, "Hey, where can we improve? How did you handle this?"

It's kind of like you really get into a family in a way.

Marc: Yeah, that's great. Yeah.

It is new, the CNCF, and they've also last year changed the Sandbox application process.

The bar was higher before, and I don't know, Curifense likely would have passed that bar.

But the push in the CNCF right now, in the TOC, the technical oversight committee, is really to lower it down and make it easier and easier to get experimental style projects adopted in, which hopefully just increases the number of projects tremendously.

Justin: Yeah. Well, I mean, number one, thanks for making me feel-- completely deflate me. I'm just kidding.

No, but number two, you do see that. There are like a lot of GitOps working groups.

You see a bunch of experimental projects here and there, which I think is actually good and encourages inclusion and making sure that, "Hey, you know what? Maybe there is that one project that is kind of like, 'Eh, I don't know if it's relevant, but it could end up being a really big hit.'"

Marc: Yeah, just in general, one of the things that's exciting, both Curifense and about a lot of the newer Sandbox projects is, open source projects really focused on security, it's not something historically that we've had a lot of.

Justin: Right.

Marc: With such good security expertise and it's now available to a one or a two person startup can throw Curifense in a cluster and actually get a enterprise grade web application firewall.

Justin: Exactly. And as an open source project that can be really used without any commercial support, if you don't want it.

It was really validating yesterday, VMware acquired a company called Mesh7, which I just found out about yesterday, but does what Curifense does, but it's a proprietary offering.

So we know we're in the right space.

We know we have really great support from Matt Klein who is the creator of Envoy, and also Chris Aniszczyk who is one of the leads of the CNCF.

So we're lucky to have that.

But also, we have a great product and we have a great project that is going to make sure that the folks that are using Envoy, the Airbnbs, the Netflixes, we're going to eventually have them as users and contributors.

And we look forward to that because it's just where things are going.

You just see more and more companies adopting cloud native approach to software development, and Envoy being that sort of, I wouldn't say Nginx replacement, although you see more and more companies using that service and HTTP proxy over Nginx in the cloud native space.

I still love Nginx. I'll always be a fan of Nginx.

And we're also, as Tzury said, going to be supporting it soon.

But yeah, we're really, really excited about the Envoy ecosystem and look forward to serving all of them.

Marc: Yeah. That's cool.

We've talked on and off about the future roadmap like, "Oh, there's Nginx coming up, and there's some changes that we're going to make."

Let's actually dive in for just a minute here and actually chat about what's specifically on the roadmap.

Like if I want to adopt Curifense now, what's in the short-term roadmap that you guys see that are important and strategic for you to finish out in 2021?

Tzury: Starting with marketplaces.

So within few weeks, you'll be able to deploy Curifense from within your Cloud Marketplace, or Amazon, Google Cloud Platform, or Azure within their managed Kubernetes, for example, in addition to the Helm Charts and the other deployment tools that we provide today.

There would be, as I mentioned, the Rust part will be completed soon.

That means much better performance and safer and more capabilities.

Everything related to security automation, I mentioned.

AI, machine learning, base analysis and policy, automation policy, definition, recommendation, it's coming down the road within H1.

So there's a lot of exciting stuff coming down the road.

I would say a whole bunch of analytics and reporting layer on top of Curifense that you can just plug and play on top of say Kibana or Grafana, or probably I can't tell right now specific one, but from my experience software delivered, it's so dynamic.

So I'm assuming we will have more tools in addition to Kibana and Grafana, I mentioned, for analytics and visualization.

So just say, "Use the product."

And by the way, by the way, even though it's open source and free, to ensure early adopters getting everything they need to get started, we had made this internal decision to treat each and every user, GitHub user even, as a paying customer even though they're using the free product.

So they will get full support by our team, from deployment questions, advice and consultancy, and everything as if they were like commercial customers.

Marc: Wow.

Tzury: Just so we make sure we get this feedback and real world experience and improve as we move forward.

Marc: It's free fanatical support.

Tzury: Exactly.

Marc: Yeah. I mean, you get great product feedback, but also somebody who's adopting it, kind of a little bit of a design partner on figuring out more of the medium term roadmap, probably, they can influence it pretty significantly.

Tzury: That will definitely influence it.

Even if they would not intend to.

Marc: Cool. Since joining the CNCF, has there been changes to the way you're handling the open source community?

Justin, just a open question there, how are you handling the community side?

How do people get involved in the project right now?

Justin: So we're lucky enough to be a very new project where we're not getting flooded with issues.

But the issues that do come in, I am so excited to be helping out and basically working with our team to make sure that these get squashed out as soon as possible.

We had one gentleman from the Istio team that opened an issue, and to me that was really, really awesome.

We just got to do an update for a newer version.

But I think that one thing that we're doing is, we're investing a lot in swag because as I have learned with working with the DigitalOcean, Hacktoberfest for years on end, you would be surprised what developers would do for a T-shirt.

And we really feel that having really good swag, just like Linkerd does, will encourage brand advocates to talk about Curifense and it's just a way to grow this community.

We have a Slack channel, we have our social channels, and it's a grind.

We're very new, so it's hard to really get attention.

But right now, I think just making sure the product is just getting better and better, and when new users come in, whether they want to be contributors or just they want to use the product, that they know there is a community person, who is me, that is going to treat them like royalty.

It's not like me just saying that, I really am excited for new users that are opening up issues because it's a first impression.

If we treat them like garbage, who's going to adopt this? So We're excited.

Marc: So to that end, is there any specific targeted type of use case that you'd love to see more of or is it really just, "Hey, anybody who wants a web application firewall and is running cloud native infrastructure, try it out, give us some feedback."

Justin: As I said before, since we are an extension of Envoy, we're looking to adopt as many enterprise users as possible.

So we're lucky to have Matt Klein as a product advisor for Curifense.

And we think we have a good shot of eventually getting Airbnb, Stripe, Netflix, and others to adopt Curifense, or contribute to the project.

So in terms of use cases, we would love them to use every component of Curifense as possible, or use just one feature, whether they just want to just use the WAF or the seven layer DDoSs protection.

I mean, it's really up to them. But what we want is large enterprises using the product and telling people, "Hey, that's what we use in our stack. And that's what Reblaze makes."

That's kind of what we're going for.

Marc: Awesome. Tzury and Justin, it's been really great chatting about Curifense.

Before we go, is there anything else that you'd like to add?

Tzury: Well, personally, I like to thank to each and every team member of Curifense, Reblaze team obviously, but far beyond Reblaze, teams from Lyft, headed with my client, teams from Cisco, Airbus, eBay, Red Hat and Elastic, the CNCF team obviously, Justin, and everybody else, every team members.

Really, without them nothing would have happened.

So that is a great opportunity for me to thank each and every one for endless amount of hours and efforts putting into Curifense to make it what it is, and obviously keep working, keep improving and evolving the product down the road.

And sure enough, my client, Chris and Santos from Cisco, you guys are awesome.

Without you, this would never be happening.

Marc: Yeah. And our maintainers who are Flavio Aviv, Phillip. I got that right, Tzury?

Tzury: Yeah.

Marc: Xavier and Spiros, thanks. I always screw up Xavier's name. Can you say it please?

Tzury: Xavier.

Justin: Xavier. Okay, yeah. So those are the maintainers and they're just an amazing group of folks to work with, and I'm very lucky to be able to work with them on a daily basis.

Marc: That's great. Justin and Tzury, thanks so much for joining me.

I'm really excited about Curifense. It's a new project, but it's got a lot of maturity, a lot of story to it.

And I'm personally really excited to see this project move forward, see what happens and watch it get through the incubation, and hopefully onto the graduated phase and widespread adoption.

Tzury: Thanks so much, Marc. It was a really pleasure to come on the show.

Justin: Indeed.

Tzury: Marc, thank you very much for your time and for the opportunity.

And we're looking forward to working together.