An Interview with Mitiga’s Tal Mozes on Charting a New Path in Cloud Incident Response

I spoke with Tal Mozes, the Co-founder and CEO of Mitiga, about the emerging market for cloud incident response. Topics we covered include:

• Leveraging services experience to build a product company: How 20 years of cybersecurity services experience created an opportunity to build a cloud incident response product.
• The role modern incident response plays in cloud security: How capabilities have evolved to address the specific risks and opportunities of today’s cloud environments.
• Tech-enabled incident response services: Discussing why Mitiga blends tech and services to change the paradigm for delivering incident response services.
• The impact of Alphabet’s acquisition of Mandiant: Perspectives from the incident response market after Alphabet’s acquisition of Mandiant.
• The future of Mitiga: Where Mitiga is headed after its $25 million Series A round in April 2023.

Note: This interview has been lightly edited for clarity.

Leveraging services experience to build a product company

Cole Grolmus: I'm curious about your time at EY and the Hacktics services business you owned before EY. You spent 20 years doing pure cybersecurity services before starting Mitiga. Connect the dots going backwards on how that duration of time informed your decision to start Mitiga.

Tal Mozes: There are a lot of different aspects to that. In 2004, my current co-founder, Ofer, I, and another co-founder started a company called Hacktics that specializes in application penetration tests. We were pioneers in the application security layer.

Later on, we automated everything we knew into a product called Seeker Security. We managed to take something that used to be only in professional services and fully automate it into a product. I'll park it there and jump to EY.

Hacktics was acquired by EY. I joined EY, and I managed the EY Americas Cybersecurity Center of Excellence for a while. Then, I relocated to the UK to build something similar.

Through that time in EY, selling a lot of professional services, I participated in some of the world's biggest incidents and incident response engagements. Some customers got infected really badly, especially after NotPetya and WannaCry in early 2017.

We worked with a lot of incident responders, and we saw them send tens of different people just to understand where the system logs were, collect those logs, and sift through them to understand what happened.

I suggested to those incident responders to automate a lot of legwork—which maybe would have taken three developers around three weeks to build. They told us their business model is time and materials based. They were not looking to be more efficient.

We had this eureka moment that incident response is a space of cybersecurity that hasn't changed since the internet was public in '94. Not because of the technology challenge, but because of the business model challenge.

You've worked for a Big Four consulting firm as well, so you know that these firms always strive to give as much value as possible to customers. And the way they deliver that value takes time. At a moment when the financial regulators are talking about the importance of resilience and encouraging companies to increase their ability to bounce back as quickly as possible, there’s potential for misalignment.

Essentially, if you’re breached, calling a professional services company that will take a time and materials approach to help you recover is misaligned with your goals. I knew at EY that I wanted to change this business model and to build something that allows customers to have a rapid and speedy recovery.

This is what started the idea for Mitiga: understanding the value customers are looking for and the problems with the business model. In professional services, the holy grail was always to sell value-based projects and not necessarily hourly-based projects.

Cole Grolmus: The bigger consulting firms have had a really hard time flipping over into value-based pricing. Maybe someday we'll be able to pull it off with incident response because that’s a company-wide issue when an incident happens.

But I'm empathetic, too. I understand why it's hard for services firms to shift out of time and materials. It's really hard when the incentives aren't quite aligned. I can understand your feeling where the only real way to tackle this problem effectively is to do it outside the firm and not within it.

Tal Mozes: Building a product is a completely different DNA than professional services. So, I had to take it out.

The role modern incident response plays in cloud security

Cole Grolmus: Could you make the distinction between what Mitiga is doing for cloud incident response versus what a Wiz, Orca, or any company in the broader cloud security space is doing with their product?

Tal Mozes: Cloud security is a big space. If we take the NIST framework of security, we have: identify, detect, protect, respond, and recover. If you go to Wiz, CASB, it's all about protecting, it's about understanding the controls, misconfigurations, and so on.

We come in when all of those fail—because unfortunately no protection system is 100% effective. Not surprisingly, cloud and SaaS breaches are rising. We’ve built a unique expertise in cloud and SaaS investigations. It’s part of the recently coined CIRA category—cloud investigation and response automation.

SaaS risk today is one of the biggest risks. It's like taking your third party risk, multiplied by your Shadow IT risk, multiplied by the application layer risk. This is where you are: SaaS, uncontrolled. Added to the infrastructure risk that you have with AWS, Azure, GCP, and the split responsibility model for security. Many people term this “shared responsibility.” But the truth for IR is that it’s really split.

We’ve built an expertise in understanding cloud forensics, and from this expertise, we’re able to offer different products and solutions. For example, we understand what kind of forensic data needs to be collected from where, how to store it, and for how long we need to store it—so we built a forensic data lake. Because we understand forensic data so well, we also understand how attacks look in cloud and SaaS environments. So, we were able to proactively build an automated threat hunting capability.

