En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies pour vous proposer des services et offres adaptés à vos centres d'intérêt. OK En savoir plus X
Déposez votre CV Fournisseurs du secteur public

Logo Gazette.fr

20

Commentaires

Réagir

Visualisation de données

Plusieurs milliers de sites Internet de communes mal sécurisés

Publié le • Mis à jour le • Par • dans : A la une, France

20

Commentaires

Réagir

Sécurité informatique des sites des communes françaises © D.R.

La Gazette a dressé une carte indiquant le degré de sécurité de plus de 14000 sites de communes. Bilan : environ 6500 ne sont pas à jour.

 

Peu après les attentats de janvier, de nombreux sites de collectivités ont été piratésdéfacés dans ces cas – par des anonymes soutenant les terroristes. Nul besoin d’avoir un bac + 12 en sécurité informatique pour faire tomber un site tant ils sont nombreux à être insuffisamment sécurisés.
Dans le cas de notre enquête, nous recensons environ 6500 communes françaises disposant d’un site qui est non seulement vulnérable, mais qui expose cette vulnérabilité aux personnes en quête de proies faciles.

Pour les identifier, « il suffit » en effet d’analyser le code source ou les en-têtes de la page d’accueil pour lire les versions du serveur, de l’application et du langage utilisées. Ces informations permettent de déterminer si un site est vulnérable à des failles de sécurité, ou du moins de donner des indications sur la manière de l’attaquer en vérifiant si les versions des logiciels utilisés ont fait l’objet d’alertes de la part des éditeurs ou de la communauté des développeurs.

Les risques varient en fonction de la faille, de l’habileté du pirate, de ses moyens et de son but : défaçage, intrusion dans le système pour y glisser des malwares (1) qui contaminent ensuite les personnes qui se connectent, ou pour voler et/ou détruire des données…

Ce constat est inquiétant, alors que l’e-administration est un axe important de la modernisation de l’action publique et répond à une demande effective des citoyens. Or  la confiance est nécessaire au bon déploiement de l’e-administration.

« Niveau de sécurité incertain » signifie que nous n’avons pas pu déterminer de façon sûre si le site est sécurisé ou pas (cf. encadré)

Le co-marquage service-public.fr comme base d’enquête

Notre enquête se base sur les données du co-marquage de service-public.fr, un service proposé par l’État permettant aux administrations centrales de diffuser des informations locales, soit quelque 15 000 sites référencés (2). Notre base de données est une photographie à l’instant T, en l’occurrence la première semaine de février. Entre-temps, certains hébergeurs ont effectué des mises à jour, notamment 1&1, dont les serveurs étaient alors exposés à une faille connue à ce moment. 98 sites sont concernés. (voir aussi encadré).

Nos conclusions s’appuient donc sur les éléments visibles et déclarés sur chaque site, considérant que la version annoncée et/ou détectée est la version effectivement en place. Le bon réflexe en terme de sécurité sur internet est plutôt de cacher les versions utilisées que de mentir. Vous trouverez sur Github, ici et , notre algorithme pour déterminer le niveau de sécurité. Vous y trouverez en détail la liste des outils encore supportés et donc sécurisés, ceux qui ne le sont plus et ceux où nous n’avons pas pu déterminer.

Guides des bonnes pratiques

Si votre site n’est pas sécurisé ou si vous ne le savez pas, pas de panique : l’Anssi, l’agence gouvernementale chargée de la sécurité des systèmes d’information, propose des documents accessibles pour appréhender cette matière ardue et, dans le cas d’un marché public visant à la construction d’un site internet, d’y faire figurer les conditions de sécurité ad hoc : le guide d’hygiène informatique et la note sur la sécurisation des sites web.

Suite aux cyberattaques de janvier 2015, l’Anssi a aussi produit une fiche d’information pour les webmasters et une fiche de bonnes pratiques, deux documents courts pour rappeler des fondamentaux, pas forcément coûteux. Enfin, elle vient de sortir une note sur les attaques DDOS, celles qui consistent à saturer un site de requêtes pour le faire tomber. Vous pouvez aussi vous adresser à ses observatoires régionaux, les OzSSI ou aux Clubs de la sécurité de l’information régionaux (Clusir).

 

