No Alerts, Still Breached: Ethical Leadership in AI Security and Why Undetected Cyberattacks Threaten Healthcare AI Governance

Guman Chauhan: I went from my company. Humanizing AI first care. Talked about how healthcare needs to be emotionally ready before it can be technologically ready. How people feel safe, need and empowered that change happens. Hundreds of thousands of dollars of data, hours of technology. Most dangerous situation isn't being breached. It's being breached and not knowing it. No alert doesn't mean no breach. Often means you are not looking for the right signal. In fact, technology accounts for only about 30 to 40% of the problem. But most organizations already have all the fancy tools.

Chris Hutchins: Organizations often measure cybersecurity maturity by policies, tools, and compliance checklists, but history shows that breaches are inevitable. The real differentiator isn't whether an organization is breached, it's whether it knows when that breach happens and how effectively it responds. Guman, you said that there are only two kinds of organizations, those that are breached and know it, and those that are breached and don't. And you've been very clear that the second group is far more dangerous. So today I want to explore what really separates assumed security from proven security, why so many breaches go undetected, and what leaders should actually be testing. Guman, welcome to the Signal Room. Excited to have you here. You know, we talked about this recently, but there's just a whole lot of activity and buzz around AI. But there's some other things that are probably a little bit more important to make sure that we're in a position where we can be using it safely. Of course, that really is around data protection, data privacy. Really the space that you're in, really want to make sure that we delve into some good content today because people really need to understand what the stakes are. So when you ask organizations, are you sure if you would know if you were breached? What do you hear most often from your clients?

Guman Chauhan: Yeah, I think that's one of the questions that is, I would say uncomfortable when, but when I work with their organization and when I ask this question, they say yes, we would know. And they say it with a lot of confidence, and they will point out their tools, their security operations center, or their dashboard full of green and check mark. But when I follow up with the when was the last time you tested this assumption, and that's where silence starts. So in a real yeah, so in real incident, I have been seeing leadership believed detection was solid, yet attacker had already had been inside there inside for weeks or months using stolen credentials. And as you see, the some of the largest breach in the world went undetected for for months or even years. So in this case, attackers you know were already inside, quietly moving laterally, and they were exfiltrating data and doing their work that they are supposed to do once they are inside. So in this case, in this scenario, no malware, no noisy exploits. It will show just a legitimate access doing legitimate things, and no one notice until a third party or customer raised the alarm.

Chris Hutchins: That's the last thing that's the last place you want to hear about it from from someone who's discovered that this there's a problem, especially a client. You've you've talked about the different situations, and you said the most dangerous one is being breached and not even knowing it. Why is that worse than a breach that's already been identified?

Guman Chauhan: Yeah, so I often say most dangerous situation isn't being breached. It's being breached and not knowing it. And the reason is simple, damage compounds silently. So when a breach is identified early, organization can act, they detect suspicious activity, trigger alerts, and that are like actionable, actually actionable, activate their incident response plan, contain the threat, notify stakeholder and customer. And most importantly, they learn from that incident or what happened. So over time they strengthen control, no, to do and they also optimize their detection rules and make sure and they also try to close those visibility gaps, improve response time and and retrain their team based on the lesson learned. So in this scenario, we know breach, I mean breach is painful, but it becomes a catalyst for maturity. Now compare that that way to the more dangerous scenario when breach goes undetected. That's the question that you asked. So in unknown breaches, attackers have time and in cybersecurity, time is everything. So I mean, organization assumes silence means safety while attackers quietly moving laterally, as we discussed, and they were doing their work. Like the one of the biggest one of the biggest challenges in our field is attackers can use a valid credentials, so you can't even do anything with that. So in this scenario, I mean those organizations those cannot identify the breach. It means they never done their due diligence. The data is still being used by attacker. We never reach out to customer, customers never done any due diligence, they never reach out their password or you know, set up MFA, and because they are totally unaware and they are unprotected still. So regulators often learn from this kind of incident after the attackers do. So, I mean, because they don't do anything for the incident response, so no forensic investigation, no due diligence, and worse of all, no learning from the incident. So that's why I always emphasize visibility matters more than perfection, because the breach you can see is painful, but breach you can't see is devastating.

