The Grand Unified Approach to Securing Cloud Native | Cloud Native Now 2023

Hello, I'm, uh, orris Siegel, c t o for Prisma Cloud, and I'm here to present to you the Grand Unified approach to securing cloud native applications. Uh, and before we begin, I'll just want to, uh, I'll, I'll just introduce myself. Uh, so as I mentioned, I'm Ori, I'm the CT O of Prisma Cloud.

Uh, I was previously c d o and co-founder of a company called Pure sec, that was, uh, acquired by Palo Alto Networks back in 2019. Uh, pure SEC was a pioneer in the serverless, uh, security space. I'm also an app security, uh, veteran with over 20 years of experience.

Um, I worked at companies like, uh, Akamai, I b m, Watchfire and so forth. I, uh, filed, uh, an, they got accepted the 30 patents in the fields of applications and, and cloud security, uh, mostly around static dynamic analysis, uh, reputation, uh, client reputation, uh, web at firewalls. And I'm also a contributor, uh, to several organizations that you probably heard about, like oasp, uh, um, W C S A, NIST sans, et cetera.

Uh, you can find me on LinkedIn and on Twitter, uh, via those links. So, um, let's talk a little bit, let's spend a couple of minutes talking about, uh, how are view of application security is constantly challenged and disrupted, uh, whenever a new technology, um, is, is, uh, starting to get used and starting to get more, uh, common, um, in, in our technological stack. Uh, so in the beginning, you know, 20 years ago when, when I was, uh, still building web app firewalls at the end of the nineties, um, the focus was really on the application layer.

And that's when, uh, WAFs came to be and later, later on application security testing. And then, uh, a few years later, uh, cloud infrastructure, public cloud infrastructure, uh, became popular. And so we saw technologies or, uh, you know, solutions like, uh, cloud security, posture management, and then people figured out the, the, the complexities of IAM roles and permissions in public cloud.

And so we saw, uh, uh, product categories around IAM security or, uh, referred to as Kim today. And then people started building these applications using infrastructure as code. Uh, and so we saw, uh, scanners for I A C templates and I a c security, and then containers took off and serverless as well.

And we saw cloud workload protection become a thing, a and, uh, generate a lot of buzz around it. And that evolved into agentless scanning, uh, for, for cloud workloads, which is obviously, uh, a method that many people prefer. And, uh, you know, in the past few years, we've heard a lot about, uh, vulnerable OSS packages.

And so S C a or software composition analysis scanners, uh, became the big thing that everybody talked about. And, and really recently we've heard a lot about a p i security. And so a p i security became a thing.

Uh, and every time there's a new, uh, layer of technology that we use in, when we are developing applications, uh, there's a new category of security products that, that, uh, takes our focus from the main thing, which we'll talk about in a minute, and, uh, defocus us or disrupts, um, our ability to apply security properly. So, you know, looking at what changed in these 20 years, uh, in the past 20 years, um, so, you know, may maybe 20 years ago, the the way we developed applications was rather, uh, simple. We had the infrastructure, you know, the hardware, we had the network, we had the application layer, and we had our, uh, our data, the applications data, and it was very easy to secure applications that were built, uh, and were running, you know, they're built in a monolithic way and running in our own, uh, data centers.

We would, uh, probably put a web app firewall in front of the application, put a firewall. The perimeter was very, uh, clear and easy to understand. Everything was inside, uh, this, this little bubble.

Um, today things changed, uh, rather dramatically in the way we, uh, use technologies to, to build cloud native applications. So, first of all, obviously cloud native applications are a lot more, uh, complex or made of a lot more components. Uh, but they are using public cloud infrastructure, and we are using, in many cases, uh, public cloud services like storage buckets and, and databases.

And we use I iam roles to, um, uh, grant permissions, um, um, you know, to access these services. And we have the cloud networking. And if you're using, uh, orchestrators like Kubernetes, then you have the orchestrators and the orchestrators are running workloads.

And then on top of that, uh, you have your own application, which is also broken into many different pieces. You have your custom code and third party code, and you have secrets and microservices and APIs and web interfaces. And you have a, a very, uh, sophisticated C I C D pipeline that helps to automate the deployment process.