Pour vivre heureux, vivons masqués

Même si des mesures techniques comme des pare-feu permettent de se protéger, masquer les données renseignant les versions logicielles et applicatives est la base d’une installation sécurisée. Pourtant, beaucoup de sites parmi ceux analysés ne respectent pas cette règle de bonne hygiène, qui ne coûte rien. Elle ne dispense en aucun cas d’avoir des outils à jour. La sécurité doit concerner toutes les briques logicielles qui composent un site, serveurs, langage de programmation et applications. Si deux briques sont très sécurisées mais que la troisième présente une faille, votre site n’est pas sécurisé. De même, la sécurité d’un site est un processus continu qui repose sur des mises à jour, un site n’est jamais sécurisé une fois pour toute, il l’est à un instant T, en attendant qu’une faille de sécurité soit découverte.


Create infographics

La version du serveur, une information souvent non visible

Dans le détail, côté serveurs (3), les sites de communes se montrent plus discrets (et donc plus sécurisés sur ce point) : la plupart d’entre eux n’exposent pas leur version dans la configuration par défaut, ce qui explique que plus des deux tiers des sites ne l’affiche pas. On connaît en revanche la technologie utilisée. Ce qui permet de relever que 2% des sites utilisent des versions de serveurs qui ne sont plus supportées.

Les trois quart des sites utilisent un serveur web Apache, une proportion plus important que pour la moyenne du web, mais qui correspond au positionnement des sites de mairies qui ont en majorité peu de trafic, alors que Nginx est plutôt utilisé pour des sites à gros trafic.

Create infographics

Create infographics

Le langage de programmation, faille majeure

Seul un tiers des sites masque le langage de programmation utilisé. Parmi ceux qui le dévoilent, une majorité utilise le langage PHP, et la moitié indique aussi sa version. Parmi ces derniers, seuls 20% utilisent une version à jour. Or, plus une version est ancienne, plus elle présente des vulnérabilités.

Et la taille des villes ne change rien à l’affaire : une grande ville peut présenter les mêmes failles qu’une petite commune sans moyens, et des versions de langages anciennes. Nous avons dénombré 38 communes de plus de 50 000 hab. dont le site est mal sécurisé, sur 145, soit un bon quart. A contrario, Wisembach (406 hab.), Latillé (1480 hab.), Brié-et-Angonnes (2416 hab.), etc. ont des sites à jour, et mieux encore, bien d’autres masquent les informations, le bon réflexe en sécurité : Condé-sur-Marne (716 hab.), Falleron (1511 hab.), Charleval (2481 hab.), etc.

Toutefois, plus une ville est grosse, plus son site a des chances de présenter un bon niveau de sécurité (informations masquées ou site à jour), comme l’indique le graphique ci-dessous.

 

https aux abonnés absents

A l’origine, le protocole https, qui chiffre les données qui transitent entre une site et l’ordinateur de l’internaute, était essentiellement utilisé par les sites d’e-commerce. Mais son utilisation s’est peu à peu généralisée en même temps que le public commençait à s’intéresser à ces questions. Depuis 2014, Google privilégie même les sites utilisant https dans ses résultats de recherches. De ce point de vue, les sites des villes ont bien du retard : sur les plus de 14000 sites de notre base, seulement 53 proposent une version sécurisée, et pour 16 d’entre eux ils s’agit de sites hébergés sur des plate-formes comme WordPress ou Google qui fournissent d’office cette fonctionnalité. Toutefois, il semble que la partie « espace personnel », là où les internautes laissent des données personnelles, utilisent https.

Autres enseignements

Les données récupérées à l’occasion de cette enquête permettent par ailleurs d’établir que, sur notre échantillon de 15 000 sites, l’immense majorité des communes françaises de plus de 5000 habitants ont un site. Les exceptions concernent surtout l’outre-mer : Parmi les communes qui n’ont pas de site, certaines se sont rabattues sur une page Facebook, par exemple Baillif en Guadeloupe. L’office du tourisme en revanche peut avoir un site correctement fourni. On peut aussi relever certaines communes qui, en l’absence de site propre, renvoient directement sur leur intercommunalité. A noter aussi que M’Tsangamouji, à Mayotte, a un site dont l’accès… est soumis à mot de passe : une sécurité parfaite, mais pas forcément un exemple à suivre.