Knowing all of that, we definitely know how to respond very, very quickly to those incidents when they occur in our clients’ environments. We’re able to help our customers recover much faster than anyone else. And today, it takes us a few hours to help respond to those incidents instead of weeks and months because we already have all the data we collected in advance and we’ve verified all the data that needs to be kept is being kept.

We have a lot of automation. Our platform automates the entire process, which is something very, very different than all the other products that you have mentioned. Our approach helps you to gain visibility of your controls, configurations, and stuff that has been misconfigured.

Cole Grolmus: Rephrasing what you said in a slightly different way: instead of starting from zero when an incident occurs, you've got a Mitiga customer X percentage along the way of already having the data that they would need to investigate an incident, and the playbooks and the means for how to‌ perform an investigation. That's the starting point for a Mitiga customer, as opposed to starting from scratch and having to build that all on the fly.

Tal Mozes: We’ve learned that when it comes to the cloud, if you haven't thought about it in advance, you won't have all the telemetry you will need for a comprehensive investigation. In most cases, you won't be able to ask your cloud provider for those logs, or you will need to wait for weeks to get the data you need to start an investigation.

Even when you go to certain SaaS services like Office 365, they will only give you the last seven days of data. If you want to look at something older than that, for example, investigate a business email compromise that happened 10 months ago, they will throttle downloading the logs and it'll take you more than 24 hours to download. You'd better save it all in advance, so when you're being called to the response, you don't have to spend three weeks just collecting data. Streamline the investigation with all the automation that we have built.

You've been through big crises, you know how it is. It's not just the CISO’s office involved. There are different stakeholders taking part in incident response. You have legal and compliance involved, the PR agency, CEO, CFO, Chief Risk Manager. We enable situational awareness by showing everybody on one platform what is going on in their own language. Having an executive summary and timeline of events makes it all a lot easier and saves a lot of time and effort. More than you can imagine.

Cole Grolmus: Let’s go further into the approach that Mitiga takes from a product standpoint. On one side, the negatives of cloud security and all the risks are pretty well documented. We don't need to cover that.

What I'm curious about is the opposite of that, which is: what opportunities are now available to you from an IR perspective in cloud and SaaS that were not there in an on-premise world, back in the days when you were doing EY and other on-prem investigations?

Tal Mozes: When you go to on-prem, you won't find two environments that are the same. Each environment has a unique fingerprint. When you go to the cloud, all environments are very similar. My AWS and your AWS would be the same, and my Salesforce and your Salesforce would look the same.

That allows us to build automation and scale that you couldn't do before. It's not like we can build a Mitiga for on-prem, because you won't have one product that fits all. But in the cloud, we can do that.

One of the biggest opportunities here is to learn from the network effect. When any of our customers are being breached in their environment, it doesn't matter what they have: GCP, AWS, Slack, Okta. We will deploy a squad of engineers to investigate what had happened, but also codify the incident response for that. And once that has happened, we can execute this exact code against all of our customer environments at once and help everyone respond.

If you go to the insurance market, one of the biggest risks today in the cyber insurance market is accumulated cyber events, when everybody is being affected at the same time from something like NotPetya, WannaCry, Log4j, or whatever happens. Until today, there was no real answer to that, someone that could handle all those claims at once.

It takes our technology, or similar technology, the same amount of time to handle one or 4,000 different affected customers of the same cyber campaign. You only need to automate the response for the same breach or attack vector once. This is a huge opportunity for us.

Cole Grolmus: That's pretty fascinating from a business model perspective. The network effect gets bigger and better and stronger as the customer base grows, but also cumulatively over time as you see more incidents. Any one customer gets to benefit from every other customer and anything that's happened to them. That's a pretty big advantage.

On the flip side of that, given that you've spent so much time in on-prem, traditional incident response as well: which cloud security risks and incident response processes are completely different than on-prem? What are new things that we weren't even thinking about before that we now need to worry about?

Tal Mozes: When you go to an on-prem IR, usually the methodology is: save the hard drive, capture the memory, split it to three copies, one in the safe, one for the client, one for us to work on, and start investigating from there. Then, look for system logs, application logs if they exist, and so on.

When we're talking about the cloud, you have to think about logs by design. Logs cost money. There is a risk of not having them, and there is a financial risk of having them. And you need to understand exactly what is missing, why you should allow or enable certain logs, where you should keep them, and how to keep them.

You can't keep all those logs in your SIEM. SIEM storage can cost three, five million dollars a year. You need to know how to keep the logs, and you need to keep it for more than the 90 days that it’s usually being kept because we see that it takes over 220 days to discover that you've been breached.

Thinking about all this (we call it a forensics data posture), in advance is mandatory today. It's something that you didn't need to think about as much in the old school.

We differentiate between infrastructure, SaaS, PaaS, and "lift and shift". A lot of organizations will just move their entire infrastructure into virtualization, but it will look very similar to on-prem. Even in those aspects, we cannot keep treating it all like just another endpoint like we used to do.

