Building a Third Party Platform for Cloud Security

Security.

Hi there. Welcome to the Cloud Security Podcast, and thanks for joining us today. Your hosts here are Tim Peacock, the product manager for threat detection here in Google Cloud, and Anton Chuvakin, which is me, a reformed analyst— reformed, that's important— and a member of cloud security team here at Google. You can find this podcast wherever you find podcasts and at our website whenever we finally launch it. And this time it's coming soon, soon, soon, soon, soon. You can also follow us on Twitter as well, twitter.com/cloudsecpodcast. Our guest today is Avi Shua, the CEO and co-founder of Orca Security. So it's going to be very cloudy today and very secure. Tim, now on to you.

What's fun today is that this episode is probably going to have more questions about the business of security than you've heard on our show in the past. We all know that security outcomes don't magically pop into existence thanks to the good efforts of security fairies. So we think it's sometimes helpful for all of us, including the listeners of the podcast, to think about the economic drivers of the security products, businesses, services that we all love and rely on. So if you hate this new thread of conversation in the podcast, let us know through the usual channels. And if you like it, let us know as well. So Anton, the first question, please.

So Avi, you might be an orca, but we have to talk about the elephant in the room. Congratulations on your really big round of funding. And I mean, by really big, I mean really big. So what's going on in the industry today that you're raising such a big round after another round? Why do you need so much money? Is security really such a hard problem?

So first, thanks for having me. Indeed, we just raised an enormous round of $210 million on a $1.2 billion valuation led by CapitalG. And the reason is that security is a very big problem that matters to anyone. What we see when we talk— look at businesses worldwide is that everyone is becoming a software company. The impact of COVID and the way it accelerated businesses worldwide cannot be overstated. Almost every business out there tried to find the way to have digital representation And when you are moving to become digital, of course, everyone is moving to the cloud. And at the same time, they need to care about security. They need to find ways to secure the environment. And as you probably know, the old paradigms that were mostly borrowed from the on-premise world, they don't work well for the cloud. There's an extremely big market for security, which is tailored for the cloud. And in order to continue building it and bringing it to the industry, you do need a lot of money.

So, we have a generational shift here of people moving to the cloud and an opportunity to not only have a new security operating model, but new security businesses built on top of that.

I think that definitely, and it's not only the technology, but the processes that dramatically changed when people moved to the cloud, the processes and the culture. If you think about it, not so long ago, only a few years back, if the business came with a new feature that was requested, it was completely acceptable This feature will be out in 5 months, 6 months, maybe 18 months. Today, everyone expects it to be in the next week or in 2 weeks. Businesses cannot really succeed if they'll say, okay, someone wants a feature, let's get it out next year. And while cloud enabled it, it really changed the way that you can do security. Security cannot continue to be something blocker to the business, but something that needs to work with the business and enable it. Many of the processes that we are so used to implementing for many years simply doesn't cut through.

That makes sense. So let's shift gears a little bit and talk about your background. You're a veteran, I want to say graduate or maybe product of the Israeli IDF Unit 8200. Can you give our listeners who don't know what that is, and I'm sure there's somebody who doesn't know what it is, a quick description of who they are and why we see so many veterans, not products, coming out of Unit 8200?

So you can call it a product or a graduate of that, and I think all of them are completely fine. But essentially, Israel a few decades ago reached the conclusion that cyber is going to be a major part of its military strategy. At the end of the day, there was the understanding that wars are not only going to be fought in the battlefield, but a lot of them are going to be fought in cyber. Some say that Unit 88 did cyber before people have coined the word cybersecurity. It wasn't called cybersecurity when I started around 20 years back. And Unit 8200 is essentially the cyber offensive unit of the Israeli intelligence. And the very interesting thing about it is that most of the people there are not experienced university graduates or people that came with tons of experience. Essentially, they take children which are 16 and 17 years old that they believe to have the capabilities to become cybersecurity experts and teach them. I myself joined the unit at the age of 18, went through some cybersecurity training and learned most of what I know during that time. And I also had the honor of teaching one of these trainings later on and to stay around a decade in this unit. And one of the nice things when you take people that are young and haven't been into the industry or to university is that you can really shape the way that they work and the way that they think. about problems. And when you do it in a certain way, you can reach really great outcomes.

Well, based on the number of security companies we see founded by people with experience there, I believe it.