Logiquement, la proportion de villes ayant un site internet augmente régulièrement avec la population pour atteindre les 90% pour les villes de plus de 3000 personnes.

 

Comment avons-nous déterminé si une version de PHP est à jour ?

De nombreux sites présentent un “niveau de sécurité incertain”, ce qui signifie que nous n’avons pas pu déterminer de façon certaine si le site est sécurisé ou pas. Cela provient de la manière dont les logiciels sont développés et installés. Nous allons prendre l’exemple de PHP, le langage majoritairement utilisé. Il existe deux moyens d’avoir une version de PHP à jour :

  • Utiliser une des dernières versions de PHP sorties, elle sont à jour de toutes les failles de sécurité. Si une faille est détectée, l’éditeur sort une nouvelle version et il faut la mettre à jour.
  • Utiliser une version de PHP packagée dans un système d’exploitation supporté par un éditeur ou une communauté de développeurs. Dans ce cas la version de PHP est choisie lors de la sortie du système d’exploitation, et l’équipe en charge de la sécurité dans l’entreprise ou la collectivité, ou la communauté qui s’occupe du système d’exploitation récupère les correctifs de sécurité disponibles dans les nouvelles versions de php et les intègre dans sa propre version. Le numéro de version peut alors ne pas être modifié au sein du système d’exploitation packagée, ce qui n’empêche pas de disposer d’une version à jour.

Malheureusement pour nos analyses, il n’est pas possible, à partir des informations récoltées, de déterminer dans quel cas on se trouve. Le degré de sécurité du site au niveau du langage de programmation est donc incertain. En effet, lorsqu’un site utilise une version de php distribuée dans un système d’exploitation, trois cas sont possibles :

  • la version distribuée dans un système d’exploitation et le système ont été mis à jour : la version de PHP est sécurisée.
  • la version distribuée dans un système d’exploitation et le système n’ont pas été mis à jour : la version de PHP n’est pas sécurisée.
  • une version installée manuellement dans un système d’exploitation différent de son système d’origine : elle n’a donc pas bénéficié des patches de sécurité.

Exemples :

  • Version 5.4.37 : une des dernières version de php sorties et qui ne contient pas de faille de sécurité identifiée. Elle est donc à jour.
  • Version 4.1.2 : une version très ancienne de php, aucun système d’exploitation supporté actuellement ne l’utilise.
  • Version 5.4.20 : une version qui est utilisée par au moins un système d’exploitation supporté actuellement (OpenSuse 13.1) : on est dans un des trois cas décrit ci-dessus, il est donc impossible de savoir si elle est sécurisée.

Ce même procédé est appliqué pour toutes les briques logicielles pour laquelle nous disposons d’informations suffisantes.

Les failles de sécurité ont été catégorisées manuellement pour ne retenir que celles qui sont pertinentes pour le site d’une commune. Ainsi une version d’un logiciel comportant une faille sur une fonctionnalité qui n’est pas utilisée sur ce type de site est tout de même considérée comme sécurisée. La mise à jour d’un site pouvant être compliquée, les administrateurs font parfois le même genre d’évaluation pour savoir si elle est nécessaire ou si on peut s’en passer.

Faut-il publier ces données ?

