Unveiling the Layers of Database Security with Dejan Milicic (RavenDB)

Hello everybody and welcome back to this episode of Build Amazing Things Securely. My name is Laura Bell Main, and I'm gonna be your host today. And today we are. Oh, it's exciting. I met a new friend. You know me folks I tend to travel around a bit and I meet. Cool people all around the world. And I happened to be in San Francisco as you do, and there was a wonderful I'll be honest, there was a wonderful stand at Q Con San Francisco, and I was drawn in by the many pairs of socks they had on their stand because I'm a magpie for socks at conferences. But what it turns out was behind all of the socks was a really cool company and a really cool technology and a really nice person and. Person is joining me today. Now, I'm gonna get the name wrong, but I am intentionally gonna do this publicly because I wanna make it okay for us to ask each other if we get things wrong with things like names. So I think I'm welcoming Dejan here today, but Dejan, how do we pronounce your name? Let's get it right from the very beginning,

It's actually Dan like yogurt, but I'm a bit old fashioned and I'm not I'm not offended by any kind of pronunciation, so I'm completely

That's amazing. We all learned something already in the first two minutes of the podcast, so well done. Team Dan today is joining us from RavenDB now. Welcome. Thank you for coming on the show

Thank you for having me.

Now as I do, team, we try and get people to introduce themselves. So who are you, the human.

Okay. Since I'm a big proponent of kaizen, and that would be iterative gradual small doses changes. So I, my identity changes over time. So if I could describe myself, that would be I. Part of my education, I'm primarily mathematician. I worked as a software engineer and then at one point in time I learned there are just two parts for career development, individual contributor, and the manager and I managed to find something in between, which is developer relationships or derel, as people call it nowadays. It was like evangelists, if you remember, and advocates. Now it's dere. So currently I'm a dev re a bit of a mathematician, uh, engineer. Yeah. I'm one of those guys who goes into supermarket and waits in, into line to pay for my things. And then I started starting calculating flow to, to compute wage. Cash share has the largest flow that, that's who I'm.

I love it. I love it. Nerd to the nth degree. And also useful 'cause who better to go shopping with than the person who can tell you which checkout is actually gonna get you through the quickest. Thank you for sharing your adventure with us. Where are you joining us from today?

I am physically sitting in Serbia.

Amazing.

less familiar with third world countries, this is south of Hungary and east from Croatian in Italy.

Amazing. And another reminder that there is incredible technology going on all around the world, and I love that we're getting voices from, not just from California. Fantastic. We're derell. We're RavenDB. Let's dig into that a little bit more because the point of this podcast is we dig into amazing technologies that are being built and why they're being built and how that works. So tell me a little bit about RavenDB. What is it what is it that you are an evangelist for, if you will?

RavenDB one more database and why would anyone would, why would anyone want to have one more database?

I was gonna ask

yeah. This was kind born out of frustration. Founder of this company, and this is very interesting story. He was open source contributor for an hibernate project. You learn a lot and unsolicited advice to young people working on open source project would be one of the best ways to promote your career and to advance, and you're doing something good on top of it.

You hit first career plan.

so obviously he gained lots of knowledge and then he started working as a consultant. It. And it turns out that most companies back then, and that was something like 2008 or 2009 were using of course re relational databases. And he concluded that by the lunchtime, so you enter company when you do consulting around 9:00 AM and by the lunchtime you can discover couple of, at least couple of antipas, and this thing is repeating over and over again. So every good developer will start thinking, okay, how this can be optimized and this, in this obsession with optimizing things and to solving or actually preventing problems is what led to inception of this database around 2010. And since then, RavenDB is pragmatic solution for people who would like to actually have a really boring database. And I know our marketing will not love this, but why am I saying boring? So it's like actually boring technology is especially exciting. Why? Because. You do not want to nurture data your database. You don't want to run circles around your database. You don't want to work with the database. You want to do what your job is, and that would be solving problem for people, changing software and database or any kind of data. Persistence should be reliable. Partner should be part of your infrastructure and you should actually forget about it. Sometimes I say to people, okay, I like comparing database to Windows, Not Microsoft Windows, but the actual Windows, physical ones. So when was, can you tell me what, when was the last time you spotted anything regarding your windows on the home? It must, they must have been, they must have been dirty or broken, malfunctioning. But if they are working as they should be so clean and properly functioning, you will not notice them. Same goes with the database. The best database is one that you do not notice. It's like electricity or internet. It just works. Server sits there and that would be some kind of ideal of a boring and reliable technology.

