When looking at security measures in Microsoft Entra ID environments, a common recommendation is to implement Conditional Access policies.
Whether Conditional Access is implemented can be quickly checked, and you can put a check mark next to it in your best-practice compliance form. However, simply implementing conditional access will not provide much security. A phishing attack that we recently analyzed highlights this very well.
Kubeflow is vulnerable to the theft of authorization tokens by any user of the Kubeflow UI or APIs, such as the Dashboard, Pipelines API, or Notebooks. With this token, the attacker can take over the user’s account and the data that is processed by that user. The attacker needs a valid user with the kubeflow-edit or Contributor role in a random Kubeflow namespace to perform this attack. This is given if Automatic Profile Creation is enabled. A setup based on the official manifests prior to version 1.10, and on most other packaged Kubeflow distributions, is vulnerable.
The Istio edit permissions were removed by Kubeflow in a timely manner. Affected users should update to the latest version to mitigate this issue.
When configuring a new device, achieving an acceptable Lynis hardening score is a challenge most practitioners are familiar with.
Navigating its recommendations often requires significant background knowledge, leaving administrators without clear guidance on which settings are vulnerable and how to remediate them effectively.
We believe that security hardening should be insightful and accessible, a philosophy that drove this research and the development of our tool, Hardener, built around three identified deficits in established frameworks:
Hardening a Linux client system to an acceptable degree is a time-consuming process, one that demands familiarity with a broad set of configuration parameters, framework recommendations, and the reasoning behind each control.
This post introduces our new Linux client hardening guide (MD, PDF), a comprehensive, publicly available hardening reference for Linux systems.
Over the last few weeks, I have had a very productive exchange with Christoph Klaassen on the impact of AI on security governance and compliance. In this post, we summarize our thoughts.
When the Perimeter Dissolves: InfoSec in the Age of Agentic AI
There’s an old saying among hackers coined by Dr. Eugene Spafford: “The only truly secure system is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards – and even then I have my doubts.”1
It was a joke, a wry nod to the impossibility of perfect security. But here’s the thing: the joke doesn’t land anymore. Because in the world we’re building right now, the systems don’t stay powered off. They reason. They plan. They act. And they do it faster than any human security team can keep up.
Welcome to the age of agentic AI. If you work in Information Security Management and/or Governance, Risk & Compliance, this is the inflection point you may have been sensing in your gut for months.
While investigating how process mitigation settings are initialized, I encountered the global variable PspSystemMitigationOptions. Tracing how this value is populated led me to the CmControlVector. In this blog post, we take a look at the Windows kernel land configuration manager, especially its global CmControlVector variable. Quick note: the kernel’s configuration manager is not related to Microsoft Intune’s Configuration Manager. In short, the configuration manager is responsible for managing and implementing the registry. However, it is also responsible for setting up parts of the system during early boot.
Exactly one week ago, Sven and I had the incredible opportunity to give our very first talk at KubeCon + CloudNativeCon 2026: How To Break Multi-Tenancy Again and Again …and What We Can Learn From It. We discussed the challenges of namespace-based multi-tenancy and presented real-world exploits in Kubeflow, Istio, and Traefik that bypass threat boundaries between namespaces and workloads. Based on these problems, we developed a methodology to assess and address them. You can find the methodology discussed in the talk in detail in another blog post or on GitHub. You can also find the slides here.
This page introduces our structured methodology for assessing security risks in Kubernetes environments that use Namespace-based Multi-Tenancy. It addresses weaknesses that break Namespace-based isolation that not well studied, yet. We found this issues during our research and presented them together with this methodology in our Talk at KubeCon + CloudNativeCon Europe 2026.
The methodology assumes that industry best practices, such as NetworkPolicies, Role-Based Access Control (RBAC), and Pod Security Standards, are already in place. These measures provide a necessary baseline level of protection against well-known isolation threats. However, they are insufficient to address a class of more subtle attack vectors arising from interactions between tenants and shared components. Such attack vectors may still compromise the confidentiality, integrity, and availability (CIA) of the cluster and its workloads, even in well-hardened environments.
We reported a possible Man-in-the-Middle (MitM) attack scenario in which a VirtualService can redirect or intercept traffic within the service mesh. This affects Namespace-based Multi-Tenancy clusters where tenants have the permissions to deploy Istio resources (networking.istio.io/v1).
This blog post highlights the risks of using Istio in multi-tenant clusters and explains how users can mitigate these risks and safely operate Istio in their deployments.
The behavior described in this post applies to Istio version 1.29.0 and to all versions since the introduction of the mesh gateway option in the VirtualService resource.
There is a growing landscape of security products promising to protect an organization’s IT infrastructure from attacks. Solutions referred to as EDR, and sometimes also as XDR, are designed to protect endpoints from all malicious activity. The ever-increasing cases of breaches and the associated costs, especially in the realm of ransomware attacks, raise the question of whether there is more that can be done to add an additional layer to traditional endpoint protection concepts. That is why a customer of ours commissioned us to evaluate whether EDR supplementing solutions provide extended protection against ever-evolving threats, as well as to shine a light on the performance overheads those solutions might introduce.
This blog post describes the methodology we use to evaluate and compare different EDR solutions for our customers. Given the growing number of sophisticated attacks, it is important not only to look at detection rates in isolation but to assess how these solutions perform under realistic conditions.