There's a lot you need to understand with the cloud: how it works, what is available for you, what tools are existing, how the logs are being saved. You need to know that they are compressed and encrypted. You have different encryption providers. Every SaaS will have different APIs. Some need to be collected every two minutes and some every 24 hours.

There's a lot of new knowledge that needs to be gathered to handle this new space of incident response in the cloud. It's completely different from on-prem.

Cole Grolmus: So, it's not accurate to say: "I have a solid on-prem incident response process. I can just lift and shift that into the cloud, and it's all of a sudden going to work." It's definitely not anywhere near that easy, and there are a lot of things you need to think about.

Tal Mozes: An environment that was breached nine months ago might not even exist today. The cloud is super dynamic. If you don't keep context like: “what were the security settings at that time?” or “what were the configurations at that time?”, those environments won't be there today to investigate. You won't even know where to start.

Tech-enabled incident response services

Cole Grolmus: The tech and services combination within Mitiga is really interesting. We wrote a whole 80-page report on this with Momentum Cyber about services becoming productized, automated, and more of a blend instead of just a service or just a tech platform.

Could you take me through where you're at with Mitiga on the services and tech spectrum? Which part of the delivery of the overall solution is services, which part is tech, and where do you see that going?

Tal Mozes: The majority of what we do is tech. We will sell a subscription to our platform that has a forensic data lake, hunts, and incident response.

Where the high touch parts are is when you do investigations. We run a continuous and automated threat hunting process, and we get results. Those results could be indications of compromise or indications of attack vectors. You still need someone to look at the results to make sure there are no false positives. We're not alerting the customer and annoying them for no good reason. That can take a few hours.

When there's an incident response, we can automate‌ parts of it. If we see something for the first time, we need to deploy a team to look at the incident, investigate it, and understand what has happened. They will codify it eventually. You only have to deploy it once. Usually it takes two hours to three days, depending on the incident. You still need to have expert incident responders to understand what happened and investigate it.

The other part of it is onboarding. We need to work with our customers to explain the risk of why they need to enable a certain log, show them the risk, and show them how to do it. This is where we add people into the technical aspect.

Cole Grolmus: It's almost a self-reinforcing thing where the tech is the default mode, but there's expertise, development, and codification of knowledge around that — which makes the tech and data stronger.

Tal Mozes: Customers get people supporting them, part of that support reports back to improve the product for everybody else. For us, they're part of our R&D. For the customer, they get a fully-blown solution. By partnering with our teams they also expand their own internal knowledge and capabilities related to cloud IR.

The impact of Alphabet’s acquisition of Mandiant

Cole Grolmus: One broad industry question: how do you see the incident response market being impacted with Alphabet (Google Cloud) acquiring Mandiant?

Mandiant is a well-known player in the space, with potential changes occurring with the acquisition and potentially shifting to more of a product-based delivery model. I'm curious about your thoughts on that.

Tal Mozes: From what I'm hearing from the market, customers using multi-cloud environments don't want to have one of their cloud providers being in charge of the incident response as well.

They're still independently serving a lot of customers with hybrid environments. All of them will be hybrid, but not necessarily GCP customers. In that sense, it looks like it's staying‌ the same for now.

We do have a lot of customers calling us because they were Mandiant customers and they don't want to be using Google for their IR.

Cole Grolmus: People still have questions about what the acquisition means and are still figuring out how exactly this is going to impact their business if they’re a Mandiant customer. With such a big deal, it takes a while to truly see what the effects are going to be.

Tal Mozes: They're not building the technology to automate IR. We have this platform, and we are not interested in growing the professional services part.

IR is a very wide term. We're using it loosely. What we are doing very well is a cloud investigation.

What Mandiant is doing well is holding hands with the customer, talking with comms, with PR, with legal, and other services they can do on top of that.

The future of Mitiga

Cole Grolmus: From the outside looking in, things seem to be going really well. What’s next for you and Mitiga?

Tal Mozes: We're starting to work with many insurance providers to allow their customers to buy new insurance products. When they have a breach, they can actually use Mitiga for the IR, quantify their incident response posture, and be more resilient.

That allows companies to have lower deductibles, allows the insurance company to have lower loss ratios when there is an incident, and so on. The data that we collect from all those incidents is very important to them.

Most of the insurance companies are suffering from ‌survival bias. They only have data of customers that have been breached, but not of customers that have been attacked and not breached. We collect forensic data insights from customers that have been attacked and not breached, as well as not being attacked or attacked and breached.

Also, we are developing some more interesting products that we've been asked to build by our customers. A product we call Investigation Workbench allows our customers to do hunts for themselves on top of their data that we're collecting for them.

There's a lot of stuff on the roadmap. We'll probably launch a new platform capability every quarter. But the essence is always the same: it's expertise in cloud and SaaS investigations.

Thank you to Andrew Smyth for the introduction and Katie Levine for a detailed review and edits.