Entretien avec le développeur : Adam Swan

Nous poursuivons notre série d’interviews avec les participants du Programme Développeur (https://my.socprime.com/en/tdm-developers), chasseurs de menaces et passionnés de cybersécurité pour vous présenter ces personnes formidables qui parcourent le web à la recherche de menaces pertinentes et créent un contenu unique pour leur détection. Rencontrez Adam Swan, ingénieur en chasse aux menaces senior chez SOC Prime.

Adam, parlez-nous un peu de vous et de votre expérience en chasse aux menaces.

Enfant, lorsque les salons de discussion AOL étaient à la mode, je me souviens avoir été fasciné par un tour de passe-passe qui m’a permis de piéger les autres en modifiant leur message d’absence via un lien élaboré. Ces aperçus du ‘piratage’ ont allumé une étincelle qui m’a envoyé sur cette voie professionnelle un peu par hasard. J’ai fini par suivre tous les cours de programmation disponibles au lycée (pour être honnête, les seuls cours qui m’intéressaient), et j’ai ensuite découvert que je pouvais faire de la cybersécurité un parcours professionnel en explorant les programmes universitaires. J’ai finalement intégré un programme d’assurance de l’information au Pennsylvania College of Technology. Le programme était un mélange de technique et de politique et a certainement ouvert une porte qui a finalement conduit à la chasse aux menaces.

Après l’université, j’ai immédiatement commencé à collectionner les certifications pour me conformer à la norme 8570 du Département de la Défense des États-Unis, espérant qu’elles ouvriraient davantage d’opportunités techniques là où je travaillais. Cependant, même après avoir réussi plusieurs certifications, y compris le CISSP pour ‘cocher toutes les cases’, je sentais que je ne *savais* vraiment rien. C’est là qu’un poste d’analyse de malware s’est ouvert, et le responsable m’a dit que je devais obtenir la certification GREM pour être éligible. Sans aucune connaissance préalable de l’analyse des malwares, j’ai relevé le défi de la certification après quelques semaines d’étude intensive. J’ai vraiment apprécié la matière et j’ai finalement senti qu’un chemin s’ouvrait vers un travail hautement technique. J’ai été accepté dans un poste junior et j’ai passé quelques années à perfectionner mes compétences en analyse de logiciel malveillant, réponse aux incidents et criminalistique sur machines éteintes.

Cependant, ce n’est que lorsque Nate (@neu5ron) m’a demandé de rejoindre son équipe que je me suis vraiment lancé dans la chasse aux menaces. Il m’a présenté Elastic, et nous avons été captivés par la puissance de la centralisation et de la recherche dans les journaux d’événements de Windows. Cela a culminé avec une sorte de tournée de conférences où nous faisions l’évangélisation de la puissance des journaux de Windows. C’est à cette période que je suis devenu un chasseur et je ne suis jamais vraiment revenu en arrière. Je pratique depuis environ deux ans et demi maintenant. Donc, comparé à peut-être certains des autres analystes que SOC Prime a interviewés, je suis encore nouveau.

À votre avis, quelles sont les tendances les plus importantes en matière de chasse aux menaces dans l’industrie actuellement ?

Il y a trois tendances que j’aimerais aborder.

Premièrement, de plus en plus d’organisations lancent des programmes de chasse aux menaces ou intègrent des concepts fondamentaux de la chasse aux menaces dans leur fonction SOC existante. C’est énorme car les fondamentaux de la chasse aux menaces sont, selon moi, très efficaces pour améliorer les programmes de sécurité.

Deuxièmement, une autre tendance dans la chasse aux menaces est la dépendance à l’égard de la détection et réponse sur le point d’entrée (EDR). Je préfère ceux qui offrent l’accès à des données passives riches concernant les événements importants sur les systèmes et qui permettent à des analystes d’écrire une logique de détection ou de mener une analyse manuelle. La direction doit se méfier de tout fournisseur qui prétend simplifier ou automatiser entièrement la détection des menaces. Les adversaires sont conscients de ces outils et peuvent les contourner.

Enfin, la communauté de la chasse aux menaces n’existerait pas ou ne serait pas où elle est sans le partage. Des projets comme SIGMA qui permettent de partager concernant la chasse aux menaces, ont établi une base solide pour de futurs succès.

Adam, qu’en est-il de Sigma, quelle a été votre première expérience avec Sigma, quand avez-vous commencé à l’utiliser ?

SIGMA est dans ma conscience depuis son annonce, mais ma première utilisation en production a eu lieu début 2018 quand un client avait collecté des journaux Windows remontant à plusieurs mois mais n’avait pas beaucoup de détections / alertes autres que celles fournies par le fournisseur. Avec l’aide de l’ingénieur SIEM, j’ai déployé les règles SIGMA publiques pertinentes.

Et selon vous, quels sont les principaux avantages de Sigma en tant qu’outil de chasse aux menaces ? Sigma peut-il changer la manière dont les organisations construisent leur cyberdéfense ?

Premièrement, SIGMA permet le partage de la logique de détection entre des organisations aux architectures dissemblables mais ayant des sources de données et des menaces familières. Ainsi, si j’ai Splunk et que vous avez Elastic et que nous collectons tous deux les journaux Windows, nous pouvons utiliser SIGMA comme un langage commun pour partager la logique de détection contre nos menaces communes comme les ransomwares.

Deuxièmement, SIGMA nous permet d’écrire la logique de détection et de l’entourer de métadonnées attrayantes qui peuvent ne pas être (facilement) intégrées dans l’alerte de votre SIEM. Par exemple, si vous suivez votre couverture MITRE ATT&CK dans certains SIEMs, il n’est pas évident ou facile de relier ces règles à leur technique associée. Avec le fichier YAML SIGMA, vous êtes en mesure d’étiqueter les règles comme vous le souhaitez.

Troisièmement, si vous gardez votre logique de détection écrite en SIGMA, vous vous préparez pour réussir l’adoption inévitable d’un nouveau SIEM. Si votre SOC est soudainement responsable de l’adoption d’un nouveau SIEM (disons lors d’une acquisition) ou que votre direction décide de passer à un nouveau SIEM avec SIGMA, vous facilitez la transition agile ou l’adoption de la nouvelle technologie. Ceci est d’autant plus important si vous offrez le SOC/la chasse aux menaces comme un service (MSSP).

Quel est, selon vous, la partie la plus compliquée et chronophage de l’écriture de nouvelles règles Sigma et combien de temps en moyenne vous prenez pour écrire une nouvelle règle Sigma ? Est-il convenable pour vous d’utiliser Sigma comme outil pour écrire de nouvelles règles ? Et comment prenez-vous la décision de quelle règle créer ?

Les règles immédiatement exploitables sont basées sur des observations directes. Cependant, les règles basées sur une hypothèse éclairée concernant le comportement des adversaires ou sur la manière dont le comportement des adversaires affecte un système donné sont tout aussi valables. La partie la plus chronophage de l’écriture d’une règle SIGMA est la recherche et la vérification que la logique que vous écrivez va détecter la technique/outils/menace visée. Écrire une règle en SIGMA ne devrait pas prendre beaucoup plus de temps qu’écrire une requête contre n’importe quel SIEM. Cela est dû au fait que SIGMA ne vous gêne pas, il n’est pas exigeant, et la syntaxe devient rapidement familière.

Pour garantir la qualité, je recommande vivement à quiconque écrivant des alertes SIGMA de prendre à cœur la présentation de Daniel Bohannon sur les signatures résilientes (https://www.slideshare.net/DanielBohannon2/signaturesaredead-long-live-resilient-signatures).

Qu’en est-il de votre expérience avec l’interface utilisateur Sigma, Adam ? Avez-vous des idées sur la façon de la rendre plus utile/convenante pour les développeurs ?

L’interface utilisateur de SIGMA est excellente, j’utilise uncoder.io pour vérifier que ma règle sigma sera convertie car copier et coller une règle est très simple. Ce serait bien si l’interface utilisateur SIGMA faisait des suggestions/recommandations pour la compatibilité avec différentes bases de données. Par exemple, s’appuyer fortement sur les caractères génériques peut poser problème pour la compatibilité avec Elastic.

Adam, en tant que rédacteur de contenu, vous avez probablement un laboratoire. Comment testez-vous vos règles et quelles sources de journaux préférez-vous utiliser ?

Avoir un laboratoire pour simuler des attaques et confirmer/tester la résilience de vos signatures est très important. Je préfère travailler avec des journaux auxquels une organisation moyenne a accès. Aujourd’hui, écrire une règle pour la journalisation native des terminaux est le filet le plus large possible pour capturer.

Quels types de menaces informatiques pensez-vous poseront les plus grands risques pour les organisations dans l’année à venir ? Des suggestions sur la façon d’améliorer les capacités de détection contre ces menaces ?

Les menaces varient considérablement d’une organisation à l’autre. Je dirais que la plus grande menace pour l’organisation moyenne est l’adoption d’exploits/techniques wormables dans des ransomwares wormables (ou tout type de malware destructeur). Les jours de l’intrusion de Schrödinger sont derrière l’organisation moyenne, la plupart des organisations sauront qu’elles ont été piratées lorsque leurs données seront prises en otage. Heureusement, les méthodes de prévention et de détection de ces types d’attaques sont relativement matures. L’exécution de ces méthodes peut aller de relativement simple à extrêmement complexe en fonction de l’étendue et de la complexité des réseaux/systèmes que quelqu’un défend. Donc, ma recommandation est vraiment pour la direction. Chaque fois que possible, optez pour la simplicité.

Chez SOC Prime, nous avons lancé le Programme Prime Bounty qui encourage le partage de contenu entre les professionnels de la cybersécurité. Adam, aimez-vous l’idée de récompenser les développeurs pour le partage de règles Sigma et d’autres contenus de détection des menaces ?

Oui. Si vous faites des recherches en sécurité. Pensez à la façon dont vous pouvez partager la détection. Tout ce qu’il faut, c’est augmenter la verbosité des journaux dans votre laboratoire, puis revoir les journaux pour détecter d’éventuelles détections après avoir exécuté une preuve de concept. Si vous ne savez pas comment commencer, contactez-moi @acalarch et je vous promets que c’est incroyablement simple.

Adam, quelle serait votre recommandation pour les jeunes spécialistes en cybersécurité qui décident juste quel chemin choisir ?

Voici les choses que j’aurais aimé avoir faites :

1. Profitez de la formation que vous pouvez obtenir en assistant à des conférences. C’est moins cher et vous serez entouré de pairs et de mentors potentiels.
2. Soyez votre propre défenseur et soyez sceptique/réaliste. Clarifiez vos intentions de parcours professionnel à votre direction, soyez un élément moteur concernant vos intentions, recherchez des mentors et n’ayez pas peur de passer à autre chose.