And you have infrastructure is code to help you to codify, uh, how this whole thing, uh, gets deployed. And so many, many, many different layers, a lot more than what we used to have 20 years ago. And what happens when you have, uh, more layers, uh, that directly translates to, uh, more security tools.

And that is, uh, a problem with the cybersecurity industry. Our, our, um, um, response as a vendor, our, our response to having more and more layers was to build more and more categories of security products. Um, you know, just looking at a few of those, and really, I listed, I think about a 30 here.

Uh, you have your cloud security posture management that I mentioned, and infrastructure is code security, and then cloud IDs, i p s and cloud incident response and Kubernetes security and container security. And then on the application, have you assessed, and desked and I asked, and, and really a lot, uh, a lot of different products. And the question that you have to ask yourself is, how many security products, uh, do you really need in order to secure an application?

And, and the question, uh, you know, you can twist this question a little bit, uh, by, by asking when is it, or how many products will make you feel secure or make you feel that you checked all the boxes, uh, that you need in order to, uh, go to sleep, uh, peacefully at night? And, you know, beyond that, thinking a little bit more, uh, perhaps we're also, um, losing some things when we're using many, many, many different point solutions. Uh, one might argue that if you choose to go with a best of breed of every point solution, the overall, uh, uh, security coverage that you have is much greater than, you know, just picking a few of those.

Uh, but that's not the, the reality you are losing, uh, when you are using many, many different point solutions. And that's what we are going to spend a few minutes talking about right now. Uh, so really three things that are, uh, are, are a problem when you choose to, you know, to go the way of, uh, using many different point solution.

Uh, the first is manageability. The second is your ability to effectively triage issues. And the third is security.

And we'll get back to that in a minute. It, it sounds a bit funny because you're buying a lot of, and buying and using a lot of security products. Why would security be a pro a problem here?

So, manageability, I don't really need bullets to, to, uh, uh, explain that. I think it's pretty, uh, self-explanatory. When you have a wide range, a wide set of tools of many, many different tools, you need to maintain them.

You ha you need to make them, uh, make sure that they're all up to date with the latest and greatest and signatures, et cetera. You need to have a team that knows how to use all these tools. Uh, so managing a wide set of tools, that's, that's really becoming a problem these days.

And, you know, uh, uh, through a recent survey, uh, that, uh, that we, uh, we are quoting here, uh, we saw that the average, uh, security team for an enterprise uses, uh, around 70 or 76 to be precise, different security tools, which is really mind boggling. Just think about, you know, how do you manage 76 security tools. Um, now let's talk about, I think the more, the two more interesting aspects of, of using point solution.

And one is the ability to effectively trash, uh, issues. So, you know, I have the Tower of Babel here of Babylon here. And you know, the, the way we develop and we secure software today, uh, we have multiple teams.

We have the dev and the DevOps teams. They're using their own tools. They're using I d e, they use a GI repository.

They have their own CI c d pipeline. If they are using security tools, it's probably either, uh, s e software composition analysis or, uh, sast. Uh, you have your cloud security team.

The cloud security architect usually would be using cloud security, posture management and cloud workload protection tools. And then you have your, uh, your SOC team, uh, the operations team, they're using SI and soar, uh, and monitoring runtime events. And then you have your AppSec team or AppSec engineer using a, a DA scanner and the WAF to protect the applications.

Uh, so how do these people communicate between themselves? Uh, and I'll give a few examples. We don't have to go through the entire, uh, matrix here of communications, but for example, the AppSec engineer will run a desk scanner, will report vulnerabilities to the developer, and they will report, uh, based on a U R L because that's what they know.

Uh, and they will, will, will let the developer know, for example, that there is a SQL injection or cross scripting in that U R L. Um, they can also report vulnerabilities to the cloud security team, whether, you know, if they found some problems. The cloud security team will, uh, communicate with the developers, uh, telling them about misconfigurations and, uh, and vulnerabilities.