I love this so much because, I'm a security person and a lot of security focuses in the products and things that people are building in these big, flashy things. Look at me. I'm doing security, but I'm a big fan of Boring. The boring things that just get done and you don't have to think about them because we're all too busy already. And I love that's been embraced at the data persistence layer too. So what makes it boring then? So what is the. If we were gonna talk about the cool tech here, 'cause I don't think many of us have actually built a database system before, other than we've used them. We've used 'em to store our data, but we've never actually gone, Hey, how would I build one of these from the ground up? If you have team at home, kudos. That's a lot more energy than I have on the average week. So what goes into building a good, stable, boring database?

Okay. Speaking about security in the databases I would go to I would like to go and remind you that most people who are doing testing and quality are labeling them some themselves, qa, quality assurance, but when you look at it, it's more like quality control. 'cause you have this chain of building software and then people are sitting at the end of the chain and they're discovering bug.

Yeah.

So actually it's not qa, it's qc quality Control. QA is embedding quality as integral part of every step in building software. And then same goes with the database. When you look at the people can go and look online analysis and, a record of big biggest security breaches. You can see that lots of them are related to the database. And there's one big search engine, full text search engine that is especially prominent and which is notorious for people setting it up, uh, not protecting it properly. And then this all happens on a sub network. And after a couple of years, the sub network goes Open and all of a sudden your unprotected database is actually open to the whole world. So actually what we came up with is something we are branding as secure by default, which means that securing a cluster is integral part of the setup process. And actually the moment you complete setting upper cluster, it's already protected. You could also say that security is interesting because in every other single area, you would like to be inventive. You want to be inventive with security, you want to be conservative. You don't want to come up with new things. You don't want to write your own hashing algorithm because this is hard. I always come to the fact that, there is formally verified implementation of cryptographic primitives in Firefox, if I remember correctly. And there's something very interesting. They used F STAR programming language for formally proving H-T-T-P-S and cryptographic primitives. And actually while proofing they discovered that there, there are omissions in the specification of the protocol. Security goes up to that level, so you could end up with correct implementation. But the protocol itself contains contains traps. When you look at it you also have various components. Security for me is sociotechnical concept. So you have technical aspects, and then you have like social engineering and, training people. So you know, if if you have any kind of system that you set up and then you as average person or maybe even junior or entry level developer need to go and read like 40, 50 pages manual, this will take some time. Maybe you will postpone it or you will make mistakes or you will wait for senior colleague to come and help you. This represents equally sinister moment as any kind of technical emission. 'cause security is a chain and you're hanging of that chain and any of these links if they're weak you will fold down. from the perspective of building something like database it would be closest to building an operating system. It's so close to the hardware. You cannot, you don't want to rely on garbage collection. You do your own memory allocation memory reni allocation management. You're doing really hardcore stuff. I usually say, okay, this is real programming. It's not bus line of business. It's actual real programming like young

That's fighting talk. That's fighting talk

Yeah, so it's very low level and there are lots of things that can go wrong. And you know what's also interesting with the business applications, you write them. If you have a bug, you're pretty much sure you, you created a bug with system level software, like a database. What can happen is that you actually run into. Various problems into operating system bugs into I dunno, Linux core problems. Then you go and report that. So it's really hard not to mention concurrency, which is probably the hardest problem of modern era. Unfortunately not all people are aware enough of how hard it is and it's challenging.

Thi, this is really interesting to me. I don't think I'd ever really considered the complexity of building a database, but You have me sold on the idea that this is way more work than I would want to do myself. And I love the idea that you've built your company, you and your team have built RavenDB to be secure by default. Now, this phrase is a phrase that we're hearing a lot. So those at home who are listening, just as a refresher, remember that President Biden out of the US has been talking about secure. By design and default through all of the new guidance that's coming out through the US and that's been echoed globally. So there's this big push for us to not try and make security something we turn on, but something that is just there. And in fact, to make it less secure, we have to take conscious steps to undo things, which we obviously don't want to be doing. So let's talk about this in your context, in a database. What kind of things do you have to lock down and configure to make a database secured by default?

