Le processus DevSecOps

Différentes pratiques doivent être intégrées à l’environnement DevSecOps et aux étapes stratégiques du pipeline. Les processus définis pour ces pratiques doivent garantir que la sécurité est intégrée au développement de manière à donner les moyens d’agir aux développeurs, sans entraver les déploiements à cadence élevée.

Réduire les frictions dans la livraison

Un concept né du succès de Netflix et adopté comme stratégie pour instaurer une culture DevSecOps est celui de la « voie balisée » (Paved Road). Il consiste à créer un parcours fluide permettant aux logiciels de passer de l’idée à la production. Toute décision susceptible d’avoir un effet sur les processus de livraison doit donc tenir compte de sa capacité à aider les développeurs ou, au contraire, à freiner la livraison. Il faut réduire au minimum ces obstacles, voire les éviter complètement.

Un aspect essentiel de la mise en place d’une culture DevSecOps consiste à réduire les frictions entre les équipes en cultivant l’empathie.

Pour adopter cette approche, il faut rallier de nombreuses équipes de l’organisation, mais tout commence au niveau de la direction. Si les dirigeants ne sont pas à l’origine du changement de culture, celui-ci ne se produira tout simplement pas. La direction doit promouvoir les principes de la voie balisée à tous les échelons de l’entreprise. Les valeurs de l’entreprise doivent clairement indiquer que chacun est responsable de livrer rapidement des produits sécurisés aux clients. Il devient alors plus facile de donner la priorité aux pratiques qui allègent la charge liée à la livraison logicielle.

Modélisation des menaces

Le rapport DevSecOps Insights 2020 a révélé que la modélisation des menaces avait un effet très positif sur la confiance globale d’une équipe dans la sécurité de son code. Malheureusement, cette activité est depuis longtemps considérée comme très laborieuse. Ainsi, alors que les organisations adoptent une approche DevOps/DevSecOps, la modélisation des menaces est souvent exclue des pratiques de sécurité mises en œuvre. Pourtant, son impact sur le développement ne doit pas être négligé. 

À la base, la modélisation des menaces consiste à examiner un logiciel en projet pour déterminer ce qui pourrait mal se passer si un attaquant le ciblait. Cette analyse vise à indiquer à l’équipe de développement les contrôles de sécurité à envisager lors de l’implémentation. Traditionnellement, la modélisation des menaces couvre largement l’ensemble du contexte de l’application. Des diagrammes de flux de données, des cadres d’analyse détaillée des menaces et des méthodes prescriptives de hiérarchisation des menaces sont souvent utilisés dans ce processus.

Dans un modèle DevSecOps, toutefois, les méthodes de modélisation des menaces qui mobilisent beaucoup de temps et de ressources sont un frein. Il est cependant possible d’adopter une approche simplifiée dans le pipeline. DevSecOps s’appuie généralement sur des pratiques de développement agile, comme la gestion du backlog produit. Au lieu de concevoir un système entier, on ajoute de nouvelles fonctionnalités et améliorations au backlog sous forme de récits utilisateur. Ces éléments indépendants et faciles à gérer sont essentiels pour permettre un développement à cadence élevée. Les organisations peuvent procéder de la même manière pour la modélisation des menaces.

Au lieu de considérer la modélisation des menaces comme un processus à appliquer à une application monolithique, il est possible d’intégrer des pratiques simples au backlog. Lors de la rédaction d’un nouveau récit utilisateur, celui-ci doit également inclure une brève description des menaces qu’il introduit ou affecte. Les fonctionnalités ou données sensibles concernées doivent être identifiées. Grâce à ces informations mises à la disposition des développeurs dans le backlog, la modélisation des menaces remplit son rôle tout en pouvant accélérer le développement de chaque récit.

Gestion des versions, métadonnées et orchestration

