Orchestrate all the Things - Single point of control, database security as a service: jSonar gets $50 million funding from Goldman Sachs. Featuring CEO / Founder Ron Bennatan

Episode Date: June 26, 2020

jSonar offers a security layer that sits on top of databases. Let's face it: database security is not the most appealing topic for most people. Bennatan is very aware of it. That, however, has not stopped him and the jSonar team from carving out a spot for themselves. And it has not stopped Goldman Sachs from investing 50 million dollars in jSonar either. Let's hear why, and what makes jSonar special. Article published on ZDNet in June 2020

Welcome to the Orchestrate All the Things podcast. I'm George Amatiotis and we'll be connecting with Ron Benattan, CTO and co-founder of JSONR. JSONR offers a security layer that sits on top of databases. Well, let's face it, database security is not the most appealing topic for most people. And Benattan is very aware of it. That, however, has not stopped him and the Jsoner team from carving out a spot for themselves. And it hasn't stopped Goldman Sachs from investing $15 million in Jsoner either.

So let's hear why and what makes Jsoner special. I hope you will enjoy the podcast. If you like my work, you can follow Link Data Registration on Twitter, LinkedIn, and Facebook. So, thanks again for making the time. And I'm going to start with a question. Well, I don't know if people have asked you that before, but I'm going to ask you just because I got things mixed up, basically. So, I was wondering, what's in your name? So, why Jasoner? got things mixed up basically so I was wondering what's what's in the name so why why JSONR and

to give you a little bit of context the way I got mixed up is I replied to the initial email you know informing me about the upcoming funding and so on by mixing up your name with JMeter which was a tool I used to in a previous lifetime, to monitor app applications. So I wonder, you know, what's behind Chase Honor? Okay. Yeah, a lot of people ask and we're really bad with names until fairly recently before Mariah joined. We're just a bunch of engineers. So we choose cheesy names and that's where it comes from.

So the original name was created by a combination of JSON and archive. That's where JSON-R comes from, because one of the main tech components in the system is this JSON-based data lake for security data because we need the data to be we need to be able to store all types of data very easily without having to jump through hoops so it's a json based archive for long periods of time to handle retention. And then it so happened that also the term Sonar was helpful because we store all this data to find patterns and find things. So we kind of said, oh, this is a great name. It's both the JSON archive and also it's a Sonar system.

And all our products, then we started calling with Sonar as the prefix. So we have a product called Sonar-G and Sonar-C and Sonar-SQL and Sonar-K and really confused the customers because they said, why sometimes do you stick the letter at the end and sometimes you stick the letter at the beginning? But there you go. That's where we ended up with. Okay, well, as someone with an engineering background myself,

I sympathize. That's all I can say. Part of me is happy because I guess it's right. There is some kind of Java involved in that, actually. So from the JavaScript to JSON and then to your name. So with that out of the way, just to get things rolling, that's a very typical question. So how would you describe what JSON does in one line, elevator pitch?

We just make good database and data repository security. That's really, really simple. That's what we do. We make security products for where data lives, but we do it in a very good way. Okay. Okay. Yeah, that's a good explanation indeed. So you did mention earlier that before you had your current marketing lead join, you were quoting you a bunch of engineers. So I was wondering if you wanted

to share a bit of history and background, like when did you get together, how and why did you get the company started and what has been your path leading you to where you are today? Okay, sure. So we started in 2003, kind of in the second half of 2003. And when we started, there were two of us, Wuri and myself. And Wuri and I have been together for, I don't know exactly, but maybe 30 years. We first met at the distributed systems lab in the university.

I was doing my PhD. He was a 16-year-old kid who was writing kernel-based file systems. Then we spent some time in the Israeli army together in the same unit. Then we spent a whole bunch of time in other startups. So we've stuck together for a long time. And then we both decided to start this in 2003. We started working on this, just the two of us. And then at some point, we thought we had something.

So we started building the company. And that's also why the company is kind of split between Boston and Vancouver in British Columbia because he lives in British Columbia, I live in Boston. So that's how we were formed and then we started, it took us a while to build the first version of the system because there was a lot to build. But the minute we got started, because both of us have done a few startups, we know that you don't build things by yourself. You build things with a bunch of customers that tell you that this you know, this is a stupid thing to do. This is a smart thing to do. So we didn't try to create a product that was perfect. We just tried to create something that we knew was good enough. And then we started with our,