Chris Hutchins: Yeah, that's it's really interesting because you when you talk about things being undetected, there's so so many ways now that people are able to get their hands on credentials. So I think probably it's maybe I'm wrong, but it seems like it would be even more likely now that that would be the way that hackers are are actually getting in behind the firewall because it's really hard to detect. I mean, is is that what you're experiencing?

Guman Chauhan: Yes, correct.

Chris Hutchins: So historically, I think at least organizations that I've been exposed to, they have alert mechanisms for for breach, things like that. But oftentimes I think that we maybe have a false sense of security. I mean, why do you think organizations stop there and they figure since they're not getting any alerts, they're fine. There's no breach going on.

Guman Chauhan: Yeah, because alerts are often treated as a proxy of truth in our industry. So if dashboards are quiet, leadership assumes everything is fine, but attackers understand this better than anyone. And actually they design attacks specifically to stay invisible. So instead of deploying malware, they use valid credentials, phishing, deep, and other social engineering tactics. So once they are inside in your network, they access data during normal business hour. So they stay within the expected user's threshold. It means they know when the alert can be triggered in your tools, so they are more sophisticated. So it means you never get any alert because they deliberately behave in a way that avoid triggering detection tools because they know how these tools work. And we have been seen repeatedly in cloud breaches where attackers used the admin credentials or service account. There would there were no ex there were no expiry date on those, and they operated exactly like legitimate administrators, so you will not find any anomalies, no alarm, and no alerts, because they are a valid user account. So no alert doesn't mean no breach. Often means you are not looking for the right signals. And because and also don't don't forget that attackers have access to the more sophisticated tools in the age of AI, and it will always be a cat and mouse race.

Chris Hutchins: Are there ways now that they ha they can actually imitate or or fake an IP address? Because I know that you know a lot of the the technologies that are used to prevent a breach really are tied to a specific range of IP addresses within an organization or even where they're where the an employee might actually be accessing from. Is there a lot of that kind of capability out there?

Guman Chauhan: So in terms of IP address, it's not easy to fake the like spoof the IP address because those IP address are typically tied to the domain. So if you have an application that's running public, like some of the public phishing applications, and if someone wants to mimic the same application using some other IP address or same IP address, it's not possible. They can use a similar kind of domain with some change like hyphen dot or some extra character. Right. And that might trick you. That's part of the fit, the all phishing game the attackers are doing.

Chris Hutchins: Interesting. So that's actually a way that you could think about tightening up your detection if you're paying attention to the IP ranges.

Guman Chauhan: Correct. Yeah.

Chris Hutchins: Interesting. Well, we we we just talked about one example, but what are some of the other common reasons that breaches go undetected over for extended periods of time? I I know every once in a while we'll hear of one that's been ongoing, and by the time it's detected, there's just a lot of damage done.

Guman Chauhan: Yeah, so I mean, as I said, when the breaches go undetected for weeks or months, it's rarely because attackers are extraordinarily sophisticated. It's usually because they operate in a way that look normal. The most common reason I see, as we discussed, they they are using a valid account, using a some I mean, working as a legitimate user in your network. In cases like colonial pipeline and other countless cloud breaches, authentication succeeded. So no security tools assume everything was fine. And second reason I see where attackers deliberately blend into normal business activities. So, like one of the breaches from SolarWinds is a prime example where attackers looked like trusted administrations for a month. So third, I would say the alert fatigue is that high real attack. You know, security teams receive thousands of others every day, and they are not able to identify which one is the true or false. So, and and I think I personally I also see breaches go undetected due to the blind spot, like unknown assets, shadow IT, not collecting enough information or log from any device or network, except cloud permissions and third party access. One of the example, Capital One and Moveit breaches are the reminders that you can that what you can't see, you can't protect. I mean you have to understand what exactly your assets are. You can't protect if you don't know what your assets are. And also make sure you are collecting the enough log for your tools. There's no matter to buy a fancy tool if those tools don't have enough information to identify anomalies or any suspicious activity going on in your network. And we saw that most of the time many organizations don't detect breaches themselves at all. They learn from banks, customers, regulators, or law enforcement. And that's a clear sign detection has failed. The pattern and the pattern is consistent. Breaches go undetected not because security teams don't care, but because visibility isn't validated. Alerts aren't trusted, a response delayed.