Dans un monde automatisé, le changement est la seule constante, et il doit être cohérent et traçable. Pour suivre tous les changements, DevSecOps doit garantir une gestion des versions adéquate et immuable. Chaque action doit être versionnée, comme le code, afin de permettre une restauration rapide. Une fois converties en métadonnées, les équipes opérationnelles peuvent suivre efficacement les changements et les mesurer.

Les logiciels d’orchestration ne permettent pas seulement de déployer l’infrastructure de manière reproductible : ils fournissent également une grande quantité de métadonnées sur chaque tâche. Ces métadonnées peuvent ensuite être utilisées par le logiciel d’orchestration lui-même, mais aussi comme source faisant autorité pour les outils intégrés. Associé à la gestion des versions, le logiciel d’orchestration devient une puissante source d’information pour toutes les équipes opérationnelles.

Conformité

La mise en œuvre d’initiatives de conformité ne doit pas nécessairement se résumer à un exercice sur papier. Les organisations peuvent plutôt créer des métadonnées représentant les exigences de conformité et les intégrer directement à leurs ressources. Elles peuvent aussi automatiser les règles de sécurité en étiquetant les ressources, afin de mettre en œuvre l’architecture de sécurité souhaitée, par exemple le zonage.

Cette approche permet d’assurer la conformité à grande échelle. Par exemple, elle peut concrétiser la capacité à répondre à une violation dans les 72 heures, conformément aux nouvelles règles du RGPD. En intégrant les exigences de conformité au code dans DevSecOps, le processus de développement devient un levier pour le programme de conformité.

Architecture de sécurité

L’architecture de sécurité repose sur un ensemble de principes propres à chaque entreprise. Ces principes dépendent du type de données traitées, mais un ensemble de principes généraux peut orienter la livraison logicielle vers des pratiques plus sécurisées. Les organisations qui adoptent un modèle DevSecOps doivent mettre en place des processus permettant de définir et de mettre à jour en continu ces architectures. Elles peuvent ainsi développer plus rapidement et en toute sécurité.

Intégrer ces principes à la culture DevSecOps et les rendre accessibles dans le backlog permet aux responsables produit d’inclure facilement la sécurité dans leur plan et l’architecture correspondante. Si un écart est nécessaire en raison d’un processus métier ou d’un manque de ressources, il est consigné et le risque associé est pris en compte. Ces écarts peuvent ensuite être traités comme n’importe quel autre bug et suivis jusqu’à leur résolution.

Gestion des incidents

La réponse aux incidents de sécurité ne doit pas être improvisée ni laissée au hasard. Il est essentiel de préparer à l’avance les workflows, les plans d’action, les playbooks et les guides d’exploitation. Cela garantit une réponse cohérente, reproductible et mesurable. La gestion des incidents doit s’appuyer sur les métadonnées pour simplifier le processus et faire évoluer les indicateurs afin de mettre en évidence le temps nécessaire au redéploiement d’une ressource compromise. Les processus définis dans les playbooks doivent couvrir tous les types d’incidents. DevSecOps réunissant différentes fonctions, les processus qui le mettent en œuvre doivent en faire autant. La gestion des incidents doit donc s’appuyer sur un niveau d’abstraction permettant de traiter les incidents opérationnels et de sécurité selon le même cadre. C’est une autre étape efficace pour renforcer la culture de responsabilité partagée, essentielle à DevSecOps.

Une fois formalisés, les playbooks peuvent être intégrés au pipeline CI/CD afin d’automatiser leur exécution. Dans un environnement DevSecOps, la recherche proactive et préventive des menaces, ainsi que la détection et la réponse continues aux menaces et aux vulnérabilités, réduisent le nombre d’incidents majeurs et augmentent celui des mesures d’atténuation. Les tests d’intrusion, les exercices de red team et les programmes de bug bounty offrent une couche supplémentaire de protection contre le risque de violation. Même si la détection continue est bénéfique, les organisations doivent éviter la fatigue liée aux alertes. Il faut pour cela mettre en place des boucles de rétroaction qui favorisent l’amélioration continue de la surveillance et une automatisation accrue de l’évaluation et du traitement des alertes.

