Comment intégrer la modélisation des menaces au rythme effréné du DevSecOps ?

Le DevSecOps vise à accélérer la production de logiciels de qualité. Pourtant, la modélisation des menaces est réputée complexe et chronophage, et de nombreuses entreprises estiment qu’elle ralentit le cycle de vie du développement logiciel (SDLC). Comment concilier les deux pour bénéficier de la sécurité apportée par la modélisation des menaces sans entraver le processus de développement logiciel ?

Cet article passe en revue la modélisation des menaces et explique comment elle s’intègre naturellement au processus DevSecOps.

Qu’est-ce que la modélisation des menaces ?

La modélisation des menaces examine la conception des opérations d’un système et la circulation des données entre ses sous-systèmes. Elle identifie ensuite tous les points d’attaque que les pirates pourraient exploiter, ainsi que les moyens de le faire. Enfin, elle conçoit des solutions pour protéger le système et ses données.

Selon Adam Shostack, expert reconnu, le processus de modélisation des menaces pose les questions suivantes :

• Que construisons-nous ? Évaluez la circulation des données dans un système, les frontières qu’elles franchissent et les technologies utilisées à chaque transfert.

• Qu’est-ce qui pourrait mal tourner ? Examinez tous les moyens possibles d’exploiter les transferts.

• Que pouvons-nous faire ? Concevez des défenses contre chaque exploitation.

• Avons-nous bien fait les choses ? Cette dernière question, la plus importante, nous invite à revenir sur le processus et à l’évaluer. Elle nous rappelle que le travail n’est jamais vraiment terminé : il y a toujours matière à amélioration.

L’équipe hiérarchise ensuite les risques liés aux menaces et les intègre au développement.

Quand faut-il réaliser la modélisation des menaces ?

Le moment idéal pour réaliser la modélisation des menaces se situe aux toutes premières étapes du SDLC, pendant la phase d’architecture du développement d’applications. Plus tôt vous identifiez les menaces, plus vous pouvez concevoir efficacement des solutions pour contrer les vecteurs d’attaque.

Il est préférable d’intégrer la sécurité à l’application dès le départ, mais il n’est jamais trop tard pour profiter des avantages de la modélisation des menaces, même pour les applications existantes. Cet exercice peut être utile à toutes les personnes concernées, quel que soit le moment où il intervient dans le SDLC.

L’histoire de la modélisation des menaces

Les premières tentatives de modélisation des menaces remontent aux années 1990, avec le concept d’arbres d’attaque. Par la suite, Loren Kohnfelder et Prerit Garg, de Microsoft, ont diffusé un document intitulé « The Threats to Our Products », largement considéré comme la première description formelle d’un processus de modélisation des menaces.

Depuis, le secteur s’est mobilisé autour d’organisations telles que l’Open Web Application Security Project (OWASP), qui classe les principales menaces, les décrit et recommande des mesures pour y répondre. L’OWASP a également publié une évaluation similaire des menaces pour la sécurité des API numériques, destinée aux API de logiciel en tant que service (SaaS).

Aujourd’hui, alors que Yahoo, Uber et First American Financial ont vu des pirates dérober des millions de dossiers d’utilisateurs, toutes les organisations doivent être conscientes des menaces numériques. Les rapports de sécurité de 2020 dressent un tableau alarmant :

• Plus de 18 000 vulnérabilités ont été recensées en 2020, et près d’un quart d’entre elles étaient de gravité élevée.

• Les entreprises ont déboursé en moyenne 3,86 millions de dollars pour remédier à une violation de données.

• Les attaques par maliciel et rançongiciel ont augmenté respectivement de 358 % et 435 %.

Conseils pour la modélisation des menaces

Le processus de modélisation des menaces peut être assez complexe. Une approche éprouvée, la méthodologie STRIDE, recommande une analyse technique distincte pour chaque grand type d’attaque :

• Usurpation d’identité : contourner l’authentification en se faisant passer pour quelqu’un d’autre.

• Altération : compromettre le système d’une manière qui permette d’autres exploitations.

