By Kevin Hanes, CEO of Reveal Security
When I reflect on the years I spent leading one of the world’s largest Security Operations Centers (SOCs) and incident response teams, the lessons learned aren’t just war stories…they’re a playbook for how we should rethink our responsibilities in the face of today’s fast-evolving attack surfaces. Back then, we were managing massive volumes of alerts, hunting nation-state actors, and responding to zero-days on behalf of our clients that “outsourced” their security to us. But the reality is, even with the best people and tools in the world, the hardest lesson always circled back to this:
You can’t outsource responsibility.
Sure, you can outsource security services. You can hire MSSPs, employ managed detection and response, push workloads to the cloud, and sign SaaS contracts that include the phrase “shared responsibility model.” But at the end of the day, when the breach hits the front page or the regulators come knocking, it’s you. It’s your logo, your customers, your board, and your job.
That’s why the SaaS security challenge feels deeply personal to me. I’ve been on the frontlines of the security response when systems get encrypted, stolen credentials are exploited, or anomalous activity gets missed. And I’ve seen what happens when we, as security leaders, let gaps stay open because they’re hard, unfamiliar, or not fully understood.
What You’re Not Thinking About Will Hurt You
Let me be blunt: most security programs today aren’t truly thinking about their SaaS attack surface. And not because they don’t care, but because it’s sprawling, dynamic, and in many cases, invisible to their current security stack.
When you use Salesforce, Workday, Microsoft 365, Google Workspace or hundreds of other SaaS applications, you’re trusting platforms you don’t control, running on infrastructure you don’t own, accessed by users you may barely manage. You might have some visibility at authentication but what about after that? Your SIEM might capture logs if you integrate it all. But real post-login visibility – actual behavioral understanding of human and non human identities inside the SaaS app? Across multiple SaaS apps? That’s not something traditional tools were built to handle.
Let me ask you this: Can your current tooling detect if a privileged contractor logs in and starts extracting sensitive records from a CRM they rarely use? Can it distinguish a credentialed user doing legitimate business activity in a sanctioned application versus insider abuse? If the answer is “not reliably” or “it would be noisy,” you’re not alone.
And that’s the point. The noise is deafening if you try to retrofit old tools into this new SaaS world. You need something purpose-built. Something intelligent. Something that applies ML and AI to understand identity behavior, not just rules looking for known patterns. Something like what we’re building at Reveal Security.
Threat Actors Go Where It’s Easy
One of the things I used to say to my team was: “Why would a threat actor bother doing anything sophisticated when the basics get the job done and they don’t get caught?” Threat actors are smart. They’ll follow the path of least resistance. Today, that path leads straight into SaaS.
Why?
Because SaaS is easy. It’s accessible from anywhere. It’s interconnected, with API hooks, third-party integrations, and OAuth tokens galore. It’s complex – meaning it’s hard to monitor and it’s often assumed to be secure because it’s delivered by a big-name vendor. But let’s be honest: your SaaS security probably relies more on trust than verification. And we know how that story ends.
We’ve seen nation-state actors using MFA-reset flows in SaaS platforms to impersonate legitimate users. We’ve seen insider threats using SaaS admin privileges to quietly exfiltrate data. And very recently, we’ve seen a major cryptocurrency exchange suffer a data breach driven by the bribery and recruitment of their customer support agents. These “rogue insiders” leveraged their legitimate access to internal SaaS-based customer support systems to steal sensitive customer data. The harsh truth is, SaaS is the low-hanging fruit of modern cyberattacks. And we, as defenders, haven’t made it nearly hard enough to exploit.
Saying The Quiet Thing Out Loud
Now, I’m going to say something that doesn’t often get said publicly. I know that feeling – the one where you almost don’t want the alert to fire. Because if it doesn’t fire, you don’t have to know. If you don’t know, you don’t have to respond. And if you don’t respond, maybe no one blames you. And mostly, they all end up being false positives that just create work.
But let me tell you something: that feeling is fleeting. When the breach comes – and it will – everyone knows. Your team knows. Your customers know. Your board knows. And you will carry the weight of the question: Why didn’t we see this? How did the adversary elude our existing controls?
We all got into security because we believe in protecting people, systems, and trust. So let’s not kid ourselves. The goal isn’t to silence alerts, it’s to generate the right ones. The ones that matter. The ones that catch misuse and abuse, even when it’s subtle, after authentication, and inside a sanctioned app.
That’s why at Reveal, we don’t just focus on anomaly detection; we focus on behavioral understanding. We track identity journeys inside SaaS apps and cloud infrastructure, building a fingerprint of “typical” and flagging when things deviate in meaningful ways. Ways that are rare, security relevant and worthy of investigation.
Taking Responsibility for SaaS
We’re still in the early innings of this game. But here’s the reality: SaaS isn’t going away. If anything, it’s becoming the foundation of modern enterprise productivity. And with that shift comes a new kind of responsibility.
CISOs and security teams are being asked to secure environments they don’t fully control. That’s hard. But it’s not impossible. It just means we need to rethink our strategies.
It means taking responsibility for SaaS security. Not waiting for the vendor. Not assuming the identity provider is enough. Not pretending our existing stack can stretch far enough. It means owning the risk – fully and proactively.
And let me be clear: this isn’t about FUD. It’s about clarity. We have an opportunity right now to lead. To implement tools that give real visibility and can take action. To advocate for standards to make SaaS logs more readily available and FREE! (This is another big topic of its own.) To ask the hard questions, even when the answers are uncomfortable.
Because we all know, it’s not a matter of if, it’s a matter of when.
Final Thoughts
Tackling the SaaS security problem isn’t about buying another product. It’s about a mindset shift. It’s about accepting that while you may not control the SaaS infrastructure, you still own the risk. That means choosing tools that give you eyes where you don’t have them today. It means prioritizing post-authentication visibility, identity analytics, and anomaly detection driven by behavior – not brute force.
And most importantly, it means standing up and taking responsibility.
Because no one else is going to do it for you.
– Kevin