you know, first set of customers and, you know, we view them as friends. So they were open enough to tell us this is stupid. Stop doing that. We're our problem is really here. And, um, and that's how we've been growing. We've been growing by just being very,

very close to, to these, to these people and doing what they tell us to do. Um, and it's been, it's been interesting since then it's been so you know at the beginning it goes slow because you don't know exactly what you're doing but the minute you pick up on something that is a problem that a lot of people have then then we started to grow and we've been doubling since

then so every year we double now again doubling doesn't mean the same thing. Sometimes doubling means, you know, we hire more people. Sometimes it means we have double the customers. Sometimes it means we have double the revenue. But overall, that's been the path for the last, I want to say, three years, three, four years. Okay. Okay.

So, yeah, actually, I have to admit that before I got news about your upcoming funding, I wasn't familiar with the name obviously and I didn't know about what you do, but you must have been doing something right to be able to get that kind of funding. I also have to say that this something is probably not a very sexy topic for most people, security and policies and all of these things, but the fact that you have been growing like you have and you've reached that point means that there's use for that in the market and I also like the way you described the interaction and the growth that has been coming as a result of that. So I was actually going to, my original plan was to mention the funding details wrapping up but I think you know I think that the way you described your growth,

maybe it's a good point to mention it now. So, yeah, you're getting funded with a hefty amount, actually. So $50 million. Would you like to share a little bit on how that came along? Well, you know, again, typical question, what are your plans? How are you going to invest this money? Yeah. By the way, you said something a second ago,

which is something I always say and which is odd, right? That this is absolutely not a sexy area. And you're absolutely right. And it has to do also with the answer to why this funding. It's not a sexy area because it's not a lot in the news. It's not something that is new. It's not like Kubernetes security new. You know, it's not like a Kubernetes security. Everybody talks about it. However, it is on the other side, if you think about security and security comes in various layers, this is the security for the layer that in many ways counts the most.

It's the data repository. And the reason it's not sexy is because A, database has been there for 40, 50 years. And it's not sexy because it's been around for a while. And when things happen, they're very bad and they're so bad that nobody knows about them, okay? Or nobody knows explicitly about them. But what Goldman saw, or what Goldman kind of knows, even from their own inside, right? Goldman is the top of the company, is that if you don't have good security at that layer, then almost nothing matters. And whenever you have really serious problems, it has to do with, maybe there aren't a lot of cases, but when there's a case, it's a trauma. It's a disaster for the company. And so we were growing very well. And we got to know Goldman more than a year ago,

even not with a specific agenda. And since then, we've just kept in touch. And at some point, we decided on the JSONR side that we need to do a growth round because, yeah, we can grow the way we're growing, but there's no reason why we can't grow much faster. For example, we have no presence really outside the U.S. at all. And we're very focused on a very core set of customers and verticals. We have a good presence in financial services for obvious reasons. The banks, the insurance companies, financial services companies understand risk. They understand that they have to mitigate risk. So they invest first in this kind of technology. But you can't really say that only financial services companies have databases, right? Everybody has databases and everybody has sensitive data in databases.

So we saw that we could grow beyond the US. We saw that we can grow beyond some of our core verticals. We saw that we can grow beyond the very specific solutions that we're doing into more things. I'll give you an example. We do a lot of threat detection. We do a lot of compliance work. We do a lot of work that has to do with policy. But there are other areas that we just dabble in, like, for example, user rights management or being able to analyze, say that you and I both have access to a certain data repository and you have some privileges and I have other privileges and together we can do something pretty dangerous. And yeah, we're monitoring what you're doing and we're monitoring what I'm doing. But unless we go into the database and understand exactly the privileges and the relationships between those two things, then we just have half the picture.

So we realized that if we could invest more, then we could grow much faster in almost multiple dimensions. Or another example is our install base tends to be the largest companies, the largest banks, largest insurance companies, the largest healthcare companies. And it's a very lucrative market, but you have to ask yourself, okay, so if you take the Fortune 2000, that 2,000 companies in the world, what about all the other companies

