What happens when Cisco, Isovalent, and Splunk team up to secure your switches? This demo shows how Cisco, Isovalent, and Splunk work together to protect your switches and streamline runtime security operations. See Tetragon running on a Cisco Nexus 9000 series switch, delivering: * Real-time threat detection without impacting performance * Rich metadata surfaced into Splunk for deeper analysis * Seamless security for critical infrastructure Introduction Hey, and welcome to this demo showcasing how Cisco, Isovalent, and Splunk come together to better protect your switches. If you have any questions after this, feel free to reach out, and thank you of course to our friends and colleagues on the Splunk and Cisco Nexus teams for working on this with us. Over the next 5 to 10 minutes, we'll demonstrate how security and SecOps teams can mitigate specific CVEs on Nexus switches using the Isovalent and Splunk integration. As you can see here, we have our Splunk dashboard open to our pre-built CVE Mitigation on Nexus Switches dashboard. This is focused on Nexus 9000 series switches, but let's go ahead and get started and dive into some of the widgets. Tetragon overview On the top left, you can see which Nexus switches are affected by CVEs. For this demo, we only provisioned one switch, which is NX-OS-9K. Over here on the right, this widget displays a timeline of CVE exploit attempts that were blocked by the Isovalent Tetragon enforcement policies. For example, you can see that the CVEs were blocked at 2 p.m. on this attack timeline, and we'll dive into those CVEs down below. Here we get more specific details on those alerts triggered by Tetragon when those CVEs were blocked. As a fun note, neither of these CVEs is really exploitable in the wild. The second one was actually created just for this demo, as you can see with CVE-2030-9999. Maybe in about five years or so you'll see this CVE pop up for real. The first one is an older CVE, so most kernels are already patched against it. Tetragon setup This includes details like the process ancestry, the binary path, the user IDs, and the arguments used during execution. That metadata gives us a deep forensic understanding of what happened and where, and it provides valuable context for mitigation and analysis. Let's take a look at the first one. This is a Dirty COW exploit, CVE-2016-5195, that was blocked by Tetragon. Here in the Splunk dashboard, we can start to see the details of what happened and where. The exploit originated from the /tmp/dirtycow_exploit binary, and it executed with user ID 20002. As I mentioned, most kernel distributions have already been patched against this vulnerability, but Tetragon provides that added layer of protection. The second one is a fake privilege escalation vulnerability. Here we labeled it as CVE-2030-9999, and it targets the adminctl binary. This is obviously a fake privilege escalation vulnerability, and we created it to affect the SUID binary adminctl. For those of you unfamiliar, adminctl is a setuid-root binary. That means it always runs with root privileges regardless of the user executing it. Policy configuration This binary can be triggered to overwrite root-owned files when saving machine state. So we've installed an Isovalent Tetragon enforcement policy that mitigates this CVE by stopping and killing the process. Here we can see the action taken as SIGKILL. That means the adminctl execution is killed when it is launched by an unprivileged user. Here we can see that the alert shows the /volatile/tmp/adminctl binary from unprivileged user ID 20002 was killed. Now this is interesting, but let's get a little more information on the parent binary and the process tree itself. So let's dive deeper. What we're going to do is open up our process tree for the workload. I've already preconfigured this to go into the specific date and time range we care about, and here we're looking at a preloaded tab with that time window. We can see the process tree for the time when the two alerts were fired by Tetragon, and we see the same exact information that appeared down below in the Splunk dashboard. It's just presented in a different way, because now we get to see the full ancestry of what happened on this workload. What we care about here are two things, and we're going to talk about one for each CVE. In the process tree itself, we can see the SSH process as a parent process on the Nexus switch. What this means is that there was an SSH session initiated to the switch. The first couple of child processes, vsh, represent the default shell that is running on the Nexus switch. Then we have this bash child process, and this is where things get more interesting with the attacker activity. As the first child process under bash, we can see the Dirty COW exploit binary. This is the same binary we looked at in the previous dashboard, and it exploits CVE-2016-5195, which was blocked for obvious reasons. There are no child processes beyond this because the process was killed. Still underneath bash, where the attacker initiated activity, we can see the second attempt on the adminctl binary. Here we see the adminctl binary with arguments like save state, trying to affect /etc/passwd. The attacker ran this a few times trying to modify the saved state of this sensitive file, and what we see here is that Tetragon detects that it's a non-privileged user and blocks the event from executing and modifying the /etc/passwd file. After seeing that process ancestry tree, I want to move back to the main dashboard for a moment before we close out and show you two additional sections that focus more on alerting use cases versus the enforcement use cases we just saw. As you can see through that process ancestry tree and the Splunk dashboard, what Tetragon was doing through those policies was taking action and blocking the events from executing. However, if you have policies where you only want to generate informational alerts or warning alerts, Tetragon can also do that on Cisco Nexus switches and surface those through a Splunk dashboard. In this demo, what we did is assign a variety of policies at different levels of severity, ranging from warning to informational. Here we can see that there were 58 warning alerts generated and 349 informational severity alerts. Conclusion Thank you so much for being with us over the last few minutes, and I hope this helps demonstrate how Isovalent, Splunk, and Cisco are coming together to support security and SecOps teams, helping visualize and mitigate CVEs effectively on Nexus switches. If you have any other questions, please feel free to reach out. We love talking about this stuff, and we'd love to show you more. Thank you so much, and enjoy the rest of your day.