In this premiere episode of Mitiga Mic, Mitiga’s Co-founder and CTO Ofer Maor joins host Brian Contos to share the journey behind Mitiga’s creation—and how it became the first purpose-built platform for cloud, SaaS, and identity detection and response. Ofer discusses why traditional incident response falls short in modern environments, how Mitiga built its platform from real-world service experience, and the crucial role of automation and AI in modern SOC operations.

Whether you’re a CISO, security architect, or cloud practitioner, this candid conversation offers firsthand insights into:

• Detecting lateral movement across cloud and SaaS platforms
• Building cost-effective forensic data lakes for rapid investigations
• Addressing the cloud security skills gap with automation and managed support
• Leveraging AI to scale analyst impact through automated triage

Watch the full episode below and read the edited transcript to explore how Mitiga is helping organizations respond faster, detect sooner, and reduce the blast radius of cloud-based breaches. Follow updates to the Mitiga Mic series on our YouTube channel.
‍

Mitiga Mic: Ofer Maor and the Journey to the Cloud

‍
Guest: Ofer Maor, Co-founder & CTO, Mitiga

Host: Brian Contos, Field CISO, Mitiga

The following transcript has been edited for clarity and flow.

‍
Brian Contos:

Ofer, welcome to Mitiga Mic.

‍
Ofer Maor:

Thank you, nice to be here.

‍
Brian:

I wanted to kick off this series with you primarily because I’d love to get the origin story of Mitiga—about you, your co-founders, and how this whole thing came to be.

‍
Ofer:

Sure. I’ll go back a little beyond Mitiga. I have two co-founders, Tal and Ariel. Tal and I had two companies before Mitiga. By the end of 2019, Tal and I were still at our last acquisition. One of our previous companies was acquired by EY—Tal became a partner there. Our second company was acquired by Synopsys, and I stayed on with them. We were both ready to move on and start the next thing.

We were introduced to Ariel—our third co-founder—through Glilot Capital. He’s about our age. While Tal and I were building companies, Ariel was in the military. He served in Unit 8200, retired as a colonel, and was looking to start a company. We were paired up, each coming from slightly different angles but with the same core notion: we’ve been in this industry for a long time, there are so many security solutions, and yet everybody keeps getting breached.

The incident response (IR) industry back then—and even now, to some extent—hasn’t changed much. You call one of the big IR companies, they send in a team, charge $400–$500 an hour. We call it “hurry up and wait.” Everyone rushes in to do the IR, and then they wait—for data, for permissions, for whatever.

This whole model was outdated. Meanwhile, people were moving to the cloud, and that called for new thinking. We saw a need to do something different in response and resilience—assuming we’ll get breached but making sure it doesn’t turn into a crisis because we find it and stop it really fast. That was the core idea behind Mitiga.

We started from the IR side. We said, “Let’s change IR for the cloud—or rather, create IR for the cloud—because nobody knew what that even meant.”

‍
Brian:

That’s what I think is really interesting. You didn’t start by saying, “We want to build a platform,” which eventually became the amazing Mitiga platform. Instead, you said, “We need to address IR in the cloud. However we do that, let’s figure it out.” It’s a cool evolution—maturing the process as you went.

‍
Ofer:

Right. As a founder, there are two ways to start a company. One way is to go into an established market where there are a few vendors that maybe didn’t execute well, and you build something better. Great story—maybe you’ve heard of a company called Wiz. They didn’t invent CSPM. Prisma Cloud and Orca were already there. Wiz just went in and beat the market.

Then there’s the other type of founder who sees a problem that’s coming—it’s not dominant yet, but it’s on the way—and decides to build a solution for it. That’s a much harder path. For some reason, I keep choosing that one. I like innovation, I like new things. I like hacking through the jungle and making my own trail instead of taking the stairs.

My previous company, Seeker, was the same. We were first to market. It took years before it became a category that Gartner recognized. Mitiga followed that same pattern. We didn’t know how to do cloud IR—nobody did in 2019. But we knew that if we brought in the right talent and designed the company to eventually build a platform, then every service we provided would teach us how to automate and improve it.

That’s what we raised our seed funding for. We told VCs, “Look, we’re going to sell services for a while, but these services will help us build a great platform.” It takes a leap of faith. Being second- or third-time founders helped. One of our first investors—still our biggest—Jay Leek believed in the team and the vision.

