Decoding Cyberattacks: Unveiling the Secrets (And Mastering the Art of Defense!) | Cloud Native Now 2023

Thank you for, to join today's session, decoding Cyber Attacks, unveiling the Secrets and mastering the Air of Defense. Um, I'm gonna go through some of the key challenges that I'm sure most people already have either faced or accepted when it comes to cloud security. So the first thing is, you know, we all have vulnerabilities.

Um, whether you're looking at cvs, the disclosed ones, or again, we talk about zero data threats that we haven't disclosed, um, they do exist, and we're all susceptible to those threats. Now, the important thing is staying ahead of threat attacks. There's different architectural assignments you're can take on.

You know, there's probably here of zero trust or least, uh, permissive policy, uh, least privilege. Um, all of these kind of, uh, phrases are gonna be thrown around, but again, you need kind of a comprehensive view in order to prevent these kind of threats, these advanced threats as they occur. And again, you get the visibility to understand that you are protected against that threat.

Um, again, the attack can come from different directions. So if we're talking about cloud native, which I think is what most people are joined today's session for, um, threats can originate in the cloud provider itself. They can originate on your e C two, like essentially your vm, whether that be a process, a container, uh, or Kubernetes abstractions.

So with that, we'll jump into what our cystic threat research team have, uh, discovered, uh, when it comes to dependency issues. Now, the first thing that's worth pointing out is, again, it's a, a crazy statistic, but it's, it's one that we should all be cautious of is that 87% of the images actually have a higher critical vulnerability. Now, that's not completely terrifying in the sense of, okay, 15% of them are in use and 2% of them are exploitable.

But there is this kind of fear that, first of all, we all have, uh, vulnerabilities in our environment. What we want to be able to do is prevent, uh, vulnerabilities getting into an in use scenario where they end up in runtime way to do that is apply shift left methodology where we scan images within our build process or pipeline to make sure, okay, these ones don't make, uh, meet, you know, if it's hype vulnerability, uh, that we found from a CV database and it's assigned to that image, we don't wanna allow that into runtime. But if it does get into runtime naturally, we want to be able to apply similar o p A policy to, like, again, there's tools like OPA gatekeeper that are great for preventing threats in runtime.

Now, 2% of these are exploitable, but we also need to know what are the percentage that have actual fixes. If 71% of them have a fix available, then we also want to take on that cautious approach as well, that we can fix these images, we can apply a patch, get the latest version, and naturally have a safe, um, journey, uh, in security. And again, we're only so safe, but we should follow our best practices.

So the first thing worth pointing out here is that like CVE IDs, um, are only the tip of the iceberg. As I mentioned earlier, uh, a huge amount of images have this kind of zero day and this call zero day because we, we really just don't know that there's a, cuz it's an undisclosed, uh, vulnerability within those images. Now, the attackers obviously don't want to disclose this and they remain a zero day and they move laterally as a result of it.

And we don't know that they're, um, even exploiting images right now. So with that in mind, you need to have kind of two approaches. Naturally, you want to continue following the best practice of scans, images, preventing them from, again, run time if they have no high vulnerabilities.

Um, but you also wanna apply strong runtime forensics to be able to say, Hey, something looks unusual from this image. And again, it might be a sign of, um, uh, compromise even if it's not related to a known vulnerability. Now, the best way to do this is by kind of following what's going on in known issues or exploited attacks that have happened in the past.

So the cystic, um, um, sorry, research team, they've on, you know, discovered things like purple urchin, a scarlet eel where these attacks, even though they're always advanced, they're always new, they apply different indicators of compromise. Um, they will always follow certain best or practices within their environment. So what we wanna do is be able to detect when unusual terminal shell occurs, or we wanna be able to detect when an unusual process is spawned.

So this kind of stuff gives us an idea that something is happening and it's unusual, but it's not necessarily malicious at first sight. Now again, all vulnerabilities, um, tend to come back again in the future. So just because you see a CV and it's an old disclosed one, don't think it's not an active campaign because they can always be recycled.

And that's something, yeah, we, we point out here. So security scanning is a continuous process. Uh, all vulnerabilities may rematerialize and that's just a sad reality that some of these attackers, these campaigns, they just come back.