Chris Hutchins: You mentioned tools here. I think that's one of the areas that most organizations are spending a fair amount of money on. I I know it's not not inexpensive to try to protect an enterprise these days. But let's talk just a little a little bit about what some of these are. We've got SIEM, which is a security information and event management tool, and there's EDR, like endpoint detection and response, SOAR, orchestration automation and response, and then SOC, Security Operations Center. On paper, that stuff sounds pretty good. It sounds like the organization's mature. With all that, why do you think breaches still are slipping through the cracks, even with all the spend on technologies to prevent it?

Guman Chauhan: Yeah, because you know, tools don't equate outcomes. And most organizations invest in fancy AI-driven tools nowadays. And there's a lot of companies out there in the market that they are selling these kind of tools with the tag of AI-driven. And so companies are buying tools for collecting logs, you know, storing telemetry information and automatic workflow, and that the tools that you discussed, they are pretty standard tools that every company is using nowadays. And so you find that most of these tools are running in isolations mostly, and that's the one of the biggest gaps because they are doing their own task, they are not integrated, and but they don't invest, so that's why they buy a lot of tools, but they don't invest in tuning detection, they don't invest time in validating those alerts, and they don't train engineers on real attack patterns. So, no matter how much tools you buy, if they are not fine-tuned, if you are not testing those regularly, if they are really alerting for the right purpose or not. So we have been seeing environments with the world-class tools where alerts fired but no one trusted them enough to act. And in other cases, alerts went to shared inboxes, no one was actually monitoring during off-hour. In many and saw that one of the I I saw a lot of post-breaches review, teams often discovered logs weren't ingested or alerts weren't escalated. So I see a few cases organizations were not collecting any logs from the assets because they don't know about it. So, I mean, again, I want to emphasize that you cannot protect assets if you don't know if it exists in your environment. And that's the first that's the first thing that as a security practitioner have to understand. You have to know your stuff, you have to know what you are protecting.

Chris Hutchins: That's an excellent point in that soft. I know there's always been challenges in any health system that I've been around, having a good active inventory and having things actually connected so that you can monitor things in in in real time. How much of the breach stuff activity that goes on is a problem with technology versus people or organizational behavior? I mean, there's there's definitely you know ways that probably fall under each of those. But what would how would you say that that breaks down?

Guman Chauhan: Yeah, so I would say when breaches go undetected, it's rarely a pure technology failure. In fact, technology accounts for only about 30 to 40 percent of the problem. But most organizations already have all the fancy tools that we discussed, I think that that you point out, SIEM, EDR, SOC, everybody in place, and they they are super confident that they have everything that they need to know. But the big the bigger issue, I think I see is our process and people. So roughly 40% of detection failure comes from broken or untested processes, unclear escalation paths. We don't have incident response plan that exit I mean we have an incident response plan that exits on paper and alerts that fire but aren't acted on and delays caused by approval and handoff. So this is the part of process. So remaining 30% come from the down people and behavior. So security analysts hesitate to escalate because they fear false positive or business disruption. Leadership often prioritizes uptime over rapid containment as a result, early warning signs are ignored and delayed. So I mean as we discussed before, buying more tools or technology won't fix the detection automatically. You have to do some define those tools and make sure you have a proper process. You have a lot of process policies documented, but when the time when the last time you validate these are working as as designed. And I see one I think one also I found to that in several breaches we saw that security engineers or suspicious behavior, but they were hesitated to escalate because they don't want to trigger a false alarm. So that was very interesting, yeah.

