Daniella Pontes, Sysdig | DevOps Connect 2022

Hello, everyone. This is Daniella kons. I'm a security product marketing manager at cystic.

And today we are going to talk about how you can automatically prioritize vulnerabilities using runtime intelligence. With the agenda. I always like to give an overview of why we are we are here talking about this.

What is the scenario? What brought us to this situation and then we are going to dive into exactly what we want to address which is elimination of noise and prioritization of what matters. But once you have accomplished that what else you can do, you can improve your security with the shift left kind of approach but also look to the your right side, you know, make sure that remediation also is is enabled and optimized.

Then we are going to do a demo so I can demonstrate what actually I'm talking about and I will spend a couple of meeting minutes talking about sissy introducing you to cystic. Let's get started. Vulnerability management is nothing new you, you know, we we have been doing this for a long time already and vulnerabilities are nothing but the bug a bug that can be exploited by the cyborg crime community and they are growing and they are becoming more active.

But why it's now something so important that we need to revisit and see what else we can do to make it better first. I'd like to bring attention to the fact that we have an accelerated development. So we are bringing more code to production and we are doing this faster.

so vulnerability Management in the past was something done after deployment introduction was scheduled and you would do a scan on your your code, you know in your application, you would find vulnerabilities and you would allow yourself sometime to fix them that cannot be the the case anymore deployment is done in a pipeline. And if you wait until you production to do your first assessment, but the time you're done with that first reporting you're hit with another deployment and everything that you you did. It's now no longer out is outdated.

So the attacks of places completely different because you have a new code out there. So we have to move away from that pointing time kind of action, but regards to vulnerability management, but there are more differences in terms of what we are dealing with one of the reasons why we are developing faster and bringing code faster to production is because we are using a lot of open source and there is nothing wrong about it. That's exactly why you know, the developer communities putting out there source code that others can build on top.

So but what is what happened is a lot of their layers and dependencies that are included in in your final application comes from open source that has vulnerabilities those projects. Sometimes don't have enough resources to keep up with, you know, what's going on in in the cyberlands and space and also they keep all the version of there for many reasons some of them being because people But you need that so you have more. code coming to production and codes with more vulnerabilities because they have more dependencies on other third party codes like open source.

So what this is creating is a vulnerability backlog because now you have a lot of vulnerabilities in your application. And the reason is because you are building fast with third party code and then if you just stop to fix all the vulnerabilities that this is in that code now you you lost their advantage of the developing fast, and that's your your main goal. So what's going on is we are not dealing with that vulnerability load up front, you know, and the volume is so high that you feel that you know, you cannot make a dent in in the scale.

So they have develop the backlog is growing. But there is a fourth aspect which is that we are in a society that is built and driven and supported by software is our infrastructure is our hospitals our education. It is our you know our business and and this is like this is something that is a really critical to the society.

And today economy. A lot of countries are now bringing out, you know laws and and requirements for organization to make sure that the supply chain of the code that they are bringing to to production they're using it's actually secure. So I have here some some statistics.

One of them is from the Linux Foundation report recently that they shows that 98% of organization in both in the public and the private sector Using open source. So we are really exposed to all the vulnerabilities that we are bringing to our code and using in production. And another interesting statistics is from our report this year about in for cloud native and and usage that shows that 75% of the containers in production have high in or critical interview vulnerabilities.

So that vulnerable the backlog that volume is actually is a reality, you know, and it's getting into production. So what are the challenges that vulnerabilities are created in cloud-native in environments today? Well overload and allowed fatigue.

We are one single container can have hundreds of vulnerabilities thousands of vulnerable to sometimes and how do you go about dealing with that? So you have three personas in this environment like the security the devops or the Ops teams that need to make sure the environment it's it's safe to run and you have the development teams that needs to deal with the vulnerabilities that needs to be remediated. And they are all facing this overload.

And what what's what happens is that they not only they cannot handle it but in the mix there are very critical dangerous vulnerability that they miss and also even when they find them the lag time to find and remediate is increasing so you have a larger risk exposure window out there. And because everybody is dealing with an amount of vulnerabilities or or requirements that they they can barely put their hands around it creates friction because they cannot find in time they cannot fix in time and they cannot protect the environment against you know, the Cyber threats that they are facing. What about prioritization?

Yeah prioritization is great and we have been doing this but ineffectively I actually would like to call attention to this quote from and about it's one of the most common way to fail all I would say the fastest way to fail in vulnerability management is by simply giving someone a report with tons of them to be fixed. We all know what's gonna happen. The report will stay there and you continue doing what you were doing before because it's just the obstacle in front of you is so so challenging that it basically paralysis.