that have databases what about companies that have 5 000 employees 3 000 employees do they not need database security do they not have databases are they not using aws rds are they not using azure of course they are so and but but to do something that works for them is a little bit different than to do something that works for the biggest bank. And the product, it's the same functionality, but it has to be packaged differently. It has to be delivered as a SaaS. It has to be simplified. So there's a lot of things we could do. And we said, okay, this is the time.

We're ready to take on more so we can do more yeah yeah it does make sense the way you describe it and actually uh just just uh listening to you i was going to make you that exact question uh which for you was a comment was your concluding comment so sass basically i it looked to me like you know the way you talked about it it looked to me like what you have been doing was maybe applying kind of in a consulting kind of way in a kind of services way working with specific clients like big clients like in the finance domain you mentioned, and others, I suppose, probably of the same magnitude. But you're right, if you want to take

this worldwide, then yes, you have to be able to provide it through software as a service. And so I guess, you know, that really answers my question very adequately. So you're going to go to expand in that area, I guess. Yeah, very much so. And we started doing this a little bit last year, but just like was typical in the company that was so focused on engineering, we just put it up. We created a website that was different from jsonar.com.

It was called dbstech2.com. And it was a SaaS version of the product. Of course, as engineers, not understanding that you don't do things like that. And that you kind of have to lead with a good structure and good awareness. And you have to, you know, the minute you start going beyond your core competency, you have to adjust it a little bit. You have to, you know, if you're talking to, you know, different size of companies, you know, they really need different levels of simplicity and they need different levels of functionality. And they need, if they're in a different geography, then they need different out-of-the-box things. And so we kind of, at the beginning, put the, I don't know how to say it, carriage before the horse. But that is absolutely an area that we're going to release a lot of capabilities around by doing something that is, you know, one of the big differences when you have a big company

and like I'm talking about a really big company, they have staff, they have staff, therefore they have requirements and they have people who can implement things. And therefore, when you work with those types of companies, they kind of tell you what they want. The minute you go to smaller companies, they don't tell you what you want, what they want anymore. They're looking to you to tell them what they need to do in order to secure their data well. And so the technology is there. What we're doing now is packaging it in a way that's just very, very consumable for anybody.

Sometimes that takes longer and more effort than just building code. That's why this is really important to us. It does. It does indeed. One question, to move on a little bit, to focus on the actual tech that you're using and how you are doing what you're doing. So one question someone may have when they get to know what you're doing

is like, okay, so every database does have security capabilities built in. So what is it that you do that offers more than just having a bunch of capable database administrators and letting them take care of things and implement whatever security measures are needed on the database level and is it the fact that you have somehow abstracted this and made that generic let's say and available through a centralized point or whatever database you may be using? Is it that you maybe have added some extra capabilities on top of that? You spoke for example earlier about having the ability to compare actions taken by a set of users and deriving some results out of that what is it that

you know makes what you do what gives it its added value compared to let's's say, out-of-the-box database security? Yeah, yeah. It's kind of everything that you said. And it's a good question because I think databases do have very, very robust security layers. But the differences are the way that we augment those things is a combination of things. I mean, the first one is more of a human nature thing. The person who's responsible for the security of the database is the DBA.

A DBA is not someone who has security in their mindset. DBAs have performance in their mindset. They have availability in their mindset. They don't really think about security, nor do they know a lot about security. And I worked many years in Oracle security. I worked many years before Jason in other database security companies. So the first is just who is responsible for securing the database? Is it really the DBA? The answer is no, not really. So the DBA doesn't know enough about security.

The security people don't know anything about databases because it's fairly complex. So that's the first problem that you have is nobody's really able to do this well because they don't have the right abstractions. So one piece is to make database security something that can be owned by security engineering, that can be owned by information security, without having them to understand the difference between a drop index and a drop clustered index. It's just too complicated, and they don't need to know that in order for them to do their work. The second one is that there's just so many databases. It's not like 20 years ago, I think a company, even a big company, would have four database types. They'd have Oracle, SQL Server, maybe they have DB2 on the mainframe and maybe one more now.