Chris Hutchins: Well, so you you've kind of touched on this already a little bit, but alert fatigue is something that we hear about it in in the healthcare space, we hear it a lot because there's so many alerts that are fired from the clinical record that you know the the clinicians and the nurses are bombarded with alerts. When you have such a high volume of them, it's difficult to know what to act on. How do you how do you think about managing alerts and really making sure that, you know, to your point, people aren't reluctant to report something, but that what you described seems like maybe the the alerts aren't fine-tuned enough to really make sure that they understand you have to escalate this. What are some of the things that you could be done to really help distinguish meaningful signals from the the volume and the noise of all the alerts?

Guman Chauhan: Yeah, so I think as we discuss alert fatigue is something we hear about constantly and for a good reason, because it's one of the biggest reasons real attack gets missed. And most security teams receive thousands of or maybe millions of emails, alerts, depending on the size of organizations. And as I said before, when the same alert fires over and over again, engineers naturally become desensitized. And if your SOC can't clearly distinguish signal from noise, attackers don't need to be sophisticated because they just need to be patient. So the solution isn't more alert, it's a shift from volume-based alerting to risk-based detection. And so instead of asking did something happen, team should ask, Does this activity meaningfully increase business risk? So effective security teams correlate those alerts and the asset, they define the asset if it's critical or not, and behavior. So these teams prioritize alerts tied to privilege access or sensitive data, not just technical anomalies. And they also regularly disable alerts that never lead to a real incident. So I've seen organizations reduce alert volume by 60% and actually improve detection simply by removing rules that hadn't resulted in a single actionable event in a year. The goal, I mean that the goal is not to see everything, it's to see what matters most and act it fast.

Chris Hutchins: Right. That brings up what when we talk about what matters, how do you even approach the testing of these applications and the risks that you may have, whether it's human behavior or it's it's organizational behavior or it's a technology thing. You've been a strong advocate for external testing. Why is external penetration testing still one of the most effective ways to understand the real world risk that you're you're dealing with?

Guman Chauhan: Yeah, because it shows reality and not assumption. So many organizations hesitate to authorize full scope independent penetration testing because they are worried about business impact. And my response is simple. Ships aren't built to stay in harbor. You don't learn how strong your I mean, you don't learn how strong your defense are by protecting them on stress. So you learn by testing them in real conditions. I mean independent third-party testing is one of the one of the I would say thing that we can use unless you let you see your environment exactly as an attacker would, but in a controlled and responsible way. So I mean external testing answers questions. The question that internal might not see as when attacker what is the question like when what can attacker actually see from outside? The question second question will be which assets are truly exposed, and the question like which security controls fail silently. So in practice, these tests often surface uncomfortable truth like system believed to be internal, but turn out to be external facing. So we saw some incident where they believe it's not a public facing application, but they would it was. And in in this scenario, we we also found like old and forgotten credentials still work. And most concerning, tactical alerts never fire even during active exploitation. So this kind of testing gives you a real picture how your how your network or application or infrastructure is working from outside of the world. I think that's the part many organizations miss. Pen testing shouldn't be and with report, just a report. It should validate whether your security team or SOC actually detects what testers were doing. Because that's that's one of the one of the best ways to optimize your SOC tool to make sure you're getting the alert if someone's trying to do something with your network or application or data. So the most mature teams correlate test activity with alerts, fine-tune their detection rules, improve response workflow based on the real attack behavior. And today, this doesn't have to be limited to annual. You know, nowadays we have a annual or traditional pen testing. Nowadays we have a AI-driven security testing platform that they do pen testing regularly and can continuously simulate real-world attacks on demand. And so they can I mean provided they are scoped and correctly and unbiased, which is one of the reasons we always go for independent third party because make sure they are not biased. So I mean they're when they these tools are used properly, they give organization a ongoing visibility into exposure, detection, and response gaps.

