RGPD: la licorne IT de 2018 ?

L’arrivée du Règlement Générale de Protections des données (RGPD) et son échéance au 25 mai 2018, fait de cette nouvelle réglementation un sujet brulant. Comme tout professionnel de l’IT , il m’a été difficile de ne pas me sentir concerné. Comme beaucoup, à la simple évocation du mot Data, je me suis mis à rêver à une nouvelle source d’activité!

Après quelques mois à lire tout ce que j’ai pu sur le sujet, j’ai creusé la question dans tous les sens. J’ai regardé les offres existantes, dévoré les multiples dossiers spéciaux sur ce thème, rempli les formulaires et questionnaires d’évaluation de sa « maturité RGPD », regarder les offres des éditeurs,…

Finalement, il faut se faire à l’idée que le RGPD est un sujet transverse certes, mais avant tout juridique!

Effectivement les personnels IT peuvent être sollicités sur la partie « outillage » et robustesse de l’infrastructure mais ça ne devrait pas aller plus loin dans la plupart des cas!

Pourquoi?

A cause de 2 points :

  • Les DSI ne sont pas souvent responsables de traitement de données personnelles pour leur  propre compte. Une DSI n’est souvent qu’un acteur technique
  • La responsabilité de la conformité au RGPD est un acte juridique, pas un acte technique. Je n’ai trouvé aucun référentiel technique à suivre pour être en conformité

Cela explique pourquoi on trouve des offres où des consultants se posent en DPO externalisé et proposent des audits sans se déplacer physiquement dans les entreprises et sans même être informaticien.

Cette prédominance du juridique fait aussi, qu’en cas de sanction les entreprises vont naturellement demander des comptes à leur DPO (quand elles en ont un).

Pour illustrer un peu plus ma vision, je vous propose l’infographie suivante que montre l’impact du RGPD sur la fonction RH. Vous constaterez que la DSI n’intervient assez peu en direct dans ma présentation.

Bref, il va falloir que je trouve autre chose pour gagner ma vie…

infographie RGPD-RH

Retour d’expérience sur les attaques de site WordPress.

WordPress est devenu une plateforme très populaire aussi il est régulièrement pris pour cible.

Comme je possède plusieurs sites fonctionnant avec ce moteur, j’ai trouvé amusant de regarder de plus prés les logs pour tenter d’identifier les tentatives d’attaques. Il faut garder à l’esprit qu’à l’exception de rares attaques vous visant directement, la plupart du temps les attaques suivent la loi des grands nombres. En général, des robots se contentent de tenter leur chance dans l’espoir d’exploiter une faille oubliée. Ce sont un peu des Shadocks du web appliquant le principe : »plus ça rate, plus ça a de chance de réussir »

Dans cet article, je ne vais pas spécialement m’attacher à identifier les attaquants. Ce serait un sujet à part entière et pour tout dire un peu limite vis-à-vis de la législation française. L’analyse des logs d’accès est moins risquée pénalement.

1 – les tentatives d’inscription

WordPress permet l’inscription en ligne d’utilisateur. Il est donc assez logique pour un pirate de chercher à s’inscrire légitiment sur le site dans l’espoir de disposer de droits suffisants pour faire ces petites histoires.

La contre mesure est simple et efficace, interdire les inscriptions.

Si vous tenez à tout prix à autoriser les inscriptions, assurez-vous que par défaut le nouvel inscrit aura un niveau « Abonné » (dans les réglages généraux de WP).

Pensez aussi à modérer les commentaires…

2- les tentatives de connexion

C’est le cas le plus évident. Un robot tente selon différentes techniques de se connecter en tant qu’administrateur en « devinant » la combinaison  (Identifiant ; mot de passe). Plus qu’une divination, il va le plus souvent faire de multiples tentatives depuis plusieurs adresses IP différentes.

Je me suis aperçu que certaines attaques commençaient par recenser les auteurs des articles. Les attaquants utilisaient ces noms comme identifiants pour leurs tentatives.

Un dernier mode d’attaque est de faire des demandes de réinitialisation du mot de passe. (wp-login.php ?action=lostpassword)

En terme de contre mesure, il faut avoir un identifiant différent du nom affiché publiquement. Et bien entendu avoir un mot de passe FORT (long et complexe).

La question de le changer régulièrement fait débat. Personnellement, je considère qu’un mot de passe suffisamment fort n’a pas besoin d’être le changer sauf en cas de doute.

3- l’appel de scripts

Dans ce cas l’attaquant va tenter d’exécuter un script PHP de WordPress pour exploiter une faille connu. Un exemple est l’exécution XMLRPC.PHP. Fin 2015, une faille a été largement exploitée et on continue à voir des accès à ce fichier.

Plusieurs scripts sont appelés (WP-setting.php, Control.php , sqlibak.php,etc…) parfois des aussi des scripts ASP (là je n’ai pas compris) . Il s’agit d’essayer de lancer des scripts ayant des failles connues ou d’exécuter des fichiers installés précédemment. Les scripts du dossier wp-admin sont des cibles de choix

La contre-mesure élémentaire est de faire les mises à jour le plus tôt possible de WordPress mais aussi de son hôte (serveur web, PHP, SGBD,…)

Personnellement, je vérifie régulièrement les fichiers de mon site. Je contrôle en particulier les dates de modification avec mon client FTP et au besoin je compare avec une sauvegarde.

Autre appel, mais plus étrange : J’ai noté que les moteurs de recherche cherchaient à visiter (sans succès) des pages générées par le script /aloir/glotir.php …

Je n’ai pas encore trouvé d’explication satisfaisante mais visiblement le phénomène est répandu.

 

4- Les plugins et thèmes

C’est la suite logique du point précédent. Ces éléments sont souvent pris pour cible pour les pirates. Les 2 attaques que j’ai subit en 8 ans ont ciblés des templates.

Les mécanismes sont simples :

  • On aime en avoir beaucoup
  • On est moins rigoureux estime leur mise à jour
  • Les auteurs ne sont pas toujours très réactifs
  • Même si la plateforme de téléchargement WordPress retire les extensions à problème, il n’est pas simple de vois si l’une de nos extensions n’est plus recommandée.

Les pirates vont donc cibler les extensions les plus populaires et celles qui peuvent permettre de télécharger des fichiers sur le site.

Parmi les modules attaqués, il y a notamment :

  • recent-backups
  • revslider
  • simple-ads-manager
  • wp-ecommerce-shop-styling
  • wp-mobile-detector

… que je n’utilise pas mais aussi le fameux jetpack.

En ce qui concerne les thèmes, je n’ai pas eu beaucoup de tentatives récemment à part sur Organizer (que je n’utilise pas non plus)

La première des contre mesure est donc de ne conserver que les plugins et thèmes utilisés. Il faut de plus vérifier régulièrement leur mise à jour. Si un de ces éléments n’a pas eu de mise à jour depuis plus de d’un an, c’est suspect… Au-delà de 18 mois, on peut considérer qu’il n’est plus maintenu et que son utilisation est dangereuse.

C’est particulièrement problématique pour les thèmes et les développements spécifiques. Leurs mises à jour doit être prévu …votre prestataire doit être en capacité de comprendre ce qu’il doit corriger. Ce n’est pas toujours très évidemment !

En plus des failles propre à WordPress, il devra prendre en compte les failles liées à la technologie qu’il a utilisé : PHP , MySQL, CSS, XML,…