Intégration de la modélisation des menaces à DevOps
Ce billet est rédigé par Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez et Ben Hanson
Introduction
La modélisation des menaces est une méthode de sécurité importante qui permet d'identifier et de hiérarchiser les atténuations des risques les plus importantes pour une application ou un système. Ce document contient quelques réflexions sur la façon dont il est possible d'adopter la modélisation des menaces plus efficacement et efficacement, de l'intégrer à des méthodologies et outils DevOps modernes, et de se concentrer sur la valeur fournie à tous les différents acteurs impliqués dans le cycle de vie du développement logiciel.
Ce document est-il pour vous ?
Ce document est le résultat du travail d'une petite équipe d'experts en sécurité et en modélisation des menaces de Microsoft et intègre des entrées et des idées de certains des experts les plus importants de l'extérieur de Microsoft. Il tente de répondre à une question simple mais urgente : que devons-nous faire pour garantir que le processus de modélisation des menaces que nous utilisons est mis à jour aux exigences modernes imposées par les méthodologies Agile et DevOps, afin que nous fournissions la valeur requise au coût le plus bas ?
Si vous êtes propriétaire de produit, membre d'une équipe de sécurité, ou simplement un développeur qui envisage d'adopter la modélisation des menaces dans le cadre de votre cycle de vie de développement, ce document est destiné à vous.
De même, si vous avez déjà adopté la modélisation des menaces, vous trouverez peut-être des idées pratiques pour améliorer votre processus.
Néanmoins, le document est conçu pour introduire des idées visant à améliorer les processus actuels ou à adopter avec succès la modélisation des menaces dans le cadre de votre processus DevOps. Il n'introduit pas d'outils ou de produits spécifiques, même s'il est notre espoir de voir ces idées implémentées par certains outils ou produits à l'avenir. Par conséquent, vous ne trouverez pas d'annonces de nouveaux outils ou aperçus des fonctionnalités à venir, ici.
Pourquoi la modélisation des menaces est-elle importante ?
La modélisation des menaces est l'une des principales approches de conception de solutions logicielles en toute sécurité. Grâce à la modélisation des menaces, vous analysez un système qui identifie les vecteurs d'attaque et développez des actions pour atténuer les risques apportés par ces attaques. Bien fait, la modélisation des menaces est un excellent composant de tout processus de gestion des risques. Il peut également aider à réduire les coûts en identifiant et en corrigeant les problèmes de conception au début. Une ancienne étude de NIST a estimé le coût de la résolution d'un problème de conception dans le code de production à environ 40 fois plus élevé que la réparation pendant la phase de conception. Il économise également des coûts en raison d'incidents de sécurité pour les problèmes de conception éventuels. Considérez que le rapport sur le coût des violations de données de 2022 d'IBM Security et de l'Institut Ponemon estime le coût moyen d'une violation de données à 4,35 millions de dollars. Pour les méga-violations, impliquant la compromission de plus de 50 millions d'enregistrements, le coût moyen atteint 387M USD !
La modélisation des menaces est la première activité que vous pouvez faire pour sécuriser votre solution, car elle fonctionne sur la conception de la solution. Cette caractéristique rend la pratique de sécurité la plus efficace que vous pouvez appliquer à votre SDLC.
Microsoft a une longue histoire avec la modélisation des menaces. En 1999, deux employés (puis) Microsoft, Loren Kohnfelder et Praerit Garg, ont écrit un document, Les menaces pour nos produits. Ce document a introduit l'approche STRIDE, synonyme du processus de modélisation des menaces Microsoft.
La modélisation des menaces est un processus évolutif
La modélisation des menaces n'est pas un processus statique ; il évolue à mesure que les besoins et les technologies changent.
Les attaques de chaîne d'approvisionnement comme la récente ciblant SolarWinds montrent la nécessité de couvrir avec la modélisation des menaces plus de scénarios que la solution elle-même, y compris le développement et le déploiement.
Les vulnérabilités open source comme la récente pour Log4j ont démontré la nécessité de compléter l'approche actuelle en fonction de l'adoption des outils d'analyse de composition logicielle pour analyser les composants vulnérables en concevant la solution de manière défensive pour limiter son exposition.
L'application de nouvelles technologies comme Machine Apprentissage introduit de nouveaux vecteurs d'attaque qui doivent être compris et contrôlés. Considérez, par exemple, la possibilité de jouer des sons malveillants fabriqués inaudibles par les oreilles humaines pour provoquer l'exécution de commandes par les services IA, comme indiqué dans https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.
Chez Microsoft, différents groupes de produits pratiquent différentes variantes de modélisation des menaces en fonction de leurs exigences de sécurité spécifiques. Chaque variante vise à garantir un niveau adéquat d'assurance de sécurité aux scénarios auquel elle est appliquée, mais ce qui signifie « adéquat » signifie des modifications en fonction du contexte spécifique.
Par exemple, la sécurisation de Windows diffère de la sécurisation d'Azure Cognitive Services, car ces systèmes ont des tailles et des caractéristiques très différentes. Un aspect clé de la modélisation des menaces est d'équilibrer son coût par rapport à la tolérance de risque pour une application. Bien que cela puisse entraîner la décision d'éviter complètement la modélisation des menaces pour certains scénarios, il est si efficace lorsqu'il est correctement fait que nous vous recommandons uniquement de l'adopter pour n'importe quelle initiative informatique, y compris les projets de développement de logiciels et de déploiement d'infrastructure.
L'importance de se concentrer sur le retour sur investissement
Les deux dernières années ont connu une augmentation constante de l'intérêt dans la modélisation des menaces comme un processus de développement logiciel clé. Cet intérêt est dû à l'augmentation exponentielle des attaques sur les infrastructures et les solutions. Les initiatives telles que la norme minimale recommandée par le NIST pour le fournisseur ou la vérification du code pour les développeurs et le manifeste de modélisation des menaces ont encore augmenté la demande jusqu'à ce que les approches actuelles aient montré certaines limites. Par exemple, les résultats de la modélisation des menaces dépendent fortement du processus adopté et de la personne qui effectue le modèle de menace. Par conséquent, il y a une préoccupation quant à l'obtention d'une meilleure qualité de l'expérience.
Mais qu'est-ce que la qualité signifie pour la modélisation des menaces ? Pour nous, un modèle de menace qualité doit avoir les caractéristiques suivantes :
Il doit identifier les atténuations exploitables, les activités que vous pouvez faire pour réduire les pertes potentielles résultant d'attaques. Actionnable signifie que ces atténuations doivent être bien définies, ce qui signifie que vous obtenez suffisamment d'informations pour les implémenter, puis tester l'implémentation. Cela signifie également qu'ils doivent être fournis pour permettre une consommation facile de l'équipe de développement. Avec DevOps et Agile, cela signifie qu'il existe un chemin facile d'importation des atténuations dans le backlog.
Pour chaque atténuation, elle doit identifier son état. Certaines atténuations sont nouvelles, tandis que d'autres sont déjà existantes. Le modèle de menace doit reconnaître ce qui existe déjà et se concentrer sur le risque actuel pour identifier comment améliorer la situation.
Il doit identifier clairement pourquoi chaque atténuation est requise en la liant aux menaces respectives.
De plus, les atténuations ont une force relative pour chaque menace. Par exemple, le chiffrement TLS peut être une atténuation forte du risque de divulgation des données en transit et, en même temps, il peut s'agir d'une atténuation presque complète du risque d'usurpation du serveur.
Les menaces doivent être crédibles, bien définies et spécifiques à la solution.
Les menaces doivent avoir une gravité associée, qui doit tenir compte à la fois de leur probabilité et de l'impact. La gravité doit être raisonnable et idéalement non biaisée.
Il devrait être possible d'obtenir une vue complète des risques et de la façon dont ils peuvent être traités. Ce point de vue contribuerait à favoriser une conversation significative avec l'équipe de sécurité et avec les décideurs de l'entreprise, et il nous permettrait de masquer les complexités inutiles.
Cette liste présente déjà un concept important : la modélisation des menaces peut fournir une valeur à de nombreux rôles impliqués pendant le cycle de vie du logiciel, mais chaque rôle a des besoins et des exigences différents. Par exemple, les développeurs doivent recevoir des informations claires sur ce qu'ils doivent implémenter et sur la façon de vérifier que ce qu'ils ont implémenté se comporte comme prévu. D'autre part, l'équipe de sécurité s'inquiète généralement de la sécurité globale de l'écosystème d'infrastructures et d'applications détenues par l'organisation ; par conséquent, ils doivent recevoir des informations permettant de décider si le système dans l'étendue est suffisamment sécurisé et satisfait à ses exigences de conformité. Enfin, les propriétaires de produits et les décideurs d'entreprise doivent comprendre ce qui est nécessaire pour rendre le risque acceptable pour l'organisation.
Ces différents besoins nécessitent de fournir différentes vues sur le modèle de menace, chacun d'entre eux se concentre sur un scénario d'utilisation spécifique.
Un problème typique de modélisation des menaces est que plus il réussit, plus il est difficile pour les rares experts disponibles de couvrir la demande tout en fournissant la haute qualité attendue de cette expérience. Par conséquent, dans certains cas, la qualité peut être affectée négativement. Tout est bon jusqu'à ce que la modélisation des menaces cesse de fournir une valeur significative par rapport à l'investissement. Plus d'un certain nombre d'organisations sont affectées par ce problème. Il y a déjà eu quelques rapports des décideurs d'entreprise qui commencent à interroger la modélisation des menaces, car ils ne fourniraient pas une valeur significative pour le coût.
Avec valeur, nous faisons référence à la valeur métier, qui est la possibilité de fournir les informations nécessaires pour comprendre les risques représentés par le système dans l'étendue et conduire à un processus de décision significatif pour sélectionner les mesures d'atténuation appropriées à mettre en œuvre. En outre, la valeur est également liée à la fourniture des informations correctes aux développeurs et aux testeurs. Enfin, la valeur est liée à la communication du risque résiduel avec toutes les parties concernées. Par exemple, nous pouvons mesurer la valeur en mesurant l'impact du processus de modélisation des menaces. Supposons que nous mesurons le risque global de la solution en affectant un nombre à la gravité identifiée à chaque menace. Dans ce cas, nous nous attendons à ce que le risque global diminue au fil du temps par effet du modèle de menace. Si le risque global reste constant ou augmente, nous pouvons avoir un problème. Plus la diminution est forte, plus l'impact du modèle de menace est élevé. Bien sûr, le modèle de menace ne contrôlerait pas les atténuations implémentées. Il incombe au propriétaire du produit de décider de ce qui doit être implémenté. Mais l'avantage de lier l'efficacité du modèle de menace à l'implémentation réelle des atténuations est qu'elle augmente l'impact sur la sécurité réelle de la solution, ce qui réduit le risque que le modèle de menace reste un exercice théorique.
Au lieu de cela, le coût est lié aux activités nécessaires à l'exécution du modèle de menace lui-même, qui est le temps nécessaire par toutes les parties concernées pour produire le modèle de menace et le discuter.
Cela pose la question suivante : pouvons-nous définir un processus de modélisation des menaces axé sur l'optimisation de la valeur métier et la réduction du coût ?
Importance de DevOps
Nous avons déjà mis en évidence l'importance de garantir que la modélisation des menaces est une pratique précieuse intégrée au processus DevOps. Cela signifie que le processus doit être disponible pour tous les membres de l'équipe, généralement en le simplifiant et en l'automatisant. Plus important encore, la modélisation des menaces pour DevOps signifie que nous devons nous assurer que l'expérience est profondément intégrée aux processus DevOps existants.
La modélisation des menaces ne doit pas devenir une autre charge, maisil doit plutôt s’agir d’un atout pour faciliter la collecte et les exigences de sécurité, la conception de solutions sécurisées, l’inclusion d’activités dans l’outil Task &Bug Tracking de choix et l’évaluation du risque résiduel en fonction de l’état actuel et futur de la solution.
Alignement avec DevOps
Nous pouvons utiliser différentes techniques pour aligner la modélisation des menaces avec la pratique devOps actuelle.
Menaces et préventions
Tout d'abord, nous devons concentrer le processus de modélisation des menaces sur ce qui doit être fait. Les menaces, qui sont les modèles d'attaque et la façon dont ils peuvent se produire, sont nécessaires pour expliquer pourquoi l'équipe doit implémenter un contrôle de sécurité. Ils sont également un facteur déterminant quand les atténuations doivent être mises en œuvre. Pourtant, l'objectif réel est de déterminer ce qui doit être fait : les atténuations. Par conséquent, l'approche doit mener à l'identification rapide des atténuations requises et doit informer le processus de décision afin qu'il soit plus facile de déterminer ce qu'il faut faire et quand. Le principal livrable de ce processus de décision est d'avoir les atténuations sélectionnées dans le backlog pour les faire partie du processus standard. Dans l’idéal, l’outil de modélisation des menaces et l’outil de suivi des bogues de tâche et de suivi des bogues doivent être synchronisés pour refléter les mises à jour de l’état d’atténuation dans le modèle de menace. Cela permettrait de réviser dynamiquement et automatiquement le risque résiduel, ce qui est essentiel pour soutenir les décisions éclairées dans le cadre des chorégraphies habituelles de la méthodologie Agile adoptée, comme la réunion de planification sprint.
Que pouvez-vous faire aujourd'hui ?
En tant qu’expert en modélisation des menaces, vous devez vous assurer d’implémenter un processus de modélisation des menaces capable d’identifier clairement les actions et de les inclure dans votre tâche et suivi des bogues de votre choix. Il est possible d'adopter l'un des nombreux outils de modélisation des menaces capables d'automatiser ce processus.
En tant que développeur, vous devez vous concentrer sur les contrôles de sécurité identifiés comme nécessaires. Le processus doit être conçu pour vous les fournir de la même façon que vous vous attendez à recevoir toute autre activité.
Fonctionnalités, récits utilisateur et tâches
Nous avons déjà déclaré que les atténuations représentent l'artefact le plus important produit par le modèle de menace concernant l'intégration de DevOps. Par conséquent, il est important de définir clairement le type d’objets créés à partir de ces atténuations sur l’outil Task &Bug Tracking de choix. Certaines atténuations peuvent durer plus d'un sprint. Par conséquent, il peut être préférable de les créer en tant que fonctionnalités. Mais beaucoup sont plus faciles et peuvent être implémentés dans un sprint unique ; ainsi, il serait possible de les représenter en tant que récits utilisateur ou tâches. Bien que la génération de différents types d'éléments de travail puisse être possible, cela peut entraîner un processus compliqué qui peut entraîner des erreurs et une confusion. Pour cette raison, il semble plus pratique de coller avec un seul type d'élément de travail. Étant donné que les atténuations peuvent être considérées comme des enfants d'histoires utilisateur, vous pouvez envisager de les représenter en tant que tâches, ce qui implique de détendre l'exigence d'exécution du type d'élément de travail indiqué dans un sprint unique.
Que pouvez-vous faire aujourd'hui ?
Vérifiez que les atténuations identifiées par le modèle de menace sont représentées dans le backlog. Identifiez un moyen de les représenter clairement.
Récits utilisateur
Les atténuations ne sont pas les seuls artefacts d’un modèle de menace, qui peuvent et doivent être alignés sur ce que vous avez dans votre outil Task &Bug Tracking. Par exemple, vous pouvez également représenter des menaces. Cet objectif pourrait être atteint en étendant les récits utilisateur par le biais de l'ajout d'une clause SANS à l'habituel « En tant que [qui suis-je] je veux [ce que je veux] afin que je puisse [faire quelque chose]. » Par exemple : « En tant qu'utilisateur, je veux payer avec mon crédit carte afin que je puisse acheter des biens, SANS avoir mon crédit carte volé des données volées ». La clause SANS peut être mappée à une ou plusieurs menaces et parfois autorisée à exprimer les exigences de sécurité. En garantissant que cet alignement entre les menaces et les clauses SANS est rendu explicite dans le modèle de menace, nous pouvons nous assurer que les risques possibles sont reflétés et pris en charge par l'équipe, car ils sont inclus dans les récits utilisateur. Vous pouvez également utiliser cette relation pour mapper chaque exigence de sécurité identifiée dans le cadre des récits utilisateur à au moins une menace.
Bon à savoir
La clause SANS n'est pas une idée originale de l'équipe qui a produit cette page. Nous ne sommes pas sûrs de qui l'a introduit d'abord, mais nous sommes reconnaissants à quiconque est venu avec cette idée.
Figure 1 : alignement des exigences
Par exemple, l'image précédente montre les situations suivantes :
La menace A est liée à l'article 1 via la clause SANS 1.
La menace B est liée à l'article 2 via la clause SANS 2.
La menace B est également liée à l'article 3 de l'utilisateur. Mais l'article utilisateur 3 n'est affecté à aucune clause SANS. Pourquoi ? Il représente une anomalie potentielle que vous devez examiner.
La menace B est également liée à l'article 1 de l'utilisateur. Il n'est pas encore clair si nous devrions autoriser l'utilisation de récits utilisateur liés à plusieurs menaces.
La menace C est liée à l'article 4 de l'utilisateur, associé à SANS 3 et 4. Il n'est pas encore clair si nous devrions autoriser plusieurs clauses SANS.
La menace D n'est liée à aucune histoire utilisateur. Sommes-nous absents d'une histoire utilisateur ou d'une clause SANS ?
L'article 5 de l'utilisateur est lié à une clause SANS, mais il n'a aucune menace associée. Manque-t-on une menace ou simplement un lien entre un récit utilisateur et une menace ?
Nous identifions rarement les exigences de sécurité dans le cadre du modèle de menace. Par conséquent, la clause SANS introduit la possibilité d'intégrer davantage l'expérience en étendant les modèles de menace avec les exigences de sécurité et en les liant aux récits utilisateur associés. Cette approche jouerait un rôle important dans l'évolution de l'expérience de modélisation des menaces à partir d'une évaluation répétée au fil du temps pour devenir l'outil de conception de la sécurité pour DevOps.
Que pouvez-vous faire aujourd'hui ?
Commencez à utiliser la clause SANS dans vos récits utilisateur.
Mappez les menaces que vous identifiez aux récits utilisateur avec des clauses SANS, et inversement.
Une expérience intégrée
Vous pouvez appliquer la même idée à d'autres scénarios. Par exemple, le modèle de menace peut lier les exigences de sécurité aux artefacts à l’intérieur du modèle de menace lui-même, comme les menaces et les atténuations, ainsi que celles de l’outil Suivi des bogues et suivi des bogues. Par exemple, la nécessité d’implémenter la surveillance pour identifier les attaques en cours doit être mappée à toutes ces atténuations liées à la surveillance, puis aux artefacts correspondants dans l’outil Task &Bug Tracking. Par conséquent, il serait facile d'identifier les situations où une exigence de sécurité n'est pas réalisée : en fait, elle ne serait liée à rien.
Vous pouvez utiliser les mêmes liens entre les artefacts de l’outil Task &Bug Tracking et les menaces et les atténuations identifiées par le modèle de menace pour faciliter la hiérarchisation des activités de sécurité. La sécurité est généralement implémentée en dernier, parfois pour résoudre les vulnérabilités réactives identifiées par un outil ou un test d'intrusion. Au contraire, il serait plus efficace d'implémenter les atténuations ainsi que les récits ou fonctionnalités utilisateur associés. Pourquoi attendre d'implémenter les contrôles pour sécuriser les détails du crédit carte quand vous devez les implémenter avec les fonctions de paiement associées ? Le modèle de menace doit mettre en évidence ces relations et fournir un moyen simple de déterminer lors de l'implémentation de certaines fonctionnalités pendant un Sprint nécessite l'implémentation de certaines fonctionnalités de sécurité associées. Ces informations peuvent être utilisées, par exemple, lors de la réunion de planification sprint pour avoir une discussion significative et favoriser une hiérarchisation éclairée. Le mécanisme est simple. Supposons que le propriétaire du produit pour un projet sur lequel nous travaillons décide de planifier un récit utilisateur pour le sprint suivant. L'histoire de l'utilisateur a une clause SANS liée à la menace. Le modèle de menace identifie plusieurs atténuations pour la même menace. Par conséquent, nous pouvons immédiatement déduire que nous devrions hiérarchiser une ou plusieurs des atténuations identifiées.
Figure 2 : hiérarchisation de la sécurité
Par exemple, dans l'image ci-dessus, nous pouvons voir que l'article 1 de l'utilisateur est lié à la menace 1, qui à son tour est lié aux atténuations A et B. Par conséquent, nous devrions également envisager d'implémenter une ou les deux mesures d'atténuation.
Que pouvez-vous faire aujourd'hui ?
Lier des récits utilisateur avec des clauses SANS aux éléments de travail correspondant aux atténuations sélectionnées à l'aide du modèle de menace comme référence. Lors de la planification du sprint suivant, veillez à hiérarchiser les activités de sécurité liées lorsque vous implémentez l'un de ces récits utilisateur avec des clauses SANS.
Intégration pour mettre en évidence les erreurs d'alignement
Une fois que nous commençons à réfléchir à la façon dont nous pourrions lier les artefacts qui composent le modèle de menace avec ceux de l’outil Task &Bug Tracking, il devient plus facile d’identifier les opportunités d’amélioration de la qualité des deux. La clé est de tirer parti de leurs relations pour mettre en évidence les différences et tirer parti des informations présentes dans un pour compléter, intégrer et interpréter ce qui est présent dans l'autre. Comme indiqué ci-dessus, vous pouvez le faire sans impact significatif sur le fonctionnement de l'équipe. C'est parce que l'approche s'appuie sur des informations existantes et crée des relations entre les différents objets dans les différents mondes. Par conséquent, le modèle de menace deviendra la source de vérité pour la sécurité de la solution. En même temps, le backlog est aligné en permanence sur l'état de la solution.
Que pouvez-vous faire aujourd'hui ?
Vérifiez régulièrement qu'il n'existe pas de menaces non mappées ou de récits utilisateur avec des clauses SANS.
Modélisation des menaces et opérations
Toutes ces idées sont principalement axées sur le côté développement de DevOps. Pouvons-nous également faire quelque chose pour améliorer les opérations ? Nous le pensons. Par exemple, il serait possible d'utiliser la modélisation des menaces comme outil pour faciliter l'analyse des causes racines, car elle fournit une vue complète du système du point de vue de la sécurité et peut ainsi mieux comprendre les implications de certaines attaques. Pour ce faire, il serait nécessaire d'intégrer le modèle de menace aux flux existants des outils de surveillance choisis. Cette approche peut représenter un complément pour le SIEM choisi.
Une autre idée de l'intégration de la modélisation des menaces avec Operations consiste à utiliser la première pour piloter la conception de la façon dont cette dernière peut se produire. Voici un exemple de conception d'événements pour la solution. La modélisation des menaces identifie les attaques possibles et nous pouvons utiliser ces connaissances pour identifier les événements que la solution dans l'étendue peut déclencher lorsque ces attaques échouent. Si vous effectuez une validation d'entrée stricte, un attaquant malveillant aurait besoin de quelques tentatives avant de réussir. Initialement, les tentatives échouent et l'une d'elles réussit finalement. En déclenchant des événements pour chaque échec et en déclenchant des alertes quand un seuil est atteint, vous pouvez détecter les attaques et prendre des mesures pour les corriger. Ces situations sont rarement détectées si vous vous limitez à la surveillance de l'infrastructure. Par conséquent, il est nécessaire d'inclure des événements personnalisés, que l'équipe doit concevoir et implémenter avant que le SOC puisse les exploiter.
De plus, ces derniers ne savent peut-être pas grand-chose sur la solution. Par conséquent, le SOC peut ne pas être en mesure de déterminer comment réagir lorsque la validation d'entrée échoue. Malheureusement, lorsqu'une violation de données se produit, il est impératif de réagir rapidement pour réduire rapidement les dommages directs et la probabilité et l'entité des amendes éventuelles.
Par conséquent, nous devons planifier à l'avance ce qui doit être surveillé, dans quelles conditions nous pouvons avoir un problème et ce qu'il faut faire quand cela se produit. La meilleure façon d'identifier ces événements consiste à s'appuyer sur un modèle de menace. Par conséquent, il serait utile de l'exploiter pour générer des artefacts standardisés afin de guider et d'accélérer l'implémentation des configurations nécessaires pour piloter la surveillance et l'audit et faciliter la réponse aux incidents.
Que pouvez-vous faire aujourd'hui ?
Utilisez activement le modèle de menace pour identifier les événements que vous pouvez déclencher pour chaque menace. Ces événements peuvent être fournis par l'infrastructure ou quelque chose que l'application doit déclencher. Incluez des éléments de travail dans votre backlog pour vous assurer que ces événements sont implémentés.
Collaborez activement avec vos équipes d'opérations et de sécurité, y compris l'équipe SOC, pour vous assurer que les événements sont utilisés pour déclencher des alertes et identifier les incidents de sécurité.
L'impact sur le retour sur investissement
Vous pouvez vous demander pourquoi ces techniques peuvent avoir un impact positif sur le retour sur investissement de la modélisation des menaces. De notre point de vue, ils sont essentiels pour augmenter la valeur de la modélisation des menaces pour les équipes DevOps. Le problème que nous avons constaté à plusieurs reprises est que ces équipes perçoivent la sécurité comme un coût qui offre une valeur limitée et nécessite beaucoup de travail imprévu. Parfois, il n'est pas clair pourquoi ils devraient investir tant de temps pour fixer la sécurité. Par conséquent, la sécurité devient un problème au lieu d'être une opportunité. La modélisation des menaces a le potentiel de surmonter ces problèmes, car elle fournit les raisons d'implémenter la sécurité. De plus, il peut être démarré tôt dans le processus de développement et éviter les erreurs de conception qui peuvent coûter cher si elles ne sont pas détectées bientôt. Les techniques ci-dessus visent à mieux intégrer la modélisation des menaces à DevOps. Cela garantit que les décideurs d'entreprise et les développeurs perçoivent la modélisation des menaces comme un complément naturel au processus de développement et d'exploitation. Par conséquent, la valeur reçue par l'adoption de la modélisation des menaces augmente et ses coûts diminuent en raison de l'intégration avec les différents outils déjà utilisés.
Simplification du travail pour les modélisateurs de menaces
Un autre aspect important nécessaire pour améliorer le retour sur investissement de la modélisation des menaces est lié à la réduction de son coût et à l'augmentation du nombre de personnes capables de le livrer tout en conservant des niveaux de qualité plus homogènes.
Il y a beaucoup de tentatives pour répondre à la pénurie de personnes compétentes. Certains d'entre eux sont basés sur l'implication active de l'équipe DevOps dans l'exercice de modélisation des menaces. L'idée est d'identifier un chef de file de l'initiative, c'est-à-dire une personne ayant des connaissances intermédiaires sur le processus, mais qui n'est pas nécessairement un expert, et qu'elle dirige la discussion entre les autres membres de l'équipe. Cette approche est activement approuvée par les signataires du Manifeste de modélisation des menaces.
Nous sommes d'accord que cette approche permet d'obtenir une bonne valeur et représente une amélioration de la situation actuelle. Il fournit également de bonnes informations et permet à l'équipe de développer sa culture de sécurité. Néanmoins, ce n'est pas sans inconvénients parce qu'il couvre seulement quelques problèmes, en laissant beaucoup de choses. Cela crée un problème de cohérence, car il serait trop facile de s'enfoncer dans le trou du lapin et de perdre un temps précieux sur des questions secondaires, en oubliant les questions importantes. L'expérience du dirigeant joue un rôle important dans la prévention de ces situations. De plus, cette approche nécessite beaucoup de temps de la part de tous les membres de l'équipe pour discuter de chaque problème.
C'est pourquoi le fait de consacrer quelques heures par Sprint à cet exercice peut représenter un investissement important. Tout le monde sait que la plupart des équipes ont tendance à perdre du temps sur les grandes réunions impliquant tout le monde, et ces sessions de modélisation des menaces ne feraient pas d'exception. Pourtant, cette approche est excellente pour les petits produits, où l'équipe compte quelques membres supérieurs.
Une approche différente
Compte tenu des limitations de l'approche précédente, nous préférons limiter le nombre de réunions, leur longueur et le nombre de participants. Par conséquent, la responsabilité du modélisateur de menaces serait plus importante : non seulement pour mener les entretiens, mais aussi pour créer et maintenir le modèle de risque lui-même. Cette approche nécessite des compétences et une expertise plus importantes. Les modélisateurs de risque peuvent être représentés par des champions de sécurité ou par des membres de l'équipe de sécurité interne. La plupart des organisations allaient pour la première, car l'équipe de sécurité est généralement entièrement réservée.
Les champions de sécurité sont membres des équipes DevOps qui s'intéressent particulièrement à la sécurité. Ils ne sont pas experts par aucun moyen, mais ils ont une connaissance de base et la volonté d'améliorer l'état de la sécurité de leur équipe. L'idée est de créer un contact privilégié entre les champions de sécurité et l'équipe de sécurité interne afin que les premières soient autorisées à aider leurs équipes à faire la bonne chose, tandis que l'équipe de sécurité peut réduire sa charge de travail. Avec la modélisation des risques, les champions de la sécurité agiraient en tant que modélisateurs de risque, et l'équipe de sécurité interne aurait la responsabilité de les guider et de passer en revue leur travail.
Que pouvez-vous faire aujourd'hui ?
Examinez la possibilité d'adopter un programme champions de sécurité et d'en tirer profit pour renforcer davantage votre cycle de vie de développement logiciel sécurisé.
Rôle des base de connaissances
Un problème important avec la modélisation des risques est de s'assurer que la qualité de l'expérience et la valeur de l'équipe DevOps est élevée, peu importe qui effectue le modèle de risque. Avec les champions de la sécurité, ce problème devient encore plus urgent. Une idée de résoudre ce problème consiste à fournir des base de connaissances pour stimuler la création du modèle de risque. Les bases de connaissances pour la modélisation des risques sont des packages d'informations sur un contexte spécifique : elles contiennent une définition des entités associées à ce contexte, les modèles d'attaque possibles sur ces entités et les préventions standard qui peuvent être appliquées. Les bases de connaissances permettent à l'organisation d'obtenir des résultats plus performants et plus cohérents, car ils représentent des documents de référence qui guident les modélisateurs de risques de manière prescriptive. Les bases de connaissances doivent avoir des règles qui nous permettent d'appliquer automatiquement des menaces et des préventions à un système. Cette automatisation nous permettrait de surmonter le fait que certains modélisateurs de menaces n'ont peut-être pas l'expérience requise pour déterminer si une menace doit être appliquée ou si une prévention est efficace.
Les bases de connaissances ne sont pas une nouvelle idée : de nombreux outils actuels de modélisation des menaces les prennent déjà en charge sous une certaine forme. Mais de nombreuses implémentations modernes présentent des inconvénients importants. Par exemple, vous devez être en mesure de gérer facilement des base de connaissances. Leur facilité de maintenance est un problème qui n'est toujours pas résolu. Par exemple, il n'est pas facile d'identifier les meilleures sources d'informations à utiliser pour les créer. De plus, la maintenance est généralement manuelle. La création et la maintenance des base de connaissances doivent être la responsabilité de l'équipe de sécurité interne de l'organisation. Nous espérons que les sociétés commenceront à fournir des base de connaissances pour les outils de modélisation des menaces les plus courants afin de lever certains des fardeaux de leurs clients à l'avenir. Ces base de connaissances devraient être flexibles pour soutenir et faciliter leur adoption même par les organisations les plus matures, qui doivent adapter les base de connaissances à leurs pratiques, stratégies et réglementations.
Que pouvez-vous faire aujourd'hui ?
Envisagez la possibilité de consacrer une partie de l'effort de l'équipe de sécurité centralisée pour développer des base de connaissances qui peuvent être utilisées par les différentes équipes de développement pour accélérer la modélisation des risques.
Consommation de bases de connaissances
Un autre problème avec les base de connaissances est que parfois ils sont trop complexes à consommer. Beaucoup d'entre eux essaient d'être complets en incluant des problèmes essentiels et moins critiques. Malheureusement, tous ne sont pas requis par tous les systèmes. Vous souhaitez adopter une approche plus simple lorsque le système que vous analysez est petit et ne gère pas les données sensibles. Au contraire, vous souhaitez aller plus loin si le système est complexe et traite les données PII et de valeur commerciale élevée. Par conséquent, il doit être possible d'appliquer différentes versions des connaissances en fonction du contexte ou marquer certains modèles d'attaque et les préventions associées comme « TOP ». Par conséquent, les modélisateurs de risques peuvent décider s'ils veulent une expérience complète ou pour réduire le travail nécessaire.
S'agissant de l'efficacité, il est impératif de s'assurer que les activités sont simplifiées et automatisées autant que possible pour réduire la quantité de travail nécessaire. Nous pensons qu'un endroit idéal pour effectuer un modèle de risque d'une solution de taille moyenne doit être d'un jour de travail pour le modélisateur de risque. Ces résultats ne sont possibles que si l'outil de choix fournit des accélérateurs pour permettre de réduire le temps nécessaire. Par exemple, si l'outil applique 20 types de préventions différentes dans 100 endroits différents et que vous êtes invité à spécifier pour chacun d'eux leur statut, vous serez 5 fois plus efficace en vous concentrant sur le premier au lieu de celui-ci. L'outil de choix doit fournir cette fonctionnalité tout en lui accordant la possibilité d'effectuer un travail plus approfondi si nécessaire.
Que pouvez-vous faire aujourd'hui ?
Si les base de connaissances que vous utilisez aujourd'hui ne prennent pas en charge le concept de menaces et de préventions « TOP », envisagez la possibilité de supprimer ce qui est rarement nécessaire ou utile, pour permettre de se concentrer uniquement sur ce qui importe vraiment.
Parfois, le problème est que les base de connaissances adoptées tentent d'être génériques et couvrent plusieurs scénarios. Vous pouvez améliorer la situation en les spécialisant.
Poser les bonnes questions
Au cours de notre analyse, nous avons envisagé la possibilité d'utiliser un outil pour prendre en charge un cadre questions afin de conduire les premières phases de l'analyse. Nous avons remarqué que la plupart des modélisateurs de risques inexpérimentés ne peuvent pas poser les bonnes questions pour obtenir les informations requises pour leur analyse. Certains de nos experts ont démontré qu'il est possible de déterminer certaines questions cruciales basées sur un diagramme système dans l'étendue. Ces questions peuvent même être appliquées automatiquement, avec certaines règles de génération. Le problème est que cette approche peut ne pas fournir la valeur qu'elle semble promettre. Cela serait dû au fait que vous devez comprendre la raison d'être de chaque question. Sinon, vous ne serez pas en mesure d'évaluer la réponse et de déterminer si elle est satisfaisante. Toutefois, la génération de questions automatisées peut fournir une valeur significative aux modélisateurs de risques moins experts, ce qui améliore leur compréhension des systèmes dans l'étendue.
Que pouvez-vous faire aujourd'hui ?
Adopter une approche structurée pour poser des questions. Par exemple, notre équipe a eu de bons résultats en adoptant Microsoft STRIDE comme référence. Pour ce faire, demandez à chaque composant des questions de solution comme suit :
Usurpation d'identité : comment le composant s'authentifie-t-il auprès des services et des ressources qu'il utilise ?
Falsification : le composant valide-t-il les messages qu'il reçoit ? La validation est-elle lâche ou stricte ?
Répudiation : le composant journalise-t-il les interactions dans un journal d'audit ?
Divulgation d'informations : le trafic entrant et sortant est-il chiffré par le composant ? Quels sont les protocoles et algorithmes autorisés ?
Refus de service : le composant est-il configuré en haute disponibilité ? Est-il protégé contre les attaques DDoS ?
Élévation de privilège : les utilisateurs affectés reçoivent-ils les privilèges minimum requis ? La solution combine-t-elle du code destiné aux utilisateurs normaux avec cela pour les utilisateurs à privilèges élevés ?
Les techniques comme celle-ci peuvent être enseignées et peuvent être améliorées avec l'expérience. Par conséquent, il est important d'implémenter une approche d'apprentissage continu conçue pour collecter des apprentissages et les diffuser au sein de l'organisation.
L'impact sur le retour sur investissement
En fin de compte, il est possible d'identifier de nombreuses idées pour améliorer l'efficacité de l'expérience de modélisation des risques, sa qualité et, en fin de compte, augmenter le retour sur investissement. Cet effort devrait cependant être considéré comme un processus continu, qui devrait être dirigé vers l'amélioration continue de la pratique.
Conclusions
La modélisation des risques est une excellente méthodologie pour améliorer la sécurité de votre organisation. Si elle est effectuée correctement, elle peut fournir une valeur pour un coût très raisonnable. Nous avons déjà identifié différentes techniques qui peuvent s'avérer essentielles pour améliorer la valeur de la modélisation des risques pour sécuriser les solutions modernes, notamment :
Aligner le modèle de risque avec votre pratique DevOps en
Se concentrant sur les préventions
Liant des préventions avec des récits utilisateur
Mettant en évidence les différences entre le modèle de risque et le backlog
Utilisant le modèle de risque pour piloter une surveillance et un audit plus complets pour la sécurité
Simplifiant la création de modèles de risque et augmenter la cohérence des résultats
S'appuyant sur les champions de sécurité
Adoptant des base de connaissances pour automatiser l'identification des menaces et des préventions
Créant de meilleures base de connaissances
Fournissant un cadre de questions pris en charge par l'automatisation
J'espère que certains d'entre eux sont déjà présents dans votre outil de modélisation des risques de choix. D'autres seront incluses à l'avenir. Nous savons que l'optimisation du retour sur investissement pour la modélisation des risques est un effort à long terme qui nécessite des réponses que nous n'avons pas encore. Nous savons également que certaines questions sont encore inconnues. Ce document devrait fournir un certain nombre d'aliments pour la pensée et, espérons-le, peut vous aider à améliorer la façon dont vous effectuez la modélisation des risques. Nous espérons qu'il peut être un phare pour vous et nous, et qu'il sera utile de diriger nos efforts pour les années à venir.