Les applications et produits documentaires étant par définition des systèmes ouverts, les risques sont multiples. Ils peuvent concerner la plateforme sur laquelle l’application est installée, les composants même de l’application ou encore l’intégrité des données et services. Et cela est accentué par la constante évolution des modes opératoires. S’ils sont très souvent basés sur une approche technique, ils peuvent aussi profiter des défaillances humaines.

Ne pas rester statique

Les conséquences d’une attaque mal contenue sont toujours néfastes : interruption de service aux utilisateurs, dommages sur la plateforme et l’application, perte ou altération des données, etc. Sans compter les impacts sur l’image de marque. Une politique efficace de sécurité documentaire ne peut donc pas être “statique”. Elle doit, au contraire, se penser en termes de surveillance et d’adaptation permanentes. L’idée étant de prévenir, de surveiller, de contrer et de revenir le plus rapidement à la normale.

Penser “security by design”

Il est également important de réfléchir aux problématiques de sécurité depuis les méthodes de développement jusqu’à la mise en place des moyens de protection courants (firewall, politique de mots passe fort, filtrage sur les adresses IP, etc.) et de mettre en place des circuits rétroactifs permettant de détecter et protéger en temps quasi réel. Ces circuits consistent bien évidemment de prendre en compte en permanence les failles de sécurité publiquement déclarées, mais il s’agit surtout de rester en surveillance constante des remontées des différents indicateurs (sondes) de l’application (temps de réponse moyens, nombre d’accès simultanés, « santé » des index etc...) pour pouvoir avertir et réagir dès qu’une anomalie est détectée (corruption des index, explosion du nombre d’accès simultanés, saturation des disques...).

Impliquer les équipes dans la production

La dynamique de production de notre progiciel repose sur la méthode Devops complémentaire à la méthodologie Agile. L’objectif étant de faire collaborer tous les acteurs de l’entreprise dans le développement du produit. Ce qui permet de :

– multiplier la fréquence des mises à jour.
– garantir une meilleure qualité de celles-ci, par la mise en place de stratégie de surveillance active et de rétroactions régulières.
– prendre en compte rapidement des nécessités de correctifs relatif à la sécurité

Conséquence positive de cette démarche : le souci de produire une solution sécurisée ne reste pas le problème exclusif du développeur, mais concerne désormais l’ensemble des équipes. Nous avons récemment introduit dans l’architecture de notre produit, la notion de conteneurs de données. Ces derniers autorisent, notamment, une redondance des données qui diminue considérablement le risque de perte et facilite la récupération en cas de corruption suite à une intrusion.

Mettre en place une méthodologie de test

Pour parer les principales menaces d’intrusions techniques (attaque par Injection SQL, attaques XSS, attaque de type ../, attaques de type CRLF…), nous avons également mis en place une infrastructure de test dans laquelle nous avons intégré un firewall de type IPS (logiciel Suricata recommandé par l’ANSSI). Celle-ci nous garantit que chaque ligne de code qui sort du processus de validation répond aux critères de sécurité de l’ANSSI.

L’humain, le maillon faible

Concernant les faiblesses du maillon humain, le problème est à aborder autour de 2 axes :

– la prévention. Elle passe par la mise en place de campagne de sensibilisation (ne jamais brancher une clé USB dont nous ne connaissons pas l’origine, toujours définir des mots de passe forts, ne pas communiquer ses login et mot de passe à des tiers, supprimer des bases de données les personnes ne faisant plus partie de l’organisation, etc.)

– la protection par la généralisation de tous les moyens à notre disposition pour éviter l’éventuelle propagation de processus malveillants (limitation des droits d’installation sur les postes, antivirus, anti-malwares, etc.)

Il faut toujours garder en tête que les menaces techniques, même si elles sont bien réelles, demandent un très haut niveau de technicité à l’attaquant et peuvent être la plupart du temps déjouées si un minimum de moyens de protection a été déployé. Il n’en est pas de même lorsque l’attaquant exploite les faiblesses humaines.

Cuisine interne

Aussi, pour limiter la porosité entre les activités quotidiennes de gestion et les serveurs de recette ou de production, nous avons opté pour une utilisation systématique de serveurs hébergés dans des infrastructures dédiées. Il est ainsi presque impossible qu’une violation survenant sur les postes de nos salariés ait des conséquences sur nos applications de production ou sur les applications des clients que nous hébergeons.

De même, notre solution a été pensée pour être capable d’intégrer avec la plupart des systèmes de fédération d’identité ou de SSO (Single Sign On) et ceci afin de cloisonner au maximum la phase de fourniture d’identité de celle de consommation des services.