But what why we are not doing a prioritization effectively when you have a lot prioritization is what needs to be done. You need to find in this amount, which is the one that will move the needle well because the way that we our Solutions out there have been trying to prioritize vulnerabilities first based on CVS as the score that are completely out of context they have no they have no intention to tell you exactly what risk you're exposed to in your own environment. And even if you use the scores like just based on you know, okay, let's see what this critical and what is critical and it's in my in my environment.

You still maybe you go from 500 to 100 that you still have. You you didn't manage to reduce the volume to to the size that you can actually handle so it's completely ineffective another kind of prioritization that you you see out there is very high touch, you know, before you produce any results in terms of reducing the amount of vulnerable that you need to pay attention to you need to know the environment. You need to know about security.

You need to know about the application to apply all the risk factors. So it's really again not scalable and that doesn't bring you to manageable size because all of them are failing to remove noise. a lot of the vulnerabilities that comes to the runtime environment they are in packages that are never used as a mentioned before the way that we are building application.

Today is by just using open source that comes in libraries in packages and in Frameworks or even in pre-built images that we just use as part of the image layers in the final build. You need those to build the application, but when it runs a lot of the package actually the majority of Patrick are not used or the packages with vulnerable of this are not used they are never loaded. So they don't pose any risk to your environment.

If you don't find those you don't remove those whatever vulnerability prioritization that you are doing. It's it's you polluted with noise. And that's what we address.

With risk Spotlight, we do automatic parallelization by removing the noise, which is from what we've seen in our customers environment can be up to 95% of the volume of vulnerabilities that is assessed because even packages that are not used to produce in your assessment a lot of vulnerabilities, which is just noise. And by also understanding what is used in at one time, we can automatically prioritize the vulnerable to show you up front the vulnerability that is really exposing you to risk. And for that you need nothing in terms of you know, you you need to provide additional input or if risk factor based on the application the or the environment is just the the system cystic intelligence runtime intelligence looking into your system when they application is running that we can tell the truth about what expose you to risk or not.

So it's skills because there is no need of the human factor to be added in the process. One thing that I would like to call attention to is we need to keep focus on risk and what do I mean by focus on this even after prioritization when you come to a handful of vulnerabilities, sometimes you cannot fix some of them first, they could not have a fix yet. But also sometimes you just can't fix in your environment because it would disrupt an application that you know, you cannot or don't want to have downtime.

So your security team needs to do another assessment level need to understand this the risk of this application from a broader lens, you know understand, you know, the the factor the CVSs Vector in terms of what are the risk factors and how it is qualified for your environment also check the exploits available for that vulnerability and if they can be effective in your environment, so having reach Us to data regarding a vulnerable. It is also very important for that second phase if necessary. If you need to understand, you know, I cannot fix this vulnerability, but let me see what kind of risk I'm exposed to.

And as I mentioned, you know, the work is not finished by just identifying what you need to fix and how fast and what is really exposing you to risk. You need to you need to actually get the Remediation in place. Who does the remediation the developers they don't understand all they don't need to understand or don't want to understand the security aspect of each one of those vulnerable.

They don't talk vulnerables. They talk packages, they talk package because it's packages that they bring into the application to support the code that they create. So we also provide that kind of visibility.

They we give them the information about the packages that needs to be fixed because they have great government abilities exposed that one time and we point them to the exactly fix version. And because we also tell them the ones that are not exposed at runtime or they are never used, you know, they can go back and start removing specific packages kind of that that feedback to the shift left security to make shift left more effective and optimized. Now let's go to do a quick demo.

So you can see you know what I mean in real life. So here I'm at please dig secure platform. And as you can see here, there are multiple different ways that we can help our customers in terms of security use case and I will give you a brief overview after the demo, but now let's focus on vulnerability management and we can do the entire life cycle of your container, you know from the pipeline to the runtime in a continuous way a security cannot be a checkpoint security needs to be continued, but let's see at the wrong time.

So here are the containers that we have in our environment and you can see some of them has really large amount of vulnerabilities for this demo. I always like to find applications that are commonly used and found an environment. Let's see this nginx here.

When I open this container, I'm already kind of overloaded by this number here 447 vulnerable cannot put my head my head around I cannot even you know move towards that because I don't know where to start and even if I try to just look for the the critical ones I ask you have a lot and they don't even know if those are really relevant. So what I need to do is to apply the sense of what is exploitable exploitability and what Paul's a chance of exploit first thing is to use our runtime intelligence to see what vulnerabilities I've tried to packages that are exposed or loaded at one time here already reduced the amount of vulnerability that really deserves then kind of attention to to a good bunch. And then I see which ones have exploit available.

They the activity that we see in the in the cyber crime. Escape it's important indicator of what kind of threat I'm exposed to. So here are the ones that have exploits available and If I want to know which ones has a fix I'm down to the very one that I can take an immediate action, but knowing the ones that are used in an exploitable is important as well because the ones that don't have a fix actually pulse, you know, a high risk in my environment.

