La semaine dernière, nous étions à B-Boost, une convention d’affaires à La Rochelle autour des sujets du logiciel libre et de l’open source. Encore merci aux organisateurs de cette invitation !

Nous y tenions un stand et avons animé une conférence sur les tests d’intrusion dans le monde open source.  

En attendant un éventuel replay et parce qu’il n’y a pas que la vidéo dans la vie 😉 nous vous proposons ici le fil rouge de la présentation 👨🏻‍🏫 délivrée par Hadi.

Fidèles lecteurs que vous êtes devenus 😘, vous savez désormais ce qu’est un test d’intrusion ou pentest (voir notre artcile sur La définition du pentest). 

Par contre, vous ne savez peut-être pas où se niche le pentest dans un Système de Management de la Sécurité de l’Information ⚙️ (ou SMSI pour ceux qui ont potassé de l’ISO 27001 🤯 ).

Le test d’intrusion fait en effet partie de la panoplie d’approches d’audit qui permettent de réaliser le Check dans un cycle PDCA (Plan, Do, Check, Act), pour que justement on ne donne pas de “Check à blanc” (vous apprécierez le jeu de mots 🤹🏼‍♂️) à ceux qui ont déployé les systèmes d’information objet de ce SMSI. Le Check est donc là pour vérifier si les mesures de sécurité mises en place permettent de réduire la probabilité des scénarios de risque, ou Hacker Stories© dans notre jargon Knock Knockien (voir notre plaquette sur les HackerStories). 

Pour mieux visualiser, imaginez les tests d’intrusion comme des surligneurs 🖍 qui tracent sur le système d’information les chemins que pourrait arpenter la menace, à savoir les chemins 👣 qui permettraient la réalisation des Hacker Stories© imaginées.

Le test d’intrusion se met ainsi au service d’une bonne gestion des risques cyber, à condition bien sûr qu’il soit bien défini et cadré (voir notre article sur Comment exprimer son besoin en pentesting).

En complément de cette nécessaire expression de besoins, il faut que la panoplie d’outils utilisés par le pentester, dont une bonne partie provient de la sphère open source, soit correctement développée, documentée, maintenue, et surtout être exempte de vulnérabilités. Imaginez cette situation ubuesque où le pentester, ayant réussi à compromettre une première machine, y installe sa boîte à outils pour poursuivre son exploration intrusive mais ne peut pas être garant que l’un des outils n’est pas lui-même truffé de failles ou de portes dérobées 🤷🏻‍♂️ … 

Au lieu de contribuer à la sécurité de l’organisation cliente, il se retrouverait accélérateur d’insécurité pour ses clients, INADMISSIBLE 😡 !

Chez Knock Knock, nous nous employons donc à recenser, qualifier, tester et auditer tout outil open source qui se retrouverait indexé et utilisé dans notre HackerToolbox 🛠, vaste mais oh combien nécessaire chantier 🏗.  Elle sera bien entendu elle-même publiée en Open Source !

Nous proposons également des ateliers Hacker Stories© comme approche méthodologique permettant aux clients de structurer leur gestion des risques cyber, et ainsi de définir et prioriser leurs chantiers de pentest.

Elle est donc là, notre modeste contribution au monde open source qui nous donne tant !

Et vous RSSI, comment faites-vous pour sélectionner les périmètres à pentester ?

Et vous autres pentesters, comment faites-vous pour vous assurer que vos boîtes à outils sont safe ?

Dites le nous 🎙