cPacket Network Observability for Incident Response

The next section is gonna be about, uh, digital forensics. Again, I'm, uh, Ron Nevo, I'm the CO of cpac, and with me is Andy, who is our senior director for technical marketing. I'll do the talking.

Andy is gonna run the slides, uh, run around the demos and digital forensics actually where we started. Right? So the, one of the main reasons that people wanted us to capture packets was like, I want to know what happened later.

And, and the way I think about digital forensics is really the, the metaphor that I have in my mind is really a, you know, the black box of, of aviation, right? So one of the interesting things about flying is even though we're flying a lot more since the seventies, actually, the number of incidents and the number of deaths didn't go up. And one, one big reason of that is because we spent inordinate amount of time to understand what happened and ensure that's not gonna happen again.

So for the most part, I think when we think about breaches in, uh, in digital work in cyber, right, we really have to be able to, uh, perform the same thing, right? And, and there are many other ways to do digital forensics, right? I think this is, you know, I'm not gonna go through all the bullet points here.

Uh, the point of why you need packet capture in addition to everything else that we need, is really, uh, in my mind, summarized in the fact that you get the complete context, right? You certainly, again, it's not that we don't need everything else, but it does give you the context in the network. Uh, many cases, uh, things, the packets carried, the actual information that was, or the actual hack that happened, and the last thing, it's very, very, almost impossible to hack the packets once they're captured, right?

Well, I, what I can modify logs, I can modify, um, many things on a system if I get control of it. Uh, it's very hard to, uh, penetrate our devices and, and, um, and hack the data and we can have another whole session about how do we protect that, the data on our devices. But believe me, it's pretty hard to go and change it.

So what do we need for a digital forensic solution that includes packets? Uh, pretty much everything we said in the beginning, it has to be pervasive. Meaning I can deploy the monitoring point, I can source packets anywhere and everywhere all the time.

'cause I don't know when the breach is gonna happen. It has to be, uh, native to the environment. So one thing you don't want to see is huge amount of transfer from the cloud back to the data center.

If you are monitoring cloud and you have 70,000 VPCs in the cloud, you want to keep it there, uh, not just start carrying it Dover on, on the, on the network. And the storage, uh, needs to be scalable. So one of the things that we do have in our storage, uh, capacities is, uh, we ship four U with 500 terabyte, uh, device, but we can expand it up to a two petabyte and the ability to go to an object store, you can even expand beyond that.

So typically people still stay within the seven days, some of them go to 30, uh, which is usually is okay, but technically we can go much, much broader than that. And the, I I love that you brought up cloud, um mm-hmm. For, for those of us that have multiple data centers mm-hmm.

And also have public cloud deployments. Mm-hmm. What does the solution like for us?

It, so the only difference will be that you don't really need the basic on the packet worker, the software that what I described as a packet capture, it's literally the same software that we run at 200 gigabits per second on-prem or native in A-W-S-G-C-P Azure. Okay. Literally the same.

But what's the, and the controls, sorry. The control center control can run either place and it controls everything in the same way. So would I need a, a control center per deployment, or can I aggregate this into one?

You can Aggregate to a single place. Okay. How do you handle, um, let's say that I deploy that, that control center on prem?

Yeah. Are you going to be streaming logs back to my data center Or There is amount of metadata that will come back and forth. It's relatively small and or you can separate the collection into two and have a CCL or CCLE that can aggregate the data.

Okay. And what are the performance and characteristics of the cloud capture? It's a great question.

So today we are maximizing, so, you know, how you choose an, an appliance and kind of traffic Mirroring. Yeah. So, so we, the cloud access is, is actually a long, another long conversation, right?

So we support today all the, uh, options with traffic mirroring AWS golo, balancing Azure just introduce, uh, VT A and uh, GCP vap as well as we're able to do in Azure and inline option. Okay. The capture itself, usually people deploy behind the load balancer, like a native load balancer, but we are able to maximize the throughput of an instance.

So I forgot what we're using today. I, I don't remember. Whatever it is.

