J'ai déjà longuement parlé de la maturation de la cybersécurité et du passage d'une sécurité basée sur des promesses à une sécurité basée sur des preuves . Dans cet article, je développerai l'une des tendances liées à cette transformation - à savoir l'essor de l'ingénierie de la sécurité.

Passer d'une sécurité basée sur des promesses à une sécurité basée sur des preuves et l'évolution de l'informatique

Quand je parle de la maturation de la cybersécurité , je veux dire en grande partie changer la façon dont nous abordons le faire. Jusqu'à très récemment, nous le considérions comme une fonctionnalité et supposions que la sécurité était un problème d'outil : si vous achetez le « bon » produit de sécurité « nouvelle génération » auprès d'un fournisseur de premier plan, vous serez « en sécurité ».

Maintenant, après de nombreuses années passées à voir comment cette approche n'a pas tenu ses promesses, nous commençons à comprendre que la sécurité est un processus, pas une fonctionnalité. Nous développons une conviction systémique selon laquelle nous devons revenir à l'essentiel : collecter des données de sécurité en un seul endroit, comprendre ce qui se passe dans notre environnement, apprendre ce qui constitue des pratiques commerciales normales dans notre organisation et ce qui peut être un signe de compromis, identifier comment pour détecter les comportements malveillants et réagir de manière appropriée. Au lieu d'obtenir un widget qui, lorsqu'il est activé, active un bouclier de protection impénétrable, les équipes de sécurité matures examinent la sécurité à travers le prisme des couches et des tâches à effectuer.

« La meilleure façon de construire une posture de sécurité est de la construire sur des contrôles et une infrastructure qui peuvent être observés, testés et améliorés. Il ne repose pas sur des promesses de fournisseurs qui doivent être prises au pied de la lettre. Cela signifie que l'ensemble exact d'activités et de comportements malveillants contre lesquels vous êtes protégé doit être connu et que vous devez être en mesure de le tester et de le prouver. Cela signifie également que si vous pouvez décrire quelque chose que vous souhaitez détecter et prévenir, vous devriez pouvoir l'appliquer unilatéralement sans l'intervention du fournisseur. Par exemple, si un ingénieur en sécurité a lu sur WannaCry, il devrait avoir la possibilité de créer sa propre logique de détection sans attendre un jour ou deux jusqu'à ce que son fournisseur publie une nouvelle version.

Un autre facteur qui modifie la façon dont la sécurité est assurée est l'évolution de l'informatique à laquelle nous avons assisté au cours de la dernière décennie. Il fut un temps où une formation en informatique était suffisante pour se lancer en tant que professionnel de la sécurité, car elle permettait de comprendre comment les différents éléments de l'infrastructure fonctionnaient, interagissaient les uns avec les autres et ce qui était nécessaire pour les sécuriser.

L'automatisation de l'informatique et l'essor du cloud font abstraction d'une grande partie de ce qui se passe en arrière-plan, ce qui rend plus difficile le développement de modèles mentaux autour de l'infrastructure informatique et la compréhension de la manière de la sécuriser. Pour réussir en matière de sécurité aujourd'hui, il faut comprendre l'infrastructure sur site, les différents composants de l'infrastructure cloud, ainsi que l'infrastructure en tant que code et les pipelines DevOps, pour n'en nommer que quelques-uns. À mesure que l'informatique devient plus complexe, les exigences envers les personnes chargées de la maintenance, de l'administration et de la compréhension de cette complexité augmentent.

Parmi les autres facteurs qui accélèrent le changement dans notre façon d'assurer la sécurité, citons :

- Faible corrélation entre les résultats et les dépenses de sécurité,

- Entreprise exigeant des résultats mesurables,

- Complexification croissante des environnements de sécurité et des clients,

- Prolifération des outils de sécurité,

- Maturité croissante des professionnels de la sécurité,

- Hausse des primes d'assurance,

- Émergence de la nouvelle génération de prestataires de services,

- Émergence de l'écosystème des fournisseurs support,

- Mise en place de cadres de sécurité, et

- Soutien des investisseurs à la sécurité fondée sur des preuves.

La cybersécurité du futur ressemblera beaucoup au génie logiciel

Voir le génie logiciel comme un modèle de cybersécurité

La cybersécurité est née dans les cercles de piratage - parmi les personnes à tendance technique curieuses des produits et des outils de rétro-ingénierie, du bricolage et de la pénétration de ce qui était considéré comme incassable. Ensuite, plusieurs fournisseurs de sécurité sont venus promettre la sécurité, en disant "nous vous alerterons quand quelque chose de mal se produira, ayez juste quelqu'un pour vérifier les alertes". Étonnés par la perspective d'une telle simplicité, nous avons commencé à embaucher des analystes de sécurité pour surveiller les alertes. Aujourd'hui, une dizaine d'années plus tard, nous constatons qu'il faut revenir à l'essentiel. Cette prise de vue est, évidemment, une simplification excessive, mais la vérité est que nous devons réintégrer les pirates dans l'industrie. La vérité est que la cybersécurité du futur ressemblera beaucoup à l'ingénierie logicielle.

Le développement de logiciels nous offre un excellent modèle : les analystes commerciaux et les chefs de produit opèrent entre le business et la technologie ; ils parlent aux clients, comprennent et évaluent les exigences commerciales, les traduisent en exigences techniques et hiérarchisent ces exigences pour le développement. J'entends souvent dire que les équipes de sécurité sont accusées de ne pas parler aux clients et de ne pas suffisamment comprendre les affaires. Bien que le sentiment soit juste, je pense que les personnes qui font ces déclarations passent à côté de l'essentiel : critiquer les professionnels de la sécurité technique pour ne pas comprendre les affaires revient à critiquer les ingénieurs back-end pour ne pas être doués pour les entretiens avec les utilisateurs. La vérité est simple : si les ingénieurs back-end voulaient faire des interviews d'utilisateurs, ils n'auraient pas choisi le back-end et seraient plutôt devenus des concepteurs UX.

Nous avons besoin d'équipes de sécurité pour mieux comprendre le métier, cela ne fait aucun doute. Mais nous ne pouvons pas résoudre le problème en envoyant tout le monde de l'informatique et de la sécurité commencer à interroger les employés de l'entreprise (bien que nous devrions encourager l'établissement de relations). Au lieu de cela, nous avons besoin de l'équivalent d' analystes commerciaux et de chefs de produit en sécurité pour combler le fossé .