Every company has 40 databases. They've got their bunch of sql databases they started dabbling in no sql they have hadoop they have stuff running on the cloud each one of these has a separate security model there's no way for them to manage it at that level okay they need to have a consistent policy what is What does the security officer care that you're storing the data in SQL Server and I'm storing the data in Mongo and Mariah is storing the data in a combination of S3 and Athena? Okay, you don't care. If you're a security officer, you need to have a single policy. You need to have a single way of telling what's going on. So us being able to support all of these databases in a unified way, just think how much time that takes away from the equation. And the third is everything that we put on top of it. So in the same way that in every other security area, for example, in the last five years, there's been a lot of

investment on user behavioral analysis and entity behavioral analysis and threat detection. Same thing with databases. The database will just allow you to set a set of privileges, allow you to say, George can do this and laser can do that. But the question is not what George is allowed or is not allowed to do. The question is, okay, given that George is allowed to do this thing, is George misusing those privileges? So it's not a hard and fast definition of a policy. It's an analysis that compares the policy with the actual actions and tries to say, you know, George is an insider. He has privileges. He is the root user of this database. But should he really be doing that many select statements on the employee table and constantly looking at salaries of everybody? Why? You have to have that privilege, otherwise you can't administer that application perhaps,

but it still doesn't mean that somebody doesn't need to either alert or even prevent you from doing something like this. So those layers of controls are what our products bring on top of the different databases and then do it in the same way regardless of what the database type is. Okay, that makes sense. And actually it brings me to another question that I've been meaning to ask, which has to do with the way you integrate databases.

I'm assuming based on your description that you have a kind of integration layer and you connect to various databases using their APIs. I imagine both query the meta schemas you know in terms of privileges and so on but probably also do not really inserts on the data level, but modify user privileges and this kind of thing. And it sounds like you also have a layer that sits on top of that and lets the end user define and implement policies

and monitor how these policies work and who does what and so on. So when you have a new database to integrate, how do you go about it? What do you do? Yeah, so it's exactly as you say. What we do is we... Sometimes it's something we can do ourselves. Sometimes it's something that we have to do through a partnership with the vendor.

But what we do is first we check what are the public APIs that this platform provides. And the APIs sometimes are at the database level, but sometimes they're at other levels too. So I'll give you an example. If the database is a cloud database, okay, it's running on AWS or it's running on GCP, then sometimes the layers that control access are not necessarily the database itself. They're part of the cloud, right?

If you have a database like DynamoDB, then controlling things could be through IAM, not through Dynamo. Sometimes controlling things is done through security groups. So the first thing we do is we have to understand what the platform looks like, what APIs are available, what APIs are at the database level, what APIs are at the controlling level. Most of the time, these are public things. We don't necessarily need anything directly from the vendor, but sometimes we do work with the vendor.

We've worked with people like Snowflake directly. We work with people like Teradata directly, and we look at, we have a concept of, it's actually very similar in other security areas to the store layer, where we need to orchestrate something. So we have a concept of playbooks and actions. And so a playbook could be something like lock a user if they've done something strange, or a playbook could be something like lock a user if they've done something strange or a playbook could be auto-discovery of databases. Because if somebody is bringing up and down databases, you can't even ask the administrator to onboard a database into our system. We have to use the APIs to onboard that database into the system by ourselves automatically.

So that layer is responsible for anything that has to do with automation. And the reason it started with is that when you go to... So we didn't start by building that layer. We started building more of a detective layer. And then very early on, we understood that. We kept hearing the same sentence again and again from every CISO. We said, enough with the detective layers.

You've got to be a preventive layer. It's enough. We can't stand anymore all these systems which monitor things and tell us what's going on. Stop with that. Look at what's going on, but then put in the intelligence that will tell you what you need to do about it and put the capabilities that would integrate. And it's exactly like you say, sometimes it's, okay, go to the database and change the privileges. Sometimes it's go to, you know, you can think the same abstractions for 50, 60 database platforms, that's very valuable because otherwise they would have to do each one of them themselves. Yeah, again, that makes sense.

