Category: Cisco Live SOC

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

Barry

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
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.
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
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.

The AI Agent completes its analysis and outlines its conclusion.
The AI Agent completes its analysis and outlines its conclusion.

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 AI Agent elaborates on its initial conclusion when asked for additional analysis.
The AI Agent elaborates on its initial conclusion when asked for additional analysis.

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 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:

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 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

Elliot Hinsen, 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.
Recorded data upload dates and times shown in EndaceVision.
Extracted images were reassembled from the packet data using Zeek.
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.
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 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:

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

Threat actors are recording PCAPs, maybe you should too?

Original Entry by : Barry "Baz" Shaw

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

Barry

On Aug 29th, Government Cybersecurity agencies from around the world released a joint advisory detailing how nation-state threat actors are compromising networks across the world, particularly in the US, Australia, Canada, New Zealand and the UK: www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a www.darkreading.com/cybersecurity-operations/cisa-fbi-nsa-warn-chinese-global-espionage-system

These attacks are primarily focussed on telecommunications, government, lodging and military networks, and the tactics, techniques, and procedures (TTP) overlaps with APT (Advanced Persistent Threat) actors linked to multiple China-based entities. These threat actors are exploiting well-known vulnerabilities in VPN servers and web user interfaces on switches and routers.  Even devices not owned by targets of interest are being compromised in order to provide additional attack pathways to the intended targets.  Upon gaining a foothold in a network, persistence is achieved by modifying ACLs, opening services on non-standard ports to avoid detection, and tunnelling C2 and exfiltrated data to obfuscate malicious activity.

Of note in this particular instance is the use of PCAP collection on the target network by the threat actors.  Once they’ve gained a foothold on the network infrastructure, the native capability of some routers to record PCAPs is then used to capture TACACS+ (authentication) traffic.  When transmitted in clear text (or weakly encrypted) this authentication traffic exposes users credentials which can then be used to elevate the attacker’s access and enable them to move laterally across the network.

The use of network sniffing to extract credentials in authentication traffic is a common technique of threat actors (attack.mitre.org/versions/v17/techniques/T1040/).  As we continue to see the stubborn use of unencrypted and weakly-encrypted protocols on networks, these insecure communications remain prime targets for credential gathering.  Additionally, the uses of maliciously collected PCAP is evolving, with the ArcaneDoor campaign taking this a step further and exfiltrating captured PCAPs for remote analysis (attack.mitre.org/campaigns/C0046/).  Exfiltrated PCAPs may contain anything from authentication data to file objects.

PCAP data is the ground-truth for what is happening on the network, and it is the source that all other network and security telemetry is derived from.  Threat actors know this and value the raw unfiltered and unsampled intel that it provides about the target.  This begs the question: if your adversaries see value in collecting PCAPs off your network, shouldn’t you be capturing full PCAP too!? 

If you are not recording your network traffic, your security team has less visibility into network activity than your attackers – which makes the job of protecting your network impossibly difficult. With PCAP at their fingertips, SOC analysts can see exactly what’s happening on the network, making for faster, more accurate investigation and resolution of security incidents – as this excellent blog post from Cisco’s Steve Nowell describes.

That full PCAP data is so valuable to attackers also highlights a stark warning that wise defenders should heed. PCAP data must be protected and secured to the highest standards.  Can you trust packet capture solutions that aren’t FIPS and Common Criteria certified? Or packet capture sources that can’t be properly locked down and protected from access by attackers?

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

Cisco Live US 2025 SOC – PCAP or it didn’t happen!

Original Entry by : Barry "Baz" Shaw

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

Barry

Elevating Incident Response with the Ultimate Network Forensics

After a successful SOC @ RSAC2025, our team was stoked to be invited to help Cisco run the SOC at Cisco Live US (CLUS). We jumped at the chance to work with the Cisco team again. It was a great opportunity to innovate while helping Cisco protect and educate the attendees of the conference. Plus, the Cisco team is a lot of fun to hang out with—there’s a very infectious vibe in the SOC that has everyone buzzing for the entire week.

Packet capture is essential in the SOC. It provides an indelible record of all network activity, which is invaluable to the SOC team when investigating threats or security risks—hence the phrase, “PCAP or it didn’t happen.” For CLUS, we deployed two EndaceProbes with a combined storage of 864TB to continuously record all network activity delivered via 2 x 10GbE SPAN ports. This gave us the capacity to record at least several weeks of full network packet data—covering more than the entire duration of the show.

Endace Fusion integrations provided the glue between the Cisco Security suite and the packet data on the EndaceProbes, enabling analysts to quickly pivot from Splunk Enterprise Security/Splunk Cloud, Cisco XDR, Cisco Firepower, and Cisco Secure Network Analytics (SNA) through to EndaceVision and hosted Wireshark. When access to historical full PCAP is available in a seamless integration, security analysts are empowered with the ease of contextual access, and this simplifies the use of PCAP data, where previously it could be seen to be cumbersome to use.

The EndaceProbes each hosted two VMs that were running Zeek and delivering critical log data into Splunk. Custom Zeek script additions provided additional valuable detail around clear text passwords in email and HTTP, shining a light on the heavy use of insecure protocols, and ultimately driving automation to manage the unexpected volume. File-carving was enabled, and over 750,000 files were reconstructed from packet data, with over 40,000 samples submitted to Splunk Attack Analyzer (SAA) via Endace’s automatic submission software. SAA then sent over 12,000 files to Secure Malware Analytics (formerly Threat Grid) for dynamic analysis of the behavior.

SOC Findings and Lessons Learned