Principes de génie logiciel pour la cybersécurité

Le génie logiciel offre un ensemble d'outils, de concepts, de principes et de modèles mentaux qui partagent la cybersécurité de demain.

Tout d'abord, la sécurité de demain sera la sécurité sous forme de code.

Maintenant que nous obtenons tout sous forme de code - politiques sous forme de code, infrastructure sous forme de code, confidentialité sous forme de code, détections sous forme de code, etc. - nous sommes en mesure de déployer, de suivre et de tester les modifications apportées à la posture de sécurité de l'organisation et les annuler si nécessaire. Ceci, à son tour, signifie une approche qui peut être testée et validée, renforçant davantage le point sur la sécurité fondée sur des preuves. Semblable à la façon dont cela fonctionne en génie logiciel, vous pouvez désormais exécuter des tests de sécurité automatisés pour voir comment votre système se comportera et employer une personne chargée de l'assurance qualité (pensez à un testeur de pénétration) pour aller au-delà des automates et rechercher des cas extrêmes non couverts par l'automatisation. .

Deuxièmement, la cybersécurité du futur reposera sur une surveillance continue, un déploiement continu et des itérations fréquentes. La posture de sécurité d'une organisation n'est pas statique, elle change à chaque seconde et la vitesse à laquelle elle change s'est accélérée avec l'essor du cloud. Quelques secondes après le déploiement d'une nouvelle couverture de détection et de réponse, l'environnement d'une organisation aurait changé avec des centaines de machines virtuelles lancées dans le cloud et des dizaines de nouvelles applications SaaS installées sur les terminaux, pour n'en nommer que quelques-unes. L'évaluation et la couverture de la sécurité ne peuvent pas rester statiques - elles doivent évoluer à mesure que l'organisation elle-même évolue. La sécurité est donc un processus et non une caractéristique - un processus basé sur une évaluation continue et un raffinement continu de la posture de sécurité de l'organisation.

Troisièmement, l'industrie de demain devra faire les choses à grande échelle, en privilégiant l'API. Fini le temps où les équipes de sécurité devaient se connecter à des dizaines d'outils pour affiner manuellement certaines configurations, et plus encore - déployer manuellement des solutions de sécurité. Tout doit être fait à l'échelle de la machine, via l'API.

Quatrièmement, la cybersécurité verra le monde des outils commerciaux coexister et s'intégrer étroitement au monde de l'open source. Bien que cela ait été le cas pour le génie logiciel pendant un certain temps avec tous les outils de génie logiciel commerciaux tirant parti des bibliothèques et des composants open source, dans le domaine de la cybersécurité, l'open source est souvent considéré séparément du marché des fournisseurs. J'ai déjà examiné en profondeur le rôle de l'open source dans la cybersécurité, je vois ce rôle grandir à mesure que l'industrie mûrit. Les fournisseurs de cybersécurité ne pourront pas s'en tirer en créant simplement des versions commerciales des outils open source ; ils devront s'appuyer sur le dessus et ajouter une valeur réelle au-delà de la déclaration que "nous ne sommes pas open source" et de montrer leur certificat de conformité SOC 2.

