CrowdStrike CTO: 'Rookie mistakes' are hurting cloud security

More than two decades after the advent of the cloud computing era, CrowdStrike still sees too many organizations making too many unforced errors.

Elia Zaitsev, global CTO at CrowdStrike, spoke with TechTarget Editorial at Black Hat USA 2023 earlier this month about recent trends the threat detection vendor has observed so far this year. A common theme was enterprise struggles with cloud security, including misconfigurations, poor development practices and a general lack of knowledge about how to secure hybrid cloud environments.

Zaitsev explained that while cloud providers have designed their services to be simple and easy to use, organizations too often deploy applications or instances that make easy targets for threat actors. And many threat actors, he said, are increasingly looking for simple but effective ways to gain access to networks and make money, whether it's selling credentials on the dark web or extorting stolen data. Here's more from the conversation with Zaitsev.

Editor's note: This Q&A has been edited for clarity and length.

One of the trends that that stood out from CrowdStrike's 2023 Threat Hunting Report was the increase in identity-based attacks. Why do you think that is happening so much still, to this day, with all the emphasis we put on identity management, securing credentials and multifactor authentication?

Elia Zaitsev

Elia Zaitsev: I like to think about these a lot in terms of military analogies. And just like any other innovation on the battlefield, you find there's a technique that may not necessarily be new but is very effective. Kerberoasting is a great example. If you if you saw the report, I think we observed almost six times the number of attacks this year [compared with 2022].

Well, here's the interesting note on Kerberos: It's not a new thing. It has been around since 2014. It's not a zero day. It isn't a bug in the code of Microsoft Active Directory. This is a fundamental issue in the design and architecture, and it has been around since 2014. And this is my original point: The adversaries are now realizing, "Hey, this is incredibly effective." And once you start seeing something is a little bit effective, you're going to push on it with both hands and try to move that along. Nothing has changed in regard to the underlying technology -- adversaries are just seeing it's super-effective.

And I'm speculating here, but I think there are some economic motivations to it as well. Credential brokerage services, where you can go online and just purchase credentials en masse, have become a business in and of itself. Think about the adversaries' motivations. If they're an e-crime actor and not a nation-state actor, they just care about money at the end of the day. Whatever gets them that payoff and that ROI benefit -- how much effort do I put in, versus what I get out -- they're going to do it. They want to maximize that. If all an adversary needs to do now to monetize a penetration against an organization is go get a bunch of legitimate credentials and post them online, then that's a much quicker, easier thing to do. And it's also stealthier, by the way, than to burrow deep, move laterally throughout the organization, put backdoors everywhere and steal intellectual property.

But for defenders, what do you think is perpetuating that attack surface on the enterprise side? Why are we collectively not better at defending this?

We spent as an industry so much time and effort focusing on malware, anomaly detection, exploits, et cetera. And we've gotten, by some measures, quite effective at preventing that, but sometimes we over-focus. Sometimes we let mastery of one domain lull us into a false sense of security that we've solved the problem. I think about half, maybe two thirds of organizations are still relying primarily on legacy antivirus technology. What does antivirus technology have to do with [a threat actor] coming in with legitimate credentials?

At some point, unless you have fully adopted zero-trust technology, you've got to trust that if someone says, 'Hi, I'm Rob, and I have access to this device,' and they have Rob's password, then they must be Rob. We still see a lot of kind of old-school techniques that don't really have a technical fix, like pretending to be someone from IT [support] and asking an employee for their password. That's not a technical control. That's a human weakness. That's social engineering.

And with techniques like Kerberoasting becoming very popular, we see cloud variations of that. Cloud is the new domain for adversaries. It's the new battle theater that they're increasingly moving towards. And there are some other identity-based, credential-based techniques that they're going after in the cloud specifically as well, like looking at secrets that are built into an application, which is a big no-no from a security architecture perspective. But people make mistakes.

There are built-in tools in these cloud service providers that are designed to allow you to manage these environments -- inheriting permissions and having metadata APIs built into these systems. And of course, they're there to make developers' lives easier. But if not properly secured, the adversary will take advantage of that as well.

I think by and large, cloud service providers are doing a pretty good job of making these technologies fairly secure by design. The issue is many organizations and developers are new to the cloud.