And I would say that it's probably something that presents a very practical way where offensive knowledge kind of seeps into the defensive ecosystem. Like many years ago, probably like RSA 2013, I've encountered a few people who showed up in vendor booths and they basically said, we had cyber offensive experience. And to me, that was the first time that I've encountered people openly saying that We are good defenders because we worked as attackers for the government. And interesting that I remember that shift as it was yesterday, even though it was like 7 years ago. I was like, wait a second, of course it existed for decades. How come it's coming out now as a positive? So this was kind of interesting side observation.

I know an angel investor who had the strategy of investing in kids who were just coming out of their couple of years at the NSA, funding them as they sort of productized a technique or a service they ran there. And then those had a number of very quick, successful acquisitions by some of the larger security players for their expertise and technology. So it makes sense that we're seeing the intersection of national security, the graduates of those programs or veterans of those programs, and then our security industry.

Not so much to me national security, it's actually more the offensive side. And I don't mean the pentesters, because when you are an actual real attacker with a goal in offense as opposed to in testing, To me, that's different. To me, that's the part of the magic, I think. So Avi, you are building a multi-cloud covering multiple providers system to both detect issues that are pre-fail, like configuration errors, weaknesses, all this stuff, and also post-fail issues like say incidents or compromised systems or compromised services. Is that correct? Like you are planning to cover both stuff before the incident and stuff after the incident, right?

Definitely. But our main focus is essentially to detect the pre-fail, but not only to provide a list of thousands of issues that you need to fix, but to essentially find the critical attack vectors that can be exploited by attackers. One of the things that brings many security tools a bad reputation is the fact that they bring you thousands, tens of thousands, sometimes millions of critical pre-fail issues. And then there's absolutely no way that you can handle both of them. So you look at the post-fail, as you put it, ones that attackers essentially managed to manifest. One of the things that makes our solution unique is that we essentially can commit to provide the full coverage with no agent. This is essentially one of the differentiators of the platform, to use a technology called site scanning that covers all of your cloud estate to the workload level without the need for you to install anything, but not only provide an extremely long list of issues, but to connect the dots.

Mm-hmm.

So to speak. So essentially not to tell you you have 10,000 vulnerable machines, 5,000 rules that are too permissive, and 500 services that are exposed to the internet, and to expect the practitioner to connect the dots, but to essentially tell you this is a service which is exposed, this service is the one which is running with the vulnerable software, and running with a role that have permission to download the customer data. Now, this is not just a list of issues. This is a vector of several things that can be exploited today and should be the top of your to-do list.

Okay, but so does it mean that you would treat stuff before the incident is more important? So I hear you, but I'm kind of curious to prod. You would be then close to what Gartner would call CSPM, right? Like posture management tools, right?

The CSPM tools are the way And I really love to speak not necessarily the Gartner language because the Gartner language essentially many times is coined the way that the industry evolved. And this is not necessarily the way that we should look at these things, is that you want to see all of the risks in your cloud environment. And if you'll ask someone who is not a cybersecurity expert, what are the risks? These are not only cloud misconfigurations. CSPMs, as Gartner called them, essentially focused mostly on the cloud configuration. They don't look at your workloads, at their vulnerabilities, at the CIEM risks. customer data which is not encrypted, et cetera. We are trying to detect all issues that exist in a cloud environment. And when I say in, it's not only within the configuration, also in the workload, in the data, et cetera.

Okay. But so that still means mostly stuff that leads to incidents as opposed to incidents.

Exactly. But again, to not only to give a long list, but to connect them together.

Yeah. I mean, one of the interesting things here to me is the opportunity for dealing with alert fatigue. Like we've all heard that a famous retailer, when they were breached, their point of sale malware had been picked up by one of their threat detection systems before the card data exfil happened. They said they didn't catch it because of alert fatigue. Clouds and cloud security requirements are, to pun, quite nebulous in many cases, and it's hard to optimize your SOC around that. So how are you thinking about this problem of alert fatigue and giving analysts the right thing at the right time?