I think that we can go up to 20 or 25 gigabits per second on a single instance, but people usually don't deploy a single instance. They will always deploy two in balance or more. Okay.

Does that make sense? Yeah. So we don't have today any bottleneck from our ability to capture the bottlenecks are, um, VPC, um, A-W-S-V-P-C flow traffic mirror, VPC traffic mirroring may, uh, prioritize the actual data over the, uh, monitor data, right?

So you might start to see gaps there, but that's, you know, we can, we can talk about how to solve that. Mm-hmm. So there, are there scenarios then in public cloud where I could end up dropping data that's in flight Beyond the traffic mirroring?

Uh, usually not, not not significant. I mean, there is always an option, but it's not, there's usually a problem. Gotcha.

But the other thing is, we actually have other people that are able to capture at high speed to other, uh, companies. But what we found is that, uh, capturing is one thing. Finding the packets after is actually harder sometimes, right?

So the ability to index and being able to download the relevant packets fast is actually a big challenge. And that's another requirements that you should introduce when you think about a packet capture. And if you remember the point I was making at the beginning, which is I can capture and analyze index, this is also when I meant I can index, meaning I can create a fast index for me to find where the packets are so I can retrieve them very quickly.

And the last point that I think we kind of try and make through the demos is that everything we do has an open API. So we are very easy for us to integrate with other solutions, whether it's homegrown or the Datadog, ServiceNow, other seems whether we send the data as we showed until now and think what Andy is gonna show now is if you have an NDR solution and the NDR solution found the data, found the breach, and now you need to enrich it, how easy or it should be easy to go get it back, right? So I'll hand it over to Andy.

What I'm gonna do is basically just give you a, a very quick demonstration of how we can integrate with a third party NDR and uh, then basically push that information out to, uh, to the likes of, you know, for example, a ServiceNow. So, you know, very much like we did before, um, you know, we might have a situation where we have a, you know, uh, a DNS beaconing or some kind of, uh, an attack going on a network, maybe it's an SQL, uh, you know, intrusion, uh, or injection attack going on within the network. Um, and we can rely on, you know, we can feed that data, we can analyze that data and we can feed that out to a third party NDR.

Once we've, uh, we've got that data maybe that NDR is going to, uh, to act on what data it's gonna create a ticket. But what we can do is we can augment that information. So once we get the, uh, you know, the information that the NDR is triggered or we've sent the information to, to that NDR, we can basically then, uh, add additional, additional packet information to the, for example, a ticket.

So what I can do is I can open up my ServiceNow dashboard, I can go into my, uh, my incident and uh, here we can see we've actually just got a ticket that's been created by our Zeke, NDR, uh, that's telling us that's what, uh, about five, 10 seconds ago, uh, telling us that we detected an SQL injection, uh, incident within the network. So we've got some kind of an intrusion in there, but we now need to go in and figure out exactly what's going on. So, you know, what can happen is using our APIs, as Ron mentioned, we can actually now add additional information to that ticket and we can push, for example, access to a PCAP file.

So just like we did before, we can actually now go in and, uh, open up that PCAP file and we can download the PCAP file and actually now view the data and actually go through and, and look at exactly what's going on. And we can see in this particular case that all the payload with our, our payload that we are, we are looking for within the filter. So just like we were doing with, you know, packet inspection, we're able to now integrate into a much wider, uh, team and framework of tools to allow us to get access and actually then integrate and get you access to that really much faster in real time environment.

Yeah. So to recap, right, if you think about digital forensics and what we mean by that, assuming you do one packets, you want to be lossless, you want to be able to work anywhere, hybrid cloud, and these are the value, right? It's precise, it's, uh, tamper proof.

And usually this is, again, the point where we're making is it's not, uh, you still have your network security tools or security tools, right? And they will find things that we are not able to find. But in order to fully understand what was going on, uh, it's very useful to have the packets and we designed it such that it should be easy, I won't say trivial, but it's easy to be able to integrate with any other tools.