• Répudiation : contourner la détection en dissimulant les preuves d’attaques ou en falsifiant les journaux pour qu’ils paraissent normaux pendant les attaques, afin de masquer l’intention et de les laisser se poursuivre.

• Divulgation d’informations : porter atteinte à la confidentialité en trouvant des moyens d’extraire des données sensibles de n’importe quel endroit du système.

• Déni de service (DoS) : empêcher les utilisateurs d’accéder aux systèmes en épuisant délibérément les ressources nécessaires à leur bon fonctionnement.

• Élévation de privilèges : contourner l’autorisation en incitant le système à accorder à un compte des privilèges supplémentaires permettant un accès plus étendu.

Les diagrammes de flux de données (DFD), STRIDE et les méthodologies plus récentes de ce type fournissent un cadre pour répondre à des questions telles que :

• « Que construisons-nous ? » Les DFD permettent notamment de représenter le système et ses différentes frontières de confiance, première étape pour comprendre les menaces à la sécurité.

• « Qu’est-ce qui pourrait mal tourner ? » STRIDE se concentre sur cette question et examine chaque type d’attaque en fonction de la conception du système.

Par exemple, en 2019, une attaque par déni de service contre le serveur d’API Kubernetes a exploité une faille qui permettait d’envoyer de très grandes quantités de données dans la « charge utile » de l’API, ralentissant ainsi le système.

Les mesures d’atténuation de cette menace comprenaient :

• des limites de taille pour les charges utiles de chaque appel

• des limites d’appels API pour un utilisateur ou une adresse IP spécifique

Ces mesures ont permis de repousser de futures attaques DoS contre le serveur d’API.

De tels efforts nécessitent d’examiner en détail les fonctionnalités du système pour chaque type d’attaque. Des solutions sont possibles, mais leur recherche, leur conception, leur développement, leurs tests et leur déploiement prennent du temps.

Pourquoi la modélisation traditionnelle des menaces complique le DevSecOps

La modélisation traditionnelle des menaces nécessite des réunions d’analyse réunissant toutes les parties prenantes, notamment les professionnels de l’informatique et les experts en cybersécurité. Ces réunions permettent de partager des connaissances et des renseignements sur les menaces et les stratégies d’atténuation, ce qui est utile à toutes les parties.

Cependant, ces réunions prennent beaucoup de temps et peuvent mobiliser de nombreuses personnes pendant plusieurs jours. Il est donc impossible d’en organiser avant chaque sprint. Elles vont à l’encontre de la culture DevSecOps, qui vise à accélérer le cycle de vie du développement logiciel.

Tendances DevOps populaires pour accélérer le développement :

• Automatiser et tester le plus en amont possible dans le pipeline de build (« shift left »).

• L’automatisation ne concerne pas uniquement le code applicatif, mais aussi l’infrastructure système, que les nouvelles technologies permettent de définir sous forme de code et donc de tester.

• Cette automatisation accélère l’intégration continue et la livraison continue (CI/CD), ce qui permet de déployer plus souvent les fonctionnalités et les correctifs, avec une plus grande confiance.

Résultat : le développement logiciel s’accélère constamment. Certaines équipes déploient du nouveau code en production toutes les deux à quatre semaines. Avec un tel rythme, comment trouver le temps d’organiser de longues réunions sur la sécurité ?

Former les équipes à la modélisation des menaces pour éclairer le processus DevOps

La formation est essentielle pour insuffler une approche axée sur la modélisation des menaces dans le SDLC sécurisé, comme le souligne Brandon Jeanmarie, expert en sécurité chez IBM. Mais il est impossible d’organiser fréquemment de longues réunions. Il recommande donc une approche « juste à temps » pour former les membres de l’équipe de développement qui travaillent avec des clients :

• La modélisation des menaces est facile à comprendre : saisissez les occasions de l’expliquer aux développeurs et aux responsables afin qu’ils comprennent les possibilités, en commençant « maintenant », là où ils en sont dans le développement de leur système.

