Introduction à la sécurité pour le décideur : où sont les failles et suis-je concerné?

safety-sign-13

Imaginez une société qui possède certaines données critiques de ses clients, par exemple des milliers d’adresses postales. Un prestataire intervient dans les locaux de la société, passe les trois barrières de sécurité physique, obtient un badge, arrive dans une salle serveur techniquement bien maintenue et mise à jour avec un seul point d’accès réseau à l’extérieur. Là il assiste à une réunion, commence à travailler sur la structure de la base de données et repart après avoir montré une dernière fois patte blanche. Le lendemain il demande à la société un exemple de données pour pouvoir effectuer des tests. Et sans lui faire signer quoi que ce soit, un responsable lui tend un CD contenant la totalité des données, les fameuses données critiques comprises. Le site est-il physiquement et techniquement sécurisé? Oui. Les données sont-elles sécurisées? Beaucoup moins sûr.

A notre époque où le piratage est une à la fois pratique « sportive » et stratégique, où les pirates peuvent sortir des photos dénudées de stars et voler des secrets industriels et militaires, la sécurité est devenu un enjeu majeur et générateur d’articles anxiogènes dans le monde des applications informatiques.

En effet, en tant que particulier ou professionnel, vous ne serez jamais à l’abri d’une attaque ou d’un vol de données (tout comme vous ne serez jamais à l’abri d’une agression ou d’un cambriolage de vos bureaux) : aucune protection n’est sûre à 100%. Pire, quand une faille de sécurité est trouvée (comme la fameuse faille HeartBleed), il est parfois compliqué voire impossible de savoir si vous en avez été ou non victime, d’autant que les fabricants des solutions ne communiquent que lorsque la faille a été identifiée et bouchée.

Bien sûr, comme pour beaucoup de problématiques très techniques, il est compliqué pour le décideur profane, mais pourtant concerné, de discerner où résident les menaces. Le résultat est que quand au journal de 20 heures le présentateur annonce avec le visage fermé des catastrophes une nouvelle faille, il est incapable de déterminer s’il en est une potentielle victime. Cet article a pour but de l’aider à y voir plus clair.

Pour comprendre, reprenons un peu le trajet d’une donnée quand un utilisateur affiche un écran de votre application, dans le cas d’une application client serveur, comme par exemple un Extranet.

Etape 1 : le point de départ est l’ordinateur qui la contient, qui utilise un système d’exploitation pour stocker et récupérer les données. Ce système peut contenir des failles qui peuvent permettre à une personne mal intentionnée de prendre contrôle de l’ordinateur et éventuellement extraire ou manipuler la donnée. Ci-dessous les statistiques de fuite des différents systèmes d’exploitation. Ces chiffres sont à prendre toutefois avec des pincettes, car ce n’est pas parce qu’un système est moins attaqué qu’il est plus sûr, il peut être tout simplement moins attractif pour les pirates (source GFI, enquête par un organisme américain sur les failles de sécurités recensées sur l’année 2014).

vulne-2014-3

Etape 2 : la donnée est ensuite éventuellement répertoriée et exploitée par des logiciels (système de gestion de base de données par exemple), qui possèdent leurs propres failles potentielles, comme par exemple celle-ci sur Oracle.

Etape 3 : nous arrivons maintenant à votre application métier qui exploite les données, et qui peut posséder une faille dans son développement, avec les conséquences suivantes :
– celles permettant de prendre le contrôle du système d’exploitation et de retourner à l’étape 1.
– celles  permettant d’accéder à la base de données et de retourner à l’étape 2.
– enfin celles permettant d’accéder à des écrans sans le droit d’accès approprié.
J’ajoute ici que les informations sont également lues par l’utilisateur via un logiciel (souvent un navigateur Web), qui n’est pas exempt de faille comme le montre le tableau ci-dessous (même source).

vulne-2014-2

Etape 4 : la donnée est transportée dans un tuyau (la plupart du temps le réseau  internet) pour arriver sur le poste de l’utilisateur final, et ce tuyau peut être écouté par un tiers (cela peut même être un gouvernement cf. cet article de mon directeur technique). Si les données ne sont pas cryptées, il suffit de les écouter, sinon il est nécessaire de posséder ou de trouver la clé pour les lire.

Etape 5 : et enfin nous arrivons à la dernière faille, la moins documentée et prévue par les experts : l’utilisateur lui même. De très nombreuses failles de sécurité sont dues à un utilisateur qui fait preuve de libéralité, que ce soit involontairement (mot de passe trop simple, trop utilisé ou communiqué à un tiers, enregistrement de données sur un support non sécurisé, prêt de matériel, transmission de la données sans signature de contrat ou de dérogation, etc.), ou volontairement (vouloir partir avec les données de son entreprise pour les vendre ou les exploiter soi-même, vendetta, etc.).

Maintenant que j’ai brossé ce tableau succinct et en apparence catastrophiste, voici pour conclure cette introduction deux principes fondamentaux à suivre pour limiter les risques :

En premier principe, la sécurité est un effort à prendre en compte dans les choix techniques et pendant non seulement le développement et le déploiement d’une application, mais également pendant l’exploitation :
– mise à jour régulière par votre hébergeur des serveurs pour l’étape 1.
– mise à jour régulière par votre développeur des système de gestion de bases de données pour l’étape 2.
– audit régulier de la sécurité de l’application, avec tests d’intrusion et validation du code pour l’étape 3 (et si un framework ou une bibliothèque sont utilisés, mise à jour régulière de ceux-ci).
– utilisation et renouvellement d’un protocole https pour l’étape 4.
– formation régulière des utilisateurs finaux, surveillance de l’utilisation des données, suppression ou restriction des comptes utilisateurs le plus tôt possible pour l’étape 5.

