Endace Blog

Cisco Live AMER 2026: Never underestimate Cisco Live!

Original Entry by : Stephen Donnelly

By Dr Stephen Donnelly, Chief Technical Officer, Endace

Cisco Live AMER is a huge event, attracting more than 20,000 attendees to see the latest products, technology, and innovations from Cisco and its partners. In 2026, Cisco Live AMER had a dedicated SOC for the second time, out on the main show floor for everyone to see. The SOC mission is threefold:

To Protect: The primary goal of the SOC is to protect attendees, partners, and staff using the Cisco Live network from threats from outside or within the network
To Educate: The SOC educates attendees about modern Agentic SOC operation, current threats, and best practices. Over a dozen new analysts were trained in the SOC, empowered by agentic workflows.
To Innovate: The live environment is an opportunity to pressure test how Cisco Security, Splunk Security, and Endace can work together in a next-generation SOC where AI assists, evidence grounds the decision, and humans remain in control

Endace (a Cisco Solutions Plus Partner) was invited to collaborate in the SOC again this year.

We have a great relationship with the SOC team and have assisted at multiple events by providing our always-on full packet capture capability. Capturing all the network traffic at the event not only provides incontrovertible evidence to confirm incident investigations but allows SOC analysts to ‘zoom out’ from a single alert to see the full context of the event.

Visibility of the network activity before and after an incident helps determine the attack chain, and any indications of compromise, such as malware downloads, C2 beaconing, reconnaissance, or lateral movement. A complete record of traffic for the event also enables systematic threat hunting, as well as providing the ability to help train AI on real-world traffic for the Agentic SOC.

The SOC dashboards on show outside the Cisco Live USA 2026 SOC — The SOC dashboards on show outside the Cisco Live AMER 2026 SOC

Endace’s Always-On Packet Capture

To capture all the traffic at the event, Endace supplied two EndaceProbe appliances for use in Cisco’s ‘SOC-in-a-Box’. Each capture appliance features 100 Gigabit Ethernet capture interfaces and NVMe storage, capable of sustained capture at 100Gbps. Each appliance also supports multiple virtual machines which have access to the live captured data in real-time and can host analytics tools. An Endace InvestigationManager VM provides federated search across both appliances, with integrations for Cisco XDR and Splunk, and an MCP server for AI agents.

As incidents are raised in XDR or Splunk Enterprise Security, they are automatically enriched with links to the Endace InvestigationManager. These links allow AI agents and SOC Analysts to easily access full PCAP captures for the related traffic, or pivot to wider searches as needed.

Cisco's SOC-in-a-Box, used at a wide range of events globally. — Cisco’s SOC-in-a-Box, used at a wide range of events globally, is installed in the Cisco Live NOC.

How much is enough?

At 2025 Cisco Live AMER in San Diego, the EndaceProbes captured a total of 78.9TB of network data during the whole event: a record volume of traffic at the time. We expected 2026 to be even bigger, so we configured 160TB of packet storage across the two appliances.

Full packet capture started as soon as the SOC was stood up on the Friday before the show, capturing the network traffic as the show floor and booths were constructed. By the end of the second full day of Cisco Live we had already captured 100TB, and it was looking like our 160TB allocation might be insufficient. This would have meant overwriting traffic captured at the start of the event, so we reconfigured the storage to increase the total packet storage to 192TB. Metadata and search indexes are on top of this figure, allowing retrieval of any captured flow in seconds.

By the end of the show, the EndaceProbe appliances had captured more than 200 billion packets, consuming 199TB of storage, without dropping any packets from the SPAN or overwriting any data since the start of the event. How was that possible with only 192TB of storage configured?

The EndaceProbe appliances support hardware compression of packet data prior to storage. Of the 199TB of traffic collected, 37% was unencrypted, which compresses well. The overall compression ratio for the packet data was 1.25:1, so our 199TB of traffic consumed only about 159TB of storage space. Our original 160TB configuration was pretty close after all!

A dashboard at Cisco Live USA 2026 shows Endace statistics for the show's duraction. — A dashboard at Cisco Live AMER 2026 shows Endace statistics for the show’s duraction.

Why was so much traffic unencrypted, isn’t it a security risk? In some cases yes, the SOC detected 685 unique accounts exposing login credentials in the clear, mostly because of misconfigured email clients using SMTP, IMAP, and POP3 without encryption. The SOC even automated a playbook to contact affected users and warn them of their exposure, inviting them to the SOC for a demonstration and help with remediation.

A surprising amount of traffic still uses unencrypted http. This is commonly used for downloading unencrypted (but signed) software update packages such as Microsoft .cab and Android .apk files, plus EDR rule updates etc. The contents of these files are freely available and frequently cached so transport encryption is not necessary, provided package signatures are verified to confirm authenticity.