Adopter une approche technique de la sécurité signifie se concentrer sur l'amélioration des processus pour la fourniture continue de la défense au lieu de cocher les cases de conformité. Il permet aux équipes de sécurité de fournir des solutions techniques et de créer des outils évolutifs avant de recommander l'embauche de plus de personnes, ce qui, à son tour, leur permet de faire plus avec moins. Tous ces facteurs combinés font de l'approche de la sécurité fondée sur des preuves dont j'ai discuté en profondeur auparavant une fatalité ; ce n'est plus la question de si, c'est une question de quand (réponse : c'est déjà en train de se produire).

Place de la sécurité dans le cycle de vie du produit

Lorsque nous pensons à la sécurité, l'une des premières questions qui nous vient à l'esprit est "à quel endroit du cycle de vie du développement logiciel appartient-elle ?". Bien que ce soit une question valable, zoomer sur le cycle de vie du développement logiciel à lui seul crée des points lumineux autour de ce qui se passe avec le logiciel dans la nature. Pour discuter correctement du rôle de l'approche technique de la cybersécurité, il est impératif d'examiner le cycle de vie du produit dans son ensemble, qui comprend la façon dont le logiciel est construit ainsi que ce qui se passe après qu'il a commencé à être utilisé en production.

Historiquement, la sécurité était isolée de l'équipe de développement qui construisait le produit et, par conséquent, elle était considérée comme la dernière étape pour assurer la «conformité» avant la sortie. Certes, la sécurité n'était pas la seule partie du cycle de vie du développement logiciel (SDLC) qui existait en silo ; tout comme la gestion des produits (PM), la conception, l'ingénierie (souvent divisée en front-end et back-end) et l'assurance qualité (QA), pour n'en nommer que quelques-uns.

Avant l'adoption d'Agile qui a institué l'idée d'équipes interfonctionnelles, le développement logiciel se présentait à peu près comme suit :

1. Un chef de produit écrivait des exigences et les envoyait aux concepteurs
2. Les concepteurs construiraient des maquettes et les enverraient à l'équipe de développement
3. Les ingénieurs back-end termineraient leur partie du travail et enverraient la partie restante à l'équipe front-end
4. Le produit fini a ensuite été envoyé à QA pour examen

Comme les bonnes personnes n'étaient pas impliquées à la bonne étape, cette approche traditionnelle dite en cascade a entraîné beaucoup de gaspillage, d'inefficacités, de remaniements et de mauvaises décisions. Agile avec ses frameworks Scrum et Kanban , a conduit à de courtes itérations et à une publication fréquente du code, et surtout, il a créé des équipes de produits interfonctionnelles où un PM, un concepteur, des ingénieurs logiciels et un QA travailleraient ensemble. Concrètement, cela signifiait que les ingénieurs logiciels et l'assurance qualité fourniraient des commentaires sur les exigences et les conceptions avant qu'elles ne soient jugées prêtes pour le développement, et que les PM/AQ fourniraient leur contribution au fur et à mesure de la construction du produit, réduisant ainsi la nécessité de jeter le code plus tard. et refaire ce qui a déjà été "fait".

Agile n'a pas résolu tous les problèmes. En particulier, lorsque DevOps a émergé, les ingénieurs DevOps se sont retrouvés dépourvus de tout contexte sur ce que faisaient les équipes produit, rendant leur travail réactif et difficile à faire. Finalement, les meilleures pratiques de conception organisationnelle se sont rattrapées, et récemment, en 2019, Manuel Pais et Matthew Skelton ont publié ce qui est à mon avis le guide le plus percutant sur la conception d'équipes technologiques - Team Topologies: Organizing Business and Technology Teams for Fast Flow . Dans leur livre, Manuel et Matthew passent en revue les défis courants de la conception organisationnelle, partagent les meilleures pratiques concernant les modèles et les interactions d'équipe réussis et recommandent des moyens d'optimiser les flux de valeur pour les entreprises technologiques.

Jusqu'à récemment, la sécurité était en retard pour devenir une partie de l'organisation de développement, existant comme un poste de contrôle cloisonné qui, dans le meilleur des cas, donne le feu vert aux versions et attribue de nouveaux tickets aux équipes de développement, généralement marqués comme "la plus haute priorité". ”. Bien que ce soit encore une tendance observée dans de nombreuses organisations, l'approche de la sécurité a commencé à changer ces dernières années. Nous voyons la croissance de DevSecOps comme la réponse de la sécurité à DevOps, et à mesure que la sécurité est intégrée aux pipelines CI/CD, son rôle passe de la conformité à la fourniture de la défense. En ce qui concerne le développement de nouveaux produits, la sécurité commence en effet à ressembler à du génie logiciel.

À l'avenir, nous continuerons probablement à voir les équipes de sécurité fonctionner comme des unités autonomes au sein de leurs organisations. Cependant, de plus en plus de vulnérabilités spécifiques aux applications seront gérées par ceux qui construisent le produit et qui ont le plus de contexte sur le code - les ingénieurs logiciels. Les équipes de sécurité agiront en tant que consultants auprès des équipes de développement de produits, à l'instar du rôle joué aujourd'hui par les ingénieurs en fiabilité des plates-formes et des sites.

État d'esprit d'ingénierie pour l'infrastructure et les opérations de sécurité

Bien qu'il soit généralement facile d'imaginer à quoi pourrait ressembler un état d'esprit d'ingénierie vis-à-vis de la sécurité lorsque nous parlons de développement de logiciels, cela peut être beaucoup plus difficile à faire lorsque nous examinons l'infrastructure et les opérations de sécurité - des choses qui se produisent au jour le jour, après, et en dehors du développement logiciel. Cela s'explique en grande partie par le fait que la sécurité des applications fait partie du cycle de vie du développement logiciel et que les startups natives du cloud financées par le capital-risque recherchent activement des moyens de sécuriser leur code et de le faire de manière évolutive.

Comparativement, peu de discours ont été vus sur l'apport d'un état d'esprit, d'approches et de cadres d'ingénierie aux opérations de sécurité, à la détection et à la réponse, à la gestion des incidents, à la criminalistique numérique et à d'autres domaines de la sécurité. Ces composants vitaux des processus de cybersécurité d'une entreprise ont été considérés comme des éléments internes qui peuvent bien faire leur travail tant qu'ils ont « les bons produits » déployés sur le réseau et quelques personnes pour surveiller ces produits. Plus important encore, les équipes de sécurité ont constamment manqué de ressources et ont été épuisées par les derniers incendies, ce qui les empêche de se concentrer sur la construction de défenses de manière proactive.

Inutile de dire que cette approche s'est avérée limitative et souvent préjudiciable à la position de sécurité de l'organisation. Bien que je n'aie pas de preuves pour étayer cette affirmation, je suppose que la plupart (sinon toutes) les entreprises qui apparaissent dans les nouvelles comme ayant subi une violation au cours des dernières années, ont déployé les outils les plus récents et les plus performants dans leur environnement. Le fait que ces outils n'aient pas réussi à protéger les entreprises contre les incidents de sécurité ne signifie en aucun cas qu'ils font un mauvais travail (bien au contraire). Au lieu de cela, je pense que ces événements soulignent qu'aucun produit n'est à l'épreuve des balles malgré ce que le marketing du fournisseur peut suggérer, et pour défendre nos entreprises et nos employés, nous devons changer notre façon d'aborder la sécurité.

Adopter un état d'esprit d'ingénierie vis-à-vis de la sécurité signifie plusieurs choses, notamment :

• Accepter que les outils ne soient que des outils et regarder au-delà de la sélection des fournisseurs, les principes fondamentaux de la cybersécurité en tant que domaine de pratique. Cela signifie poser des questions telles que « Que dois-je faire pour sécuriser mon organisation ? Quels sont les risques auxquels je suis confronté ? Quels comportements malveillants peuvent se produire dans mon environnement ? Comment est-ce que je les détecte ? Comment vais-je réagir lorsqu'ils sont détectés ?", à la place "Quel outil dois-je acheter pour sécuriser mon organisation ?"
• Fortes de cette prise de conscience, les entreprises doivent mettre cette approche en pratique, en s'assurant qu'elles ont une visibilité totale sur leur environnement ("panel de verre unique"), sur ce qu'elles détectent et comment elles le font (savoir quelles détections fonctionnent dans leur environnement , ce qu'ils détectent exactement et comment ils le détectent), ainsi que la possibilité de tester leurs défenses de manière reproductible.
• Réaliser que de nombreux composants des opérations de sécurité peuvent et doivent être automatisés, et rechercher des moyens de créer des moyens évolutifs pour assurer la défense de l'organisation. En pratique, cela signifie adopter les détections en tant que code, l'infrastructure en tant que code et d'autres approches qui ont fait leurs preuves et s'adaptent à d'autres domaines technologiques. Lorsqu'une équipe détecte de nouvelles vulnérabilités et de nouveaux comportements malveillants, elle doit disposer des outils pour y répondre d'une manière qui élimine le besoin d'appliquer manuellement la même réponse à la même vulnérabilité demain.

Historiquement, la plupart des connaissances en matière de sécurité résidaient dans les têtes de praticiens expérimentés qui « ont été là, ont fait cela ». À mesure que l'industrie mûrit, nous devons rechercher des moyens de codifier ces connaissances et de les rendre partageables, testables et accessibles pour être utilisées et améliorées par les organisations du monde entier. La cybersécurité sera toujours un art car elle traite avec l'adversaire créatif et intelligent. Cependant, il doit également devenir une science si nous voulons continuer à développer notre base de connaissances et rendre les cyberdéfenses accessibles aux organisations qui ne peuvent pas se permettre d'embaucher « les meilleurs parmi les meilleurs » sur le terrain. L'adoption d'une approche scientifique et technique de la sécurité permettra aux équipes de sécurité de créer des systèmes et des processus pour faire leur travail de manière cohérente.

