TECH30717 – Fiche de révision – Examen Intra

Séance 1 : Introduc?on à la sécurité applica?ve

La sécurité applicative désigne l’ensemble des mesures mises en place pour protéger les
applications contre les menaces de cybersécurité. Elle englobe les pratiques, outils et
méthodologies visant à sécuriser le développement, le déploiement et l'exploitation des
applications.

• Définition simplifiée : "La sécurité des applications, c’est comme protéger une maison
avec des serrures et des alarmes, mais pour des logiciels."
• Définition technique : "La sécurité des applications fournit un cadre sécuritaire pour
définir, conceptualiser, développer, implémenter, maintenir et retirer une application."
(Dr. Meng-Chow Kang, Cisco)

La sécurité applicative couvre plusieurs domaines :

• La confidentialité (empêcher l’accès non autorisé aux données) C

• L’intégrité (prévenir la modification non autorisée des données) I
• La disponibilité (assurer l'accès aux utilisateurs autorisés) D
• L’authentification et l’autorisation (gestion des accès) A
• La journalisation et la surveillance (enregistrer les événements pour enquêtes et
conformité) è LOGS

Exemples d’applications : Réseaux sociaux, applications bancaires, e-commerce (Twitter,

Microsoft 365, ZoneCours, Desjardins Acces D, etc.)

2. Pourquoi faire de la sécurité applicative ?

L’objectif principal est la protection des informations sensibles et la préservation de la

réputation des entreprises. Le principal objectif de la sécurité des applications est la protection
des intérêts, la marque et la réputation de l'entreprise.

Une application vulnérable peut entraîner des pertes financières, des fuites de données, risques
juridiques et des atteintes à la confiance des utilisateurs.

Les enjeux majeurs :

1. Accroissement des cyberattaques : L'augmentation du nombre d’applications et la

complexité croissante du développement rendent les logiciels plus vulnérables.
2. Menaces et risques :
o Injection SQL : Attaques ciblant les bases de données via des entrées malveillantes.
 o Cross-Site Scripting (XSS) : Exploitation de failles pour exécuter du code
malveillant côté client.
o Authentification faible : Accès non sécurisé favorisant les compromissions de
comptes.
3. Coût des incidents : Un vol de données peut engendrer des coûts énormes, incluant la
perte de clients et la gestion des répercussions légales.

Exemple concret :

Un informaticien a découvert une faille dans le protocole de création des codes QR pour les
preuves vaccinales, permettant de contourner les vérifications d’authenticité.

3. Mise en place de la sécurité applicative

La mise en œuvre d’une sécurité applicative efficace repose sur des méthodologies et des outils
adaptés aux différentes phases du cycle de développement.

Protéger les applications

En mettant en place des contrôles permettant :

• Authentification forte (ou MFA en anglais)

• Validation des données entrées et transmises,
• Refus des valeurs par défaut,
• Attribuer seulement les privilèges nécessaires,
• Etc.

Approche holistique

Il ne suffit pas de sécuriser uniquement l’infrastructure (réseaux : pare-feu et systèmes de

détection d’intrusions) (Machine : antivirus, patching), il faut aussi protéger l’application elle-
même.

Méthodes et bonnes pratiques:

• Développement sécurisé (Secure SDLC)

o Intégration de la sécurité dès les premières étapes du développement (approche
"Shift Left")
o Utilisation d’analyses de code statiques et dynamiques (Static & Dynamic Code
Analysis)
o Déploiement de pare-feu applicatifs (WAF – Web Application Firewall)
• Standards de sécurité et bonnes pratiques
 o NIST SP 800-53 : Cadre pour la gestion des risques liés à la cybersécurité.
o OWASP : Organisation spécialisée dans la sécurité applicative fournissant des
guides comme OWASP SAMM (Software Assurance Maturity Model) et OWASP
Testing Guide.
o OWASP Testing Guide :
§ Validation des données
§ Authentification forte
§ Principe du moindre privilège : Attribution minimale des droits aux
utilisateurs et processus.

Défis à surmonter de la sécurité applicative:

• Triangle de projet
o Coûts d’implémentations du cycle de développement sécuritaire : Il est difficile
de démontrer une relation 1 à 1 de retour sur investissement en sécurité.
o Manque de ressources qualifiées : Besoin de personnel formé aux pratiques de
sécurité.
• Coût de mise en œuvre : Difficile de prouver un ROI direct pour la sécurité.
• Perception de la sécurité comme un frein : La sécurité est parfois vue comme une
contrainte pour l’expérience utilisateur et les performances.
• Sécurité après-coup (Afterthought) : La sécurité est perçue comme une couche de
peinture qu'on ajoute vers la fin du développement et non comme un élément essentiel
de la fondation de l'application

4. Attributs d’un logiciel sécuritaire

Un logiciel sécurisé doit intégrer plusieurs attributs essentiels pour garantir une protection
robuste contre les cyberattaques.

1. Confidentialité : Protection des données sensibles contre tout accès non autorisé.
2. Intégrité : Prévention des modifications malveillantes ou accidentelles des données.
3. Disponibilité : Assurer un accès continu aux utilisateurs autorisés.
4. Authentification : Vérification de l’identité des utilisateurs (ex. MFA – authentification
multi-facteurs).
5. Autorisation : Gestion fine des permissions selon les rôles des utilisateurs.
6. Journalisation : Enregistrement des événements critiques pour permettre la surveillance
et les audits. (logs)
7. Résilience : Capacité à détecter, contenir et récupérer d’une attaque rapidement.

5. Positionnement de la sécurité applicative au sein d’une organisation

La sécurité applicative ne doit pas être une réflexion après coup, mais une composante intégrée
à la gouvernance de la sécurité de l’information.

Approche DevSecOps:

• Intégrer la sécurité dans le cycle DevOps pour automatiser les contrôles et réduire les
risques dès la conception.
• Favoriser la collaboration entre les équipes de développement, d’exploitation et de
sécurité.

Alignement avec la stratégie de l’entreprise :

• Soutien de la direction : Il est essentiel que la direction comprenne les enjeux et

soutienne les initiatives de sécurité.
• Formation et sensibilisation : Tous les acteurs impliqués dans le développement doivent
être formés aux bonnes pratiques.
• Gestion des risques : La sécurité applicative s’intègre dans la gestion globale des risques
numériques de l’organisation.

Conclusion

La sécurité applicative est une nécessité incontournable face à l’augmentation des cyberattaques.
Elle doit être intégrée dès la conception des logiciels, soutenue par des standards reconnus
(OWASP, NIST) et adaptée aux contraintes organisationnelles. L’approche DevSecOps et
l'automatisation des contrôles permettent de renforcer la posture de sécurité sans ralentir
l’innovation.
Séance 2 : Sécurité applica?ve - Introduc?on au SDL

Cette séance vise à offrir une vue d’ensemble sur les différentes approches de développement
d’applications et à introduire le Security Development Lifecycle (SDL) de Microsoft comme un
cadre de référence pour intégrer la sécurité dans le développement logiciel.

1. Comment développe-t-on une application ?

Imaginons que tu veux créer une application. Voici comment ça peut se passer :

1. Jour 1 : Tout commence bien, tu codes vite, tout fonctionne.

2. Après 6 mois : L’application marche bien, les utilisateurs sont contents.
3. Après 9 mois : Ça devient compliqué ! Tu ajoutes de nouvelles fonctionnalités, mais sans
documentation ni structure, les erreurs s’accumulent.
4. Après 12 mois : L’équipe grandit, mais sans règles claires, les bugs et les problèmes de
communication explosent.
5. Après 18 mois : Il faut tout organiser : ajouter des tests, écrire des règles, structurer le
code, sinon c'est la catastrophe.

➡ Moralité : Si on ne suit pas un processus structuré dès le début, ça devient un chaos total.

Pourquoi sécuriser une application dès sa création ?

• Si la sécurité est oubliée au début, corriger les failles après coup devient très coûteux et
risqué.
• L’objectif est de protéger les données et d’éviter les failles qui pourraient être
exploitées par des attaquants.

Un processus est un ensemble d’acmvités logiquement agencées pour effectuer une

transformamon donnée (saisissent un input, le transforment et fournissent un output à un
desmnataire), procurant une plus-value à l’organisamon.

Intrant > Ac?vité de transforma?on > Extrant

Exemple : Processus BPMN, Adminission HEC, etc.

Qu’est-ce que serait l’extrant dans un processus de développement d’applicamon?

à Si l’intrant est l’applicamon, l’extrant serait l’idée.

Un processus de développement (ou cycles de développement) d’applicamon définit les acmons

pour construire, déployer et maintenir les applicamons.
Typiquement la définimon de processus inclut:
 • L’ordre (séquence) des acmons
• Les rôles et responsabilités impliqués
• Les livrables

Il existe divers processus de développement d’applicamon (chacun avec ses avantages et ses
inconvénients)

• Modèle linéaire: Subdivision par phase de développement (exigences, concepmon,

réalisamon, tests, etc.)
• Modèle itéra?f: Subdivision par foncmonnalité où chaque itéramon a comme objecmf la
livraison de la foncmonnalité prévue.

2. Différentes méthodes pour développer une applicaFon

Les cycles de vie du développement d’applications définissent les étapes nécessaires pour
construire, déployer et maintenir une application. Les méthodes les plus courantes incluent:

• Modèle en cascade : Approche séquentielle où chaque phase (exigences, conception,

développement, tests, etc.) doit être complétée avant de passer à la suivante. Bien que
rigide, cette approche offre une structure claire, mais peut être inefficace face à des
changements imprévus.

On avance étape par étape (exigences → conception → développement → tests →

déploiement). C’est rigide, mais structuré.

• Méthodologie agile : Approche itérative où les développements sont réalisés en cycles

courts (sprints) avec des livraisons fréquentes. Cela permet d’adapter rapidement
l’application aux nouveaux besoins, mais peut parfois compromettre la planification à
long terme.
 On avance petit à petit avec des cycles courts et des ajustements fréquents. C’est plus
flexible.

** Meilleure gesmon du risque avec agile car on peut s’ajuster en cours de route. Tandis
que la méthodologie en cascade est plus difficile et tu dois avendre de finir le cycle de
développement. Tu ne peux pas nécessairement faire de déviamon/modificamon en cours
de route. Inverse du modèle cascade!

• Unified Process (UP) : Un modèle itératif et incrémental qui divise le développement en

phases (inception, élaboration, construction et transition), avec une forte implication des
parties prenantes et des tests continus. On mélange planification et flexibilité pour
s’adapter aux besoins du projet.

• Autres modèles : Des variantes comme DevOps, qui intègre les opérations et
l’automatisation pour accélérer le cycle de développement, ou le modèle en V, qui met
un fort accent sur les tests dès le début.

➡ Problème : Ces méthodes parlent de développement, mais elles ne prennent pas assez en
compte la sécurité dès le départ.

Pourquoi mettre en place un SDLC (Security Development LifeCycle)?

à L’objectif de ces modèles est de gérer et d’équilibrer le coût, le temps et la portée tout en
garantissant la qualité du produit.

3. Présentation du Security Development Lifecycle (SDL) de Microsoft

Le Microsoft SDL est un cadre de développement sécurisé qui répartit des activités de sécurité
tout au long du cycle de développement. Son but est de minimiser les vulnérabilités en intégrant
des mesures de sécurité dès la conception.
Les principales phases du SDL comprennent :

1. Formation des développeurs: Sensibilisation et formation des équipes de

développement aux bonnes pratiques de sécurité.

Exemple : Imagine qu'une équipe de développeurs crée une application bancaire. Avant
de commencer, ils suivent une formation sur les attaques courantes (injection SQL, XSS,
etc.) et apprennent comment les éviter.

2. Définition des exigences : Identification des exigences de sécurité et de confidentialité à

respecter selon les normes et réglementations en vigueur (dès le début).

**Échelle de bug et niveau de la qualité

Exemple : Dans une applicamon e-commerce, l'équipe décide que :

• Chaque umlisateur doit se connecter avec un mot de passe fort.

• Les transacmons financières doivent être protégées par une authenmficamon à
deux facteurs (2FA).
• Les données des clients doivent être chiffrées.

3. Conception de sécurité:
o Modélisation des menaces pour identifier les risques potentiels dès la phase de
conception aka Iden?fier les menaces avant qu'elles ne deviennent des
problèmes.
o Spécifications de sécurité sur des aspects comme l’authentification, le chiffrement
et la gestion des accès.
o Exemple : Une entreprise développe une application de messagerie. L'équipe fait
une modélisation des menaces et découvre que sans cryptage, les messages
pourraient être interceptés. Solution : Ajouter un chiffrement de bout en bout
pour sécuriser les conversations.
4. Implémentation :
o Utilisation d’outils approuvés (IDE : GitHub, VScode, Jenkins, etc.) pour garantir un
développement sécurisé.
o Faire des analyses de code automatiques pour détecter les erreurs.
o Exemple : Un développeur travaille sur un site web de réservamon d’hôtels.
Il umlise des bibliothèques sécurisées pour gérer l'authenmficamon et s’assure que
les entrées umlisateur sont validées pour éviter une injecmon SQL.
 o Exemple : Un site d’apprenmssage en ligne permet aux umlisateurs de se connecter
avec un mot de passe. ❌ Mauvaise approche (stocker les mots de passe en clair)
car si la base de données est compromise, tous les mots de passe sont exposés.
✅ Bonne approche (hachage sécurisé avec bcrypt) car même si la base est piratée,
les mots de passe restent protégés.

5. Vérification – Test de sécurité :

o Tests statiques du code pour détecter des vulnérabilités avant l’exécution.
Exemple : Un portail de santé en ligne est testé à Un ouml détecte qu’un mot de
passe est stocké en clair dans le code.
o Tests dynamiques pour simuler des attaques et détecter des comportements
indésirables. (Pen testing) Exemple : Un testeur simule une avaque XSS et
découvre qu’un champ de formulaire est vulnérable.
o Tests de fuzzing pour identifier des failles en injectant des données invalides ou
aléatoires pour voir si l’application plante. Exemple : Des données mal formatées
sont envoyées pour voir si l’application plante.
6. Déploiement :
o Validation finale et correction des failles détectées avant la mise en production.
o Mise en place d’un plan de réponse aux incidents pour gérer les menaces après le
déploiement.
o Exemple : Une application mobile de paiement est sur le point d’être lancée.
L’équipe :
1. Effectue un dernier audit de sécurité.
2. S’assure que toutes les dépendances sont à jour.
3. Ajoute un plan de réponse aux incidents (en cas de faille détectée après le
déploiement).
7. Maintenance :
o Surveillance continue de l’application et mise à jour des exigences de sécurité en
fonction des nouvelles menaces.
o Exemple : Une plateforme de streaming surveille en permanence les tentatives de
connexions suspectes. Un jour, ils détectent un pic d’attaques sur les comptes
utilisateurs et réagissent en :
1. Forçant les utilisateurs à changer leur mot de passe.
2. Renforçant les politiques de connexion.

Le SDL de Microsoft est utilisé comme référence dans l’industrie, mais d’autres frameworks
existent, tels que OWASP SAMM, CLASP, BSIMM, SAFECode.
➡ Pourquoi c’est utile ? Parce qu’intégrer la sécurité dès le début coûte moins cher et évite des
catastrophes plus tard.

SDL Microsoft vs SDL OWASP

Différences Clés:

1. Rigidité vs Flexibilité
o SDL Microsoft : Cadre structuré et rigide, imposant des pratiques strictes à chaque
phase du développement.
o OWASP SAMM : Approche progressive et adaptable selon la maturité de
l’organisation.
2. Formation
o SDL : Exige une formation systématique des développeurs avant le début du
projet.
 o OWASP SAMM : Propose une formation progressive, selon l’évolution de
l’organisation.
3. Modélisation des Menaces
o SDL : Obligatoire et systématique dès la conception.
o OWASP SAMM : Peut être intégrée progressivement, selon les besoins.
4. Tests de Sécurité
o SDL : Intègre des tests automatisés avancés (analyse statique, dynamique,
fuzzing).
o OWASP SAMM : Introduit les tests de manière plus flexible et progressive.

Conclusion: Quel modèle choisir?

• SDL Microsoft est adapté aux grandes entreprises avec des processus bien définis et des
exigences strictes en matière de sécurité.
• OWASP SAMM est plus flexible et convient aux entreprises avec des niveaux de maturité
différents, leur permettant d’évoluer progressivement.

4. Vue d’ensemble des activités de sécurité

L’intégration de la sécurité dans le cycle de développement repose sur plusieurs activités clés :

• Exigences de sécurité : Définition claire des exigences de sécurité et de respect de la vie

privée dès le début du projet.
• Modélisation des menaces : Identification et évaluation des menaces potentielles afin
d’anticiper les risques avant l’implémentation.
• Utilisation d’outils approuvés : Adoption de compilateurs sécurisés, d’analyseurs de code
et d’outils de gestion des vulnérabilités.
• Analyse statique et dynamique:
o L’analyse statique du code permet d’identifier les vulnérabilités sans exécuter
l’application. Analyse automatisée: Exécuter l’outil d’analyse de code et régler
tous les problèmes de violation des régles de sécurité.
o Décider de la fréquence optimale pour réaliser des analyses statiques sans
impacter la productivité.
o L’analyse dynamique teste l’application en cours d’exécution pour détecter des
failles exploitables.
• Tests par injection de fautes (fuzzing) : Simule des attaques en introduisant des entrées
non prévues pour identifier des faiblesses potentielles.
• Plan de réponse aux incidents : Préparation d’un plan d’action en cas de compromission
de l’application.
5. Exemples de bonnes pratiques de sécurité

En appliquant le SDL, on met en place des mesures concrètes :

✔ Limiter les privilèges des utilisateurs pour éviter les abus.

✔ Valider les entrées des utilisateurs pour éviter les injections SQL.
✔ Utiliser des outils de sécurité pour analyser le code.
✔ Faire des tests réguliers pour détecter les failles avant qu’un pirate ne les exploite.
✔ Préparer un plan d’urgence pour réagir vite en cas de cyberattaque.
Séance 3 : Modélisation des menaces

Objectif – Comprendre :
• Ce qu’est la modélisation de menaces
• Comment identifier les menaces avec STRIDE
• Comment prioriser les menaces avec DREAD

La séance abordait plusieurs concepts clés liés à la modélisation des menaces, une discipline qui
permet de relier la gestion des risques et les requis de sécurité dans le cadre du développement
d’applications. Cette approche est essentielle pour identifier et atténuer les risques avant la mise
en production d’une application.

1. Concepts clés de la modélisation des menaces

La modélisation des menaces est un processus structuré qui vise à :

• Identifier les menaces potentielles pour une application.
• Analyser la surface d’attaque, c'est-à-dire les points d’entrée exploitables par un
attaquant.
• Prévoir les mesures de sécurité nécessaires pour atténuer ces menaces.
• Démontrer la sécurité aux auditeurs et aux parties prenantes.

Elle est particulièrement importante en sécurité applicative, car 50 % des vulnérabilités se

trouvent dans l’architecture et non seulement dans le code.

2. Menace vs. Vulnérabilité vs. Risque

Une vulnérabilité est une faille ou une faiblesse dans la conception, la mise en œuvre ou le
fonctionnement et la gestion d’un actif qui pourrait être exploitée par une menace.
Une menace est la possibilité pour un agent de menace d'exploiter une vulnérabilité.
Un risque est le potentiel de perte lorsque la menace se réalise.
Les acteurs de la cybermenace, également appelés acteurs malveillants, sont des personnes ou
des groupes qui exploitent les vulnérabilités de sécurité dans les systèmes, les appareils, les
logiciels ou les processus administratifs, dans le but de voler des données sensibles ou de
perturber les opérations commerciales.

Les acteurs de la menace peuvent avoir des motivations financières, idéologiques ou politiques,
et leurs motivations déterminent le résultat de l'attaque.

• Crime organisé : Les auteurs de menaces qui entrent dans cette catégorie ont des
motivations financières.
• Acteurs de l'État-nation : Le gouvernement d'un pays finance ces acteurs menaçants pour
qu'ils se livrent au sabotage ou à l'espionnage. Ils ciblent les infrastructures d'un autre
pays pour voler des secrets ou saper des opérations.
• Cyberterroristes : Les cyberterroristes politiquement motivés ciblent les agences
gouvernementales et les infrastructures critiques, perturbant les activités pour causer des
dommages physiques ou économiques. Aucun gouvernement ne les finance
officiellement.
• Hacktivistes : Les hacktivistes sont des individus ou des groupes aux motivations
idéologiques qui ciblent les gouvernements ou les entreprises, dans l'espoir de perturber
les opérations ou d'endommager les données. Bien qu'ils ne soient pas motivés
financièrement, ils veulent causer un préjudice financier en interrompant leurs activités.
• Insiders malveillants : Les menaces internes malveillantes peuvent ne pas être
sophistiquées, ayant généralement un accès légitime aux systèmes parce qu'elles sont un
employé ou un sous-traitant. Des initiés malveillants ciblent leur propre organisation,
cherchant à voler la propriété intellectuelle ou les secrets commerciaux. Il peut s'agir d'un
employé mécontent ou d'une personne qu'un concurrent paie pour voler les
informations.
• Amateurs de sensations fortes : Les amateurs de sensations fortes sont des acteurs de la
menace motivés en interne qui attaquent les systèmes justes pour voir s'ils peuvent les
compromettre. Bien qu'ils n'aient pas l'intention de causer des dommages, ils peuvent
néanmoins endommager les données, voler des informations ou perturber les activités
commerciales. Ils possèdent différents niveaux de compétence et de sophistication.

**Est-ce qu’un employé qui commet une erreur est un acteur malveillant? NON…À moins que
cela soit intenmonnel.

Qui fait la modélisa?on des menaces?

• Expert en sécurité
• Expert technique (architecte, developpeur, réseau, operamons, etc.)
• Le/La responsable d’une applicamon

Quand est-ce qu’on fait la modélisa?on des menaces?

Dès la phase de conception d'une application et tout au long de son cycle de vie pour anticiper
et atténuer les risques.

Est-ce que cela s’applique quand on achète une solu?on?

Oui, il est important d’évaluer les risques de sécurité d’un logiciel avant de l’acheter et de
l’intégrer à un système.

Comment fait-on de la modélisa?on de menaces?

La modélisation des menaces peut être réalisée à travers deux approches principales :
conversation et entrevue.

1. Conversation

Cette approche consiste à explorer les menaces potentielles de manière collaborative et itérative.
Elle comprend trois éléments clés :

• Explorer des idées : Brainstorming pour identifier les menaces potentielles.

• Prototypes : Création de maquettes ou schémas pour visualiser les attaques possibles.
• Expérimentations : Tester des hypothèses et voir comment les menaces pourraient se
concrétiser.

📌 Objectif: Encourager la créativité et anticiper les scénarios d’attaque possibles.

Exemple : Sécurité d’un système de gestion des employés

• Idée explorée : Un ancien employé pourrait conserver l’accès après son départ.
• Prototype : Modélisation du cycle de vie des comptes utilisateur.
• Expérimentation : Test de connexion après désactivation du compte.
• Résultat : Mise en place d’une revue automatique des accès et d’un processus de
désactivation immédiate.

2. Entrevue

Cette méthode repose sur un dialogue structuré avec des parties prenantes clés.
Elle comprend deux étapes :

• Sujet déterminé : Cibler un aspect spécifique de la sécurité (ex. protection des données,
authentification).
• Revue : Examiner les résultats, valider les hypothèses et ajuster la stratégie de sécurité.

📌 Objectif: Obtenir des informations précises auprès d’experts et valider les hypothèses
identifiées lors des conversations.
Exemple : Sécurité d’un cloud public

• Sujet déterminé : Sécurisation des données sensibles stockées dans le cloud.

• Entrevue avec un expert en cybersécurité :
o Question : Comment s’assurer que les données sont protégées en cas de fuite ?
o Réponse : Mise en place d’un chiffrement côté client avant envoi vers le cloud.
• Revue : Vérification que le chiffrement est bien appliqué et conforme aux normes ISO
27001.

Quels ou?ls sont u?lisé pour la modélisa?on des menaces?

ModélisaFon des menaces

Deux grandes étapes:
• Iden?fica?on des menaces
o STRIDE “Microso' introduced its STRIDE (Spoofing, Tampering, Repudia;on,
Informa;on Disclosure, Denial of Service, and Eleva;on of Privilege) threat
modeling methodology in 1999."
• Priorisa?on des menaces
o DREAD “is a quan;ta;ve risk analysis that rates, compares and priori;zes a
cyberthreat's severity.”
Pourquoi doit-on prioriser les menaces?

