Summary
From Offense to Defense: A CISO’s Evolving Challenge
In this episode of The Defenders Log, Joshua Domagowski, CISO of Astronomer, shares his journey from “playing around” on his dad’s computer to leading complex cybersecurity defense.
The Attacker’s Edge: Domagowski was initially drawn to the offensive side because of how “relatively easy it is to attack versus defend.” An attacker needs to find just one weakness, while defenders must safeguard every angle. This realization led him to pursue the more complex and crucial challenge of defense.
The CISO’s Evolving Role: Today, the job is an asymmetric warfare scenario. His time is split roughly 50/50 between proactive defense measures and responding to incidents. A top concern for him and many CISOs is the rapid adoption of AI and the challenge of balancing business velocity with safeguarding sensitive customer and internal data.
Untrusted Code and Zero Trust: A unique challenge for Astronomer, a data orchestration platform, is the execution of untrusted customer code on their infrastructure. This prevents standard InfoSec approaches. To mitigate risks like ransomware, Domagowski emphasizes a layered defense and Zero Trust architecture, prioritizing access to data over systems.
The Human Factor: Ultimately, cybersecurity is a human-made problem, and humility is key. Domagowski advises his younger self and other security professionals to practice clear communication and understand that other business units have their own priorities. He stresses that fixing broken processes is often a more effective path to efficiency than simply adding technology like AI.
Full episode of The Defender’s Log here:
TL;DR
Origin Story: Joshua Domagowski (CISO of Astronomer) moved from offensive computing (hacking his dad’s PC) to defense because the latter presented a more complex and worthwhile challenge (attackers need one flaw; defenders must secure all).
Key Defensive Philosophy: Cybersecurity is asymmetric warfare. Defenders must embrace an attacker mindset to build a strong posture.
Top CISO Challenges:
- AI Adoption: Balancing the speed of AI deployment with the need to safeguard sensitive data (customer/internal).
- Untrusted Code: A unique risk where his platform executes customer code, preventing standard network security approaches.
- Geopolitical/Compliance: Navigating complex and evolving regulations (e.g., US Cloud Act vs. EU Data Act).
Security Strategies: - Zero Trust Architecture (ZTA): Adopted as a fundamental building block to mitigate risks like ransomware by focusing on securing access to data rather than just systems.
- Anti-Ransomware: Relies on robust, well-tested Business Continuity and Disaster Recovery (BC/DR) plans.
Leadership & Culture: - Humility: Recognize that cyber is a human-made problem; failure is inevitable, but continuous improvement is key.
- Process First: Efficiency gains often come from fixing broken processes before adding new technology (like AI).
- Communication: Security leaders must be able to clearly articulate what’s at stake and appreciate the priorities of other business units.
Links
View it on YouTube: https://www.youtube.com/watch?v=LIAt17ih8R8
Listen to the episode on your favourite podcast platform:
Spotify
https://open.spotify.com/episode/4ojIc4rjIDeiHQdZWZ0s3K
ADAMnetworks
https://adamnet.works
The Defenders Log Podcast Transcript: Episode 10
Guest: Joshua Domagowski, CISO of Astronomer
Teaser
Joshua Domagowski: I always liked playing around on my dad’s computer, which he had for work, and he somehow believed that the games I was wanting to play on it were crashing his computer. Is there anything in particular that got you to recognize that going from the bad side to the good side was a worthwhile endeavor? So, I think it was really just how relatively easy it is to attack versus defend, right? When you’re an attacker, you only have to find, you know, one small area to kind of get in where I found I was able to do some things that maybe were not intended for computers. And then that created a growing interest in, well, how can I do that? and developed as a skill that we’re bringing to this.
Show Introduction
Announcer: You know, cyber is deep in the digital shadows where threats hide behind any random byte. A fearless crew of cybersecurity warriors guards the line between chaos and order. Their epic battles rarely spoken of until today. Welcome to the Defenders Log, where we crack open the secrets of top security chiefs, CISOs, and architects who faced the abyss and won. Here’s your host, David Redekop.
David Redekop: Welcome to another episode of the Defenders Log. This is episode number 10, and I’m really glad for Joshua Domagowski, the CISO of Astronomer, to join me today on this episode where we’re going to hopefully hear some defense or defender stories. Joshua, welcome.
Joshua Domagowski: Thank you, David. It’s a pleasure to be here.
From Gaming to Prevention: The Origin Story
David Redekop: I know that when it comes to aspects of technology, especially in the defense space, all of us have had some kind of a hobby or something that led into that. Were there any particular hobbies that got you started down this path?
Joshua Domagowski: I guess way back when I was a teenager, I always liked playing around on my dad’s computer, which he had for work, and he somehow believed that the games I was wanting to play on it were crashing his computers. It was quite restrictive on what I could do in that regard. So, it led me down a dark path of programming where I found I was able to do some things that maybe were not intended for computers. And then that created a growing interest in, well, how can I do that and developed as a skill, but then also how can I defend against that, and then that took me through the military. and I would say kind of in my final years while in the military, I really landed on the defense being far more important today.
David Redekop: Was there anything in particular that got you to recognize that going from the bad side to the good side was a worthwhile endeavor?
Joshua Domagowski: Um, so I think it was really just how relatively easy it is to attack versus defend, right? When you’re an attacker, you only have to find, you know, one small area to kind of get in. And when you’re defending, you’re having to defend against not only, I would say, you know, all of the different tax purpose area that you may have, but you also have a lot of other things that slow down the process, all the noise that comes into the systems that you’re monitoring, you know, and how you build the organization around being able to respond quickly to it with the necessary human technical skills and the technology as well. So, it was a much more complex problem that was, I think, also interesting in its own right than just being an attacker.
David Redekop: I’m in complete agreement with you on that front as well. I always find that it’s an asymmetric warfare scenario where the bad guys often just need to find the one weakness, but the good guys, the defenders have to find them all, defend them all. And so, but yet somehow it seems like the whole black hat or the whole adversary emulation has gotten more of the attention since the onset of social media, right? where there seems to be this coolness factor about being able to attack versus the boringness factor of being able to defend. And I’m hoping that we can turn that around and actually get those that have in the past found to be an attacker to take up that challenge to become a defender. So, I don’t know if you have any tips on how we can do that.
Joshua Domagowski: I think there’s definitely benefit in building an offensive skill set and experience because having an attacker mindset I think is critical for building a good defensive posture. And so I think there’s definitely an aspect of encouraging the the right development of that skill set and of that mentality and then being able to kind of show how that mindset when applied to defensive purposes can really help safeguard I would say much of today’s industry and even civilization because so much of what we have today rests on information systems and information technology, whether you’re talking about, you know, our grandparents or other related family or those that are less technical that rely on it in their day-to-day business encounters.
The CISO Role: Balancing Proactive vs. Reactive Measures
David Redekop: And would you say that in your role today that the bulk of your efforts and time is spent constantly looking on the defensive side and very little of it is actually applied to responding to incidents or how would you relate to the incidents of being proactive in the boring and thorough and you know absolutely covering every aspect versus actually spotting something that needs to be responded to.
Joshua Domagowski: I would say it varies. It tends to ebb and flow definitely. I think as we see different things trend for a variety of reasons whether it’s events that may be impacting the company externally, whether it’s your normal holiday seasons, but I would say it’s probably about 50/50. There’s definitely a recurring, I would say, cycle of checking of course what incidents we do come across and then ensuring that we are actually monitoring and structuring the organization and our technologies in such a way to expand our scope of monitoring and detection while also decreasing the noise that we have coming in.
The AI Trend
David Redekop: Is there in the process of the events that do occur that you do have to pay attention? Is there anything in particular that has surprised you as far as a trend, a change that has occurred over the last year or two that you hadn’t forecasted as far as how we had to pivot to adjust to new realities?
Joshua Domagowski: So, I wouldn’t Yes. In terms of I would say a trend that we’ve had to adjust to and adapt to as it being a surprise, is I mean I guess it’s definitely been a surprise in terms of the speed and pace with which it has picked up, and that would really be around AI adoption, which I think is probably on the top of most CISO’s plates right now for how to tackle because on one hand you have the mandate from the board and from the CEO of you know ensuring velocity can be a top priority for the company and leveraging AI to be able to achieve that, but then on the other hand you have of course internal sensitive data. You also have customer data, particularly when we look at like Astronomer’s use case, we are a data orchestration platform for customers. So, safeguarding our customer data, our customer code, and then also being able to adopt AI in the right way and in a secure way is definitely not only a balancing act, but it’s also a complex challenge.
The Challenge of Untrusted Code
David Redekop: Yeah, I can’t even imagine how many challenges you’re facing when I compare the stuff that’s close to my heart and close to this space that we defend, having highly confidential customer data isn’t one of them. Was there anything in particular that stood out to you that wow, in my past defender’s life, this has never come across. This is new that occurred that uh that you encountered in this current role.
Joshua Domagowski: uh in this current role what was definitely new for me was not only, you know, ingesting customer data but also our platform by its nature enables the execution essentially of untrusted code, right? Our customers are writing code that they’re executing on in our infrastructure and because of the nature of our platform and what it’s supposed to the functionality it’s supposed to support, I can’t take, I would say, a very standard InfoSec approach of, okay, we’ll we’ll deny any kind of reverse shell like connections that might might reach out to a third party IP address or we’ll just go ahead and ensure very specific um ACL’s or what not. It can definitely be much more dynamic depending upon the customer’s use case and how they have it integrated with their systems. So, I would say that has been kind of on my my larger concerns, kind of top of mind for me as I kind of look at the how to safeguard and how to secure that infrastructure has been around how to handle essentially untrusted code in the infrastructure and what that is doing with our customers data and with our infrastructure in general.
David Redekop: Yeah, I can’t imagine that’s a small task. Do you sleep well at night sometimes? I find that uh the folks who usually sleep well at night but have their reasons for having restless nights, it’s just the right amount of concern because it’s what we don’t know that bothers us or should bother us to see if there’s any extra effort that we need to apply in in areas.
Career Journeys: Certifications vs. Experience
David Redekop: I was curious about CISSP certification. You went through that journey, right?
Joshua Domagowski: Actually, no. No, I don’t have a CISSP.
David Redekop: Oh, okay. For some reason, I had pictured you as that. So, if you had someone on your team that came to you with a CISSP certification, how would you rank that versus having a solid real life defender experience?
Joshua Domagowski: I think it depends upon the specific role that I would be evaluating them for. I definitely would prefer experience over just a certification. However, there is a sense in which my experience with CISSP and other various certifications is that it does ensure the person can speak the language and the vocabulary kind of of the industry and also be able to communicate with other stakeholders. And I think that that is important and valuable. But if the other individual that has more of an experience background is able to prove that they have that sufficient vocabulary, then I would much rather go with the experience over the certification.
David Redekop: Yeah, we find that in most organizations prefer the experience over certification. After all, most certifications come as a result of someone paving the road, right? Someone actually being there to figure out what was important before the certification standards and bodies were even set up. But very often I find that the concern of incoming defenders is, well, everybody wants experience. Well, how am I supposed to get the experience unless I do the work first? So, they tend to gravitate towards well, let’s at least get the certification so that you know we have at least something to show for it. But in my experience, it’s those that are really hungry for it and are really willing to stick through the challenge of perhaps initially taking a different position that maybe is just in a supportive role. The amount of people that you see today that are experienced they started out in a support role, they had desk side support or some kind of a tech support role and eventually grew from there.
Joshua’s Path to CISO
David Redekop: How did you end up? What was your journey like to get to the role of CISO?
Joshua Domagowski: Uh so I think definitely maybe a little unconventional in some ways. Of course, I had the stuff that I used to do in the military, both on the offensive as well as defensive side there. Due to the nature of some of the roles and really just kind of fortunate the way things worked out. I had a variety of positions ranging from strategic planning to a tactical and operational level, I would say, units in which I was kind of overseeing things. And then a lot of what I did towards my latter time was actually more of an actual software engineer developer where I was building capabilities, which I think is a critical part that is also often needed kind of in that track in security is to have an engineering mindset so that you build things properly.
But then from there when I left I went over to Cybereason specifically out in Japan where the majority of the customer base was for the managed services and I helped build out and globalize the managed services offering there. So essentially MDR, managed detection and response, for the company. And growing that and defending more than a thousand customers globally and multiple languages was definitely a very interesting challenge, and it exposed myself and my team to a lot of unique constraints based upon industry verticals and other various compliance requirements that they might have. And so that was, I would say, the majority of the track that I had while there was it was a great experience because not only was it the service kind of to where you were talking about of the support roles of handling communications with customers and and other stakeholders, but it was also building the technical systems that we needed to run this operation, sift through the noise, find what was actually an attack and be able to do some predictive analysis, correlation and whatnot, and then stop the attack and work with our customers to mitigate that as it was occurring, but also mitigate it in the future by providing recommendations, helping them fix their infrastructure or make key purchase decisions on their end.
Leadership Skills: Humility and Communication
David Redekop: Did you end up learning Japanese in the process?
Joshua Domagowski: So, I was stationed in Japan for a while. My wife is Japanese, so I I learned it a bit prior, but then I have to say my kids right now are the ones that are correcting my Japanese. So, it is important.
David Redekop: That is really cool. If you have kids that can teach you things, although I think all of us have kids that will teach us things, it would be pretty boring if your kid couldn’t teach you something. And I think that’s a way to keep us humble, right? And really well really well grounded. That is pretty cool.
So, I’m wondering what kind of a role humor played versus technical competency? I find, and the reason I asked that, is because in my life I have found some incredibly smart, incredibly technically knowledgeable people and I found myself really enjoying having conversations with them for a period of time but then it gets dry and I realize wait a minute that happens with client engagement as well. So, how do you stay engaged with the right mix of humor and competency?
Joshua Domagowski: That’s an interesting question. Um, I think part of it is the big picture right? I mean, we’re not always going to win. They’re always in whatever engagement we’re doing, but we should always strive to do the best we can. And then there needs to be, I think, an appreciation for our limits that we’re bringing to this. You know, cyber is a human-made domain. I would say cyber security is a human-made problem and we’re humans trying to fix it. So, I think there needs to be as you mentioned there needs to be a large amount of humility in how we approach these problems, and I think there needs to also be a larger expectation that we’re doing our best. We will fail as we all will, but we’re doing our best and we will work to improve and move on and if you can’t have fun along the way, then one needs to go and look for something else in my opinion.
David Redekop: I like that. I have not heard of it in that context that cyber is a human-made domain, and that kind of explains why it’s so imperfect, why we seem to be so utterly capable of creating net new problems, or sometimes we have a new solution in search of a problem to which to apply it. Right. It’s definitely a self-looking ice cream cone in so many ways.
Joshua Domagowski: Right. Right.
David Redekop: Oh man, there’s another Texan that just used that same expression. So, it must be a thing, Joshua, to have our surroundings described as a self-flicking ice cream cone. That’s awesome.
Advice to a Younger Self
David Redekop: Do you have any advice to your younger self that you would give in light of what you’ve experienced as a defender?
Joshua Domagowski: Sure. I think probably to my younger self would be to be more immediately aware that other people are trying to solve other problems. Meaning that oftentimes, you know, what I see as a priority is definitely a priority probably for me and my organization. But when I go to another stakeholder in a business, another organization, they have their own fires that they’re trying to put out. They have their own problems that they’re trying to, you know, solve. And so I think again kind of having an ability around that, but also an awareness really of that the picture is much bigger than just what I see it as. And it’s also multi-dimensional in many ways. And having that appreciation to both work on the conciseness of my language when I’m explaining things to them, also being able to better, I guess, verbalize what exactly I’m asking of them in terms of an input or response or whatnot. and then being able to help them help me in many ways and also where I can potentially help them with their priorities so that it is less of a lift and less of a translation on their end to just kind of say hey I’m security and we have an issue.
David Redekop: Yeah, that is wise having the ability to clearly articulate what’s actually at stake but then also having others do the same back to you. So many problems can be avoided by just having a clear solid understanding of what is important to everybody. But a lot of the times I find that in the same way that we lack understanding of another person’s perspective, it’s difficult in cyber to know exactly how much of my position I am taking for granted and how much of it needs to be articulated in the form of by the way these are the assumptions. This is the circumstances. This is the impact broader much broader than what appears to be at the surface especially you know since we very often use things in in layers and take the approach of layers defense and depth and we have the OSI seven layer model and a lot of the times I find we are stuck at a certain layer and then forget that the person that’s impacted is at a completely different layer on a different team something that we have even have insight into. And so what may seem like a simple issue actually has a much broader impact that if we wait for it to surface after the fact, it’s going to be too late.
Strategic Defense: Processes and People
David Redekop: And we’re seeing this even with major cloud outages happening. I hope no one else is next, but I saw a good amount of memes in the last couple of days about first it’s AWS and then it’s Azure. Well, guess who’s next, right? And uh all that kind of stuff. But I’m sure there’s a lot of guys that like you mentioned earlier that sleep well sometimes, but other times they are wondering, you know, what have I not communicated or what have I not understood or what are we missing? The space is very deep to the point where if all we ever did is read everything there was to read, we still wouldn’t have full awareness of everything. And so the management of that I’m wondering how you handle that in your role as a CISO when there are so many different areas and layers of responsibility to maximize the efficiency of that. Do you have any wisdom around that?
Joshua Domagowski: So, the way I normally pursue it or approach is of course there’s a larger strategy which I try to frame kind of my actions in terms of what I’m able to control 100%. But from there, I also try to balance that with a certain amount of opportunism where as things arise or pop up, that might be the best time to go ahead and readjust my own priorities to maybe tackle something with product or the head of engineering or or something so that I can meet their timelines and we can both push each other’s goals forward. Um, so that’s one approach I do use.
The other one is again kind of just that iterative process of refining what we have. So, the way I I try to look at say processes in the company because a lot of people particularly say AI they say hey let me get AI added to this process and we’ll do great and oftentimes to your point around efficiency, I don’t think that that’s always necessarily the solution. Sure, you might have some gains, but oftentimes efficiency can be achieved through fixing a broken process, and you need to identify that first. And so one of the things I also try to do internally and work with other stakeholders on is making sure first off that we have processes that they’re properly documented, that everyone knows what they should be. Then also being able to really decompose those into the ordered interaction between people and technology, which is really what I think processes are kind of composed of. And then once we’re able to kind of recursively decompose those, we can rebuild it kind of like Legos in a way that can achieve efficiency and then we can greatly expand it through the adoption of AI or other automation technologies. Um so that’s kind of the approach that I would say I try to take both from like a high level as well as to a more tactical level um to achieve efficiency.
David Redekop: Yeah, I find that what you’ve just described there is what I’ve seen the best human engineers do. The ones that are thinking like the human first, then the people part comes first and then the technology and the process part comes naturally comes second. And if you ask them how they did it, they’re not really sure. But because they were focused on the person first, everything else just came natural, right? And so I find that the more technology leadership is good and efficient, the more there has been that attention at the human side, at the human side.
Anti-Ransomware Strategies
David Redekop: I’m curious if you have any particular anti-ransomware strategies that you apply. So far, I don’t remember having read any stories about your organization having been impacted and hopefully that doesn’t happen, and I’m always curious what organizations strategies are specifically around the fact that attackers very often only need that one area of weakness. Is there anything in particular that you can talk about or is this a a competitive advantage that uh you hold close to your chest?
Joshua Domagowski: I wouldn’t say there’s any quote unquote competitive advantage. I would guess I would start with making sure that you have a robust and well-tested business continuity and disaster recovery plan, right? Because assuming one has to assume that and that will happen to the worst degree possible. And so ensuring that you have the ability to in that scenario reconstitute your business and everything that you are providing to customers from essentially scratch I think is critical.
I think after that is then ensuring that you have the right safeguards from an access and permissions perspective definitely because you want to minimize lateral movement which I think then kind of moves back out to then the outer part of the circle of ensuring that you are mitigating what could potentially be the vector for getting ransomware so that you’re kind of building from everything’s in flames rebuilding to how do we stop an attacker from propagating through the network and accessing the machines and the data systems that we don’t want them to to then how do we try to prevent that from even occurring in the first place? That’s been the main approach that I’ve taken with it. Now, as to like specific technologies just all of it is really table stakes, I would say, in terms of cloud engineering and ensuring that we have a layered defense as well as a zero trust architecture so that we are safeguarding really more access to data than I would say to the systems per se.
David Redekop: I would suspect that the larger an organization is, the more is at stake and so the more preventative tabletop exercises are absolutely necessary. I just had a my previous podcast uh was with KPMG managing partner, and Alex, and what he described was that people often come to KPMG thinking that, ‘Okay, you must be dealing a lot with Fortune 50s, Fortune 500s in terms of incidents,’ but his point was, ‘No, very rarely do we do that because they are more prepared and necessarily need to be more prepared’.
Advice for Growing Enterprises
David Redekop: So, I’m wondering if there’s any particular advice you would have for growing enterprises that are not necessarily at the operational maturity that you might be at, that other large enterprises might be, that they can adopt that doesn’t break the bank.
Joshua Domagowski: I think that there’s a couple approaches there. I think one is first categorizing and mapping data in terms of your organization. Understanding what data is critical to your company, and that’s going to be very dependent upon the organization what it does, how it works with customers, what it’s selling, so on. But, knowing I think first like what data is critical, and then tiering it accordingly from a risk perspective. I think then looking at what systems connect and either transform, compute, or store that data, and looking at how those systems are configured, ensuring that it is properly, you know, configured.
Um, I would say like an example for instance would be a lot of SaaS vendors, you know, the lower tiers are not going to provide the necessary security and compliance functionality that you need. So, ensuring that if you are putting, you know, your crown jewels in a given system, that that system has all the bells and whistles you need, if you’re relying upon it to be able to properly store, secure, as well as provide the monitoring observability on access to it. And I think after that, you kind of expand outwards from there to a larger risk management framework where identifying what risks you may have based upon the data and the data systems, which you need to of course identify those data flows that you have in the company, and using that to then drive a company-wide, I would say, risk mitigation strategy from there.
And I think that that can, if you position it properly, that can actually open up a lot of revenue for companies in the form of achieving different compliance certifications when you look at SOC 2 and ISO and whatnot, because those are not just costs, they can also be door openers when you start looking at different markets and different industry verticals. So, that would be, I would say, the main approach there. The other approach is, of course, Zero Trust itself is not necessarily a bank breaker, but it is something that can be incrementally built out, and that definitely I would say addresses most of the challenges when it comes to mitigating ransomware.
David Redekop: Right. I’m glad I didn’t have to ask you about Zero Trust. You know that we live in that space, but this uh I have these interviews because I really would like the world of defenders to know that defense really takes a very broad approach, right? You got to take care of everything. But Zero Trust just seems to have such a broad impact when done right and when it’s adopted as, you know, as a fundamental building block that you approach everything to. Then it is just it, because what it does is it forces you to get down to first principles and just do things right, you know, from the ground.
Mitigating Insider Threats
David Redekop: What about insider threats? Do you have any particular wisdom that you want to share around how you can uh detect and prevent insider threats from reaching a point of actual risk?
Joshua Domagowski: Well, there’s definitely the whole principle of least privilege, which goes without being said in terms of any accesses and your permissions that are granted to anyone in the organization, and I would say a robust, you know, quarterly access review and other various you compliance driven frameworks and processes help to to mitigate that.
I would also add that a strong and good working relationship with the HR people team is critical because there’s a lot of, I would say, very rich telemetry that may be in or data that may be in other systems that security normally doesn’t have access to. An example to that is if one kind of follows the DPRK IT impostor trend or some of the other things that have been going on. What has been noted in a lot of the published reports is that a lot of flags existed in other systems that security is normally not looking in. You know, in terms like the interview process, the quality of the Zoom connections, you know, the routing of the laptop changing all the like so many different things that security normally doesn’t pay attention to and I find normally lives in the HR route. And so having a good relationship there to be able to also pull that larger or pull data to be able to paint that larger picture can also help address some of the insider threats as they’re kind of coming in the door.
David Redekop: That’s just a whole different lens through which to look at because from our experience I mean we’re just a small company of you know less than 50 people and we’ve been involved you know with long coffee interviews with every single one. So it’s very difficult to get past that initial stage of building a truthful impression. But I imagine that once an organization is way beyond that and the entire hiring process is only through means of virtual presence then that really makes sense, right? Because you would have the virtual session have extra latency that normally wouldn’t be if they were physically close by, and that would really reveal itself even if, you know, they had a VPN into your local geo proximity that the latency would reveal that this isn’t the real proximity. That makes sense. I hadn’t really thought about how you could make use of that kind of nuanced data to make an assessment. I’m wondering if AI also has a future role to play and say look for any signals of potential mistrust with this engagement and be able to surface that kind of stuff. It’s almost kind of scary.
Joshua Domagowski: No, it is. It is very scary. It’s hard to deal with such a virtual world and with all the AI technology, it’s hard to trust someone without meeting them in person these days, unfortunately.
David Redekop: Right. Right.
Misconfigurations and DevOps Culture
David Redekop: What about to get a little bit more technical here? I mean, it seems like lately some of the major outages and problems that we’ve had have been as a result of misconfigurations or technology problems that were at first, you know, looked like it was DNS and then it turned out it wasn’t DNS. it was how DNS data was being fed and it was a deeper problem. So those misconfiguration and visibility gaps they seem to continue to be a huge risk. Is that a major topic of conversation in your circles as well?
Joshua Domagowski: It definitely is because, I mean, there’s many cases where that can happen. Of course, I mean, there we could talk forever about all the different permutations of how that could happen. But yes, it is a concern of course where anything from product upgrades and feature rollouts that maybe some customers don’t want or maybe they break something and being able to roll it back. I think we all remember what happened with CrowdStrike last year around that. But yeah, basically the ability to both roll out changes in a transed tiered group so you can always see how things are actually impacting past testing. Of course making sure you have good robust testing which sometimes does not always exist but then also you know configurations and backups to those in different locations so that you can always revert worst case scenario I think is also critical. The other aspect to it that has also been a larger conversation that we’ve always had is do we have the right telemetry and observability on when these are occurring, who’s initiating them and so forth and so on. It’s never the situation anyone wants when there’s been a big change and no one knows who caused it, why and and what’s happening and then you don’t know if it’s a security related issue or or just engineering not having done something they should have done.
The “Pushing Code on Friday” Debate
David Redekop: One of the topics that I wanted to ask you about is about pushing code on Friday. It fundamentally bothers me that we have developed this culture in software development to not push code on Friday because what is done as a stakeholder. What it’s done is it’s kind of given us collectively or them if it’s us and them thing. It’s given engineers collectively a way of saying we’re going to have Fridays to be more relaxed, we’re just not going to have any expectation to get anything actually done on a Friday. I’m not saying it is that bad, but that is the feeling that I get is that is this a an a way to get less efficient because we don’t want to have problems on the weekend to address and we’ve now collectively decided we’ll mitigate, you know, our customers from having any problems by not push pushing any changes on Friday. I’m still wrestling with this because something about that doesn’t sit right with me. What do you think?
Joshua Domagowski: Well, you can always hire, you know, in other countries that may have different work days of the week, which can sometimes offset that a bit, but it has its own challenge of course too. Yeah, I definitely think that there’s an aspect in which risk if not properly controlled in an organization can always make room for let’s say the exploitation of it for let’s call laziness for lack of a better term. But I think, you know, depending upon how engineering is built and the the leadership there if the various RNRs that are properly delineated and KPIs are communicated and people are held to them I think you can still get around that, but yes, and I think an initial re knee-jerk reaction it’s definitely led people to say, well, they don’t want to risk it, so why not try it?
David Redekop: Yeah. And I suppose that the larger the organization is and the more revenue is tied to business continuity, the less of a risk appetite there is going to be for making any changes. And so one of the good outcomes out of that is that we have collectively as an industry found a way to make the steps smaller at a time right? Micro steps, roll out, test it, roll back if there’s a problem. and even the methodologies, everything that goes through the pipeline before anything gets published. You can always add more testing in there. But then again, there is no test like that of a real world deployment. So, I guess the takeaway from this for me so far has been there is a neverending iterative cycle in getting more efficient progress while not creating a problem in the process. You know, just like doctors have to operate on the patient without killing the patient, we have to figure out a way to keep on running without disrupting the organization.
Joshua Domagowski: Agreed. And I think that there’s an aspect too in which the way DevOps as an organization or team is positioned in the larger company between your support teams and engineering I think is also critical to that too. Because if they’re closer to the support side and they have to kind of bear the brunt of changes that are rolled out and they oversee that. Then I think it also makes them more accountable to how changes are rolled out in the company when they are and then it’s no longer well I’m just not going to push it on Friday because it might make them work on the weekends because they already have that hook to support that may have them work on the weekends because they didn’t maybe say upgrade or push out a change.
Geopolitical and Compliance Challenges
David Redekop: Let’s switch to geo specific uh challenges. Do you find that there’s a dramatically different process that you have to apply based on some geopolitical changes or are you just operating only in markets that can work with your existing process flows?
Joshua Domagowski: No, we definitely have, I would say geopolitical differences or geographic differences for sure. And I would say the most apparent would definitely be between the US and the EU with a lot of what’s been going on between the two countries. Of course, there’s the US Cloud Act and then the recent EU Data Act, which has language that seems to be targeting the other count’s bill or the other political units bill. So, that has definitely created, I would say, some uniqueness in the way we have to approach that, and some of the additional technologies we’ve had to implement to be able to meet those requirements.
David Redekop: Right. And technology always seems to have so much of a leap before public policy can keep up. And so I find it interesting how there’s sometimes this arbitrage of that technology change that is taking place and how organizations even can take advantage of, you know, the coming policy changes. There is such a complex web that we have woven between politics and technology that it’s not for the faint of heart to try to navigate what data needs to go where for what compliance. So, I can just imagine that in your role there’s no shortage of potential compliance reviews that you could be doing. And so at some point do you have to pick and choose what you’re going to be paying attention to and what you’ll just let go for now?
Joshua Domagowski: We definitely do. I mean a lot of that also comes down to, you know, the the nature of the contract of course that we’re pursuing, and we try to keep a breast of larger changes by roping in external legal counsel where necessary and also, you know, circling the wagons internally to identify potential risks and make sure we have a strategy around that. But yes, I mean, sometimes it just requires, I think, a very clear definitive stance on this is what we support, this is what we do and having a very frank conversation with our prospects and customers about what we are doing, our roadmap, etc. And I think that transparency and frankness is key. I mean as it always is, but particularly in these times of a lot of political and policy changes that are going on. So, yes, we definitely kind of pick different things to focus on. I would say a lot of that is definitely around data because that’s foremost in terms of what we do as a company. And then of course the AI thing is I think impacting everyone. So, we try to focus on that a bit as well. I keep a tab on that particularly as it relates to data. And those are I would say our primary focuses right now when it comes to managing the different geographic regions.
Conclusion
David Redekop: Yeah, I can definitely see Joshua how your challenge is not ever boring, right? We’re talking at the beginning of the call about going from offensive to defensive because the defensive space was even more challenging. Well, it sounds to me like you’ve upped the game on the challenging part of the role of CISO. So, that’s even more challenging than just, you know, the plain defense because you’re navigating, you know, everything from legal to, you know, geopolitics to technology and then keeping it all going. Is there any one particular piece of advice that you would like the world to know that Joshua would like them to know?
Joshua Domagowski: I think it goes back to the thing we mentioned or talked about beforehand around, you know, we as humans are imperfect. We’re doing our best to solve it and we all need to be humble about what we can do but also continue to rise to the next level as best we can.
David Redekop: Absolutely. Yeah. I think the moment that we uh stop being humble is when we get ransomed. And that’s not to say that the people that got ransom weren’t humble, but once you reach a point where you feel like there’s nothing left to learn, that’s when you likely become more vulnerable. So, I definitely would agree with that uh advice, Joshua. And uh thank you so much for coming on the podcast today. I look forward to connecting with you again and we’ll chat again soon.
Joshua Domagowski: Well, thank you for having me. It was a pleasure talking with you. Bye for now.
Show Outro
Announcer: The Defender 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.