Évaluations de sécurité proactives

Quel que soit le degré de maturité de la méthodologie DevSecOps d’une organisation, l’identification active des vulnérabilités reste nécessaire.  Le terme « test d’intrusion » désigne souvent les efforts déployés pour identifier de manière exhaustive les vulnérabilités dans un périmètre donné. La red team se distingue par son objectif, généralement plus ciblé : reproduire les motivations et les tactiques d’un attaquant réel. Par exemple, un test d’intrusion peut chercher à repérer toutes les pages d’une application vulnérables à une injection SQL, tandis qu’une évaluation red team n’en identifierait peut-être qu’une ou deux, puis exploiterait ces vulnérabilités pour attaquer l’application plus avant.

Tests d’intrusion

Les tests d’intrusion constituent souvent la première étape de maturité de la gestion des vulnérabilités dans les applications. Ils visent à identifier les zones d’une application susceptibles d’être vulnérables à une forme d’attaque. Idéalement, ces évaluations donnent une visibilité complète sur la posture de sécurité globale et permettent de corriger les vulnérabilités à risque. Toutefois, obtenir une vue exhaustive des vulnérabilités d’une application peut prendre beaucoup de temps. Dans DevSecOps, bien que ces tests constituent un élément essentiel de l’hygiène de sécurité, ils sont généralement réalisés après la mise en production.

Red team

Les évaluations red team sont généralement menées dans les organisations très matures. Elles constituent une étape supplémentaire après les tests d’intrusion. Dans une approche red team, l’objectif n’est pas d’identifier le plus grand nombre possible de vulnérabilités. L’approche est plutôt axée sur des objectifs et s’apparente davantage à celle d’un attaquant. Le périmètre ne se limite généralement pas à une seule application : il couvre l’ensemble des systèmes de l’environnement. L’organisation peut ainsi comprendre comment des vulnérabilités dans plusieurs systèmes peuvent être combinées pour mener une attaque et mieux cerner l’impact potentiel d’une attaque réussie. Ces évaluations nécessitent donc des compétences plus pointues et plus variées que les tests d’intrusion classiques. À mesure que son approche DevSecOps gagne en maturité, une entreprise peut envisager d’intégrer des missions red team à ses pratiques régulières d’hygiène de sécurité.

Programmes de bug bounty

Les programmes de bug bounty ont également beaucoup fait parler d’eux ces dernières années, notamment grâce aux programmes participatifs désormais accessibles. Ils définissent le périmètre, les exigences et les modalités de signalement auxquels les hackers externes doivent se conformer pour tenter d’identifier les vulnérabilités dans l’environnement d’une organisation. En échange du respect de ces règles, les hackers reçoivent une « prime » pour les vulnérabilités qu’ils signalent à l’organisation.

Les programmes de bug bounty sont un excellent moyen d’encourager des acteurs externes à divulguer les vulnérabilités de manière responsable et constituent une couche supplémentaire de détection. Ils ne doivent toutefois pas remplacer les tests d’intrusion. Les chercheurs en sécurité qui participent à ces programmes n’agissent généralement pas dans le meilleur intérêt de l’organisation. Ils ne cherchent pas à identifier les vulnérabilités de manière exhaustive et recherchent le plus souvent les failles les plus critiques, celles qui leur rapporteront la prime la plus élevée.

Renseignements sur les menaces

À mesure que les composants de l’environnement sont définis et documentés sous forme de code, la visibilité sur les renseignements sur les menaces s’améliore également. De nombreuses organisations peinent à identifier leurs actifs informatiques de façon à relier efficacement les renseignements sur les menaces reçus aux actifs de leur environnement. En veillant à ce que les processus alimentent les capacités de renseignement sur les menaces avec les métadonnées du pipeline DevSecOps, l’organisation peut s’assurer de recueillir les renseignements pertinents et de les appliquer en fonction des risques, en y apportant une réponse adaptée.