La priorisa?on des menaces est essenmelle pour op?miser les efforts de sécurité et réduire
efficacement les risques. Voici les raisons principales :

1. Limiter l’impact des attaques

→ Traiter en priorité les menaces les plus critiques réduit les conséquences sur l’entreprise.

2. Optimiser les ressources

→ Toutes les menaces ne peuvent pas être corrigées immédiatement. Il faut allouer les efforts
là où l’impact est le plus fort.

3. Réduire les risques de sécurité

→ Se concentrer sur les vulnérabilités les plus exploitables empêche les attaques les plus
probables.

4. Assurer la conformité réglementaire

→ Certaines menaces doivent être corrigées en priorité pour respecter des normes de sécurité
(ISO 27001, NIST, RGPD).

5. Éviter les interruptions critiques

→ Corriger les menaces qui peuvent provoquer des interruptions de service (ex : attaque par
déni de service).

Les meilleures pra?ques pour la modélisa?on des menaces

• Commencer tôt dans le processus de développement d’une applicamon

• Impliquer plusieurs personnes dans le processus
• Éduquer les différentes personnes impliquées dans le processus (parme prenante)
• Évaluer la tolérance au risque de votre organisamon

3. IdenFficaFon des menaces avec STRIDE

STRIDE signifie Spoofing, Tampering, Repudia?on, Informa?on divulga?on, Denial of service

(DOS) and Eleva?on of privilège, développé par Loren Kohnfelder et Praerit Garg en 1999.

But : Pour idenmfier les vulnérabilités et menaces potenmelles pour les produits de l'entreprise.
La méthodologie STRIDE de Microso‚ vise à garanmr qu'une applicamon répond aux exigences de
sécurité de confidenmalité, d'intégrité et de disponibilité (CIA), outre l'autorisamon,
l'authenmficamon et la non-répudiamon.

L’objectif est de cartographier ces menaces sur l’architecture d’une application.

Exemple de Spoofing:
• Une avaque par usurpa?on d’iden?té peut inclure le SIM swapping ou le vol de mots
de passe.
• Une altéra?on peut être la modifica?on d’une base de données sans autorisamon.