It wasn’t easy. Services and products are very different cultures. But we knew we were starting with services and would end up as a product company. Still, transitioning was hard, even knowing what we were aiming for.

So we started the company, positioned ourselves as “doing IR in the cloud.” And—maybe not surprisingly—cloud breaches started happening. It was 2020, the height of COVID. Everything was moving to the cloud. Our first year was busy. We offered IR services and eventually retainers. We learned a lot.

One thing that quickly became clear was the importance of data. Even today in 2025, if you haven’t prepared your data correctly, it doesn’t matter if you call in one of the big-name IR firms. If you don’t have the logs, they can’t help you. There’s nothing to investigate. Amazon isn’t going to hand over their hard drives so you can image them—unless maybe you’re a Fortune 10 company.

In the old days, if you were unprepared, an IR team would come in with suitcases full of tools, go to your servers, pull data from hard drives and firewalls, and build a puzzle. In the cloud, you can’t do that. You don’t own the machines or the rooms they’re in. You’re 100% dependent on telemetry. And that telemetry isn’t turned on by default. It also has terrible retention.

Very early on, we said, “We’re going to collect the data ourselves.” We didn’t have a platform yet, so we started with Splunk. At the time, it was the go-to for log collection. But we quickly realized it wouldn’t work. Splunk isn’t built for the scale or cost profile of cloud telemetry.

On-prem, you only send a subset of data to your SIEM. The rest stays on the device. But in the cloud, if you turn on telemetry across sources, the volume is huge. So we started building our own data lake. That’s still a core part of Mitiga today.

We spent about two years just on that foundation. That work—building the core data collection and engineering framework—was really hard. Distributed architecture, constant log format changes from cloud providers, ensuring data flow, monitoring structure—there’s a lot to maintain. But with that foundation in place, we became very good at what we do. We built automation capabilities for investigations right on top of the data lake.

‍
Brian:

When you built that out, was your original intent to focus just on AWS, GCP, Azure—or did you already plan to expand into identity and SaaS apps?

‍
Ofer:

It evolved—but quickly. VCs tend to frown on services, but services have a great advantage: they put you in the market, in front of real customers. You get to see what’s actually happening.

We noticed that attackers don’t respect organizational silos. They don’t think, “Oh, that’s cloud, that’s SaaS, that’s IAM.” They go wherever access takes them. And with federated identity and SSO, access takes them everywhere.

We saw breaches that involved entire public cloud footprints. So we had to look beyond just CSPs.

‍
Brian:

So when you told customers, “We’re not just a service anymore—we’ve built a platform with a distributed data lake that spans cloud infrastructure, identity, SaaS,” what was their reaction?

‍
Ofer:

It varied. Tech companies—SaaS companies—understood it early. They were born in the cloud and didn’t have on-prem. But in large enterprises, most didn’t get it back then, aside from the more advanced ones.

We had to do market education. Fortunately—or unfortunately—breaches kept happening. When someone got breached, people would say, “Oh, it’s in the cloud? Call Mitiga.” That helped.

Even when we hadn’t collected data beforehand, we’d plug in our platform, collect what we could, apply automation and enrichments, and deliver value. A lot of those companies stayed with us as customers.

One example: a CISO got a ransom note through Slack—during a holiday, of course. The attacker had compromised an employee’s identity, used SSO to move through apps, and claimed to have terabytes of data. Because we had the data, within hours we provided an assessment of what they actually accessed versus what they claimed. The negotiator used that to call their bluff. They paid $250,000 instead of millions.

It was still a breach, but with far less sensitive data involved. That outcome was only possible because we had the data. The customers who already understood that got a lot of value early on. But even those who didn’t fully grasp it were telling us, “You already have the data, you see everything, and you understand it. We’re still struggling just to detect issues.”

Most companies struggle with detection. Their SIEMs aren’t really made for cloud data, and they don’t have enough detection engineers. They told us, “You’ve already done the hard work. We’re struggling with basics.”

So, a couple of years ago, we said, “We have to build detection capabilities too.” That was actually easier for us because we already had the data, the normalization, enrichment, and automation logic. We just had to take it to the next level: collect data in near real-time and identify what was already investigation logic and convert it into detection logic.

