This year's BSides Zürich conference took place in downtown Zürich, Switzerland, on September 17. Zürich has a vibrant tech ecosystem, thanks in great part to the renowned ETH Zürich engineering school and the presence of engineering offices for major tech companies like Google and Microsoft.
BSides Zürich has a unique format. In the morning, three 20-minute talks are presented. Then, attendees can deep dive into the topic of their choice in breakout rooms together with the speaker in an interactive and informal atmosphere. They repeat this process in the afternoon.
This set-up has interesting benefits. First, you get to interact with the presenters and ask questions. BSides Zürich is a small venue, maxing at 150 seats. This makes these conversations feel very intimate and high-quality. A second benefit of this format is that it means you need to choose which topics you’re most interested in, as opposed to attending several 45-minute talks on topics that may not be as relevant to you.
Next, we'll look at some highlights among the talks given at this year's BSides Zurich.
Sanaz Yashar from Mandiant presented the first talk of the day. After providing her analysis of the leaked Conti group chat logs, Sanaz discussed the types of connections that Mandiant sees in their investigations between cybercrime and nation state actors. These relationships are typically one or several of:
- Partnership: Nation state actors partnering with cybercriminals to perform campaigns. This can happen, for instance, when a nation state actor purchases initial access to a target organization from an underground credentials broker.
- Recruitment: Nation state actors directly hiring cybercriminals.
- Indirect: Nation state actors looking the other way on cybercriminal campaigns when it serves their political objectives, such as going after an enemy nation.
- Moonlight: Nation state actors purposely masquerading as cybercriminals, such as in the infamous NotPetya case.
- Shared tools: Cybercriminals and nation state actors leveraging the same, shared tooling.
This talk was fascinating as it leveraged many insights coming directly from the field of incident response and provided a deep analysis of the hidden relationships of governments with cybercriminals.
Datadog’s very own Tommy McCormick works on our Compute Security team, which is in charge of securing our workloads. In this talk, he showed the main threats to containerized environments and how to protect against them.
- At runtime in block mode, using the OPA Kubernetes admission controller blocking malicious or dangerously configured workloads;
- At runtime in audit mode, accepting but logging and warning about malicious or dangerously configured workloads, in particular to ease the deployment of new policies or to establish a security baseline in a legacy cluster;
- At build time, by scanning Helm charts in pull requests for misconfigurations, and having a bot directly raise the issue on the GitHub pull request;
- At deployment time, by scanning Kubernetes manifests using gator.
Throughout the talk, Tommy argued that policy-as-code should be treated like code: properly versioned, deployed, and tested. In particular, he described how his team leveraged canary deployments of OPA Gatekeeper policies in order to ensure that new policies did not unexpectedly block engineers from working. He also demonstrated how to write unit tests for OPA policies, using the
gator verify feature.
You can find Tommy's slides here.
In his talk, Sven advocated for the “modern” security team. Security teams are—purposely and by design— outnumbered by the engineers who work on features and infrastructure. In addition, the rapid rise in the number and usage of cloud-native technologies makes it challenging for traditional security teams to keep up.
These two things put together make it impossible for security teams to act as blockers by reviewing every single feature or change released to production. Instead, Sven argues that modern security teams should:
- Set expectations early, and set different baselines depending on the criticality of a system. Not everything can be hardened; so focus on what matters.
- Be embedded in the development lifecycle while ensuring they don’t block development
- Start with why. People, especially engineers, better internalize requirements when they understand why they are there in the first place. It also helps create a healthy relationship, as opposed to having security teams push for requirements that aren’t understood.
- Use the same tools as engineering teams, or “be where your customer is.” For instance, a software engineer will be much more efficient when upgrading vulnerable dependencies if they get a GitHub issue for it as opposed to a 1,000-line Excel spreadsheet.
- Bring solutions to the discussion. In a modern organization, security teams need to be knowledgeable about the technology they’re securing and be able to bring technical solutions to overcome security issues. For instance, a security engineer remediating hardcoded secrets in Kubernetes manifests should be able to implement and propose a modern secrets management workflow that minimizes friction for developers.
- Decentralize security decision-making, for instance by leveraging security champions and self-service questionnaires or threat models. On that topic, be sure to read Julien Vehent’s “Beyond the Security Team.”
BSides Zürich is one of the few security conferences happening in Switzerland, together with BlackAlps, Area41, and Insomni’Hack. We enjoyed attending and would definitely recommend anyone who has the opportunity to do the same. And we encourage the conference organizers to keep the same format, which allows for more interactive and higher quality discussions between members of the community.