• Toutes les parties prenantes du système bénéficient de cette formation : présentez la modélisation des menaces de manière adaptée au rôle de chaque membre de l’équipe. Une fois sensibilisés, ils peuvent contribuer à la solution lors de la planification des récits du sprint et établir les priorités en conséquence.

• La formation peut elle aussi être « décalée vers la gauche » : sensibilisez à la modélisation des menaces le plus en amont possible dans le pipeline. Vous instaurerez ainsi de bonnes pratiques DevSecOps et pourrez commencer à identifier et atténuer les menaces le plus tôt possible.

• Les outils de modélisation des menaces peuvent « étendre la couverture vers la droite » : les outils tiers peuvent automatiser la détection et l’atténuation des menaces aux étapes ultérieures du SDLC, y compris en production, où ils continuent de protéger le système.

Jeanmarie conclut qu’une formation adaptée au contexte et au rôle de chacun instaure une approche « secure by design » qui enrichit la culture DevSecOps d’une organisation. Et cela, sans réunions fréquentes et longues. Une fois ces connaissances intégrées à la culture, chacun peut contribuer à l’atténuation des menaces lorsque vient son tour.

4 étapes pour intégrer la modélisation des menaces à la conception des récits agiles

Alyssa Miller, spécialiste de la sécurité, pousse encore plus loin le principe du « shift left ». Elle a étudié comment intégrer plus naturellement la modélisation des menaces au DevSecOps. Voici sa proposition :

Limitez la portée de la modélisation des menaces aux exigences de chaque récit utilisateur. C’est le plus en amont possible dans le DevSecOps.

La démarche consiste à inclure l’utilisateur métier dans la discussion d’analyse du récit. Elle fonctionne parce que les exigences du récit se situent en amont des détails techniques. Posez les questions suivantes à l’utilisateur métier :

• Quels sont les actifs critiques concernés par la nouvelle fonctionnalité ?

• Quel est le pire scénario possible pour chacun de ces actifs critiques ?

La discussion fait ensuite naturellement émerger des exigences de sécurité, consignées dans le récit en langage courant, compréhensible par tous. Par exemple :

• Les fonctions critiques F1 et F2 doivent être protégées contre tout usage non autorisé.

• Les données privées XYZ doivent être protégées contre toute divulgation.

• La transaction monétaire liée à l’achat P doit être protégée contre le vol pendant son transfert.

Ajoutées au récit, ces formulations en langage courant déclenchent ensuite une série d’activités en aval dans le pipeline de développement.

En repensant ainsi le processus de modélisation des menaces, elle a pu le définir plus succinctement : « Identifier les menaces probables pesant sur un système afin d’orienter la conception de contre-mesures de sécurité. »

Selon Miller, cette approche intègre la culture DevSecOps dès les premières étapes du SDLC et permet à toute l’équipe de développement d’inclure la modélisation des menaces adaptée au contexte dans l’objectif général d’amélioration continue. C’est possible parce que chacun adopte une approche axée sur la sécurité et met cette sensibilisation à profit lors de la planification des sprints et de toutes les activités en aval :

1. Planifier : intégrer les exigences de sécurité au récit.

2. Développer : intégrer les mesures d’atténuation des menaces (contrôles de sécurité) au SDLC.

3. Tester : rédiger des récits comprenant des cas d’utilisation liés à l’atténuation des menaces et les transformer en cas de test.

4. Déployer : créer des moniteurs qui mettent en œuvre les cas de test et configurent des alertes.

Miller conclut que cette démarche permet d’intégrer la modélisation des menaces sans ralentir le DevSecOps.

Conclusion

La culture DevSecOps consiste à décomposer le SDLC en étapes que l’on peut automatiser afin d’améliorer la qualité « vers la gauche » dès le début du cycle et d’étendre « vers la droite » les outils qui couvrent l’ensemble du pipeline de livraison logicielle. Former toute l’équipe à la modélisation des menaces et à sa décomposition dans le SDLC, dès la définition des exigences, permet à la sensibilisation aux menaces de s’intégrer à chaque étape du DevSecOps et de l’éclairer.