Sécuriser vos applications dès la phase de conception avec notre méthodologie en 3 étapes

Microsoft SDL, OWASP

0  commentaires

Chez AppSec Academy, nous savons que la sécurité est l’affaire de tous. C’est pour cette raison qu’il est indispensable d’intégrer des jalons de sécurité à toutes les étapes de votre cycle de développement logiciel et d’impliquer l’ensemble des personnes qui touchent de près ou de loin à la création de vos applications.

Dans cet article, nous nous penchons sur le cas des architectes logiciels et de la phase de conception.

Les architectes logiciels ont la mission de faciliter la tâche des développeurs en s’assurant qu’ils ont fait les meilleurs choix techniques et technologiques pour garantir la sécurité de leurs applications. Pour cela, il faut mettre en œuvre un processus d’identification et d’évaluation des menaces de sécurité appelé Modélisation de la menace ou encore « Threat Modeling » en anglais.

Notre méthodologie de modélisation de la menace en 3 étapes

Il existe plusieurs méthodologies de modélisation des menaces telles que STRIDE, P.A.S.T.A., TRIKE ou encore VASR. Elles sont largement documentées sur Internet.

Vous n’aurez probablement pas le temps de vous documenter au sujet de toutes ces méthodologies et c’est pour cette raison qu’AppSec Academy souhaite vous partager son approche en 3 étapes, celle que nous utilisons chez nos clients. Elle se décompose selon la figure suivante :

L’approche que nous allons vous présenter se veut itérative. Elle peut démarrer dès la phase de conception d’une application et elle se poursuit durant tout son cycle de vie.

Il y a deux raisons à cela :

  • Premièrement, il est impossible d’identifier toutes les menaces possibles en une seule fois.
  • Deuxièmement, les applications sont rarement statiques. Elles ont besoin d’être améliorées et régulièrement revues, de sorte que la modélisation de la menace doit être répétée et modifiée à chaque fois que votre application évolue.

Étape 1 : la phase d’identification des menaces

Durant cette étape, il est nécessaire de se positionner dans la peau d’un attaquant afin d’identifier les menaces qui pèsent sur votre application. Une bonne connaissance des vulnérabilités applicatives vous permettra de mener à bien cette réflexion. Pour cela, vous devez commencer par vous familiarisez avec le TOP 10 de l’OWASP qui liste les 10 familles de vulnérabilités les plus critiques que l’on peut retrouver sur internet (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).

