Let's face it: database security is not the most appealing topic for most people. Ron Bennatan, CTO and co-founder of jSonar, is very aware of it. That, however, has not stopped him and the jSonar team from carving out a spot for themselves and making progress over the years. It has not stopped Goldman Sachs from investing in jSonar either.
jSonar announced it has closed a $50 million investment from Goldman Sachs for the company's first institutional round of funding. As part of the transaction, David Campbell, a managing director in the merchant banking division of Goldman Sachs, will join jSonar's board.
"In the last decade, enterprise database infrastructure has grown exponentially in scale and complexity. Simultaneously, data security has evolved from a compliance requirement to a critical enterprise security component.
jSonar enables its customers to meet today's data security demands, positions them to seamlessly adopt new databases, data lakes, and cloud services, all while reducing costs and expanding their analytical capabilities. We are excited to invest in jSonar and work with the team to continue to build a world-class business," said Campbell.
ZDNet connected with Bennatan to discuss what jSonar does, why, and how this led to today's announcement.
A bunch of engineers meet Goldman Sachs
Bennatan opened the conversation by admitting that, until recently, the company was "a bunch of engineers who choose cheesy names." If you want to get a bit more technical than that, let's just say that the name was created by a combination of JSON, archive, and sonar, as in finding patterns.
Bennatan describes what jSonar does as: "We just make good database and data repository security. 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".
Again, not very technical, but we'll get to that. Bennatan and his co-founder, Ury Segal, met at the distributed systems lab in the university some 30 years ago. Bennatan described their course over the years, also including other startups, until they started jSonar in 2013. That experience may help explain the way they approached product development:
"We know that you don't build things by yourself, you build things with a bunch of customers that tell you that, 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," said Bennatan.
Bennatan also conceded that database security is pretty dull. It's not a sexy area, because databases have been there for 40 years to 50 years, unlike the latest trends like, say, Kubernetes. Plus, when things happen, they're very bad, traumatic; so bad that nobody knows about them, he went on to add. That's an interesting point, coming from someone with his experience.
Perhaps paradoxically, this brings us to today's funding announcement. What Goldman Sachs knows, posited Bennatan, is that if you don't have good security at the data repository layer, then almost nothing matters. jSonar was growing without having raised capital, and the connection with Goldman Sachs was made about a year ago, but not with a specific agenda.
jSonar was happy to be steadily doubling every year, sometimes in customers, sometimes in other measures. At some point, however, this bunch of engineers decided to super-charge its growth, expand its footprint beyond the US, and offer database security as a service. So, let's see how simple really simple is.
Database security: Whose job is it?
jSonar has a good presence in a few key sectors, such as financial services. Some sectors understand risk and are more conscious about mitigating it than others, but everyone really should do that, says jSonar. Which of course, begs the question: Isn't everyone doing that already?
Don't all databases come with security capabilities out of the box? Can't database administrators (DBAs) just push the right buttons, and presto, problem solved? Well, it's a bit more complicated than that, for a number of reasons, argues Bennatan.
Databases do indeed have very robust security layers. But the people charged with the security of the database are typically DBAs. A DBA is not someone who has security in their mindset, argues Bennatan, and we'd agree. The DBA's job is to make sure the system runs smoothly, data is not lost, queries execute fast, and so on. That's already a handful.
How well can DBAs know security? Maybe not that well. Perhaps then the security people should do it. Except then the question becomes: How well can security people know databases? The answer is, not that well, said Bennatan. Databases are complex, and they're proliferating. It's not like 20 years ago when even big companies only had a few databases:
"They'd have Oracle, SQL Server, they'd have DB2 on the mainframe, and maybe one more. Now every company has 40 databases. They've got SQL databases. They started dabbling in NoSQL, they have Hadoop, they have stuff running on the cloud. And each one of these has a separate security model. There's no way for them to manage it at that level. They need to have a consistent policy.
What does the security officer care that you're storing the data in SQL Server and I'm storing the data in MongoDB and someone else is storing the data in a combination of S3 and Athena? You don't care if you're a security officer, you need to have a single point, a single way of telling what's going on. So being able to support all of these databases in a unified way -- just think how much time that takes away from the equation."
That makes sense to us -- being able to control security policy from a single point. But there is more. In the same way that there's been investment in every other security area, for things such as user behavioral analysis and threat detection, the same thing should apply to databases, argues Bennatan:
"The database will just allow you to set a set of privileges that allows you to say User A can do this and User B can do that. But the question is not what User A is allowed or is not allowed to do. The question is, given that User A is allowed to do this thing, is User A 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, User A 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?"
Database security as a service
jSonar covers threat detection, compliance, and other work that has to do with policy. It also dabbles in areas like user rights management, or access monitoring for users. But unless we go into the database and understand exactly the privileges and the relationships between things, then we just have half the picture, Bennatan said.
This is the kind of thing jSonar wants to use the investment to be able to do. Well, that, and offering database security as a service. Currently jSonar's install base tends to be largest companies, and it's a very lucrative market. However, the company would also like to address clients beyond the Fortune 1000 and Forbes 2000.
Every company has databases, and every company needs security. But to do something that works for them is a little bit different than to do something that works for the biggest bank. The product may have the same functionality, but it has to be packaged differently, simplified, and delivered with the Software-as-a-Service model (SaaS).
If you're talking to big companies, in Bennatan's experience, they have requirements, and they have people who can implement things, and they tell you what they want. If you go to smaller companies, they don't tell you they want anymore. They're looking to you to tell them what they need to do in order to secure their data well.
jSonar had a SaaS offering, but they realized that having it and selling it are two different things. So is having an API, and using other people's APIs. In that case, however, jSonar seems to be doing equally well.
jSonar works with the APIs of the databases it connects to mostly independently. Only rarely do they need to ask for special help from the database vendor, said Bennatan. But this goes both ways. jSonar interacts with the databases it connects with in a number of ways and also has a database of its own, used to store internal and aggregate information.
Outbound jSonar APIs make sure that data is accessible not just in jSonar, but can also be integrated in whatever observability solution clients are already using. In addition, having that data enables jSonar to apply machine learning to go beyond monitoring, to be able to do things like predictive analytics.
Our prediction: this bunch of engineers may be on to something, unsexy as it may be.