They will talk about incidents to the, uh, cloud soc. The cloud SOC will talk using alerts, uh, uh, back to the developers or the DevOps team, et cetera. So what I'm trying to say is that each and every team that is trying to help secure this application is talking to the other team using a different language because they're using different sets of tools that don't necessarily speak the same language.

And that is becoming, uh, a problem when you need to communicate that there is a problem. Um, the, so I'll, I'll give you a a a real world example. If you ever tried to correlate, uh, these different tools, uh, you have das that talks URLs and, and vulnerabilities.

You have SAS that talks lines of code and, and maybe different sets of, uh, vulnerabilities. Uh, you have WAF that has events, and you have s e a that talks in packages and c CVE IDs. How do you, uh, correlate these issues?

And many times they will report the same issue, but speaking a different language. So your ability to triage, uh, these alerts, um, uh, is really bad. Uh, uh, you can't really, uh, correlate this.

You can't really triage this and you will end up, um, uh, being very ineffective and, uh, in many cases, uh, going after the same issue from, uh, multiple different angles. Uh, and so what we've heard from organization is that 80%, 83% of organization that succeeded in using DevSecOps and securing their cloud application actually succeeded because they used five or fewer, uh, vendors or security tools, uh, which is something that you, you have to remember. Now, let's, let's go back to the, the third, um, issue, which is security.

And, and that's quite surprising actually. Um, I'm going to start with an example. Uh, and in this example, we have an application, a cloud native application.

Uh, it's a file processing microservice that is deployed as a container in the normal use case. Uh, the user will communicate through a web form and will upload a file that will get stored in a storage bucket. And the client will also send an a p i notification, an a p I call through an API gateway that will wake up the cloud workload to go fetch the file from the storage bucket bucket and run some analysis on it.

Now, assuming there is some V vulnerability, um, like in an open source package inside the container, inside the workload, uh, the way an attacker would exploit this, uh, would be as follows. The attacker will upload some malicious file through the web form to the storage bucket. And, uh, you know, the, the malware will get stored in the bucket, will then initiate an a p I call with the file location, the new file that was uploaded to the workload.

The workload will process the file, the exploit will run, will execute, will explode, will gain remote code execution over the workload. That will then, uh, steal some secrets from the workload, will take over the cloud account and allow the attacker to exfiltrate, uh, data. So as you can see in going back to different, uh, layers of the application, uh, what the attacker is doing here is crossing through many of those layers of the modern application stack that we talked about.

And if you were to try to use separate point solution along the way, uh, they wouldn't be able to understand that, that this is all one attack sequence. Uh, you might, uh, place an a p I protection solution here monitoring the A P I, but there's nothing I illegitimate or, you know, malicious in the a p I call itself is just telling the, the workload what it's supposed to know, uh, that there is a new file, uh, then you have a malware in the bucket, uh, and so forth. So, so placing point solution along the way wouldn't work.

You need something that can look at the entire scenario end to end and understand that there is in, there is an attacker here that trying, that's trying to cross through all of these layers together. Uh, another example, and this is from a real world, uh, very famous, uh, financial organization, uh, breach that occurred in 2019. Uh, this started with an attacker finding a service side request forgery vulnerability in the code, uh, that was running on an, uh, a web server running on an e c two instance.

Uh, the attacker then abuses the service side request forgery to send requests to the, uh, metadata service of the cloud provider. Uh, that's a URL that's only, uh, exposed internally. So the S S R F is, is used to carry this attack.

And the attacker extracts the session tokens that, um, uh, belong to the session of this e c two instance using these tokens. The attacker sets the, these tokens locally on their own laptop machine at home and can now perform or run c l i commands directly to, uh, the a w s account. Uh, what they do first is try to list all the, uh, storage buckets in that account using that IAM role.

Uh, they're, you know, they manage to find some sensitive data in a bucket. Uh, they read the contents of the ba, the bucket, uh, the contents of the file that contains sensitive customer information, and they still, the contents by copying them, um, essentially doing, uh, a synchronization, getting the files back to their own machine, again, crossing through multiple layers and essentially escalating, uh, from, from a, a medium vulnerability. And S S R F would usually con be considered a medium severity vulnerability, turning that into complete, uh, data exfiltration.