L'essor de l'ingénierie de la sécurité et comment elle change la cybersécurité de demain

L'évolution de l'ingénierie de détection et l'émergence de l'ingénierie de détection en tant que service

Au cours des dernières années, l'accent a été mis sur la transparence dans la détection des menaces. Le problème a attiré l'attention des praticiens de la sécurité, des fondateurs de startups et des analystes de l'industrie, pour n'en nommer que quelques-uns. En 2022, deux anciens analystes de Gartner, Anton Chuvakin et Oliver Rochford, ont écrit un mini-article intitulé « On Trust and Transparency in Detection » qui s'ouvre comme suit : « Lorsque nous détectons des menaces, nous nous attendons à savoir ce que nous détectons. Cela semble douloureusement évident, non ? Mais il est très clair pour nous que tout au long de l'histoire de l'industrie de la sécurité, cela n'a pas toujours été le cas. Certains d'entre nous se souviennent des débuts du réseau. Les systèmes de détection d'intrusion IDS étaient livrés sans que les clients puissent voir comment les détections fonctionnaient. Le marché a parlé, et ces vendeurs sont tous morts et enterrés par Snort et ses descendants, qui ont ouvert leurs signatures de détection pour révision et modification. Le billet de blog est une excellente lecture pour toute personne intéressée par le sujet.

L'environnement de chaque organisation est unique en son genre, et le caractère unique ne fait qu'augmenter avec la croissance du SaaS et l'émergence d'outils spécialisés pour presque tout. Chaque département de l'organisation dispose de dizaines d'outils qu'il utilise pour gérer son travail (imaginez seulement le nombre d'applications conçues pour remplacer l'utilisation de feuilles de calcul pour les seules équipes marketing, ressources humaines, finance, produit et opérations). En plus de cela, presque toutes les entreprises qui atteignent un certain niveau de croissance développent leurs propres applications internes pour économiser pour les cas d'utilisation propres à leurs opérations, à leur modèle commercial ou à leur stratégie de mise sur le marché.

Le caractère unique de l'environnement de chaque organisation signifie que la façon dont les attaquants pénétreraient dans chaque organisation et la façon dont les défenseurs seraient capables de détecter les comportements malveillants dans cet environnement seraient différentes. Concrètement, pour que les équipes de sécurité résolvent le problème de la détection de quelque chose d'unique à l'environnement de leur organisation, elles doivent créer une logique de détection pour cet environnement spécifique.

Les fournisseurs de sécurité qui promettent une couverture globale pour tout le monde constituent une excellente couche de base (tout comme l'antivirus), mais ils ne suffisent pas aux entreprises qui ont beaucoup à perdre.

L'ingénierie de la détection a beaucoup évolué au cours des 10 dernières années, comme en témoignent eux-mêmes ceux qui le pratiquent depuis une décennie . Dans l'article référencé ci-dessus, Zack Allen, directeur de la recherche sur la sécurité chez Datadog, décrit comment l'approche "plus il y en a, mieux c'est" pour créer du contenu de détection a évolué vers une prise de conscience mature que nous avons besoin d'un contenu de détection complet et de haute qualité, pas seulement "plus de détections". ". Les ingénieurs en détection qui étaient autrefois considérés comme des "sorciers" qui "descendent de leur flèche et prêchent au monde leurs dernières découvertes, présentes à Blackhat et DEFCON" sont désormais l'un des nombreux types d'ingénieurs en sécurité.

Parlant d'ingénierie de détection, Zack conclut :

« Vous ne pouvez pas écrire de détections pour votre produit de sécurité réseau si vous n'avez pas d'experts en sécurité réseau. Il en va de même pour les détections basées sur les terminaux, le cloud, les applications et les hôtes. C'est comme si un groupe de scientifiques des données construisait un modèle d'apprentissage automatique pour détecter l'asthme chez les patients. Cependant, ils ont oublié de faire venir un médecin pour leur montrer comment les patients atteints de pneumonie donneraient au modèle des faux positifs. Vous avez besoin d'experts en la matière. Cela n'a pas changé dans l'industrie, et cela ne devrait pas changer. Ce qui a changé, c'est que ces experts ont besoin d'une base solide dans les principes du génie logiciel. Vous ne pouvez pas mettre à l'échelle toutes ces détections et les déployer dans un environnement moderne, gérer des sprints (oui, c'est du génie logiciel :)), ou écrire des tests unitaires, d'intégration et de régression sans beaucoup de corps ou beaucoup d'automatisation. Je peux dire de manière fiable que mon patron préférerait entendre que je peux résoudre le problème avec un logiciel plutôt qu'en embauchant plus de personnes. »

Je vois deux signes que l'ingénierie de la détection a évolué vers une profession dédiée et bien définie : le nombre croissant d'événements tels que DEATHCon (Detection Engineering and Threat Hunting Conference), des conférences et des formations à Black Hat, BSides, et d'autres rassemblements de praticiens, ainsi que les débuts de la définition des étapes de maturité que les organisations traversent lors de sa mise en œuvre. La matrice de maturité de l'ingénierie de détection de Kyle Bailey est la meilleure tentative pour mesurer les capacités et la maturité de la fonction dans toutes les organisations.

Alors que de plus en plus d'organisations se rendent compte que la logique de détection n'est pas unique et qu'il est peu probable que les fournisseurs de sécurité soient en mesure de tenir leur promesse de « protéger tout le monde », nous commençons à voir des startups de cybersécurité spécialisées dans la détection de bâtiments. contenu. Au lieu de simplement déclencher des alertes, ces entreprises rendent le contenu de la règle lui-même visible et modifiable, ce qui permet aux équipes de sécurité de comprendre exactement ce qui est détecté dans leur environnement, comment exactement il est détecté et quels playbooks ou alertes seront déclenchés lorsqu'il est détecté. Deux exemples notables de startups dans cet espace sont SOC Prime et SnapAttack, qui prennent tous deux en charge le langage standard de facto pour l'écriture de contenu de détection - Sigma. Au lieu de promettre une couverture complète, ces fournisseurs offrent aux entreprises la possibilité d'accéder à une couverture de sécurité de manière totalement transparente et en fonction de l'utilisation.

