WEBVTT 00:02.480 --> 00:03.940 Hello, everyone. 00:04.360 --> 00:07.460 So, please take a seat, grab a coffee, close the door. 00:07.680 --> 00:09.560 Do you hear me? 00:09.980 --> 00:11.220 No, I'm sorry. 00:11.220 --> 00:13.660 It's a pre-recorded session. 00:13.660 --> 00:16.120 So, I can't hear you at the moment. 00:16.120 --> 00:22.180 As you are listening, just record I'll be on holiday in the south of France in my swimming costume. 00:22.720 --> 00:25.820 So, give me a question in the chat room. 00:25.980 --> 00:28.760 I'll be pleased to answer you at the same time. 00:29.300 --> 00:30.700 So, hello, everybody. 00:30.700 --> 00:31.820 I'm Nicolas. 00:32.220 --> 00:34.200 Just a few words to present myself. 00:34.200 --> 00:37.680 I'm an independent tester, security editor. 00:37.680 --> 00:43.000 I work for a decade in this cyber security industry. 00:43.320 --> 00:51.720 Now, I've built my own company and I work in the red team of a financial institution in France. 00:51.720 --> 00:55.220 So, as you see and heard, I'm French. 00:55.220 --> 00:57.140 So, sorry for my French. 00:57.460 --> 00:58.540 Thank you. 00:59.460 --> 01:03.840 We'll talk about automating security operations. 01:03.840 --> 01:09.080 What does it mean to you and to me today? 01:09.080 --> 01:12.200 Everyone has his own definition. 01:12.820 --> 01:17.580 For me, security operations could be related to a bunch of activities. 01:17.580 --> 01:20.740 For now, please consider at least these activities. 01:20.740 --> 01:37.900 I will talk about penetration testing, security control assessment, CTI, and DFI operations, security compliance, and all about code review and web application testing. 01:38.260 --> 01:43.640 We will see why and how to add automation within this activity. 01:44.600 --> 01:48.620 And we'll talk about Patrol. 01:48.620 --> 01:57.400 Patrol is an open source framework for automating and orchestrating tasks and security operations. 01:57.400 --> 02:04.240 It provides a solution to get a continuous and full stack overview of your cyber exposure. 02:04.580 --> 02:14.760 The solution, sorry, lets you to define your assets, policy, and the scan you want to perform. 02:14.760 --> 02:17.320 The scans give you findings. 02:17.320 --> 02:24.740 And all these findings are then collected, analyzed, and aggregated within a unique database. 02:25.500 --> 02:34.280 We developed several engines and connectors to existing security tools to assess risk on various security domains. 02:34.280 --> 02:39.840 The idea is to get a risk overview from IP to data level. 02:39.880 --> 02:46.560 The scans could be start one shot, scheduled on, started on the regular basis. 02:46.920 --> 02:54.580 And the final goal is to get a continuous monitoring of our assets and our security posture on all stacks. 02:54.680 --> 03:04.720 All the findings, the findings could be a confirmed vulnerability, a suspicious change in our systems, or a suspicious activity over internet. 03:05.200 --> 03:09.680 These findings are then contextualized and tracked over the scans. 03:11.120 --> 03:12.680 And that's all for me. 03:13.860 --> 03:17.480 Now, of course, it's not a tool presentation. 03:17.760 --> 03:26.840 I just want to tell you about security operation and about automating SecOps. 03:27.720 --> 03:33.660 As I told you before, I work in a sys service since five years. 03:33.660 --> 03:40.800 And from my windows, there are two major factors that lead current evolution of the IT landscape. 03:40.800 --> 03:44.800 These are acceleration and diversification. 03:44.800 --> 03:51.360 This applies to assets, threats, and, by the way, security incidents involved. 03:51.500 --> 03:57.440 We see an acceleration of digital program and diversification of assets. 03:57.880 --> 04:05.960 So, thanks to the digital transformation program, we see an explosion of IT project. 04:05.960 --> 04:12.420 The information systems are more and more open to the world, and then more and more open to hostilities. 04:12.920 --> 04:16.860 We have to deal with new technologies every day. 04:17.080 --> 04:24.900 New product, new framework, new library, and all these technologies are updated every day. 04:24.900 --> 04:29.740 We also see changes in the software delivery processes. 04:30.360 --> 04:36.900 Remember a few years ago, when it was about four to five months of production per year. 04:36.900 --> 04:46.140 Today, thanks to the hype of DevOps activities, we can see multiple go live in a day. 04:46.740 --> 04:58.440 And a go live means a new application, and, by the way, new vulnerabilities or new exposed things. 04:58.900 --> 05:00.880 The threats are growing too. 05:01.020 --> 05:04.200 The number of CVEs is growing year after year. 05:04.200 --> 05:05.600 It's a metric. 05:05.600 --> 05:13.580 I don't know if it's a good metric to talk about the number of CVEs, but it could be representative. 05:14.660 --> 05:18.700 But the attackers, they do a great job. 05:19.040 --> 05:23.300 There are more and more, and they are more and more organized and efficient. 05:24.080 --> 05:42.020 From a different point of view, we have to cover a quickly changing IT landscape, and at the end of the day, it's increasingly hard to get a realistic, comprehensive, and sufficiently updated vision of our cyber risk exposition. 05:42.740 --> 05:46.720 We also have to face another problem. 05:46.720 --> 05:49.520 It's the talent shortage problem. 05:49.520 --> 05:54.360 We have not enough people to do the job at the moment. 05:54.360 --> 06:01.240 Lots of tasks are repetitive, and this leads people to lose their motivation and leave the team. 06:01.240 --> 06:16.420 We definitely believe it's time to adapt our cyber defense and we have to adapt the way we do our job and we monitor our cyber security posture. 06:18.770 --> 06:27.970 To face these challenges in the team, we try to manage security incidents with two goals. 06:27.970 --> 06:30.470 The first one is for the red team. 06:30.470 --> 06:37.650 It's about identifying vulnerabilities on our assets before attacker two. 06:38.030 --> 06:49.330 And for the blue team, it's to identify indicators of compromissions, which could be past, current, or future of a potential security incidents. 06:49.330 --> 06:57.250 And to do this, we have to keep us updated from many, many things. 06:57.250 --> 07:04.910 The first one is to keep us updated from the continuous transformation of our assets. 07:04.910 --> 07:09.290 It could be more or less considered as shadow IT in big companies. 07:09.630 --> 07:26.470 We have to keep us updated from the infosec knowledge database, the new research publications, the talks talking about the new vulnerability or new way to detect certain things or to exploit the vulnerability. 07:26.570 --> 07:33.250 And all the security news and the spectrum of threat scenario is changing also every day. 07:33.250 --> 07:38.310 We have to manage lots of feeds of information every day. 07:39.230 --> 07:45.410 And finally, we found that scanning our assets is not efficient anymore. 07:45.410 --> 07:56.990 We have to monitor external resources to detect leaks, attack signals, and to understand how third parties see our security posture. 07:57.310 --> 08:04.870 And for day-to-day work, it could be very hard to manage all of this information. 08:06.710 --> 08:13.950 And the cyber security industry, it's a race against the clock. 08:14.830 --> 08:19.070 And the third aspect we have to tackle is the window of exposure problem. 08:19.070 --> 08:21.470 It's all about our reactivity. 08:21.770 --> 08:32.590 Today, we know that attackers will attack us, not just because we have a bank, we are a gas industry, we are talking plenty. 08:32.590 --> 08:38.190 No, it's just because we are on the internet and new vulnerabilities are found everywhere. 08:38.190 --> 08:42.010 It's just increasing the likelihood of attack scenarios. 08:42.010 --> 08:48.130 So the windows of exposure is a real problem and could be handled with priority. 08:48.130 --> 08:54.380 We said that we have to detect and fix the vulnerability and suspicious activities as soon as possible. 08:57.030 --> 09:05.190 So facing the challenges, we think about automation and orchestration. 09:05.470 --> 09:13.170 Just a quick reminder, my definitions of automation, it's setting a single task to run. 09:13.170 --> 09:18.390 And orchestration, it's about automating a lot of things at once. 09:18.390 --> 09:23.370 It's about coordination and management of automated tasks. 09:25.640 --> 09:28.900 Before we go, let's start our experience. 09:28.980 --> 09:36.320 A few months ago, I set up a Kubernetes cluster with default configuration exposed to the internet. 09:36.320 --> 09:37.920 It was unfiltered. 09:38.540 --> 09:42.760 Maybe you see what will be the next thing. 09:43.160 --> 09:46.200 Only 24 hours after, I was hacked. 09:46.200 --> 09:55.820 CryptoMiner was deployed on my cluster and my server starts to mine some cryptocurrencies. 09:59.220 --> 10:06.240 Forensic definitely thinks I was not targeted because I was near Nicolas. 10:06.680 --> 10:19.200 Just because probably a scanner identified that a non-secure service was exposed on the public IP and the attacker automatically deployed his payload on my server. 10:19.380 --> 10:21.820 So I don't blame him. 10:21.820 --> 10:23.080 I don't blame him. 10:23.380 --> 10:24.780 He's doing his job. 10:24.780 --> 10:28.040 He's doing a great job for this point of view. 10:28.660 --> 10:33.800 The fact we have to remember today, it's not that I'm a cheap DevOps, no. 10:33.800 --> 10:39.880 We have to accept that attackers do automation and better than us in their field. 10:41.060 --> 10:43.840 So why automating SecOps? 10:43.840 --> 10:57.140 The first thing is, for a defensive point of view, is to do more checks, to cover a larger and diversified scope, to cover a bigger perimeter of assets and make more control on each stack. 10:57.620 --> 11:02.300 And the second thing is to do it more often. 11:02.560 --> 11:06.240 It could be continuous checks. 11:06.240 --> 11:16.780 It could be very useful to reduce the windows of exposure, to reduce the delay in discovering and fixing a security incident. 11:18.880 --> 11:25.380 The third thing I would like to say, it's about efficiency. 11:25.700 --> 11:30.640 As I told you before, we have to face a big problem, a time-shortened problem. 11:31.660 --> 11:42.420 The idea is to reduce the time affected to low-value-adding tasks, to focus on more complex security cases. 11:42.420 --> 11:51.460 And for doing this, we have to automate the simple task. 11:51.460 --> 11:58.900 It's also a way to reduce and manage costs and to start for low KPIs. 11:59.040 --> 12:25.380 It could be also very useful to help you in your compliance and benchmark activities, to define and expedite the same control on a subset of assets and do it continuously to see the trends and how far you are compliant with your security standards. 12:27.160 --> 12:34.860 So, at this time of this presentation, you should be all convinced of automation. 12:35.820 --> 12:39.500 So, there are several downsides we have to discuss. 12:40.000 --> 12:43.120 Of course, there are limits. 12:43.120 --> 12:46.520 It doesn't cover all of the risks in itself. 12:47.760 --> 12:59.840 If you automate your control, you will have an increasing number of alerts to manage, an increasing number of false positives. 13:00.180 --> 13:10.280 We found also that it's very useless, inefficient to found functional vulnerabilities. 13:10.280 --> 13:17.460 We also have to qualify and contextualize all the findings we have, we have found. 13:18.320 --> 13:24.740 And about the TCO, yes, automating, we don't automate things by magic. 13:24.740 --> 13:28.440 We use tools that orchestrate all the tools. 13:28.440 --> 13:34.960 So, we have also to manage and exploit the tools. 13:36.560 --> 13:39.100 At the end of the day, a tool is a tool. 13:39.100 --> 13:43.180 And it's very useless without a cyber defense strategy. 13:43.180 --> 13:47.400 So, if you don't have a strategy, don't try to automate things. 13:50.360 --> 13:57.540 By the way, we decided to build a platform for automating and orchestrating the SecOps. 13:57.680 --> 14:05.660 Because we wanted to improve our level of manageriality and to become more efficient to adapt our work. 14:09.170 --> 14:24.070 The core concept is to efficiently moving from reactive to predictive, more or less predictive security posture with the benefits from the power of automation. 14:24.910 --> 14:33.450 And also, we decided to use... to don't develop our tools, but to use in priority the best of built tools. 14:33.450 --> 14:39.710 The great tools exist, but they're not addressing all the stacks at the same level. 14:40.270 --> 14:53.630 Issues of quality are very efficient to scan for vulnerabilities, for misconfiguration on infrastructure and your cloud services. 14:53.630 --> 15:01.800 But the web application scanners and the container security assessment and the anti-malware modules are not sufficient enough. 15:01.800 --> 15:15.980 We found that we can have only one tool to cover all the security control we have to assess. 15:20.300 --> 15:28.720 We found that we have to support scan policy, which are realistic from an attacker point of view. 15:29.380 --> 15:42.600 And the idea was to take the benefit from the best part of several security tools, making it easier to define a scan policy and to plan it. 15:44.660 --> 15:48.740 And PathWall... I will talk about PathWall a little bit. 15:48.900 --> 15:52.920 PathWall is composed in two independent types of applications. 15:52.920 --> 16:12.480 The first one on the left is the manager, the front-end application, where you have your dashboard, you manage your assets, you define your scans, you have your findings, and you try to manage the engines, which are the micro-applications that perform the scan. 16:13.120 --> 16:19.060 All these applications are open source and developed with Python. 16:19.360 --> 16:26.430 All features are reachable through the web UI or the REST API. 16:29.100 --> 16:32.180 The PathWall engines are the probes. 16:32.180 --> 16:42.360 They are the micro-applications that perform the scans, parse, analyze, and format the findings into a unique and pivoting format. 16:43.160 --> 16:50.740 This could be deployed on several separate servers. 16:51.260 --> 16:53.260 We can scale it that way. 16:54.920 --> 17:10.840 For example, you can deploy probes on your internet, on your internal network, and probes on your administration or DMZ, which are your restricted networks. 17:11.700 --> 17:15.980 And it could be the binding of your endpoint. 17:16.120 --> 17:18.040 And these PathWall engines are... 17:20.800 --> 17:22.240 Sorry. 17:22.740 --> 17:26.320 They scan the assets. 17:26.600 --> 17:30.160 For example, we developed an engine for Nmap. 17:30.240 --> 17:35.340 We don't really develop Nmap, but we made a connector to Nmap. 17:35.340 --> 17:55.540 And that way, we can perform on the same assets security scans for using Nexus, Nmap, OpenVAS, Qualys, and other security tools from the same cockpit. 17:55.540 --> 17:59.360 And all the findings have the same look. 17:59.360 --> 18:09.760 And we can compare and track all the findings on these assets issued by the separate engines we use. 18:12.040 --> 18:13.780 A bit deeper. 18:14.140 --> 18:17.980 PathManager, as I told, it's the front-end application. 18:18.800 --> 18:23.560 Here, you define your assets and a group of assets. 18:23.560 --> 18:26.360 You can also define the scans policy. 18:26.360 --> 18:30.460 You can schedule scans and manage the scan regime. 18:32.340 --> 18:36.400 PathWall engines, it's the second component. 18:37.640 --> 18:49.120 The PathWall engines are the connectors with the scanner which could scan the assets, which could be on the internet or your internal network. 18:51.400 --> 19:00.420 The PathWall engines could be also linked to an external scanning service. 19:01.420 --> 19:07.000 Or a link to your CTI repeater. 19:07.000 --> 19:17.460 You can also create the tickets or inject alerts or raise alerts to your DFI system. 19:17.520 --> 19:30.440 You can also inject the data in your sim or on your ELK if you want to analyze or to make alerts on a different way. 19:34.380 --> 19:40.220 As today, we developed a large range of engines in various domains. 19:40.680 --> 19:52.100 For each engine, we create a Docker image including the tool needed and the REST API to deal with them. 19:52.100 --> 19:57.560 So, you don't have to install tools, dependencies, or manage the system requirements. 19:57.560 --> 20:01.060 It's just as simple as a Docker pool. 20:01.660 --> 20:21.120 It's true, except from several engines, like NMAP with the Docker image, do not embed the scanner. 20:21.120 --> 20:25.100 But it could be linked to your instance. 20:25.100 --> 20:36.520 So , on this slide, we see a lot of engines, a lot of various domains. 20:36.520 --> 20:41.360 The idea of PathWall, it's a framework. 20:41.360 --> 20:50.220 You can build your tool to the detection of the control you have to perform. 20:50.220 --> 20:58.240 I don't see many companies that use PathWall with all of these engines. 20:58.440 --> 21:17.140 It's more or less separated between the vulnerability assessment or the data lakes or the static code analysis or dynamic code analysis. 21:20.800 --> 21:34.540 We also have a lot of ideas for the nature engines regarding gravity management, CTI, web application scanners, and so on. 21:34.540 --> 21:50.660 So, the engines are also open source and we accept any contribution to create or to give us ideas to develop any engine. 21:51.400 --> 21:58.340 Maybe it's time to talk about use cases. 21:58.340 --> 22:06.100 The first one is... I come from the right team. 22:10.360 --> 22:14.480 I always do the same. 22:15.780 --> 22:23.760 The first step of the test is to perform the recon activities. 22:23.760 --> 22:26.280 So, we search for subdomains. 22:26.280 --> 22:27.840 We always have IP. 22:28.040 --> 22:34.580 We try to discover the port, the open port. 22:34.580 --> 22:37.880 We fingerprint these services. 22:37.880 --> 22:42.000 We search for vulnerabilities and so on. 22:42.000 --> 22:53.980 For this, we use several tools with the same, more or less, the same settings on your assets. 22:54.020 --> 23:08.240 So, with PathWall, we use PathWall in our security assessment to do this as quick as possible and to do this continuously. 23:10.740 --> 23:21.140 The second use case is to examine the source code and the running web applications for security defects. 23:21.140 --> 23:25.820 It's to be involved in the CI-CD pipeline. 23:26.660 --> 23:32.800 So, on each commit, we take on the code repository. 23:32.800 --> 23:44.060 We are able to clone the project and start a static code analysis using the one-day dependency checks or the for the GS dependencies. 23:44.460 --> 23:51.000 And the code is built in and so on. 23:51.000 --> 24:05.520 And once the web application is deployed on the staging environment or on the predictions, we can also orchestrate autonomous scan using Arachne, ZAP, and NIC2. 24:08.920 --> 24:17.620 PathWall is available through the REST API, and we also developed PathWall for PyClient, which is a Python library. 24:17.620 --> 24:21.840 So, it's very easy to integrate with all those security tools. 24:24.310 --> 24:28.690 The third one is about efficient preparation scenario. 24:28.690 --> 24:36.830 We use it to search for early signs of malicious domains and the websites present. 24:36.830 --> 24:44.630 The idea is to search for suspicious domains or type of cross-query domain. 24:44.930 --> 24:52.250 And once we identify them, we can monitor them to look for changes. 24:52.250 --> 24:54.230 Are they still parked? 24:55.650 --> 24:58.750 Are they should certificate? 24:58.750 --> 25:03.310 What is the web application look like? 25:03.350 --> 25:05.810 Are they new exposed services? 25:05.810 --> 25:06.910 And so on. 25:06.910 --> 25:17.490 And if we have any suspicious change on the attacker's assets, we express an alert and we manage them. 25:19.430 --> 25:23.830 The third use case is code leaks on GitHub. 25:24.190 --> 25:42.170 Many, many, many times, DevOps or IT people are leaking something on GitHub because, I don't know, it's easy, we don't really know how to use it. 25:42.170 --> 25:46.510 And we don't really know that it's a public repo. 25:46.510 --> 25:47.800 It's public. 25:47.990 --> 25:53.750 So, we want to search for leaked internal resources code. 25:54.350 --> 25:57.150 API keys, password. 25:57.430 --> 26:23.190 And we developed just a simple scrapper on GitHub to monitor our keywords and our patterns to just detect that we don't have leaked any security system script or API keys 26:30.870 --> 26:44.750 We will talk about use cases, but we found that when we automate all these security tools, we can address a lot of use cases. 26:49.330 --> 26:51.710 So I want to talk about it. 26:53.820 --> 26:58.340 Just step back a bit. 26:59.180 --> 27:09.360 If you orchestrate the security tools, you will perform more control and do it more often. 27:09.840 --> 27:12.640 It will result in more findings. 27:12.640 --> 27:16.120 And it will result to more alerts. 27:16.120 --> 27:22.780 And the security dashboard will look like a Christmas tree. 27:23.040 --> 27:26.300 That's very, very, very soon. 27:27.900 --> 27:39.560 So, well, all these events are relevant, but we have to prioritize these things. 27:39.560 --> 27:54.240 And it's the key challenge today, because we have the capacity to detect things, to find out the false positives. 27:54.240 --> 28:01.560 We have the technology and the experience, but we don't have the time to manage every, every alert. 28:01.560 --> 28:03.840 So we have to prioritize. 28:05.320 --> 28:13.340 And if you permit, I will share my morning routine with the CSF team I work in. 28:13.380 --> 28:23.960 When a new variability is discovered every, every morning, we talk about this and we share questions. 28:25.440 --> 28:32.460 The first thing is when a new variability is discovered, we talk about the CVSS best score. 28:32.460 --> 28:36.660 We talk about if we are vulnerable or not. 28:36.660 --> 28:39.960 Are we exposed on the internet with this vulnerability? 28:39.960 --> 28:45.400 This vulnerability has been identified on a critical asset. 28:46.140 --> 28:51.760 Are we aware of any functional exploit with this vulnerability? 28:51.880 --> 28:57.400 Is there any patch or compensation measure available? 28:57.600 --> 29:02.180 Are there any likelihood catalysts? 29:02.180 --> 29:05.880 Is this vulnerability exploited in the world? 29:05.880 --> 29:08.340 What is the media hype level? 29:09.120 --> 29:14.340 Has the vulnerability been exploited with relevant threat actors? 29:14.340 --> 29:17.200 And we ask for the CTI team. 29:17.200 --> 29:23.500 We also have the question, are we already found? 29:23.500 --> 29:32.720 And the team is in charge to investigate and research us if we can. 29:33.760 --> 29:40.940 And the next question is, are we really able to detect exploitation of this vulnerability? 29:41.140 --> 29:57.600 And at the end of the day, at the end of my morning, sorry, the managers say, okay, we have enough data to initiate a crisis and to treat this in priority. 29:59.820 --> 30:02.240 It's definitely a teamwork. 30:02.240 --> 30:08.280 It's not just become within the CTI team. 30:12.080 --> 30:14.580 It's really a teamwork. 30:14.640 --> 30:18.200 All the IT and business service lines are involved. 30:19.680 --> 30:24.120 The second thing is that vulnerability metadata are not static. 30:24.120 --> 30:28.140 They are continuously evolving over the time. 30:28.140 --> 30:39.740 Everything changes when a new patch is available, when a new exploit is placed, and when a new security resource is available. 30:39.740 --> 30:47.620 One event could change the way to manage a security incident. 30:48.460 --> 30:54.800 And as you remember, we start using the CVSS BASC score. 30:54.800 --> 31:03.620 And we want to know today if the CVSS BASC score is sufficient enough to be a primary factor of discrimination. 31:04.900 --> 31:09.460 Just a quick reminder of the CVSS scoring. 31:09.460 --> 31:12.740 CVSS scoring, there are three vectors. 31:12.740 --> 31:20.160 The BASC score, which represents the internal characteristics of the vulnerability. 31:20.160 --> 31:28.080 We also have a temporal vector, which represents the characteristics of the vulnerabilities that change over time. 31:28.520 --> 31:37.520 And we have another component about the environmental, which represents the characteristics of the vulnerability within the client context. 31:38.280 --> 31:43.860 CVSS is the norm, is the standard adopted. 31:43.860 --> 31:58.980 But the CVSS BASC score is usually provided, but the temporal and the environmental scores are on our behalf. 31:58.980 --> 32:00.940 We have clues. 32:00.940 --> 32:07.180 We have information from many parts, which are not 32:11.500 --> 32:14.360 always on the same page. 32:15.080 --> 32:20.900 It's just a score, a BASC score. 32:20.900 --> 32:31.850 For example, we have FunFact, which was scored at 5, and Spectre was scored at minus 5. 32:31.850 --> 32:44.110 So we just have the CVSS BASC score and the primary discriminator. 32:45.930 --> 32:54.430 We hope to see if it's sufficient enough to do our job. 32:55.090 --> 32:59.130 So just go deeper with it. 32:59.130 --> 33:06.690 We found that we have to manage multiple criteria for prioritization. 33:06.690 --> 33:14.630 And we have to manage the CVSS BASC score about the batch availability, the age of the vulnerability. 33:15.070 --> 33:19.790 We have to manage the discovery ease and the detection ease. 33:19.790 --> 33:28.170 All of this data are available from various sites or feeds of information. 33:28.630 --> 33:34.790 But all of these are publicly and in quite good quality. 33:35.810 --> 33:41.940 For the criteria of prioritization, it's all about the threats, about the temporal metrics. 33:43.650 --> 33:50.080 It's about the exploit availability, exploit maturity, and the ease of exploitation. 33:50.620 --> 34:12.520 Also, the threat intensity is very useful to know because it's a sign of the maturity and the likelihood of occurrence of the risk. 34:12.520 --> 34:26.780 With the MITRE ATT&CK and the CTI feeds information, it could be useful to know about the threat relevancy. 34:26.780 --> 34:30.500 Sorry, it's very hard to say that in French, remember. 34:30.980 --> 34:36.180 And it's excluded by monitors, protectors, or not. 34:37.460 --> 34:45.040 And the third pillar, it's about the assets in itself, the renewable assets. 34:45.040 --> 34:50.140 Is the asset critical or not? 34:50.140 --> 34:52.780 What is the exposure of the asset? 34:52.780 --> 35:01.000 Are we vulnerable from an asset exposed from the internet or a restricted network? 35:01.000 --> 35:05.080 And what about the distribution of the vulnerability? 35:06.180 --> 35:29.820 If we have a vulnerability with a high CVSS without a functional exploit on the restricted network, it's not the real priority. 35:29.820 --> 35:46.740 But a vulnerability with a standard middle CVSS, but exposed on the internet with an exploit available and a large distribution, it's the top one priority. 35:47.460 --> 36:01.780 So we take all these criteria for pre-stabilization and we have to make decisions to check if we have to manage this as quick as possible or not. 36:02.260 --> 36:06.620 The first thing is, okay, it's very useful. 36:06.620 --> 36:17.700 We have to ask for immediate correction and we start a crisis... we open the crisis room. 36:18.260 --> 36:22.000 The second is, okay, it's urgent. 36:22.000 --> 36:30.240 We ask for an immediate correction and we assess that the correction is efficient. 36:30.820 --> 36:35.840 The third action is, okay, it's a vulnerability. 36:35.840 --> 36:37.660 We know about this. 36:37.660 --> 36:43.860 Apply the fix in the next patching campaign, but no more. 36:44.280 --> 37:02.180 Finally, if the vulnerability matches no top criteria, okay, apply a fix if possible, but we don't have any intention of this. 37:02.180 --> 37:04.500 We have to choose our battle. 37:05.840 --> 37:10.640 The top of vulnerability, we don't manage this. 37:15.780 --> 37:24.440 For that, we are working on the new tool, which is a battle here. 37:26.820 --> 37:34.700 The open sourcing of the... this application is currently in discussion. 37:34.700 --> 37:37.180 I hope it will be the case. 37:37.620 --> 37:43.460 The idea of the battle here is to manage all these metrics. 37:45.220 --> 37:56.800 And we use... we massively use the CVE search and the app of CVE tools, which are open source tools released by the circle. 37:57.760 --> 38:24.000 The idea is to grab some... to collect and clean data, like CVE, CPE, cross-references, to create and update vulnerability metadata from this... from the NVD, the exploit DB, packet store, meta-exploit, Talos, the enable DB, and so on. 38:24.000 --> 38:31.760 And to compute a vulnerability prioritization rating using the vulnerability metadata. 38:31.760 --> 38:34.880 And the asset criticality and exposure. 38:34.880 --> 38:43.000 And this sector are known by platform manager. 38:43.180 --> 38:54.560 Because in platform manager, we know that we found a vulnerability on an asset exposed on the internet, on the internet network. 38:54.560 --> 38:59.680 And we know about the distribution too. 39:01.020 --> 39:13.160 And the idea is to provide platform manager a rating from the vulnerability found using any scanner as well. 39:13.440 --> 39:23.460 We can also use the battle here to track changing on the changes, sorry, on vulnerability like CVSS, exploit known, and so on. 39:23.460 --> 39:47.380 And to perform alerting, like if we found that... if we found a vulnerability on the monitored product or product versions, okay, we send automatically an email, we send an event, we send a slack, we open a Jira ticket, and so on. 39:47.560 --> 39:57.060 And finally, the idea is also to share feeds with using platform and CTI. 39:57.720 --> 40:02.360 So we will talk about this one later. 40:03.980 --> 40:07.220 I reached the end of the presentation. 40:07.780 --> 40:19.420 So if we can just have a step back and talk about all automating, let's say your seconds, it's quite possible. 40:19.420 --> 40:24.540 The idea is to have a cost effective activities. 40:24.880 --> 40:42.920 We start to rational the tool integration, the product licenses, and all the things needed to deploy and use the various security scanners, we have to. 40:43.200 --> 40:47.600 The second one is to provide turnkey solutions. 40:47.600 --> 40:49.300 Every component is available. 40:49.300 --> 40:53.400 So document images is very easy to use and they're deployed. 40:53.400 --> 40:57.280 We provide templates for scan policy and so on. 40:57.280 --> 41:07.940 The third one is a patrol and all of the tool galaxy is open source and easily customizable to your specific needs. 41:07.940 --> 41:16.920 And we have documentation, we also have to improve the documentation, but everything is available. 41:19.740 --> 41:24.600 And globally, it's a full stack and continuous assessment. 41:24.600 --> 41:41.560 The idea is to have a 360 degree overview on your assets to perform a real time assessment with relevant data to keep you updated from every source where we can. 41:42.120 --> 41:46.640 Finally, it's made with love by Express. 41:48.340 --> 41:58.940 We and all the community, the patrol community is composed by security. 42:02.440 --> 42:16.720 And finally, if we can summarize with two things, for big companies, it's quite an opportunity to aggregate findings from different existing tools you already have in place. 42:16.720 --> 42:25.640 And for newcomers and small organizations, you can bring new capacities to quickly improve your security. 42:27.520 --> 42:30.140 So what next? 42:30.880 --> 42:33.740 We have a roadmap, of course. 42:33.740 --> 42:54.600 We are working hard to improve our integration with all the tools, especially two tools, DeHype, which is a security incident response, and Umbroader, which is an IT automation and security compliance tool. 42:54.840 --> 43:02.360 All of them are open source projects, very, very mature projects. 43:02.440 --> 43:07.940 And we definitely want to have more integration with this. 43:08.420 --> 43:15.760 We also try to improve the Python client API. 43:15.760 --> 43:25.420 We are currently redesigning the front end of the platform manager. 43:25.420 --> 43:36.220 We are also testing endlessly new use cases in debugging, improving quality and security, global security of the platform. 43:36.260 --> 43:39.720 And we also are building an enterprise solution. 43:41.380 --> 43:49.720 But it's an open source project, and it will be always the case. 43:49.720 --> 43:53.080 Contribution is really, really needed. 43:53.080 --> 44:02.380 So if you have the ability to test it and give us feedback, it would be very, very great for us. 44:02.380 --> 44:16.520 And if you want to contribute or just to push new issues, we will be very happy to have this. 44:19.840 --> 44:24.730 So we are at the end of the presentation. 44:25.480 --> 44:33.540 So if you have any questions, please do it in the chat room. 44:33.680 --> 44:43.520 And finally, I know it's a lot late to say that, but I really want to thank the DEF CON organization. 44:44.160 --> 44:47.450 Thank you for accepting my talk. 44:47.450 --> 44:54.610 And thank you for you guys and girls to have attended this session. 44:54.610 --> 44:55.030 Thank you. 44:55.030 --> 44:56.710 Thank you very much. 44:57.130 --> 44:59.890 And go for questions. 44:59.890 --> 45:00.910 Thank you.