So actually after you finish setting up Raven DB cluster, the bad thing you can do to, in order to secure it is not to touch a thing because we tend to, we turn things around, you can set up RavenDB to be unsecured database, but in order to do this needs to be conscious decision. So you need to go and descend into configuration json file, and you need to set up couple of keys and values, and then you are exposing your database to be unsecure. But even then, if you don't go with additional keys, you have, for example, if I run a RavenDB unsecured on my machine, then I will have it, of course, unsecured. But this instance will still reject any connection temps, which are not coming from the lube device. So you have, you actually have two layers of being unsecured. You, you have being unprotected and then being unprotected and willing to accept connection attempts, which are coming from outside.

Amazing. So this is, we're looking at both here the access level and what you can do in your local machine and your local environment, but also that network connectivity level of what can interact and what trust you have with other, uh, calling parties. So it's quite a layered thing.

And then also if you want people to use your security measurements or your security protocols, you need to make it affordable or approachable. So what we are using, I already told you our idea is that you should be using something that's proven. For example, we started, and I'm always joking that all good developers are a bit lazy, so they would like to use something that's already there. So RavenDB is using HCTP as a communication protocol, no proprietary communication protocol, and we are using X 5 0 9 as a means of authentication and partial authorization. Now this means that you need to create a new certificate. And this is still not widespread enough. So what we are using, we are offering you. Okay? You can bring your own certificate if you want, but if you don't want, we will on your behalf register and create one with Let's Encrypt and

Awesome.

Since this is easy, people are incentivized to just click, wait for lets encrypt to generate a certificate, and then you go and use it. So again if you make things easy to use, people will not avoid it. This is also part of the overall like security design. If I may use that part.

I love this. There's lots of lessons that our audience can pick out here and I'm just gonna reflect a few of them 'cause I think they're really great. So it, whether you're building a database or a front-end application, those Pathways we create through our applications, through the user experience, the easier they are to follow, the more likely we are to follow them. 'cause we avoid friction. As engineers we are fundamentally lazy and most of us very proud of that. That's literally why we do our job, to make our life easier. So if you make security, the pathway for security or secure behavior as easy as that, so the an easy friction-free pathway, you're gonna. Get people to follow that more times than normal. And by providing things like certificates, easily using things like let's encrypt, which, is widely available, very well documented, but well understood again, is taking away those barriers. So there are opportunities, whatever we're building here, uh, to create those pathways through, that are secure by default, that are friction free and that are using things that can be trusted so that you are not having to do them yourself. These are really great lessons for all of us to remember. I think.

I think you summed it up perfectly.

So I've got a question and you can totally tell me, no, I don't wanna answer it, but people ask me this a lot and I have feelings and opinions, but can we talk a little bit about encryption and databases? Is that all right? Can we do that?

Absolutely.

All right.

It's only that I'm not sure. I'm not a security expert, so I'm not sure if I will

but you're a database

I.

and you're a maths nerd, so I respect

I'm also engineer, which means that I'm not afraid to say that I don't know something.

Perfect. We're gonna be just fine. Alright, so let's jam on this. So one of the things that folks get told, Hey, you need to encrypt your data in your database. Now, sometimes they mean encrypt the whole thing. So it is encrypted, rest the whole database as a big blob. And sometimes they will go to the level of granularity of encrypting the records within the database. So in your experience as an engineer. In the database world, what are the headaches with this? What are the things that are misunderstood or go wrong from your side of things?

So again, when we step when we take one step back, you have encryption in transit and you have encryption at trust. Both are equally important. Again, chain and links and, a chain is solid as the weakest link. Actually challenge with encrypted databases. In RavenDB we are doing encryption. So when we are talking about low level organizational things in file system, you have one huge file and within this file, RavenDB is keeping everything so you can store adjacent documents, binary attachments, et cetera, et cetera. Now as encryption approach is relying on the operating system, encryption infrastructure and whole file is encrypted. Probably the biggest not the biggest, but something which is significant is that if you have a encrypted database, inevitably you will allocate additional memory so your database engine will allocate additional memory. And also what is interesting is that of course it'll take slightly longer for your data to be stored and then read and encryption. Good encryption is like every good security. It's providing you security, but it's not preventing you in doing what you do. So from your exp from your perspective as a developer, as someone who's building solutions. You want encryption to be completely transparent, to be completely built in. Again, you don't want to notice it. What we are also doing. Even so you have a choice when you create a new database in Raven, do you want it to be encrypted or not? But what we are thinking further on Your backups will always be encrypted because, you have a database and you will have backups and the backup is actual copy of a database. So again, your data is is as secure as the most exposed copy of it. And, backups is something that we are not Thinking enough about, I think starting with companies who are doing backups, but not attempting res, restoring them only to discover when it's critical that actually they, they're unable to restore any of the backups for whatever reasons. And then when it comes to the databases, how you will perform backups, frequency, see will it be binary or logical ones, snapshot, incremental, et cetera. How you store them, whether you keep them, how you manage them, who ha has access to them, et cetera, et cetera. So it's a non-trivial problem. And what I think is most important for people not to drive on, as I call it, an autopilot. So you should be conscious about every single step in the operational procedures and everything you're doing with any part of the system, including your database.

