cPacket Network Observability for AI-Enhanced Incident Detection
cPacket uses AI-driven network observability to detect unknown and emerging threats across hybrid cloud and enterprise environments. By applying machine learning and unsupervised anomaly detection to trillions of packets and billions of sessions, it identifies behavioral deviations, flags exfiltration and lateral movement, and delivers deep, real-time insights for proactive, scalable cybersecurity and incident response. The challenge of identifying what constitutes “normal” versus “abnormal” behavior in complex networks is central to cPacket’s AI-driven approach. Instead of relying on static, unmanageable thresholds, their platform uses machine learning to establish a baseline of normal behavior by location, application, and time of day/week, considering all collected metrics (e.g., duration, data volume, latency, connection failures). This allows cPacket to identify subtle anomalies, such as unusually long session durations for specific services or traffic between groups that shouldn’t be communicating, which are indicative of unknown threats like slow-drift exfiltration or lateral movement.
cPacket’s AI capabilities are showcased through examples like detecting exfiltration and lateral movement. For exfiltration, the system can identify both burst and slow-drift data transfers by monitoring session lengths and data volumes, flagging attempts to steal sensitive information. For lateral movement, it detects traffic between unusual or unauthorized network segments. These advanced detections are typically performed on data collected by the packet capture devices (C-Store), where billions of sessions are analyzed. The metrics from these sessions are fed into an S3 bucket, allowing cPacket’s AI model to continuously establish baselines and detect deviations, which are then aggregated into “insights.” These insights provide concise descriptions of anomalous behavior, including when, where, and potentially why they occurred, helping security teams quickly understand and triage potential threats.
The cPacket platform provides a live, real-time view of network activity, with the AI engine continuously generating “insight cards” that group related incidents, such as scanning activity. These cards provide detailed information, including source IP addresses, countries of origin, and communication attempts, which can be further investigated by drilling down to the packet level. While cPacket does not decrypt encrypted traffic, it can still detect numerous indicators of compromise that occur in the clear. Their system is designed for network observability, and its security benefits, such as detecting unusual scanning patterns or unexpected external connections, emerged as a valuable, albeit initially unintended, outcome. This comprehensive approach, including the ability to pull full packet captures for deep forensic analysis, significantly enhances proactive cybersecurity and incident response capabilities.
Presented by Ron Nevo, CTO, and Andy Barnes, Senior Director, Technical Marketing. Recorded live at Security Field Day 13 in Santa Clara, CA on May 30, 2025. Watch the entire presentation at hhttps://techfieldday.com/appearance/cpacket-presents-at-security-field-day-13/ or visit https://techfieldday.com/event/xfd13/ or https://cPacket.com for more information.
Transcript
So, so again, my name is Bravo. I'm, uh, the CTEO of C Packett. Uh, with me is Andy, who is, uh, senior Director of technical marketing.
I'll do the talking and he'll do the demonstrations. Uh, so really the, what we wanted to talk with you about now is, okay, the objections that I always have and, and it started also, uh, I, I remember the first time I started, uh, you know, I had dashboards and we were able to see retransmissions, and I went to the customer and I had, uh, 70,000 retransmissions and it was red. So he looked at me and said, well, why is it red?
I was like, well, 70,000, that's a big number. Said what? Nobody called me.
So it be that bad, right? So, so this answer of what is normal, what is abnormal, and what is in our network observability case, will they get a phone call in the security world? Is it, uh, mal, uh, something malicious or not, is something we've been struggling with for the last, uh, or trying to solve for the last, uh, four or five or six years.
So the whole idea there is really what are you gonna do when, uh, you don't have the thresholds? And even if you had the thresholds, so let's say, you know, the application, so you can, could in theory say FTP is okay, not FTP is not okay, and start giving us many, many thresholds. It's very quickly becomes unmanageable.
So what you want to do, and this is where, you know, you can call it ai, you can call it machine learning. Uh, we used to call it machine learning. Now we call it ai.
Uh, is allow us to establish what a normal behavior is. And when we say a normal behavior, we mean, um, Uh, we mean, uh, by location, by application, by time of day, day of week. So you have temporal, you have physical, you have logical, and all the metrics that we co connect.
So today on the CCP session, for example, we have like 50 different metrics. We have duration, we have amount of data, uh, we have, uh, other things like latency and then connection failures and whatnot. So what is a normal for a given location for a given application at a given time of day or day of week sometimes is event.
I think, uh, when we talk with, uh, here on the network field day, we had some guy from the MLB and he was like, well, a game time looks very different than non-game time, right? So you have to take all these into account. So it's one thing, right?
So you know, what is abnormal, right? You know, is a session duration for this service, this type of clients, two days is too much or not. And the second thing we want to do is be able to correlate and aggregate and give you one insight versus all the incidents that we see, right?
'cause what you'll see, for example, if it's a C two, you'll see typically more than one, you want to kind of bring them all together. Makes sense? So I'll, we'll give another example.
You can apply everything that I showed before. You can apply, uh, the same thing. So we'll just use the exfiltration, an example.
That's again, we have one of, uh, a big, uh, a big AI player that doesn't want that. His crown jewels will be the weights of their, uh, learning of their model. They don't want that to leave their organization, right?
So acceleration is really about, okay, I have a bad actor in whether he is uploading his personal, um, hard drive, or he is trying to steal the, uh, weights. Or I worked in Qualcomm, uh, many years back and they lost the whole, uh, source code of the phone when Qualcomm did phones. Uh, and that you don't want to happen.
And, and this one can happen in different ways, right? It can be a burst. So you need to react very quickly, or it can be a slow drift, and you want to make sure that you're able to count the session length.
Another typical, so this one, I'll just click quickly. Another example that you need, this baselining is lateral movement, right? So all of a sudden you start seeing, uh, traffic between two sessions that are, or between two groups that are not supposed to communicate or what we prefer before.
And implied the slow burn dedos, which is about opening many, many, many, many connections over time, just keeping the connections empty. Uh, so it's not something I can detect in the packet booker, but I can detect them in the capture. So these type of things typically will be identified On the packet capture.
And the way we do that is we take all the metrics from the session analytics, uh, in the packet capture, we put them in a big bucket of metrics, because now you're dealing with really, you really want to look at the billions and billions of sessions over a day. So we put them right now in an S3 bucket, and we're using the model that this kind of demonstrate in a lot of details. And, and I'm not gonna go through all the details, uh, to establish, uh, the anomalies.
So what we do is basically we look on all the metrics based on, um, as I mentioned, the physical location, the logical location, and the temporal location. Uh, define, define what the baseline is, and then start looking for anomalies. So any session that, any session or group of sessions that starts, uh, deviating for that, and we collect all that to insight.
And the idea with an insight is really discard that. Again, Andy will show in a second, which should give you in one place a concise description of what's going on and what's going on. Means, what have we seen, when did it happen, when many times means like every day at eight, right?
So when can be a period, uh, periodicity, uh, where in your network, and hopefully we can also understand why it happened. So that's also useful, I think. Yeah.
So these scanners, for example, is something that you'll always see on your network, but it's also a good indication for, um, people probing you before DDoS, right? Usually you'll see before DDoS a little more activity from new newer scanner. So that's something that, uh, an insight, you can use questions, But you're always being scanned.
Yes. So when, when your DDoS comes, you might not be able to figure out which one of them started it, right? That's True.
Usually what we see is a little higher. So there is also level of scanning. Uh, if you build the, uh, scanner, uh, you know, if you can block, if you can, you know, restrict the IP addresses that have been scanning you for the last month, you can do that.
Yes. There usually what you're seeing is a little higher activity. This is why the, the accuracy of the detection is important.
But yes, you, as soon as anytime we put that, you always see scanners. Yes. Yeah.
It, it's called, uh, the internet background noise. Yes. It's the background noise.
Totally. I think, you know, what is interesting, what we've seen before here is that many times the, uh, IP addresses that we identify, were not actually on the restricted list. So it always helps them to increase that, and you can subtract and look for new ones.
But yeah, it's not a perfect method, but it is still a little early indication to the DDoS. The DDoS is still gonna be there. Okay.
Thinking from a, an operations perspective. Sure. Is, is your AI gonna be able to help any of my ops teams, uh, with network troubleshooting?
Yeah, So AI a was designed primarily for that. So we're should watch the network field over the next one. But yes, most of the things we're looking for is around, uh, whether it was a server overloaded or network overloaded.
So, you know, again, we are coming in from the network observability, so that's the core thing we do. It so happens. Then we started connecting them to real networks.
We started seeing things like suspicious thing that might be an exfiltration, might be a, uh, might be a scanner that was, there was kind of unintended concept, you know, it's like the 3M post-it story, right? We went to build the best network observability solution as we build that, right? They were trying to build the, uh, to get the, uh, strongest adhesive that they can find.
They ended up with something that is, uh, very easy to turn and, you know, became a big seller, right? So we, we didn't go for observability. We again, for, sorry, we didn't go for security, we went for observability.
It just so happens that as we deploy, we start seeing things that are relevant to the SOC team. So, um, yeah, so what I'm gonna do here is I'm actually going to gonna show you a live system, uh, which is using our AI observability platform that we're, uh, developing now. It's actually, uh, out there being used by some of our customers.
And basically this is looking at our entire corporate network. So it's looking at everything in real time. This is not simulated data.
This is, this is really what's going on within our, our environment. So you can see we've got quite a few, uh, machines running around in the network. We get a nice little overview of where everything is and how it's all kind of interacting together.
But more importantly, the AI engine machine learning that's running in the background is constantly analyzing all of that data, and it's actually then, uh, generating what we call insights. So these are the cards that get generated as part of the output from the, uh, from the engine. So what it's done is it's looked at, for example, each of the different interfaces and each of the different monitoring points within our environment.
And it's looking for certain things. And, and, you know, one of the things it's identified is that there are scanners going on within the network, as, as we talked about earlier. So, you know, we've, we've identified them at different monitoring points, uh, and different places throughout, throughout the network.
So in this particular case, uh, I'm gonna open up for example, the scanning on our NAT and our VPN interface. So you can see the, the engine has, instead of it giving you a list of 84 different incidents, it's kind of grouped them all together and said, this is all basically a, the the same old problem. Um, and we're gonna group all those together for you.
Um, we gives you the information on the last time it happened and the start time, and it gives you a kind of an explanation of, of kind of what's going on. Now, when I open that, that insight card, we have kind of a, an overview of exactly what's happened in the last week. Now in this case, we're looking at scanners.
So it now breaks down those incidents for us over, you know, the last hours, days, week, month, or for however long we've, we've kept that data for. And we can look for, you know, specific days or specific number of counts. So there are a couple of incidents there that are maybe a little bit out of the ordinary that we will, you know, we can perhaps go in and, and dig into.
But what we can also do is we can scroll down now or we can see who are those scanners. So here, for example, we can get an information about all the source IP addresses, the countries that they're coming from, and how many times they've tried to communicate and scan our of that particular monitoring point of that particular endpoint within our network. Now, on top of that, though, I can actually go even further down in there.
So because the, uh, the platform is tied into our ccle uh, management system, I can actually now investigate that in a lot more detail by clicking on the investigation tab. And, uh, actually now logging in, downloading and getting access to that data, I've, I've already got it loaded. So I've read up here, but effectively what it allows me to do is to now get full access to all the information about that particular host.
How many times has that remote endpoint tried to scam the network? How many times, how much bandwidth has it been using over the last 24 48 hours? I have access to all of that information directly within there.
I can get a breakdown, uh, of each time that has done, uh, made a scan. I can see which protocols they use, um, which, uh, which ports they've gone after. And on top of that, I can also go one step further.
And again, just like we can do or we did with the DDoS or with Beaconing, I can actually now go and pull the packet capture down from, uh, our packet capture device, our C store, and I can now open up Wireshark and I can look at all that deep data in, uh, in real time and actually then troll through and look at what's going on, uh, within that packet capture. Hey Andy. So again, I have this ability from a high level to drill all the way down or down to a single conversation, uh, for that scanner.
Hey Andy, it's Tom Hollingsworth. I got a little piece of feedback for you guys on that, uh, table down there. Uh, yep.
Would you consider that there are over 65,000 TCP ports and we don't have all of them registered when you put other, could you maybe have your designer people put the port number in parentheses after other so that we all know which port it is? 3 billion packets, uh, if I knew the port number off the top of my head. So for example, I know it was, um, you know, audio.
Yeah, absolutely. Yeah, that's something we're, we're actually looking at as part of a, uh, an extension that we're adding that'll give you a lot more analytics into an application level, uh, which would obviously relate to the portals as well. So yes, absolutely we can, we can take that feedback.
And The other question I would have is, uh, there is such a thing as I PV six, right? So How well does that fit in there? Do you beat me to the I PV six question?
It's Okay. Sorry. Yeah, so I, I have to ask this on behalf of Nick Bario and Chris Cummings and Ed Horley, what is your V six support?
So, uh, the answer is gonna be, it depends. Some of the features are supported in IP V six, some of them are not. Okay.
Is it just, is it packet scanning in V six or is it also packet Scanning is supported? Uh, some of the TCP analytics isn't, so it's not gonna be a, it's a, it's a long answer. We have a whole thing and we are in the process of adding it.
Uh, it's not complete. Okay. So some of the analytics is, some of the analytics isn't, right?
Yeah, it's a big item on our roadmap, but, uh, yeah, still on the road, I think the full support is on the roadmap. Yep. So the, the second option we've got here is, as Ron talked about, was, uh, you know, for example, exfiltration.
So what I can do is I can, uh, utilize the, uh, the filter to look for have there been any, uh, exfiltration, uh, attempts within the network. So I can actually break those down and I can look in there and actually I can get a list of all of the exfiltration attempts. And here's an interesting one.
So we had, looks like somebody has tried to get access to our security cameras and our alarm system, uh, within the network. So I can see when that happened and uh, how often it's happened. So I can open that incident again and again, I can get a breakdown over time of what that, uh, how many times that particular thing has happened.
And again, now I can look at this and, and actually this was something that we didn't even know was going on in our network until we actually switched this feature on within, uh, within this platform. And, uh, Ron you could give some history, but when we reverse, uh, looked up this IP address, it turned out it was our security company that was Mo was actually monitoring and managing, uh, the system and using, uh, you know, remote ports to get access to, uh, to do that management. And again, we have access to that information just as we do before.
So we can actually go in and look at all that information, which ports, et cetera. So exactly the same as we were doing, we have that level of granularity to understand exactly what's going on. Yep.
Yeah, the way that it was flagged, the reason it was flagged is because the service was defined as broader service inside our data centers. Later it's like, okay, so these doors and, you know, this is a normal behavior, then you'll filter them out. We kept them here for a demo so we can show that, uh, this is essentially learned what that normal behavior for that group is.
And then it was a deviation from that. Okay. I think we need to mow on, is there one more, Andy, or, uh, No, for this that's, uh, hand back to you.
Will, will, will you flag, uh, traffic from uh, uh, some Chinese cameras back to calling home? It? This one wasn't, but it would have.
Yeah. Yes. Uh, yeah.
So I think really, again, it's the, the two questions that I got right was, it's almost, it's impractical in most cases to set predefined thresholds. Then what do you do about it? Right?
That's the answer.