So and that's where we provide, you know, very rich vulnerability data. We provide for multiple Source, they're not always agree and it's exactly when they don't agree but you need to do to take a closer look because that shows the it has different impact depending on how the the environment exposed that vulnerability also we provide a link to available exploits. Once you have the exploit you can actually test that exploit against your defense and it Like your own code and and and and vulnerabilities, you know, they have dependencies also certain things needs to be in place certain conditions need to be in place.

So by understanding the exploit you also understand better your exposure. So another thing that I would like to show is that the third Persona that we serve with our solution is is the developer the developer don't don't care about you know, the vulnerability itself. It will not try to fix the vulnerability would try to fix the the package by finding the ones that are exploitable the ones that they can fix and there was that expose to risk.

So the same workflow they can go to the ones that I know. So the ones that they exploitable and there was that they can have effects so developers now with no time, you know trying to put their heads around 400 plus vulnerabilities and try to find the packages that would have the best effects in terms of you know, getting rid of, you know, a large number of vulnerability. There's a really exposing the company to threats.

So that's basically the demo that I wanted to do today. let's go back to our presentation let me talk a little bit about systic. We have Builders.

Yeah, our founder Laurie is the co-creator of Wireshark that you know Network tool that, you know provides deep visibility and the so-bloft and he also created Falco Falco is the threat detection engine which is a you know, the factor standard for cloud native environment in today's part of the cncf, you know incubation a project. We all end. It's a popular tool in the open source Community.

We are over for 14 million downloads and all those 40 million downloaders are actively using Falco creating a detection Behavior detection kind of of policies policies to fight, you know, the threatening scape. They're facing in India production environment. We are also partners of with our customers.

We also partner with our customers and and everybody in the ecosystem. We are very ecosystem friendly. For example, AWS shows us to be the solution to protect in To protect their serverless platform.

We have a very deep and and differentiated integration with them as is Nick showed that shows us to provide to complement their security portfolio with the with our runtime protection. They see us, you know, the the best solution in the market and we have a mission to make Cloud deployment as a small secure and reliable and indeed what we want to enable is companies to continue developing fast because security should not be a barrier or is low down the development. Actually we believe that security is an enabler for them to just concentrate in building more code.

Because we take care of the rest. So here is just I'd like to give you an overview of what kind of use case security use case that we help our customer with. We provide security from source to run.

We are there in the very left, you know securing your infrastructure's code, which means your terraforms your kubernetes Helm charts. You make sure that they configuration controls in those forms that will be the the infrastructure base for your code in production. They are checked for security policies or compliance policies that you have in place.

At the build phase while you're building your containers. We are there providing vulnerability management. We check in your Registries or in repositories that you you get your package from and we keep doing that continuously as you deploy in at runtime.

We also continue looking because vulnerability something that is always yeah. It's a dynamic environment. The idea found new ones are found and more and more.

We find more what's called zero days with zero days exploits. And we provide this risk prioritization through runtime intelligence because we are at the end the whole cycle we know what is going on at runtime and we use this intelligence to help the entire cycle at runtime. We are there helping you to make sure that you're configuration and permission Management in the cloud at the right place.

There are no excess privilege is one of the main reasons why a bridge becomes a disaster. So we do make sure that we check that for you. And also automatically we have a layer of policy centralized policy that you can apply consistently, you know through the entire life cycle threat detection is is the you know, this is dig.

I would say our specialty many ways we because we have powerful this threat engine that this very powerful and flexible. You can use Falco to describe and detect any kind of malicious delay. If you are normally we also have drift control to block attacks based on you know, making sure that what is in production cannot be modified.

So no new executables are allowed to run and we Implement native kubernetes micro segmentation. We use our learning mode capability to understand. What is the communication profile and we automatically create the policy that you can apply to your kubernetes and we provide incidents response.

We our Solutions provide the most detailed and granola data that you can get for forensics analysis and doesn't matter how long your container runs one minute or you know for for hours a day. We are there to detect and collect information about the events. So even after the containers gone, you can still respond question the same what happened before and after the event and we help you also to Get the Remediation in place.

We provide you direct access to compromise containers so you can do local investigation and also mitigation and we apply compliance checks. From your source to run in all this this phase. So here we are we provide you a single view of risk.

We prioritize what matters we are based on open source, that's a core Foundation of our solution and we help you to be fast and scale and keep security as part of your strategy. So you can continue building application fast without exposing your company to your organization to risks. Here, I have some content that you could access from our website for you to dive deep and deeper in some security aspects, but we actually have a lot of content there.

We are very committed to educate our customers and Prospects so they make the right decision for their organization. So, that's what I had to present today. I hope you enjoyed.

Thank you.