Dinesh Mistry – See How to Develop Secure Cloud-Native Apps

Hello everybody. My name is Dinesh and with deep factor. And today I'm going to be talking to you about developer security and specifically the Deep Factor platform.

I'll give you a short introduction into what factor actually does. So then I'll jump directly into a demonstration just for note. I head up our customer excellence in sales engineering nearing team here at Defector.

So with that I'll go ahead and jump into the first slide. So deep factor is designed specifically for cloud native application. So even though this context of the talk today will focus on microservices and containers.

Our platform is absolutely supported on monolithic and Legacy application Stacks. But if you take a look at Cloud native applications, there's really three areas that make up an application. There's the front end which is usually what's accessible by the customers.

There's some middleware. This is the application code that organizations owed and then there's a back-end database. So today we'll focus on the specific service in this case.

It's called my service. If you take a look at the container that runs application code there's really four areas of risk this the application code that the developer owns and controls as well as dependencies that application brings into support its functions. And in this area what factor does is we observe the application during runtime and by runtime, I mean when the QA team is going through and doing nightly regression tests, maybe some basic acceptance testing to identify any vulnerabilities as early on in the development process as possible.

So here we're identifying things like hey is my application subject to remote code execution. Is there any insecure Network Behavior happening? Is it making an outbound call to a nation state?

For example, often third party dependencies are not reviewed by the developers and they could be doing something nefarious without a developer actually knowing And then we also look at the supply chain. So by supply chain, what we're looking at is the vulnerable dependencies and operating system packages that the application is using up at the uni think about beat factor is we're actually only generating alerts if your application is using these third-party dependencies, so a great example here would be for example, if you're developing in Java and you've imported the vulnerable version of log4j Deep Factor will monitor the application as it's being exercised and if that code path for that particular module gets exercised will generate an alert and this drastically helps reduce the alerts that developers have to consume. We don't want to be generating hundreds of alerts.

We want to be very action-oriented. We also have the ability of the things like license type. So is the dependency importing the GPL license?

Lots of organizations are sensitive to GPL licenses, for example, because it may require them to open source part of their application. And then finally there's some type of web or API interface. So this may be microservice to microservice communication.

Maybe it's something that's directly accessible by the end user. But here we're going to assess the application for the loss top 10 type vulnerability. So is there any bullet type issues?

Is there any SQL injection cross-site request forgery Etc? And then finally with the executive order that was issued mid last year. We also provide a comprehensive bill of materials.

In fact, we actually provide a dynamic bill of materials. So not only do we provide you with all the packages and dependencies that are installed inside of the container, but we take it a step further. So also identify all the licenses all the processes all the ports connections Uris URLs Etc.

So you have a very comprehensive view into a lot this particular application is doing And then finally, we actually take the alerts that we generate and we map them back to compliance Frameworks today. 2 type 2 and this 853 and these are actually specific to the application. So when people think of compliance or often thinking they're infrastructure in our case, we're actually saying hey, you're exposing an environment variable that contains sensitive information and that would potentially be in violation of PCI and sock 2.

So how is it that the factor actually gets instrumented or installed into your application? Well, it's actually quite straightforward. So in this example, we're talking specifically about kubernetes.

It's a one-time install. It's actually a Helm install. We install a mutating web hook and we pass it some parameters and the parameters are very configurable so it could be hey watch my entire namespace watch these particular pods exclude these particular pods.

And then that's it from there on the developer is completely hands-off. So if you think about a typical ci/cd workflow the developer works on his or her laptop or desktop, they build the code. They push that code to some type of source code repository a job kicks off.

It builds that container and then it automatically get automatically gets deployed into a kubernetes cluster. So in the QA team is going through and running its nightly regression test or some basic acceptance testing that's happening deep factor is observing for all those components that we mentioned earlier. So identifying application risks supply chain risk compliance risks Etc.

And then in real time, we're actually sending out notifications. So we understand that developers may have their preferred methods to consume alerts. So we support things like messaging platforms such as slack.

Maybe they want to look into the UI itself to investigate further, or maybe they just want to have a ticket created and assign if anything is greater than the P2 for example, so it's very simple from a developers perspective and you'll see how easy it is here as I jump into the demo. So if you take a look at the Deep Factor interface, we make it very easy to consume applications. So the flexibility is up to the developer or the consumer of the product in my example of actually just grouped by components into individual applications.

These can be individual pods. They could be you know, split across multiple kubernetes clusters again, this is just all based off labels and is very simple to set up. So here you can see I've got an application.

It's rather. I've got five applications. Some of them are just running a single component.

I've actually got a full application deployed call Bank of anthos that's made up of nine components. Um, and the rest of them are just single components. So what I'll do is I'll actually show you how easy it is to deploy deep-factor with your application.

So if I switch over to the terminal here, you can see that on the right hand side. I'm showing my development namespace and I'm going to actually just change into this python directory, and I'm just going to apply. This manifest so this process would typically be automated through your cicd pipeline.