We have over ten researchers whose sole job is to understand cloud logs—how to detect things and how to investigate them. We’ve built what I believe is the most advanced cloud detection platform in the market. We already have over 1,000 detections and expect to double that by the end of the year.

But we go way beyond detections. Our detections are deeply connected to identities and entities, which makes them actionable. You can immediately investigate what else happened—not just respond to an alert.

‍
Brian:

That’s what really impressed me. The usability, the intuitive flow, and the MITRE ATT&CK Cloud Matrix mapping. I can drill into persistence and see only alerts related to that tactic—makes it so much easier to go down the rabbit hole of long-term compromises.

‍
Ofer:

Exactly. It’s not just about seeing an alert. Let’s say a user is compromised. You block them, reset their password—great. But what did they do between the time of compromise and the time you noticed?

Maybe they created a forwarding rule or another account. You need to see everything that happened. And most SOC analysts aren’t cloud log experts—and that’s fine. Even being an expert in one cloud’s logs is hard, let alone AWS, GCP, Office 365, Okta, Salesforce, and so on.

So you need technology to help. I like to compare it to EDRs. They started as investigation tools, evolved into detection platforms, and in some cases even prevention. They give you depth on endpoints. Cloud detection and response is the same.

Most organizations don’t build their own EDRs—why build your own cloud detection stack? Focus your engineers on rules that are unique to your organization, not on reinventing what we’ve already done across hundreds of environments.

‍
Brian:

One of the features I was really intrigued by when I first saw the platform was AI Insights—the way you’ve built a capability that sort of thinks like an investigator. It looks at alert patterns and says, “If I see something like this, here are the next steps I’d take.” It stitches together those alerts and says, “Hey, these are highlights based on all of these signals.”

To me, that’s incredible. It’s like having an AI incident responder working hand-in-hand with the rest of the solution. I’m not even sure I have a specific question there—it’s just really fascinating. But I guess the question is: how early on did you decide that you wanted to leverage AI? And of course, “AI” is a loaded term—it can mean nothing or everything—but what did it mean for you?

‍
Ofer:

Yeah, so before I get into that, let me take one step back. Remember, we came from services—IR specifically. In the early days, we would do anything: red team engagements, whatever. Today, of course, we don’t do that anymore. But we kept some of that services DNA.

So, part of what Mitiga offers now is a managed version of our platform. You can use Mitiga CDR, or you can get Managed CDR, and you’ll still get incident response on top of that as part of the service. Why? Because—even though it’s already 2025—it’s still early for a lot of organizations. Some don’t have enough cloud security skills in their SOCs. Others just don’t have the people.

We help with that. And that gives us a unique perspective. We’re not just building the product—we’re using it. We used to have a tagline: Built by investigators, for investigators. And that still applies.

My office is two doors down from the R&D and product teams. The office after that? It’s the investigation team. They’re using the platform daily. And we’re always asking, “What are they doing that we can automate?”

That’s how we think about AI. It’s not like we said, “We need to use AI.” AI is just a tool. Like any other technology, we ask: what’s the right tool to solve this problem?

Three or four years ago, everyone was trying to bolt on blockchain. I didn’t want to build a “think tank” for AI just to say we use AI. But as we worked on automation—clearly, AI became one of the best tools for it. So we’ve been working on AI automation since Day One. The recent advancements in GenAI and LLMs? Huge leap forward.

Now we’re building an automated triage analyst that learns from our real analysts. It will help give you a recommended triage path for every alert. That’s another layer on top of AI Insights.

Let’s break it down. Before Mitiga, triage might take a SOC analyst six hours. With Mitiga, maybe it’s 15 minutes. With AI Insights, it goes down to 7 to 10 minutes. With our new AI-driven triage, the assessment is ready when they open it. If it looks solid, they’re done in 30 seconds. If not, maybe a few more minutes. But the point is—it’s incredibly efficient. AI helps your analysts do way more with fewer resources.

‍
Brian:

I love it. I absolutely love it. Thanks so much for taking us through your journey—the origin story, the evolution from services to platform, how the product matured, and how AI is changing the game.

Honestly, there are a thousand other product capabilities and features I’d love to talk about—things like forensics timelines, multi-tenant views, integration options—but we’ll save those for another episode.

Thanks again for being a part of Mitiga Mic.

‍
Ofer:

Thank you.

‍