Mastering Kubernetes and Container Security with Abhishek Singh at QSC24

This is Textron tv. Hey, everyone. We're back here live at Salt Lake.

Salt Lake City. I was just talking about Q Con in Salt Lake City. My next guest is gonna be there.

We hope we'll be able to interview him there as well. But we're actually in sunny San Diego today for Qualys QSC, Americas 24. Uh, QSC, of course stands for Quais Security Center.

My next guest is Abha Singh. I hope I got that right. Abha.

Yes. Abhishek is product manager. Well, I don't you tell them what you are.

I'm the VP of Product Management for Kubernetes and Container security at COIs. Yes. And I'll be speaking today, uh, of how to manage risk for containerized workloads.

Absolutely. You know, and I, as Abha and I were talking before we got on, uh, we interviewed, uh, Kumar yesterday, who is some of the synap stuff, but he has a wider portfolio. You're really focused on, let's call it cloud native Kubernetes, uh, containerized security.

And that's a pretty important chunk of, of today's infrastructure, right? Because something like, I think greater than 70 or 75% of all new, all new applications, greenfield, are built on the Kubernetes stack, right? And a, a large chunk of brownfield, you know, uh, uh, uh, applications that have been transformed to cloud microservices are also built on Kubernetes and containers.

So it is the new compute stack, right? Um, however, A, it's a hard, it's not easy to use Kubernetes and containers. And B there's a, there's a really, there's a different security paradigm at play here, right?

You've got distributed applications, you've got this whole Kubernetes thing going on and service mesh on top of it. It's a challenge. Why don't, before we even get into what you're talking about today and, and some of the risk involved from a security vendor point of view, talk to us about the challenges of, of securing that type of stack versus let's say our traditional lamp or VMware, you know, hypervisor kind of stack.

Yeah. So incidentally, that's part of my talk. So is It, it's not, okay.

I didn't even know that, but good. Yeah. But before we go to the differences, I will try to focus on what is common.

Okay. So it's a different form factor end of the day. It's how applications are being written.

Uh, so the problem has not changed. It's a different, delivered a different form factor. So that's a similarity.

It's the same vulnerability management, risk management practice. Yes. In a different form factor.

In terms of the new challenges, uh, there was a talk at RSA and they said, CIA is dead. CIA stood for, uh, confidentiality degree availability, yes. Says CI is dead for C cloud.

Uh, and what is more relevant is Dai. And again, I'll cover it in my talk today. D-I-E-D-I-E.

Okay. So The new acronym for cloud native is DIE distributed. Immutable ephemeral.

Yes. So what does distributed mean? Like you said, uh, the big fat monolithic apps are getting broken down into microservices.

And when you do, so all the internal interactions are getting network exposed. So the volume of vulnerability increases, your taxus increases the volume of vulnerability increases. So that's a distributed part in terms of immutable, you can't patch them in place.

So just like the containers are immutable, the vulnerabilities also are immutable. So if you patch it, a new copy will get deployed with the same old vulnerability Of you gotta patch the gold copy or whatever you wanna call it, Distributed, immutable. And then ephemeral.

Ephemeral means you cannot have a snapshot based approach. It doesn't work. Any snapshot you take will instantly be incomplete and invalid.

The average, the average container has a lifespan of what? A couple of minutes or something? Seconds.

I hear second. Yeah. Seconds.

So any snapshot you take is immediately worthless, incomplete, and invalid. Yeah. You have to have a mechanism that it can summarize all the workloads without having to deal with these three challenges of distributed, immutable, and ephemeral.

Absolutely. And, and when we talk about it, there's, and by the way, it's the first time and I was at RSAI didn't hear that talk. I'm sorry, I missed it.

But, um, there's another element to this too. And that's the APIs, right? A lot of the container to container communication is not even over sort of the regular network, if you will.

It's API to API traffic. And if you're not tuned into that, you're missing Yeah, that's a very good point. I've given a specific example, right?

So someone says that my host is not on the internet, so my container must be secure. The fact is it's going through proxies and it's internet exposed. Yes, it is.

So Your host may not be, but the container is, and that's the power of APIs. It's exposed through proxies in front of it. So even though the host seems like not exposed, the container is Yeah.

And that's a very different problem for, And, and that API traffic represents something like 51%. Yeah. Of all or more of all internet traffic is API to API.

Yeah. And, and then that's exactly right. You may say, oh no, it's just strictly internal.

It's container to container, not even container to host, but it's still that one container might be in Japan, one container might be in San Francisco, and it, it, it's not just going on a backend kind of stuff. So I, I agree with you. This, this is, so let me make sure it's not CIA, it's D-I-E-D-I-E.

Alright, well, I'm gonna remember that. I'm gonna say, I'll make sure you told them. You told me about it.

