Les éditeurs d’origine proposent des mises à jour de correctifs trop longtemps après l’apparitions des problèmes, voici pourquoi cela n’est plus acceptable pour les grandes entreprises.
Les responsables informatiques sont de plus en plus concernés par la nature interconnectée des entreprises et les difficultés que celle-ci présente en matière de sécurité. Cependant, toutes les inquiétudes ne sont pas fondées et une fausse panique a pu, au contraire, empêcher de contrer une éventualité de cyberattaque.
D’aucuns pensent qu’il n’existe pas d’alternative au paiement annuel de la « redevance maintenance » et à l’application de sempiternels correctifs logiciels. Ce serait ignorer la nature même des menaces qui pèsent actuellement sur la sécurité, en admettant une fois pour toutes que la plupart des éditeurs de logiciels ne sont pas des spécialistes de la sécurité et qu’ils ne le seront probablement jamais. Dans la plupart des cas, les correctifs fournis par les éditeurs de progiciels de gestion intégrés (ERP)servent uniquement à éliminer des bogues, ce qui correspond dans la plupart des cas à une forme glorifiée — et lucrative —d’un jeu de la taupe où les codes erronés se succèderaient indéfiniment les uns aux autres.
Arrêter d’attendre un correctif de sécurité
De manière générale, les éditeurs de logiciels étudient les bogues pour en déterminer la validité et l’importance, un processus aussi long que compliqué. Ils doivent en effet identifier tous les endroits où la bibliothèque ou la base de code affectée a été utilisée, sur quelles plateformes, et pendant combien de temps. Dans nombre de cas, cette méthode permet aux éditeurs de se rendre compte qu’un bogue existe parfois depuis longtemps, jusqu’à 20 ou 30 ans. Il arrive même qu’un problème donné soit « patché »une nouvelle fois bien des années plus tard ; il est en effet relativement simple de passer à côté d’un bogue.
Traiter la faille en amont plutôt que le problème une fois qu’il est apparu
Vient le jour où un correctif est publié, et c’est là que commencent les ennuis pour la plupart des entreprises. Appliquer un correctif est un processus généralement long et fastidieux, en particulier pour les plateformes qui intègrent un grand nombre de personnalisations potentiellement mises en danger par certains effets secondaires du patch. Même dans le cas des entreprises qui ont choisi d’appliquer les correctifs « rapidement »(ce qui est rare, le rythme étant plutôt annuel, au mieux mensuel), une année entière peut s’écouler jusqu’à ce que le patch téléchargé soit installé, testé dans l’environnement opérationnel et, in fine, mis en production. Les clients doivent ainsi attendre que les correctifs soient publiés, puis procéder à de rigoureux tests de régression, vérifier le niveau d’assurance qualité, exécuter des tests auprès des utilisateurs finaux et réparer les éléments mis à mal par les correctifs —le tout, multiplié par chaque instance de base de données ou d’application en service dans l’entreprise. Ces multiples tâches prennent énormément de temps, ne sont pas sans soulever certains risques et phénomènes de rupture, et induisent un coût relativement élevé. Et lorsqu’une situation similaire se produit à nouveau, il faut relancer la mécanique, dans la mesure où les éditeurs de logiciels se contentent le plus souvent de mettre sur liste noire des commandes qui sont généralement contournées par la suivante, obligeant les clients à répéter ce cycle plusieurs centaines de fois.
À titre d’exemple, la vulnérabilité qui a affecté Apache Struts et provoqué la faille de sécurité d’Equifax était due à une désérialisation non sécurisée (CWE-502, l’une des nombreuses failles de type CWE-20 : Validation incorrecte des entrées), une erreur largement répandue dans la plupart des applications actuelles. Or, le patch publié pour supprimer le problème ne permet toujours pas de résoudre les vulnérabilités CWE-502 ou CWE-20 : il en résout uniquement l’exposition (CVE-2017-5638). À peu près à la même période, un autre patch a été publié pour corriger une faiblesse similaire (CVE-2017-9805). C’est pourquoi plusieurs centaines de correctifs ont été publiés dans le but de remédier à cette désérialisation non sécurisée, la plupart étant contournés à moult reprises. Au-delà des éléments patchés, pensez aux failles de sécurité qui ont fait les grands titres de l’actualité au fil des ans : Marriott, Target, Adult Friend Finder ou eBay. Aucune n’a été résolue par le correctif fourni par l’éditeur d’origine. Ces entreprises ont probablement été victimes d’erreurs de configuration, de menaces internes, de l’action d’administrateurs laxistes, de la non-application des règles de sécurité, etc. Ce sont précisément ces menaces qui amènent les utilisateurs d’ERP à se demander s’ils sont vraiment protégés en confiant leurs règles de sécurité à l’éditeur d’origine.
Le fait est que les correctifs proposés par les éditeurs sont complexes et que même lorsqu’ils sont appliqués, leur portée demeure limitée car ils traitent le problème une fois qu’il a été découvert, et non la faille dans son ensemble.
Il existe naturellement une meilleure solution.
Privilégier une approche globale de la sécurité
Les solutions de sécurité de nouvelle génération traitent la quasi-totalité des énumérations de faiblesses communes (CWE — Common Weakness Enumeration) applicables, et non les points d’exposition pris séparément. Par exemple, au lieu de « démanteler » un problème d’injection SQL et de se focaliser sur chaque vulnérabilité syntaxique (ce qui correspond à la stratégie de correction des éditeurs d’origine), les solutions de nouvelle génération minimisent les faiblesses de l’injection SQL dans leur ensemble.
Aujourd’hui, les responsables de la sécurité des systèmes d'information (RSSI) ont besoin de stratégies de sécurité modernes et moins onéreuses, telles que la protection des bases de données « in memory », ou l’autoprotection en temps réel des middlewares et des applications —sans oublier d’autres techniques proactives bien plus efficaces pour gérer la sécurité des piles de logiciels d’entreprise tout en réduisant massivement les indisponibilités opérationnelles et les interruptions de service. Les RSSI les plus avisés utilisent ces technologies comme outil de contrôle courant ou compensatoire, en fonction de la situation, dans le but de répondre ou de dépasser les attentes des auditeurs de sécurité lorsque l’application des correctifs s’avère peu pratique, voire inenvisageable pour l’entreprise.
Par Eric Helmer, directeur technique (CTO) chez Rimini Street