So in the cloud context or in the cloud native context, uh, these attacks cross layers and escalate very quickly as you just saw. So let's get back to, uh, uh, the problem of point solutions. When you are using many, many different point, point solutions as you've seen, and these are not a part of one single platform that sees everything end to end, you are seeing parts of the full picture, you're not seeing the whole picture.

Uh, each of these tools is not seeing the real picture. And the real picture is the application. When you're trying to protect an application, you need to think about the application.

You, you don't, or you can't, or you shouldn't think about each separate component of the application. If you think container security, you're missing the point. If you're thinking, uh, cloud misconfiguration, you're missing the point.

You need to see the entire thing end-to-end to understand how to protect it. And as a result, when you're not seeing the application end-to-end and you're focusing on the different layers, um, you, you essentially fail to secure the application. You get a sense of false sense of security, and you have siloed protections that are not really harnessing the power of seeing things end to end.

And we will get back to that, uh, in a minute when I, in a few minutes when I explain, uh, the kinds of benefits that you can get when you see everything end-to-end. So, um, let's take a break for a second. Uh, essentially what you're hearing me saying is that you should consolidate all of your security tools into one platform.

And, uh, you know, if you've been around enough in the cybersecurity industry or heard about, you know, uh, been in touch with the cybersecurity industry in the past few years, you know that, uh, that's not the first time that somebody tells you that we need to consolidate, that there are too many tools. There have been attempts to do that in the past. Most of them failed.

Uh, the question is, what changed? Now that, uh, that brings me to ask you, uh, or to tell you that you need to consolidate your, uh, you know, your cloud native application security tools. And here, I I really want to maybe take a different approach.

Usually a security vendor will try to frighten you about the things that are related to new technologies. I want to show you a few really interesting, um, um, features, um, that are actually very positive when it comes to cloud native for, to adopting cloud native technology. There are a lot of benefits, uh, to adopting cloud native technologies.

Uh, the first is that deploying security solutions, uh, has become super simple. Uh, I'm sure that if you're, if you ever deployed cloud, you know, uh, things in the public cloud, you've, you've clicked that button before, you know that button, that's when you launch a cloud formation, stack it, it really takes one click to deploy, um, a security solution where, you know, in, in the past you needed to deploy, uh, maybe a box, you know, a physical, uh, server or to deploy an application and install it and learn how to use it. Today, it's a one-click thing.

Uh, you grant the, um, the security vendor access to your cloud environment, and they start doing their thing, doing their magic, you know, uh, uh, uh, giving you visibility to the problems, et cetera. So super simple installation in the cloud, uh, native world. The other thing is the co codification.

Uh, I talked about infrastructure is code templates. So everything, uh, in cloud native, uh, can be codified. Uh, and that allows us to trace, uh, from code to cloud, uh, how the application, uh, should look like.

Uh, so think about, uh, in the past when, um, when somebody logged or maliciously logged into a server that you owned and changed something, there was zero capability for you to know that something change, unless you have some kind of security controls today, you can look left inside the, the, the code, your code repository, see the exact recipe of how the application should look like, what are, uh, the components that make up the application. Then look to the, to the live production environment and see whether, uh, there was a drift. Uh, whether what you have running is actually what you intended, uh, when you, uh, developed the application on the left, you know, inside your code repositories.

Uh, the second thing is, thanks to, you know, the microservice architecture that is very common in cloud native applications. Everything is broken down into very small, uh, units, um, computational units. Everything is very focused.

You have a microservice for, uh, logging user in, you have a microservice, uh, for running some kind of file transformation. You have a microservice for, for a shopping cart. It's very easy to analyze these microservices.

They are not a monolithic, a huge, uh, behemoth of a monolithic application. It's very easy to understand and to analyze these microservice and the interaction, uh, between them. And that really helps from a security perspective.

And it also allows you to very easily model how the application should behave. Uh, for example, a microservice that, uh, its only purpose in life is to log in, users in, into the application, obviously shouldn't be running, uh, uh, crypto mining operations doesn't make any sense. So it's very easy to have some kind of AI or machine learning model that models the good behavior of the application.

