L'inertie de l'entreprise freine l'intégration DevSecOps

Le DevSecOps (Développement/Sécurité/Opérations) est un sujet de plus en plus discuté, car les entreprises ont du mal à relever le défi de l'amélioration en continu de leur infrastructure de cybersécurité.

Maintenant que le premier trimestre 2020 est terminé, avons-nous vraiment fait des progrès dans l'intégration complète entre les fonctions Développement, Opérations et Sécurité dans l'entreprise ?

Le terme DevOps (Développement/Opérations) fut utilisé pour la première fois en 2009 par le consultant IT Patrick Debois. Une dizaine d’années plus tard, le secteur IT évolue en direction du DevSecOps en réponse aux menaces mondiales pesant sur la cybersécurité. En effet, on a compris qu'un effort plus concerté est nécessaire pour limiter efficacement les risques.

L'une des difficultés, c'est que le concept de DevOps n'est pas encore utilisé dans toutes les entreprises, et celles qui ne l'utilisent pas sont d'autant plus hésitantes à ajouter un niveau supplémentaire d'intégration avec les équipes et les systèmes de sécurité. Toute personne qui a travaillé en entreprise sait que l'implémentation d'un changement de culture est difficile, pour ne pas dire plus, et ne se fait pas en une nuit. Et le passage du DevOps au DevSecOps nécessite ce type de changement.

De l'inertie à l'intégration

L'histoire de la fin de vie d'Oracle Java 8 illustre parfaitement la nécessité de mieux intégrer la sécurité dans le développement et les opérations. Traditionnellement, les applications Java étaient développées et livrées, et les inévitables mises à jour de sécurité étaient de la responsabilité de l'équipe Opérations, qui devait mettre à jour l'environnement JRE (Java Runtime Environment) sur chacun des systèmes utilisant l'application concernée. Sans surprise, c'est devenu un combat contre les problèmes de compatibilité, que certaines entreprises ont parfois préféré éviter plutôt que de mettre Java à jour et résoudre les problèmes de sécurité.

Java 10 met fin au combat, en créant une expérience bien plus symbiotique : les composants Runtime sont inclus directement dans l'application Java au fur et à mesure de sa construction. Ce changement contraint l'équipe Développement à devenir propriétaire des mises à jour régulières de l'application pour résoudre les vulnérabilités de sécurité, mais le changement est très lent. Les applications Java 8 sont toujours un élément essentiel dans de nombreuses opérations, même après la fin de vie de la version 8, et les entreprises se tournent maintenant vers OpenJDK et Corretto Java pour continuer avec l'ancien modèle.

C'est là que l'inertie intervient. Les entreprises continuent à utiliser les systèmes d’ancienne version (comme les applications Java 8), et le cycle des problèmes de compatibilité continue à empêcher les mises à jour nécessaires pour résoudre les vulnérabilités de sécurité. Le personnel de sécurité, trop occupé, n'y prête pratiquement aucune attention, car il est passé depuis longtemps à des projets plus importants, comme la protection contre le prochain WannaCry.

Il est possible d'améliorer l'intégration, en donnant plus d'importance au versant Sécurité du DevSecOps. Voici les points à prendre en compte pour passer de l'inertie à l'intégration.

Prenez les choses en main

Les concepts de propriétaire et de responsabilité doivent changer. L'équipe Développement qui a créé un produit donné doit être responsable de la réponse aux besoins futurs de l'application, comme les mises à jour de correctif. L'ancienne approche « On l'a développée, maintenant on la confie à l'équipe Opérations » ne fonctionne pas dans un environnement intégré. L'équipe doit continuer à assumer ses responsabilités pendant la phase Opérations. Fini le jeu de ping-pong pour connaître l'équipe "propriétaire" des mises à jour. Les bugs, les versions correctives et les correctifs sont de la responsabilité de l'équipe DevSecOps.

Suivez le rythme

Grâce aux très nombreuses options technologiques, les entreprises utilisent toute une variété d'outils de développement, de navigateurs et d'outils d'analyse des vulnérabilités. Cela multiplie les difficultés, car l'application traditionnelle des correctifs n'est parfois plus possible. Dans le même temps, faute d'exécuter les mises à jour en temps réel, l'entreprise est vulnérable aux menaces.

Par exemple, Microsoft a sorti la nouvelle version Edge Chromium, qui exploite la structure Open Source Chromium de Google. Cette année, Google a sorti trois versions de Chrome entre les Patch Tuesday de janvier et février. Cela signifie que Microsoft a dû choisir entre intégrer les mises à jour Chromium en temps réel, ou retarder la résolution de vulnérabilités critiques chez ses clients. Autre exemple : si une entreprise utilise un navigateur interne basé sur Chromium, ces mêmes mises à jour doivent être distribuées en mode Push pour protéger les utilisateurs des menaces.

Pensez global pour les corrections

La meilleure façon de réussir l'intégration, c'est de s'assurer que la sécurité est intégrée dès le départ dans les processus Développement et Opérations. Avant de lancer un nouveau produit ou une nouvelle application, l'équipe DevSecOps unifiée connaît tous les composants du produit, tous les fournisseurs qui vont publier des mises à jour pour ces composants et la fréquence prévue pour ces mises à jour. Pour les entreprises qui mettent à jour une application Web ou en SaaS, les mises à jour devraient être faisables assez rapidement.

Pensez d'abord sécurité

Vous êtes pressé de toutes parts pour la mise sur le marché mais, pour les professionnels stratégiques de l'équipe DevSecOps, la réduction des risques passe avant l'impact opérationnel. En effet, ils travaillent dans un contexte où la cyberhygiène reste un problème. Les anciens systèmes ne reçoivent pas correctement les correctifs, et les mises à jour sont effectuées trop tard, voire pas du tout. Pour éviter cela, les entreprises doivent adopter le principe de "la sécurité d'abord", et améliorer la réactivité et l'exhaustivité de l'application des correctifs et mises à jour.

Connaissez vos fournisseurs

Il est indispensable que l'équipe DevSecOps examine soigneusement les mises à jour et correctifs qu'un fournisseur tiers donné va fournir, à quelle fréquence et quels sont les risques si certaines versions ou entreprises ne sont pas couvertes. Dans le cadre de cet examen, identifiez les fournisseurs réactifs face aux risques de sécurité et ceux qui ne le sont pas. Comme de nombreuses entreprises (Microsoft, Oracle, etc.) ont un calendrier de publication différent, l'automatisation des processus DevSecOps peut aider à garantir que les mises à jour sont appliquées en temps réel et améliorer la cyberhygiène.

L'équipe DevSecOps peut commencer à atteindre ses objectifs en tenant compte du facteur humain, et en faisant de la technologie une aide, pas une difficulté supplémentaire. Que les collaborateurs soient dans l'équipe Développement, Opérations ou Sécurité, ils travaillent tous pour la même entreprise. En accentuant l'automatisation des processus, en obtenant une meilleure visibilité de tous les composants concernés et du calendrier de publication des fournisseurs tiers, et en impliquant la sécurité dès le départ dans le développement d'un nouveau produit, vous mettrez en place des mises à jour plus fluides, une meilleure sécurité et une culture de la productivité.