In April, Christoph Klaassen and I wrote about the paradigm shift that AI brings to information security management and GRC. We argued that traditional governance, built for human-speed processes and annual cycles, can’t keep up with systems that reason, plan, and act. The blog post closed with four shifts every InfoSec professional should make.
Several readers came back with the obvious follow-up: “Fine. But what do I actually do on Monday morning?”
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.
Three weeks ago, I attended MCTTP 2025 in Munich,
organized by Vogel IT and curated by the fine folks Florian Hansemann, Dr. Marc
Maisch, and Florian Oelmaier. Awesome event with some very cool talks, and great
conversations over dinner and most notably at the Oktoberfest on Saturday
(thanks again for that special trip, Flo!). I had the pleasure and honor to give
the keynote on the 2nd day. The goal was to make it a bit entertaining and
enlightening for the international audience, so I covered some German
literature, too ;-). The slides can be found
here, and the transcript
here. Looking forward
to meeting some folks again next year, maybe even at
TROOPERS26 😉
The #TROOPERS25 ‘AD & Entra ID Security’ track was a blast – as was the whole
conference 😉 – bringing together some of the smartest researchers in the field
and a great audience of practitioners willing to share their experiences during
the roundtable. The slides of the talks have
been released in the interim on the TROOPERS website, but
since many speakers published additional blogposts or released tools, we provide
a compilation of resources from the track in the following.
This is meant to be the first part of a 3-part series discussing the space &
types of IP addresses, with a particular focus on what has changed between IPv4
and IPv6. In this first post I’ll take the audience through a historical tour of
some developments within the IPv4 address space.
In a second part I’ll discuss the properties of different types of addresses
from a routing and from a security perspective, both in the IPv4 and in the IPv6
space. In the third part we’ll look at the implications of deploying IPv6 in
certain networks based on those differences, e.g. “how to handle ACLs and IP
address based log analysis approaches in a dual-stack network where systems have
one RFC 1918 IPv4 address and multiple IPv6 GUAs?” (for specific reasons the
latter two parts might be published on another medium though). In any case let’s
start with a brief history of IPv4. The goal here is to understand how we got to
the state that we have today.
I’ve been at Black Hat Vegas last week and in the following I’ll shortly discuss
some talks I’ve attended and which I found interesting.
Gabriele Fisher &
Luke Valenta: Monsters in the Middleboxes.
Building Tools for Detecting HTTPS Interception
This talk was about identifying if inbound HTTPS traffic reaching a server had
been intercepted by a middlebox (or
its software equivalent which is usually called “middleware”, a prominent
example being the Lenovo Superfish piece a few years ago) on its path.
In some organizations we work with a certain state of IPv6 deployment has been
reached in the interim which includes, among others, the following aspects:
the network infrastructure is IPv6-enabled (incl. interface addressing,
routing [protocols] and the like).
parts of supporting services (security functions, monitoring, system
management) include IPv6 in a proper way.
3rd party providers have been contractually obliged to deliver their services
in an “IPv6-enabled” mode (as opposed to only being “IPv6-capable” which was
the standard requirement in many RFIs during earlier years).
It might then happen that networking people (who often are the initial
motivators for deploying IPv6) in such organizations are stating, when asked
about IPv6: “it’s [mostly] done”.
Point is that, alas, this does not necessarily mean that a single service or
application is *actually using* IPv6, so while the above certainly constitutes
an achievement it might not even be halfway through.
In this post I’ll cover some properties of the Windows Server 2019 IPv6 stack.
It is an update of a similar post I wrote on the
IPv6 properties of Server 2016
a while ago.
For this reason I will mostly look at the same properties I did at the time
(read: at times without providing too much technical background information;
that can be found in the other post) and I’ve hence performed the same types of
practical tests.
This week Chris and I participated in the RIPE 78
meeting in Reykjavík. Being part of the group was fun as always and we had quite
some interesting conversations with peers from (not only) the IPv6 community.
Big thanks to the RIPE NCC team for the smooth
organization and for taking care of us!
In this post I’ll provide some notes on talks I found particularly interesting,
plus links to our own contributions.
Chris and I will give a tutorial on the above
topic at next week’s RIPE Meeting in Reykjavík. In
this post (actually this will probably become a small series of posts) I’ll try
to summarize some thoughts on IPv6 security in enterprise environments in 2019.
We’re going to cover three main areas:
Why IPv6 Is Different, Security-wise
Traffic Filtering in IPv6 Networks
IPv6 Security in L2 Networks / First Hop Security et al.
Let’s start with the first item. In real-life scenarios the security of “a
protocol” – IPv6 can rather be considered a “protocol family” which includes
helper protocols like ICMPv6 and MLD (which in turn is implemented by means of
ICMPv6 messages) and potentially others like DHCPv6 – might depend on a number
of factors: