Lorsqu’il s’agit de correctifs logiciels, les attentes et la réalité sont souvent deux choses différentes.
L’idée fausse commence par la terminologie même que les entreprises utilisent pour décrire la pratique et les attentes qu’elles y attachent.
TechTarget appelle un correctif « un travail de réparation rapide d’un élément de programmation conçu pour résoudre des problèmes de fonctionnalité, améliorer la sécurité ou ajouter de nouvelles fonctions ». Mais au-delà de la vue d’ensemble, il n’existe pas de définition unique de ce qu’est un patch.
Il s’agit là d’un véritable problème dans le monde des technologies d’entreprise, où les parties prenantes ont tendance à considérer les correctifs comme la solution ultime aux problèmes émergents de performance et de sécurité. Ne pas obtenir de résultats avec la solution qu’une entreprise attendait comme un remède miracle est une chose ; aggraver la situation une fois la poussière retombée en est une autre, bien plus importante.
Les correctifs sont loin d’être la solution miracle que les mégavendeurs voudraient vous faire croire. Ils ne sont qu’un élément d’un processus de sécurité qui doit prendre en compte de nombreux autres facteurs pour que l’entreprise soit pleinement et réellement sûre.
LA TOILE DE FOND : LA SÉCURITÉ ET LA PERFORMANCE SONT PLUS IMPORTANTES QUE JAMAIS
Pour comprendre le problème de la pensée « patch-first », il faut comprendre le paysage dans lequel les responsables informatiques modernes doivent naviguer.
La situation de chaque entreprise est différente, mais deux facteurs sont à la base de nombreux blocages technologiques importants.
Premièrement, les attaques contre la chaîne d’approvisionnement sont devenues une arme de choix pour les cybercriminels. Ils annulent effectivement la capacité de la victime primaire à se défendre directement et peuvent provenir de composants qui constituent certains des systèmes les plus importants de l’entreprise. Une entreprise touchée peut faire tout ce qu’il faut, cocher toutes les cases et appliquer tous les correctifs, et pourtant se retrouver avec un risque et une responsabilité énormes en raison de la cybercriminalité.
Deuxièmement, les logiciels jouant un rôle central dans presque toutes les activités commerciales imaginables, même des problèmes de performance ou des pannes mineures peuvent créer des expériences négatives avec les clients d’un côté du comptoir et une faible productivité pour le personnel de l’autre.
En outre, ces préoccupations peuvent se traduire par une série infinie de conséquences négatives pour l’entreprise, telles que des migrations longues et gourmandes en ressources et des problèmes de sécurité. Il n’est pas étonnant que les acteurs du secteur des technologies de l’information perdent le sommeil et sortent les Tums, alors qu’ils doivent travailler dans un contexte où toutes sortes de choses, à l’intérieur ou à l’extérieur de l’entreprise, peuvent tourner au vinaigre.
UNE PLONGÉE PLUS PROFONDE DANS LES PRÉOCCUPATIONS DES ENTREPRISES EN MATIÈRE DE CYBERSÉCURITÉ
Associez maintenant la notion ci-dessus à une statistique simple, mais très révélatrice : Pas moins de 82 % des violations signalées sont le résultat d’une erreur humaine ou d’une négligence, telle qu’une mauvaise configuration.
En d’autres termes, un pourcentage considérablement élevé de problèmes potentiels peut être résolu avant qu’il ne soit nécessaire d’appliquer des correctifs. Si le serveur X avait été correctement configuré ou si la recrue Y avait décidé de ne pas ouvrir la pièce jointe d’un courriel douteux, seuls 18 % des cyberattaques signalées devraient être signalées.
Un correctif peut techniquement être utilisé pour résoudre des problèmes de sécurité résultant d’oublis de configuration, mais il est loin d’être nécessaire. Les entreprises n’ont tendance à aller aussi loin que dans des circonstances inhabituelles ou à haut risque.
Au contraire, dans l’écrasante majorité des cas, les utilisateurs peuvent gérer les mauvaises configurations par eux-mêmes ou avec l’aide d’une entité non OEM, telle qu’un fournisseur de services de maintenance de logiciels tiers (TPSM).
LES OBJECTIFS DES PATCHS DES MÉGAVENDEURS PEUVENT ALLER À L’ENCONTRE DES BESOINS DE L’ENTREPRISE
Au lieu d’envisager toutes les variables possibles en cas de problème, l’objectif par défaut d’un mégavendeur est le volume. Après tout, remédier au problème pour le plus grand nombre d’utilisateurs possible (avec le moins d’impact possible) est une question de bon sens lorsqu’un fournisseur de logiciels s’adresse à un très grand nombre de clients.
En d’autres termes, le processus standard d’application de correctifs laisse intrinsèquement les clients sur le bord de la route.
Une solution unique telle qu’un correctif ne peut jamais prendre en compte le contexte unique d’une entreprise, mais le contexte technologique est un facteur essentiel de différenciation et un moteur de croissance pour la plupart des entreprises. Un patch OEM développé exclusivement pour un public de masse idéalisé doit, de par sa nature même, éviter les problèmes de déploiement que les entreprises intègrent dans leur fonctionnement de base.
Le correctif qui fonctionne parfaitement pour une installation de base peut casser des éléments clés d’une implémentation modifiée ; le même correctif développé pour des déploiements prêts à l’emploi peut ne pas avoir le même effet positif (ou aucun effet positif) dans un environnement personnalisé.
Tous ces facteurs créent un environnement dans lequel les objectifs fondamentaux d’un équipementier pour corriger un produit donné peuvent ne pas correspondre du tout aux besoins du client ou à son plan de croissance. Mais les correctifs sont présentés comme le principal moyen de résoudre les problèmes, même si un correctif n’est pas nécessaire. Cela peut conduire à des idées fausses et à des problèmes qui pourraient être complètement évités avec une perspective différente.
LES CORRECTIFS ET LES COMPOSANTS TIERS
Revenons un instant sur le problème des attaques contre la chaîne d’approvisionnement dans l’entreprise. Parmi celles-ci, les violations impliquant des bibliothèques et des composants open-source ont augmenté de 650 % rien qu’en 2021, ce qui représente une énorme source d’opportunités pour les cyber-attaquants.
Il est impossible d’obtenir un environnement numérique parfaitement sécurisé. Mais même si une entreprise parvenait à construire un produit impénétrable basé sur un code propriétaire sécurisé à 100 %, dès qu’elle introduit un composant externe, tel qu’une API ou une bibliothèque open-source, sa capacité globale à sécuriser le produit est diminuée.
Et les attaques contre la chaîne d’approvisionnement menées par les cybercriminels sont généralement loin d’être de petite envergure.
En 2021, par exemple, des chercheurs ont mis en évidence une faille de sécurité de 10/10 (« la pire des pires ») dans Log4j, une bibliothèque open-source omniprésente utilisée dans d’innombrables solutions au niveau de l’entreprise et en deçà. L’exploit issu de cette vulnérabilité, connu sous le nom de Log4Shell, a provoqué une onde de choc dans les milieux de la cybersécurité, de la technologie et des affaires lorsqu’il a été découvert.
Dans de nombreuses situations, les mégavendeurs ne vérifient que l’interopérabilité des composants à code source ouvert qu’ils utilisent. La sécurité ne peut pas ou ne veut pas être prise en compte pour un grand nombre de raisons. Lorsqu’un problème de sécurité survient dans l’un de ces composants, la responsabilité de la correction tend à être transférée à la personne ou à l’entité qui assure la maintenance du composant.
Dans d’autres cas, un fournisseur peut être contraint – ou choisir – de retarder le déploiement d’un correctif adéquat dans l’attente de plus amples informations ou de l’évolution de la situation. Si ce produit est arrivé en fin de vie, il peut s’avérer peu ou pas rentable pour le fournisseur de résoudre les problèmes liés à ses composants tiers.
Cela signifie qu’une entreprise peut ne pas savoir d’où vient un correctif, qui en sera responsable en dernier ressort ou quand il arrivera dans le pipeline. Et comme le montre le célèbre webcomic XKCD, il en résulte des situations où des pannes de composants de niche peuvent avoir des conséquences technologiques considérables.
Cela peut même créer des situations dans lesquelles les clients ne savent pas si les systèmes dont ils dépendent sont vulnérables, ni ce qu’ils doivent faire ensuite. Les instructions et la documentation relatives aux composants open-source sont notoirement rares ; si l’on ajoute à cela les problèmes évoqués ci-dessus, il ne manque pas de moyens pour que le processus de correction standard laisse des clients valables sur le carreau.
COMMENT LES FOURNISSEURS TIERS DE SERVICES DE MAINTENANCE LOGICIELLE MODIFIENT L’APPROCHE « PATCH-FIRST » (CORRECTIFS D’ABORD)
En revanche, les fournisseurs de TPSM veillent à ce que les choses fonctionnent, quels que soient les problèmes rencontrés.
Dans certains cas, la solution rendue peut être un véritable patch. Lorsque des problèmes surviennent dans le code des composants open-source, par exemple, des modifications du code peuvent être mises en œuvre.
Dans d’autres cas, le fournisseur de TPSM peut s’associer à des services de sécurité externes pour obtenir une vision plus complète de la santé du système. En conservant une liste de définitions constamment mises à jour et en les comparant au parc de logiciels du client, l’entreprise peut fournir une vue d’ensemble qui se concentre principalement sur la sécurité du parc en allant au-delà des murs OEM clairement définis.
Les pratiques qui prennent activement en compte et renforcent la sécurité de l’ensemble du système, définies au sens large comme le « durcissement« , l’emportent sur les correctifs isolés en termes de perspectives de sécurité globale. Elles renforcent la capacité de l’entreprise à travailler dans son propre intérêt, car elles prennent en compte le contexte unique de l’entreprise. Et, ce qui est peut-être le plus important, ils permettent à l’entreprise de rester technologiquement proactive, en la libérant de la réactivité inhérente au processus d’application des correctifs.
Les logiciels sont omniprésents dans les entreprises. Lorsqu’il s’agit de résoudre des problèmes qui touchent certains des systèmes les plus cruciaux d’une entreprise, qu’est-ce qui est le plus important – cocher une case indiquant que vous êtes en sécurité ou atteindre un niveau de sécurité holistique qui tient compte de la santé et du fonctionnement de l’ensemble de votre système ?
Alors que la pile technologique moyenne s’éloigne de la pensée conventionnelle néfaste, il est grand temps que l’industrie dans son ensemble reconsidère ce que sont les correctifs, ce qu’ils font, et leur rôle douteux en tant que meilleur moyen de résoudre les problèmes logiciels.