The SOC team was surprised and initially overwhelmed at the volume of unencrypted traffic on the network. Logging of passwords was coupled with a Cisco XDR automation that created an incident on each detection. This resulted in a heavy workload identifying and notifying users to educate and protect them in the future. The Splunk team developed a creative automated solution to notify users that the SOC detected their use of insecure protocols.

We even found a version of POP that was news to us all—APOP. This hashes the server timestamp in the response header with the user’s password to create a password digest. While this obscures the password, it only delays its inevitable retrieval, all the while the actual message bodies are still transferred in plain text!

In the theme of plain text passwords, reviewing the connections associated with one of these sessions showed a large number of file downloads in the Zeek log generated on EndaceProbe.  This was one of many clients that used the free conference Wi-Fi to download Windows update files, but after filtering out the cab files in a Splunk search, we found a suspicious-looking file:

A search on this filename in SAA confirmed the presence of a malware download by this unfortunate user, whom the SOC team made every effort to identify.

There were also a few notable occasions where Secure Firewall alerts indicated intrusion attempts, which, after a pivot to EndaceVision, were pulled up in Wireshark for further analysis. One alert of note was a “BROWSER-IE Microsoft Internet Explorer Chakra.dll Array.filter type confusion attempt” indicating a malicious web server was trying to exploit a vulnerability in IE. 

A review of the PCAP noted that the target client was, in fact, running Safari on MacOS X.

This indicated that even if the web server was launching a legitimate attack, the client was not vulnerable to this attempt and therefore no further action was required. This highlights the value of full PCAP, packets in related sessions that don’t trigger alerts can offer valuable insight and context to security analysts. This allows rapid determinations to be made with confidence.

Read more about the SOC at CLUS 25 on Cisco’s Blog here:

https://blogs.cisco.com/security/cisco-live-san-diego-2025-soc

Acknowledgements

Our thanks to the Cisco team, led by Jessica Bair-Oppenheimer and Steve Fink, for the opportunity to include EndaceProbes in the Cisco Live SOC architecture. The SOC team is a collection of Cisco experts across many Cisco solutions who were a pleasure to work with and innovate with.  We came away with a great appreciation for the power and ease of use of the Cisco Security tools. The close collaboration resulted in the Endace team leaving with not only ideas for further integrations and workflow improvements, but also prototype integration extensions that were developed and proved out during the SOC.

To learn more about all the ways Endace integrates with Cisco, check out:  https://www.endace.com/cisco.

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

Helping Protect Cisco Live 2025 in San Diego

Original Entry by : Michael Morris

By Michael Morris, Senior Director of Technology Alliances

Building on our collaboration in the SOC at RSAC 2025, Endace was honoured to be invited by Cisco to provide EndaceProbe packet capture and a team of threat hunters to support the Cisco Live Security Operations Center (SOC). Our primary goal was to protect the network and attendees at Cisco Live San Diego 2025, our secondary goals were to educate and innovate.

Two EndaceProbes were deployed in Cisco’s SOC-in-a-Box, continuously recording all network traffic provided over two 10G SPAN ports.  We integrated with Splunk Enterprise Security and Cisco Security Cloud to deliver real-time network visibility. This enabled the SOC team to detect, locate, and address threats to attendees from external and internal sources, and helped to streamline and accelerate SOC investigation workflows.

The SOC at Cisco Live aims to protect the more than 23,000 attendees from threats on the conference network. When an attendee’s device is found to be compromised or unsecured, the SOC team makes every effort to identify, locate and help remediate the issue. The SOC team also provided public tours of the SOC to educate attendees about how the SOC is configured, the processes team members implemented, and the sorts of issues and threats that we uncovered.

Drawing on our experience at RSAC 2025 (where Endace captured 36 TB of data and 45 billion packets) we further optimized our approach for Cisco Live’s SOC.

The SOC was set up in two days, leveraging prior planning and our engineers’ experience at RSAC 2025.

At Cisco Live, Endace:

  • Captured 78.9 TB of traffic representing 99.5 billion packets
  • Reassembled more than 740,000 file objects in real time and sent 42,624 files to Splunk Attack Analyzer for further analysis
  • Detected 2,256 occurrences of cleartext passwords being used from 92 unique devices
  • Provided packet-level forensic evidence to all the SOC analysts for investigating and triaging a range of security events
  • Integrated with Cisco XDR, Splunk, Cisco Firepower IDS, Splunk Attack Analyser, Cisco Secure Malware Analytics, Cisco Secure Network Analytics to provide a seamless IR workflow
  • Innovated with new integrations that streamed additional metadata into Splunk, which sped up the investigation and remediation process

It was impressive to see the whole team of Cisco and Endace Engineers pivoting to the packet data to investigate an entire range of security incidents. Inspecting the packet data enabled fast decisions because the team could see exactly what was happening on the wire before, during, and after any event. As they say, PCAP or it didn’t happen!

Having complete packet data available at the SOC team’s fingertips really highlighted the incredible value of always-on packet capture; recording every packet and delivering complete, real-time visibility into threats, performance issues, and anomalous behaviour across the network.

There is an infectious energy that we get when working in a SOC environment like this, with Engineers from different teams and companies collaborating to track down threats, and share ideas on how to improve the SOC. The Endace team came away with many learnings that will improve EndaceProbe and our partner integrations.

We look forward to being a part of the SOC again at some more big upcoming events – stay tuned, details coming soon.

Read more about the SOC at CLUS 25 on Cisco’s Blog here:

https://blogs.cisco.com/security/cisco-live-san-diego-2025-soc

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