Patches : problème technique ou humain ?

Patches : problème technique ou humain ?

patch update

Brenno de Winter, journaliste spécialiste de la sécurité informatique, a récemment fait une remarque remarquable dans un article : l’ampleur du problème de la cybercriminalité n’est pas principalement due aux défauts de l’utilisateur, mais surtout à des logiciels défectueux et vulnérables. De nombreux responsables informatiques devront cligner des yeux à quelques reprises lors de la lecture de l’article paru dans le magazine ICT de mai 2015. Pendant des années, l’adage était : PICNIC (Problem In Chair, Not In Computer). Cet adage ne vaut-il rien ?

A lire en complément : Cegeka propose aux enchères de fréquences 5G en Belgique

Pour ceux qui n’ont pas lu le texte, il est utile de répéter quelques arguments. En octobre 2011, De Winter a organisé  » Lektober « , au cours duquel 700 rapports de fuites de logiciels ont été réalisés. En mars 2015, IBM a publié les résultats d’une étude approfondie de sa propre initiative : elle avait analysé les produits de 2 600 fournisseurs et trouvé pas moins de 9 600 fuites dans ces produits. En 2014, un chercheur a découvert des milliers de fuites dans les applications de la boutique Google Play Store.

Ces chiffres sont horrifiants. La recommandation de l’auteur aux développeurs de développer de meilleurs logiciels est absolument raisonnable. Mais il est illusoire de penser qu’un logiciel intouchable et 100% sécurisé deviendra un jour la norme. Après tout, les logiciels sont le produit de personnes qui commettent des erreurs humaines. Les correctifs resteront donc toujours une réalité. C’est à l’utilisateur de les installer pour équiper son système de la variante de logiciel la moins dangereuse possible.

A lire également : Jeff Bezos, une entreprise de télécommunications par satellite, conclut un partenariat avec Télésat Canada

Il y a beaucoup de discussions au sujet de la mise à jour des réseaux d’entreprise. La théorie, prêchée par les experts en sécurité des TI, suppose que les logiciels ne sont plus sécuritaires lorsqu’il y a des fuites de sécurité. De plus, la rétro-ingénierie rend les systèmes exponentiellement plus dangereux après la sortie d’un correctif qu’avant, jusqu’à ce que le correctif soit appliqué. Les auteurs de logiciels malveillants analysent instantanément les correctifs publiés pour découvrir quel correctif fuit le plus près. Ils trouvent rapidement des moyens d’abuser de la faille de sécurité avec un exploit. Cela fonctionne très bien, parce qu’en pratique, les gens ne veulent pas de correctifs qui comblent les failles de sécurité.

Dans la pratique, il s’agit d’entreprises pour lesquelles le bon fonctionnement des logiciels est une nécessité pour la production. Le concept de  » ne jamais changer un système en marche  » est encore très en vogue. Les patchs ont une mauvaise réputation. Ils apportent souvent des modifications au logiciel, qui ont souvent des conséquences profondes sur le fonctionnement du logiciel. Pour de nombreuses entreprises, la faible probabilité que cette faille de sécurité mène à une infection du réseau est moins grande que la probabilité que l’entreprise s’immobilise pendant une journée

.

BAS PLUS L’état ultime de la cybersécurité

En conséquence, les correctifs ne sont souvent pas exécutés directement ou même jamais. Microsoft est maintenant confronté à cette réalité et va changer radicalement le processus de patch. Avec Windows 10, les correctifs sont d’abord offerts aux consommateurs. Lorsque des millions de consommateurs ont installé un correctif particulier, il est possible de faire une prédiction raisonnablement précise des effets d’un correctif dans un environnement professionnel. Si aucune plainte sérieuse n’est reçue, le correctif est mis à la disposition des utilisateurs professionnels. De cette façon, Microsoft espère stimuler un déploiement rapide des correctifs au sein des réseaux d’entreprise.

Il y a cependant deux objections majeures à ce plan. Premièrement, il prolonge la période pendant laquelle les réseaux d’entreprise sont exponentiellement plus vulnérables en permettant aux auteurs de logiciels malveillants de lancer le processus de rétro-ingénierie avant que le correctif du réseau d’entreprise ne soit disponible. Les entreprises qui ont toujours bien patché sont soudainement désavantagées. Deuxièmement, cela n’encouragera pas les entreprises à appliquer les correctifs maintenant. Le fait que les correctifs ne soient pas déployés dans un délai d’un mois, voire de deux mois, peut être attribué à la crainte de problèmes avec le correctif. Mais le fait qu’un patch ne soit pas déployé avant un an est dû à autre chose. Il est possible de tester un patch sur un système de test en un mois (ou deux) pour exclure les problèmes techniques. De plus, après deux mois, s’il y avait eu des problèmes avec le timbre, cela aurait déjà été clair. D’autres entreprises, qui avaient déployé le timbre entre-temps, se seraient plaintes.

Les opérateurs de systèmes qui contestent ce deuxième point en faisant valoir qu’un déploiement réussi par d’autres entreprises ne les convainc pas de l’efficacité d’un patch parce que leur infrastructure commerciale n’est pas comparable à d’autres réseaux ne seront certainement pas convaincus par une période d’essai pendant laquelle le patch a été utilisé par les consommateurs. La nouvelle tactique de Microsoft n’aura donc aucun effet positif. Seules deux choses peuvent aider : Tout d’abord, les développeurs de logiciels doivent tester leurs correctifs de manière plus approfondie avant de les faire connaître au monde entier pour éliminer les correctifs nuisibles. De plus, les administrateurs système devraient prendre les correctifs plus au sérieux. Chaque entreprise devrait élaborer une politique de correctifs. Créez un environnement de test réaliste et testez les correctifs dans cet environnement pendant plusieurs jours ou plusieurs semaines. Quand il n’y a pas de problème avec un patch : déroulez le ! Si l’adage PICNIC est toujours d’actualité, en tant qu’administrateur réseau, vous n’êtes certainement pas le problème.

Ce billet de blog est fourni par G Data.