So I think this alert fatigue is as important as not having detection capabilities at all, because if the tool can give you a million alerts, Essentially, it doesn't provide any value. And I've seen organizations that have tools that had literally millions of critical items. And when you have a million critical items you need to look at, these are real numbers, then essentially you don't have a clue. And the only thing is that you have is once you're breached, someone will go back and tell you, but you got the tool that alerted on that, and why didn't you look? Nobody will essentially say, but I couldn't read it because it was buried as one of a million. I think that one of the main issues that cause this alert fatigue is that we are having too many tools, and these tools are working in silos, and they don't share the information. And essentially, we are many times just prioritizing the issues based on what is the most pickable lock in my organization. Imagine that someone came into your offices and just put a list of pickable locks. It might be the lock in the restroom. It might be the lock in the janitor closet. It might be many locks, but one of them is also the lock to the safe that contains all of your sensitive data. So essentially, it doesn't make sense to prioritize only based on that. But because we are taking too many tools that are working in silos, most organizations need to connect the dots themselves, and therefore they end with so many issues that they simply cannot make sense. My approach to that is essentially what we call to look at the vector of the attack, not just to say, what lock is the most pickable, but also what is to take automatically, the exposure and the impact. So essentially, where does the lock sit? Is it exposed to the internet or only to a certain individual within the environment? And what's behind this lock? Is it just a test environment or does it have keys to data or the data itself? And when you take into consideration not only how pickable the lock, how severe the vulnerability is, but the exposure, And the blast radius, you can reduce the number of alerts that are prioritized by order of magnitude, sometimes 3 or 4 orders of magnitude. We worked with a customer that had literally more than a million critical alerts, and when we applied this capability, it reduced to 33. And with 33, it's something that you can actually do something with.

33 from a million is quite a significant reduction. What were the most important things? Was it understanding what data was behind it? Was it prioritizing environment? What, what drove that the most?

The vast majority is the exposure. One thing that really shocks me, if you install most of the tools in the cloud security industry today, install them on an on-prem environment, they'll just pop up critical vulnerabilities for any critical CVE installed in the environment. But the vast majority of them, excluding Orca, won't stop and look at the configuration and say, yes, this environment is vulnerable to an NTP remote code execution vulnerability. is NTP exposed? 99.9% of the environments, it is blocked by compensating control, which is the security groups or the port forwarding. And we're simply able to take this automatically into consideration. So if you take exposure into prioritization, then you are able to reduce order of magnitude of alerts. You know, you don't need to care about a USB driver vulnerability in a virtual machine in GCP, but—

Mm-hmm.

Joking about that, automatically most of the tools does. You do need to take into consideration that the exposure can be recursive. It might be something which is exposed via service that is exposed via service, et cetera.

Right.

And the impact is not only whether they have files in the environment itself, but if it have permission to access a certain environment. So if you take this exposure and the business impact, you can dramatically reduce the number of issues that you actually need to look at.

Yeah, that does make sense to me as well because I've seen examples of people evaluating and revealing stuff like that on-prem, but it's much worse in the cloud because of different topologies. Like I've seen people say, oh yeah, this has a vulnerability, a local privilege escalation. And then you kind of realize there's so many controls layered on top of that, that it's going to be last on the list, even though it's in theory high severity. I'm slightly sad that this problem came to the cloud, but okay, it did. Connected to some things that your tool can actually act on issues, right? You can also prevent certain things. You can apply controls, right? You're not just informing people, correct?

Yes.

How is this functioning? Because, for example, we had an episode on our podcast when we talked about automatic remediation, and we do still see people who are sort of afraid and sort of like expect that the tool would tell them what to do, but it wouldn't do it. Your tool does both act on findings and does find things. So how do you balance this preventative and detective side, and how do customers deal with both?

So our approach to acting is not to act automatically without getting, I'll say, policy of the user. We allow the user to define the automatic actions based on the way that they see the environment and the impact of that. Many times when we say remediation in security, we actually mean governance because we don't really remediate a problem. For example, if someone is running with a vulnerable version of Python or have privileges that allow anyone access, we don't really fix it. We govern it, we kill it. The action is extremely aggressive in a sense, and the decision whether it makes sense to do it in one environment or another is purely a business decision based on the risk appetite, the type of the service, etc. There's cases that even super critical issues cannot be governed automatically simply because the business doesn't allow that. So we give the choice to practitioners to define their rule base, their policy of how to act upon a certain finding.

That makes a ton of sense. Shifting gears a little bit and getting back to the business side of it, you must spend a bunch of time talking to CISOs and CIOs. How do you explain to them that cloud threat detection is different than threat detection on-prem? And not to ask a leading question, but are agents dead in the cloud?