Non seulement les organisations peuvent acheter une couverture de détection générique auprès de fournisseurs spécialisés dans l'ingénierie de détection, mais elles peuvent désormais demander à leurs fournisseurs de services de sécurité de créer la logique d'alertes adaptée à leur environnement. Bien que ce ne soit pas quelque chose d'offert par tous les fournisseurs aujourd'hui, c'est là que je pense que l'industrie se dirige, car les consultants en sécurité et les entreprises de détection et de réponse gérées cherchent à ajouter plus de valeur au-delà de la sélection des fournisseurs et de la surveillance des alertes. Bientôt, l'ingénierie de détection en tant que service deviendra la norme pour les fournisseurs de services de sécurité.

Notamment, l'évolution des attentes des clients modifie également la façon dont les fournisseurs de sécurité tels que la détection et la réponse aux terminaux (EDR) et la détection et la réponse étendues (XDR) fonctionnent. Ayant souvent commencé comme des «boîtes noires» qui exécutent une logique de détection générique intégrée à tous leurs clients, ils offrent désormais également la possibilité aux clients d'écrire leurs propres détections par-dessus. De nouveaux fournisseurs tels que LimaCharlie, où je dirige le produit, Panther et une toute nouvelle catégorie de soi-disant Open XDR offrent également une visibilité complète sur la couverture de sécurité de l'organisation (pas seulement les règles personnalisées, mais toutes les détections qui s'exécutent dans l'organisation).

L'importance croissante de l'ingénierie de la sécurité

J'utilise l'ingénierie de détection comme exemple; nous assistons à une forte poussée vers l'ingénierie dans tous les domaines de la sécurité. Avec l'infrastructure en tant que code, la gestion de l'infrastructure appartient désormais à l'ingénierie, et non à l'informatique. Par conséquent, les compétences en génie logiciel deviennent une condition préalable à la sécurité.

Avec l'essor du cloud, les principes et pratiques d'ingénierie logicielle sous-tendent désormais la manière dont l'infrastructure est provisionnée, la manière dont les politiques et les configurations de sécurité sont appliquées, la manière dont la posture de sécurité de l'entreprise est testée et interrogée, la manière dont les modifications apportées aux configurations de sécurité sont mises en œuvre et suivies, etc. . Alors que les ingénieurs DevOps sont en charge de l'approvisionnement et de la gestion de l'infrastructure, les ingénieurs en sécurité qui combinent une solide connaissance de l'ingénierie avec une compréhension approfondie de la sécurité, sont parfaitement adaptés pour la sécuriser.

La plupart des professionnels de la cybersécurité ont aujourd'hui développé leurs compétences en informatique - conception d'architectures réseau, provisionnement de pare-feu et gestion des politiques de pare-feu, et autres tâches essentielles au maintien de l'informatique dans l'entreprise. Malheureusement, de nombreuses personnes en charge de la sécurité n'ont qu'une compréhension de base du génie logiciel, ce qui les empêche de développer les compétences dont elles ont besoin dans un monde où tout - infrastructure, politiques, détections, etc. - existe sous forme de code. Il est naturel que lorsque l'infrastructure sous-jacente est codée, les professionnels de la sécurité doivent apprendre à coder. Il en va de même pour l'automatisation et l'utilisation de l'API : puisque la grande majorité des tâches techniques sont désormais accomplies à grande échelle via l'API (y compris le travail qui était auparavant effectué manuellement au sein des équipes de sécurité elles-mêmes), nous avons besoin de personnes qui comprennent comment concevoir, utiliser et désactiver les API de manière sécurisée.

Les équipes d'ingénierie de sécurité doivent aller au-delà des contrôles opérationnels en créant des solutions d'ingénierie aux problèmes de sécurité. Alors que de plus en plus d'organisations réalisent que les outils de sécurité prêts à l'emploi ne répondent pas au caractère unique de leurs besoins et de leurs environnements, celles qui disposent des niveaux de ressources et d'assistance appropriés pour prendre au sérieux le renforcement de leur posture de sécurité commencent à aller au-delà de la configuration commerciale des produits. Bien que, dans certains cas d'utilisation, un outil acheté auprès d'un fournisseur de sécurité puisse être mis en œuvre tel quel, le plus souvent, il nécessite quelques ajustements pour répondre aux besoins uniques d'une organisation. Cependant, nous constatons une compréhension croissante, en particulier parmi les grandes entreprises manipulant de nombreuses données et les entreprises natives du cloud, que les outils commerciaux ne sont pas en mesure de répondre à la multitude de besoins et d'exigences en matière de sécurité. Ces entreprises commencent à construire certains éléments de leur pile de sécurité en interne, déléguant la conception et le développement de ces solutions à des architectes de sécurité internes et à des ingénieurs de sécurité.

Tom Tovar d'Appdome a suggéré dans son récent podcast que nous pouvons classer les organisations de sécurité en trois catégories :

1. Des équipes de sécurité traditionnelles, composées de professionnels de la sécurité techniquement solides avec une connaissance approfondie de la sécurité et de la conformité, et des meilleures pratiques pour les deux.
2. Des équipes de sécurité avancées qui ont souvent des chercheurs en sécurité et des architectes de sécurité chargés de concevoir des systèmes, d'évaluer des produits, de tester des pénétrations, etc.
3. Organisations de cybersécurité et d'ingénierie qui disposent d'un talent d'ingénieur "hardcore" capable de créer et de fournir des solutions de sécurité pour les organisations modernes

Je vois ces catégories non pas comme différents stades de maturité, mais comme une évolution en termes de besoins organisationnels. Les entreprises natives du cloud commencent à constituer des équipes d'ingénierie de sécurité conçues pour travailler en étroite collaboration avec DevOps, l'ingénierie logicielle et le développement de produits. Ainsi, de nombreux éléments qui appartenaient traditionnellement aux équipes informatiques et de sécurité appartiennent désormais aux équipes DevOps et d'ingénierie de la sécurité. Ce modèle qui repose sur des constructeurs - des ingénieurs talentueux capables de concevoir des solutions de sécurité - n'est pas nécessaire pour toutes les organisations. Cependant, à mesure que de plus en plus d'entreprises se lancent dans le cloud dès le premier jour, à mesure que leurs environnements deviennent de plus en plus uniques avec la prolifération des outils SaaS, et à mesure que de plus en plus d'équipes de sécurité réalisent la valeur d'une sécurité adaptée à leurs besoins, nous assisterons à un énorme basculer vers l'ingénierie de la sécurité.