The Cisco Live SPAN was configured to capture not only the attendee WiFi network, but also a large amount of infrastructure traffic including CiscoTV, one of the largest users of the network. Some of that traffic was also unencrypted, such as syslog data from IDS appliances. This also contributed to the relatively high percentage of unencrypted traffic seen.

Packet Loss

If the EndaceProbe appliances captured all the traffic from the SPAN without drops and did not overwrite any data, did we get everything? Looking at the bandwidth arriving on the 10GE SPAN port the traffic was reaching 10Gbps early in the day, suggesting the SPAN may be saturated and dropping. Without access to the SPAN port statistics this can be difficult to quantify, but one approach is to look at the sequence numbers seen in TCP flows.

Analyzing traffic flows from Cisco Live USA 2026 in InvestigationManager — Analyzing traffic flows from Cisco Live AMER 2026 in InvestigationManager

When a TCP flow encounters packet loss in the network, a retransmission will occur to fill in the missing data. When this flow is captured by analysis tools they may or may not see the initial lost packet, but they can see the retransmission and infer the loss. Conversely, if the analysis tools see many TCP flows with missing segments but no retransmissions, this can indicate multi-path routing (not applicable at Cisco Live), or packet loss at the SPAN port.

Examining these indicators showed estimated packet loss exceeding 30% during peak times, or around 13-14Gbps of traffic. This could be easily solved in future by upgrading the SPAN port to 25G or 40G Ethernet, a definite learning opportunity.

File Reconstruction

The EndaceProbe appliances also extracted files from unencrypted connections. Over Cisco Live Americas 2026 a total of 2,392,180 files were extracted. These files were filtered by type and deduplicated, with 23,368 submitted to Splunk Attack Analyzer and 5,427 to Cisco Secure Malware Analytics for deeper inspection.

Examining the rate of file extraction over time, we noticed it did not follow the overall bandwidth curve. This is counterintuitive, as more files should be transferred and extracted as the network bandwidth increases during the day.

This anomaly may be caused by the SPAN being overloaded and dropping packets before they reached the EndaceProbes. Files cannot be successfully reconstructed and extracted when packets are lost, and a packet loss rate exceeding 10% implies that most file transfers would have at least one packet missing. With a higher bandwidth SPAN to the SOC we are confident the file extraction counts would have been significantly higher.

Conclusion

Never underestimate Cisco Live! We will be back next year with a faster SPAN and more storage to support the SOC in 2027 (and at Cisco Live APCJ in Melbourne this November), helping protect, educate, and innovate. Hope to see you there!

Acknowledgements

Our thanks go to the Cisco SOC team, led by Jessica Oppenheimer and Ivan Berlinson, for the opportunity to integrate EndaceProbes with the Cisco Live Agentic SOC architecture.

The SOC team is a collection of Cisco and Splunk experts across many domains who were a pleasure to work and innovate with, and we came away with a great appreciation for the power of the Cisco Security and Splunk tools.

The Endace and Cisco teams were able to prove out integration innovations and test them in earnest in a real-world environment in preparation for making them generally available to the market.

More from Endace, Splunk and Cisco in the SOC series

Read more from Endace about the Cisco Live USA 2026 SOC:

- Elliott Hinson: Supporting Encryption vs. Using Encryption – when the best laid plans go astray
- Barry (Baz) Shaw: Using LLMs and Endace Full Packet Capture for Incident Response

Read related Cisco Team Blogs from the Cisco Live USA 2026 SOC:
https://blogs.cisco.com/security/clamer-soc-2026

For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/

Event SOC Website
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html

Cisco Live AMER 2026: Using LLMs and Endace Full Packet Capture for Incident Response

Original Entry by : Barry "Baz" Shaw

By Barry “Baz” Shaw, Senior Engineering Manager, Technology Partner Programs, Endace

At Cisco Live AMER 2026 Endace debuted an MCP (Model Context Protocol) server for the integration of EndaceVault into the emergent agentic Security Operations Center (SOC), providing access to 200TB of full packet data and on-demand packet analysis to all agents present in the SOC.

Going into Cisco Live we had key questions about the utility of PCAP data to agents, how to manage making terabytes of data available without overflowing their context windows, and whether the models could parse, analyze and make judgements from the PCAP data comparable to that of an analyst. Results from some simple tests are extremely encouraging and indicate a bright future for agentic AI in the SOC.

Endace Always-on Packet Capture

Two of Endace’s newest EP94C8 EndaceProbes were installed in the GovWare SOC to provide full packet capture to support the conference SOC directives of Protect, Educate, and Innovate. Full packet capture provides unique insight into all activities on the network, delivering critical context and evidence for Incident Response and Threat Hunting teams.

The EndaceProbes each hosted three VMs that were running Zeek and delivering critical log data into Splunk. Custom Zeek script additions provided additional valuable details around clear text passwords in email and HTTP, and the use of insecure protocols. Zeek was also used for file-carving and automated submission of objects to Splunk Attack Analyzer and a beta of Endace’s new Vault API used in a Cisco XDR automated workflow was field tested.