Let's take a quick walk back into the history of security, literally 3 decades back, and think about yourself trying to assess an environment. You are the practitioner, you're an engineer that is responsible to assess the security of an on-prem data center. You have several options at your disposal, but physically you need to either run something on the machine or use network-based approach, or you won't be able to do anything about it. This is the physics of the problem. This is essentially the way it's built. It's a box in a different room. If you don't run anything on it or use network-based support, you'll be completely blind. So, what the industry did is to build tools that are working with these physical limitations, that are either agents or network-based security tools. And we built these tools and used these tools for decades because this is essentially everything that we had. When the cloud came, we as an industry just did exactly what humans usually do. We took what we had, said, ah, okay, it worked on the on-prem, it should work on the cloud. We had agents, let's take the agent. We had networks, these are virtual networks, let's take what we have. Nobody stopped and said, is this really the ideal way of doing that? Is the limitation that guided us a few decades ago still the limiting factor that exists today? Truth is, these are no longer the limiting factor. These are no longer physical machines in a room. These are virtual entities that are purely software that can be looked at in a different way, there's many other paths that are not the network. There are many other risks and just lifting and shifting the security controls, it's completely suboptimal, just like lifting and shifting your workloads is suboptimal. And while some of the risks are similar to the risk that we had on the on-prem, some aren't. And definitely the most ideal way to solve them is not the way that existed before. So this was a long intro, but to answer your question, when we tell—

Yeah, I know.

more veteran CISOs that you've put years trying to engineer tools into your environment because this is essentially the only way you could do it, but you can fast forward it in the cloud. This problem that used to be a huge part of your work for when you're handling on-premise environment is simply no longer there. You can get full visibility to everything with 3 clicks. Usually they start back, no way, you are kidding me that you can do it without deploying things, without changing configuration, et cetera. But once they see, they understand that, Simply, there's a better way to do it in the cloud.

I like that.

Are you talking about the modern environments or are you talking about people who did lift and shift? Like, so this is kind of my side question to this. If somebody applied all the on-premise thinking and all the possible worst lift and shift practices for their IT, does your magic still work? Does your way to observe things with agents, does it still work? Because this is an important question to me.

Definitely. Because essentially what we do is we leverage the capabilities of the cloud providers to assess the environment without the need for agents. So even if you lifted and shifted the environment and snapshotted all of your machines and ran them as virtual machines in the cloud without doing any modernization, we can still do our magic or site scanning technology, which is the better name that we call it, to assess them by utilizing the native capabilities of the cloud because they're still running on the cloud. Essentially, one of the things that we really love about what we do is that we don't ask anything about the environment. We do the enumeration and scanning ourselves. We don't ask if you use managed containers, whether you use just virtual machine you copied, whether you installed Kubernetes on host or used any of the managed services. We just find out and scan in a touchless manner.

Okay, that does make sense. And so while we're discussing this, I kind of have another side question which came up in a few discussions, and I even started doing a Twitter poll to figure out the answer. So when you mention the threats that you would observe for and other things, are these typically more cloud-specific threats or are these threats more traditional threats but against cloud assets? Because where I'm going with this is if I do lift and shift, not that I recommend it, I would end up with a lot of traditionally configured assets in the cloud. And so they would be affected by, well, traditional threats all the way down to the '80s, password guessing or whatever. So do you mostly fight cloud-specific issues or do you fight traditional issues in the cloud?

We fight both, but what we usually see is the top ones that attackers use combinations. And I think that the siloed approach that many organizations, vendors take is essentially the one that causes that. At the end of the day, you don't really care about, and of course I'm exaggerating, but you don't care about GCP configuration or Kubernetes configuration or about secrets configuration, et cetera. You care about the combinations of them. And when you just look at one of them, you're probably going to miss the others. Of course, there might be risks that are only in the configuration, but most of the cases I see things like things that are exposed that they shouldn't. These things might be vulnerable. These things may have privilege that they shouldn't have. And it's the linkage which essentially allows the attackers to get into the environments.

Okay, so that's sort of a combination. You wouldn't necessarily call it by saying they deal with issues they had in the data centers because cloud technology, for example, made them exposed or something of that sort, right?