Au moment de la rédaction de cet article, nous constatons que les meilleures pratiques en matière de conception organisationnelle n'ont pas rattrapé l'essor de l'ingénierie de la sécurité. Concrètement, cela signifie que même si les équipes d'ingénierie de sécurité ont leurs propres outils dont elles sont responsables, il semble y avoir de nombreux conflits de propriété entre les ingénieurs de sécurité et les ingénieurs logiciels/DevOps ainsi que les équipes de sécurité opérationnelle. Il est juste de dire qu'à partir d'aujourd'hui, dans chaque organisation qui a la chance d'avoir une équipe d'ingénierie de sécurité, la forme de cette équipe est légèrement différente. Les conflits organisationnels et les zones de propriété peu claires sont des étapes naturelles dans la formation de toute nouvelle discipline, donc ce que nous voyons est organique et attendu.

La nature changeante du rôle d'analyste de sécurité

À mesure que la cybersécurité devient as-code, elle deviendra de plus en plus difficile pour ceux qui ne codent pas. Je parle de l'évolution du rôle des analystes de sécurité.

Les analystes de sécurité, traditionnellement classés en niveau 1 (spécialiste du triage), niveau 2 (répondeur aux incidents) et niveau 3 (analyste expert), jouent un rôle important dans une équipe de centre d'opérations de sécurité (SOC). Avec les progrès récents de l'automatisation, la forme de ce rôle a commencé à changer.

Tout d'abord, alors que les équipes de sécurité recherchent des moyens d'améliorer l'efficacité et la productivité, de plus en plus de processus et de procédures dans un SOC qui étaient auparavant manuels sont automatisés. Deuxièmement, la montée en puissance de l'intelligence artificielle (IA) promet d'éliminer le besoin de trier manuellement des milliers d'alertes - sans doute l'un des plus gros problèmes auxquels les équipes de sécurité sont confrontées. À ce jour, l'IA n'a pas encore tenu sa promesse d'automatiser la sécurité, mais cela finira par se produire. Probablement plus tôt que nous aimerions l'imaginer, nous assisterons certainement à une bataille d'IA avec des adversaires entraînant leurs propres modèles et leur propre défense - la leur. Images futuristes mises à part, les analystes du SOC devront s'adapter à l'évolution de la sécurité.

En raison des deux facteurs décrits ci-dessus, les analystes SOC (en particulier ceux traditionnellement appelés "Tier 1") doivent commencer à acquérir de nouvelles compétences. La compétence technique la plus urgente est le codage, et les analystes le comprennent, comme l'illustre l' enquête Voice of the SOC Analyst commandée par Tines en 2022.

Il y a suffisamment d'alarmistes dans l'industrie qui suggèrent que l'avenir des analystes est sombre, mais je le vois différemment. Le rôle ne va pas disparaître, mais sa forme et sa portée vont changer. Dans le passé, être analyste consistait en grande partie à savoir comment utiliser des produits de sécurité spécifiques. Aujourd'hui, la sécurité commence à être considérée non pas comme un problème d'outil mais plutôt comme un problème d'approche. De plus, les outils de sécurité sont de plus en plus banalisés et standardisés de sorte qu'ils fonctionnent tous de la même manière : si un analyste a utilisé un EDR, il est probable qu'il n'aura pas besoin de beaucoup de temps pour en apprendre un autre. Les produits exacts qu'un analyste utilisait dans le passé deviendront moins importants que sa compréhension des fondamentaux de la sécurité. Les analystes qui cherchent à rester pertinents à mesure que l'industrie mûrit devront devenir plus techniques. Bien que tout le monde ne devienne pas et ne doive pas devenir ingénieur, il sera de plus en plus essentiel qu'ils comprennent comment les acteurs de la menace voient le monde et comment les attaques sont menées.

Je pense que l'avenir des analystes en sécurité sera similaire à l'avenir des professionnels de l'AQ (assurance qualité) dans le développement de logiciels. La grande majorité des tâches d'assurance qualité ne sont plus manuelles et nécessitent l'utilisation d'outils, de langages et de cadres d'automatisation. Ceux qui paient le plus sont ce qu'Amazon et de nombreuses autres entreprises appellent désormais les "ingénieurs en test" - des ingénieurs logiciels qui se concentrent sur le test des fonctionnalités et des API des produits. L'assurance qualité manuelle existe toujours, mais elle est difficile à trouver, les rôles sont incroyablement compétitifs et, comme l'offre de travailleurs qualifiés dépasse largement la demande, ils obtiennent la rémunération la plus basse. Mechanical Turk d'Amazon change radicalement la donne, réduisant encore le coût de l'assurance qualité. L'assurance qualité n'est pas morte, mais elle s'est grandement transformée (et notamment il n'a pas fallu d'IA et de ML avancées pour la changer).

Pile de sécurité du futur

Au fur et à mesure que les équipes de sécurité deviennent plus techniques, elles commencent à reconnaître qu'aucun fournisseur ne peut promettre la « sûreté » et la « sécurité » en tant que fonctionnalité. Traditionnellement, la plupart des outils de sécurité commerciaux faisaient abstraction des couches fondamentales des équipes de sécurité et offraient une vue de haut niveau sous la forme d'alertes et de rapports résumant ce qui s'était passé. Les organisations qui souhaitaient une visibilité sur les couches fondamentales de l'infrastructure de sécurité et les données au niveau des événements ont été obligées d'utiliser des outils open source ou de créer des outils à partir de zéro.

Comme l'approche DevSecOps nécessite une visibilité sur les couches fondamentales de la sécurité, la pile de sécurité du futur sera très différente de ce que nous voyons aujourd'hui lorsque nous examinons les soi-disant cartes du marché de la cybersécurité. Tout d'abord, on verra de plus en plus de solutions neutres qui pourront être utilisées par les praticiens pour interroger leurs systèmes, avoir une visibilité complète sur leur environnement et construire une couverture de sécurité adaptée à leurs besoins. Ces outils fonctionneront de manière transparente et leur travail sera facilement testé et vérifié. Surtout, nous verrons un mélange de solutions commerciales et open source qui peuvent être faites pour fonctionner ensemble pour répondre aux cas d'utilisation de la sécurité de l'organisation. Au centre de la sécurité se trouveront les processus et les professionnels de la sécurité - et non les "produits" car les outils ne sont que cela - des outils ; c'est la façon dont ils sont utilisés et à quoi ils servent qui importent.