Um, now many of those attack factors actually exist within supply chain and build pipeline. We mentioned that we apply the shift left methodology where possible, but it's also important to do in use scanning and we'll talk about all this in the demo environment. Now, the key takeaways I hope that everyone takes from this session is that we focus on the shift left effort, but we also, you know, don't forget the shield right is just as important when it comes to vulnerabilities.

It's not all in the build and pipeline, uh, CI I C D sessions. Uh, you also wanna see what's going on within say, Kubernetes runtime. You also wanna be able to see like for your cloud provider, um, they have certain built-in capabilities, but because it's not comprehensive, you know, again, you need to apply comprehensive, uh, controls in order to prevent these threats.

So with that, um, we'll jump it straight into the demo. I think that's the best way of approaching this problem here. So I'm going to go into the cystic secure UI as you can see here.

And you can already see that I've triggered a bunch of detections or at least a bunch of, uh, detections have been triggered in the environment. So some things like suspicious domain was contacted, there was terminal shell, um, drift detection. This is all great.

I think the first one I'd like to point out here is the suspicious domain contact. Once you understand your environment and you know what your application, for instance, normally talks to, like you create an allow list and you say, I normally talk to these ports, domains, IP addresses, then when a, let's say a container then suddenly starts communicating with an unusual domain, we have to treat that as potentially suspicious. So you see it's medium priority alert drilling into that type alert.

We see it's happened twice. So there's two events that were triggered related to that. By clicking into the actual event itself, we get deeper context.

The first thing is we see the process tree. Process tree gives us this kind of process, visual lineage that tells us this user, in this case root executed an action which was essentially bashing into some, uh, shelling into a container to perform an active an action which was curl. So we see it's curled against some GitHub user content location.

Now going further into the alert, because we, you know, enricher context from different sources, we can see the process activity, which was, I mentioned there, the bash activity that led to curl. We know what was the curl. So we see exec, C v E, the system call activity, the event type with the relevant destination that they're pointing to.

We know that it was happening see by the user. It was in WW data which we saw inside, uh, our process tree. But then we also this context with again, other metadata sources.

So if you have Kubernetes auto log, we'll tell you, um, this process is associated with a container. Now that container is associated with a Kubernetes deployment and that Kubernetes deployment created a workload that runs in a certain network namespace or on a certain cluster. Um, so you wanna have all this context if you're running in a cloud provider, you wanna get that context too.

So we can better follow the breadcrumbs to understand how the threat got into this environment, who deployed it, and naturally how we can fix the issue going forward. We even get the container context to tell us from which image registry it was taken from. And again, this all ties into what we were saying earlier, which was if we start seeing an unusual spike in events triggered that are, you know, suspicious, is that from an image that carries a known vulnerability?

So with that from a response action, we could respond by um, applying network activity to this workload. We know it's a suspicious domain connection. So if we clicked on network activity, what this does is we cr see a topology map that will tell us that container spoke to, in this case suspicious IP addresses associated with that d n s address.

Because Kubernetes network policy by default is not focused on D N s, it focused on ip, we can then generate a network policy to say my workload normally talks over UDP 53. You know, if I'm seeing some unusual TCP 4 43 connection to uh, some DNS address, then it should drop those connections because that's the idea behind network policy. So this is reactive in this case, but it also works as a proactive measure by applying least privileged policy.

Any connections we don't trust will get dropped. Now we want to know how all this applies to vulnerable images. So if we went into our insights view and clicked on Kubernetes live, which is one of the newest features introduced into Kubernetes into Cystic Secure, we see the images that are in environment, as you can see here in this column in use vulnerabilities.

It's one thing to say here are the vulnerabilities and these are the exploits associated with a container image, but are they actually running an environment? Cuz you might have tens of thousands of vulnerabilities, but in reality what's running in your cluster, assuming you had proper scanning process already in the pipeline, a build process, only certain vulnerabilities might get through to runtime. So by clicking into the image, uh, we can actually see from the top view it's telling us it's currently running, it's in my cluster.

