 Hello and welcome to the webinar. Today we're going to talk about Deep Fence's Threat Mapper project. I'm your host, Owen Garrett. I look after products and community at Deep Fence. And with me is my colleague Sandeep. Sandeep is one of the original authors of the Threat Mapper project. And what we're going to do today is explain what Threat Mapper is about. How we complement security initiatives that you probably already have in place for your cloud native applications. And then we'll move to the best part of today's session. We'll get a demo and a deep dive into how Threat Mapper really works and what it can do for you to improve the security of your applications. Threat Mapper is in the business of protecting applications. Cloud native applications, typically running in multi-cloud environments so complex, multiple points of presence and multi-modality. They may be predominantly Kubernetes based or Docker based, but Threat Mapper also protects components which are serverless running in Amazon Fargate or even bare metal or virtual machines. If you're in the business of managing the security of a suite of modern cloud native applications running in cloud or on-premise Kubernetes like environments, then Threat Mapper is an ideal solution for you. We take over where the shift left initiatives that your DevOps team and shift left is a great series of initiatives and steps to ensure that code that is pushed into production is believed to be secure and reliable. But so many times, code is pushed into production but in some way it can degrade, vulnerabilities can be found, issues can happen, and it falls to the application security team responsible for those production platforms and the applications running on them. To be sure, is that application still secure? Are attacks under place? Am I at risk? Shift left, we liken a little bit to the story, the tragic story of the Titanic. The Titanic was built in the Haralds and Wolves shipyards, very close to where I grew up, only a few miles away, and it was something that the Northern Irish community was immensely proud of. Haralds and Wolves were one of the biggest, best-regarded shipbuilders of their time. And the Titanic was the most ambitious, most sophisticated shipbuilding project that had ever taken place. We know the tragic story. We know that in the rush across the Atlantic, in potentially where threats were not seen until it was too late, the tragedy struck. But the Northern Irish community is always confident to say, she was fine when she left us. Don't let that happen to your applications. Just because they're fine when they leave development and move into production, that does not guarantee that there are no weaknesses in your attack surface. And ThreatMapper exists to help give you the confidence to discover what is running within your production platforms, the components and the infrastructure, to learn the topology of the applications that have been deployed, these complex, multi-tiered, cloud-native applications, and from that topology, then to deduce the attack surface, which components are greatest exposure to potentially being exploited. And then ThreatMapper scans those components running in production against up-to-date vulnerability lists, looking for weak spots, weak dependencies and vulnerabilities. The ThreatMapper product is built in a set of tiers. It begins by learning the attack surface that you're exposing in your applications, whether they're running in public, private clouds or in a combination of both. Investigating that environment, interrogating it for workloads and containers, and looking at network traffic to discover the topology of those applications. Then scanning those applications, pulling manifests and matching those against vulnerability lists. Compliance technology will come to that in a little bit, but then the final part of the first stage of ThreatMapper is to put this information together to build a ThreatMap. This is the actionable information that you can move from to work with your development team to minimize the risk of your running applications. Then as we go through ThreatMapper, in the future we have additional tiers, the ability to gather attack information, and then at the end, the ability to create an ecosystem of solutions that plug into our fully open source security observability platform. Let's come to that in a moment, but let's first wind back and put the problem that ThreatMapper exists to solve into context. The context is that organizations and enterprises are building applications and making more and more use of third party, often open source components. The application is built on a huge stack or pyramid of dependencies. And these dependencies present risks that the organization has to take ownership of. It's commonly quoted that enterprise web-facing applications, up to 90% of the user level code that makes up that application is third party open source components. And when you provide an application based on open source components to your end users or to your customers, you take on the responsibility for the security and provenance of those components. And with that comes great risks. Vulnerabilities are find within those components. Over 18,000 CVEs were published last year, and this year we're racing to meet or exceed that level with almost 18,000 published up until November 2021. Of those CVEs, over 50% of them are rated by white sources being of high or critical severity. And other types of attacks happen in the software supply chain, where bad actors impersonate packages or intercept CI pipelines in order to try and compromise applications before they're deployed into production. And managing this large number of dependencies on average 528 such dependencies and tracking the vulnerabilities within those dependencies has created an initiative or an industry known as Shift Left. Shift Left aims to secure code before it's deployed into production. The Shift Left initiative began from observations from IBM and the like that the relative cost to fix bugs and remediate issues is reduced the earlier on within the software development lifecycle, you can do it. But the net result is that Shift Left puts a huge burden on the side of developers to scan their code, to use tools to ensure that the code that they're building is 100% secure, or at least as secure as is physically possible to make it. But as we all know, Shift Left only deals with half of the problem. These great initiatives to deploy secure code into production tend to stop once that code is running within production. Shift Left is half the solution but you also have to continually secure your production environment. Is that environment configured correctly? Increasingly, that problem is being well solved by cloud providers and system integrators and other providers who are ensuring that the attack surface for the runtime platform is limited as far as possible. But we're still left with the problem that applications that left development in a secure state, are they still secure? When they're running in production, are they under attack? And if so, how should you respond? These are the problems that DeepFence ThreatMapper was created to solve. They are real, pertinent, serious problems for applications today. Vulnerabilities can find their way into production through a range of different ways or routes. It takes from GitHub's survey of their own code bases, it takes on average four years for a vulnerability to be discovered in code that has been published to GitHub. And once discovered, it takes on average 12 weeks to remediate and provide a fix for that vulnerability. And as a result, a great many container apps contain known vulnerabilities. When those vulnerabilities find their way into production, the impact can be devastating. Equifax ended up with a cost of well in excess of a billion dollars to secure their software development and production systems after 143 million customer records were compromised as a result of a vulnerability in a Struts library. A vulnerability that was published, that was patched for new code, but which Equifax neglected to identify was also present in code that was running in production at that time. And two months after the vulnerability was announced and a fix was available, an attacker find a way to exploit that vulnerability in running unpatched Equifax code. Or more recently, 120,000 web servers were vulnerable to a dramatic exploit giving an attacker access to any file a web server could access on the local file system, an unlimited path traversal exploit. In the cutting edge most recent releases of the Apache web server, problems happen in production because not all vulnerabilities can be patched before code is deployed to production. So often it's just not possible to track down and patch every single vulnerability when indeed 99% of them may never be exploitable anyway. Or perhaps your production environment includes third party resources, containers you've pulled off Docker Hub, agents from monitoring providers, network components like ingress controllers that you've taken from a third party source and those sources may not have gone through the same rigorous shift left vulnerability scanning processes that you've applied to your own code. But most importantly, as affected Equifax and the users of the Apache web server recently, unknown vulnerabilities can be discovered after a component has been deployed into production. Shift left responsibility ends when code goes into production and we need a way to pick up that responsibility and apply it systematically and carefully in production environments. Red Hat surveyed a large number of OpenShift users over the last 12 months and one of the questions I asked them was, in the last 12 months, what security incidents or issues related to Kubernetes and containers have you experienced? 94% of their respondents said they had at least one security incident in their Kubernetes environment over the last 12 months. And these are all real-time runtime instance. There are not things that could have been caught in a shift left project securing code before it moves into production. Why does this problem happen? The problem happens quite simply because the interests and the targets and the KPIs for Dev and DevOps and for app security are misaligned. Development and DevOps are charged with innovating as quickly as possible, building new exciting applications and features, getting those features into production as quickly as possible, and then iterating, improving those rapidly. And typically, a Dev or DevOps team will focus on a small set of applications. On the other hand, the application security team is charged with the integrity and the security of an organization's runtime environment and suite of applications. They operate at a much more steady pace in a much more methodical fashion, threat hunting, looking for vulnerabilities, and then feeding those back to the development team when they need to be resolved. And it's really common whenever users run our tools in their production environment to find tens of thousands of potential, not necessarily exploitable, but potential vulnerabilities infrastructure-wide. For a host, hundreds of such vulnerabilities on individual hosts, dozens of these vulnerabilities within containers. When the app sec team passes this information back to the development team, the response is that we cannot prioritize, we cannot act on this enormous list of theoretical vulnerabilities. Give us better intelligence, tell us what to target on. And frustration comes from the app security team because they see the DevOps team as just not putting enough priority or concern towards security issues. How can we resolve this misalignment? How can the app sec team understand what's running in production and give the DevOps team real actionable information that they can move on that will make a material improvement to the risk and exposure that those applications have? This is exactly the problem that threat mapper exists to solve. What I'd like to do now is hand across to my colleague Sandeep, and Sandeep will show us threat mapper and action, how we can interrogate, scan and learn what's running in our production environment, find the vulnerabilities and prioritize the vulnerabilities that need to be remediated. So I'll pass the screen across to Sandeep, and let's move on to the demo. Thank you, Owen. Going ahead and sharing my screen, you should start seeing the dashboard of threat mapper. Thank you so much, Owen, for that context. The truth is there is a semantic gap or there is a distance between what happens in CI CD, which is where you scan code for vulnerabilities and what happens at runtime. What threat mapper really tries to do is use the runtime context to prioritize some of these vulnerabilities. Ideally, this shouldn't be about only vulnerability management. This should be about exploitability management. So we really start converging going from those thousands of vulnerabilities to those handful of exploitabilities which really need focus. I mean, just imagine having thousands of vulnerabilities across infrastructure and having no concrete means to prioritize these is as good as not knowing how many vulnerabilities exist because they're not actionable. They're measurable. Sure, you can't really act upon those. That's where threat mapper comes in picture. What you're seeing here really is essentially an MRI scan or a single pane of glass, really, for a whole of your cloud estate. And this is basically your compute. You see multiple clouds here. There's a digital ocean. There is Google Cloud. You see third-party APIs that are getting called. One of the services is calling Slack, calling into Slack hook. There is S3 bucket. We are calling into here from one of the cloud nodes. So this really works across multiple clouds, multiple modalities. In this particular case, you've got digital ocean. You've got Google Cloud. Let's dig deeper and see what we have running here and how threat mapper sort of lets you scan some of these things. Some of these resources for vulnerabilities, how it lets you prioritize, and it's going to go from there. So in digital ocean, for example, here, you're seeing two things. One is a region NYC one and the Kubernetes cluster, which could be across multiple regions, by the way. So they are being shown at the same level. Let's dig deeper into this particular zone. You're seeing a couple of nodes there. And one particular VM, which seems to be running some processes, seems to be running some parts, and then you're going to be able to start seeing and really go from cloud to the region to users all the way down to processes with this particular view. So it really starts with visualizing what you're running within a cloud or across multiple clouds, within your containers, within Kubernetes, and even natively running processes on VMs. So for example, what we have here is a WordPress pod, and this is how it's going to look like. So we have come all the way down from digital ocean, this hierarchy region to this particular node, which is a host and a container or a pod here in this case, which is WordPress. And then this is really the first view. All of these connections that you're seeing, these are live. Every three seconds you're going to start seeing all the connections that are happening. We really start building this connection map at process level, and then really bubble it up throughout the cloud hierarchy, throughout the hierarchy of all the compute and resources that you have. That's the first part. Now, coming to really being able to sort of act upon these visualized resources, you can scan this particular container, for example. This is WordPress. You can say, you know what, I want to scan WordPress container for all the vulnerabilities. You could say I want to scan it only for Python vulnerabilities, only for PHP vulnerabilities, or you could say, you know what, scan every executable piece of code which is running within this particular pod, within this particular node, you could even go beyond and say, you know, scan all executable code within this particular cluster or this particular region. And then you could actually do this at runtime. And I think I forgot to sort of speak about what you could do early on. For example, CICD Jenkins basecans or GitHub Action Basecan, that's the first part that you can do with ThreadMapper. Sure. You can also scan your vulnerabilities within registries. For example, all the popular registries that you see, including cloud registries are already connected. You can use, you can use ThreadMapper to scan that. For example, we have a Docker hub registry here, which is basically showing you a bunch of images. You can scan all of your images even here, but this applies only for the continued images, of course. You can scan them one by one. You can scan them in a batch mode. You can set a cron job from the GUI to scan them periodically. So every 24 hours, you can have all of these scan reads. So that's also possible. So CICD basecanning for CircleCI, GitHub Actions, for Jenkins, you know, all of these popular frameworks that you have is available. Registry basecanning you can do from here as well. And we were speaking about runtime scanning, which is essential at this point where you can say that here, you can scan this running container or a running node for vulnerabilities. And this is where it sort of starts becoming, you know, incredibly cooler really, because we start using this runtime context to really tell you that, sure, you scan for vulnerabilities and then you end up with hundreds of vulnerabilities. What's the point of it all, right? The point of it all is to really figure out what are those top one or two or three or four vulnerabilities which have a direct attack path to those vulnerabilities. Okay. That's number one. And that basically makes it exploitable at you now. This can be exploited at that particular point in time. Over here, what we're really seeing is this container has been scanned before. You're seeing there are a whole bunch of vulnerabilities here. Many of them are just low. Some of them are critical. There is one critical. But here is an attack path. What is being shown here? We're showing, look, this particular pod or group of pods is directly accessible from the internet. So anybody could just scan for, essentially do a recon. And if they have a payload for this particular vulnerability, in this particular case, there are top three vulnerabilities which seems to be exploitable over the network. As a network has network as an attack vector, have a fairly high CVS score, which pod they are sort of accessible on. You have all of this detail over here. This is where the runtime context comes in picture. Let's do one thing. Let's dig deeper on some of these vulnerabilities in this particular view, which is really about digging deeper and all of these vulnerabilities and adding runtime context on top of it really. For example, what you're seeing here is two tabs. One is what is most exploitable at this very instant within my infrastructure and what are the attack paths? How can the bad guys get to those vulnerabilities? Show me where to go, which door to close, which, you know, container to patch, which VM to patch, all of that really. That comes in here. And then of course you have a scan by scan view of things. Things like, well, I scanned this for a container yesterday and today I see there is one additional vulnerability. And then you can really go down and see what really might have caused this. Is there a new build that we did? Is there a new package which did not have a vulnerability but it is reported today? All of that stuff really. Let me dig deeper in this one particular vulnerability and see how this really looks. Over here, what you have is this is a GMP 2.6, 2.1, this very specific version, which is there in a container image called reverse proxy, which seems to be latest. We did actually pull it from Docker Hub and then this is the container image ID. This is a particular layer in which this is happening and the score is five. So this is basically a medium vulnerability in terms of severity. And then you've got all other details like how to go and fix it. And if sometimes our information is not possible, we just point you to the appropriate URL where you can go and see the details. Super importantly, here is the attack vector. Attack vector is network. Attack complexity is low. Authorization is not required. All of these details have a meaning. But the thing is these are computed or when you scan statically, you do not have that runtime context. At runtime, when you say attack vector is network and attack complexity is low, you're really, really looking at a tool which is telling you things like this. Hey, this is directly exposed to the internet. And look at this. This is happening on port number 8000 and this particular CV, it's easily exploitable over network. You must go and fix it. CVSS tells you it's 5. The score is low, but this one is loaded. This is out there, ready to be exploited. And this is basically a prioritization bet which you can do. You can do this on a scan by scan basis or we can go back to our most exploitable vulnerabilities. Now, this is where we were talking about the runtime context. Some of this context is just not there. Who's talking to that container? Is that container doing network IO? Is that container even running? Is that host even online? All of this data, all of this context is not there in CI CD. It is also not available when you're doing snapshot based scanning from afar or some of the network scanner. Some of these details are just not there. So you lack this context to really prioritize. Here, what we're really doing is we're saying, look, you've got 1029 vulnerabilities here, but let's sort them based on what is the most exploitable and how to determine what is most exploitable. First, we figure out whether that container or a host is running. Simple. It's online. So the vulnerabilities within that node are loaded. Number one. Number two, is it doing network IO? Is it even talking to the world directly or indirectly? In this particular case, you see the webgoat. We have WebDVW container which is directly exposed to the internet for the sake of testing, of course. But there is another one here which is sitting behind a proxy. So some of these containers or some of these nodes might be sitting behind a web server or a load balance or a bunch of proxies really, but they're still equally exploitable. It's just that there are multiple hops to get there. With this attack pass, we're showing you what is directly exploitable, which is that if we're talking to the internet, what is sitting behind a proxy or a bunch of proxies doesn't really matter as long as the vulnerability is there and can be accessed remotely, it's exploitable. So really that. So is the node running? When was it patched? Have you installed this package six months back and never updated it? How many containers or how many instances of this base image are being used? Typically you have one base image that is used as a base for everything. The same thing happens for AMIs as well. So if it is in one of the base images, it's probably there everywhere and it's more exploitable. And then again, the runtime context. How many connections are there? Are these connections that are happening on the same port where this particular service is running and this service is the one which is actually loaded that dependency. Going forward, you're also going to be able to see per process vulnerability. Really, really bringing it down from thousands to hundreds, dozens and then down to that one vulnerability or exploitability that need to focus on. For example, here, what you have here is this particular one, which is in the web code. Same level of detail again, directly exposed to internet. This could be stashed behind or hidden behind multiple layers of proxies. You would still see this as the first vulnerability. Why? Because the vulnerability is exploitable, easy to exploit, all the details are here and we are actually taking the runtime connection data and really overlaying this. This cannot go wrong. All the runtime context is being used to prioritize the exploitability of these vulnerabilities. So that's about the most exploitable vulnerabilities or exploitability management and the top attack parts that you need to focus on. Let's move on to some of the integrations that we have. You can directly file a JIRA ticket from within ThreatMapper. So you can say, you know what, here's an exploitable vulnerability and here is a snapshot of connections. Let's go and fix this right now. Everything else can be. You can do that. You can file a JIRA ticket right from within the product. You can get notifications from Slack, major duty, email is always there. You can have custom HTTP endpoints configured as well. Very recently we added integration for Chronicle. If you're using Chronicle, your SOC team is using it. It can even ship that vulnerability there and of course Microsoft Teams. When it comes to Sims, all the usual integrations we have here, and this list is ever changing really. We already integrated with Splunk Elastic Search, which is basically your L-based login stack which might be homegrown. Sumo Logic, we've got a couple more coming very soon. JIRA we spoke about, you can archive these vulnerabilities for compliance reasons in S3 buckets as well, right? For up to six months or longer, as compliance is mandatory, you can archive them. And then of course there is an excellent reporting mechanism at PDF, which could be really per, could be per team or at a higher level, which is basically an executive summary. You have all of those options as well. So once again, scanning in CI CD helps you measure vulnerabilities, helps you measure the tax surface, but adding runtime context to it, like what ThreatMapper does, really makes those vulnerabilities actionable. With that, that's pretty much I had from my side over in terms of demo. Back to you. Hey Sandeep, thank you. I'm really impressive to see all of the information that ThreatMapper is able to gather starting from zero knowledge of your environment or your applications. The managing company that you see here gathers information from sensors that you deploy across your various cloud or Kubernetes or Fargate environments. And those sensors discover the workloads that are running, how they communicate with each other. So the network traffic that Sandeep described so that we can build topology. We discover the vulnerabilities by scanning the hosts in the containers and then the icing on the cake, the ability to identify the most exploitable vulnerabilities. That attack path visualization gives you exactly the information you need to go back to your engineering team and say this container, this virtual workload, this serverless unit, this is the thing that you need to fix first of all because this is the biggest risk for exploit that we're exposing to the outside world. And to gather all of that information without any prior knowledge is the real power that you'll see within DeepFence ThreatMapper. Let me know, go on and we'll talk a little bit about the roadmap. So if I can grab the screen share, Sandeep. Yep, I'll just go ahead and stop sharing my screen. So let's talk about the future roadmap for ThreatMapper. What you've seen is production ready. It's used by a number of our users and other users across the world to secure their applications right now. But we have an aggressive roadmap to build this technology out, to build a true broad security observability platform. The first release ThreatMapper open source was made a little over a month ago. And all of the capabilities that Sandeep showed you in the demo that's just passed, these are all live and production ready in the ThreatMapper open source release. In order to fully understand the attack surface, there's one more thing that we need to do. We need to be able to interrogate the configuration of the platforms you're running on and look to see are there further weaknesses or vulnerabilities in how those platforms are configured. That's the next step in our roadmap for ThreatMapper. We use a suite of tests coming from the OpenScap security content automation protocol project. These are effectively runtime tests, shell scripts and the like that can be run against production environments looking for known weaknesses and configuration errors. From the base Linux image up through to Kubernetes master configuration or node configuration, docker configuration or individual containers. Based on the wisdom of the crowds from initiatives from organizations such as CIS Center for Internet Security, these SCAP profiles and similar tests apply best practice tests against your configuration. This is something that you'll see coming into the ThreatMapper open source platform in due course. Not only can we look at your runtime workloads, we can also look at and test the underlying platform that those workloads are running on. This then brings us to the next step, the next capability that you'll see within the ThreatMapper open source security observability platform. The first tier tells you about your state right now at that instance, the workloads, the configuration and any vulnerabilities that exist. But the next thing that you need insight on is how are those applications being used? Are there anomalies in resource usage, spikes in network traffic, spikes in application, CPU or memory usage? Are there indicators of compromise? So, has a workload potentially been exploited because a process is misbehaving? It's running a system call it shouldn't? Like a tracing operation? It's spawning new processes or maybe it's crashing? Have there been unusual activities in processes accessing the file system? Has someone found a way to create an executable file on disk and then start that file running? Very, very common footprint of someone who's putting in place something like a Bitcoin miner. But most importantly, are there indicators that somebody is trying to attack your applications? These subtle, almost specter-like indicators show that reconnaissance traffic is flowing across your network, show that maybe there's commands and control traffic happening. And by putting that information alongside the threat information, ThreatMapper will be able to give you the information that tells you what is going on within your application right now and what vulnerabilities are attackers potentially seeking to exploit. There's some really smart technology behind these indicators of attack. We have a series of EBPF probes that we can deploy against your running workloads and we can capture all or filtered network traffic from all of those nodes. You could potentially then match that against threat rules to identify recon traffic, to identify command control traffic, to identify exfiltration activities. And these capabilities provide very, very deep insights. Much deeper than solutions that just gather network traffic stats and report anomalies. Much deeper than solutions that just capture traffic from web application firewalls or maybe from service mesh proxies. The deep-fence technology is proxy-free. It operates out of band with a simple kernel configuration, no kernel modules required. We use EBPF, not just for capturing process and file anomalies which indicate compromise, but also for capturing network traffic, the indicators of attack. And our intent is to combine this technology to create a security observability platform. That you can pull information from in real-time. So not just use it to identify vulnerabilities that need to be closed because they express a risk to your applications, but also to identify traffic that is indicating an attack maybe in place. And our hope and expectation is that organizations will be able to build ecosystem solutions on top of this. Whether it's a simple case of feeding all of this data into Splunk or Elk for your own analysis, or whether it's a case of third-party tools plugging into this platform to capture the information that we can provide and add value on top of that. As part of our roadmap, we'll be taking the technology that was within previous deep-fence products and moving that into our open-source platform over the next three to six months and beyond. And just as we'd like other organizations and entities to take advantage of our ecosystem and create add-ons that can build on the information that our security observability platform can generate, we have our own technology, deep-fence threat striker, that can pull information and correlate and apply runtime protection to your application platform in order to quarantine or isolate potentially compromised workloads or deploy very targeted surgical firewall rules to prevent traffic coming from sources, individual, local, or remote IPs that are potentially sending attack traffic. Well, let's get back to ThreatMapper. ThreatMapper 100% open-source, available on GitHub, Apache licensed, very, very simple to deploy and get running. The first step is to get ThreatMapper Management Console up and running. It's simply a case of grabbing our Docker compose, spinning that up, and you can have ThreatMapper running on a single Docker-enabled host within a matter of minutes. And then you'll wish to deploy the deep-fence sensors across your runtime environments. We support Kubernetes, Docker, serverless with Amazon Fargate, and the sensors can also be deployed within virtual machines or bare metal machines in order to discover the workloads running on those machines and the network traffic and to feedback to the Management Console. Please do take a look. We would love to get your feedback. Get in touch with us through the deep-fence community Slack. Get in touch with us through GitHub, feature ideas, bugs, raise an issue. Let us know how you're using ThreatMapper. Star it if you want to keep on track with what we're doing with ThreatMapper over the next few months. We look forward to catching up with you on any of the various community channels that are available to support ThreatMapper users. So with that, shift left, secure your code before it goes into production, but also secure right. Do it properly, secure your production environments using ThreatMapper to identify vulnerabilities in production, find exploit paths, and then seal those off so that your application, your users and your data are secure. Thank you very much for your time today. I hope this has been instructive. Don't hesitate to get in touch. All the best. Thanks, everyone.