Au cours des dernières années, nous avons commencé à voir de plus en plus de responsables de la sécurité rejeter l'idée de faire aveuglément confiance aux fournisseurs : c'est l'approche que nous préconisons chez LimaCharlie, où je dirige le produit, ainsi que celle adoptée par d'autres solutions de nouvelle génération telles que SOC Prime, Panther, Prelude et, plus récemment , Interpres, pour n'en nommer que quelques-uns.

L'image ci-dessous est une liste des entreprises et des outils open source d'aujourd'hui qui adoptent une approche d'ingénierie fondée sur des preuves en matière de sécurité. Il n'est pas censé être exhaustif (il existe de nombreux autres excellents outils qui répondent aux critères ci-dessus) et il ne s'agit pas d'une «carte du marché» traditionnelle.

Combler le fossé des talents

Pour embaucher de grands talents, les entreprises doivent changer leur façon de travailler

Les équipes de sécurité qui défendent les entreprises contre les acteurs malveillants sont stressées, en sous-effectif, sous-évaluées et sous-payées. La réalité est que les groupes de piratage sont plus aptes à attirer des talents profondément techniques que n'importe quelle entreprise. Ils les paient hors taxes, et bien plus que n'importe quelle entreprise. Ils offrent un excellent équilibre travail-vie personnelle, le frisson du piratage et un sentiment d'accomplissement. La plupart d'entre eux sont 100% anonymes. Pas besoin d'accumuler des certifications sans valeur et de payer quelques centaines de dollars toutes les quelques années pour les maintenir "à jour", et pas besoin de traiter avec les recruteurs, les ressources humaines, la formation de base à la conformité, la politique du lieu de travail, le juridique, la conformité, la paie et les patrons exigeants pour couronner le tout. Si cela donne l'impression que je fais de la publicité pour travailler pour l'adversaire - ce n'est pas du tout mon intention, et la vérité est que rien de tout cela n'est nouveau pour les professionnels de la sécurité expérimentés. Je ne fais que démontrer que pour embaucher de grands talents, les entreprises doivent faire mieux.

Cette affectation, associée au fait que bon nombre des meilleurs professionnels de la sécurité ne se sentent pas motivés pour faire face à la bureaucratie du travail pour les grandes entreprises, brosse un tableau sombre du marché du travail actuel.

Il serait contraire à l'éthique et faux de suggérer que j'ai une liste de solutions rapides et faciles, donc nous, en tant qu'industrie, devons les trouver ensemble. Nous pouvons commencer par abandonner l'exigence de « 5 ans d'expérience » pour les emplois de premier échelon, et nous en servir au fur et à mesure, en supprimant les préjugés et en améliorant notre processus d'embauche.

Amener les ingénieurs logiciels à faire de la sécurité

Comme tout dans la sécurité devient as-code, l'un des pipelines rarement discutés pour les talents en cybersécurité pourrait être le génie logiciel. Certains affirment qu'il peut être plus facile d'enseigner la sécurité aux ingénieurs qu'aux professionnels de la sécurité technique en génie logiciel. Bien que je ne sois pas la bonne personne pour porter un jugement sur l'exactitude de cette affirmation, j'ai vu suffisamment d'ingénieurs en logiciel se transformer en praticiens de la sécurité pour savoir que ce chemin est réel.

Le défi consiste à faire savoir que la cybersécurité est un cheminement de carrière viable pour les diplômés en génie logiciel, à leur fournir la formation adéquate (en ajoutant des cours de cybersécurité de niveau approfondi aux programmes d'informatique) et à concevoir des cheminements de carrière significatifs pour qu'ils trouvent leur chemin dans la cyber-sécurité. Cela soulève une question de rémunération pour de nombreux emplois de cybersécurité d'entrée de gamme que les nouveaux diplômés peuvent occuper : si une personne peut obtenir son premier emploi dans un logiciel qui paie 20 à 40 % de plus que tout ce qui lui est proposé dans le domaine de la sécurité (s'il peut même obtenir un entretien ), toute l'idée de faire en sorte que les ingénieurs logiciels s'occupent de la sécurité tombe à l'eau.

Former la nouvelle génération d'ingénieurs en sécurité

On parle beaucoup de la pénurie de talents en cybersécurité, et il est facile de remarquer une mer de nouveaux entrants promettant de résoudre ce problème. Des bootcamps de cybersécurité de 6 semaines aux cours en ligne, en passant par les nouveaux diplômes collégiaux et universitaires, tout le monde veut une part du gâteau dans "l'éducation de l'avenir de la sécurité". Il est tentant de penser que tout ce dont nous avons besoin est de préparer davantage d'élèves du secondaire et d'adultes à changer de carrière enthousiasmés par la sécurité et à s'inscrire à ces programmes, et 3 à 5 ans plus tard, nous sommes tous prêts, je vois que le problème va beaucoup plus loin.

Si vous regardez la grande majorité des programmes éducatifs, vous remarquez que leurs programmes ont tendance à omettre la composante ingénierie. Je n'ai pas passé assez de temps à compiler les données donc mes observations sur ce sujet sont plutôt anecdotiques, mais voici ce que je vois :

