Cybersécurité : patcher, le bon geste à adopter
Si le patching est un moyen de se prémunir contre les cyberattaques, les entreprises rechignent à l'utiliser par craintes de coupures de services et / ou de régressions d'applications. Pourtant, des bonnes pratiques existent pour appliquer des correctifs de façon sécurisée.
Alors que tous les éditeurs déploient sans cesse des correctifs pour prévenir les cyberattaques, combien d’entreprises se font pirater chaque année ? Pourquoi ne déploient-elles pas des correctifs pour éviter la catastrophe ? La raison invoquée est toujours la même : dès lors que l’application ou l’architecture n’est pas prévue pour une résilience totale (avec la possibilité de perdre un ou plusieurs nœuds sans impacts), les coupures de services nécessaires à la mise à jour sont trop complexes car elles nécessitent de planifier l’interruption de services pour réaliser le patching et recetter les régressions possibles sur l’application. Une opération délicate que certaines entreprises préfèrent éluder lorsqu’elles estiment que l’impact sur leur développement est trop important. Et c’est là tout le paradoxe : elles ont peur de patcher par crainte d’impacter l’application tout en gardant un risque, de plus en plus important, d’être piratées par cette négligence consentie.
Comment patcher en limitant les désagréments
Dans le cas d’une plateforme traditionnelle de type IaaS avec des applications trois tiers par exemple, il est recommandé de patcher automatiquement et systématiquement les environnements hors production dès la mise à disposition des correctifs. Ensuite, après avoir validé l’impact des patchs sur les environnements amont, l’entreprise doit en un minimum de temps, moins d’une semaine, appliquer les mises à jour en production. Ce délai doit être encore plus court pour les failles critiques où l’élévation de privilège est possible et l’exposition du service concerné est forte (site web public par exemple).
Dans le cas des nouveaux développements de type DevSecOps, il est possible d’intégrer ces mises à jour au fil des releases via l’automatisation, qui redéploie systématiquement l’environnement dans un contexte complètement patché et sécurisé. Toutefois, la méthode agile et les équipes éponymes privilégient trop souvent la mise à disposition de nouvelles fonctionnalités métiers plutôt que la gestion de la dette technique et la mise à niveau des patchs sur les environnements.
Patching insuffisant, que faire ?
Constituées de micro-services, de composants éphémères ou de compilations sur mesure de logiciels, les infrastructures informatiques des entreprises sont aujourd’hui excessivement complexes. Des éléments de cette architecture s’avèrent alors hors de contrôle du système de patching, fragilisant ainsi tout le SI. Pour réduire les risques d’intrusion, deux possibilités s’offrent aux entreprises.
Il est important de lancer régulièrement des scans de vulnérabilités afin de pouvoir détecter des failles non corrigées ou potentiellement oubliées. Complémentaires du patching, ces outils garantissent une bonne mise à niveau des applications et permettent de gérer les logiciels à patcher manuellement car installés en dehors d’un cadre prévu par les systèmes traditionnels de mises à jour automatiques (application compilée à la main par exemple).
Pour les applications de type cloud native ou dans un cycle de vie orchestré par les concepts DevOps, il devient vital d’intégrer la gestion de la dette technique et des failles de sécurité dans les sprints agiles. C’est une nouveauté pour les développeurs qui ne géraient pas jusqu’à présent ce type d’activité. On parle ici de DevSecOps où la sécurité est intégrée à la plateforme d’intégration continue. Le patching est alors plutôt un redéploiement des environnements avec les dernières mises à jour de sécurité intégrées dès les environnements de développement. Charge aux équipes DevSecOps de s’assurer qu’aucune brique n’a été oubliée dans le plat de spaghetti des micro-services.
En conclusion, quelle que soit l’architecture informatique de l’entreprise, le patching est crucial car il est plus simple d’agir sur un développement quand un patch provoque un effet de bord de type bugs ou coupures de service potentiellement provoqués par un patch, que d’intervenir après l’exploitation d’une faille. Et si d’aventure le patch n’existe pas ou si les failles 0 day ne trouvent pas toujours un correctif immédiat de la part des éditeurs, il est crucial de contrôler et de surveiller son infrastructure en complétant son socle de sécurité avec des solutions de SIEM, WAF, SOC, CERT. Enfin, il est recommandé de se faire accompagner par un expert en cybersécurité pour la mise en œuvre et le management de ces équipements.