Chris Hutchins: You've really kind of outlined some some really important things. And I think the thing that I'm hearing loud and clear is you've got to test more than just your detection capability by measuring whether an alert fires or not. There's much more to it than that. And organizations really have to be aware that that they need to be looking at many other factors. And honestly, I'm an organizations that are in any any industry, you can pick you know almost any one of them. The focus of the business is not primarily data security. I mean, it you have an accountability for it, but their expertise is really running the business. So, you know, I think what you say around having an external partner to help with that testing, I think is extremely important. Let's jump a little bit into what happens in an organization once there's been a breach. What separates organizations that are mature from those who are repeating maybe the same mistakes again and again?

Guman Chauhan: Yeah, so I would say what really separates organizations after a breach is how they respond to it. I mean, I see the mature organizations don't treat a breach as something to hide. They treat as it's a learning moment. Right. And they take the time to understand why it happened and they fix the root cause and then retest their control to make sure the same issue can't happen again. On the other hand, immature organizations do the opposite. They look for someone to blame and they just apply a quick fix to stop the immediate bleeding or problem and move on as fast as possible without changing anything meaningful. And that's the differentiator between the immature and mature. And this is not about buzz-up or tools. It comes down to accountability follow-through. Organization that mature always ask, what did this incident teach us? And those are not mature, they ask how quickly can we forget this happened. So that's the differentiator between two organizations. So the mindset is what determines whether the next breach is smaller or far more damaging.

Chris Hutchins: Yeah. You're touching on something I think it's is really worth emphasizing. We're talking about some things that the leaders really need to be aware of, much like you know, creating psychological safety within an organization so that if people see something that that's wrong, if there is a mistake made somewhere, that they're not afraid to raise their hand, or if they see something that could be vastly improved and it maybe it could actually shift their focus to something else that's more high value to do for the company because we automated it. There's a culture, a component to this that leadership needs to be really dialed in on. I think when I was running an IT shop years ago, one of the things that I had to really make sure that the team knew is if you find something that needs attention, don't hesitate. You know, just bring it and we'll we'll circle the wagons, we'll bring everyone together, we'll go in and take a look at what happened, we'll rectify the situation, and then we'll put some safeguards in there to make sure it doesn't happen again. And the best opportunity to close those loops is the people that are actually doing the work and they're detecting what's what's really happening. There's no there's no substitute for having that kind of a culture where there's trust. And if you've heard any of the recent episodes for my listeners, you know, we've I've had a conversation with a medical psychologist who really has emphasized there's been a massive erosion of trust in human relationships over the last 20 years. And we're talking about information security. We're trying to keep things, nefarious actors from accessing our environment. That's one of the aspects. But then there's also the inadvertent mistakes that people can make with technologies. So it's got to be an environment where people are not afraid to speak up if they see a risk. And I really appreciate that you emphasize that. Guman, I think we're gonna get towards the the end of our time, but I want to just kind of get some bigger picture things that you that you can share with the audience and things that they can actually carry away from this. If an organization could do just one thing this year to improve their breach readiness, what would you recommend that they do?

Guman Chauhan: I mean, to be honest, my recommendation is simple. Just test a real incident end-to-end. Not just a tabletop exercise where everything goes according to plan. So plan something, simulate an actual breach and see what really breaks. Test whether alerts fire, whether they reach the right people, whether anyone has the authority to act, test how quickly leaders are notified, how legal and security coordinate, and how communication flows when decisions have to be made under pressure. Right. In real breaches, it's not the attack that surprises organization. I say it's their own response that surprises them because they are confused and they have no idea what to do. So, I mean, testing exposes gaps you you didn't know existed before attackers do. So I would say you don't build confidence by hoping your plan works. You build it by proving it before a real incident forces the test. So that's my only advice based on this discussion.