• La plupart des bootcamps sont si courts et de si haut niveau qu'il serait déraisonnable de croire qu'ils peuvent fournir à leurs diplômés une connaissance approfondie de l'industrie. J'ai rencontré de nombreux grands professionnels de la sécurité qui sont passés par des bootcamps. Cependant, ils sont devenus formidables non pas parce qu'ils ont pu participer à un bootcamp, mais à cause de ce qu'ils ont fait en dehors d'eux. Je ne dis pas que ces courts cours immersifs n'offrent aucune valeur. Pour illustrer le point que j'essaie de faire valoir, je vous encourage à réfléchir à la raison pour laquelle il y a tant de bootcamps de 4 à 8 semaines enseignant le développement front-end et si peu de formations de 4 à 8 semaines enseignant le développement back-end. La réponse est simplement parce que le développement back-end, similaire à la sécurité, nécessite une solide compréhension des théories et des concepts profondément techniques, et la capacité de traiter ces concepts et de les implémenter dans le code sans souvent aucun retour visuel. Je dirai publiquement que vous ne pouvez pas enseigner cela pendant le même laps de temps qu'il faut pour enseigner aux gens comment créer un site Web simple.
• De nombreux programmes universitaires, surtout au niveau de la maîtrise, se concentrent davantage sur la rédaction de politiques que sur le développement de compétences pratiques. Même ceux qui sont plus profonds et pratiques ont tendance à être ce que l'enseignement universitaire est dans son ensemble - trop vieux, trop théorique et trop superficiel. La sécurité évolue quotidiennement, avec de nouveaux exploits, de nouvelles vulnérabilités, de nouveaux vecteurs d'attaque et de nouvelles technologies créées tous les jours également. Les programmes universitaires doivent passer par de longues approbations, des examens académiques rigoureux et des évaluations, à tel point qu'au moment où un programme est approuvé, il parle de l'actualité il y a six mois ou plus. Il y a d'excellents enseignants et instructeurs qui travaillent dur pour rester au courant de l'industrie et enseigner à leurs étudiants des compétences utiles, pratiques et actuelles. Nous devrions tous être profondément reconnaissants pour leur travail, mais il convient de dire que ces personnes ne travaillent pas en accord avec le système éducatif lui-même, mais contournent plutôt ses limites pour faire du bien aux étudiants et à la société.
• Les certifications en cybersécurité ne reflètent pas les compétences et les expériences dont le marché a besoin. Je n'ai pas l'intention de diminuer la quantité d'efforts que les gens y consacrent et je ne prétends pas qu'ils n'offrent aucune valeur. Ce que je veux dire à la place, c'est qu'à très, très peu d'exceptions, ces certifications offrent des concepts théoriques et donnent aux gens l'impression de savoir comment la sécurité doit être faite, sans donner de réelles compétences pour le faire réellement. Alors que les attaquants pénètrent profondément dans le code et recherchent des moyens de contourner les contrôles, d'exploiter les vulnérabilités et d'exfiltrer les données, nous semblons sérieusement penser que nous pouvons les arrêter en enseignant aux gens comment rédiger des politiques et en passant des examens à choix multiples sur la sécurité du cloud. . Imaginez être opéré par un chirurgien cardiaque avec un «certificat en cœur» qui n'a pas fait une seule intervention chirurgicale dans sa vie (je ne peux pas).

Tout cela est loin de dire que les meilleurs professionnels de la sécurité d'aujourd'hui ne sont pas issus des universités, et qu'il n'apparaît pas non plus qu'ils viendront demain. Les personnes qui deviennent des professionnels de pointe en ingénierie de la sécurité viennent d'emplois pratiques dans les tests d'intrusion, l'armée, la NSA et d'autres institutions gouvernementales avec de fortes composantes offensives. Ils viennent d'équipes de sécurité matures d'entreprises natives du cloud qui prennent la sécurité au sérieux. Ils sont autodidactes devant leurs ordinateurs, lors de compétitions CTF (capture the flag) et lors d'événements comme Open SOC, Black Hat, DefCon, etc.

Pour façonner l'avenir de la sécurité et combler le manque de talents, nous ne pouvons pas rester assis et espérer qu'un nombre suffisant d'individus motivés trouveront le moyen d'acquérir les compétences dont ils ont besoin pour sécuriser nos employés, nos entreprises et nos pays. L'espoir n'est pas une stratégie, pas plus que les bootcamps de 6 semaines ; nous devons construire des systèmes et des institutions pour combler le fossé technique en matière de cybersécurité. La sécurité est difficile. Enseigner la sécurité est également difficile, mais cela doit être fait. La conformité et la rédaction de politiques sont importantes, mais elles ne nous aideront pas à elles seules à défendre nos réseaux contre les attaquants - incroyablement talentueux, hautement qualifiés, très motivés et bien payés.

Alors que nous devons trouver des moyens d'impliquer les ingénieurs logiciels dans la cybersécurité, nous avons également besoin de professionnels de la sécurité profondément spécialisés pour acquérir des compétences en ingénierie. Bien que tous les praticiens de la réponse aux incidents, de la criminalistique numérique et de la sécurité des points finaux ne deviennent pas des ingénieurs, la plupart des gens gagneraient à connaître les bases du développement logiciel et à maîtriser des langages tels que Python. L'adoption d'une approche d'ingénierie des opérations de sécurité nous permettra d'automatiser les parties manuelles de la réponse aux incidents et de développer en permanence des moyens évolutifs de sécuriser le périmètre de l'organisation tout en consacrant plus de temps à la construction proactive de défenses. Pour cela, l'enseignement de la cybersécurité doit commencer à inclure des cours de génie logiciel au même titre que les diplômes de génie logiciel et d'informatique devraient enseigner les bases de la sécurité.

Réflexions finales

Il n'y a en effet pas de solution miracle qui résoudra tous nos problèmes de sécurité, et produire plus d'ingénieurs en sécurité ne le fera pas non plus. Cependant, l'adoption d'une approche d'ingénierie de la sécurité peut nous aider à intégrer la sécurité dans les produits logiciels dès leur création, à accélérer la maturation de l'industrie et à pérenniser nos opérations de sécurité.

La pénurie de talents va très certainement être un obstacle. Cependant, simplement parce que nous n'avons pas les ressources dont nous avons besoin, nous ne pouvons pas et ne devons pas rejeter une solution viable à ce problème difficile. Il est également clair que nous devons changer nos pratiques d'embauche et réévaluer les critères utilisés pour identifier les futurs leaders de la sécurité. Nous obtenons ce pour quoi nous optimisons. Chaque jour, les attaquants passent d'innombrables heures à apprendre de nouvelles technologies, à désosser les logiciels que nous créons et à rechercher des vulnérabilités dans le code. Si nous regardons les offres d'emploi en sécurité, il est facile de conclure que nous espérons arrêter l'adversaire en passant des tests à choix multiples et en obtenant des certifications qui sont des compétences très différentes de celles nécessaires pour comprendre comment fonctionne le code et comment le défendre.

Je suis convaincu que l'approche technique de la cybersécurité est incontournable. Nous commençons déjà à voir les signes de sa croissance, et elle ne fera que s'accélérer à partir d'ici. La question est - à quelle vitesse serons-nous capables de construire l'infrastructure nécessaire à son développement ? Si l'histoire nous a appris quelque chose, c'est que l'état de la pratique de la cybersécurité dans son ensemble accuse des années de retard par rapport aux dernières et plus grandes conférences données à DefCon, Black Hat, etc. Nous devrons voir quels seront les prochains événements qui modifieront l'industrie.

L'image principale de cet article a été générée parle générateur d'images AI de HackerNoon via l'invite "cybersecurity".