And then, uh, flags anomalies. Uh, it's much easier than it used to be, uh, when we had monolithic, uh, not cloud native applications. So there are really a lot of opportunities from a security perspective when it comes to, uh, adopting cloud native technologies.

I want to take a step back and talk about, um, what I refer to as the cascading effect of modern software development and the modern C I C D pipelines. Um, so, you know, if, if we look at, uh, modern software, obviously using open source, uh, packages, and that package, uh, will usually, will usually be used, uh, in multiple, uh, code repositories, multiple projects, each of these code repositories, uh, generates, uh, or is a part of a bigger C I C D pipeline that, uh, you know, that creates, uh, the artifacts. And so of these pipelines, we have numerous container images that are getting created.

And, you know, you have one software package. It goes into multiple code repositories that generates multiple, um, uh, C I C D pipelines that generates multiple container images. This keeps on growing.

Uh, and this gets deployed in, in many, many different, uh, for example, Kubernetes clusters on many different cloud accounts and, and cloud regions and, and even multiple, um, cloud services. And then you have, uh, these container, uh, uh, these Kubernetes clusters are running many, many, many container instances, some of which contain that software package. And I, you know, I, if we assume that the software package could have a vulnerability, you end up with one vulnerable software package that quickly cascades into a problem of thousands and thousands of vulnerable, um, running container instances.

And, um, you know, at the end of the day, this means that, uh, when you look at the live environment and you start scanning it, for example, you know, you using, uh, legacy tools that scan each instance for vulnerabilities, you get 5,000, um, alerts. And, uh, th that is, you know, think about the problem. Uh, we started with one software, vulnerable software package, and we ended up with 5,000 alerts.

And software packages is not the only thing that, or vulnerable software package that can cascade, uh, other things can cascade as well. Uh, when you have an issue in an infrastructure as code template, a misconfiguration that cascades as well, when you have a vulnerable open source package that cascades when you, uh, buy mistake embed a or a hard code secret into a piece of software that cascades to the many, many different instances. And so for, uh, uh, the same for vulnerabilities in your custom code application configurations and flawed business logic, one flowing business logic gets replicated to thousands of instances.

And so, um, you know, looking at this cascade effect, uh, the ability to trace from code to cloud and sometimes even from cloud to code, can allow us, you know, assuming we have this capability to trace back these 5,000 errors to the single line of code that actually, uh, generated that snowball effect. And that's what we would like, um, our platform to be able to do. We would like it not to alert on 5,000 different instances of a problem, but rather point to the code, commit the single code commit, and that specific developer that created the problem and let them know that, uh, they need to fix it in one, uh, uh, very, um, specific location.

And this brings us to cloud native application protection platforms or synapse, uh, as they are referred to. And you know, you will, you will hear about synapse from many different angles. Different vendors arrive to building a synap from a different perspective.

Some will tell you it's related to cloud security. I, I, I really dislike that, uh, idea that's not the purpose or a synap or, uh, a, a cloud native application protection platform is not a cloud security tool. It is actually a platform that helps you to first of all, uh, gain visibility to the problem that you have in your cloud native applications.

It then provides you with tools and controls to prevent risks from actually getting deployed. And in, uh, at the same time, it provides the ability to gain insight and prevented and deploy preventative measures, real-time preventative measures, uh, during runtime and what sap, uh, should give you. And that's, that's the whole, you know, the, the, the vision behind this, uh, the platform is many different, uh, security controls, uh, or, you know, um, um, you can call them guardrails in, in some, uh, places that map to different locations in your C I C D pipeline in your application lifecycle.

You know, starting from the left with code scanning and source composition analysis, scanning for secrets in the code, uh, scanning infrastructures, code templates, um, um, you know, making sure that your supply chain is secure. Your C I C D pipelines, uh, cannot get poisoned or, or accessed by unauthorized, um, entities. Then during the deployment, you want to, uh, perform vulnerability scanning as part of your C I C D process.