PCAP and AI – a key question answered

In this scenario we wanted to test the ability of a reasonably new on-prem model to make incident judgements based on PCAP data. Using the qwen-3.6 model and Open WebUI, a DNS buffer overflow attempt flagged by Cisco Secure Firewall, and raised as an incident in Cisco XDR, was chosen as the candidate.

Cisco Live USA 2026: Possible Buffer Overflow Attempt Flagged — Cisco Live AMER 2026: Possible Buffer Overflow Attempt Flagged

Using the Endace XDR workflow integration (which automatically creates Endace Pivot-to-Vision and EndaceVault links directly in the worklog) a quick pivot from Cisco XDR to EndaceVision shows DNS traffic present:

Investigating the suspect DNS traffic in EndaceVision

After pivoting from EndaceVision into Wireshark, we can see DNS activity and some large query responses. This verification served as the analyst judgement to be compared with the LLM findings.

Examining the actual packets in Wireshark lets us validate the AI agent's analysis. — Examining the actual packets in Wireshark lets us validate the AI agent’s analysis.

In Open WebUI a new chat was opened, the Endace MCP connected as a tool, and the following prompt was issued:

There was a firewall alert called ‘PROTOCOL-DNS Microsoft SMTP excessive answer records buffer overflow attempt’ recorded for the traffic between IP addresses <redacted> and <redacted> at 2026-06-03T15:24:01.000Z and 2026-06-03T15:22:33.000Z. Can you get a packet decode from Endace and either confirm or deny the existence of DNS responses that would match this alert.

The model’s reasoning is shown in the following screenshot:

The AI agent's reasoning before starting the analysis. — The AI agent’s reasoning before starting the analysis.

The Endace MCP tools contain detailed annotations that provide context to the model. Above we can see this context helping the model choose between different time inputs and correctly identifying that the start and stop times provided in the prompt were (accidentally) transposed in the prompt.

The AI agent prepares to retrieve and analyze the packet data.

Once the AI issued the tool call to the Endace Vault API via the MCP, the extraction of the related PCAP data began. To make this data more consumable by AI, it is converted to JSON by the Endace Vault API and streamed back in manageable sized chunks. The AI can request additional chunks as required, which protects the context window from being swamped by a large PCAP download.

An example of the returned JSONified PCAP data is shown below, this is the raw data that the AI has to make its determination.

A sample of the packet data returned in json format

After consuming the JSONified PCAP data the AI began its analysis, clearly having parsed the PCAP data and displaying an understanding of the DNS protocol. From the name of the alert, it understood the specific details pertaining to the alert and was able to look for these in the DNS packets:

The AI agent shows its reasoning and the resulting analysis. — The AI agent shows its reasoning and the resulting analysis – Part 1.

The AI agent completes its analysis and outlines its conclusion. — The AI agent shows its reasoning and the resulting analysis – Part 2.

The reasoning of the model makes for interesting reading. It can comprehend the nature and specifics of the alert and use this to reason about the DNS packets. It successfully found an oversized DNS response and provided unprompted enrichment by determining the hosting provider of the DNS server.

So far, the model has performed admirably, validating the firewall alert and the analyst judgement. To take things further, we asked the model to do some extra analysis over and above the human analysis we’d done. While this chat was user driven, we expect that this is the kind of autonomous activity AI agents will perform on their own.

The AI was asked to confirm the hosting provider and look at the contents of the large DNS response to determine if it contained a malicious payload or was in fact just a verbose and unusually large response.

Can you confirm that the destination host <redacted> is in fact Microsoft hosted? Is there anything in the large DNS response that could be malicious or is it just a DNS response?

The model has told us that the source of the DNS response is a reputable domain and that the payload of the response was just a large number of regular AAAA records. In a pre-AI SOC, the analyst would need to spend time inspecting the PCAP in Wireshark (if they had access to full packet capture in the first place) to determine this was a false positive.

Conclusion

While this example was intentionally not an autonomous agentic finding, the model was able to determine that this alert was a false positive by analyzing the PCAP. The fact that relatively small open-source models can successfully extract findings from PCAP data is a major validation of their utility in the agentic SOC. We expect that frontier models will provide even richer analysis of PCAP data when available in the SOC if the token cost can be justified. A possible architecture is an on-prem first approach, escalating to a frontier model in the event on-prem cannot make a confident determination.

By using an agent to investigate events like these, and having access to full PCAP data, alerts can be triaged by the agent, requiring only a cursory review by a human analyst to definitively close cases in record time. This validates the core concept that the agentic SOC will improve overall efficiency and accuracy by optimizing incident triage and freeing up time for analysts to work on the more complex incidents that threaten enterprise operations.

Acknowledgements

Our thanks go to the Cisco SOC team, led by Jessica Oppenheimer and Ivan Berlinson, for the opportunity to integrate EndaceProbes with the Cisco Live Agentic SOC architecture.