4, so that's usually considered a a fairly clean base image that you might apply or like an operating system to your container. Now I wanna get all the additional context. So I can see there was a policy evaluation done on it and it actually already failed a bunch of violations that associated with it.

However, that image was still, let's say, allowed to run in a runtime. So by scanning images earlier on, by applying these policies we can choose whether or not we accept the risk or we prevent the image from coming through. And again, it seemed that it had an acceptable image as risk.

So you can allow it within your environment. Now if you wanna get all the different context, we obviously know that these are the packages and versions that have vulnerabilities and the same ones that are currently in use and we can even see the exploits associated with it. And the context of for these Java uh, packages, uh, are they critical medium or low severity cvs.

So this is something we should probably be concerned with cuz they're both high CVS S score. And it's also, as we can see here, an in use application within environment. Now if I was go to the overview or we go back, sorry to the previous page, which was to the uh, Kubernetes live, the overview page gives us context of not just the images that are used, we can see to which network namespace workloads, the nodes, the host they run on and the clusters they're in.

We see the workloads, the the risk score that's provided to them, but also we can tie this to the events, uh, and the severity codes of the actual in-use applications. So let's say I'm seeing a suspicious amount of drift activity and we're seeing that like all happened within a certain period of time, being able to tie that to an image that has a vulnerability is one thing because we can say, okay, I can, you know, probably correlate that activity, but you also want to tie it to a known regulatory framework like Mitre attack. As we mentioned earlier, the attacks are becoming more and more sophisticated.

So if an attacker, uh, applies some certain behaviors activities to do perform reconnaissance or initial access to get into your environment, and from there they execute some script and move laterally and then start performing data exfiltration, stealing sensitive data. You also want to be able to say in live, which is in the current environment, are we seeing an unusual amount of persistence? Then we say, okay, I think someone's sitting in our environment and they're doing stuff, um, or they're trying to evade detection by deleting logs.

So on. So we get a better picture of is, has someone just recently moved into our environment and they're moving throughout it in order to perform some action, whether that be end goal is execution or executing some malicious script or is it to perform a connection to a command and control server to actually do data exfiltration? So if you do see some unusual activity related to defensive agent, you can drill into it and then see the most relevant events associated with that most recent event.

Now, when we talked about, you know, the shield right perspective, it's not just about images that are ha carry vulnerabilities, you want someone to compare it against historical behavior. So if we were to go into our investigate, or sorry, into the events view and we look at Kubernetes events, you might think this looks kind of the same as Kubernetes live. But the big difference is with Kubernetes live, you look at what's currently happening, like we see, uh, unusual activity happening.

Uh, we see it in line with MI attack, but with the Kubernetes events view, this gives us the historical context to say every day, every week, whatever our containers perform in a certain way. And then most recently, let's say today there's been an unusual spike in high priority alerts being triggered. Again, they all seem related to drift.

So if I was to click into let's say the Drift policy, we then can look into the individual alert to understand, okay, why is there suddenly a lot of drift detection? Is it something I should be concerned with? And once I drill further into the alert, I actually realize it's not such a critical activity.

The first thing to point out is that Felix, the IO activity is associated with a, uh, a component called Calico, which is our networking interface. It's a legitimate application. Now it's possible there is drift in the case of someone hijacking the networking interface, which would be concerning.

But when we look at actually what is being performed, you may realize it's just your network interface has actually just changed its design over time. So what might be the best action in this case is maybe to edit the policy and white list it if you're getting false positive detections. However, if the workload was compromised and it was making unusual IO activity, then you want to go into insights, focus on your Kubernetes activity and then see okay, in that time period are there any other activities associated with Calico?

And the easy way to solve that is by typing into Calico and seeing what are the other activities that are coming from these workloads. And then as we see, it's not doing anything unusual. It's not connecting with suspicious d um, C2 servers.

Um, it's really just the change in regards to the right activity. And of course, you know, that was being triggered as a drift. And with that you get a deeper insight into the images of what's going on.

If they carry vulnerability at the pipeline stage, be able to scan that through until it's in runtime, but also correlate it in deep visibility within Cystic Secure to secure, uh, uh, potential applications before they come into runtime and when they're currently running. Uh, hopefully that session was helpful.