Entretien avec le développeur : Thomas Patzke

Nous continuons à interviewer les développeurs de notre Programme de Prime de Menaces (https://my.socprime.com/en/tdm-developers) pour encourager les professionnels de la cybersécurité à développer plus de règles Sigma, partager leur contenu de détection de menaces et renforcer la communauté. L’interview précédente est ici https://socprime.com/blog/interview-with-developer-florian-roth/

Rencontrez Thomas Patzke

Thomas est l’un des experts les plus inspirants de la communauté de la cybersécurité avec plus de 13 ans d’expérience dans le domaine de la sécurité de l’information. Il travaille comme membre d’une équipe bleue et chasseur de menaces chez ThyssenKrupp CERT et est créateur de Sigma avec Florian Roth. Thomas Patzke n’est pas seulement un contributeur au projet Sigma mais aussi un développeur expérimenté écrivant le code pour Sigmac et partageant des outils liés à la cybersécurité avec la communauté (https://gist.github.com/thomaspatzke).

Parlez-nous un peu de vous et de votre expérience en Threat Hunting.

J’ai commencé à travailler dans la sécurité de l’information en 2006 comme consultant avec une large gamme de projets. Rapidement, je me suis tourné vers la sécurité offensive, notamment la sécurité des applications et occasionnellement, j’ai fait de l’analyse de journaux et de la criminalistique dans des projets de réponse aux incidents. Même si ces projets de RI étaient assez petits, les tâches étaient très intéressantes et mon intérêt pour les sujets défensifs a grandi avec le temps et a reçu un coup de pouce en 2015 lorsque j’ai commencé à travailler dans un CERT et j’ai continuellement été en contact avec des incidents intéressants et des acteurs de menaces. Creuser dans de grandes quantités de données pour trouver un attaquant m’a fasciné dès le début et finalement, j’ai complètement basculé de la sécurité offensive à la chasse aux menaces et à la réponse aux incidents.

Vous êtes l’un des inventeurs de Sigma, combien de temps a-t-il fallu pour transformer l’idée de Sigma en un concept achevé ? Thomas, pourquoi le nom « Sigma » a-t-il été choisi ? Vous attendiez-vous à ce que Sigma soit utilisé par des milliers de professionnels de la cybersécurité dans le monde entier ?

Construire Sigma a été un processus fluide et très agile. Lorsque Florian m’a contacté la première fois avec l’idée d’un format de signature pour les événements de journal, ses idées étaient déjà très concrètes. Nous avons affiné cette idée ensemble en envoyant des messages vocaux dans les deux sens et dès le lendemain, Florian a déjà écrit les premières règles Sigma (https://github.com/Neo23x0/sigma/commit/87deb349adb22331aae1b923420d382fea278d2c) qui ne diffèrent pas trop de la manière dont les règles Sigma sont écrites aujourd’hui. Le nom « Sigma » était l’idée de Florian et comme je connais Florian, il y a sûrement une histoire derrière, mais vous devez lui demander pour l’avoir 😉 J’ai aimé le nom et donc nous avons décidé de l’adopter.

Par la suite, nous avons encore affiné Sigma et découvert de nombreux défis dans le partage de signatures de journaux tels que des conventions de nommage de champs différentes et les avons résolus dans le langage de signature et les outils de conversion. Après deux à trois mois, nous avions quelque chose que nous considérions comme prêt à publier, mais même après la version initiale, de nouveaux concepts ont été ajoutés et continueront de l’être à l’avenir.

Je m’attendais à ce que Sigma soit utile pour certaines personnes parce qu’il a été construit sur la douleur que Florian et moi avons ressentie dans la gestion des incidents et nous savions que d’autres personnes dans ce domaine avaient la même douleur. Le retour positif de tant de personnes et l’adoption par les équipes de réponse aux incidents de diverses organisations étaient bien au-delà de mes attentes.

Thomas, quels sont les principaux avantages de Sigma en tant qu’outil de chasse aux menaces ?

Le principal avantage de Sigma réside dans la distribution d’un résultat de chasse aux menaces, les signatures de journal pour des événements spécifiques. S’il est possible de l’exprimer comme une règle Sigma, vous pouvez le distribuer facilement dans une organisation avec une infrastructure de détection hétérogène. Il est courant dans les grandes organisations d’avoir différents systèmes SIEM à cause d’une infrastructure informatique ayant évolué historiquement ou parce que différentes solutions sont utilisées pour différentes fins. Avec Sigma, vous devez écrire la règle une fois et vous pouvez la convertir en une requête Splunk et ArcSight pour les SIEM, une requête Elasticsearch pour le data lake, un one-liner Grep ou PowerShell pour trier un système suspect et pour la partager avec la communauté.

Quel est selon vous la partie la plus compliquée et la plus chronophage de l’écriture de nouvelles règles Sigma et combien de temps cela vous prend en moyenne pour écrire une nouvelle règle Sigma ?

Pour moi, cela ne prend que quelques minutes pour écrire une règle Sigma, ce qui n’est qu’une petite fraction du temps que je passe habituellement à faire des recherches menant à la signature de journal. Florian et moi avons fait un effort pour concevoir Sigma comme étant convivial et facile à écrire. Je pense que je suis trop partial pour identifier les parties compliquées de Sigma. C’est quelque chose pour lequel nous comptons sur les retours de nos utilisateurs qui ne devraient pas hésiter à nous contacter via le problème GitHub ou directement s’il y a quelque chose qui pourrait être amélioré.

Sigma devient de plus en plus populaire dans le monde entier, selon vous, comment la règle Sigma influence-t-elle l’industrie et comment voyez-vous l’avenir de Sigma, des réflexions spécifiques sur son développement futur ?

Je sais que des utilisateurs Sigma placent Sigma comme une exigence dans les appels d’offres pour des produits de sécurité parce qu’ils y croient et nous avons déjà eu des contacts avec divers fournisseurs de sécurité qui souhaitent intégrer le support Sigma dans leurs produits. Ce serait formidable de voir le support Sigma natif dans les produits de sécurité comme YARA et Snort qui sont déjà intégrés dans de nombreux produits. J’ai développé de grandes parties du convertisseur Sigma mais je suis totalement d’accord avec le fait que cela devienne obsolète par un support Sigma natif !

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

Oui ! En tant que chercheur en sécurité offensive, vous pouvez choisir pendant des années si vous voulez être payé pour vos recherches ou les publier ouvertement et augmenter votre réputation. Les primes de menace étendent cela à la recherche défensive et c’est une bonne étape pour remédier au déséquilibre des récompenses entre les deux domaines. Je suis un grand ami de la publication gratuite des résultats de recherche et je crois que les gens continueront de le faire à l’avenir. Les primes de menace pourraient même inciter davantage de personnes à consacrer du temps à la recherche en sécurité défensive et à améliorer la situation globale.

Que recommanderiez-vous aux spécialistes en cybersécurité qui apprennent juste à écrire des règles Sigma, avez-vous des conseils pour maîtriser l’écriture Sigma ?

Le contenu compte ! Je pense que l’écriture de règles Sigma est relativement facile et la courbe d’apprentissage est assez rapide. Un éditeur avec un support YAML est suffisant et il existe des outils en ligne comme l’interface SOC Prime Sigma qui soutiennent l’analyste dans l’écriture de règles Sigma. Donc mon conseil pour apprendre Sigma est très simple : allez-y, faites des recherches intéressantes ou prenez des recherches existantes (n’oubliez pas les crédits !) et faites-en une règle Sigma. Vous deviendrez automatiquement fluide avec Sigma après un certain temps.