Do you think the cloud services and platforms are getting increasingly complex, or is it more that enterprises are having a hard time keeping up with it all because they don't always know what they're responsible for?

You said something key in there, which is that it's that it comes back to that shared responsibility model. I think by and large, cloud service providers are doing a pretty good job of making these technologies fairly secure by design. The issue is many organizations and developers are new to the cloud. And they're coming in and making rookie mistakes. For example, I'm a developer, and all this built-in high security is a bit annoying, so I'll just create one account and give away too many permissions because it just makes my life easier when I'm developing. I don't think it's the complexity of the cloud. I think the scale of the cloud is the real key.

It's why organizations love [cloud] from a development perspective. I can have one developer, with a few lines of code, set up thousands of servers and deploy an application at that scale, which is amazing from a software development velocity standpoint. But it also means if I make a mistake, that mistake now gets magnified a thousand times over. And again, going back to why adversaries are focusing on cloud and identity, it's because of the ROI. If I can find a misconfiguration in a cloud application, I can then exploit that a thousand times over because of the scale, versus having to go manually [compromise] one application at a time.

Does the cloud make things harder for you, from either an incident response perspective or for deploying your Falcon platform?

Actually, the cloud is fantastic for us operate in. Because we can take advantage of all these cloud service provider APIs and controls, it's much easier for us to deploy. And deploying rapidly at scale has always been one of our big strengths in the traditional on-premise environments because of the cloud-native technologies we developed.

To some extent, it gets even easier when you're operating in the cloud for us because we have agentless technologies with cloud security, or we can tap into those same provider APIs to instantly enumerate all of the environment, even on deploying runtime security. And by the way, the big thing we emphasize at CrowdStrike is that to get full control and visibility, you need to combine that runtime view with that control plane view and the cloud security posture management side. I think this is another area where companies are falling down a little bit in their cloud security program.

But just to finish my previous point there, just a few weeks ago, I think we released a new feature called 1-Click XDR, where we can take advantage again of those same built-in cloud technologies, for example, from AWS, and have our runtime security automatically deployed as your workloads are spinning up. That's even dramatically simpler and generates less friction than in the traditional on-premise world. We do have the techniques and capabilities to keep up with the scale. In fact, we benefit from it. But organizations don't necessarily take advantage of it. Especially because some of the traditional roles and responsibilities between security and development have broken down a little bit, or they haven't been reestablished as organizations have moved to the cloud. Again, in the old on-premise days, if I'm a developer, I can't just materialize a server out of nowhere. I've got to talk to the IT team, I have to get infrastructure provisioned, and the networking team has to come in and set up the firewalls. Now developers can do it with a couple lines of code and push it out. I think a lot of organizations are now having to catch up and rebuild that same discipline that they did in the on-prem world.

How so?

For example, going back to my previous point, we have a lot of developers now essentially getting to play the role of securing their own environments, and they want to go the path of least resistance. They say 'Hey, let's keep things nice and simple. Let's focus on just these new agentless approaches because I don't want to add additional software to my stack.' We have seen a little bit of overemphasis from organizations focusing on these agentless controls, not realizing that they're not getting the full picture of the puzzle. I can identify a misconfiguration with CSPM [cloud security posture management] technology and I can fix it. But how do I know if something happened in that time between me deploying the application and realizing I've got a misconfiguration that I have to resolve? If I don't have runtime security and I don't have EDR, then I don't have the data to go back and see if somebody took advantage of that issue and exfiltrated data and stole credentials.

The flip side of it is, we think you need both. If I'm just using runtime security, and I see that I've got a web application that somebody exploited and they tried to dump credentials, runtime security will stop that then and there. Fantastic -- that's what it's supposed to do. But in the cloud world, there's that scale issue that we have to deal with. Let's say that application is in a container that has a vulnerability or misconfiguration. And that container is now running a thousand copies on maybe multiple cloud providers -- the fact that most organizations are hybrid and using multiple providers just adds to that complexity and scale. If I don't have the security posture management side of things, I can go fix that one container, but I've got 999 other ones just waiting to be exploited. And again, the runtime security in many of the situations will stop it at the last minute. But now you're just putting a bigger burden on the security team because they've got to go respond to all the additional instead of just fixing the application code or configuration and redeploying it.

Rob Wright is a longtime technology reporter who lives in the Boston area.