The Endace and Cisco teams were able to prove out integration innovations and test them in earnest in a real-world environment in preparation for making them generally available to the market.

Cisco Live USA 2026: Supporting Encryption vs. Using Encryption – when the best laid plans go astray

Original Entry by : Elliott Hinson

By Elliott Hinson, Integrations Engineer, Endace

Are you actually using encryption, or does your software simply support it?

The answer may seem silly, but there lies a hidden amount of complexity behind this question that many users never have the need or opportunity to approach.

At the Cisco Live USA 2026 Security Operations Center (SOC) we found a great number of instances of users using technology that supported encryption. However, through some form of misconfiguration or a sheer lack of knowledge, they had configured their system to not use the encryption that their software did, in fact, support.

Sony DSLR FTP uploads

The first incident that I would like to discuss regards a user operating a Sony DSLR camera with automated photo upload enabled. Most DSLR cameras these days offer a Wi-Fi or Bluetooth connectivity option to offload photos for later processing.

While sifting through log data in Splunk, we discovered one user at the conference had configured automated image uploading to an FTP server in the cloud directly from their Sony DSLR camera.

Because this was configured to an FTP cloud server, and because we had the full packet data recorded via the EndaceProbe, we were able to inspect the username and password for the login credentials of this FTP server, which were being broadcasted in the clear over the network. Furthermore, thanks to Endace’s file carving ability, we were even able to reconstruct the original file uploads that the user had sent to the cloud over the Wi-Fi network, also unencrypted.

This represented one of the lower risk level incidents of supporting encryption without using encryption because the photos were intended to be used at the Cisco Live Conference, and they were not particularly private. One could imagine an incident, however, where much more private photos had been taken on a similar camera system, and those photos could be gathered by any nefarious actor with access to the Wi-Fi network.

This problem is particularly unfortunate, since a quick perusal of the Sony documentation for that particular model of camera shows that they very clearly do support encryption in the form of SFTP or FTPS. However, the user had not configured these and was unaware that they had been uploading their photos and password in the clear all week.

Recorded data upload dates and times shown in EndaceVision.

Extracted images were reassembled from the packet data using Zeek.

POP3 email, using the wrong port

This flavor of incident resulted in several users being invited into the SOC for us to inform them of the dangers of using unencrypted email. The POP3 protocol, as well as the SMTP protocol, do support encryption. However, once again we found users were connecting to their email servers with mail clients that had not been configured to enable encryption. It had merely asked them for a port number, and the user, not knowing which port number to use or why that may be important, had simply selected the default.

This was quite convenient for us, since their username for their accounts was their email address (and their email login password was also exposed). So, all we had to do was use the email address that we had seen passing, unencrypted, over the network to send them an email inviting them to the SOC to improve their security posture. For one of the users, it was as simple as changing the mail client to use the POP3 port that supported encryption.

This represented a much higher risk level of incident, since not only was the username and password for their email accounts in the clear, but we could also reconstruct emails for several users with this problem. That allowed us to uncover an additional problem. Some of these users were using a network monitoring solution that also did have encryption enabled and was sending email reports containing sensitive information about the state of their laptop computers in the clear. The issue was fixed by digging through a nested menu to check a box that enabled encryption.

What was interesting was that this network monitoring software was attempting to send unencrypted email reports to service providers that were actually returning error codes indicating that they did not support receiving unencrypted email. However, while the service providers were attempting to stop this unencrypted email system from being received, this did not preventing the user’s client software from sending their username and password in the clear for anyone to see.

Almost encrypted office-suite

This next incident was particularly tragic because of how much effort the user had clearly put into attempting to ensure their security by supporting encryption at multiple layers of their software stack.

Once again sifting through Splunk logs and corroborating those Splunk logs with the original packet data – available to us from the EndaceProbe in the Cisco Live SOC – we discovered a user who had configured a self-hosted Office 365 alternative on their Android smartphone so they could synchronize and manage contacts, images, and important documents using a self-hosted office suite server.

Initially, we thought this was a case of some user setting up an office suite on a home network and port forwarding that instance to the open internet using their home router. This obviously is not a recommended way to expose a private service to a remote user, but is still very commonplace due to users not fully understanding the risks of such a setup.

In this case, however, upon further inspection we discovered this office suite server was running behind a Cloudflare TLS termination gateway. We also saw that encryption for the WebUI had been configured correctly so attempts to access a non-encrypted version of the login page would automatically redirect to the encrypted page.

The one weak link in the system was that this particular Android client had been configured to use the unencrypted webDAV endpoint and was not following redirects because it was not a full web browser. It was at this point that we realized, tragically, that we were observing a user who:

had properly put their self-hosted office suite system behind a Cloudflare DDOS protection gateway
had properly configured TLS for the service
had properly HTTPS redirection in place.

However, since they did not have port 80 configured to only allow HTTPS redirection and not allow any other access to the services via port 80, and because the android client was defaulting to using port 80 but not being redirected, the user was leaking sensitive credentials and business information for anyone to see.

