Recherche d'outils d'analyse de vulnérabilités — que tester soi-même dans une équipe de 8 sans rien casser ?

Il faut absolument distinguer scan actif et passif. Si vous branchez des fuzzers agressifs ou des modules envoyant des requêtes massives sur vos formulaires web et pages de login, vous allez verrouiller la base de données. Pour les scans de ports au niveau réseau, limitez le débit de requêtes par seconde. Et côté web, ne lancez jamais le scan sur un environnement connecté à la base de prod : utilisez impérativement une préprod clone.

Vous ne passerez jamais l'audit d'un client grand compte allemand avec un simple rapport de scan fait maison. Un auditeur n'acceptera jamais qu'on lui dise "on a scanné en interne et c'est clean" il lui faut une signature et une méthodologie indépendantes. De toute façon, la majeure partie du rapport de cent pages généré par l'outil n'est que du bruit, et il faut une réelle expertise pour faire le tri.

edit : j'ai écrit une erreur ci-dessus, désolé.

Pour mener le scan en toute sécurité suivez ces étapes : 1) Faites une sauvegarde de la base de données de prod, restaurez-la sur un environnement de test et ciblez uniquement cette adresse de test. 2) Bridezede l'outil de scan pour limiter le débit à 3 voire 5 requêtes par seconde maximum. 3) Avant de lancer le scan gardez ouvert un tableau de bord surveillant l'utilisation des ressources serveur en temps réel.

on a testé en prod l'année dernière via le formulaire de contact résultat : huit cents tickets de support vides ouverts en deux heures. le système de notifications a planté donc excluez absolument les formulaires du scan ou faites ça sur un serveur de test.

Lors de la mise en place de moteurs gratuits et open source, prenez impérativement ces trois précautions : 1) Choisissez uniquement le mode collecte d'informations et analyse passive, désactivez les tests d'exploitation ou de déni de service. 2) Mettez sur liste noire les liens des formulaires déclenchant l'envoi d'e-mails ou de SMS. 3) Lancez le scan en dehors des heures ouvrées, au milieu de la nuit.

Dans notre équipe de huit personnes, on fait un scan automatique des dépendances chaque semaine. À la mise en place, on a découvert 14 failles critiques dans les packages tiers qu'on utilisait. On a tout corrigé en 3 jours simplement en mettant à jour les versions, ce qui a considérablement réduit le risque sans même envoyer un seul paquet de test au serveur.

Quand on installe et qu'on lance ces outils sur le serveur, est-ce qu'ils laissent des fichiers résiduels ou un agent qui pourrait créer une faille de sécurité ou bien tout revient à l'état initial une fois le scan terminé ?

Ne touchez surtout pas à la machine de prod. Lancez un outil open source d'analyse statique de code sur votre machine locale pour votre codebase. Et pour l'OS du serveur, contentez-vous de lancer la commande du gestionnaire de paquets qui liste les mises à jour de sécurité. Vous aurez déjà réglé la moitié du problème avec zéro risque.

Vous avez raison.

Chez nous, ça s'est passé comme ça. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

La discussion part dans tous les sens, je recentre. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

C'est noté, merci.

Je vais résumer ce qui a été dit jusqu'ici. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Je vous conseille de ne pas vous presser. Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.

Désolé, mais ce n'est pas vrai dans tous les cas. Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.

Corrigez-moi si je me trompe.

Désolé, mais ce n'est pas vrai dans tous les cas. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Je suis d'accord.

Il y a un point que je ne comprends pas. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé. Bon courage.