Chris Hutchins: That's very well said. Let's touch on another interesting way to do things because oftentimes if you don't say something that's a little controversial, people might not be paying attention. We can't really afford to have that risk so much. So, what's an uncomfortable question that every security leader should be asking their teams today?

Guman Chauhan: Uncomfortable. Okay, that's a good one. Okay, so I I mean, based on this discussion, the question that I would ask, if we were breached right now, who would know and how soon? So this question cuts through the tools, dashboard, and policies. Because if answer is not immediate or specific, or if it's vague or maybe depends on assumption, it means there's a real risk right there. So in in many organizations didn't learn about the incident from their own security teams, as we discussed, they find out from customers, banks, regulators, or media after weeks or months. So if you can't clearly name who gets the alert, who makes the call, and how quickly action happens, then detection is not working as planned or as planned on your paper. So I know this question may be uncomfortable, but it is powerful because clarity, not confidence, that would expose risk.

Chris Hutchins: Yeah, that that's the that's excellent. It is a really important thing to make sure that we're really asking the right questions and we're we're not afraid to be a little bit provocative in how we ask. So as we close out, I mean, how would you summarize the difference between assumed security and proven security?

Guman Chauhan: Yeah, so that goes back to our introduction. Like what what I define in the assumed security is solidly built on tools, policies, procedure, certification, compliance framework like ISO, SOC 2, GDPR, and other. But we know that these are important and they help establish a baseline and create a structure, but they often create a false sense of confidence because they describe what should exist, but they don't tell how well these actually works in the real world. So this is assumed security based on policies, program plans. Proven security, on the other hand, I will I will define is based on the evidence demonstrated through a testing, detection, and what actually fires, response, what happens quickly, and the teams that know how to act under pressure. So proven the proven security is measured by how fast you know something is wrong and how effectively you contain the damage. Again, I want to emphasize in real breaches, organizations don't fail because they lacked policies or certifications. They fail because assumptions were never tested. So I mean the the final takeaway from this question is silence is not safety. It often means you are not seeing the what matters. Visibility, testing, and response. That's what proves security.

Chris Hutchins: I love that. Silence is not security. I think that's a that's a brilliant way to put it. As we wrap, if our listeners wanted to get in touch with you, they want to have a conversation, maybe they've heard some things today that give them a little bit of reason to be concerned in their own organization. How do they reach out to you? What's your preferred way to be communicating with us?

Guman Chauhan: Yes, so people can find me on LinkedIn. I'm pretty active on LinkedIn and they can reach out to me anytime, and they can also use my personal email. I can send you my email. My name is gumanc2 at gmail.com. So they can reach out anytime, and I'm happy to mentor if anyone's interested. And I want to give away to community.

Chris Hutchins: That's amazing, Guman. I I really appreciate that. And and I'll make sure that I put all the information in in the show notes, folks. So if you want to reach out to him, I'll make it easy for you to find him. Guman, thank you so much for a practical and grounded conversation. This has been fascinating to me. I am certainly not a security wizard, but I have a lot of respect for what you do and people like you who are out there likely not resting as well as I do because there's so much horrible activity that people are trying to pull off. And their whole issue of having to defend ourselves against breach is just mind-blowing to me that people are so motivated to cause that kind of havoc. So thank you for doing what you're doing. And thanks for for being my guest today on the Signal Room. And to our listeners, that's it for this episode of the Signal Room. We're here to amplify the signals that matter across leadership, ethics, and innovation. So until next time, stay tuned, stay curious, and stay human.

Guman Chauhan: Thank you so much for having me.

Chris Hutchins: That's it for this episode of the Signal Room. If today's conversation sparks something in you, an idea, a challenge, or a perspective worth amplifying, I'd love to hear from you. Message me on LinkedIn or visit Signal Room Podcast.com to explore being a guest on an upcoming episode. Until next time, stay tuned, stay curious, and stay human.