Authentication data transmitted in the clear because of a simple, overlooked, mis-configuration.

Conclusion

To wrap all this up, and provide a moral to this collection of stories: just because your software stack supports encryption does not guarantee that it is necessarily using that encryption. You have to make sure that all software is configured correctly to be using the encryption that it will most likely already support. Furthermore, most firewalls and security systems won’t flag unencrypted traffic as it is not necessarily malicious nor is it inherently risky to the network operator.

The only way we discovered this was thanks to the use of Splunk logging and its integration with Endace’s always-on packet capture system. This allowed us to reconstruct the full packets for these incidents – which a smart PCAP system or a firewall triggered PCAP system would never have seen.

Acknowledgements

Our thanks go to the Cisco SOC team, led by Jessica Oppenheimer and Ivan Berlinson, for the opportunity to integrate EndaceProbes with the Cisco Live Agentic SOC architecture.

The Endace and Cisco teams were able to prove out integration innovations and test them in earnest in a real-world environment in preparation for making them generally available to the market.

Episode #66 Cody Spooner from Corelight talks Incident Response and Threat Hunting

Original Entry by : Michael Morris

In the Packet Forensic Files, Episode 66, Michael talks to Corelight’s Cody Spooner.

By Michael Morris, Senior Director of Global Business Development, Endace

The Increasing Complexity of Incident Response
and Threat Hunting

In this episode of the Endace Packet Forensic Files, I sat down with Cody Spooner, Principal Sales Engineer and DFIR expert at Corelight, to discuss a really interesting topic: the subtleties and differences of “Enablers” vs “Behaviors” of a cybersecurity compromise.

Cody explains that when most people think of threat hunting or incident response investigations, they picture analysts looking for signs of malicious activity. In reality there are critical subtle differences between the “behavior of a compromise” and the underlying “enabler of a compromise” that often go unnoticed or overlooked. He highlights how organizations tend to focus heavily on detecting malicious behaviors – such as data exfiltration or unauthorized logins – but often miss identifying the enabling conditions – such as misconfigurations or legacy protocols – that led to those compromises in the first place.

Cody shares examples of seemingly harmless issues that can become the doorway to a full compromise, such as configuration issues or outdated or deprecated protocols like NTLMv1 and SMBv1. These often persist in modern environments and Cody suggests that incident responders and threat hunters can usefully focus on identifying and eliminating these enablers to reduce the organisation’s risk profile.

Cody gives advice for security teams on how to shift their mindset from focusing only on behaviors to focusing on enablers as well in their threat hunting activity. He also provides insights into how IR teams should interpret and contextualize indicators of compromise and discusses how the “why” behind an attack can often change or influence the response strategy.

Finally, Cody shares his thoughts on what emerging technologies or architectural trends will create new classes of enablers that defenders need to start paying attention to now.

Other episodes in the Secure Networks video/audio podcast series are available here. Or listen to the podcast here or on your favorite podcast platform.

Endace Ecosystem Expands: Is 2026 the Year of the Packet?

Original Entry by : Mark Evans

By Mark Evans, VP Marketing, Endace

A growing ecosystem, driven by increased demand

Endace’s Fusion Partner Program is expanding rapidly, with new partners, including Microsoft Sentinel, Google SecOps, Sumo Logic and Exabeam (and more coming), and updated integrations to solutions from Cisco, Splunk, Palo Alto Networks, Elastic, Sumo Logic, Fortinet, and others.

On the surface, this looks like steady ecosystem growth. In reality, it reflects a clear shift in what customers are asking for.

Organizations are rethinking how their security and network operations stacks work together and, more importantly, where reliable data comes from. As that conversation evolves, one thing is becoming clear. Full packet capture is no longer a niche requirement, but rather a foundational need.

The growth of the Fusion Partner ecosystem is a direct response to that shift. More vendors are integrating with Endace because their customers want immediate access to packet-level evidence inside the tools they already use. When something happens on the network, teams need to be able to go straight from alerts to the ground truth. And quickly!

Integration first: from tools to a unified evidence layer

One of the biggest changes happening in security operations is how tools work together. Detection platforms are no longer enough on their own. They need access to reliable, underlying data to more accurately detect complex threats and malicious behaviour, and link together attacker activities to create an accurate picture for security teams.

Full packet capture strengthens existing platforms by acting as a shared evidence layer across the SOC and NOC stack. Instead of operating in silos, systems such as SIEM, SOAR, XDR, and NDR can all draw from the same packet-level data to enable SOC and NOC teams to investigate incidents quickly and make confident, evidence-backed decisions.

Through the Fusion Partner Program, this capability is embedded directly into existing tools and workflows, enabling analysts to move seamlessly from detection to deep investigation without leaving their primary tools.

From alerts to evidence