You know, you build the images, you scan the images, pre-deployment, and then as we move to the right to the runtime, you have cloud workload protection and cloud security, posture management, uh, and, uh, cloud identity and title management or ia, uh, IAM security and web app and a p i security, and of course, data security to, to make sure that, uh, your data is not exposed or leaked in any way. So a cloud native application protection platform should give you all of these different, um, controls and guardrails throughout the application life cycle. And, um, and this is really the final section of our, uh, of our, our talk today.

Uh, I'm going to give you a, a glimpse of, you know, uh, some of the good stuff that you can get, some of the benefits from having a single platform that sees everything, uh, end to end. And, uh, we'll take the, the, the, the case, uh, the, the very interesting, uh, case of API security and reconstructed in the, in, in, you know, um, from the perspective of a, of a synap. And, uh, again, I, I don't believe in the term API security, it's all application security, but, but I, I thought it would be a good and interesting, um, um, demonstration of the power of a synap.

So, uh, if you ever, uh, if you've ever done a p i security to some extent, you know that there are certain tools that are being used for doing that. Uh, you know, the security team will use an a p security tool that will list the a p i endpoints, perhaps alerting about some risks to the API endpoints. But that's what it does.

It looks at traffic, it alerts you on risk to the API endpoints. And then at the same time in your organization, you probably have somebody running some kind of software composition analysis on the code flagging, uh, you know, vulnerable packages. So you have one person working on the code on the left, finding vulnerable packages, one person working on risks to the A P I endpoints on the other side of your organization, and, and they don't talk to each other.

And then you have yet another person that's responsible for cloud workload protection, perhaps your SOC team or your DevOps or second DevOps team. And they are monitoring the cloud workloads, uh, checking whether they are vulnerabilities or attack events. And, uh, these three people are not really talking, uh, between themselves.

Uh, each one is concentrating on the different aspects, uh, of the problem. So you have three teams, uh, using three different tools, getting three different alerts or, uh, events, and you have one application. So you can't really expect these three people to be able to triage the pro, uh, the problem effectively.

And the synap approach to doing that, uh, would be all in one platform that's, that harnesses the power of seeing everything, uh, from all of the different layers. So you start with the visibility to the A A P I endpoints and, uh, the platform can alert you about risks. For example, we detected that, that a p I endpoint, uh, uses sensitive data, uh, that the endpoint itself, uh, does not require a syndication, that it's reachable from the internet.

But then the platform, because it sees other layers, like the container layer for example, knows that there are risks to the workload itself to the container. There are critical severity vulnerabilities. Uh, the container can be, uh, accessed over the network.

Uh, you can gain remote code execution. Uh, there are some packages that are being used in runtime vulnerable packages that are being used. So that's another set of risk factors from an underlying layer, not the a p I layer that definitely affect the risk to the API itself because the ha the API is running on the cloud workload.

And so you can obviously ask the Cena platform to apply real time protection, not only alert about the risks, but actually prevent the risks using, uh, the web application and a p i security module that, uh, that it provides. And then it can also provide at the application layer, uh, the ability to, uh, uh, virtually patch some of these exploitable packages. So for example, let's say we found a log for J vulnerability inside a package running in the container that's hosting the A P I and the package is news.

We can then apply a virtual patch and prevent that specific attack, uh, giving you the time to go and fix the code, update, uh, uh, the vulnerable library and so forth. So as you can see, uh, we started with a very small narrow, uh, mindset of we're coming to do API security, but then we harness the power and the visibility of seeing through all of the different layers because we're using one platform that sees everything end-to-end and can prevent at all, uh, different layers. Um, so, uh, just to summarize this unified approach obviously answers the problem of manageability.

You have a single platform that gives you full stack cloud native application security from code to cloud. Uh, it can allow, uh, much better, uh, triage of issues. You can connect the different dots.

You don't have to look at different issues from different perspectives and not know that there are all the same problem. And it gives you better security, uh, because you're collecting signals from all of the different application layers, uh, and you can apply as you've seen here, and much more intelligent and more, more secure and more capable, uh, um, uh, protection layer. And that is the whole point of, uh, using a cloud native application protection platform like, uh, Prisma Cloud in this case.

Uh, and, uh, by that, I'd like to thank you for joining me and, uh, um, enjoy.