(bouncy string music) >> TheCUBE presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the cloud native computing foundation, and its ecosystem partners. >> Welcome to Valencia, Spain in KubeCon and CloudNativeCon Europe 2022. I'm your host, Keith Townsend. And we're getting to the end of the day, but the energy level has not subsided on the show floors. Still plenty of activity, plenty of folks talking. I have, as a second time guest, this KubeCon, which is unusual, but not, I don't think, disappointing in any way, we're going to have plenty of content for you. Owen, you're the CPO, Owen Garrett, you're the CPO of... >> Of Deepfence. >> App Deepfence. >> Yeah. >> We're going to shift the conversation a little bit. Let's talk about open source availability, open source security availability for everybody. I drive a pretty nice SUV back home and it has all these cool safety features, that warns me when I'm dozing off, it lets me know when I'm steering into another lane, and I'm thinking, why isn't it just a standard thing on every vehicle? Isn't safety important? Think about that for open source security. Why isn't open source security just this thing available to every project and product? >> Keith, I love that analogy. And thanks for having me back! We had a lot of fun yesterday. >> Yeah, we did. >> Yeah. We, at Deepfence, we really believe security is something that everybody should benefit from. Because if applications aren't secure, if vulnerabilities find their way into production, then your mother, my aunt, uncle, using the internet, use an app, their identity is stolen, through no fault of their own, because the developer of that application didn't have access to the tools that he or she needed to secure the application. Security is built around public knowledge. When there are vulnerabilities, they're shared with the community. And we firmly believe that we should provide open source, accessible tools that takes that public knowledge and makes it easy for anybody to benefit from it. So at Deepfence, we've created a software platform, it's 100% open source, called ThreatMapper. And the job of this platform is to scan your applications as they're running and find, identify, are there security vulnerabilities that will find their way into production? So we'll look for these vulnerabilities, we'll use the wisdom of the community to inform that, and we'll help you find the vulnerabilities and identify which ones you've got to fix first. >> So when you say use the wisdom of the community, usually one of the hard things to crack is the definitions, what we called virus definitions in the past. >> Yes. How do we identify the latest threats? And that's usually something that's locked behind value. How do you do that >> You're right. when it comes to open source? >> You're right. And it's worrying, 'cause some organizations will take that and they'll hide that extra value and they'll only make it available to paying customers. Ethically, I think that's really wrong. That value is out there. It's just about getting it into hands of users, of developers. And what we will do is we'll take public feeds, like the CVEs from the NVD, National Vulnerability Database, we'll take feeds from operating system vendors, for language packs, and then we help organizations understand the context so they can unlock the value. The problem with security scanning is you find hundreds of thousands of false positives. Like in your SUV. As you drive down the street there are hundreds of things that you could hit. >> You're right. >> But you don't hit any of them. They're false positives, you don't need to worry about them. It's the one that walks across the road that you've got to avoid, you need to know about. We do the same with security vulnerabilities. We help you understand of these thousands of issues that might be present in your applications, which are the ones that really important? 'Cause developers, they're short of time. They can't fix everything. So we help them focus on the things that are going to give the biggest bang for their time. Not for the buck, because we're not charging them for it, but for their time. So when they invest time in improving the security of the applications, we, with our open source, accessible projects, will help guide them to invest that as best as possible. >> So I'm a small developer. I lead a smaller project, just a couple of developers. I don't have a dedicated security person. What's my experience in adopting this open source solution? Now I biting off more than I can chew and creating too much overhead? >> We try and make it as easy as possible to consume. So you're a developer, you're building applications, you're here at KubeCon, so you're probably deploying them onto Kubernetes, and you've probably used tools already to check them and make sure that there aren't vulnerabilities. But, nevertheless, you've got to let some of those vulnerable packages into production and there could be issues that were disclosed after you scanned. So with our tool, you place a little agent in your Kubernetes cluster, it's a DaemonSet, it's a one held command to push it out, and that talks back to the console that you own. So everything stays with you. Nothing comes to us, we respect your privacy. And you can use that to then scan and inventory your applications anytime you want and say, is this application still secure or are there new vulnerabilities disclosed recently that I didn't know about? And we make the user experience as easy as we can. We've had some fantastic chats on the demo booth here at KubeCon, and hey, if times were different, I'd love to have you across the booth, and we'll click and see. The user experience is as quick and as sweet and as joyable as we can make it. >> All right. We've had a nice casual chat up to this point, but we're going to flip the switch a little bit. I'm going to change personalities. >> All right. >> It's almost like, if you're an comic book fan, the Incredible Hulk. Keith, the mild-mannered guy with a button up shirt. Matter of fact, I'm going to unbutton my jacket. >> Okay. >> And we're going to get a little less formal. A little less formal, but a little bit more serious, and we're going to, in a second, start CUBE clock and you're going to give me the spiel. You're going to go from open source to commercial and you're going to try and convince me- >> Okay. >> In 60 seconds, or less, you can leave five seconds on the table and say you're done, why you should do- >> Here's the challenge. >> Why I should listen to you. >> Owen: Why you should listen to Deepfence. >> Why should you listen to app Deepfence? So I'm going to put the shot clock in my ear. Again, people never start on time. You need to use your whole 60 seconds. Start, CUBE clock. >> Keith, (dramatic horn music) you build and deploy applications, on Kubernetes or in the cloud. Your developers have ticked it off and signed off- >> Zero from zero is still zero. >> Saying they're secure, but do you know if they're still secure when they're running in production? With Deepfence ThreatMapper, it's an open source tool. >> You've got to call- >> You can scan them. >> Before you ball. You can find the issues >> Like you just thought out. >> In those applications running in your production environment and prioritize them so you know what to fix first. But, Keith, you can't always fix them straight away. >> Brands need to (indistinct). >> So deploy ThreatStryker, our enterprise platform, to then monitor those applications, see what's happening in real time. (dramatic horn music) Is someone attacking them? Are they gaining control? And if we see >> Success without, the exploits happening- success without passion- >> We will step in, >> Is nothing. >> Tell you what's going on. >> You got to have passion! >> And we can put the thumb on the attacker. We can stop them reaching the application by fire rolling just them. We can freeze the application (dramatic horn music) so it restarts, so you can go and investigate later. >> Keith: Five seconds. >> Be safe, shift left, (dramatic string music) but also, secure on the right hand side. >> That's it. I think you hit it out the park. Great job on- >> Cheers, Keith. >> Cheers. You did well under the pressure. TheCUBE, we bring the values. We're separating the signal from the noise. 60 seconds. That's a great explanation. From Valencia, Spain, I'm Keith Townsend, and you're watching theCUBE, the leader in high tech coverage. (bouncy percussive music)

>>The cube presents, Coon and cloud native con Europe, 2022, brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Valencia Spain in Coon and cloud native con Europe, 2022. I'm Keith Townsend, along with my host, Paul Gillon senior editor, enterprise architecture at Silicon angle. We are continuing the conversation here at KU con cloud native con around security app defense. Paul, were you aware it was this many security challenges and, and that were native to like cloud native >>Well there's security challenges with every new technology. And as we heard, uh, today from our, some of our earlier guests, uh, containers and Kubernetes naturally introduce new variables in the landscape and that creates the potential vulnerabilities. So there's a whole industry that's evolving around that. And what we've been looking at today, yesterday, we talked very much about managing Kubernetes today. We're talking about many of the nuances of building a, a Kubernetes based environment and security is clearly one of them. >>So welcome our guests on Garrett, head of products. >>Thank >>You and community at deep fence. You know what I'm going. I'm going to start out the question with a pretty interesting security at scale is one of your taglines. >>Absolutely. >>What does that mean? Exactly. >>So Kubernetes is all about scale securing applications and Kubernetes is a completely different game to securing your traditional monolithic legacy enterprise applications. Kubernetes grows it scales it's elastic, and the perimeter around a Kubernetes application is very, very porous. There are lots of entry points. So you can't think about securing a cloud native application. The way that you might have secured a monolith securing a monolith is like securing a castle. You build a wall around it. You put guards on the gate. You control, who comes in and out, and job is more or less done securing a cloud native application. It's like securing a city. People are roaming through the city without checks and balances. There are lots of services in the city that you've got to check and monitor. It's extremely porous. So sec, all of the security problems in Kubernetes with cloud native applications, they're amplified by scale, the size of the application, the number of nodes and the complexity of the application and the way that it's built and delivered. >>That's, uh, kind of a chilling phrase. The perimeter is porous. Uh, yeah, companies are adopting Kubernetes right now. Evidently bringing in all of these new, these new, uh, vulnerability points. Do they know what they're getting into >>Many don't, there's, there's a huge amount of work around trying to help organizations make the transition from thinking about applications as single components to thinking about them as microservices with multiple little, little components, it's a really essential step because that's what allows businesses to evolve, to digitize, to deliver services, using APIs, mobile, mobile apps. So it's a necessary technical change, but it brings with it. Lots of challenges and security is one of those biggest challenges. >>So as I'm thinking about that poorest nature, I can't help, but think, you know, if I have my, my traditional IPS does a really great job of blocking that centralized data center and access to that centralized data center. As I think about that city example that you gave me, I'm thinking, you know what? I have intruders or not even intruders. I have bad actors within my city. You >>Do you, how >>Do, how does deep defense help protect me from those bad actors that are inside or roaming the city? >>So this is the wonderful, unique technology we have within deep fence. So we install little sensors, little lightweight sensors on each host. That's running your application on Kubernetes nodes as a Damon set against Fargate instances on Docker hosts on bare metal. And those sensors install little taps into the network using E B P F and they monitor the workloads. So it's a little bit like having CCTV cameras throughout your city tracking what's happening. There are a lot of solutions which we'll look at what happens on a workload traditional XDR solutions that look for things like process changes or file system changes. And we gather those signals indicators of compromise, but those alone are too little too late. They tell you that a breach has probably already happened. What deep defense does is we also look at the network. We gather network signals. We can see someone using a, a reconnaissance tool roaming through your application, sending probe traffic to try and find weak points. >>We can see them then elevating the level of attack and trying to weaponize a particular exploit that they might have find, or vulnerability that they find. We can see everything that comes into each of the components, not just at the perimeter, but right inside your application. We see what happens in those components process file, integrity, changes. And we see what comes out, attempt exfiltrate, something that looks like a database file or et cetera password. And we put all of these little subtle signals, the indicators of attack, the network based signals and the indicators of compromise. We put those together and we build a picture of the threats against each of the workloads in your cloud, native application. There's lots and lots of background, recon traffic. We see that you generally don't need to worry about that. It's just noise. But as that elevates and you see evidence of exploits and later spread, we identify that we'll let you know, or we can step in and we can proactively block the behavior that's causing those problems. So we can stop someone from accessing a component, or if a component's compromised, we can, we can freeze it and restart it. And this is a key part of the technology within our threat striker security observability platform, >>Uh, false alerts are the bane of the security ministry's existence. What do you do to protect against those? >>So we use a range of heuristics and a degree, a small degree of machine learning to try and piece together. What's happening. It's a complicated picture. So some of your viewers will have heard of a might attack matrix. So a dictionary of techniques and tactics and, and protocols that attackers might use in order to attack an infrastructure. So we gather the signals, those TTPs, and we then build a model to try and understand how those little signals pieced together. So maybe there's, you know, there's a guy with a striped striped vest that is trying the doors in your city, you know, a low level criminal who isn't getting anywhere. We'll pick that up and that's low risk. But then if we see that person infiltrate a building, because they find an open door, then that raises the level of risk. So we monitor the growing level of risk against each workload. >>And once it hits a level of concern, then we let you know, but you can then forensically go back in time and look at all of the signals that surround that. So we don't just tell you, there was an alert and a file was compromised in your workload, do something about it. We tell you the file was compromised. And prior to that, there were these events, process failures. Those could have been caused by network events that are correlated to a vulnerability that we know. And those in, in turn could have been discovered by recon traffic. So we help you build that entire active picture up. Every application's different. You need to have the context to understand and interpret signals that a solution like threat striker gives you, and we give you that context. >>So I would push back. If I'm a platform team, say, you know what? I have a service mesh. I, I have trusted traffic going to trucked traffic going from trusted sources. I'm, I'm cutting off the problem even before it happens. Why should I use, uh, deep fix? >>So a service mesh won't cut off the problem. It'll just hide the problem because a service mesh will just encrypt the traffic between each of the components. It doesn't stop the bad traffic flowing. If a component is compromised, people can still talk to another component and the service mesh happily encrypts it and hides it. What we do. We love service meshes because we can decrypt the traffic or we can inspect the individual application components before they talk to the mesh side car. So we can pull out and see the plane, text traffic. We can identify things that other tools wouldn't have a hope of, of identifying. >>So, you know, you, you just, uh, triggered something. >>Yeah. >>A lot of companies do not like decrypting that traffic after it's been sent, they don't want anyone else, including security tools to see it. Yeah. How do you ensure, how do you serve those clients? >>So we serve those clients by having an architecture that sits entirely on premise in their infrastructure. Their sensitive data never leaves their network, their VPCs, their, their boundary. They install a threat striker console. So this is the tool that does all of the analysis and make the protection decisions. They run that themselves. They deploy the threat, striker sensors in their production environment. They talk over secure links, authenticated to the console. So everything sits within their power view, their level of their degree of control. >>So if, if they're building a, a, a cloud application though, or, or a hybrid cloud application, how do you connect? How do you deal with the cloud side? >>So whether their production environments are next to the threat striker console, whether they're running on remote clouds, our sensors will run in all of those environments and the console will manage a complex hybrid environment. It will show you traffic running in your Kubernetes cluster and AWS traffic Mon running on your VMs on Google traffic, running in your 4g instances on again, on AWS and on your on-prem instances, it gathers that data securely from each of those remote places, sends it to the console that you own and operate securely. So you have full control over what is captured. It's encrypted, it's authenticated, it's streamed back. So it never leaves your level of control. >>Talk to me about the overhead. How is this deployed and managed with MI environment? >>So there are two components, as we've learned, we have the console. All of the work is done on the console, the any necessary decryption, all the calculation that runs on a Kubernetes cluster, that, that you would deploy, that you would scale. So that's fully in your control. Then you need to install little sensors on each of your production environments to bring the data back to the console. >>Now those on pots, or are those in running inside of, uh, containers themselves. >>So they are container based. They're typically deployed as a demon set. So one instance per node in your Kubernetes cluster, they are, we have put a lot of engineering work into making those as lightweight as possible. They do very little analysis themselves. They do a little bit of pre-filtering of network traffic to reduce the bandwidth, and then they pass the packets back to the management console. So our goal is to have the minimal impact on customers, production environments, so that they can scale and operate without an impact on the performance or availability of their applications. And we have customers who are monitoring services running on literally thousands of Kubernetes nodes and streaming the data back to their management console and using that to analyze from a single point of control what's going on in their applications. >>So we hear time and again, CIOs complaining that they have too many point security products. Yes, I think average of 87 in, in, in the enterprise, according to, to one survey, aren't you just another, >>And that is the big challenge with security. There is no silver bullet product that will secure everything that you have. You have your, the what, you're the, what you're securing scales over space from your infrastructure to the containers and the workloads and the application code. It scales over time. Are you secure? Are you putting security measures in, at shift left development when you deploy or are you securing production? And it scales over the environments. There is no silver bullet that will provide best to breed security across that entire set of dimensions. There are large organizations that will present you with holistic solutions, which are a bunch of different solutions with the same logo on them, bundle together under the same umbrella. Those don't necessarily solve the problem. You need to understand the risks that your organization is faced. And then what are the best to breed solutions for each of those risks and for the life cycle of your application at deep fence, we are about securing your production environment. >>Your developers have built applications. They've secured those applications using tools like SNCC, and they've ticked and signed off saying with this list of documented vulnerabilities, my application is secure. It's now ready to go into production. But when I talk to, to application security people to ops people, and I say, are the applications in your Kubernetes environment? Are they secure? They say, look, honestly, I don't know, the developers have signed off something, but that's not what I'm running. I've had to inject things into the application. So it's different. There could have been issues that were, that were discovered after the developers signed it off. The developers made exceptions, but also 60, 80% of the code I'm running in production. Didn't come from my development team. It's infrastructure, it's third party modules. So when you look at security as a whole, you realize there are so many ax axis that you have to consider. There are so many points along these, a axis, and you need to figure out in a kind of a van diagram fashion, how are you going to address security issues at each of those points? So when it comes to production security, if you want a best breed solution for finding vulnerabilities in your production environment, threat map, open source, we'll do that. And then for monitoring attack behavior threat striker enterprise will do that. Then deep defense is a great set of solutions to look at. >>So on. Thanks for stopping by security at layers is a repetitive thing that we hear security experts talk about. Not one solution will solve every problem when it comes to security from Valencia Spain, I'm Keith Townson, along with Paul Gillon and you're watching the Q the leader in high tech coverage.