Rather than replacing existing platforms, packet capture strengthens them by acting as a common evidence layer across the SOC and NOC stack. Whether an alert originates in a SIEM, an XDR platform, or a performance monitoring tool, analysts can pivot directly to packet-level data to see exactly what happened.

This is what the Fusion Partner Program is designed to enable. It integrates packet data directly into platforms like Microsoft Sentinel, Google SecOps, and Splunk, so analysts have definitive forensic evidence at their fingertips when they need it most. It is a simple idea, but it changes everything about how investigations are conducted.

AI is raising the bar for evidence

The rise of AI in security operations is accelerating this shift. AI can identify patterns, surface potential threats, and recommend actions, but those outputs still need validation. Without access to underlying network data, teams are relying on probability rather than proof.

Packet capture provides the validation layer that AI necessitates. It enables teams to confirm whether alerts are real, supports more accurate automated responses, and helps ensure that investigations are grounded in evidence.

At the same time, AI is making packet data more accessible. As AI-assisted investigation improves, teams no longer need arcane, packet wrangling skills to extract value from pcap data. AI-enabled investigation and automation tools can put relevant pcap evidence right at their fingertips. This accelerates investigations, removes a potential barrier to packet capture adoption, and broadens its relevance.

Compliance is making packet capture unavoidable

Regulation is another major force driving packet capture adoption. Across global frameworks and industry standards, organizations are being asked to collect more detailed telemetry, respond to incidents more quickly, and provide stronger evidence when required. Increasingly, these expectations point directly to full packet capture.

Research shows that regulatory bodies are either explicitly requiring packet capture or setting requirements that cannot realistically be met without it. For example, in the SANS whitepaper Full Packet Capture as Strategic and Regulatory Imperative, author Matt Bromiley explains that some frameworks now mandate short retention windows for full packet data, while others emphasize comprehensive logging, forensic evidence preservation, and rapid incident reporting which implicitly require packet capture in order to meet their requirements.

Mandated packet capture requirements are already in place at the U.S. federal level. The U.S. government’s OMB M-21-31 requires US federal agencies to implement at least 72 hours of full packet capture (FPC) as part of baseline cybersecurity logging.

Many regulatory reporting timelines now also depend on forensic-grade network evidence. For example, under the EU’s NIS2 Directive, organizations must issue 24-hour early incident notifications and 72-hour full incident reports with detailed forensic evidence. These deadlines are nearly impossible to meet without full packet-level visibility, reinforcing full packet capture as a compliance enabler.

At the same time, best practice cybersecurity standards such as NIST CSF and ISO 27001 are placing greater emphasis on continuous monitoring and the ability to reconstruct complete network activity, rather than relying on logs or sampled data alone. In practice, this means organizations need access to full packet data to meet both compliance and operational requirements.

This is being reinforced across major frameworks. Requirements for continuous monitoring, detailed logging, and rapid incident reporting all point toward the same conclusion: logs and sampled data are not enough on their own. Organizations need complete visibility into network activity to meet both operational and compliance expectations.

The result is a shift in mindset. Packet capture is no longer a nice-to-have. It is becoming table stakes for both security architecture and compliance strategy. Packet capture provides a single, authoritative source of network truth to support detection, investigation, response, reporting, and auditing, while also strengthening overall security posture.

The shift to evidence-based network security and performance ecosystems

The expansion of the Endace Fusion Partner Program is a clear signal of where the market is heading. As demand for packet-level visibility grows, more vendors are looking to integrate it into their platforms to enhance incident detection, investigation, and response.

2026 may well be remembered as the year organizations recognized the limits of detection without evidence. As that realization spreads, packet capture is becoming a foundational component of modern security operations architecture.

As we move forward, we’ll continue to see real operational impact and faster, more confident responses. Most importantly, decisions are based on what actually happened on the network, rather than assumptions or partial visibility. And increasingly, the ecosystem forming around packet capture will define how security operations evolve next.

Endace Achieves Cisco Solution Plus Partner Status

Original Entry by : Michael Morris

By Michael Morris, Senior Director of Global Business Development, Endace

I am excited to share that Endace has just achieved an amazing milestone. On March 17, 2026, Endace achieved Cisco Solution Plus Partner status.

This means our EndaceProbe™ Analytics Platform is now available on the Cisco Global Price List (GPL) and can be sold by Cisco sales teams and channel partners as a Cisco SKU (initially for USA-based customers only).

Solutions that are part of the Solution Plus Partner Program achieve that partnership level through strong sponsorship by a Cisco Business Unit that sees value in complementing Cisco’s solution offerings.

Endace’s tight integration with Cisco Security solutions, including Cisco Secure Network Analytics, Cisco Secure Firewall, and Cisco XDR, as well as Splunk Enterprise Security and Splunk SOAR, make Endace an extremely complementary solution for recording critical network forensic evidence for security and network teams.

Endace’s industry-leading platform – EndaceProbe – provides Always-On, full packet capture across on-prem, virtual, and cloud-native environments. With the ability to access and analyze recorded packet data quickly from a single-pane-of-glass, and full API integration with a wide range of security and performance monitoring solutions,