I didn't create the term, but I like it so much. Uh, Yeah, no, I like it too. Yeah.

It is a new three foundational elements of how you practice security in the cloud. I like it. And I'll give you a better analogy, distributed, so don't worry about availability.

CIA availability is taken care of because it's distributed. Right. Immutable.

So the integrity is taken care of, it's immutable. Sure. So E, the C and the I ephemeral.

So you don't have to worry about secrets because they're always changing all the time, right? So, right. Even the secrets have gone ephemeral.

Yeah. But does it mean there's no security to be done? No.

No. It's a different form factor. So now we've, we've hit on this, let's now talk about the challenges of securing this new form factor.

Yeah. Right. It, it is ephemeral.

You need, you can't, you can't work it. It's almost like in quantum ish, right? You can't work in the present because the present is constantly shifting.

You, you've gotta, you gotta have policies in place and, and tell us how Qualys approaches this. So it has to be built in versus bolt on, right? So when containers come and go, they come with policies in place, uh, because by the time you react and push the policies, they're gone, right?

Mm-Hmm. So they have to be built into the container. They come with the default policies and they honor it.

So if continuous are ephemeral, does it mean you leave it all open because it, it's hard to chase The answer is no. Yeah. Because your actual attack surface is not, uh, that dynamic.

It is called dub dub. com. And behind that, the containers are going up and down.

But that attack vector is constant. The database it connects to is stable. The containers are churning.

If you can't create policies between containers and your databases, that's, you're missing the point. So you have to create policies that can withstand this ephemeral nature of containers because they're built in and because they're built in, it allows only the relevant countries to talk to databases, not the rogue ones. Right.

So when we say they're built in, yeah. Are they built into like sort of the Kubernetes fabric or mesh, if you will? Are they built into the configuration of the container itself?

Both. It primarily means shift left. Mm-Hmm.

Then you build it in before it hits production. Yeah. And then it's a matter of orchestration, whether you, which Is Kubernetes, Uh, put it inside a pod, put it in a demon set as on the node, or put it outside in a service mesh.

Those are more instrumentation, uh, or orchestration options. Options. Yeah.

But built in means you have pre discovered them before they have hit production. Yep. Pre discovered in dev, we have done some shift load business.

But again, it doesn't mean you shift left and you forget. Right. You have to shift left.

And No, You gotta sh in today's world, you gotta shift everywhere. You Have to shield, right? Right.

Which means that you have to assess whether my shift load was done well or not. And you can suggest what the shift left policy should have been. So the right is a key component.

And this is where call shines because the world said continuous, let's shift left. But you're missing the point because if you shift left, you lose touch with reality. 'cause left is Pre pre-deployment theory.

It's theory, right? Yeah. This is ground real reality.

So you have to absolutely have your eyes on here to make sure a shift left is working to strengthen the shift left. So there's synergy between left and right, and just a shift left is not gonna cut it. I agree with you.

And there's other problems with shift left, frankly, as well, right? When we shift left, for a lot of people, that means let's make it the developer's problem. The developer's not a security expert.

It, it's not that they want to develop insecure software, that's not it. But we can't expect them to be the security person. It's not just that.

Uh, I mean, you could say developers have to do their qa, you don't need a QA team anymore. That's not true. Yeah.

Developers need to do more testing, but that doesn't awe the need for a qa, right? It's like having, we have saints produced in the world, so we don't need police, right? You Yeah.

Yeah. Police function where if people are wellbe behaved, this can be streamlined, but that doesn't Awe the need for security. And here's the, to use your analogy to think that we're gonna have a world full of saints is naive.

Yes. Right? It's not gonna happen.

I'm not Sure. Purest shift left strategy. Absolutely.

And to think that developers, I've seen many studies that developers only spend between 11 and 25% of their time developing software, And we need their cooperation. But security is fundamentally a police function. And it's not going away anywhere.

Developers just want to develop code And we need their help. Yeah. I, I, I agree with you.

And, and the other, from an economic point of view, who's your most expensive asset? People? Asset, yeah.

The developer. Yes. Why would you make your most expensive person also do q and a?

Also the security, security testing. Yep. Yep.

It just doesn't, it doesn't scale Up feedback and collaboration to make this all work. I agree with you a hundred percent. Alright, let's jump into what you're talking about today.

Yes. I'll talk about, uh, so if you look at call, right? Most of our customers are VMDR customers.

They love us because of our vulnerability management. The main message is that hey, containers are a new form factor, but the fundamental problem of managing vulnerabilities of risk has not changed. The new acronym CSPM, this pm that pm but ultimately it's risk management.

It's about bringing together all vulnerabilities and then having remediation for them. So that's my fundamental message. It's the same problem.

