Turn XDR volume into revenue. Morpheus investigates 100% of alerts and triages 95% in under 2 minutes, letting MSSPs scale without adding headcount.
The post The Autonomous MSSP: How to Turn XDR Volume into a Competitive Advantage appeared first on D3 Security.
The post The Autonomous MSSP: How to Turn XDR Volume into a Competitive Advantage appeared first on Security Boulevard.
I have no context for this videoβitβs from Redditβbut one of the commenters adds some context:
Hey everyone, squid biologist here! Wanted to add some stuff you might find interesting.
With so many people carrying around cameras, weβre getting more videos of giant squid at the surface than in previous decades. Weβre also starting to notice a pattern, that around this time of year (peaking in January) we see a bunch of giant squid around Japan. We donβt know why this is happening. Maybe they gather around there to mate or something? who knows! but since so many people have cameras, those one-off monster-story encounters are now caught on video, like this one (which, btw, rips. This squid looks so healthy, itβs awesome)...
The post Friday Squid Blogging: Giant Squid Eating a Diamondback Squid appeared first on Security Boulevard.
Regulators made their move in 2025.
Disclosure deadlines arrived. AI rules took shape. Liability rose up the chain of command. But for security teams on the ground, the distance between policy and practice only grew wider.
Part two of a β¦ (moreβ¦)
The post LW ROUNDTABLE Part 2: Mandates surge, guardrails lag β intel from the messy middle first appeared on The Last Watchdog.
The post LW ROUNDTABLE Part 2: Mandates surge, guardrails lag β intel from the messy middle appeared first on Security Boulevard.
Session 5D: Side Channels 1
Authors, Creators & Presenters: Lukas Maar (Graz University of Technology), Jonas Juffinger (Graz University of Technology), Thomas Steinbauer (Graz University of Technology), Daniel Gruss (Graz University of Technology), Stefan Mangard (Graz University of Technology)
PAPER
KernelSnitch: Side Channel-Attacks On Kernel Data Structures
The sharing of hardware elements, such as caches, is known to introduce microarchitectural side-channel leakage. One approach to eliminate this leakage is to not share hardware elements across security domains. However, even under the assumption of leakage-free hardware, it is unclear whether other critical system components, like the operating system, introduce software-caused side-channel leakage. In this paper, we present a novel generic software side-channel attack, KernelSnitch, targeting kernel data structures such as hash tables and trees. These structures are commonly used to store both kernel and user information, e.g., metadata for userspace locks. KernelSnitch exploits that these data structures are variable in size, ranging from an empty state to a theoretically arbitrary amount of elements. Accessing these structures requires a variable amount of time depending on the number of elements, i.e., the occupancy level. This variance constitutes a timing side channel, observable from user space by an unprivileged, isolated attacker. While the timing differences are very low compared to the syscall runtime, we demonstrate and evaluate methods to amplify these timing differences reliably. In three case studies, we show that KernelSnitch allows unprivileged and isolated attackers to leak sensitive information from the kernel and activities in other processes. First, we demonstrate covert channels with transmission rates up to 580 kbit/s. Second, we perform a kernel heap pointer leak in less than 65 s by exploiting the specific indexing that Linux is using in hash tables. Third, we demonstrate a website fingerprinting attack, achieving an F1 score of more than 89 %, showing that activity in other user programs can be observed using KernelSnitch. Finally, we discuss mitigations for our hardware-agnostic attacks.
ABOUT NDSS
The Network and Distributed System Security Symposium (NDSS) fosters information exchange among researchers and practitioners of network and distributed system security. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation. A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technologies.
Our thanks to the Network and Distributed System Security (NDSS) Symposium for publishing their Creators, Authors and Presenterβs superb NDSS Symposium 2025 Conference content on the Organizations' YouTube Channel.
The post NDSS 2025 β KernelSnitch: Side Channel-Attacks On Kernel Data Structures appeared first on Security Boulevard.
via the comic artistry and dry wit of Randall Munroe, creator of XKCD
The post Randall Munroeβs XKCD βEPIRBSβ appeared first on Security Boulevard.
This episode of the Defenders Log features host David Redekop and guest Andreas Taudte discussing the often-overlooked world of DDI (DNS, DHCP, and IP Address Management) and its critical role in network security.
Taudte defines DDI and explains his accidental entry into this specialized, yet foundational, field. He stresses that DNS and DHCP are core network services, and misconfigurations are common, often inherited from retiring long-term employees. He shares βhorror stories,β including a system where a majority of DNS responses were βnot existingβ (NXDOMAIN) due to misconfigured devices and a global organization where administrative access was never revoked from former trainees.
The discussion highlights DDI as a forgotten attack surface, noting that attackers focus on areas like DNS tunneling (TXt, HINFO, SINK records) and data exfiltration because these areas are often ignored by traditional security tools. Taudte notes improvements in awareness, especially regarding the need to integrate DDI tools with the broader ecosystem.
Taudte emphasizes the importance of applying security in layers, especially for DHCP, which he calls the βSandwich Kidβ of DDI, as it links devices to IP addresses. He supports the βdefault deny allβ approach (or Zero Trust) but notes that legacy infrastructure, such as 20-year-old factory robots, prevents a one-size-fits-all solution.
His final piece of advice is that DNS resolution should be predictable. Network teams must always be able to trace the path of a DNS query and predict the source of the response, filters applied, and what policies are enforced.
Would you like to explore any of the discussed topics, such as DNS tunneling or the concept of predictable DNS resolution, in more detail?
Full episode of The Defenderβs Log here:
The Hidden Layer of Cybersecurity: Andreas Taudte on DNS & DDI Defense
Cybersecurity experts David Redekop and Andreas Taudte discuss the crucial role of DDI (DNS, DHCP, and IP Address Management) as a foundational layer for security.
View it on YouTube: https://www.youtube.com/watch?v=pOjLMKL0qEc
Listen to the episode on your favourite podcast platform:
Spotify
https://open.spotify.com/episode/4TG0PXtD0ColIrxFXr7n0N
ADAMnetworks
https://adamnet.works
David Redekop: You know what drew you into this world of DNS and DDI?
Andreas Taudte: DNS resolution should be predictable.
David Redekop: I didnβt tell you this. This is something that many people are not aware of because itβs quite old. I always like to ask, is there one piece of advice or wisdom that you would like the world to know?
Andreas Taudte: But if you have some suspicious, uh, DNS communication within your network, everything that is not leaving your DNS infrastructure can still be a threat.
David Redekop: You are clearly a good teacher, instructor, empowering others.
Andreas Taudte: If you look at some network management tools or some network monitoring tools, they have some tab or some submenu where you have some item toβ¦
Voiceover: Deep in the digital shadows where threats hide behind any random byte. A fearless crew of cybersecurity warriors guards the line between chaos and order. Their epic battles rarely spoken of until today. Welcome to the Defenders Log, where we crack open the secrets of top security chiefs, CISOs, and architects who faced the abyss and won. Hereβs your host, David Redekop.
(01:20 - 05:20)
David Redekop: Welcome to another episode of the Defenders Log. This is episode number 11, and, uh, I had the chance to meet Andreas Taudte. I hope I pronounced your name, uh, correctly. Andreas Taudte, welcome.
Andreas Taudte: Many thanks for having me, and itβs good to have a chat with you again.
David Redekop: Yes, absolutely. I didnβt tell you this.
Andreas Taudte: Oh, that makes my life easier. Iβm kidding. No, no, no, no, no. Most of my German friends speak English better than I speak German anymore because itβs been so many years since Iβve had to actively use it. So, weβllβ¦
David Redekop: No, weβre going to make it the harder way. Weβre going to stay with English.
Andreas Taudte: Okay. Okay. So, just have to be careful what Iβmβ¦ what Iβm talking about. Uh, whenβ¦ when Iβ¦ when I switched to German, when I mean thinking about something like, oh my god, what is he thinking about? Stuff like that.
David Redekop: Well, you know what they say. The mother tongue is, uhβ¦ years ago I was, uh, told that the way you determine your mother tongue is how you do your times table. And everybody learns the mathematical timetable. In this part of the world, it is usually done 1 through 9, right? 6 * 7, 7 * 8, 9 * 9, right? So you have this entire matrix of your times table, and I learned it in German. So to this day, if you ask me whatβs 6 * 7, in my mind, itβsβ¦ [German thought process] and then I have to translate it back to English. So technically, German is still my mother tongue based on that determination, butβ¦
Andreas Taudte: I never⦠never heard about it. Never heard about it. But what⦠what I realized is when I, um, in⦠in the past before the pandemic, I was traveling, uh, a lot, but only in the northern hemisphere. For whatever reason, I never had a chance to go to the⦠to the⦠to the southern hemisphere. And when you are in⦠in a location where you are talking in⦠in English the entire day and maybe for a week or so, it happened to me that even my thoughts started to be in English, which was just awkward.
David Redekop: Wow. What about your tongue? Do you get a tired tongue from being in English all day?
Andreas Taudte: No. I guess itβs a little bit difficult in the beginning when you havenβt done it for a couple of days or even weeks, uh, toβ¦ Yeah. Come up to speed and make it fluent and stuff like that. It always just takes a little while, like anβ¦ like an old machine that needs to warm up a little bit. But, um, onceβ¦ once Iβm in, um, itβsβ¦ yeah, I know itβsβ¦ itβs definitely not perfect. And if you look at grammar and stuff like that, totally not correct, but yeah, I get used to it quite veryβ¦ very quickly. Very quickly.
David Redekop: Yeah. Well, this is going to be interesting from an AI LLM closed captioning perspective because our first run-through is always AI run, and then we go through an edit. So, I suspect weβll have to do a firstβ¦ a few German fixes in this one. Okay. I hope Iβm not offending you, but I have a German joke ready.
Andreas Taudte: Okay.
David Redekop: You heard about the, uh, British that were calling the, uh, German Coast Guard because they were in trouble?
Andreas Taudte: Ah, yeah. Oh, I⦠I knew when this is heading to.
David Redekop: βHelp, help. We are sinking.β And the German Coast Guard comes to the microphone.
Andreas Taudte: βYeah, what are you thinking about?β I guess this was actuallyβ¦ Iβm not sure, but I guess this was an ad many years ago in television about someβ¦ I have no idea, some academy where you can have someβ¦ some lessons or something like that. If youβ¦ if you look it up onβ¦ on YouTube or something like that, uh, youβ¦ you will actually find a real recording of that. Itβs a very, very old ad from theβ¦ from the time when we had televisions and not when weβre not watching Netflix onβ¦ on iPads, right?
David Redekop: One of the casualties of having had cultural migrations in my life is that a lot of things I discover for the first time today, and people like you are graceful in responding, βYeah, weβve known about that for decades already.β But itβsβ¦ itβs a really good one. Itβs an old one that is really good one. Yeah.
(05:21 - 09:52)
David Redekop: All right. Well, Andreas Taudte, it was a pleasure meeting you at, uh, I think the first time was in Stockholm at, uh, DNS-OARC, and, uh, you, uh, highlighted some things that made me realize that you really are an extremely deep learner. And, uh, based on what I saw you, uh, deliver in terms of content, you are clearly a good teacher, instructor, empowering others. And partly what we want to do with the Defenderβs Log is not only raise awareness around the aspect of zero trust networking, zero trust connectivity, andβ¦ and how just the core of, you know, doing security differently than weβve done it in the past. Instead of layering so many things, doing everything at the top layer, letβs start with doing things properly at the foundational layers. Letβs think about first building blocks and first principles, and, uh, you seem to just fit squarely in that space. So, Iβm glad you, uh, were available to, uh, hang around with me here online for a bit. And maybe you can just start by telling us, you know, what drew you into this world of DNS and DDI? Maybe start with DDI 'cause that term is very common inβ¦ in your world, but itβs not necessarily well known. So, letβs start with what DDI means and then how you got pulled into this world.
Andreas Taudte: Oh, letβsβ¦ letβs see if we, uh, we can make an entire podcast about that. Um, let meβ¦ let me try to make this very short. So, first of all, DDI stands for DNS, DHCP, and IP address management. When I started in this industry, it hadβ¦ it already had aβ¦ a different name. It was just called IPAM. And IPAM back then already included the management of the core network services DNS and DHCP. And then around, I guess, 2012, Gartner came up with a report and they actually created this acronym of DDI. Before that, it was just IPAM. And back then, uh, the old IPAM guys were a little bit confused like, βYeah, wait a second. DNS and DHCP was always included. So why double it?β Meanwhile, I like it that we have the phrase orβ¦ or theβ¦ or the acronym DDI and IPAM because in many tools you will find an IPAM section. So if you look at some network management tools or some network monitoring tools, they have some tab or some submenu where you have some IPAM to manage some networks or document some networks. But DDI really means that you have some interaction with the core network service, that you are pushing configs and that you are getting results into the database, for example.
Andreas Taudte: And I ended here by accident. I was, uh, a trainee at a company that was doing banking software, and when a customer not only wanted to buy the software but wanted to get it hosted in a data center, they had a subsidiary that was, uh, a data center provider, and I was a trainee in that organization. And during that time, they got acquired by a huge, massive organization that wanted to get foot in the door into this industry. Um, and during that period where my time with this company came to an end, they werenβt allowed to hire people because they were still talking about contracts because it was aβ¦ a Swiss organization. I was working for a German organization, and some, um, managers in the different organizations had to negotiate stuff and things like that. And in my class back then, there was a guy, uh, that was doingβ¦ exβ¦ that was a trainee for a system integrator that was, uh, doing DDI purely. Nothing else. Or IPAM, sorry, back then it was IPAM, right? Um, and he was like, βYeah, if theyβ¦ if they canβt hire you, uh, maybe just send us your CV.β And, um, two weeks later, um, I was hired, and I moved from the guy that was coming to the office, uh, whenever he wanted to, uh, do some stuff on data center machines and getting stuff done with monitoring and, uh, backups and you name it. I moved right into the industry of being a consultant for DNS and DHCP. So at the first couple of weeks, I had to read a lot of books, and some of them are still behind me. If you look at the recording onβ¦ later on on YouTube, for example, you can see these books, and some of them are back from these days. And yeah, and itβs aβ¦ itβs a small niche, and uh, Iβm in that niche since 16 years now, and it looks like that Iβ¦ itβs the only thing I can do. I canβt do anything else.
(09:53 - 14:23)
David Redekop: Well, it is a fun space because it is not one where you could implement something and offered a solution and have everybody adopt it. Itβs not like itβs got the lifecycle of a computer that may be anywhere between three to eight or nine years at theβ¦ the outside that eventually gets caught up with a modern operating system. Like, I donβt think Windows 95, for example, or even Windows 2000 can do anything online anymore because itβs so deprecated. However, I, for example, know personally of a Fortune 50 company in Canada that still operates on publicly usedβ¦ on public space as private space because somebody years ago read Hitchhikerβs Guide to the Galaxy and thought that, βOh, since 42 isnβt in use, weβre just going to use 42 dot for our entire enterprise.β And so when you start doing that and then you start statically assigning everything from gateways to switches, there is no refresh cycle of IP addressing because you might replace hardware in the regular lifecycle, but youβre going to adopt the old address schema. And so this is now going on, I want to say, about 15 years thatβ¦ that theyβve been on a re-addressing project. So in effect, theyβre using a proper RFC1918 today in parallel to the old one, but anytime we try to completely remove the old one as an alias on gateways, we still find stuff that breaks, right? And so IP address management, you might think of it as youβ¦ or DDI as something that as niche as it is, the more niche it is, the more you know fixed it should be. And yet it goes back so far. And so unless you have someone like yourself that really understands the IP addressing history of any organization, a lot of things donβt make sense. So in aβ¦ a new person thatβs responsible for infrastructure that has experience can basically, uh, determine what might have happened in the past in order for us to arrive at this stage. Iβm not sure if you have similar stories.
Andreas Taudte: Oh yeah. Yeah, definitely. In many cases, the network team that is responsible for these core network services, DNS, DHCP, and the IP address management on top of it, they havenβt built it themselves. They inherited it from somebody. It happens very rarely that an infrastructure like this is managed by somebody who built it back then. And just during anβ¦ an event that I attended thisβ¦ this week, I met again with a person that is responsible for the, uh, DNS and DHCP infrastructure of a huge car manufacturer since nearly 30 years, and now heβs retiring. So he knows every single server and zone, and I guess he even knows every record personally, something like that. So thatβ¦ thatβsβ¦ thatβs very rare that you have somebody that isβ¦ that knows an infrastructure like this in and out. Andβ¦ and hopefully they make a proper offboarding so that theβ¦ the new team has a chance to, yeah, get as much information out of his brain as possible. And this isβ¦ this is happening in my industry at the moment more often, that you see people that are responsible in organizations for these services since 20 years, 25 years, or in that case, nearly 30 years, and they are retiring. And yeah, maybe they willβ¦ they will come to the office once a week for half a day to get some extraβ¦ extra income. So they are notβ¦ not completely gone. But, uh, for everything that is related to daily tasks and troubleshooting and stuff like that, and especially with DNS, you canβt wait till Friday afternoon when the old guy comes into the office to troubleshoot an issue in DNS. Thatβs not possible. So this is happening, uh, very, very frequently, uh, right now. So sinceβ¦ since one or two years, I see stuff like this happening more often. And yeah, if you are the new guy, maybe somebody that just finished university, somebody that grew up with, uh, with an iPad and internet in every coffee storeβ¦ Yeah, that can be challenging.
(14:24 - 23:38)
David Redekop: Absolutely. You must have some stories that you can tell even if you donβt identify the guilty. But whatβs like the worst horror story where youβve walked into where there is some kind of a conflict whether or misconfiguration in the area of DDI?
Andreas Taudte: The short answer would be, um, every time. Umβ¦ No, butβ¦ but, um, toβ¦ yeah, um, I always just try to be the, uh, the advocate for these teams, uh, because then theβ¦ the real issue is that it has been there since ever. So DNS and DHCP was running in an organization since ever, as alreadyβ¦ as I already mentioned, it was, uh, created, uh, designed and built many, many years ago. And in a lot of implementations, itβs just a checkbox. If you take a look at the Windows box for example, yeah, itβs a checkbox in the server manager and ta-da, you got a DNS server. Yeah, itβs, uh, itβs running and itβs doing its job, so itβ¦ it donβt has the attention that it should have. And in most cases, itβs not that you have a dedicated team or person that is, uh, responsible for, uh, taking care of DNS and DHCP other than this guy that isβ¦ that that is doing this sinceβ¦ since 30 years. In many cases, it is just a, yeah, like a side hustle of the network team in addition to, yeah, the WAN and the LAN and the Wi-Fi and Voice over IP and security and you name it. So every time when I have a chance to meet with aβ¦ with a new organization, I try to do some kind of workshop to have a chance to really deep dive into their infrastructure. Because if you ask a client, βHey, what does your DNS and DHCP look like?β And they go to the whiteboard and they make some nice drawings, and this is just, uh, 80% of the truth. Sometimes not even half of it. But the remaining, uh, 20%, this is whereβ¦ yeah, theβ¦ you name it, hit the fan. So what I tried to do is I tried to get as deep as possible into an infrastructure. Um, and I even created over the last 15 or 16 years, I created a kind of workshop documents which is more or less something like a questionnaire. Itβs actually, itβs available on GitHub. Iβm not sure if we can add it to the podcast notes, um, afterwards. Maybe thatβs possible.
David Redekop: Absolutely. Yeah.
Andreas Taudte: Yeah. Happy to share that. So because if you ask more specific questions, you make the client think. They are just like, βOh yeah, wait a second. Yeah, you are right. We have something like this in this specific location because itβs something like that.β So stuff like that always happens when people like me in this niche walk into a huge organization with thousands or hundreds ofβ¦ of servers. Maybe some stories that are quite kind of funny. Um, so for example, many years ago Iβ¦ I installed a POC with aβ¦ with a customer, and we made a POC very close to the, uh, production environment. So that itβsβ¦ itβs not just a small lab where theyβ¦ where they were able to play around it. It was a proper POC. And back then, um, the DDI tools started to add dashboards to their web interface where you have some statistics like memory usage, CPU usage, or some statistics from DNS and DHCP. And there is a very basic statistic, uh, available in ISC BIND which is in most cases the underlying DNS server in the DDI tools. And it has something like, okay, how many NXDOMAIN, uh, responses do you have? How many SERVFAIL responses do you have? And in this specific case, we were running this POC for a week or two, and then we had something like 75, 76 percentage was NXDOMAIN, uh, responses. So which means that the majority of responses in their DNS were responses answered with βnot existing.β And that helped us to identify some, u, misconfigured systems that they distributed all over their locations. So it was nothing like a DNS tunnel or some control plane of a command and control center or something like that. Back then it was just a misconfiguration, and we were able to identify that, which dropped the load on the DNS servers heavily because these boxes were causing a lot ofβ¦ of CPU, uh, usage and memory usage. So this is something that was an easy fix.
Andreas Taudte: Another one was also was more related to letβs say theβ¦ the organization behind anβ¦ in DDI tool because many organizations think that they can just buy a fancy appliance or XYZ as a service and ta-da, they have a security deal in DHCP, and thatβs not the case. And in this specific scenario, it was an official reference customer of a huge DDI vendor, and they were even when they had some regional meetings with other customers. They were even on stage presenting their solution and stuff like that. And I know them since more than 10 years. Actually, I designed the DDI infrastructure back then. And years later, we made a security assessment of the infrastructure. And we identified that they have user accounts that no longer belong to the network team. And we try to identify what these user accounts are. And the story behind that is when they have a trainee in the organization, they are moving from department to department. So they are in the network team for a couple of weeks and then they go to the security team, then they go to the development, then they go to the support. So they during theirβ¦ their time over approximately 3 years being a trainee in this organization, they have some weeks or months in every single department. And when they join the department in the network team, they have anβ¦ they get an account in the DDI tool, and because they hadβ¦ they should somehow support the rest of the team, they have an admin account. So they have full control over the system. And maybe they finish their time being a trainee and then they become an employeeβ¦ employee, and then they move into the support department or they stay with the developers. They have the same account in Active Directory like they had when they were a trainee, and nobody ever refuted the access rights. So somebody belonging to the dev team has full access to the core network services or the management platform of the core network services for DNS and DHCP of a global organization. And this is not really related to DNS and DHCP security per se. Itβs related to, yeah, ownership responsibilities, rules, policies that come on top of that. So these areβ¦ these are two funny stories that Iβ¦ I recall from the past couple of years, and there are much more. So if weβ¦ Iβm happy toβ¦ to have some beers with you in the future. Uh, we canβ¦ we can deep dive into many, many more stories like that.
David Redekop: Iβm sure thereβs no shortage of situations where the principle of least privilege was just never registered because you donβt need the principle of least privilege in any new business to drive up topline. You donβt need it in order to drive down costs. In fact, itβll do the opposite sometimes. You donβt need it to create a, you know, leading edge status even as a software company. But so many proactively secure methodologies actually require a commitment and a conscientious effort because of the risk of not doing so can have such a large impact. Right? And so if there was ever an incident in an organization like that and someone looked at doing proper root cause analysis, itβd be like, βWell, why did that compromised account have those admin privileges that were not necessary?β
Andreas Taudte: Yeah, thatβsβ¦ thatβs a story that we see over and over again. And we keep on bringing up the theme that an attacker just needs to find very often for each stage of the attack just one weakness. Whatβs the next one weakness that I can exploit? And that happens to be one of them.
(23:39 - 25:07)
Andreas Taudte: Yeah, thatβs the issue withβ¦ thatβsβ¦ thatβsβ¦ thatβs related to DNS specifically, but also to the entire DDI infrastructure at an organization because itβs something like anβ¦ anβ¦ an intersection between different areas. So it covers network, you have cloud, you have security, you have operations. And in many organizations, when the organization is big enough, these different flavors are different departments and they are even sometimes separated into subdivisions and things like that. So when maybe when a potential attacker would like to slip through the detection mechanisms that they have in place, if I have four different departments that are more or less responsible for things that are related to DNS, DHCP, and computers management and maybe they have their own tools or they donβt talk to each other or theyβ¦ they just meet twice a year to have some kind of recap of the year meeting, stuff like that. So if each organization only sees a small portion of the entire DDI world of that specific organization, itβs much easier for an attacker to slip through the potential detection mechanisms that each of these individual departments have in place.
David Redekop: Right. Wow. I am really wondering how many organizations, if thereβs even such information available of what the attack surface is like in this boring network plumbing area of DDI. Thatβs how itβs often seen. Like it doesnβt get the very cool marketing fluff on any product. Like no one goes out and brags about their DDI security posture. In fact, Iβve never seen those three words strung together, right? Because it would be super uninteresting for anybody thatβs a potential investor or someone thatβs looking at, you know, what is your overall revenue versus cost model? Whatβs your gross margin? Theyβre not interested in those boring behind the scenes unless they are in the world of proper risk assessment and making infrastructure long-term sustainable. We could definitely spend some time analyzing that, and Iβm wondering if an organizations of analysts have any insight into how big the problem might be because what I notice is that the way attackers are growing their capabilities is they are looking for areas that are not yet addressed. So if we donβt have a broad approach to securing a particular area, then the organized adversaries can basically hone in on that, and you can see that theyβre definitely thinking about whatβs our next area of attack and thereβsβ¦ this might be an area that they can still focus on.
(25:08 - 29:45)
Andreas Taudte: Yeah, thatβsβ¦ thatβsβ¦ thatβs right. Thatβs right. Based on my experience in this field, itβs getting better. Um, I would say so especially in the last couple of years theβ¦ the awareness that DNS, uh, isβ¦ is a critical service, that it can be attacked easily, and also that it can beβ¦ can be used as a transport for some malicious things and behaviors and stuff like that. Um, so itβs getting better. With regards to IP address management, the βIβ in DDI, I have seen improvements in the past as well. So inβ¦ especially with regards to integrations into third-party systems. So theβ¦ the DDI vendors realize that nobody is buying a DDI tool to live on its own. Itβs part of anβ¦ of an ecosystem. It has systems on the left hand side, on the right hand side that could benefit from the information that is within the database. And on the other side, the IPAM system itself can benefit from information that the other tools store and collect. For example, one thing, um, that is, uh, overseen more often is theβ¦ the second βDβ. Um, itβs DHCP. Um, and somebodyβ¦ somebody called it the βSandwich Kid.β Iβm not sure if youβ¦ if you are familiar with that phrase or the sandwich kit. So if you have three kids, you have the oldest one and you have the youngest one and then you have the one in the middle. That isβ¦
David Redekop: Yeah, itβs always the one in the middle. Yeah, thereβsβ¦ thereβs thisβ¦ thatβs good.
Andreas Taudte: Thereβs this show, um, Malcolm in the Middle. Itβs an older one. Not sure if youβ¦ if youβ¦ if you know that, um, and heβsβ¦ heβs some kind of sandwich kid. And DHCP is exactly the same. So itβs whenβ¦ whenβ¦ when a company is not taking much care about DNS, then you can be sure that DHCP is completely under the radar. And it gives you so much useful information because itβs linking a device to an IP address. You have some timestamps, and in within a DHCP package, you can identify specific things like you can easily, uh, differentiate between a Windows box and a printer. And this is very, very value information. And if you just look at your IP address management database and you have the information that, βOh, thereβs a suspicious client because in that network there shouldnβt be a printer. Why is there a printer?β It could just be something like a misconfigured or misplaced, uh, machine or maybe an attacker that is faking a MAC address that somehow or belongs to an area where printers are typically located. Uh, so stuff like that. So itβs getting better, and if you look at various letβs say, yeah, rules and compliance policies and stuff like that, justβ¦ just recently, um, a new version of this, uh, guidance fromβ¦ fromβ¦ from NIST came out. Um, the first one that is, I guess itβs always 10 years ago when they wrote the first document about DNS security, it was more related to DNSSEC. So, uh, signing and validating DNS answers or responses. And theβ¦ the new version really addresses more specific things related to DNS security. So itβs getting better, and it actually, it can happen when you are an insurance organization or a bank or something like that, that some external audit happens once in a while and they will ask you stuff like, βOkay, who has access to DNS and do you have an audit trail of things that change in DNS? Do you have something like a two-man rule thatβ¦ that is, uh, in place for critical records like, yeah, maybe you can just change the record of a printer but you canβt change the record of an SAP system, for example, stuff like that.β So itβsβ¦ the awareness S is a raise in awareness. But of course, in many cases, I come to organizations that have thousands or hundreds of domain controllers running some Active Directory integrated DNS, and the IP documentation is a spreadsheet that is stored on a share drive. This is still the case, and from my perspective, itβs really impressive to see that a massive organization with limited resources to people and money is able to manage such a complex infrastructure with some core services running as just some built-in, uh, implementation and some spreadsheets orβ¦ or Wikipedia or intranet sites. Itβs very impressive that they are able to manage it. Itβsβ¦ from my point of view, itβsβ¦ it would make their life much easier. But Iβm always impressed how stable these networks work with banks, car manufacturers, retailers, universities all over the place.
(29:46 - 33:32)
David Redekop: It is so true. I am constantly marveling at the exact same thing. Why is it that it works? But it works because thereβs human attention to it, and itβs because weβve always done it this way. That is the reason weβre hesitant to change. And someone started at some point to track it in an Excel spreadsheet and it stayed there. Some of them are proud that theyβve moved it to Google Sheet so that they can now share it better, and thatβsβ¦ thatβs already a step forward. But no, Iβ¦ I like the idea of Infrastructure as Code being applied to network configuration because it really only makes sense to do those fundamental things properly from first principles. And then from then on, you have the best possible long-term value by doing things right from the base layer up. Itβs justβ¦ itβs like that with every other industry. Itβs like that with construction. If you donβt have a properβ¦ in our part of the world, we have basements, right? So before you build a house, you always have to dig a hole and then youβre putting proper concrete as your foundation, both as the floor and as the walls. And now anything you build on top of that is going to have aβ¦ a lifespan of maybe not thousands of years like some buildings used to be constructed, but at least, you know, 50, 70, maybe 100 years with a proper foundation. And itβs amazing that we donβt translate that back to networks because if you set up a business, if you set up a network, chances are that itβs going to be around a long time. It is worth it to just build that foundation properly.
Andreas Taudte: Yeah. And then nothingβ¦ nothing consists longer than a temporary solution. So something like, βOh yeah, yeah, we had just created this asβ¦ as a draft,β and then, uh, 12 years later the draft is still used by the majority of the infrastructure. But yeah, this picture of a, um, of a building is actually something that Iβ¦ that I used in a, um, in a presentation many years ago where I tried toβ¦ to highlight to, uh, letβs say the IT management, uh, layer that when they are talking about zero trust and digitalization and artificial intelligence and you name it. They are already talking about the decoration of the balcony on the second floor, but they havenβt started with the foundation yet. Uh, maybe itβs there, but maybe itβs somehow rotten. Maybe you have someβ¦ some water, some groundwater that isβ¦ thatβ¦ that is coming through the walls and stuff like that. So getting a proper foundation isβ¦ is necessary. All the other topics on the balconies, they are very, very relevant for sure. Definitely, we are living inβ¦ in very, very modern worlds where your fridge is able toβ¦ to communicate with the internet to order milk and stuff like that. So we have completely different challenges. So things likeβ¦ like zero trust and others inβ¦ in that area absolutely relevant and they have to be on the agenda. But, um, what I see more often is that thereβs a new buzzword every year and then theβ¦ theβ¦ theβ¦ the management layer, the IT organization is following this specific password and they still are running with a spreadsheet and some Microsoft based DNS inβ¦ inβ¦ in theβ¦ in the backyard.
David Redekop: Yeah. I mean, and there is value in some buzzwords because if the buzzword gains, uh, awareness and popularity, then at least the C-suite or whoever upper management happens to be in an organization can ask, βHow are we doing in this buzzword?β Right? And get some accountability. But yeah, generally when that is the only area ofβ¦ of response, itβsβ¦ itβs not sufficient.
(33:33 - 39:27)
David Redekop: Letβs, uh, switch for a moment to the marketing term βzero trustβ that I donβt really like, but only because it is a buzzword thatβs overused 'cause everyoneβs zero trust and AI everything. It reallyβ¦ it really burns those of us that have been working in that space long before those terms even existed andβ¦ and applied those technologies. But in our process of doing the default deny all, to me thatβs aβ¦ a more technically accurate, uh, description. When we do default deny all, we basically treat every destination IP address as a stranger until it is not. And the way it is not a stranger is that the DNS query was made, matched to a policy, and then a protective resolver said βThatβs safe and here it is,β and the policy engine says, βYes, youβre allowed to go there.β Right. So thatβ¦ that processβ¦ And you pointed out when I chatted with you about, I found it really quite intriguing because I had not seen that one particular threat before where attackers can actually utilize the serial number of the Start of Authority record and map it such that it maps back to an IPv4 address. Tell us more about that.
Andreas Taudte: This is actually something that I just saw at a, um, at another webinar and I guess it was some guy from Infoblox from, I guess, Poland or Czech Republic. Heβ¦ he made theβ¦ theβ¦ the original presentation where I saw that first, and I immediately tested it and it just worked. And I used it, uh, during, um, an event that I attended recently to demonstrate how easy you can put stuff into DNS. And if itβs not observed properly then, yeah, you can justβ¦ And the funβ¦ the funny thing is you donβt even have to recalculate the serial number into an IP address. When you use ping on your command line for example, you can ping a serial number because itβs just 32 bits. So that means you donβt have to recalculate it and add some dots between the octets. You can just ping it. It just works. And itβs something that isβ¦ itβs always funny and scary at the same time what you can do with DNS. Um, thereβsβ¦ thereβs aβ¦ a collection that, um, a guy called Peter Lowe isβ¦ is collecting since many years. So itβs some funny stuff that people do with DNS. So theyβ¦ they use it toβ¦ to, uh, stream MP3s for example. This is possible. So theyβ¦ they actuallyβ¦ theyβ¦ they store MP3s in public resolvers and they have a, on the other part of the world, they have the capability to read that and play music. So stuff like that is possible. Itβs something that is there since ever. Itβs a 40 plus year old protocol. And because of that, itβsβ¦ itβs like like inβ¦ like inβ¦ in our environment as well. So when youβ¦ when youβ¦ I guess you grew up when, um, a fridge was already available. Iβm pretty sure that when you came home there was a fridge in the apartment or in the house. Uh, so this is something that you are used to. So youβre not taking much attention to, yeah, how the fridge is behaving, what, um, energy it is consuming. Is it clean for example? Is itβ¦ is it cleaned more often? Uh, so to avoid some bacterials and stuff like that because it had always been there. There was food in it all the time. So youβre not taking much attention to bringing much attention to it. And itβs the same with, uh, withβ¦ with DNS and especially when the team that is maintaining, um, the DNS infrastructure just inherited from somebody else that is no longer with the company.
David Redekop: Yeah, itβ¦ it works and thereβsβ¦ thereβs this very, very valuable phrase that βnever touch a running system,β which it has someβ¦ some relevance of course. So if itβs working donβt touch it, but, um, just because itβs a broken doesnβt mean itβs working. Right. Right. Yeah. You mentioned Peter Lowe, and he was actually, uh, the one who introduced me to DNS.toys. Iβm not even sure if .toys is a valid TLD domain, but whoever runs that, Iβd like to give them credit because thereβs a really cool stuff. I actually created a conditional forwarding rule on my network because thereβs like really cool things that you can do like get a command line quick report of the weather in your area. So thatβsβ¦ thatβs not an example.
Andreas Taudte: Yeah, of course.
David Redekop: Yeah. Yeah. Really, really very cool. But anyway, when you pointed that thread out to me, I thought I need to really figure out, you know, how this works. And I was very excited to have the same emotion repeat when we see a new threat that we havenβt seen before. How does this whole approach of default deny all or what we call βdonβt talk to strangersββ¦ Microsoft, by the way, at Ignite now announced general availability of the Microsoft zero trust DNS which does that same approach on Windows 11 Enterprise or Windows 11 Pro Education. Um, itβs available as long as the device is enrolled in mobile device management. You can basically push a DoH profile to the Windows endpoint and then have that Windows endpoint use that DoH service only and then it integrates with the Windows filtering, uh, platform to basically apply the same thing to Windows endpoint. And so weβre excited because finally weβre not the only ones in the world that are saying this is the way to do egress control and proper default deny all.
(39:28 - 44:21)
David Redekop: But back to the threat that you pointed out to me that Infoblox had shared with the serial number trick, it was good to know that that was not a way for an attacker to get out. But at the around the same time is when we saw more and more, uh, report around, uh, TXT record abuse by attackers. What have you come across in that space in the TXT record abuse area?
Andreas Taudte: Itβs not only theβ¦ the TXT isβ¦ is used very often because you can store a lot of information inβ¦ in a TXT record, but there are other record types that are not really recognized by some letβs say DNS analytics tools. So for example, inβ¦ in many other devices or infrastructure devices inβ¦ in a network like firewalls and you name it. Meanwhile, they also joined this track of a DNS security. So they have something available. But justβ¦ just recently I learned that in many cases they are able to validate A records, AAAA records, PTR records, but if it comes to other record types like TXT for example but also HINFO or thereβs a record type called SINK, uh, which was originally planned to be the record type for everything else that is not an address or a name. So when it comes toβ¦ to stuff like that that is handled by every DNS server on the planet correctly but a firewall for example that has some inspection related to DNS ignores it because it has nothing. It canβt comprehend what this TXT record or HINFO, uh, record actually means and what it should look like or what it shouldnβt look like and stuff like that. So it just passes through as a standard DNS for example. So this isβ¦ this is stuff that you see quite often inβ¦ in letβs say everything that is related to tunneling.
David Redekop: Yes.
Andreas Taudte: Through a DNS protocol. So tunneling, um, is used for different flavors. So you can use it for data exfiltration which means that you try to stay hidden in the network as long as possible because youβre using DNS. So we are not talking about a something like a fiber connection. So, but if you are in the network long enough, um, and if you can extract, uh, data slowly via a DNS tunnel, of course, if you have aβ¦ an export of aβ¦ of a table from a customer database that contains credit cards, you donβt need many gigabytes. Um, if you have 100β¦ 100 credit cards, um, thatβs more than enough, I would say. Itβs also used for, um, command and control which means that if you have an affected, uh, device that needs some more information or some more data from the command and control center that is outside of the organization that, uh, was compromised, then a DNS tunnel is used as well, but in that case itβs used bidirectional so itβs not just to get data out itβs also to get information in.
David Redekop: Yes.
Andreas Taudte: So and itβs itβs not only TXT records. Um, they use A records, AAAA records and other record types as well. And very, very modern, uh, DNS tunnel techniques, they even use combinations so to make it harder to get, uh, detected. So theyβ¦ they identify, for example, the different DNS servers in an infrastructure and coming back to theβ¦ to the scenario where you have domain controllers. Um, how easy it is to find out the domain controllers in an infrastructure is you can just query the DNS name of theβ¦ of the domain and then you get a list, um, of all the domain controllers thatβs built in and then you have letβs say 20 different, uh, domain controllers that talk DNS and in many cases they can resolve internet names as well and then meanwhile these tunnels are so, uh, intelligent that they first they use different types record types. So some data isβ¦ is transferred via TXT, some is transferred via, umβ¦ um, A records, and some is even transferred via SOA record and stuff like that. And then they switch the timings. So itβs not like that they just hammer the DNS server withβ¦ with queries. They have some delays in between and they change the delay. So maybe they wait a second before the next package and then they wait two milliseconds for the next package and then they wait 5 minutes and then they even switch the resolver. So they maybe they start, uh, the tunnel on the domain controller number one, use some different, uh, delay, some different records, and after a while they switch to another domain controller. So that makes it harder to, um, identify such a tunnel because you canβt identify a tunnel by the first package. You need some packageβ¦ packages to identify okay this looks suspicious. This seems to be a tunnel. But if you are spreading this over different DNS servers in the infrastructure and you just look at one specific DNS loβ¦ lock of one specific server, itβs very hard to identify okay this is a part of a tunnel. So you really have to collect query and response logs from all these servers, bring them into one place and there you can identify βOkay, it looks like that this specific client has established a tunnel that is using various flavors of records, different delays between queries, and is using 10, 15 different DNS servers to get the data out or in.β
David Redekop: Wow. There is clearly a tremendous amount of effort in looking for evasion techniques by the threat actors for them to make all of the complex DNS evasion possible that youβve just described. I just marvel at it and that just confirms with me over and over again when I hear how complex threats can be, um, that the only approach that a defender has in the long term is to take a default deny all approach, hijack all non-authorized DNS servers, and basically have a deterministic policy approach that ensures that you know even down to record types. Weβve only recently introduced the idea of record type blocking on a per policy basis because for example the NULL and PRIVATE record types and TXT record types are not used by our everyday devices. Soβ¦ so the devices that user devices are laptops, computers and smartphones, they donβt need to use those record types. They only need A and AAAA typically. And so that approach hopefully willβ¦ will keep us in a stronger defensive space, you know, before, you know, uh, someoneβs at risk. 'Cuz I always thrive with the idea that a managed SOC gets an alert that says, βHere was a threat. It was mitigated before any damage could get done.β But we should investigate how that, you know, malware or how that fileless threat got into the network to begin with. But itβs such a thrill as a defender when you see that the work that you did in advance actually stopped the attackers at the, you know, second, third, fourth, fifth step of the attack chain. And, uh, that thrill is what drives us to look for the next defensive technique.
(44:22 - 51:33)
David Redekop: But balancing it at the same time with not creating user frustration. Right? So how do you have principle of least privilege not become principle of least aggravation? Uh, you know from userβs point of viewβ¦
Andreas Taudte: Thatβsβ¦ thatβsβ¦ thatβs a difficult one. So from my point of view, um, organizations they should just combine everything. Of course, uh, itβsβ¦ itβsβ¦ itβs great that vendors of operating systems inβ¦ inβ¦ included capabilities like zero trust DNS for example, this is great. In many organizations, of course, the majority of, uh, of employees are sitting in front of a Windows box. Yes, itβs itβ¦ thatβs whatβ¦ what what I see when Iβ¦ when I visit, um, organizations. But of course, you still have, um, thisβ¦ this fridge in the coffee kitchen. And, um, in the last couple of years, I had a chance to work with these massive organizations that are producing stuff like cars and others. And here, uh, you have different challenges like you have anβ¦ a robot that is running in a factory that was bought 20 years ago and it has some DNS server hardcoded into the mainboard and this thing still has to run for the next 10 years before it produced enough cars to buy a new robot, something like that. This is the typical calculation that companies like that like this flavor, uh, do. So even that you have something like zero trust DNS that is available for the operating system for the people in the office. Yeah, you will see a lot of machines, uh, talking IP and using DNS that are far away from having something like zero trust DNS installed per default. So even just something like a simple response policy zone that is just filtering all the already known bad guys is still useful. And donβt only enable stuff like this on your DNS server. Of course, every communication in the network starts with a DNS query and a response. So A canβt talk to B other you have some hard-coded IP addresses in some config files. And even that is the case in some of these factories for example. But in addition to this, yeah, if your firewall has a DNS security feature and itβs part of your subscription, which is always important to validate, yeah, just enable it. And if you have some some other, uh, infrastructural devices that can do stuff with or that can review stuff that is in your DNS in your DHCP justβ¦ just use it. And something that isβ¦ that isβ¦ that isβ¦ that is quite old but still relevant is stuff like like NetFlow for example. This is something that, uh, many people, uh, are not aware of because itβsβ¦ itβs quite old. Um, and Iβm not sure if this is even taught on, uh, inβ¦ in universities or schools that something like NetFlow exists and this gives you, uh, very good, uh, visibility.
Andreas Taudte: So just enable it all. Security is an onion and you have to add, uh, one layer. Um, and if you have multiple layers that cover DNS, the chance that you are in aβ¦ in a good, uh, shape is much better, uh, compared to just use one thing. Just for example have a cloud security solution that filters all your DNS traffic before it hits the the internet which is good but if you have some suspicious, uh, DNS communication within your network, everything that is is not leaving your DNS infrastructure isβ¦ can still be a threat. So if you have different network areas, so some high security network areas and some other network areas that are less secure and somebody would like to access something in another security area and the policy is doesnβt allow that but there are DNS servers in between you have your East-West communication in your DNS infrastructure that is also able to create some kind of DNS tunnel for example. And if you filter your suspicious DNS queries only at the edge before itβ¦ it leaves yourβ¦ your infrastructureβ¦ Maybe you are missing a huge portion of DNS that can have some suspicious behavior as well.
David Redekop: You just reminded me how important it is for teams in their area of knowledge to be open to what they need to be aware of from other teams. Sometimes if we talk to a network team about aβ¦ a necessary change that the security team requires, thereβs resistance there and usually the resistance comes from lack of awareness of what the security impact is. And so thereβs lots of value for security teams to become more network aware, for the network teams to become more security aware, for the application teams, the apps to understand more about network and security because the space is quite deep and all we need to think about is reflect upon what you just shared around the various, uh, attack techniques.
Andreas Taudte: Yeah, definitely.
(51:34 - 55:54)
David Redekop: I have not even gotten to a single one of my questions on my, uh, document here, Andrea. So, I think thatβs a good thing and thatβs okay. But there is one question that I always have to ask 'cuz I know for you itβs Friday afternoon. Itβs allβ¦ itβs already getting dark or has already gotten dark during this call. You probably want to get together with family. Uh so, Iβm not going to keep you much longer, but I always like to ask, is there one piece of advice or wisdom that you would like the world to know?
Andreas Taudte: One advice that I try to give all my, uh, clients, um, customers, prospects is DNS resolution should be predictable. So as aβ¦ as a network team that is responsible for the DNS infrastructure, when a specific client in a specific location sends a query for a specific name, the team has to be able to predict what path the query takes and where the response is coming from and what filters or policies are applied, um, during this process. If you arenβt able to do that, Iβm not for 100% of course we have infrastructures that are quite complicated but if you are not aware if, uh, a client in location A wants to resolve www.example.com and a client in another location is doing the same and you donβt know where the answer at the end, uh, is coming from, then you really have to start an assessment for your DNS infrastructure. This is the from my point of view theβ¦ the minimum criteria. You need to understand your DNS infrastructure enough to make predictions like that. There are some cases where you canβt predict stuff like that, especially when it comes toβ¦ to policies and some compliance capabilities areβ¦ are involved of course. But if something is resolving host123.company.corp, the team should be able to identify what resolver is used. Is this resolver equipped with some RPI zones or some other threat intelligence? Where is this query forwarded to? And where is the authoritative DNS server located that provides the answer? Is it a secondary? Is it a primary? Is it talking to a hidden primary, for example? Or is it within the same location? Is it in the same region? Are there some GeoIP things involved so that a client on location A gets a different IP address than a client in location B for exactly the same query? So this is an advice that I try to share withβ¦ with all my clients and then we try to identify how good they are in that specific case.
David Redekop: That really hits very close to home. But you just said RPZ and I just want to say thank you. I know the world of internet is US-centric where itβs RPZ, right? But, uh, the Canadians and the Brits, we like the βZed.β But no. Okay. So now you just gave me another reason for us to reconnect because we built a sort of informal way of gauging a scorecard on DNS resilience on the inside of infrastructure. So weβre not talking about the authoritative or public resolver side, but on the inside of a network. And then Iβ¦ and I think if we get this right, we might just have to come up with a new slogan. βIt was never DNS.β Because if you get 100% resilience, it was never DNS. That would be kind of cool.
Andreas Taudte: Thatβs right. And when youβ¦ when you justβ¦ just recap the recent issues, DNS wasβ¦ was doing great. It was just the management on top of DNS. That was some kind ofβ¦
David Redekop: Yes.
Andreas Taudte: So itβsβ¦ itβs exactlyβ¦
David Redekop: Like there was no DNS protocol patch. There was no ISC BIND patch that needed to come out, right? It was the data source. Yeah. But that nuance probably never left, you know, the people that really were truly interested at the actual root cause. But yeah.
Andreas Taudte: Yeah, thatβs right.
(55:55 - End)
David Redekop: Andreas Taudte, itβs been a real pleasure chatting with you. Thank you for your time today. Weβll, uh, connect again and look forward to seeing you again as well.
Andreas Taudte: Yeah, many thanks for taking your time and Iβm looking forward to another episode even without me. Justβ¦ justβ¦ just, uh, uh, listening to all the stuff that you, uh, collected was great and I will continue to follow these episodes and yeah.
David Redekop: Well you definitely not only, um, met the bar but you allowed the quality and a sense of comfort. Thereβs a guy on, on, uh, social media that was evaluating a ton of, uh, cyber security podcasts. Heβs in a position of a CISO and he gave this podcast a C-minus and, uh, I thought, βOkay.β Well, I mean it was subjective because he basically said itβs just not for me andβ¦ and I understand that but I look at information like that and say what can I do better? And I realized at that moment that I personally need to be more relaxed and more connected and so I am now a little bit more relaxed than I was at that time. Anyway, weβll leave it at that for today and, uh, weβre looking forward to connecting with you again real soon. Take care.
Andreas Taudte: Okay. Looking forward to that. Hey, thanks. Take care. Bye-bye.
Voiceover: The defenderβs log requires more than a conversation. It takes action, research, and collective wisdom. If todayβs episode resonated with you, weβd love to hear your insights. Join the conversation and help us shape the future together. Weβll be back with more stories, strategies, and real-world solutions that are making a difference for everyone. In the meantime, be sure to subscribe, rate, write a review, and share it with someone you think would benefit from it, too. Thanks for listening, and weβll see you on the next episode.
1 post - 1 participant
The post TDL 011 | The Hidden Layer of Cybersecurity: Andreas Taudte on DNS & DDI Defense appeared first on Security Boulevard.
MCP is transforming AI agent connectivity, but authentication is the critical gap. Learn about Shadow IT risks, enterprise requirements, and solutions.
The post What Tech Leaders Need to Know About MCP Authentication in 2025 appeared first on Security Boulevard.
In a nod to the evolving threat landscape that comes with cloud computing and AI and the growing supply chain threats, Microsoft is broadening its bug bounty program to reward researchers who uncover threats to its users that come from third-party code, like commercial and open source software,
The post Microsoft Expands its Bug Bounty Program to Include Third-Party Code appeared first on Security Boulevard.
Israeli cybersecurity firms raised $4.4B in 2025 as funding rounds jumped 46%. Record seed and Series A activity signals a maturing, globally dominant cyber ecosystem.
The post Funding of Israeli Cybersecurity Soars to Record LevelsΒ appeared first on Security Boulevard.
OpenAI warns that frontier AI models could escalate cyber threats, including zero-day exploits. Defense-in-depth, monitoring, and AI security by design are now essential.
The post As Capabilities Advance Quickly OpenAI Warns of High Cybersecurity Risk of Future AI ModelsΒ Β appeared first on Security Boulevard.
CVE-2025-55183, CVE-2025-55184, and CVE-2025-67779 require immediate attention
The post Three New React Vulnerabilities Surface on the Heels of React2Shell appeared first on Security Boulevard.
The NCSC warns prompt injection is fundamentally different from SQL injection. Organizations must shift from prevention to impact reduction and defense-in-depth for LLM security.
The post Prompt Injection Canβt Be Fully Mitigated, NCSC Says Reduce Impact InsteadΒ appeared first on Security Boulevard.
To transform cyber risk into economic advantage,Β leaders must treat cyber as a board-level business riskΒ andΒ rehearse cross-border incidents with partnersΒ toΒ build trust.Β
The post Cyber Risk is Business Risk: Embedding Resilience into Corporate StrategyΒ appeared first on Security Boulevard.
The promise of personal AI assistants rests on a dangerous assumption: that we can trust systems we havenβt made trustworthy. We canβt. And todayβs versions are failing us in predictable ways: pushing us to do things against our own best interests, gaslighting us with doubt about things we are or that we know, and being unable to distinguish between who we are and who we have been. They struggle with incomplete, inaccurate, and partial context: with no standard way to move toward accuracy, no mechanism to correct sources of error, and no accountability when wrong information leads to bad decisions...
The post Building Trustworthy AI Agents appeared first on Security Boulevard.
A significant portion of cyber breaches begin with one simple issue: weak passwords. With modern cracking tools capable of testing billions of combinations per second, many passwords that users consider βstrongβ can be compromised in minutes β sometimes even faster.This makes password strength an important factor in safeguarding personal information, business systems, and sensitive data [β¦]
The post How Secure Is Your Password? It Could Be Cracked Within an Hour first appeared on StrongBox IT.
The post How Secure Is Your Password? It Could Be Cracked Within an Hour appeared first on Security Boulevard.
As they work to fend off the rapidly expanding number of attempts by threat actors to exploit the dangerous React2Shell vulnerability, security teams are learning of two new flaws in React Server Components that could lead to denial-of-service attacks or the exposure of source code.
The post React Fixes Two New RSC Flaws as Security Teams Deal with React2Shell appeared first on Security Boulevard.
Why Code Signing Isnβt Optional? If youβve ever tried running an unsigned app on macOS, you already know how brutal the experience is. You double-click your .app file, and that dreaded message appears: βThis app canβt be opened because itβs from an unidentified developer.β And thatβs it. Your user instantly loses trust. Your credibility? Gone.β¦ Read More How to Code Signing an Electron.js App for macOS?
The post How to Code Signing an Electron.js App for macOS? appeared first on SignMyCode - Resources.
The post How to Code Signing an Electron.js App for macOS? appeared first on Security Boulevard.
For years, compliance has been one of the most resource-intensive responsibilities for cybersecurity teams. Despite growing investments in tools, the day-to-day reality of compliance is still dominated by manual, duplicative tasks. Teams chase down screenshots, review spreadsheets, and cross-check logs, often spending weeks gathering information before an assessment or audit.
The post 3 Compliance Processes to Automate in 2026 appeared first on Security Boulevard.
Understand what PII is, why email puts it at risk, and how your business can strengthen security to better protect sensitive information.
The post PII in email: Explanation, risks, & protection appeared first on Security Boulevard.
Discover how AI strengthens cybersecurity by detecting anomalies, stopping zero-day and fileless attacks, and enhancing human analysts through automation.
The post AI Threat Detection: How Machines Spot What Humans Miss appeared first on Security Boulevard.
Login