EndaceProbes make recording and using packet data easy for SOC, NOC and IT teams. The EndaceProbe platform’s scalability, performance, high-speed search and open architecture ensures customers can reliably record critical network evidence. Fast access to full packet data can be integrated directly into any SIEM, Firewall, NDR/XDR, SOAR or NPM solution, putting forensic evidence at analysts’ fingertips for incident investigation and threat hunting. Analysts can go directly from indicators of compromise to absolute network evidence with a single click.

Cisco selecting Endace as a complementary packet capture solution validates Endace as the BEST-IN-CLASS packet capture solution in network security.

Cisco Solution Plus Status listing is a testament to the scalability, reliability and usability of the EndaceProbe platform and the resiliency we’ve built into our solution by achieving compliance with military grade security standards such as FIPS 140-3, NIAP NDcPP, and US DOD APL.

Our goal is to ensure that customers have the ultimate network forensic evidence at their fingertips. Integrating this capability into Cisco Security and Splunk solutions enables SOC and NOC teams to quickly and accurately detect, investigate and remediate cyber threats and performance issues.

These integrations have been honed by real-life, hands-on, experience with our Engineers working alongside the Cisco and Splunk teams in SOCs at major events such as Cisco Live, RSAC, Black Hat and others.

This “in-the-field” experience has driven numerous product innovations for Endace, Cisco and Splunk, which ultimately benefits all customers. Our gratitude goes out to Jessica (Bair) Oppenheimer, Director SOC Integrations – Splunk Security, who worked with us to incorporate Endace packet capture as a fundamental component of Cisco’s SOC-in-a-Box architecture.

We are also grateful to be working with the amazing Cisco Solution Plus team, who see the value in Endace and have worked diligently to add EndaceProbe solutions to the Cisco SP+ portfolio.

Our team is excited and energised to help the Cisco and Splunk teams solve our customers’ toughest security challenges and protect some of the largest, most critical networks on the planet.

PCAP or It Didn’t Happen!

Please out to sales.cisco@endace.com or your Cisco Sales Rep for more information.

Episode #65 Andrew Cook from Recon Infosec discusses Incident Response and Threat Hunting

Original Entry by : Michael Morris

In the Packet Forensic Files, Episode 65, Michael talks to Andrew Cook, CTO at Recon InfoSec and host of the Thursday Defensive Webcast.

By Michael Morris, Senior Director of Global Business Development, Endace

The Increasing Complexity of Incident Response
and Threat Hunting

In this episode of The Packet Forensic Files, I’m joined by Andrew Cook, CTO of Recon InfoSec – an Air Force cybersecurity veteran and seasoned DFIR expert – to discuss what it really takes to investigate and respond to today’s most complex cyber incidents.

Drawing from his years of frontline experience handling major breaches and ransomware events, Andrew shares how real-world incidents have reshaped his investigative mindset. One area he starts with is the “human impact” of working through a security incident. Cyber breaches have impacts on people who may experience guilt for having been the one who clicked on that phishing email, or anxiety and stress for the people who are trying to quickly defend, investigate, and remediate a breach to get their company back online. Their experiences are not unlike those of crime victims on the street. Or first responders facing high-pressure situations.

We walked through Andrew’s incident response workflow, focusing on the steps he considers most critical when time, clarity, and confidence are most important. He talks about the importance of “timelining” to accurately build a timeline of evidence, events, and data to fully understand the breadth and depth of a breach.

Andrew shares some of his tools of choice for incident response investigations when he doesn’t have the luxury of his company’s full security stack. He gives examples of how packet data, when combined with endpoint logs, SIEM alerts, and threat intelligence, enables investigators to build a far more complete and defensible picture of incidents. Packet-level visibility, in particular, remains a cornerstone of high-fidelity investigations—often revealing attacker behavior, lateral movement, or data exfiltration activity that traditional logs and other telemetry may miss.

We also explored how different types of incidents should be prioritized and categorized to ensure the right resources are applied at the right time. Andrew highlighted the need for clear decision-making frameworks that balance technical severity, business impact, and regulatory considerations. He talks through the concept of thinking about the potential risks and thinking backward from that outcome of what would be needed to prevent or solve that problem as you build and design your SOC architectures.

Looking ahead, Andrew shares his perspective on emerging trends shaping digital forensics and incident response, including the increasing sophistication of adversaries, growing data volumes, and how leveraging AI can help SOC analysts make sense of the complexity. Ensuring forensic rigor while meeting regulatory and legal requirements remains a non-negotiable aspect of modern DFIR work.

Finally, Andrew shares what he thinks is key to look out for over the next 6–18 months: Attackers using AI-assistance to leverage threat vectors – for example using application extensions – that drive data loss. And AI plugins given access to sensitive data that are leveraging prompt injections and PowerShell programs to compromise environments. The sophistication of threat actors with the help of AI is only getting more advanced.

