Scanner de vulnérabilités en PME : quels outils choisir et comment lire les rapports sans être un pro de la tech ?

Si vous utilisez un CMS prêt à l'emploi côté web, scindez l'analyse en deux : scan des ports externes et scan applicatif. Si le rapport indique que les ports de base de données ou d'administration sont ouverts sur l'extérieur, restreignez simplement ces ports à l'IP de votre bureau via le pare-feu du serveur, le souci sera réglé direct.

On a eu le même type d'audit pour notre entrepôt à Bologne. Pour éviter de payer 2.500 EUR à un prestataire, on a pris un scanner cloud à 80 EUR par mois. Premier rapport : 42 failles détectées. Une connaissance calée en sécu a jeté un œil : 39 étaient bénignes, genre la version du serveur qui n'était pas masquée. Corriger les 3 vraies failles nous a pris 2 heures.

Attention les rapports des scanners automatiques ne passent pas toujours auprès des grands comptes. Le client demande-t-il un vrai test d'intrusion certifié ou juste un rapport standard de scan de vulnérabilités ? Clarifiez bien le cahier des charges sinon ils risquent de refuser votre rapport à 100 EUR et d'exiger un audit réalisé par un cabinet accrédité.

Avant de payer pour un outil tiers, ouvrez un ticket auprès de votre hébergeur actuel. Beaucoup d'hébergeurs pros fournissent déjà gratuitement un rapport basique de sécurité et de scan de ports via leur interface. Ce document suffit bien souvent pour une première vérification.

Si on lance ces outils sur notre site web, y a-t-il un risque de faire planter le site ou d'effacer les commandes en base de données ? On a un peu peur de lancer un scan alors que le site tourne en production.

aucune inquiétude à avoir un simple scanner de vulnérabilités n'attaque pas votre système, il teste juste les poignées de porte pour voir si c'est ouvert puis du coup cela dit, pour ne pas saturer la bande passante c'est toujours plus prudent de lancer l'analyse en dehors des heures de bureau, au milieu de la nuit.

Si vous n'avez pas de bagage technique, filtrez le rapport en 3 étapes : 1) Cochez uniquement les alertes classées « critique » et « haute ». 2) Isolez les lignes indiquant « exploit disponible ». 3) Transmettez directement cette liste au support technique de votre hébergeur pour lui demander de fermer ces accès.

Correction : je me suis trompé sur le chiffre, c'était un peu plus bas.

Ne claquez pas 2.000 EUR dans du conseil : sortez le rapport de synthèse d'un scanner cloud et transmettez simplement les alertes rouges à votre hébergeur pour qu'il s'en charge.

je vais résumer ce qui a été dit jusqu'ici puis une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.

j'espère que cela vous sera utile.

Exactement, et ce n'est pas si connu que ça. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Bien sûr, cela change si votre situation est différente.

Il faut y aller étape par étape. bref le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Comment avez-vous résolu ce point ? Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

J'espère que cela vous sera utile.

Si j'ai bien compris, vous dites que : Essayer de faire cela seul est la voie la plus coûteuse.

Voilà, désolé si je me suis étendu.

Ce sujet est archivé. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Je vais essayer.

La solution qui semble bon marché finit souvent par coûter cher. Les décisions hâtives finissent par être corrigées six mois plus tard.

Corrigez-moi si je me trompe.

Je parle du point de vue du fournisseur, c'est mon côté. Ne comptez pas sur une seule mesure de sécurité ; allez par couches.