Le DevOps ne suffit plus face aux impératifs de sécurisation des développements. Mais réussir sa transition vers le DevSecOps implique de réévaluer le rôle et la responsabilité des équipes de sécurité et de développement. Pour Nabil Bousselham, architecte de solutions chez Veracode, « ce changement de culture soulève un véritable défi, puisque la plupart des professionnels de la sécurité n’ont jamais travaillé aux côtés des équipes de développement. Or, la clé du bon fonctionnement du DevSecOps réside dans la capacité de ces deux parties à travailler ensemble. »
Selon une étude menée en France, au Royaume-Uni et en Allemagne par le cabinet CensusWide pour MongoDB, les développeurs (92 %) et les décideurs (88 %) nous rassurent sur le fait qu’ils prennent toutes les précautions nécessaires lors de l’élaboration de nouvelles applications. De plus, tous s’accordent à dire que la sécurité des données est leur préoccupation principale lors de la fourniture de nouveaux logiciels, et ce pour 53 % des décideurs informatiques et 47 % des développeurs. Cependant, ce consensus disparaît lorsqu’il s’agit d’écrire un logiciel.
Pour Joe Drumgoole, Director of Developer Advocacy chez MongoDB, « c’est parce que l’équilibrage des priorités fait défaut : lorsque nous avons demandé aux développeurs quels étaient les principaux responsables de la sécurisation d’une application, seuls 29 % se sont cités, tandis que les autres désignaient les spécialistes sécurité (22 %), les chefs d’entreprise ayant présenté le projet (18 %), l’équipe d’exploitation (16 %) et même des membres de la sécurité qu’ils ne connaissaient pas (14 %). » Un résultat très comparable à celui des DSI. La majorité d’entre eux (28 %) pensent qu’un spécialiste sécurité porte l’essentiel des responsabilités. Ils sont par ailleurs 21 % à estimer que ce sont les développeurs.
« L’agilité, les microservices et le DevOps sont tous trois des disciplines qui ont beaucoup fait pour accélérer le rythme auquel les logiciels peuvent s’adapter à l’évolution des besoins de l’entreprise. Comment faire pour intégrer la sécurité à l’ensemble, et ne pas être obligé de l’ajouter en dernière minute, dans la précipitation et de manière bâclée ? DevSecOps est la réponse », assure Joe Drumgoole, pour qui « le processus DevSecOps n’aura rien d’évident au départ. Il nécessitera à la fois un changement de culture et une évolution des compétences. Autrement : du travail et de la patience. »
Adopter une stratégie DevSecOps repose sur six phases, selon le cabinet d’analystes Securosis.
- La phase de définition de l’architecture
La première étape consiste à analyser en profondeur l’architecture de sécurité de l’entreprise pour déterminer comment les applications fonctionnent et communiquent. Sur la base de cette analyse, les entreprises peuvent fixer de nouvelles normes opérationnelles contraignantes. Parmi elles, les exigences minimales pour les tests de sécurité et des délais fixes pour le dépannage. Elles peuvent également décider des tests de sécurité à effectuer et des mesures souhaitées afin d’en déterminer l’efficacité. - La phase de conception
L’objectif principal de cette étape est de garantir la sécurité des environnements de développement et de test. Cela nécessite des contrôles d’accès stricts pour les pipelines CI/CD (intégration continue, déploiement continu) et une surveillance supplémentaire pour les scripts en arrière-plan. Les développeurs doivent également être formés aux menaces courantes. - La phase de développement
Lorsque les prérequis sont en place, un point central peut alors être abordé : l’automatisation des tests. Pour ce faire, les développeurs ont besoin de référentiels sécurisés. Les entreprises doivent ainsi avoir accès à des bibliothèques open source sécurisées et partagées en interne. Avec une combinaison d’outils d’analyse et de scripts, les responsables peuvent s’assurer que les développeurs ne travaillent qu’avec les versions publiées. Les entreprises devraient également établir des tests de sécurité des applications interactives (IAST). Cette méthode peut être utilisée pour identifier les faiblesses de l’exécution avant qu’un code ne soit produit. - La phase de test
Conformément à l’approche « Shift Left », les tests doivent être lancés le plus tôt possible dans le cycle de vie du logiciel. Il va sans dire que les entreprises veulent trouver des bogues dans leurs logiciels avant les criminels. De plus, les environnements de tests doivent être contrôlés en permanence pour garantir leur efficacité. Grâce à divers tests effectués en parallèle, des méthodes peuvent être identifiées pour ralentir le système et le remplacer par des méthodes plus efficaces. - La phase de pré-déploiement
Il s’agit désormais de combiner sécurité et vitesse. À cette fin, les entreprises ont recours aux services cloud à la demande. Les environnements de production doivent également être protégés contre les fuites de données en utilisant des outils tels que le masquage des données ou la tokenisation, qui garantissent que les développeurs disposent de toutes les données de test, mais sans avoir accès aux informations sensibles. - La phase de déploiement
La dernière phase consiste à laisser les bulles de test individuelles croître afin de déterminer si le code qui fonctionnait avant le déploiement s’exécute également pendant le déploiement. Si le déploiement doit ensuite être étendu, les entreprises peuvent avoir recours à trois méthodes :
- Un déploiement bleu-vert ou rouge-noir : l’ancien et le nouveau code s’exécutent en parallèle sur leurs propres serveurs. Si des erreurs se produisent, les équilibreurs de charge reviennent à l’ancien code.
- Le test des canaris : les sessions individuelles sont converties en nouveau code. Si des erreurs sont découvertes, le code correspondant est retiré et les problèmes sont résolus.
- Le balisage de fonctionnalités : de nouveaux éléments de code peuvent être activés et désactivés à l’aide du balisage de fonctionnalités. Si des erreurs sont identifiées dans une nouvelle section de code, les développeurs peuvent désactiver la fonctionnalité jusqu’à ce que le problème soit résolu.
Les budgets sécurité comme variable d’ajustement dans les entreprises
Selon l’étude Mips (Menaces informatiques et pratiques de sécurité), menée par le Clusif auprès de 350 entreprises de plus de 100 salariés, 16 % des entreprises ont vu, en 2019, leur budget cybersécurité progresser fortement (de plus de 10 %), 23 % ont enregistré une hausse moyenne (moins de 10 %). Dans la majorité des entreprises 43 %), les budgets sont restés constants. C’est dans le secteur de la banque-assurances que l’on observe les plus fortes progressions budgétaires, avec une hausse de plus de 10 % pour une entreprise sur quatre. Globalement, note le Clusif, « la sécurité de l’information reste une variable d’ajustement : 56 % des budgets sont entièrement remis en cause chaque année, seuls 8 % sont « sanctuarisés ».
Les cinq principes du DevSecOps
- Miser sur l’intégration
La sécurité doit être intégrée. Envisager tous les impacts, y compris négatifs, qu’une nouvelle fonctionnalité peut par inadvertance avoir, au lieu de se focaliser sur son impact positif. - Se montrer spécifique
Déterminer les besoins et les objectifs de l’organisation et choisir les solutions adaptées à la situation. Il n’existe pas de solution universelle. - Adopter une approche axée sur les personnes
Appliquer les principes de sécurité à chaque étape et à chaque collaborateur, y compris les développeurs. Il s’agit d’un sport d’équipe où les compétences et la culture comptent à parts égales. - Partager les informations
Une collaboration ouverte est essentielle dans DevSecOps. Partager, apprendre et progresser constamment en communiquant en interne pour atteindre vos objectifs. - Être ambitieux
Ne pas mettre les ambitions en sourdine. De nombreuses plateformes cloud offrent aujourd’hui des contrôles de sécurité intégrés pour toutes les données.
Source : MongoDB.
Équipes Devops : quels KPIs pour mesurer la performance ?
Selon les analystes d’IDC, dix KPIs sont principalement utilisés par les entreprises pour mesurer la performance des équipes en charge de l’approche DevOps (par ordre d’importance) :
- La robustesse en matière de sécurité.
- La satisfaction client.
- La disponibilité/fiabilité du service.
- Le Time to Market.
- Le rythme des déploiements.
- Les bénéfices pour l’entreprise (revenus, clients, image…).
- Les baisse de coûts techniques.
- Le travail collaboratif et la responsabilisation des équipes.
- Les délais.
- Le taux d’erreurs dans le code.
Source : IDC France.
Des conflits de priorités
Une enquête d’IDC et de Devoteam, publiée en juin 2020, révèle que bien que la plupart des organisations s’accordent sur les bienfaits de la sécurité « by design », dans la réalité, peu l’ont véritablement mise en pratique. Lorsqu’il s’agit de nouveaux projets et initiatives, la sécurité reste une pensée après coup pour plus d’un tiers des organisations. La sécurité « by design » est utilisée à tous les niveaux de l’entreprise dans seulement 13 % des organisations, même si près de la moitié d’entre elles (49,8 %) l’adoptent de manière ponctuelle ou au cas par cas. L’enquête révèle également en effet que si 92,2 % des organisations s’appuient sur une analyse de risques pour orienter les décisions d’investissements. Et si 81,4 % d’entre elles estiment que leur approche de la cybersécurité est déjà alignée sur une politique de gestion des risques, seules 26 % des organisations prennent en compte la cybersécurité dès la planification de toute nouvelle initiative business. Les auteurs de l’étude soulignent que « les caractéristiques intrinsèques des métiers et l’essence même des objectifs liés à chaque fonction rendent l’équation “Risques versus Agilité” difficile à résoudre. »