And that's why I started with that. Next, we'll talk about challenges of how, uh, continuous are different, how the industry has approached it. And then finally we'll talk about the differentiated ways in what cos different novel in how we protect containers.

This is not a well known fact. I think there's lack of understanding of what cos value already exists and end with a demo of our new and hot and happening roadmap of features. Got it.

If you don't mind, I have a couple other questions for you. Absolutely. Go for it.

So one of the things that I see, and it's not just container con containerized application development, but it really happens in containerized is is the supply chain issue, right? In a world where we build our application, sort of Frankenstein style, you know, where we bring in some open source here and some open source there and a a, an artifact here, and we, we stitch 'em all together. 75, 80% of the code in these apps are not original code.

It's code we took down from a repo somewhere. And in the, and given the nature of multithreaded, uh, you know, microservice based architecture, we could have that component lives in this container. This os lives in that container.

And, and so we, it's like building an app with Legos, right? Yep. Containers with the, now it only takes one bad container to make the whole thing rotten.

Right? And that's, we, and it's a software supply chain issue. We've seen like someone thinks they're downloading a container and the container's, uh, you know, a CF, but they really downloaded a container that's says a CD and that container has a malware payload in it.

'cause they're not careful or they're misnamed or someone got into the container that's happened, right? SolarWinds, it, it happens like this. Does Quas do anything like that along the supply chain?

Absolutely. I was just thinking of what do there, We're on the same wavelength today. So, uh, there are actually four different things that came to mind while we are talking about it.

Right? So when we talk about risk, you can have risk attributed at a business entity level. Mm-Hmm.

And people have to define quality tags to find risk. Aggregated, organized at a business plan for continuous and Kubernetes, it's outta the box because we have such rich metadata in Kubernetes. Yes.

We can organize risk along pods along applications. So when this application gets broken down into five different microservices, we show you one view of the app itself. That's the risk around that application.

Mm-Hmm. So we are actually not showing you individual microservices. We can actually uplevel it to a app level, to a business level.

This is your true risk for this whole app aggregated together. Then there's a segmentation problem. If any app gets compromised, any part gets compromised, Kubernetes is completely open.

So we have mechanisms to be able to isolate infected pots, malicious pots, risky pods so that they're completely segmented. If you think of zero trust, right? You can segment everything, but people don't do it.

It's too much disruption. It can potentially cause disruption, but you have risky elements in your environment. You can absolutely create those.

Isolate them. Isolate Them. So call is about risk management.

So you have managed your risk, but end of the day you still have some risk that you're taking into production. For that, you need us to have a set management strategy because you have risks that can manifest. How do you find threats?

Our approach is very proactive. Before we talk about proactive, what does reactive mean? Reactive means that we are chasing threat actors.

They've done something, someone writes a signature, puts a threat, uh, signature for it. We catch them. And that's always been the story in security.

We're reactive instead of proactive. What we do is we can actually zero day capable without signatures call out threats. This is using our deep learning technology.

We acquired a company called Blue Hexagon. Mm-Hmm. And we can detect threats as they're traversing a network even before they have landed on a container using deep learning.

What we have done is taken this whole technology shifted it left. Now you can scan your containers for malicious supply chain implants. Ah, okay.

You can find these without signatures proactively in a shift left manner and flag them even before they get to run. Then the thing is, you have, so That lives in the pipeline that lives in your CICD pipeline. Absolutely.

So we have integrated this, uh, zero day capable signature free malware detection capability in your registry, scanning at runtime. Again, you have some assumed risk. There's no patch for it.

It's high risk. 95 QDS. I can't patch it.

What do I do? So your, your threat management has to be risk informed because I know this is a risky thing for me. I will monitor that closely.

Instead of monitoring everything, you're monitoring nothing. Right. So now I monitor this closely and again, proactive, because I'm not chasing threat behavior.

I'm chasing what my app does and I'm, I'm profiling what my application is doing in terms of interactions with APIs. Who does it interact with? The moment it makes a new connection to a nation state, we'll flag it.

And because you have monitoring risk informed very few things, we can actually call it out. So we have a comprehensive approach from left to right, not just ary scanning at the right side, but also threat management in a proactive way. Zero day capable, zero trust, like where we can see your behavior, not a threat behavior, anything changes.

We flag it for the risky assets that you have. So we have a very comprehensive approach to this whole problem of supply chain. I love it.

Hey man, thank you so much. Thank you. I hope we didn't get too deep, but I think our audience appreciated it.

I know other people sitting here may think we're talking, uh, some Greek language or something, but this, this is the kind of stuff that cloud native security lives on, right? This is what we gotta know. Aek.

Thank you. Good luck on your presentation. We're gonna take a break.

We're live here in San Diego. We're gonna come back. We've got a full afternoon, full of great interviews coming up, so stay tuned.

You're watching Text Drunk tv.