Other episodes in the Secure Networks video/audio podcast series are available here. Or listen to the podcast here or on your favorite podcast platform.

Cisco Live Amsterdam 2026: IPv6’s Time is Finally Here, for Users and Threat Actors Alike

Original Entry by : Cary Wright

By Cary Wright, VP Product, Endace

Cisco Live Amsterdam 2026: IPv6 is finally here, along with the threats

At each SOC event, we capture and inspect every packet from start of show through to the very last hour, for the purpose of securing the attendees and conference, wiping the data at the end. This gives us a rare opportunity to understand how the traffic trends and threat landscape are changing. Each SOC event shows us new data and developing trends that are useful to dig into. The week of Cisco Live EMEA, we got to see a milestone with the transition to IPv6.

The Internet has technically been out of IPv4 addresses for years, yet global adoption of IPv6 — the modern protocol designed to replace it — continues to climb slowly. As of late 2025, worldwide IPv6 usage sits at roughly 49%, based on Google’s traffic metrics. While several countries have made remarkable progress, the global transition remains uneven and far behind early expectations.

Why IPv6 Matters

IPv4’s roughly 4.3 billion available addresses are nowhere near enough for today’s hyper‑connected world. In contrast, IPv6 offers a 128‑bit address space, providing 3.4 x 10³⁸ possible addresses — more than enough for decades of growth. Technologies like Network Address Translation (NAT), private addressing, and CIDR have extended IPv4 far beyond its natural lifespan. These workarounds give organizations a false sense that IPv4 is still sufficient, reducing the urgency to adopt IPv6.

What we observed in Amsterdam

In the Cisco Live EMEA SOC, we inspected 130 billion packets across 32,434 unique IP endpoint devices at the conference, using Splunk to query unique DHCP Client IDs to measure. These included devices connecting to the Wi-Fi and wired networks at the Cisco Live conference network, including attendee laptops, phones, and conference devices such as demo stations, cameras, IOT devices, displays, networking equipment, and any other IP connected device.

Of this traffic, 62% of the data travelled over IPv6, and only 38% over IPv4. This represents a tectonic shift in the move to IPv6. Perhaps this was because we were sitting just a few miles from the Regional Internet Registry for Europe, Middle East and Central Asia (RIPE NCC), or more likely this is because the world is finally ready and moving to IPv6.

Our heaviest day was Tuesday, with 25,609 devices that connected to the network.

Across all this traffic we observed 1.7 million unique IP addresses, most of which were external addresses accessed by attendees and conference devices. Those IP addresses were made up of 386,397 IPv4 addresses, and 1,339,329 IPv6 addresses.

Threat Actors — adopting IPv6 faster than anyone

In the SOC, we have no shortage of data to interrogate, interrogating our Splunk data highlight that threat actors are now heavily favoring IPv6 to conduct their attacks, hijack resources, or compromise systems. Over 99% of malicious URLs and crypto miners used IPv6, telling us that we need to ensure we properly secure our IPv6 infrastructure. Just 1% of our attacks involved IPv4. That indicates a trend that we all need to take notice of.

Splunk search of incidents at Cisco Live EMEA 2026

A Steady Shift — But an Inevitable One

Although the transition has taken decades, IPv6 momentum appears to have crossed an important threshold. With increasing digital demands, rising IPv4 costs, and rapidly expanding device ecosystems, IPv6 isn’t just beneficial — it’s essential.

The future of the Internet is unquestionably IPv6. The challenge now is how quickly the world can get there, and how well we secure it. At Cisco Live EMEA, we saw the world has taken a large and important step forward.

Acknowledgements

This important insight to IPv6 adoption would not have been possible without the great work done by the Cisco Live EMEA SOC team, led by Jessica Oppenheimer and Ivan Berlinson.

Data collected and analyzed was the result of a team, many thanks go to the following team members:

Network Operations Center Liaisons

Remco Kamerman, Luke Hebditch, Mark Bremner and Scott Neuman

Cisco Security and Splunk SOC Team

SOC in a Box: Adi Sankar
Splunk Security Integrations: Paul Pelletier and Kenneth Bouchard, with Josh Wilson and Duane Waddle
Splunk Threat Researchers: Nasreddine Bencherchali and Paul Pang
Breach Protection Suite: Mark Pleunes, Ibrahim Yusuf, Piotr Jarzynka, Matt Vander Horst, Yannis Steiakogiannakis and Eric Rennie, with Bilal Qamar
User Protection Suite: Aaron Woland
Firewall and Security Cloud Control: Adam Kilgore and Christopher Grabowski

Endace SOC Team

Co-SOC Leader: Cary Wright
Endace Engineering: Owen Gallagher, Sundarram Paravastu and Sam Brockelsby

Read related Cisco Team Blogs from the Cisco Live Europe 2026 SOC:
https://blogs.cisco.com/security/emea-soc-2026

For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/