C'est un syndrome bien connu de tous les projets web, lorsque l'on déploie une application, que ce soit un CMS, une application métier ou un développement spécifique, qu'elle soit basée ou non sur un framework, on trouve souvent, un tas de mauvaises raisons pour ne pas la mettre à jour. Il peut s'agir de négligence, de manque de budget, de développements "trop" spécifiques qui nécessiteraient une refonte du code trop importante pour mettre à jour ce qui doit l'être sans tout casser.
Il existe toujours une multitude de bonnes... et surtout de mauvaises raisons de ne pas maintenir sa pile logicielle.
"if it works don't fix it"
"ce n'est pas parce que ça fonctionne que ça fonctionnera plus tard" - Lao tseu
Si ça fonctionne… surtout ne toucher à rien. Cet adage fonctionnait plutôt bien dans les années 80, mais Internet a démontré et démontrera toujours, que ce qui semble tourner ne marche pas toujours comme on le souhaite dans la durée. La prolifération de données personnelles dans nos bases de données, la vectorisation pour casser du chiffrement, tout indique que ce qui est "privé" aujourd'hui sur Internet sera public demain et les exemples sont légion. Stocker un secret en ligne, c'est se placer sous l'épée de Damocles, parce qu'à terme ce secret sera compromis. Que l'on pose en ligne des documents, une application, un développement, nous avons un devoir "d'entretien" de notre parc, de nos données, de nos systèmes. La réponse logique à ceci : c'est la mise à jour.
Connaitre son parc
"quand ce n'est pas parce qu'on a 2 machines qu'on n'en aura pas 12 demain" - Carl von Clausewitz
Il n'y a pas de système d'information robuste à l'épreuve du temps sans documentation de son propre parc. Quelles sont mes machines, quelles sont les interconnexions entre mes machines, où se trouvent-elles géographiquement, quels services tournent et pourquoi est-ce que je n'encours pas de risque "politique" de coupure, d'interception, de saisie… ? Connaitre son parc c'est connaitre le risque qui plane sur son infrastructure. C'est surtout connaitre sa tolérance à la mise à jour. Le temps jouant rarement en la faveur du patrimoine informationnel d'une personne physique ou morale, personne n'est épargné. Dans le cas d'une personne morale qui stockera des données de ses utilisateurs, l'erreur coûte toujours bien plus cher.
La connaissance de son parc, c'est la connaissance de la surface d'attaque que l'on offre, c'est également la connaissance des données que l'on stocke, traite ou exploite.
Un parc c'est aussi des ressources, ces ressources sont celles de votre système d'information et elles sont de plus en plus convoitées.
Les ressources d'un système d'information (la puissance de calcul éveillant notamment l'intérêt des cryptominers )) deviendront dans les prochains mois ou années aussi rentables que des données personnelles stockées dans votre SI. Connaitre et documenter son infrastructure, c'est un prérequis pour éviter la négligence.
Et c'est qui le boss ?
"quand on a besoin de s'adresser à la bonne personne" - Spinoza
Nommer un responsable du suivi des mises à jour, comme l'on nommera demain un responsable du traitement des données personnelles.Cette idée peut sembler farfelue dans nombre de structures d'hébergement d'applications web et de services.Mais l'une sans l'autre n'ont aucune chance de se confronter au temps d'Internet. Une structure d'hébergement est par nature responsable de la qualité de service de ce qu'elle héberge. En ce sens il est naturel qu'une personne physique puisse assurer au quotidien la gestion des alertes de sécurité sur la pile logicielle que sa structure exploite. Ce n'est pas au client final de comprendre l'importance de la mise à jour de son infrastructure, mais c'est bien à l'hébergeur que revient le devoir d'explication des risques et de l'importance à la mitiger dans le contexte particulier de son client.
Ne pas altérer le core applicatif par des modifications
"quand on fait un choix hasardeux et qu'on le sait" - Mozart
Là encore, il existe d'innombrables raisons de ne pas développer des fonctionnalités "dans les règles de l'art" de sa pile logicielle. Le syndrome "Install and forget" aggrave les risques provenant de la modification du core applicatif ? Un choix de conception est fait à un instant T, les raisons sont souvent économiques, mais peuvent, dans la conduite d'un projet, se retrouver "cachées" par un des intervenants ou par manque de documentation. Quand elles ne sont pas documentées, elles exposent de fait votre système d'information à un risque très important.
La catastrophe arrivera si vous n'en prenez pas préalablement conscience. La "bidouille" d'un framework, du core d'un CMS, ou de tout élément de votre pile applicative devient un problème à gérer au quotidien. Et cette gestion, qui était une économie à la base, devient un poste de coût croissant avec le temps qui passe.
Le cas des développements "sur mesure"
"quand on a des impératifs et les moyens de ces impératifs" - Confucius
Les applications métiers, comme les applications mobiles spécifiques à des usages sont par nature peu auditées, peu testées, peu pratiquées. Elles deviennent donc par nature une surface d'attaque plus sensible. Elles deviennent donc par définition et nativement propices à notre syndrome "install and forget". La pratique en vogue (et non dénuée d'intérêt) du WAF a un énorme problème : elle donne un sentiment de sécurité, tout relatif, qui ne corrige pas les erreurs précédemment énumérées.
Aucun logiciel, aucun service web en SaaS ne pourra prémunir d'une absence de mise à jour de la pile logicielle, du système de sauvegardes et de restauration de ces sauvegardes…
Comment faire au quotidien ?
"quand il faut bien faire" - Albert Camus
Il n'existe pas d'infrastructure infaillible, mais il existe des processus qui permettent de minimiser l'impact des risques encourus par un système d'information.
Ces processus intègrent aussi bien des compétences tierces qu'une connaissance approfondie de son système d'information. Il nécessite une veille constante des menaces nouvelles et d'une parfaite connaissance de la valeur des données que l'on manipule. Il est primordial de savoir quand faire le choix du fork ou du développement sur mesure que l'on assumera de maintenir seul dans le temps. Les outrages du temps sur Internet se traduisent la plupart du temps pas des brèches, en être conscient est un premier pas. S'en prémunir est une tâche plus complexe et nécessite une vision à 360° qui impliquera tous les intervenants d'un projet.
Un hébergeur qui vous propose une prestation d'infogérance saura vous accompagner dans la mise en œuvre de ces bonnes pratiques, vous permettant de vous concentrer sur votre cœur de métier et de vous focaliser sur votre application. La sécurité comme la disponibilité de vos services sont et resteront une chaine de confiance dont le moindre maillon faible aura un impact sur votre système d'information.
N'oubliez rien, n'excusez rien, attendez vous à faire face.
