I'm excited two be with you here today. My name is Ben Rockwood. I'm the VP of engineering operations at Mondoo and I'm glad that you joined us to talk about cloud native posture management for all. I want to introduces you to two really exciting new open source projects that I think are going to have a profound impact on the industry. And I hope to share some of my thoughts on that with you today. Those projects are CN query and CNSPeC. We're in the area of security. And so before we get into the tools themselves, I just want to talk a little bit about security, but I want to take it in a different direction than frequently is done. A lot of times these presentations with anything regarding security start off with sort of ten minutes worth of talking about why the world is a dangerous place and all kinds of statistics. Look, you know that the world is a scary place. That's already established. I don't need to show you a bunch of slides to tell you that it's a terrible place, but I want to make you think about security in a slightly different way than maybe you have. And I want to make it a lot more, hopefully, practical for you. So let's talk some terms here. So first, security. What is security? It's a term that gets really highly charged and overweighted sometimes. Security just means that we are protecting what matters. We have the thing persons, there's something of value and we want to protect that. And that can be all manner of things. One of the most important things I would argue that you want to protect is the work that you do. You want to secure your infrastructure, you want to secure your cloud, you want to secure your facilities. But why is it you just putting locks on doors for the sake of putting locks on doors? Doing security for security sake is a tedious task. It's really fruitless, right? You end up going in circles and this is where you see security get really weird when it sort of goes off into this sort of weird place. Now we want to just think about it a lot more practically. We have things, we have assets, we have our time that we've put value into things and services that we provide to all manner of customers, and we want to protect those things that we've created from any form of harm. It doesn't matter whether it comes from a hacker or from ourselves. We want to protect the things that matter to us. Compliance is a super important part of sort of the overall security landscape. But a lot of times too, we get a little bit nervous about it. We think about people with clipboards and pointing fingers at us, but we got to step back and remember, compliance really is about doing what we say we do. Right? We have policies. We have procedures. Are we following those procedures? What's the point of all that? If we're not actually following the procedures that we've written down, then we need to change the procedures. The answer to compliance is not to be afraid that you're going to get punished or disciplined in some way. What you need to do when you approach compliance is you need to think about, what do we really need to be doing? And then let's make sure we're go doing that thing. Your auditor should really be your friend. They should be coming and letting you know where you have procedures that maybe are outdated or ridiculous or just don't apply. Two, your infrastructure. The thing to do there is not to try and find some way around those things. It's to simply fix the procedures and the policies. They're yours, after all. I mean, they're for you and they're for your organization. You should make them your own. I know that there are regulations that are mandated in certain industries, and you only have so much control over those, but a lot of those have more latitude in them than most people want to accept. So compliance is really about doing what we say that we do. And in the middle of this is posture. Posture is all about situational awareness. In our infrastructures, in our day to day, we have these infrastructures that we've built that, frankly, they're not physical. We can't go and look at them with our eyes. These are machines existing in the cloud, in the Internet. We need to have projects and monitors to allow us to see inside these things. And they're complex to some degree. It would be awesome if we were in a factory and you could just stand on a catwalk and you could just look over the entire infrastructure, right? And you could just sort of see everything humming along. It's working, what's going and what's not. But we don't have that, right. These things are sort of imaginary. They're virtual. And so we need to have some ability to observe into this environment, and that's where posture really comes in. This is one of the critical things about security is being able to have an awareness of what's in our environment. And this is a very different type of monitoring or observability than we see when we're talking about, say, performance management or other sort of traditional SRE type monitoring applications. Where we're really concerned about the performance of the system. In this case, we're actually interested in a lot more detail because we need to be able to sort of see every part of our infrastructure and what is the state of that infrastructure. And more importantly, is getting to a sense of accuracy. Now, to segue just for a second, there are a lot of tools out there. One of the reasons that posture is a really difficult thing is that when you get into the security space and you get into the posture management space, there's a ton of tools out there and a lot of them are really good. I don't want to badmouth any single tool that's out there. There are a lot of great tools. The challenge with them is that they do one thing or one particular set of things really well. So you might find a really great tool that helps you out with scanning your AWS infrastructure or scanning your terraform, or scanning your kubernetes cluster or your containers. But there's this huge array of tools you very quickly sort of amass. And then there's this question of, well, how do you make all those tools work together? Can you make them work together? Should you even bother trying to make them work together? It's really challenging, right? And we just don't have time for that. The reality is that we have jobs we need to do. Most of us don't have the ability to sit around and sort of build these incredibly complex tool chains out of a variety of different tools. So we need something that can sort of cut through the noise and can simplify. And the way that we want to do that is through something that's much more extensible. And the best way to get extensible is to make sure that we're open source because we really want to get towards assurance. This is what matters to me very deeply. And Kubernetes and the cloud native world really bring a couple of new concepts that are really important, right? The heart of Kubernetes is this idea of a reconciliation loop, right? We have these controllers that are sitting there watching all these things that are happening and it's constantly looking at our desired state and our found state, right? What do we want, what do we expect and what is the actual sort of reality? And then it's rectifying those things, right? It's going to go and put the real state into the desired state. This is something that is great in kubernetes, but we kind of need it everywhere, don't we? And this is where posture really comes in, is trying to ensure that we have visibility so that we can actually react when the infrastructure in every part of our infrastructure is not in the state which we anticipate that we expect. And so a little personal aside, so one of the things that's been nagging at me for very decades, right, and all throughout the DevOps movement and what's come about with sre and cloud native and all that, nothing's really changed with regards to the fact that while I have lots of automation tools and I have lots of ways of creating change, there's not a lot out there and there haven't been really good models for helping me have some assurance that the things that I've built are in fact in the state that I wish they were built. Now, the way that we handled this in the sort of early DevOps days, DevOps days, DevOps era was through configuration management. And we told ourselves an interesting farce, which is that we're going two define infrastructure as code and we are going to have a given state and we're going to go ahead and we're going to deploy that and it's going to change the infrastructure to meet my desired state. But the thing is, we don't do that continuously, right? We didn't have the mechanism in most cases to do that continuously. So we say, well, how do I know that my infrastructure is the way that I intended it to be? Well, I'm going to go run my infrastructure as code. Okay, so you run your infrastructure as code. Oh, it found a number of things that drift. Right. We call this configuration drift. And so let's put it back the way that it's supposed to be. Then we wait some period of time, an hour, 6 hours a day, and we run our tool again. Configuration drift, bloop. It puts it back, right. There needs to be a more continuous way of being able to audit our infrastructure to be aware of its current state and whether or not it's in the state that we desire it to be. And a lot of this really comes down to peace of mind, right. When I build a new system, I don't want to continuously add this operational burden to myself that I have to constantly remember to go and check something to make sure that it's the way I intended it to be. I want to be able to set it and sort of forget it. And that means that I need to be able to have some mechanism to go back and sort of watch what the state of that thing is to ensure that if there were some kind of drift, if it weren't in the state that it was supposed to be that I would be notified of that now. What does it have to do with security? If you think about a lot of security, most security vulnerabilities and whatnot, security posture issues come down to really two sort of things. One is running outdated software, software that's just vulnerable, right? That's problematic because the bad guys, or anybody who wants to do harm to you, they're out there just looking for somebody, running old versions of software that they can exploit. We'd all like to think that most hackers out there are these people coming up with these really innovative ways to break into systems. But the reality is, that's not what most hackers are, right? I mean, that's a security researcher, right? Most hackers are not that they're opportunistic. They're looking for things that are out there that have known vulnerabilities that they can exploit in order to get into the system, or at least get a little further into the system so that they can find other ways to exploit their way in. That's one. So certainly vulnerable software is a problem. We need to be on top of that. We need to be updating our software and having systems to help us to know when to update their software. But then the more egregious one actually is misconfiguration. You can put the most fancy door lock on your house. You can get all kinds of cameras, you can put razor wire, you cloud do all kinds of interesting and crazy things, but your biggest threat is your kids leaving the door open, right? I mean, if the door is open, it doesn't matter how many locks are on that thing. The door is open. And how many times have you had somebody maybe do a pen test of your organization, or you ran some scanners or whatnot, and you just found ports that were just open. Right. One of the most common ways that ransomware attacks begin is an open RDP port. It doesn't matter what security measures they have in place. I mean, fundamentally, they left the door open. Now, hopefully, that there are additional layers of security that will protect against that scenario. But fundamentally, you just left the door open. That's where you need to start, right there. What is the state of the machine? What should your infrastructure look like, and does it remain in that state? So assurance is sort of the thing that's really important to me and why I'm really excited about this approach, because I think it really gets to the heart of the issue beyond just security and compliance, but really gets to me as a practitioner day to day and to my teams, day to day, when we build something, can we build tests for it? Can we make sure that it's always in the state that it needs to be and not rely on something else? And so I want to introduce you to Cnquery. We have a pair of tools and the first one here I want to talk about is cnquery. These tools work together. Cnquery is a cloud native query tool. It's a graphql interface to all the things. And when I say all the things, I mean all the things. That's the extensible part of it. But there's an important word here, graphql. And I want to just spend a little bit of time just sort of digging into this as to what do I mean by graphql. Hopefully you've heard of GraphQl before. Maybe you've played with it, maybe you haven't, but it's a really neat way of approaching things. So let's just take a quick look here. So graphql in a nutshell. On the left here I have users, some curly braces and some terms. So in this case, users is an object that I'm calling and here I'm going to provide it some parameters out of that. So these are attributes that are on this user's object that I want. I want name, I want uid and I want Shell. And when I submit that query, what's going to happen is I'm going to get back the object the way I sort of defined it here, except all the data is going to be filled in. So in this case, the object users isn't just going to return one user, it's got to return a list of users. So I've got an array of users here and you can see for each of the elements in that array, I'm only returning the information that I want here name, Uid and Shell. Right. And so it's fundamentally kind of cool that as opposed to say rest, where one of the real problems was is that you put in a query and you only had these sort of very vague sort of ways of putting in requests. And so what you would get is way too much data out. So we had to come up all kinds of crazy tricks like pagination and things like that that are just really painful. And in this case we could just ask for the data that we need to get out. Okay, so let's look at another example. So here we're asking for users again, but this time we're actually passing a method or a function onto this object where so we're going to do a filter and in this case we're going to filter by name where the elements that come back are name equals Ben R. And here I've got my curly braces again. But you notice here that I'm actually saying star. So this unsurprisingly will come back with one element in the list here. Down here the tabbing is a little bit off, but these are elements on it. So I get one response back and it's for this user that matches name Ben R. And you can see I get a little more data. So this is actually returning all the data that's available. Okay, so with that little bit there, hopefully this gets you your eyes attuned to sort of what two look for here in terms of sort of objects, methods, ways that we can sort of filter. And then the way that we're specifying a query. That's the beauty of graphql. It's very simple and very powerful. Okay, so let's look at Cnquery itself. So this is Cnquery and we're going to run a query here. This is what we just looked at before, users name. And here you can see it's returned a list. I'm just looking at the name attribute for users. So I get root demon bin sys sync. Cool. So cnquery can go and look at a number of different aspects of an operating system in this case and pull back all kinds of data. We can get more complex. So in this case I'm using Cn query again. I actually can open a shell. So in this case I'm opening a shell and I'm actually sshing to a remote host. I'm providing an identity file in order to do that. And now that I'm connected to it, I can run a variety of queries against it. In this case I'm asking for ports and I'm filtering those ports by those which have the state of listen and the address is not localhost. And then I'm returning from that address port and protocol. And here you can see that data coming out. And so you can see this model is nice and generic. We can apply it to a variety of different systems. So one of the things we can do on top of say doing this locally or in this case doing SSH, is actually provide CNquery with an inventory list similar to what you would do in ansible. And then I can actually run this query or any query I want against my entire fleet. So in this case, a very simple query like this could really help you go out and find, say, ports that remain open that you don't expect to open. Better than scanning from the outside is scanning from the inside and being able to look at the host and actually see what ports are there. So there's all kinds of interesting and powerful capabilities there. We can scan clouds. So this is CNquery. Again, we're looking at the shell and we're actually scanning my GCP organization. I've xed out my id because you don't need to see it. But in this case I'm running a query here for Google Cloud. I'm looking at my project and I'm looking at cloud run and I'm looking at all the cloud run services. So that returns me back all my cloud run services. And in here I'm just asking for name and annotations and you can see some of the annotations that are coming back off those cloud run services. Now I can do this with every single object within GCP. I can do it with AWS and I can do it with Azure. So this gives me a single unified way of looking across a whole different variety of pieces of my infrastructure in one consistent way. Then that's the extensibility that I think is really key and missing from the other tools out there. So now that we've talked a little bit about CNquery, we can look at our infrastructure, we can investigate our infrastructure, we can collect data about our infrastructure. The other side of this is being able to create and report assertions. So CNSPEC is the sibling to CN query. And here we can actually create assertions using the same types of queries about any of the assets that we can actually interface with. So here's looking at users. Again, just to make this sort of simple, we're in the C CNSPeC shell has a shell, or you can run drug commands. And we'll talk about sort of where you would go with this. Obviously this is for development purposes usually, but here we can look at users and I can say that I want none of the elements to be Ben R. So where would you actually use something like this? Checking for offboarded employees is a really good thing to do, right? Don't just look for the employees you have actually run scans and maintain a list of all your offboarded users and make sure that you're constantly looking to make sure that they don't get back in there again. This is the case where you could be running a really nice automation suite or something like that. But one of your automation tools or one of your cookbooks, ansible, whatever. Somewhere in there it still has that user defined, right? And so next time somebody goes and runs ansible or runs a chef cookbook or something, all of a sudden the user pops back up, right? Were you looking for that? No, but you could have actually just created a very simple set of rules here and used it. So we see when we get this, instead of getting just the results back, what we see is that it's failed, right? Because we actually did find that user, right? Here's another example of the other side. So here I'm saying users, and I'm looking for records that contain name Ben R. And in here we get, okay, so we got one record back that contained that. And that's what I expected. So okay, this equals, equals we're making an assertion, right? And so this is where things really differ between C and query and CnSPeC. In one case we're looking at infrastructure, we're trying to get data about it. In the other case we're actually trying to make assertions about that infrastructure. Here's another one. So we can interface with GitHub. And in this case, and I broke this up a little bit so it's a little easier to visually parse. But here I'm running CNSPEC against GitHub. I'm looking@my.org so our GitHub organization is called Mondoo HQ. And the cnquery that I'm running here is looking at the GitHub organizations object itself. And I'm looking for two factor required enabled equals true. In this case I run that query and what I get back is it is true, it is true that it is true. This is something that there aren't a lot of great tools, I think, out there for scanning GitHub. Furthermore, there's an API, but writing interfaces for each of these APIs is really challenging. And this is the beauty of CNquery and CNSPEC is we've abstracted all those APIs, all those clouds, your operating system and all kinds of other things in such a way that we can interface with it in the same way no matter what it is that we're interfacing with. But while I wanted to show you what the query syntax looks like, because I'd like to be practical and I want you two see sort of what's under the hood, the reality is that's not where you need to start. We have query packs for CNquery and we have policies that are ready to use that are over in GitHub. Right now, and we have a ton of integrations. So today we have AWS, GCP, Azure, we have kubernetes and all the different layers of kubernetes as well. We have Docker, we have Docker registries, we have vMware, we have GitHub, GitLab, Google workspace, MS 365, Octa, Slack, Linux, macOS, Linux. We do Arista. They have APIs. We cloud talk to the API. We have an interface for Arista for your network, DNS, TLS, terraform, vagrant, all kinds of other things. And the important thing is this is open source, which means anybody can come and add additional resources to the host, to the system. So we're really excited. And when you think about this, think about the layering that you have here, right, is that we can scan the kubernetes, we can scan Docker agent, and then the registries that you're getting containers from, we can scan the operating systems and we can scan the clouds on top, right? So we have complete coverage in one platform. Here's a GitHub repository for CN query packs. You can download these today, run scans on them, you can use them as a basis to modify, same with CN spec. We've got policies for CN spec, a whole variety of them in GitHub ready for you to go and play with right now. And so this is what we think of as extensible security posture management, XSPM. And the key there is it's got to be open source, otherwise it can't be extended by anybody. And it's got to be cloud native. It's got to cover the entire stack, not just one particular vertical, one cloud, just kubernetes. It needs to be the entire stack that is extensible security posture management. You want to learn more, go to GitHub.com monduhq. Go get started right now. Start developing, start downloading, start using. You can learn more@mondoo.com we would love to talk to you if you want to get together and learn more. We have a complete platform built on top of it to help you with reporting and visualization. And I really appreciate your time. I hope that you can see here an exciting new era in what we can do in security and thinking about it in a whole different sort of cloud native way. Come join us on this journey. So thank you very much. Enjoy the rest of your conference.