So I'm just gonna come jump straight into it. And I guess the, the, the nice thing here was that intro intro from anchor, sorry, sorry. The previous session from anchor. I think the idea here is that as we are modernizing these different applications, we you've got lots of choices, lots of options to do, you know, you can move it into containerized microservices applications. You can move this into cloud native workloads. You could leverage multiple different clouds. And this is all kind of the drivers behind modernizing these applications, giving you that, that potential portability.
Although, as, as again, as anchor clearly said, it's, it's not about having one app that's portable, but having the options of putting the right app in the right place, the right data in the right place and so on could be for latency reasons or whatever it is. But the core driver here is as you push these apps out into different different environments, potentially you're making them more complex than what they used to be when they were just, you know, single, single stacks or whatever that looks like.
So giving that visibility and the assurances of those applications, what they're doing, whether they're abiding by the rules and the governance stuff is becoming much more tricky. And that's really kind of what we, what we are looking to approach at here. As you move these, these workloads, as you put, put these apps and workloads across the different areas, you've, you've got in a traditional sense, you've got these different tools that that's focus on.
Very, very distinct areas. You might have some, some tooling that really focuses on your application security or your cloud native security, and you might have some tooling that focuses really on kind of the infrastructure and cloud security. And there's probably additional tools on top of this as well to, to cover the different components you've got in here. Our approach to this existing is that these different silos don't necessarily work.
And the main reason for this really is, is as we, as we approach it and get into cloud native.
And, and we, we, we mature our DevOps operations. We're we're, we are building these cross-functional teams that have cross-functional responsibilities. So rather than having those teams, you know, there's singular teams who are looking at all these different areas. What we wanna do is encourage them to have, rather than a tool for different, for different uses, give them a single dashboard that allows them to look at these different, the, the, the different applications, the different workloads they're doing, depending on the context that they've got. So it could be okay.
We want to use the, the, the context of Kubernetes to look at our applications, or we wanna use the context of cloud, you know, again, to, to what the, the guys that Hans are doing. You could look at it and think, okay, I've got this one application.
I don't care what cloud it exists on. I care about the application, how it's performing from the infrastructure side of things you could turn around and say, well, I'm an aide wheres expert. I care about how that particular Amazon cloud is operating. I don't care about the applications on top of it necessarily.
I really wanna look at it that way, but when these teams need to collaborate, when you've got the infrastructure team and the application teams or other teams working together, they need to be able to look in the middle and say, okay, how do we agree on what data is correct? And that's why these silos, we don't think these silos work effectively. I'm sure we've all seen stats. I won't use that too long. You'll get a copy of the slides. There are lots of, lots of breaches happening all the time.
It seems that a week a week, doesn't go by without some sort of breach of our data being stored somewhere and then being accidentally released, or, or, or either accidentally released, or in fact being exploited.
Now, one thing that Gartner makes clear on is actually a large number of the successful attacks would be customer misconfigurations or of just simple. Misconfigurations really simple stuff like publishing something into an S3 bucket, or sticking something on a, you know, an open, an open database way.
These are challenges that, that are difficult to solve or difficult to in, in hindsight, you look at these things and think, well, they're easy to solve, but they, they continually happen. So we need to look at why do they continually happen? And often again, to what something that ANCO was saying, it's, it's often around that, that processes and stuff. We wanna look at the actual, the actual structure of how people are putting these things in and how they're, how they're designing these things to make the, those improvements, rather than just continually lecturing people.
Or you've gotta do this.
You've gotta do that because we're humans, we are infallible. We will make mistakes. I'm always making mistakes. I'm very good at it. And then something from our own reports, we, we, we interview our, our, all of our customers every year.
And we, we kind of get insights from what they're doing and what they're doing in their infrastructure. And we do see a, a large number of known vulnerabilities. So when people are, are, are doing vulnerabilities checks, doing baseline checks, analyzing what their applications are. We see there's a very, very high number of vulnerabilities that people just, I'm not sure if they accept them, but they're aware of them and they're not solving them.
Now, it, it, it's a complicated thing. I won't get into a big discussion around this, but it's still, it's it's being made aware of things is, is half the challenge. Then having an action plan to fix them is the next challenge on the misconfiguration piece, nearly 60% of, of containers out there and being run as root.
If you're not sure what that means, it's running them as the highest level of privileges. If you think back, you know, I'm an old VMware guy I've done, I've been doing cloud for years before that I was into VMware and traditional storage and things like that.
I, I can't remember a time where I would give the keys to the data center to anyone in the line of business. If you think back, what we used to do is to say to people, you can, we'll run your applications, but we need to go through an onboarding. We need to validate them. We need to check them. And now we're saying, here's our, here's your cloud native environment. Here's your, here's your cloud environments run, what run, what you want.
And, and we call that DevOps. So the idea of, of people running as rude, running as the highest level of privileges with any application that hasn't necessarily been validated and probably doesn't need that permission is a scary prospect.
And the last thing here is, is why some of the traditional tools don't work is that we saw that, that the large percentage there over 50% of containers are running for less than five minutes. So these workloads, these applications come and go really, really quickly and lo most of the time, that's by design. That's not cuz they're failing.
That's not cuz people are pushing all the time. It's, they're designed to scale up and scale down and have very, very short lives. That means it's very difficult to get a snapshot of what's going on using your traditional tools that might do a daily scan of the environment gives he's gonna leave you kind of a little bit blind to what's really going on. So what are we doing at cystic? Let's have a look. First of all, a little bit about our background, our, our founder, very, very smart chap called Laura.
Desani you, you may not know the name, but Laura is a fantastic guy to meet.
If you have a good chance to meet him, he was one of the, the people behind wire shark, which I'm sure many of the techies listening have have used wire shark in the past wire shark is an open source tool, very, very powerful for doing network inspection and basically took that concept and thought, okay, network inspection, let's move it to applications.
So what we're doing is, is tapping into the, the, the system kernel of, of the, the underlying OS, the, the, the workloads you're running and using that to gain a large chunk of our insight allows us to auto detect the applications auto detect the, the, the connectivity auto detect, what they're doing means we can auto baseline them a whole bunch of other activities there, but it's really simple instrumentation.
We're not, we're not adding things into your applications. We're not modifying the applications. Everything stays as is. We're going underneath that.
And that's really important as a security tool to be as low level as possible. We continue our open source journey where, where Laura came from from wire shop, we continue doing that open source is really important to us, and we really believe this is important for kind of the, the future of security. We need it to be open because you know, proprietary tools in the past have been fantastic. And they've got us the, where we are now, but the, the, the beauty of open source is that anyone can look into it and inspect it.
And, and it's also fully out in the open, so anyone can add to it can validate it. So a lot of our stuff has been battle hardened in tens and thousands of, of deployments because of the open source community, nor I go through all the details on this slide, cuz I'm probably running a little bit like little bit slower than I wanted to be, but we wanna plug into your existing workflows.
You want something like this to be as seen as possible.
And then of course, we've got strong momentum, lot to customers already leveraging CIG, already getting the benefits out of the platform, trusted by some of the largest enterprises around the world as well. On that, I kind of touched on one of our larger customers, kind of a leading digital payments company over in the us.
They, they wanted to, to, to have a threat detection platform that can span multiple clouds. You know, we, we've already heard today about, about running multi-cloud infrastructure, running this, this, the ability to do that, but they wanted a centralized view regardless of where applications are working on. They wanted this to, to really feed into their, their, their incident response team, the C team so that they could, when they have an incident, they've got this automatic automatic method of, of gaining as much information as possible.
This is where company out box out the box rules come from to, to have a method of then feeding that into a detection and response engine. So when they see these incidents, they're gonna detect them. They're gonna have a way of responding to them, whether it's it's proactively blocking stuff, whether it's just having an alert system, whether it's notifying the right people and then having instant response.
So I wanna be able to go back in and have a look at what went wrong, potentially if it was wrong, something that went wrong or if it's misconfiguration and solve that it's, it's bad enough having a security incident, having the same security incident twice is something you don't wanna be encountered with. So learn from your, your security incident once patch it, fix it, put that back into the whole, think of the, the continuous improvement cycle of this.
So what are we doing?
You know, at a, at a high level, we've got the, the kind of two core sides of, of cystic cystic, secure handling, all things security is the name would suggest. And then cystic monitor, which is looking at the health of applications. This is useful not just for a, kind of a traditional DevOps and application team. So can I see what my latency years, what my error rates are? It's also really, really useful for things like indicators of compromise and stuff. So I can see where my error rates are going up. I can see if my application is auto autoscaling unexpectedly.
These can be great indicators or useful indicators of potential nefarious activities. And then clearly you've got the security side of things where I'm actually checking for foreign abilities for runtime anomalies, for things like instant response, which you touched on before.
It needs to be kind of some of our core tenants is it needs to be as familiar as possible. So we leverage a lot of the, a lot of the metadata and tooling you've already got.
We'll use the, the data you've already built in Amazon and Google and Microsoft and whatever else will use that, that groupings and the metadata in there to map against this. So it becomes really easy to say, okay, this particular cloud or this particular stack that could be across any cloud. I want these policies, these rules, these processes tied around. We wanna bring this all together.
I'd like, I like to, I touched on before kind of this single singular view of as much activity that's going on as possible. So combining the, the, the clouds. So what are you actually doing in Amazon, Google, Microsoft, Azure, et cetera, you know, how have you configured that?
Are people making changes, common things? There are things like, okay, I've got an existing S3 bucket in Amazon. It is secured, but someone comes along and changes that security. Or you've got a, you know, a, a, a user, a user access normally very, very tightly controlled.
Someone comes along and they add a new new user with root privileges. And then suddenly you start seeing activity via an API on that common, common example of someone coming in there, breaching something and then learning in a back door, or it could be absolutely just, just some people being naive to the, to the new way of doing things in the cloud, which then opens up an opportunity for education, which we we know is always needed in security. Over on the flip side to that over the right hand side, you've got the kind of the workload protection.
So now going back to the idea of the DevOps that I talked about earlier, we're inviting people to load their applications into our cloud, making them, making them responsible for the security is, is a challenge because they've already got enough on their plate. So actually making that in a giving them the, the, the security controls in a way that's makes it easy to use. So we can say to them, okay, here, here are the things you're doing bad. Here are the things that are against security, best practices. And here are the things that we've auto protected for you.
We've, we've noticed you did these things that are against our best practices. So here we've got in and fixed.
These, this is important for, for, you know, when we really trying, you want that, that speed of delivery that you get from DevOps, but without the, the potential risk of that, that comes with that, it comes inherently with that.
So the idea of shifting left is important, but actually we need to make sure that as we shift left, so shifting left in security, pushing that security earlier on in the life cycle, we wanna make sure that's done in much more of an educational fashion. So people know actually what they're doing.
It's like, you know, the old adage of, of give man fish, he he'll eat fish for a day. If teach him to fish, he'll be fed for a lifetime. It's that kind of idea. If we go in and fix their security problems, you fixed it for today, but they'll keep having those problems. If we teach them the security problems, they teach them the security best practices. They are then gonna go in everything. They deploy their applications.
And so, and inherently be much more secure. So I think that's a core part of what we are looking at doing and providing here, there are different security at different stages in the lifecycle as well.
So you want to get security in early. So the idea of shifting left as people are building their applications and potentially early with things like code scans and stuff, which would be other products. But with insisting, we wanna do that within the container build process. We've got the middle stage here, middle to left of detecting and, and responding to runtime threats.
So it could have been built fine, but someone has managed to breach it or a new vulnerability. A zero day has been exploited. You wanna be able to detect those anomalous activity by being low level, as we are tapping into the kernel, it's really easy for us to detect those anomalies cuz it's, it's something that the application doesn't normally do. The idea of continuous compliance, I think is an important one.
We're not, we're not looking at compliance one day a year anymore.
We're now we're looking at saying, I mean, many organizations are doing regular internal audits. It could be monthly. It could even be weekly. But the idea of being able to at any point in time, just bringing up a dashboard and saying, okay, what does my current compliance look like right now? And then maybe comparing that to a week ago saying, okay, what did it look like a week ago? Have we got better or worse?
And then last year I've touched on this before, but the, the ability to accelerate instant response and forensics, the idea of really being able to drive into, okay, what happened? How did it happen and how can I prevent it from happening again? The how is really important there.
So the, the in, in DevOps, we talk about fail fast. I, I, for me, failing fast is great.
I'm I'm, as I said before, I'm fantastic at failing fast, but the fixed fast is really important.
There, you want to be able to, to have a look at the insights, understand something, learn from it and feed that into the mechanism. So you fix that quicker. Next time again, I touched this before. We want this platform to be embedded in through that life cycle.
We don't, there's no point giving, giving, giving you another tool. We've already got enough tools. We all know that I've got a dozen tools on my, on my own workstation at home. I don't need more tools to make my life easier, cuz invariably, I make it more complex. So it's really important for cystic to be embedded into your existing tools. We wanna be part of your Jenkins build pipeline. We wanna be embedded into your Amazon ECR registry without you even having to do anything we're automatically scanning and validating, proving the security best practices at runtime.
We don't, you don't wanna spend six months preparing the platform, creating groupings, working out who the owners are.
It's all already there. You've already built it into the metadata in the platform. So we are gonna use that stuff already. And then incident response, feed this into your existing SIM. We don't wanna replace that. You wanna keep using it. It's got lots of other valuable information here. We wanna augment that with even more value. So put it into what already exists. Last use case before we wrap up just conscious of time. So this is another one of our, our largest customers.
These guys had huge amounts of scale and they really challenge us when it comes to scale. They're running hundreds of thousands of hosts, and they're looking for this kind of centralized view of threat hunting.
This, this was, they use actually quite a lot of our platform. So it's not just about security, but they wanted to be able to have this, this anomalous activity detection. So when maybe this was internal teams using the tools badly or not, not coming up to speed, maybe it was just actually genuinely looking for zero days and, and threats. They wanted that ability to do this anomal detection, understand what their applications are doing, define what normal is and then anything that goes outta the bounds of normal generat alert. And on that, I think I'm pretty much the top of my time.
So kind of wanting to check to see if there's questions and, and hopefully you learn something and it was useful for you today.