In this case. I'm just manually going to go ahead and apply it. So once I apply that you'll notice that the application comes up in the namespace just like you would expect it to but the developer hasn't done anything special.

The Manifest files are exactly the same. And now if I switch back into the portal and refresh the page, you'll see that that python application has registered itself. Now within a few minutes all the Telemetry and all the data will start flowing into the system.

Now from here to analyze or to take a look at the alerts that have been generated. It's quite straightforward. So for example, if we pick on this Bank of anthos application, all I would do is click on that application and now I get a application specific view of all my security risks.

So here you can see all the components that we covered earlier. And again, this is across the nine components that make up the bank of and those application. So the first representation here is the runtime alerts.

So these are all those behavioral risks that we talked about. Is there anything insecure happening from us file system perspective is my application making some type of insecure network connection and you can see that we've identified alerts in this particular category. And then in the middle, we show you all the dependencies and we understand that you know, each application may be actually made up of varying programming languages.

So this particular example, we have the application that's written in both Java as well as python. I'll put in total we've imported 723 dependencies of which 136 are actually vulnerable but you notice that we've only generated 90 to alerts and going back to my point earlier. The reason for this is because even though we've been ported a whole bunch of modules and a lot of those of vulnerable our code path is only executed 92 of those vulnerable dependencies.

This means that these are the ones that the developer needs to action first. Of course, that doesn't mean that they may not want to go back and remediate the others but they now have a prioritized set of alert setting and Target unlikewise. We showed the number of license risks.

So in this case, I've got a policy that says Identify any licenses that have type GPL and we've identified 43 and I'll show you a little bit more detail about this here in a second. We do the same for the operating system packages. So again, you can see we've got over 1300 packages that are installed a little over 550 vulnerable packages, but we've only generated 43 alerts.

So again, The code execution path only loaded 43 of the libraries out of the 578 vulnerable ones so you can see how we're actually reducing the amount of alerts that the develop would have to remediate. In the bottom here, we're actually mapping the total of the 217 alerts and seeing if they violate any of the compliance Lord so you can see out of the 217 170 would be in violation of PCI 26 for stock two type two Etc. And then we talk about the bill of materials.

So again, we're a dynamic bill of materials. So we'll give you things like what are the languages that make up this application how many total dependencies and how many of those are vulnerable but we also identify things like the network listening ports. How many web services is my application exposing.

So again, you have a very deep understanding of what makes up your application. And then finally on the bottom left here, we show you any of those web and API risks. So these are the old wasp top 10 type risks.

So these are things like HTTP requests spoofing any type of information disclosure Etc and we'll dive into each one of these sections here a little bit further as well. Now you may be thinking well, I'm not responsible for every component in this particular application. So what we do is down the left hand side, you can actually look at each individual component that makes up this application.

So here you can see that we got the nine components and we've broken down those alerts both from a security and compliance perspective across each individual component. So if you're a developer and you're responsible only for the balance reader component, you can come in and say hey just give me a very specific set of alerts that I can take care of. And again, these alerts could be sent in the form of slack messages or jira tickets Etc.

Now if we go back to the application, we'll actually drill into a couple of examples here. So if you think about the runtime, this is the behavioral characteristics of the actual application. So let me just give this a quick second to refresh this page.

If we click on runtime, you'll get a list of all the alerts that have been generated. So, you know, this is an example. So it's quite straightforward.

In this case. It's a P1 violates both security as well as compliance and we've identified that there's some processes that are running this route and which components this exists in and what category they're actually mapped to if I click on anyone of these alerts, it'll give me a lot more detail. So not only do we tell you which component this vulnerability was identified in but which application did it belong to what category does that map to as well as a compliance Frameworks?

2 will tell you the specific subsection within that framework so you can do some further investigation. Now this example is quite straightforward, but we do provide detailed description and resolution. So here we can see that the description states that you should probably not be running your application with uid zero or group zero and the resolution for this would be to run that service as regular user if we scroll down you can see which processes were actually launched.

So in this case, you can see that it was a dash shell as well as a python executable in a you name that was executed. On the right hand side, you can take some actions directly within the console so you can mark this as not an issue and then we won't report this again. You can do things like file a ticket directly from the console.

So if you were integrated into one of your jira providers, you'd be able to take the contents of this alert and send it directly over into jira. So I'll give you another example of some runtime. So I'm going to switch over to another application.

So this time I'm going to look at a C++ application and take a look at the runtime. So earlier we we talked about, you know, bad activity when it came to network behaviors. So again, this is a contrived example, but we can see that what we've done is we've identified that there's an outbound connection that's being made to have prohibited country that this could very easily happen.

If you've imported dependency that is doing something nefarious. In fact, this is quite common, especially with things like npm packages. So this time when I click on the alert, you'll see that it looks very similar, but we provide a little bit different information.