Toutes ces précautions doivent prendre en compte le second principe : les mesures de sécurité doivent être à la hauteur de la confidentialité ou du caractère critique des données. Par exemple, sécuriser une base contenant l’adresse de 500 000 personnes demande un audit de sécurité plus conséquent et coûteux que la base de ce blog (malgré les trésors de connaissance qu’il contient).
Il faut ne pas toujours céder aux sirènes des sécuritaristes et à tout prix éviter que la barrière  ne coupe le chemin des utilisateurs honnêtes en même temps que celui des pirates. En effet trop de sécurité sans justification peut entraîner au mieux une perte de productivité et un agacement pour les utilisateurs, et au pire des failles encore plus grandes par réaction. Une connaissance m’a confié qu’après s’être vu refuser pendant 2 mois les clés des réserves de son propre rayon pour raisons de sécurité, il a obtenu par un ami le passe-partout du magasin pour ouvrir donc toutes les réserves. Une sécurité particulièrement mal dosée comme dans ce cas est très facilement transposable à l’informatique et peut être plus dangereuse que le pire des pirates.

Fausse bonne idée : commençons vite fait, on verra plus tard…

 numerobis1Souvent, avec des partenaires ou des anciens ou futurs clients, la réunion se déroulait de la façon suivante : ils nous expliquaient leur idée géniale, je répondais « elle est géniale cette idée, mais il faut faire attention à la mise en place technique », la personne rétorquait « boah on verra, pour le moment on fait rapidement avec un développeur pas cher que j’ai trouvé ». La conséquence est quasiment à tous les coups la suivante : le détenteur de l’idée revient en catastrophe quelques temps plus tard, en nous demandant de le sauver ou de finir le projet : un site de vente qui a des soucis de performance le jour des soldes, une application métier jamais finie, un site de contenu ne tenant pas la charge un jour de buzz, etc…

Avant de continuer cet article un petit disclaimer : ceci n’est pas le manifeste du technicien que je suis toujours pour affirmer la supériorité de la technique sur le marketing ou la vente  : mon but est de d’appuyer sur le fait qu’une erreur fondamentale de nombreuses start’up ou les pure player informatique en particulier en France est de négliger (volontairement ou non) la qualité technique du produit.

Quand on construit une maison, on ne choisit pas un constructeur au pif et le moins cher possible, mais plutôt à un architecte pour faire des plans. C’est une question de bon sens : il faut que la maison suive des normes et le projet s’avérera très compliqué par la suite si par exemple les évacuations d’eau sont négligées, si les fondations sont mal fichues, ou si personne ne pense au jour où il faudra construire une dépendance de plus… De même certaines parties de la maison sont réalisées par des maçons, plombiers ou ouvriers d’élites, qui sont en général payés plus chers. Il y a un consensus sur le côté nocif du « vite fait mal fait pas cher ».

Pour un site web ou une application métier, le raisonnement est le même : pour construire une solution pérenne, il est beaucoup plus incertain de demander à un développeur au pif plutôt qu’à demander à un architecte informatique au moins au démarrage du projet. De même certaines parties doivent être développées par un technicien d’élite, qui peut coûter plus cher.

Meetic, Vente privée, facebook, google, Amazon : des grandes success story du web ont toutes un point commun : ce sont certes des belles idées très bien vendues mais elles ont avant tout une base technique solide menée par un équipe avec un directeur technique capable de réfléchir en amont aux problèmes futurs, et des développeurs capable de réaliser du code de très haute qualité.

Évoquons ici les problèmes qui peuvent survenir dans le cas d’un développement d’un produit vite fait.

Première crise possible : le projet ne se termine pas. J’écrirai un autre article sur les causes de non finition d’un projet, mais dans le cadre d’un projet fondateur d’un nouvel acteur du web, l’une des causes les plus fréquentes est que le développeur n’arrive pas à créer une solution stable, ou que le projet s’arrête en cours de développement.

Deuxième crise possible : l’instabilité de la solution empêche sa croissance. D’une part notre expérience nous montre qu’un taux d’indisponibilité de 2% d’un site web peut résulter en une perte de fréquentation de l’ordre de 10%. D’autre part lors du lancement d’un site, la nouveauté ainsi qu’une éventuelle opération marketing amène rapidement des internautes dès la mise en production, et une mauvaise réputation peut être construite en peu de temps si le site est inutilisable. Ce type de handicap est par la suite très compliqué à rattraper.

Troisième crise possible : problème de montée en charge quand la croissance arrive. La grande réussite de plusieurs grands acteurs du Web a été d’inclure dans le plan technique la croissance de la solution. Les problèmes de charge peuvent résulter soit en un site beaucoup plus lent, soit en un blocage définitif lors de la plus grosse période d’affluence. Un site mal codé dès le départ sera très compliqué à réparer le jour où le trafic du site est multiplié par 100 ou 200 d’un coup. Cela arrive même aux plus grand, comme Facebook qui a dû reprendre son site pour en changer les choix techniques de design.

En conclusion, quand un patron a une bonne idée, négliger le développement et ne pas donner le travail à un directeur technique et à des développeurs d’élite (profils difficiles à trouver) est une erreur, qui risque d’aboutir à l’échec du projet ou à des passages très douloureux en cours d’exploitation. L’argument de l’économie d’argent est illusoire, mieux vaut resserrer au départ les fonctionnalités pour se laisser la marge et le temps de créer un outil parfaitement conçu au départ.