Yeah, thi this is good and lots for us to consider. So if you are in this space and you're looking at database encryption there's some wise words here about, remembering the performance hit, remembering the speed, but also the added benefit of that, then being encrypted in your backups. I think there's probably a lot of space just to go nerdy in that, the whole encryption space on its own. But what I'm keen to, to do for our last few minutes together is if you were to give our audience at home some advice on how to get the most outta whatever database technology they're using or how to really judge is this the right technology for me? What would you advise 'em to be looking for?

There, there's philosophy. Call polyglot programming, which says, okay, you are allowed, it's not a syn to mix several languages according to your needs. So for example, if you're building artificial intelligence service or microservice, you may end up likely using something like Python. fOr something else, you may use Java or C Sharp. And same goes with your data persistence. Now, if you remember, there's something called CQRS where you are splitting your read side and the right side. Usually modern application, you have disparity between reads and rights. So you store something once in a database and you read them thousands of times probably per each write or with some other applications like iot, you're much more writing than reading. So you should be pragmatic. When I was leading teams, uh, I didn't allow myself to run into hipaa situation. HIPAA is short for highest paid person opinion, so I was always trying to first make decisions, defend them in front of myself. And then to come up to my team and say, okay, I'm proposing this, and here are the reasons for, and here are the reasons again, and let's go and debate and let's pick up something which is a good compromise. So I think being pragmatic you may read the books, you may read how Google is doing it, but you're not Google. Of course. If you read about, I dunno, MapReduce and Hadoop and you have such amount of data, go ahead and use it. It's a proven solution, but not it's technical marriage between the developers and the technologies and the frameworks. Less things you use, the better you will be. It'll be easier to maintain. They will be less, potential for any kinds of security breaches. You can recall something like alpine distribution of Linux where they intentionally narrow down the disposable surface because you can say, okay, for every, I dunno, 10,000 lines of code or a hundred thousand lines of code, I have one bug. So literally if you make surface smaller, you will eliminate lots and lots of potential, configuration box breaches, et cetera, et cetera. So I think Making conscious decisions is very important, and being pragmatic.

Look I'm, this is a wonderful place for us to pause that all of that was There's so many gems that I'm gonna pull out and shares of for quotes for everyone. So thank you so much. I think one that's gonna stick with me and I, for those who can't see me right now, is having a little giggle in the background. I think everyone should identify their hippo. So if you haven't yet, maybe the big first call to action is what are your personal opinions that could have Impacted your decisions and name your hippo. Maybe you could, like we talked to ducks when we're solving problems, we can name our hippos when it comes to making decisions and turn all of the, those decisions we're making in our software, whether it is from the database layer or all the way up through the stack, whether it's from security or just performance. Making sure that we're making conscious decisions. All the way through. That's wonderful advice. If we were to follow up with you and we wanted to know more about you and perhaps have a play around with RavenDB, where would we go?

Ravendb.net uh, and I think lots of info information is there. I'm active on GitHub discussions of RavenDB, which is open source project, so you can find me there and yeah.

Amazing. And that's a good excuse for us to all go and remember that GitHub discussions is a thing. 'cause I think most of us forget because we're all distracted by the cesspool that is LinkedIn. So wonderful. We will see you there. Thank you so much for coming on and being a guest today.

It was a really nice conversation, so thank you.

Awesome. Okay, everyone, you know the drill. We're a tiny podcast. We're not one of those giant monsters, so every and subscribe helps. If you have a comment, please pop it in. Send us an email, you know where to find us. And if you have a guest you would like to recommend or a technology you would like to have us discussing on the show, please send in your suggestions. We love to hear from you. Okay, we will see you again really soon. Bye.