You need to understand the environment that you live in. For example, I've seen cases that people just lifted and shifted the environment and configured their virtual machines to run with permission asterisk on asterisk, essentially to be able to change anything in the cloud environment. Essentially, then if one thing is breached, everything is breached. And they're completely unaware of this permission configuration of the cloud because they just thought we are lifting and shifting.

That is a frightening thing to hear.

But it's also a reality-based thing to hear, right?

A reminder that the world we live in is a dark and scary one.

So Avi, I have a kind of a painful question for you, possibly, or maybe a risky question. A few RSAs ago, I went and talked to people in different booths, and I probably even visited your booth maybe and asked questions like this. Why should somebody use security tools from a startup rather than the cloud provider? And of course, I knew part of the answer at the time. I was still a Gartner analyst. For example, you do cover multi-cloud in a harmonious way, so you can have same controls applied to us and other providers. But how would you go about deciding whether to use controls offered by a cloud provider, like say GCP, whether for free or for separate money, Or where you need to buy technology from a third-party vendor, like say Orca. How would you go about deciding this?

The way that we look at it at Orca is that we are not trying to look at the security of the cloud separately from the security of the things running in the cloud, which is the more, I'll say, standard way of looking at it. If you are just looking at securing the cloud configuration itself, then what you are suggesting makes sense. You have The cloud provider is probably the expert in the configuration of these technologies. So you can use tools that he provided to verify the configuration of this environment. But what you're usually doing in the cloud environment is that you need to secure as a holistic entity, your application and the entire stack that runs in your cloud environments, which take into consideration the cloud provider controls, the infrastructure configuration. If you're using Kubernetes or similar, the operation system, the applications, and the connections between them. So, for example, even if you are using the native cloud provider authentication and entitlement scheme, you still may have private keys and public keys that you need to control. Most of the tools essentially the cloud provider provide are focused on configuring the environment, while some startups like Okta and other vendors are trying to look at the problem of things that run in the cloud. If you think about it, the entire IT moved to the cloud essentially. So all of the security stack can be adjusted to the cloud. And I think it doesn't make sense to expect only the cloud provider to be the vendor selling security.

So we see a bit of a security, pardon my Italian heritage, a bit of a security lasagna where you're suggesting cloud provider with third party on top. Is that how you're thinking about it?

I really love, by the way, the security lasagna.

Yeah, yeah, yeah. Please use it.

I will definitely use it, but I think that one of the things that the cloud enables is not to look at it as a lasagna and secure each layer separately, but try to look at it holistically. While the cloud providers might be the expert in a specific layer in the lasagna, you need someone to look also at the operation system and the tomato layers.

Ah.

I couldn't find the greatest analogy.

We can't think of the dinner slice by slice. We have to think of the dinner as a whole.

Exactly. and the implications between them. And this is essentially something that, as in the on-prem world, you haven't bought all of your security from the vendor who sold you the data center, the networking, et cetera. It doesn't make sense that all of the security will come from the cloud providers.

That makes a ton of sense. So we're getting close to time. I want to ask one last question before we wrap up. What should our listeners read, in your opinion, to get deeper on one of the many things we touched on? I hate to leave listeners and say, all right, thanks a lot. What should they go check out in addition to learn more about all this?

So first, I recommend everyone who's interested to learn more about what we are doing at Orca to come visit us at orca.security to see a quick demo of how we're able to scan your environment for free, literally within 3 clicks, and see things that you've been missing. And I usually recommend to read about recent attacks and try to understand all of the layers that were involved in them. It's never, in my experience, just one mistake. It's a combination and trying to understand how things relate to each other and how a series of mistakes can essentially bring you to the front page and usually not in a very good way.

I like the series of mistakes thing. That rings true for both the security incidents I've helped my customers with, but also personally when I've crashed skiing this season. It was usually a series of mistakes, going too fast, weird snow, overconfidence. So with that, Avi, I just want to thank you so much for joining us today. This was a ton of fun. Listeners, we're going to post links to all of the materials we discussed on our podcast website when we do, I promise, launch it. We'll also tweet some of the links that were discussed today. You can follow this podcast wherever podcasts are distributed. You can follow the podcast Twitter account, twitter.com/cloudsecpodcast. My co-host Anton is @anton_chuvakin. I myself I am @TimPeacock. So once again, I will ask that you tweet at us, email us, argue with us. If we like or hate what we hear, we'll invite you to the next episode. And with that, see you next time on the Cloud Security Podcast. Security.