So again, we'll tell you where it occurred the compliance Frameworks the description and the resolution and then this time in the details, you can see that we actually show you things like what was the remote IP address the port the country that this particular application talk to? Finally give you one more quick example in the runtime space here. So here you can see that we've actually identified that it deterministic.

Random. Number generation. API was used.

This is something that would actually be in the control of the developer. So again, the detail description tells you why this is potentially bad. So historically the use of this is an error-prone but you know, what is the actual resolution right?

So we don't want to alert you to something that could potentially go wrong or has gone wrong. We actually encourage and show the developer had to remediate this. So in this case we say that you should use a function like s-rant or S.

Ran 48 In this case since it's the code that you guys own we actually also provide you with a stack Trace. c in or around line 31. So again, the goal here is to provide the developer with as much contextual information as possible and to help them get into the area of the code without having to hunt around within their source code Repository.

Right. So what I'll do is I'll switch back over into Another one of these applications here. So if I go back into Bank of anthos, for example We'll give this a quick second to refresh.

This time I'm going to look at the dependencies. So here are all those vulnerable dependencies. The one thing I'll also point out is we have integration.

So in the in this particular demo, I've got the black ducks synopsis integration configured within this demo, but if you don't have a CV a cve or a provider that you want to integrate with the fact, it does provide one out of the box, but here you get a prioritize set of vulnerable dependency. So you can see we have 53 vulnerable dependencies what the name of that dependency is. And if you click on this and we've actually grouped them all together because it's it's all part of the spring application or rather.

Dependency. We give you the version which components are affected Etc. And then we give you you know, what is the CVSs or the CV ssv2 scores and then lots of information about what this particular vulnerability entails.

So here we give you a detailed description, but we also link you out to various sources to get some further information. If you also wanted to look at all the dependencies, you could come over to this tab. And now you can see all the dependencies that have been installed.

But if we go down here and we actually click on one of these for example if I click on the spring boot. You'll see that this time what we've actually done has got a little bit further than just identifying that there's a vulnerable dependency in Spring boot. We're actually able to trace all the way down to the method and classes that are being invoked by this application.

So in this case, you can see that there were 52 classes. Start rather 52 classes and 187 methods that were invoked and this is particularly useful. If the dependency that has a vulnerability is something that could cause a breaking change for the developer.

So upgrading to the next version or the higher release of this dependency may not be feasible. But as a developer, I could go and read up on that cve and see if the particular classroom method that is vulnerable is being used by my application. So here if I scroll down I can see the green check mark represents the paths that my code is using so for example, if the vulnerability existed in this thremp thread dump endpoint, we're not using it so I can have a little bit of confidence that I can take a little bit of extra time to go ahead and remediate this particular vulnerability.

We do the same for the OS packages. So I'm not going to dive too deep into these but it's a very similar format. We show you the CBE the packages that are involved.

We'll show you things like the fixed version and again the detailed cved information. The bill of materials shows you the complete list of all the dependencies OS Packages Etc that have been installed by your application. So here you can see all the dependencies any of the severities that we do the same for OS packages, but here you can also identify all the listening ports of that application is listening on what are the incoming connections that are being made.

What are the outgoing connections of this application is making so again lots of information to understand the security posture of your application. In fact, we actually capture all the Uris that this application exposes as well. Finally, we have the web and API.

So again, these are the owasp top 10 type risks. So here you can see that we've identified a few items in this case. There's no p1s but we have identified that you know, there's a couple of content security issues and there was no policy header set here.

So when I click on this alert, it looks very similar to all the other alerts so a very detailed description a detailed resolution. We also link out to some references. We actually tell you where this exists.

So in this case it exists in a few Uris the method in which it was invoked the confidence level, but here we also capture things like the request header the response Center and the response body. So again, we give you lots of information to help resolve this now as a developer, I may want to understand how this looks within my development environment. So we also provide this copy curl command.

So sitting in front of my workstation, I could simply copy this and see this execute within my development. environment as well And then finally, we have the same view from a compliance perspective. So again, these are all those alerts but they're now mapped into the compliance Frameworks and you can see the compliance Frameworks that they would be in violation here on the right hand side.

In addition to the the depth and breadth of coverage that the factor provides. We also support a bunch of Integrations out of the box. So we'd already talked about some of these but we integrate into CI pipelines such as gitlabs Circle CI Jenkins Etc.

You can configure project management tools single sign-on providers SCA tools as well as messaging platforms. And we also have a full API. So if you would like to integrate into some solution that we don't have an out-of-the-box integration for we have a very extensive API.

It's very well documented and you can perform your own Integrations as well. So that brings us to the conclusion of the demo. So thank you for watching the demo.

This was just a brief introduction into the deep factors security platform. We certainly encourage you to request a demo. io/request demo and we'd be happy to spend a lot more time digging into specific use cases that your organization may have.

Thank you.