[00:02.480 --> 00:09.560]  Hello, everyone. So, please take a seat, grab a coffee, close the door. Do you hear me?
[00:09.980 --> 00:16.340]  No, I'm sorry. It's a pre-recorded session. So, I can't hear you at the moment. As you
[00:16.340 --> 00:22.180]  are listening, just record I'll be on holiday in the south of France in my swimming costume.
[00:22.720 --> 00:28.760]  So, give me a question in the chat room. I'll be pleased to answer you at the same time.
[00:29.300 --> 00:34.760]  So, hello, everybody. I'm Nicolas. Just a few words to present myself. I'm an independent
[00:34.760 --> 00:43.000]  tester, security editor. 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:58.540]  So, as you see and heard, I'm French. So, sorry for my French. Thank you.
[00:59.460 --> 01:09.080]  We'll talk about automating security operations. What does it mean to you and to me today?
[01:09.080 --> 01:15.920]  Everyone has his own definition. For me, security operations could be related to
[01:16.200 --> 01:21.920]  a bunch of activities. For now, please consider at least these activities. I will talk about
[01:21.920 --> 01:30.760]  penetration testing, security control assessment, CTI, and DFI operations,
[01:30.760 --> 01:37.900]  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:53.300]  And we'll talk about Patrol. Patrol is an open source framework for automating and orchestrating
[01:53.300 --> 02:01.240]  tasks and security operations. It provides a solution to get a continuous and full stack
[02:01.240 --> 02:10.240]  overview of your cyber exposure. The solution, sorry, lets you to define your assets,
[02:10.240 --> 02:18.340]  policy, and the scan you want to perform. The scans give you findings. And all these findings
[02:18.340 --> 02:26.880]  are then collected, analyzed, and aggregated within a unique database. We developed several
[02:26.880 --> 02:34.280]  engines and connectors to existing security tools to assess risk on various security domains.
[02:34.280 --> 02:42.660]  The idea is to get a risk overview from IP to data level. The scans could be start one shot,
[02:42.660 --> 02:49.280]  scheduled on, started on the regular basis. And the final goal is to get a continuous monitoring
[02:49.280 --> 02:56.920]  of our assets and our security posture on all stacks. All the findings, the findings could be
[02:57.100 --> 03:03.500]  a confirmed vulnerability, a suspicious change in our systems, or a suspicious activity over
[03:03.500 --> 03:11.800]  internet. These findings are then contextualized and tracked over the scans. And that's all for
[03:11.800 --> 03:23.880]  me. Now, of course, it's not a tool presentation. I just want to tell you about security operation
[03:23.880 --> 03:33.660]  and about automating SecOps. 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:48.540]  These are acceleration and diversification. This applies to assets, threats, and, by the way,
[03:48.540 --> 03:57.440]  security incidents involved. We see an acceleration of digital program and diversification of assets.
[03:57.880 --> 04:06.340]  So, thanks to the digital transformation program, we see an explosion of IT project. The information
[04:06.340 --> 04:12.420]  systems are more and more open to the world, and then more and more open to hostilities.
[04:12.920 --> 04:20.400]  We have to deal with new technologies every day. New product, new framework, new library,
[04:20.400 --> 04:28.380]  and all these technologies are updated every day. We also see changes in the software delivery
[04:28.380 --> 04:36.900]  processes. 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:53.780]  And a go live means a new application, and, by the way, new vulnerabilities or
[04:55.360 --> 05:04.200]  new exposed things. The threats are growing too. The number of CVEs is growing year after year.
[05:04.200 --> 05:10.820]  It's a metric. I don't know if it's a good metric to talk about the number of CVEs, but
[05:11.480 --> 05:18.700]  it could be representative. 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:30.600]  From a different point of view, we have to cover a quickly changing IT landscape,
[05:30.600 --> 05:36.200]  and at the end of the day, it's increasingly hard to get a realistic, comprehensive,
[05:36.620 --> 05:42.020]  and sufficiently updated vision of our cyber risk exposition.
[05:42.740 --> 05:50.860]  We also have to face another problem. It's the talent shortage problem. We have not enough
[05:50.860 --> 05:58.320]  people to do the job at the moment. Lots of tasks are repetitive, and this leads people to
[05:58.320 --> 06:06.420]  lose their motivation and leave the team. We definitely believe it's time to adapt our cyber
[06:06.420 --> 06:16.420]  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:35.530]  The first one is for the red team. It's about identifying vulnerabilities on our assets
[06:35.530 --> 06:42.630]  before attacker two. And for the blue team, it's to identify indicators of compromissions,
[06:42.630 --> 06:53.070]  which could be past, current, or future of a potential security incidents. And to do this,
[06:53.070 --> 07:00.990]  we have to keep us updated from many, many things. The first one is to keep us updated from the
[07:00.990 --> 07:08.210]  continuous transformation of our assets. It could be more or less considered as shadow IT in big
[07:08.210 --> 07:15.190]  companies. We have to keep us updated from the infosec knowledge database, the new research
[07:15.190 --> 07:23.130]  publications, the talks talking about the new vulnerability or new way to detect certain things
[07:23.990 --> 07:31.230]  or to exploit the vulnerability. And all the security news and the spectrum of threat scenario
[07:31.230 --> 07:38.310]  is changing also every day. We have to manage lots of feeds of information every day.
[07:39.230 --> 07:46.330]  And finally, we found that scanning our assets is not efficient anymore. We have to monitor
[07:46.330 --> 07:54.670]  external resources to detect leaks, attack signals, and to understand how third parties see
[07:54.670 --> 08:03.190]  our security posture. And for day-to-day work, it could be very hard to manage all of this
[08:03.830 --> 08:13.950]  information. And the cyber security industry, it's a race against the clock.
[08:14.830 --> 08:19.730]  And the third aspect we have to tackle is the window of exposure problem. It's all about
[08:19.730 --> 08:27.130]  our reactivity. Today, we know that attackers will attack us, not just because we have a bank,
[08:27.130 --> 08:35.650]  we are a gas industry, we are talking plenty. No, it's just because we are on the internet and
[08:35.650 --> 08:42.010]  new vulnerabilities are found everywhere. It's just increasing the likelihood of attack scenarios.
[08:42.010 --> 08:48.470]  So the windows of exposure is a real problem and could be handled with priority. We said
[08:48.470 --> 08:54.380]  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:20.190]  And orchestration, it's about automating a lot of things at once. It's about coordination and
[09:20.190 --> 09:30.460]  management of automated tasks. Before we go, let's start our experience. A few months ago,
[09:30.460 --> 09:36.320]  I set up a Kubernetes cluster with default configuration exposed to the internet. It
[09:36.320 --> 09:46.200]  was unfiltered. Maybe you see what will be the next thing. 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:15.060]  Just because probably a scanner identified that a non-secure service was exposed on the public IP
[10:15.060 --> 10:21.820]  and the attacker automatically deployed his payload on my server. So I don't blame him.
[10:21.820 --> 10:28.040]  I don't blame him. He's doing his job. He's doing a great job for this point of view.
[10:28.660 --> 10:34.960]  The fact we have to remember today, it's not that I'm a cheap DevOps, no. We have to accept
[10:34.960 --> 10:39.880]  that attackers do automation and better than us in their field.
[10:41.060 --> 10:48.220]  So why automating SecOps? The first thing is, for a defensive point of view, is to do more checks,
[10:48.220 --> 10:55.360]  to cover a larger and diversified scope, to cover a bigger perimeter of assets and make more control
[10:55.360 --> 11:03.340]  on each stack. And the second thing is to do it more often. It could be
[11:04.420 --> 11:10.440]  continuous checks. It could be very useful to reduce the windows of exposure,
[11:10.440 --> 11:16.780]  to reduce the delay in discovering and fixing a security incident.
[11:18.880 --> 11:26.960]  The third thing I would like to say, it's about efficiency. As I told you before,
[11:26.960 --> 11:30.640]  we have to face a big problem, a time-shortened problem.
[11:31.660 --> 11:40.680]  The idea is to reduce the time affected to low-value-adding tasks, to focus on more complex
[11:40.680 --> 11:53.080]  security cases. And for doing this, we have to automate the simple task. It's also a way to
[11:53.080 --> 12:01.540]  reduce and manage costs and to start for low KPIs. It could be also very useful to
[12:02.680 --> 12:10.240]  help you in your compliance and benchmark activities, to define and expedite the same
[12:10.240 --> 12:21.160]  control on a subset of assets and do it continuously to see the trends and how far
[12:22.040 --> 12:25.380]  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:43.660]  So, there are several downsides we have to discuss. Of course, there are limits. It doesn't
[12:43.660 --> 12:54.020]  cover all of the risks in itself. If you automate your control, you will have an increasing number
[12:54.020 --> 13:06.360]  of alerts to manage, an increasing number of false positives. We found also that it's very useless,
[13:06.360 --> 13:13.040]  inefficient to found functional vulnerabilities. We also have to qualify and contextualize all
[13:13.040 --> 13:23.680]  the findings we have, we have found. And about the TCO, yes, automating, we don't automate things
[13:23.680 --> 13:31.280]  by magic. We use tools that orchestrate all the tools. So, we have also to manage and exploit
[13:31.280 --> 13:41.980]  the tools. At the end of the day, a tool is a tool. And it's very useless without a cyber
[13:41.980 --> 13:47.400]  defense strategy. 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:03.680]  Because we wanted to improve our level of manageriality and to become more efficient to
[14:03.680 --> 14:15.990]  adapt our work. The core concept is to efficiently moving from reactive to predictive, more or less
[14:15.990 --> 14:24.070]  predictive security posture with the benefits from the power of automation.
[14:24.910 --> 14:32.430]  And also, we decided to use... to don't develop our tools, but to use in priority the best of
[14:32.430 --> 14:39.710]  built tools. The great tools exist, but they're not addressing all the stacks at the same level.
[14:40.270 --> 14:47.250]  Issues of quality are very efficient to scan for vulnerabilities, for misconfiguration
[14:47.250 --> 14:56.690]  on infrastructure and your cloud services. But the web application scanners and the
[14:56.690 --> 15:01.800]  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:27.960]  We found that we have to support scan policy, which are realistic from an attacker point of
[15:27.960 --> 15:36.020]  view. And the idea was to take the benefit from the best part of
[15:36.020 --> 15:42.600]  several security tools, making it easier to define a scan policy and to plan it.
[15:44.660 --> 15:51.020]  And PathWall... I will talk about PathWall a little bit. PathWall is composed in two
[15:51.020 --> 15:55.440]  independent types of applications. The first one on the left is the manager,
[15:55.440 --> 16:02.640]  the front-end application, where you have your dashboard, you manage your assets,
[16:02.640 --> 16:08.820]  you define your scans, you have your findings, and you try to manage the engines,
[16:08.820 --> 16:15.340]  which are the micro-applications that perform the scan. All these applications are open source
[16:15.340 --> 16:26.430]  and developed with Python. All features are reachable through the web UI or the REST API.
[16:29.100 --> 16:36.500]  The PathWall engines are the probes. They are the micro-applications that perform the scans,
[16:36.500 --> 16:42.360]  parse, analyze, and format the findings into a unique and pivoting format.
[16:43.160 --> 16:53.260]  This could be deployed on several separate servers. We can scale it that way.
[16:54.920 --> 17:02.440]  For example, you can deploy probes on your internet, on your internal network,
[17:02.440 --> 17:10.840]  and probes on your administration or DMZ, which are your restricted networks.
[17:11.700 --> 17:18.040]  And it could be the binding of your endpoint. And these PathWall engines are...
[17:20.800 --> 17:30.160]  Sorry. They scan the assets. For example, we developed an engine for Nmap.
[17:30.240 --> 17:38.480]  We don't really develop Nmap, but we made a connector to Nmap. And that way, we can perform
[17:38.480 --> 17:49.260]  on the same assets security scans for using Nexus, Nmap, OpenVAS, Qualys,
[17:49.260 --> 17:59.360]  and other security tools from the same cockpit. And all the findings have the same look.
[17:59.360 --> 18:06.040]  And we can compare and track all the findings on these assets issued by the
[18:07.000 --> 18:17.980]  separate engines we use. A bit deeper. PathManager, as I told, it's the front-end application.
[18:18.800 --> 18:26.360]  Here, you define your assets and a group of assets. 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:43.960]  The PathWall engines are the connectors with the scanner which could scan the
[18:44.660 --> 18:49.120]  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:10.500]  Or a link to your CTI repeater. You can also create the tickets or
[19:11.920 --> 19:21.320]  inject alerts or raise alerts to your DFI system. You can also inject the data in your sim
[19:21.320 --> 19:30.440]  or on your ELK if you want to analyze or to make alerts on a different way.
[19:34.380 --> 19:44.420]  As today, we developed a large range of engines in various domains. For each engine, we create
[19:44.900 --> 19:53.060]  a Docker image including the tool needed and the REST API to deal with them. So, you don't have
[19:53.060 --> 19:59.680]  to install tools, dependencies, or manage the system requirements. It's just as simple as a
[19:59.680 --> 20:17.640]  Docker pool. It's true, except from several engines, like NMAP with the Docker image,
[20:17.640 --> 20:25.100]  do not embed the scanner. But it could be linked to your instance.
[20:25.100 --> 20:37.680]  So, on this slide, we see a lot of engines, a lot of various domains. The idea of PathWall,
[20:39.920 --> 20:50.220]  it's a framework. You can build your tool to the detection of the control you have to perform.
[20:50.220 --> 21:00.620]  I don't see many companies that use PathWall with all of these engines. It's more or less
[21:00.620 --> 21:14.860]  separated between the vulnerability assessment or the data lakes or the static code analysis
[21:14.860 --> 21:25.040]  or dynamic code analysis. We also have a lot of ideas for the nature engines regarding
[21:25.040 --> 21:41.320]  gravity management, CTI, web application scanners, and so on. So, the engines are also open source
[21:41.320 --> 21:50.660]  and we accept any contribution to create or to give us ideas to develop any engine.
[21:51.400 --> 22:11.200]  Maybe it's time to talk about use cases. The first one is... I come from the right team. I
[22:12.080 --> 22:24.280]  always do the same. The first step of the test is to perform the recon activities. So, we
[22:24.920 --> 22:34.580]  search for subdomains. We always have IP. We try to discover the port, the open port. We
[22:34.580 --> 22:43.620]  fingerprint these services. We search for vulnerabilities and so on. For this, we use
[22:43.620 --> 22:55.220]  several tools with the same, more or less, the same settings on your assets. So, with PathWall,
[22:55.220 --> 23:06.420]  we use PathWall in our security assessment to do this as quick as possible and to do this
[23:06.420 --> 23:18.480]  continuously. The second use case is to examine the source code and the running web applications
[23:18.480 --> 23:25.820]  for security defects. It's to be involved in the CI-CD pipeline.
[23:26.660 --> 23:34.640]  So, on each commit, we take on the code repository. We are able to clone the project
[23:34.640 --> 23:40.900]  and start a static code analysis using the one-day dependency checks or the
[23:41.340 --> 23:53.140]  for the GS dependencies. And the code is built in and so on. And once the web application is
[23:53.140 --> 23:58.600]  deployed on the staging environment or on the predictions, we can also orchestrate
[23:58.600 --> 24:05.520]  autonomous scan using Arachne, ZAP, and NIC2.
[24:08.920 --> 24:15.300]  PathWall is available through the REST API, and we also developed PathWall for PyClient,
[24:15.300 --> 24:21.840]  which is a Python library. So, it's very easy to integrate with all those security tools.
[24:24.310 --> 24:32.170]  The third one is about efficient preparation scenario. We use it to search for early signs
[24:32.170 --> 24:41.770]  of malicious domains and the websites present. The idea is to search for suspicious domains
[24:41.770 --> 24:50.630]  or type of cross-query domain. And once we identify them, we can monitor them to look
[24:50.630 --> 25:00.930]  for changes. Are they still parked? Are they should certificate? What is the web application
[25:01.750 --> 25:10.910]  look like? Are they new exposed services? And so on. And if we have any suspicious change on the
[25:11.750 --> 25:17.490]  attacker's assets, we express an alert and we manage them.
[25:19.430 --> 25:26.470]  The third use case is code leaks on GitHub. Many, many, many times,
[25:28.490 --> 25:38.430]  DevOps or IT people are leaking something on GitHub because, I don't know, it's easy,
[25:38.430 --> 25:47.800]  we don't really know how to use it. And we don't really know that it's a public repo. It's public.
[25:47.990 --> 25:57.970]  So, we want to search for leaked internal resources code. API keys, password. And we
[25:57.970 --> 26:11.970]  developed just a simple scrapper on GitHub to monitor our keywords and our patterns
[26:12.850 --> 26:23.190]  to just detect that we don't have leaked any security system script or API keys
[26:30.870 --> 26:40.270]  We will talk about use cases, but we found that when we automate all these security tools,
[26:40.270 --> 26:51.710]  we can address a lot of use cases. So I want to talk about it.
[26:53.820 --> 27:06.820]  Just step back a bit. If you orchestrate the security tools, you will perform more control
[27:06.820 --> 27:16.120]  and do it more often. It will result in more findings. And it will result to more alerts.
[27:16.120 --> 27:26.300]  And the security dashboard will look like a Christmas tree. 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:49.700]  And it's the key challenge today, because we have the capacity to detect things,
[27:49.700 --> 27:57.080]  to find out the false positives. We have the technology and the experience,
[27:57.080 --> 28:03.840]  but we don't have the time to manage every, every alert. 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:38.660]  We talk about if we are vulnerable or not. Are we exposed on the internet with this
[28:38.660 --> 28:45.400]  vulnerability? This vulnerability has been identified on a critical asset.
[28:46.140 --> 28:54.140]  Are we aware of any functional exploit with this vulnerability? Is there any patch or
[28:54.140 --> 29:02.920]  compensation measure available? Are there any likelihood catalysts? Is this
[29:02.920 --> 29:09.920]  vulnerability exploited in the world? What is the media hype level? Has the
[29:09.920 --> 29:17.200]  vulnerability been exploited with relevant threat actors? And we ask for the CTI team.
[29:17.200 --> 29:28.380]  We also have the question, are we already found? And the team is in charge to investigate and
[29:28.380 --> 29:39.900]  research us if we can. And the next question is, are we really able to detect exploitation of this
[29:39.900 --> 29:49.440]  vulnerability? And at the end of the day, at the end of my morning, sorry, the managers say,
[29:49.440 --> 29:57.600]  okay, we have enough data to initiate a crisis and to treat this in priority.
[29:59.820 --> 30:14.580]  It's definitely a teamwork. It's not just become within the CTI team. It's really a teamwork.
[30:14.640 --> 30:18.200]  All the IT and business service lines are involved.
[30:19.680 --> 30:26.160]  The second thing is that vulnerability metadata are not static. They are continuously evolving
[30:26.160 --> 30:34.300]  over the time. Everything changes when a new patch is available, when a new exploit is placed,
[30:34.300 --> 30:46.420]  and when a new security resource is available. One event could change the way to manage a security
[30:46.420 --> 30:57.500]  incident. And as you remember, we start using the CVSS BASC score. And we want to know today
[30:57.500 --> 31:03.620]  if the CVSS BASC score is sufficient enough to be a primary factor of discrimination.
[31:04.900 --> 31:13.420]  Just a quick reminder of the CVSS scoring. CVSS scoring, there are three vectors. The BASC score,
[31:13.420 --> 31:21.780]  which represents the internal characteristics of the vulnerability. We also have a temporal
[31:21.780 --> 31:28.080]  vector, which represents the characteristics of the vulnerabilities that change over time.
[31:28.520 --> 31:33.080]  And we have another component about the environmental, which represents the
[31:33.080 --> 31:41.220]  characteristics of the vulnerability within the client context. CVSS is the norm, is the standard
[31:42.820 --> 31:55.600]  adopted. But the CVSS BASC score is usually provided, but the temporal and the environmental
[31:55.600 --> 32:07.180]  scores are on our behalf. We have clues. We have information from many parts, which are not
[32:11.500 --> 32:24.450]  always on the same page. It's just a score, a BASC score. For example, we have FunFact,
[32:24.450 --> 32:38.310]  which was scored at 5, and Spectre was scored at minus 5. So we just have the CVSS BASC score
[32:38.310 --> 32:54.430]  and the primary discriminator. We hope to see if it's sufficient enough to do our job.
[32:55.090 --> 33:06.690]  So just go deeper with it. 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:22.470]  We have to manage the discovery ease and the detection ease. All of this data are available
[33:22.470 --> 33:33.130]  from various sites or feeds of information. But all of these are publicly and in quite good
[33:33.130 --> 33:41.940]  quality. 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:03.380]  Also, the threat intensity is very useful to know because it's a sign of the maturity and
[34:04.300 --> 34:19.120]  the likelihood of occurrence of the risk. With the MITRE ATT&CK and the CTI feeds
[34:19.120 --> 34:27.060]  information, it could be useful to know about the threat relevancy. Sorry,
[34:27.060 --> 34:36.180]  it's very hard to say that in French, remember. 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:53.160]  Is the asset critical or not? What is the exposure of the asset? Are we
[34:53.160 --> 35:01.480]  vulnerable from an asset exposed from the internet or a restricted network? And what
[35:01.480 --> 35:12.240]  about the distribution of the vulnerability? If we have a vulnerability with a high CVSS
[35:12.960 --> 35:30.000]  without a functional exploit on the restricted network, it's not the real priority. But
[35:30.460 --> 35:41.720]  a vulnerability with a standard middle CVSS, but exposed on the internet with an exploit available
[35:42.240 --> 35:50.220]  and a large distribution, it's the top one priority. So we take all these criteria for
[35:50.220 --> 36:00.380]  pre-stabilization and we have to make decisions to check if we have to manage this as quick as
[36:00.380 --> 36:08.960]  possible or not. The first thing is, okay, it's very useful. We have to ask for immediate
[36:09.760 --> 36:17.700]  correction and we start a crisis... we open the crisis room.
[36:18.260 --> 36:24.600]  The second is, okay, it's urgent. We ask for an immediate correction and we
[36:26.060 --> 36:35.840]  assess that the correction is efficient. The third action is, okay, it's a vulnerability.
[36:35.840 --> 36:43.860]  We know about this. Apply the fix in the next patching campaign, but no more.
[36:44.280 --> 36:58.680]  Finally, if the vulnerability matches no top criteria, okay, apply a fix if possible,
[36:58.680 --> 37:04.500]  but we don't have any intention of this. We have to choose our battle.
[37:05.840 --> 37:22.460]  The top of vulnerability, we don't manage this. For that, we are working on the new tool,
[37:22.460 --> 37:34.800]  which is a battle here. The open sourcing of the... this application is currently in discussion. I
[37:34.800 --> 37:43.460]  hope it will be the case. The idea of the battle here is to manage all these metrics.
[37:45.220 --> 37:53.220]  And we use... we massively use the CVE search and the app of CVE tools, which are
[37:53.220 --> 38:04.280]  open source tools released by the circle. The idea is to grab some... to collect and clean data,
[38:04.280 --> 38:11.000]  like CVE, CPE, cross-references, to create and update vulnerability metadata
[38:11.630 --> 38:20.880]  from this... from the NVD, the exploit DB, packet store, meta-exploit, Talos,
[38:20.880 --> 38:28.420]  the enable DB, and so on. And to compute a vulnerability prioritization rating using
[38:29.290 --> 38:38.380]  the vulnerability metadata. And the asset criticality and exposure. And this sector
[38:39.030 --> 38:46.220]  are known by platform manager. Because in platform manager, we know that
[38:46.950 --> 38:54.680]  we found a vulnerability on an asset exposed on the internet, on the internet network. And
[38:54.680 --> 39:04.500]  we know about the distribution too. And the idea is to provide platform manager a rating
[39:04.500 --> 39:16.620]  from the vulnerability found using any scanner as well. We can also use the battle here to track
[39:16.620 --> 39:24.240]  changing on the changes, sorry, on vulnerability like CVSS, exploit known, and so on. And to
[39:24.780 --> 39:33.720]  perform alerting, like if we found that... if we found a vulnerability on the monitored product or
[39:34.590 --> 39:43.740]  product versions, okay, we send automatically an email, we send an event, we send a slack,
[39:43.740 --> 39:54.600]  we open a Jira ticket, and so on. And finally, the idea is also to share feeds with using
[39:54.600 --> 40:07.220]  platform and CTI. So we will talk about this one later. I reached the end of the presentation.
[40:07.780 --> 40:17.220]  So if we can just have a step back and talk about all automating, let's say your seconds,
[40:17.220 --> 40:28.060]  it's quite possible. The idea is to have a cost effective activities. We start to rational the
[40:28.060 --> 40:36.020]  tool integration, the product licenses, and all the things needed to deploy and use
[40:36.750 --> 40:47.600]  the various security scanners, we have to. The second one is to provide turnkey solutions.
[40:47.600 --> 40:53.520]  Every component is available. So document images is very easy to use and they're deployed. We
[40:53.520 --> 41:01.120]  provide templates for scan policy and so on. The third one is a patrol and all of the
[41:01.120 --> 41:08.800]  tool galaxy is open source and easily customizable to your specific needs. And we
[41:10.180 --> 41:16.920]  have documentation, we also have to improve the documentation, but everything is available.
[41:19.740 --> 41:27.900]  And globally, it's a full stack and continuous assessment. The idea is to have a 360 degree
[41:27.900 --> 41:37.140]  overview on your assets to perform a real time assessment with relevant data to keep you updated
[41:37.740 --> 41:46.640]  from every source where we can. 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:09.040]  And finally, if we can summarize with two things, for big companies,
[42:09.660 --> 42:15.440]  it's quite an opportunity to aggregate findings from different existing tools you already have
[42:15.440 --> 42:21.500]  in place. And for newcomers and small organizations, you can bring new
[42:22.400 --> 42:30.140]  capacities to quickly improve your security. So what next?
[42:30.880 --> 42:41.240]  We have a roadmap, of course. We are working hard to improve our integration with
[42:42.160 --> 42:48.520]  all the tools, especially two tools, DeHype, which is a security incident response,
[42:48.520 --> 42:56.380]  and Umbroader, which is an IT automation and security compliance tool. All of them are
[42:56.380 --> 43:02.360]  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:22.500]  We also try to improve the Python client API. We are currently redesigning the front end
[43:23.280 --> 43:31.560]  of the platform manager. We are also testing endlessly new use cases in debugging, improving
[43:31.560 --> 43:38.540]  quality and security, global security of the platform. And we also are building an enterprise
[43:38.540 --> 43:49.720]  solution. But it's an open source project, and it will be always the case.
[43:49.720 --> 43:57.520]  Contribution is really, really needed. So if you have the ability to test it and give us
[43:57.520 --> 44:08.400]  feedback, it would be very, very great for us. And if you want to contribute or just to push
[44:08.400 --> 44:24.730]  new issues, we will be very happy to have this. So we are at the end of the presentation.
[44:25.480 --> 44:34.590]  So if you have any questions, please do it in the chat room. And finally,
[44:35.120 --> 44:43.520]  I know it's a lot late to say that, but I really want to thank the DEF CON organization.
[44:44.160 --> 44:53.830]  Thank you for accepting my talk. And thank you for you guys and girls to have attended this
[44:53.830 --> 45:00.910]  session. Thank you. Thank you very much. And go for questions. Thank you.