Plusieurs internautes se sont interrogés sur la pertinence de la publication du détail des données, voire ont indiqué qu’ils trouvaient notre démarche irresponsable. Nous avons eu ce même débat au sein de la rédaction, avant de publier l’article et la carte. N’allaient-on pas encourager des hackers à cibler les sites désignés comme faillibles ? Est-ce le rôle de la Gazette de stigmatiser les communes, souvent petites, qui n’ont pas de site à jour en matière de sécurité ? Voilà les deux questions avancées, au sein de la rédaction, pour défendre la non publication de l’enquête. Une position intermédiaire défendait l’idée de publier les chiffres globaux, mais pas les données détaillées, commune par commune. Au final, nous avons estimé :

  • Des sites de collectivités ont été piratés début janvier, et avant encore, ce qui montre que les hackers n’ont pas besoin de notre article pour lancer leurs actions.
  • Si des journalistes ont eu l’idée d’identifier les failles des sites, il est évident que d’autres, peut-être avec des intentions malveillantes, l’ont aussi. De surcroît, à l’heure de la transparence permise par Internet, taire un fait en espérant qu’il n’émergera pas est une pure illusion. Des dizaines et dizaines de sites expliquent dans les moindres détails comment hacker un site.
  •  Nous ne montrons pas comment pirater un site. Notre enquête identifie les sites qui présentent des failles qui peuvent être exploitées par des hackers. Ce qui n’est pas du tout la même chose.
  • Notre travail consiste à alerter les communes sur d’éventuelles faiblesses de leurs sites, pour sécuriser leurs services. Nous sommes bien dans le rôle de La Gazette, qui explore en permanence la qualité des politiques publiques.

L’ensemble de ces arguments ont finalement plaidé pour la publication de l’article, de la carte, et des données détaillées : en l’occurrence, c’est cette transparence qui peut freiner des initiatives de hackers, car elle permet la mobilisation des communes concernées, en connaissance de cause.
Romain Mazon, rédacteur en chef web La Gazette des communes, Sabine Blanc et Julien Kirch.

Une nouvelle carte mise à jour dans un mois

Suite à notre article, certains webmasters nous ont indiqué avoir mis à jour leur site, ce qui était un de nos buts principaux. On nous a aussi signalé la sortie d’une nouvelle version de PHP. Pour mesurer l’impact lors de ce travail et reconnaître le professionnalisme des webmasters qui se sont montrés réactifs, nous ferons donc une nouvelle passe dans un mois, avec une nouvelle carte.

Projet réalisé sur une idée de Julien Kirch, qui a scrappé les données et formalisé l’analyse technique.

Haut de page

  • VoirRéduire

    Notes

    Note 01 - logiciels malveillants - Retourner au texte

    Note 02 - Seules 6% des url des adresses de sites de communes ne répondent pas à partir de la base service-public.fr. Plusieurs passes ont été effectués à plusieurs jours d’intervalle afin de ne pas pénaliser les sites temporairement indisponibles.Une vérification manuelle a été effectuée pour toutes les communes de plus de 5000 habitants afin d’affiner les résultats. - Retourner au texte

    Note 03 - la machine qui héberge le site internet - Retourner au texte

Aujourd'hui sur

les Clubs Experts de la Gazette

REP Emballages : le cahier des charges pour la prochaine période est enfin paru

Le cahier des charges d’agrément de la filière des emballages ménagers pour la période 2018-2022 vient d’être publié. Si les préparations de réagréments des éco-organismes dédiés ont, par le passé, toujours été très animées, celle-ci remporte la ...

Quels délais pour la facturation électronique entre administrations ?

Passée relativement inaperçue, l'ordonnance du 26 juin 2014 prévoyait qu'au 1er janvier 2017, les collectivités de toutes tailles devaient émettre toutes leurs factures à destination d'autres collectivités, de l'Etat ou d'autres personnes publiques sous un ...

Mesures de sécurité dans les écoles : bilan et éclairage juridique

Au cours de l’été, de nouvelles consignes avaient émané du ministère de l’Education nationale afin de compléter les dispositions mises en place après les attentats de novembre 2015. Trois mois plus tard, des interrogations demeurent toujours à propos de la ...

Compte personnel de formation : le gouvernement consent des ajustements au CCFP

Le Conseil commun de la fonction publique a voté en faveur du projet d'ordonnance créant le compte personnel d'activité - et donc le compte personnel de formation - avec 14 voix "pour" des organisations syndicales (CFDT, Unsa, FSU, CFTC, CFE-CGC et FA-FP), 8 voix ...

20

Commentaires

Réagir
Publicité
Publicité

Télécharger
l'appli!

En savoir plus

Formations d’experts

Mots-clés

Thèmes abordés AdministrationInformatique

20 Commentaires