Nous vous invitons à lire notre précédent article dans lequel nous présentons l’OWASP et son Top 10 (https://www.linkedin.com/pulse/les-3-outils-owasp-indispensables-aux-développeurs-pour-azziz-errime/?published=t).

Pour identifier les menaces susceptibles d’affecter votre application et de compromettre ses ressources, nous vous recommandons d’utiliser le modèle de menace STRIDE tiré de la méthodologie de développement SDL de Microsoft (Security Development Lifecycle) (nous vous invitons d’ailleurs à lire la fiche résumée de l’OWASP qui synthétise très bien cet outil https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html).

STRIDE est une approche moderne qui vise à évaluer les risques liés à des menaces, à partir d’une perspective offensive qui correspond à celle d’un potentiel attaquant. En effet, plus vous serez en mesure d’anticiper les actions des attaquants, plus vous serez en mesure de proposer des contrôles de sécurité qui les freineront efficacement.

Qui connaît son ennemi comme il se connaît, en cent combats ne sera point défait (Sun Tzu)

STRIDE doit être considéré comme un outil vous permettant de structurer votre réflexion lors de la phase d’identification des menaces. STRIDE est l’acronyme de différentes catégories de menaces suivantes :

Le S de STRIDE définit la catégorie de menaces qui permettrait à un attaquant d’usurper l’identité d’un utilisateur de votre application.

Le T correspond aux menaces qui permettrait à un attaquant de falsifier des données de votre application de façon frauduleuse.

Le R correspond aux menaces qui permettrait à un attaquant de masquer les preuves de ses actions.

Le I correspond aux menaces qui permettrait à un attaquant d’accéder à des informations auxquels il ne devrait pas avoir accès.

Le D correspond aux menaces qui permettrait à un attaquant de provoquer un Déni de service et à réduire de façon délibérée la disponibilité de votre application.

Et enfin, le E correspond aux menaces qui permettrait à un attaquant d’obtenir un niveau d’autorisation plus élevé que celui qui lui est normalement attribué.

Exemple permettant d’illustrer nos propos :

Cible : application bancaire

Catégorie de menaces : S de STRIDE –> Que peut faire un attaquant pour usurper l’identité d’un utilisateur tiers ?

Il débutera probablement par la réalisation d’une attaque de type « brute-force » pour trouver des comptes appartenant d’autres utilisateurs.

L’utilisation d’un clavier virtuel par la banque facilitera le travail de l’attaquant (la complexité du mot de passe sera faible). En partant du principe que 123456 est le mot de passe le plus courant, l’attaquant pourra alors, « brute-forcer » l’identifiant (qui correspond souvent à une suite de chiffre), pour accéder à des comptes valides. Ce cas de brute-force inversé est un bon exemple de menace à anticiper avant la phase d’implémentation.

123456 est le mot de passe le plus choisi

Conseil : L’identification des menaces donne de meilleurs résultats quand elle est réalisée lors d’un atelier regroupant l’ensemble des acteurs du développement de votre application. Plus vous pratiquerez cet exercice et plus vous serez en mesure d’anticiper efficacement les menaces qui ciblent votre application.

Il existe des outils gratuits ou encore payant qui peuvent vous assister lors de ce travail. Notre préférence va à OWASP Thread Dragon (même s’il est encore en phase Béta) (https://www.owasp.org/index.php/OWASP_Threat_Dragon).

Étape 2 : la phase d’évaluation des menaces

Il n’est pas toujours économiquement viable de traiter toutes les menaces identifiées et il est possible d’en ignorer certaines du fait que le changement et les éventuels dommages qu’elles entraînent sont minimes.

Ainsi, cette nouvelle phase permet d’évaluer les menaces précédemment identifiées en fonction du risque qu’elles représentent et de traiter en priorité celles qui présentent le plus grand risque, avant de résoudre les autres dans un second temps.

Pour mener à bien cette étape, il faut utiliser des critères précis qui permettent d’obtenir un calcul du risque qui soit consistent. Nous vous conseillons donc d’utiliser l’outil d’évaluation des risques DREAD, également tiré de la méthodologie SDL de Microsoft. Comme pour STRIDE, DREAD est un acronyme : chaque lettre correspond à l’une catégorie de risques suivantes :

Exemple pour illustrer nos propos :

Voici un exemple de ce que nous utilisons pour définir le niveau de risque d’une application (avec l’outil DREAD) chez nos clients pour l’Exploitabilité (lettre E) : dans quelle mesure l’attaque est-elle facile à déclencher ? Pour répondre à cette question, nous définissons les trois niveaux de risques suivants :

  • Élevé : un pirate novice doit pouvoir mener une attaque dans un laps de temps très court.
  • Moyen : il faut un pirate expérimenté pour pouvoir mener une attaque puis pour les répéter.
  • Faible : l’exécution de l’attaque nécessite à chaque fois une personne très expérimentée qui dispose de connaissances très poussées.

DREAD, tout comme STRIDE est très bien résumé dans la fiche synthétique de l’OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html).

Étape 3 : la phase de documentation des menaces

Cette étape consiste à documenter l’ensemble des menaces identifiées lors de l’étape d’identification des menaces, de les trier par ordre de criticité suite à l’étape d’évaluation des menaces puis de réfléchir aux contre-mesures qu’il est nécessaire de mettre en œuvre pour sécuriser son application en conséquence.

Pour une application existante, rapprochez-vous de vos développeurs pour ajuster le niveau de risque et pour définir le moyen de vérifier l’existence de la menace.

Exemple pour illustrer nos propos :

Le tableau suivant synthétise le travail effectué sur une menace via notre méthodologie :

Nous pouvons vous assurer qu’à ce moment, vous serez épaté par l’efficacité de cette méthodologie qui permet d’améliorer le niveau de sécurité de vos développements sans avoir à étudier son code source. Elle s’avère également redoutable lorsque vous souhaitez vous attaquer à une application ancienne qui dispose de beaucoup de lignes de code, le fameux « Legacy ».

A vous de jouer, et n’hésitez pas à partager votre expérience avec nous.

Voici les liens évoqués dans l’article :


Tags

architecture sécurisée, design review, dread, modélisation des menaces, owasp, stride


À propos de l'auteur :

Azziz ERRIME

Anciennement responsable de l’activité sécurité applicative chez Orange Cyberdefense, Azziz dispose de 10 ans d’expérience dans le domaine de la sécurité des S.I. (tests d’intrusion, audit de code, Reverse-Engineering, Formation, etc.) et a développé un intérêt particulier pour le domaine de la sécurité applicative.

Autres articles que vous pouvez aimer ...

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>