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.

Réussir un projet – Episode 2 : l’avant vente

SouffléConséquence d’une phase d’avant-vente trop rapide

Je vais être franc, je suis un peu gêné pour écrire cet épisode, car pour moi pour réussir une avant-vente la solution c’est choisir Yoocan. Cependant en tant que chef de projet et consultant j’ai suivi de nombreuses phases d’avant-vente, et j’ai l’intention ici d’énoncer les problématiques importantes ou les éléments que j’attends d’un client en prospection.

Cet article tient pour acquis le fait que vous avez lu et que vous avez suivi les conseils de mon épisode 1 et que donc votre besoin est bien défini et votre opinion affirmée.

La spécificité de la vente d’un logiciel informatique consiste en l’immatérialité du produit fini, ce que signifie que vous êtes dans un centre commercial face à des rayons pleins de produits invisibles, rendant très compliquée la tâche de choisir le bon parmi tous ceux qui existent. Quelques conseils pour décrypter les offres.

Je vais supposer également que vous êtes un fan de mon blog et que vous avez lu mon article sur le cloud, qui vous aidera à comprendre quoi choisir parmi les différents types d’accès à votre logiciel.

Donc vers quel type de solution se diriger : logiciel tout fait ou solution personnalisée? Il ne vous est pas du tout interdit de prospecter pour les deux, mais il serait intéressant que d’avoir dans votre for intérieur une opinion sur la question.
Cette question est équivalente à la suivante : est-ce que je veux le même logiciel que mon voisin ? La réponse peut être oui : vous voulez un système de partage de fichier avec versioning, un logiciel de compta, ou un CRM orienté annuaire client sans fonctionnalité spécifique à votre métier, faire développer cela de A à Z revient à peu près à réinventer la roue. Pour ma part j’ai parfois répondu à des appels d’offre en répondant « prenez tel ou tel logiciel, pas la peine de passer par nous pour faire ce que vous voulez ».
Par contre si vous voulez que votre valeur ajoutée spécifique soit concentrée dans votre application, attentions aux sirènes du « prenez un logiciel (à licence ou gratuit), nous le personnaliserons », car d’une part les personnalisations peuvent être très chères et d’autre part il vaut mieux parfois partir de rien plutôt que d’une base peu adaptée.

En dehors des fonctionnalités proposées, de la technologie utilisée, des raisons de politique interne ou de la faconde du commercial en face de vous, pour une application métier les notions suivantes sont très importantes à vérifier : bien sûr le prix, mais également le périmètre d’utilisation, et la pérennité, et le mode de réponse de vos candidats.

Que cache un prix? Le prix d’une application est principalement en quatre parties : le coût de licence, le coût de paramétrage / développement / formation, le coût d’hébergement, le coût du contrat de maintenance. Dans beaucoup de proposition ces coûts sont confondus : une licence annuelle d’utilisation d’un produit contient souvent la maintenance, le coût d’une application en SaaS sur le cloud confond l’hébergement et la maintenance. Dans tous ces coûts un seul n’est pas récurrent. Il peut être paradoxal de voir des sociétés gagner de l’argent sur la base de logiciels libres, mais ce qui est gratuit est uniquement la phase 1 du coût, et pas le reste. Je suggère soit de demander au commercial soit d’établir vous même un planning de facturation sur 3 ans. Faites attention également aux coûts de licence par utilisateur : très avantageux au début, ce type de facturation peut être incohérent avec une stratégie de croissance où l’augmentation du budget d’un département ne doit pas être linéaire.

Il ne faut pas également oublier dans le coût d’une application la possibilité d’en faire financer une partie. Le plus simple : la partie formation peut être intégrée à votre budget formation si la société est ou possède un organisme agréé. Un autre : le CIR (Crédit d’Impôt Recherche pour la recherche et développement) et surtout le CII (Crédit d’Impôt Innovation, pour la conception d’un prototype de produit innovant), permettent de faire financer en économie d’impôt le développement de votre solution.

Une autre information qu’il est essentiel d’évoquer lors d’une réunion commerciale est : quel est le périmètre d’utilisation de l’application, et quelles sont ses limites notamment en terme de charge ? J’ai construit plusieurs applications qui étaient destinées à 10-15 utilisateurs permanent, et qu’il a fallu reprendre quand ce chiffre est passé à plusieurs centaine d’utilisateurs. Le client s’est attendu au surcoût car je l’avais prévenu au départ. Il est donc essentiel pour vous de savoir dans quelle mesure le logiciel peut être utilisé : combien d’utilisateur en même temps, combien d’utilisateurs au total, volume de données maximum, les heures d’exploitation (si par exemple des mises à jour doivent être effectuées à heures régulières).

Pour terminer une application métier est une application que vous allez utiliser au quotidien avec à mon opinion une durée minimum d’exploitation de 3 ans. Il est donc nécessaire pour vous client de suivre comment l’application peut évoluer.
Concernant un logiciel, il est nécessaire de vérifier la santé de l’éditeur, la durée d’exploitation du logiciel et s’il existe un autre intégrateur (un de mes anciens clients a du recréer toute une solution en 3 mois car le seul intégrateur restant du logiciel est parti devenir professeur de plongée en Thaïlande).
Concernant une application personnalisée, la santé de l’entreprise doit également être surveillée, la technologie connue d’au moins un autre intégrateur (et attention à la notion de framework, j’écrirai un article sur le sujet dans les prochains jours), et la proposition commerciale doit contenir une partie de documentation technique pour permettre une reprise par une autre équipe, et surtout une description fonctionnelle et technique basique du mode de fonctionnement de la solution proposée : dans le cadre d’une application personnalisée, il vous faut vérifier que votre futur prestataire a bien compris votre besoin.

En conclusion, quelle que soit l’option prise, une application métier est une solution qui définira votre façon de travailler pendant quelques années, donc le choix du prestataire doit être fondé non seulement sur la qualité technique et fonctionnelle, mais également sur la capacité de votre prestataire à vous accompagner dans la durée.