Cisco Live Amsterdam 2026: First Time in a SOC

Original Entry by : Sam Brockelsby

By Sam Brockelsby, Senior Software Engineer, Endace


Sam Brockelsby, Senior Software Engineer, EndaceOverview

This year, I got my first taste of what it’s like to be part of the Security Operations Center (SOC) team working at Cisco Live® Europe 2026 in Amsterdam. The SOC team is responsible for analyzing and determining the appropriate response for various security incidents on the public Wi-Fi network for the Cisco Live event. This includes everything from relatively harmless port scanning to command-and-control attempts from malicious entities.

Coming into the SOC as a newbie was exciting and a little bit daunting. There were a lot of people to meet and a lot of new things to learn. At first, I found myself a little overwhelmed getting to grips with all the various tools, technologies and processes – fortunately, everyone on the team was incredibility supportive, open to questions and eager to help out.
As a result, I was able to get up and running within a couple of hours and escalated my first incident before lunch on the first day. I will walk through this incident in the next section.

Incident Example: Authentication Bypass Attempt

Cisco XDR® had raised an incident for an Authentication Bypass Attempt. XDR is a tool that was used in the SOC to report incidents and provide a structure to the subsequent investigation. It has powerful automated features that allow an analyst to quickly pivot into other tools such as Splunk® and EndaceProbe™. Think of it as the glue that pulls all the various tools we used in the SOC together.

In my example, the incident was detected by the Cisco Secure Firewall® via Splunk SIEM. This incident involved two endpoints on the network that were communicating with several other devices.

The detail provided by XDR told me that a number of these Authentication Bypass events had occurred since the start of the day. It also told me that the devices were all PTZOptics VHD PTZ Cameras. This suggested that there were camera systems at the event that were vulnerable.

The next step was to look at the packets. From XDR I was able to click on a Pivot-to-Vision™ link to our EndaceProbes for one of these events. Two EndaceProbe appliances captured all the traffic on the public Wi-Fi network for the event – more than 120TB of data across four days. This is invaluable for the SOC, since it guarantees that an analyst can always go back and look at the exact packet data for any given security incident.

The Pivot-to-Vision link generated an EndaceVision™ investigation on the EndaceProbes with an IP filter for the endpoint I had selected in XDR, for a 10 minute time window around the detected event in question.

EndaceVision has various tools to help understand the nature of captured traffic. In my case the Traffic Breakdown chart showed that there was a lot of http_video traffic present in my selection. This was of no interest to me, so I added an application filter to omit it from my investigation. I then launched hosted Wireshark™.

In Wireshark I applied some filters to search for POST requests to the login endpoint. I then inspected the resulting conversations between the endpoint and the other devices on the recording subnet. The conversations were unencrypted over HTTP and clear text credentials were visible.

At the very least then, we had unencrypted traffic on the network that exposed login credentials. In addition to this though, the username and password looked a bit odd to me, so I did a quick Google search on the PTZOptics VHD PTZ Camera. It turns out that these cameras have a CVE where they come configured with default hardcoded credentials that cannot be modified by the user. These default credentials can be easily found by anyone on the web, and so even if the camera operators fixed the unencrypted traffic problem, they would still be vulnerable.

The final step in the process was to escalate the issue up the chain to the Network Operations Center, with the recommendation that the camera operator take steps to encrypt the traffic and update firmware to the latest version, which patches the CVE.

Final Thoughts

Working in the SOC is a collaborative process. For this incident (and others I worked on), I needed to ask for help on numerous occasions. The SOC team we had in Amsterdam was a diverse group of people with expertise in different areas, and each person brought something unique to the table. No one has every answer to every problem, so it’s a given that you will need to ask someone else to give you a hand at some point.

For that collaboration to work though, you need to have the right kind of environment – one that challenges people to do their best, while at the same time encouraging people to speak up and ask questions free from judgement. In my experience, we got that balance right.

Acknowledgements

My experience at this event 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

Cisco Security and Splunk SOC Team

Endace SOC Team

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/ 

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