And to follow up, you did elaborate a bit on how you use APIs from the databases that you connect to. Many people these days, and actually I have to admit that, you know, initially before I got to understand your product a little bit better, my initial comparison, the way I tried to frame it was, okay, so is that another observability solution maybe is that an application monitoring solution applied specifically specializing in databases going a bit deeper I realized that you know that's that's you do more than that and you just explain how but given the fact that many people these days do have this kind of solution in place, does your product integrate with them in some way?

So do you have an outbound API that lets people consume the data you display in your dashboard in the custom dashboards? Yeah, yeah. We did build that very early on because we saw a lot of us come from this space before, so we kind of knew where people were struggling with the systems. And one of the areas is the consumability of this data. So this data is really valuable. But the thing is, it's used by different people in different groups in the organization. So it could be data that needs to be used by the SOC. It could be data that needs to be used by audit. It could be data that needs to be used by the DBAs and the application owners. And each one of those constituents or people, they use different tooling in order to get at data. So the SOC will, at least in our install base,

will almost 95% of the time be sitting in Splunk. And they're not going to exit Splunk. They're not going to go to our tool. And the audit people may going to exit Splunk. They're not going to go to our tool. And the audit people may like to use Tableau and the DBAs are just going to run SQL queries. So what we did very early on was create a layer that can get at this data either inbound or outbound through multiple ways. So you can query the data in SQL. You can use Tableau to visualize this data. We have a Splunk connector. So we can either send the data to Splunk or even better,

Splunk has a concept which they used to call a virtual index. So the user can sit within the Splunk GUI, write a search in Splunk. What it's really doing is hitting our system and we're returning the data back to Splunk. And even playbooks, you can run a playbook while sitting inside the Splunk GUI. So each user doesn't have to learn something new. They get the results and they get the answers without having to go into a new GUI. Same thing with Kibana. We have a Kibana layer. So we try to make the system, it's almost counterintuitive, but we have this, we tell the people who are building the system, if you can make the system such that nobody ever has to log into our system, then our system is perfect. Because it's doing what it's doing, and nobody even needs to know about it.

And it's been one of the driving principles in terms of making sure that certain layers are there, certain APIs are there, certain integrations are there, almost from day one. Yeah, I have to agree with that. Just not having to log in because everyone by now has a ton of systems that they're using. So adding one more just makes things harder. So if you can integrate it directly in whatever it is you're using already, then it's it's a winner okay so we're almost out of time so one last question so it's become very clear that besides working with databases you also have some sort of database of your own and you mentioned earlier the ability to not just monitor things, but act proactively, do a little bit of prediction.

And so I'm assuming, putting those two together, that you're probably using a little bit of machine learning. So if you just want to say a few words about that, what do you use it for, basically? Yeah, yeah we we do we have uh we have an entire team that builds either supervised models or unsupervised models um and we use them for slightly different things so usually the unsupervised models are things where um we're doing things like threat detection because we're trying to avoid the training period. But then there are other things where we allow ourselves to do supervised models. And I'll give you an example.

In a complex environment where you have all types of users, then you need to classify things. Sometimes you're classifying the sensitivity level of the data. Sometimes you're classifying the risk levels of certain privilege combinations. Sometimes you're classifying whether a user is trusted or not, or whether a user is an administrator or is a BI user or whatnot. In those cases, what we usually do is we have a workflow system where the initial tagging and classification happens by the app owners and then the system can train itself and and then create an automated classifier so you know the way we look at machine learning is it's not it's not magic and it's not that it's always useful and it's not magic. And it's not that it's always useful and it's not always perfect. And we look

at each case by case and we say, okay, which do we believe will function better? Because training is always something that is a little more work to our users. But on the other side, we've, we've seen that sometimes if you don't train, the results are not good enough. So, you know, we're not purists. Whenever we have a new, a new problem, we try to balance this complexity for the user and kind of the, the fidelity that you're going to get out of the algorithm once you kick it into place. Because a bad algorithm will generate a lot of noise.

And when people have a lot of noise, they just shut things down. So it's this constant balance between how much work do you put ahead of it and how much work does it save you? And I still don't know a perfect answer to those things. So we just are very careful on which one we choose. I don't think anyone does, actually. I think it's the kind of thing which is more art than science. You always kind of have to experiment.

I hope you enjoyed the podcast. If you like my work, you can follow Link Data Orchestration on Twitter, LinkedIn, and Facebook.