Ajouter un commentaire
  1. 1. lapagelocale 28/01/2016, 09h50

    Bonjour,

    C'est conscients de ces failles sécuritaires, mais aussi de cet internet qui ne se rend pas accessible aux néophytes du net (une large majorité des maires, notamment de communes "rurales"), que nous avons développé un nouveau service de sites internet spécifiques pour les communes : très simple d'utilisation (garantie de mise à jour plus probable et durable), et jamais au détriment de la sécurité et du visuel.
    Notre service peut-il répondre aux faits dénoncés dans votre article, sans pour autant coûter cher aux collectivités ? Nous l'espérons.

    Johann Roy, La Page Locale

  2. 2. Julien Kirch 06/04/2015, 22h32

    Telemak: non car comme vous l'indiquez il est difficile de les détecter de manière fiable

  3. 3. Telemak 06/04/2015, 21h12

    De notre coté, nous travaillons la sécurité avec des pare-feu applicatifs et des pare-feu réseau pro-actifs. C'est bien plus efficace, même sur un site qui présenterait des failles. Vous avez prévu de noter aussi ces critères ? Attention à la méthode pour les détecter par contre...

  4. 4. Didier 02/04/2015, 15h23

    Je rejoins azq : Il est simpliste de penser que "Informations masquées" = "vulnérabilités pas exposées". Il est aussi ridicule de se fier à la version d'un langage ou d'un outil pour espérer en déduire des failles de sécurité, il est tout a fait possible de les patcher sans monter la version.

    Il y a un probleme avec la categorie des sites "incertainsé, j'en ai cliqué un dont le langage était donné comme 'inconnu', après, visite du dit site, il se trouve que l'extension des pages était ".php", j'en déduis, même si ça n'est pas une preuve formelle, que le site utilise du PHP, mais comme ça n’était pas donné clairement et avec la version par leur outil, ça n'est pas répertorié dans les données.

    Ensuite, Nginx est souvent utilisé comme reverse proxy avec la possibilité d'une multitude de serveurs très différents derrière, et si, par exemple, ces serveurs sont susceptibles à des injections sql, c'est pas un nginx à jour qui va les sauver.

    Enfin, après avoir regardé vos scripts sur github, je suis tombé la dessus :
    CATEGORY_INFO_INSUFFISANTE = 'Niveau de sécurité incertain'
    donc, la variable porte un nom assez clair : 'info insuffisante', qui se traduit dans le doute par 'Niveau de sécurité incertain'., ne serait-ce plus juste de dire que les données sont insuffisantes pour déterminer quoique ce soit ? la couleur grise indique bien quelque chose de neutre, mais l'intitulé Niveau de sécurité "incertain", semble faire une opposition à "à jour" ou "informations masquées". Et malgré tout, c'est bien d’être à jour, c'est pas forcement utile de masquer ces informations, par contre, ces deux catégories peuvent être potentiellement vulnérable par des injections SQL, du XSS voir carrément d'autres services ouverts sur Internet.

    Je suppose que la sécurisation des site Internet est une problématique bien trop complexe pour être abordée de manière si généraliste et avec des données manquant autant de précision. Ca ne va servir qu'à effrayer inutilement certaines personnes tandis que d'autres seront au contraire trop satisfaite d'avoir un site à jour sans se préoccuper des gens autres types d'attaque.

  5. 5. Guillaume 01/04/2015, 08h43

    Bonjour,
    Vous pourriez ajouter à la liste des vulnérabilités la non mise à jour des cms genre wordpress. Vous ne semblez pas être à jour sur votre site, et c'est plus grave que l'affichage des headers html et de la version de php.
    Vous pourriez aussi corriger toutes les erreurs au niveau du html / css, 127 erreurs et 49 warnings, ça pique un peu les yeux
    J'administre un site marqué sur la carte comme 'pas à jour', subit des attaques pendant 15 jours, sans réussite.

  6. 6. azq 29/03/2015, 12h48

    L’article insiste sur ce qu’on appelle la sécurité par l’obscurité, qui reste un concept bancal : non, cacher votre version de PHP ne rend pas votre site plus sécurisé, et il y a bien d‘autres failles possibles. Beaucoup de sites de l’administration publique sont vulnérables aux failles XSS par exemple, qui sont complètement indépendantes du langage ou du serveur utilisé, et à fortiori de leur version. Et même une vieille version de PHP ne vous apprend rien, il suffit d'avoir appliqué les patchs de sécurité.

  7. 7. Nicolas S. 26/03/2015, 17h29

    Le site de la Ville de Neuilly-sur-Seine est www.neuillysurseine.fr et non pas www.ville-neuillysurseine.fr

    C'est la gazette des communes qui n'est pas à jour apparemment !

  8. 8. Sabine Blanc (journaliste)
    27/03/2015, 09h56

    Bonjour, nous avons récupéré les données sur service-public.fr, le problème se situe plutôt de ce côté, nous ne pouvions pas vérifier 14 000 sites à la main, nous avons juste vérifié que l'adresse répondait.

  9. 9. Telemak 26/03/2015, 17h15

    Vous auriez pu faire un constat chiffré sans pour autant pointer du doigt les sites commune par commune. De plus, votre méthode repose sur le postulat de cacher des informations pour faire une sécurité passive, mais vous faites le choix de mettre en lumière des vulnérabilités. Dire qu'un site est sûr car il est à jour est également faux. L'avalanche de failles 0day dont certaines ne touchent que les dernières versions n'est pas pris en compte.
    Mon constat, c'est que le nombre d'attaques est en hausse à nouveau depuis le début de la semaine et une explosion depuis hier. Et le profil des attaques montre un ciblage plus fin.
    C'est en ce sens que votre initiative est malheureuse dans la précision de l'information.
    Et je passe sur les demandes de justification des clients, qui à la limite nous permettent de mettre en lumière le travail de protection dont ils n'ont pas conscience. On parle cependant d'un sujet que le client ne comprends pas et qui est anxiogène.
    Sur beaucoup de sites, vous n'avez pas pu voir les solutions de sécurité en oeuvre (et c'est le but justement). Plutôt que d'appeler la catégorie "niveau de sécurité incertain", il est plus vrai d'écrire que votre test n'a pas permis d'analyser le véritable niveau de sécurité.
    Il reste que votre article permet de rappeler que la sécurité est un sujet important et un enjeu dans les prochaines années (plus que cela ne l'a été par le passé). Que c'est un sujet complexe et qui supporte des réponses diverses mais complémentaires.
    On peut rappeler également que la faille peut se situer sur le poste du webmaster ou sur le réseau de la collectivité. Voir sur le bureau quand le mot de passe est écrit sur un post'it.... ;-)

  10. 10. François 26/03/2015, 16h33

    Je suis complètement l'avis de Sabine Blanc et de RSSI, d'autant plus que le site data.gouv.fr (cité en référence de cet article) nous permet de télécharger librement le CSV des sites dits insécurisés... de quoi vraiment faciliter le travail de hackers. plus besoin de glaner, on n'a qu'à se servir...

    Etant webmaster d'un des sites cités sur la carte comme "pas à jour", et ayant fait le nécessaire ce jour pour ne pas afficher dans les headers HTTP la version de PHP utilisée, je pense qu'il serait judicieux à présent de pouvoir/vouloir rafraichir la carte, ceci afin de maintenir des informations fiables. merci.

  11. 11. Sylvain 26/03/2015, 16h05

    Je trouve la démarche très bonne...néanmoins, les résultats me rendent perplexe !

    En effet, un des sites que je gère est marqué comme "pas à jour" à cause de la version de php soi-disant en 5.5.20 alors qu’après vérification , il est avéré qu'il est à jour en 5.5.22.

    Je pense que vous avez lancé votre script au moment d'un changement de version de php sur des hébergeurs comme 1and1 ou OVH, du coup de nombreuses mairies sont pénalisées uniquement par ça (Temps de latence de l’hébergeur).

    Vous auriez peut être du prévoir une fourchette de versions valables un poil plus souple ou bien donner des informations en temps réel sur la carte et les graphiques ....et non pas des informations qui pour le coup ne sont pas à jour !

    Merci de mettre un point vert sur le site de la mairie de Noth (23) :-)

  12. 12. Fabien 26/03/2015, 16h02

    Bonjour,

    Est-ce que cette carte est mise à jour régulièrement ?

    Attention vous dites que la version php Version 5.4.37 est à jour or celle ci a été remplacé par la version 5.4.39 le 19 mars.

    Cordialement,

    Fabien.

  13. 13. Sabine Blanc (journaliste)
    26/03/2015, 17h20

    Bonjour, la carte n'est pas mise à jour en temps réel, mais il serait très intéressant de refaire une passe dans 6 mois et de comparer. Concernant la version de PHP, l'algorithme a été fait avant cette mise à jour, ce qui explique le décalage, on prendra en compte lors de la mise à jour, merci du signalement, vous suivez de près !

  14. 14. fabien 26/03/2015, 17h40

    Il serait judicieux de mettre à jour cette carte journalièrement ou de clairement indiquer qu'elle n'est pas à jour.

    En tant qu'éditeur, nous recevons des appels de communes qui s'inquiètent alors que les serveurs ont été mis à jour.

    Cordialement,
    Fabien.

  15. 15. Sylvain 27/03/2015, 09h44

    J'approuve à 100% votre message, je suis dans le même cas que vous (Communes qui sont inquiètes et qui peuvent remettre en cause notre suivi alors que tout est à jour !)

  16. 16. @FabianRODES 26/03/2015, 14h22

    Je plussoie au commentaire de "RSSI", à savoir que la simple colonne "catégorie" affichant le statut de vulnérabilité eut été suffisant. Pas la peine de faciliter le 'travail' de tout pirate en herbe avide d'exploit ou de sensation.

    Rien à redire sinon sur le reste de l'article qui j'espère sera lu par tous les DGS/DSI et incitera une prise de conscience et se traduira par des actions.

    Cdlt
    FR

  17. 17. ElCep 26/03/2015, 11h55

    Bonjour,
    Je suis de l'avis de Sabine, la prise de conscience de l'exposition au danger peut se faire par les populations locales du coup j'ai fait un petit mail à ma commune pour lui donner donner le lien et qu'elle justifie du budget com/internet et vulnérabilité ...
    Merci beaucoup pour cet article!

  18. 18. Olivier Jan 26/03/2015, 10h20

    Bonjour,

    Article très intéressant. Je me permets d'ajouter une précision sur l'importance du monitoring de sites web, trop souvent oublié lorsque un site est mis en ligne et qui permet de détecter tous problèmes sur un site avant que vos utilisateurs n'en soient affectés.

    Seule une supervision rigoureuse et automatisée d'un site web permet de réagir vite quand le pire est commis comme un défilement.

    Le monitoring permet également de vérifier les points importants d'un site web comme ses performances, son bon fonctionnement et son niveau de sécurité.

    Il existe beaucoup de solutions Open Source pour ce faire et des services en ligne comme Check my Website ou Pingdom permettent également de le faire à des prix modiques.

    Un site web bien désigné, bien hébergé, bien monitoré et bien maintenu (à jour notamment) à beaucoup moins de chance d'être attaqué qu'un autre.

  19. 19. RSSI 26/03/2015, 08h11

    Bonjour

    Je pense que ce type d'information n'est pas a diffuser dans l'état
    En effet, un amateur peut maintenant essayer de s'amuser
    Il serait préférable de prévenir les collectivités concernées

  20. 20. Sabine Blanc (journaliste)
    26/03/2015, 10h08

    Nous nous sommes bien sûr posés la question mais les personnes malveillantes n'ont pas besoin de nous pour détecter les sites vulnérables, cf les attaques de janvier, réalisées par des "script kiddies" à l'aide de scripts qui automatisent la recherche de sites non sécurisés.

  1. Ajouter un commentaire

      Votre e-mail ne sera pas visible

    Conformément à la loi "Informatique et libertés" du 6 janvier 1978, vous pouvez accéder aux informations vous concernant, les rectifier ou vous opposer à leur traitement et à leur transmission éventuelle à des tiers en écrivant à : Groupe Moniteur - 17, rue d'Uzès 75018 Paris cedex 02 ou en cliquant ici.