Threat Modeling et méthodologie

Transcription

1 Threat Modeling et méthodologie Naïm Qachri & Frédéric Pluquet Année Académique

2 Sommaire Threat Modeling Modélisation et récolte d information des menaces Analyse du modèle Documentation/validation des vulnérabilités Méthode ebios

3 Le Threat Modeling Le «Threat Modeling» est une méthode qui a été développée en entreprise par Microsoft dans le but d intégrer la sécurité dès le design d un projet (début 2000). Cette modélisation permet d intégrer tout une série de documents et de spécifications pouvant aider les développeurs et les testeurs dans un développement aussi bien agile qu itératif.

4 Le Threat Modeling: les avantages L avantage de cette méthode, c est qu elle adopte une perspective défensive plutôt qu une perspective attaquante. Réduction des coûts de développement: on code la sécurité plutôt que la «patcher». Conscientisation de l équipe de développement.

5 Attention!! Utiliser le «Threat Modeling» peut donner une fausse impression de sécurité.

6 Attention!! Utiliser le «Threat Modeling» peut donner une fausse impression de sécurité. CONCLUSION: Utiliser une seul perspective ne suffit pas à couvrir les menaces inconnues!!

7

8 Les identifiants Les identifiants que nous assignerons dans les modélisations n impliquent ni une hiérarchie, ni une quelconque notion de priorité.

9 Sommaire Threat Modeling Modélisation et récolte d information du système Analyse du modèle Documentation/validation des vulnérabilités Méthode ebios

10 Modélisation et récolte du système Le système de modélisation se découpe en plusieurs documents: le document d information sur le Threat modeling du système; les scénarii d utilisation; les dépendances externes au système modélisé; les hypothèses d implantation; les notes de sécurité internes et externes; les niveaux de confiances; les points d entrées; les «assets» (ou actifs du système).

11 Le document d information Ce document reprend les informations du système que l on modélise: la version; le directeur de projet et les participants; les relecteurs éventuels du projet; la localisation du développement et déploiement du projet; une brève description du projet.

12 Exemple Etape de développement : Version 1.0 Directeur: Naïm Qachri Participants: Frédéric Pluquet et Tito Puente Relecteur: Tom Grisby Localisation: BDD inc. /Serveur interne de traitement des données de RD Description: La société BDD inc. a créée une application client-server en interne pour traiter les informations clients des différents consultants de l entreprises. Une partie de ces données peuvent être manipulées directement par le client, d autres sont consultables et manipulables par le consultant pour son compte propre.

13 Les scénarii d utilisation Ce document reprend les différents scénario auquel est soumis le système: Un identifiant de scénario; Une description du scénario d utilisation du projet considéré.

14 Exemple ID: 1 Description: L application sera installé sur un server de pages web. Ce server ne sera accessible en interne que depuis une zone sûre confinée derrière un NAT-box. ID: 2 Description: Pour un accès extérieur on mettre en place un système VPN qui se connectera à un proxy. Ce dernier filtrera les requêtes de façon à n avoir que des requêtes de type lecture.

15 Les dépendances externes Ce document reprend les dépendances externes auxquelles sera soumis notre système: un identifiant; une description.

16 Exemple ID: 1 Description: La sécurité de l application développée dépend de la sécurité du serveur de page web utilisé. ID: 2 Description: La sécurité des requêtes extérieurs dépend du système «firewall» utilisé

17 Les hypothèses d implantation Ce document reprend les différents hypothèse de travail faite au cours du développement du système Chaque hypothèse se compose d un identifiant unique et d une description

18 Exemple ID: 1 Description: Si des communications chiffrées interviennent dans les communications, alors le protocole d échange de clé devra suivre les standards industrielles et de bonnes pratiques.

19 Les notes de sécurité externes Les notes de sécurité externes touchent à la sécurité extérieur de l application. Ces notes possèdent: un identifiant; une description, voir la note elle-même. Elles représentent les informations de sécurité dont doit être conscient les utilisateurs du logiciel, système, bibliothèque,... etc.

20 Exemple ID: 1 Description: Le serveur web n a pas de système intégré de renforcement des password et l application ne couvre pas l authentification, donc l utilisateur doit être conscient que le mot de passe créé doit être solide

21 Les notes de sécurité internes Les notes de sécurité externes touchent à la sécurité extérieur de l application. Ces notes possèdent: un identifiant une description Contrairement aux notes de sécurité externes, les notes internes ne concernent que les personnes utilisant ou développant le modèle des menaces. Elles servent à expliquer les choix et les décisions prises sur le design ayant un impact sur la sécurité du système développé.

22 Exemple ID: 1 Description: Le système utilisent le système interne de courrier basé sur SMTP. Ce systèmes est géré par un autre groupe de l entreprise et se trouve en DMZ. C est pour cela que nous ne prenons pas en compte le server mail dans le modèle de menace

23 Les niveaux de confiances Les niveaux de confiances reprennent les différents acteurs intervenant dans le système tel que les utilisateurs, administrateurs, le serveur de base de données... Chaque niveau de confiance est décrit avec: un identifiant; un nom pour le niveau considéré; une description.

24 Exemple ID: 1 Nom: l identité du processus du server web Description: cette identité est utilisée pour authentifier un serveur web à sa base de donnée quand ce dernier stocke et récupère de l information ID: 2 Nom: le consultant Description: ce dernier utilise son accès pour consulter les informations de ses clients et des contrats qu ils ont actuellement avec BDD inc. ID: 3 Nom: un utilisateur http Description: c est un utilisateur qui accède à une page via HTTP

25 Les points d entrées Les points d un programme, d une application ou d un système correspondent aux points par lequel nous pouvons accéder au système modélisé. Chaque point d entrée est décrit par: un identifiant (qui peut être hiérarchique dans ce cas-ci); un nom; une description; les niveaux de confiance qui ont accès à ce point d entrée

26 Exemple ID: 1 Nom: page de Login Description: page interne à partir de laquelle les utilisateurs peuvent se connecter ou créer un login pour accéder à l application Niveau de confiance: les consultants (1), les clients(2) ID: 1.1 Nom: fonction CreateLogin Description: fonction qui crée un nouvel identifiant pour un client Niveau de confiance: les clients(2)

27 Les «assets» (les actifs) Les «assets» représentent les actifs et avoirs du programme ou du système modélisé, c est à dire qui est contenu et doit être protégé aussi bien d un point de vue passif (information de login) qu actif (la disponibilité du site). Cette information est décrite également par: un identifiant (hiérarchisable); un nom; une description; et le niveau de confiance touché par cette actif.

28 Exemple ID: 1 Nom: Les consultants et les clients Description: Tout les actifs touchant aux consultants et aux client de BDD inc. Niveau de confiance: les consultants (1), les clients(2) ID: 1.1 Nom: les données de login des utilisateurs Description: Le nom d utilisateur et le mot de passe Niveau de confiance: un utilisateur avec des accès vérifiés (1), l administrateur de la base de données (2)

29 Exercice: On vous demande de modéliser et récolter les informations pour le système suivant. On souhaite développer un logiciel de chat (conversations) ayant les caractéristiques suivantes. Un serveur central reçoit les demandes des clients: la connexion via un login et un mot de passe l envoi d un message à tous les clients connectés l envoi d un message privé à certains clients (via leur logins) Le serveur s occupe d envoyer les messages aux applications clientes destinataires qui affichent les messages reçus. Chaque message contient un message texte et un fichier ou une adresse web peuvent lui être attaché. L administrateur du système se connecte comme tous les autres utilisateurs avec un login/mot de passe prédéfini (genre admin/admin) et peut supprimer les messages qu il désire.

30 Sommaire Threat Modeling Modélisation et récolte d information du système Analyse du modèle Documentation/validation des vulnérabilités Méthode ebios

31 L analyse du système Une fois le recensement des informations effectués, l analyse a pour but de modéliser le système afin d expliciter comment les messages transitent entre les différents acteurs du système. Pour cela, le «Threat Modeling» a mis en place trois outils: les diagrammes de flots de données; la documentation des menaces potentielles; les arbres de menaces;

32 Le diagramme de flot de données Le diagramme de flot de données vise à modéliser un programme sous la forme d un diagramme de processus. Cette représentation des processus permet d étudier les interactions entre les entités extérieures et intérieures au système.

33 Le diagramme de flot de données Processus interne à la modélisation Eléments externes et passifs Echanges et délimitations 1.1 processus Entité Externe Flux de donnée 1. multiple processus Enregistrement de donnée Frontières entre les privilèges

34 Clients Exemple Frontières Utilisateurs/Web server Consultants réponses requêtes requêtes réponses Processus central décomposable Page web sur le disque pages 1. Server Web application interne BDD inc. Notification d' appels de procédures données 2. Server de base de donnée Server SMTP Frontière Web Server/SMTP données données données utilisateurs

35 Les menaces Sur base des documents, nous établissons les menaces. Chacune des menaces doit être décrite dans un document. Chaque document décrit la menace sous la forme suivante: un identifiant, le nom, la description; une classification STRIDE la menace est-elle évincée? Connaissance sur la mitigation. notes d investigation points d entrées liés à la menace les actifs («assets») l arbre de menaces lié (si il y en a un)

36 La classification STRIDE Cette classification permet de classer les menaces en plusieurs grandes familles S: Spoofing T: Tampering R: Repudiation I: Information disclosure D: Denial of service E: Elevation privilege

37 Exemple: Menace-Vol d identifiant de session ID: 1 Nom: L adversaire acquiert l identifiant de session d un autre utilisateur Description: Un attaquant acquiert un identifiant actif de session d un utilisateur valide (client ou consultant) Classification STRIDE: E (Elévation de privilège) Evincement connu: Le site dépend de la sécurité cryptographique des outils fournis par le serveur de pages web. De plus, l utilisateur ne peut acquérir un identifiant de session qu à travers la page de login.... Notes d investigation: la configuration Apache idéale révèle... Points d entrées: (8) Les ports sur écoute du serveur web (HTTPS) Actifs: (15.3) Login de session Arbre de menace: Aucun

38 Les arbres de menaces 1. Menace Racine AND 1.1 condition non évincée 1.2 Condition non évincée condition évincée 1.3 condition évincée

39 Notation DREAD La méthode DREAD caractèrise le risque associé à une vulnérabilité. C est une mesure du risque de sécurité. Elle se calcule sur base de la moyenne des valeurs assignées à chacune des catégories suivantes: Damage ponetential Reproductibility Exploitability Affected users Discoverability

40 Exemple Menace: L'adversaire retrouve les données personnelles de l'utilisateur 1.1 (DREAD: 0) l'adversaire a un accès direct au serveur SQL 1.2 (DREAD: 0) l'adversaire a un login valide pour le site web et un accès à la page d'entrée de données condition évincée *M* (DREAD: 0) l'adversaire a un login SQL valide (DREAD: 0) l'adversaire fait appel à la procédure récupérant les données personnelles (DREAD: 0) l'adversaire ajoute d'autres nom utilisateur pouvant utiliser la procédure de récupération de données 1.3 *M* (DREAD: 0) L'adversaire acquiert les données d'un autre utilisateur ou son identifiant de session

41 Exercice Veuillez dessiner le diagramme de flux de données pour le scénario de l exercice précédent. Veuillez décrire une menace en particulier en lui assignant une classification STRIDE et en essayant d évaluer une note DREAD. Sur base de la menace précédente, essayer de construire l arbre lié.

42 Sommaire Threat Modeling Modélisation et récolte d information du système Analyse du modèle Documentation/validation des vulnérabilités Méthode ebios

43 Vulnérabilité Une menace devient une vulnérabilité si il existe un chemin allant de la menace racine à une condition (feuille) non-évincé. Elles font l objet d un numéro de bug report comportant: un identifiant de bug, son nom, un identifiant de vulnérabilité, un nom, une description; sa classification STRIDE, sa notation DREAD et l identifiant de la menace liée correspondante.

44 Sommaire Threat Modeling Modélisation et récolte d information des menaces Analyse du modèle Documentation/validation des vulnérabilités La méthode ebios

45 Méthode ebios EBIOS (Extension des besoins et identification des objectifs de sécurité) est une méthodologie développée par l agence nationale de la sécurité des systèmes d information Elle représente une méthodologie visant à effectuer la gestion des risques

46 ANSSI/ACE/BAC EBIOS Méthode de gestion des risques 25 janvier 2010 Démarche itérative de la méthodologie 3 Description de la démarche Ce chapitre présente les cinq modules de la méthode EBIOS : Module 1 Étude du contexte Module 2 Étude des événements redoutés Module 3 Étude des scénarios de menaces Module 4 Étude des risques Module 5 Étude des mesures de sécurité

47 Module 2 Étude des événements redoutés Fiche accompagnant la documentation Module 4 Étude des risques Module 3 Étude des scénarios de menaces d EBIOS Module 5 Étude des mesures de sécurité Chaque activité des cinq modules est décrite sous la forme d'une fiche selon le même formalisme : Objectif But et description de l'activité, replacée dans un contexte général. Avantages Liste des principaux avantages apportés par la mise en œuvre de l'activité. Données d'entrée Liste des informations d'entrée, nécessaires à la mise en œuvre de l'activité. Actions préconisées et rôle des parties prenantes Liste des actions préconisées et responsabilités génériques pour réaliser l'activité : - "R" = Responsable de la mise en œuvre de l'activité - "A" = Autorité légitime pour approuver l'activité (imputable) - "C" = Consulté pour obtenir les informations nécessaires à l'activité - "I" = Informé des résultats de l'activité Les fonctions génériques, qui peuvent endosser ces responsabilités, sont les suivantes : - Responsable = Responsables du périmètre de l'étude - RSSI = Responsable de la sécurité de l'information - Risk manager = Gestionnaire de risques - Autorité = Autorités de validation - Dépositaire = Dépositaire de biens essentiels (utilisateurs ou maîtrises d'ouvrage) - Propriétaire = Propriétaire de biens supports Données produites Liste des informations de sortie, produites par les actions de l'activité. Communication et concertation Liste des principales idées pour obtenir de l'information (techniques à employer) et la restituer (présentation des résultats, représentations graphiques ). Surveillance et revue Liste des points de contrôle pour vérifier la qualité de la réalisation de l'activité et la tenue à jour des informations résultantes. Propositions pour mettre en œuvre les actions préconisées Description détaillée de la (des) manière(s) possible(s) de procéder pour mettre en œuvre les actions préconisées.

48 Module 1 : Etude du contexte Ce module a pour objectif de faire un collecte des éléments pouvant aider à la gestion des risques. On a ainsi la possibilité d adapter cette gestion à la réalité et à la taille du contexte du domaine étudié. Cette étape permet de formaliser le cadre dans lequel évoluera la gestion des risques. Nous devons obtenir un délimitation et une description complète du périmètre d étude.

49 Module 2 : Etude des événements redoutés Ce module a pour objectif d identifier les scénarios génériques à éviter. La réflexion se fait au niveau des biens (assets) et non des supports. Face à ces menaces, le module doit mettre en évidence les impacts et estimer le niveau de gravité et de vraisemblance.

50 Module 3 : Etude des scénarios de menaces Ce module a pour objectif d identifier les modes opératoires génériques d attaque. Ces modes opératoires représentent des scénarios de menace. Cette étape est complémentaire à la précédente puisqu elle insiste sur la technique plus que sur les biens. Nous apportons aussi un estimation du niveau de menace du scénario et le poids que la combinaisons de scénarios peut fait peser sur les biens.

51 Module 4 : Etude des risques Une fois les trois modules finis, nous pouvons mettre en évidence les risques pesant sur le périmètre défini. On peut, dès lors, choisir la manière de les traiter en tenant compte des spécificités du contexte. On identifie au travers de ce module les seuls scénarios réellement pertinents

52 Module 5 : Etude des mesures de sécurité Ce module détermine les moyens qui devront être mis en oeuvre afin de traiter et suivre les risques. On peut ainsi trouver un consensus sur les mesures de sécurités, d en démontrer la bonne couverture et d effectuer la planification et la validation du traitement. On peut également durant ce processus faire un suivi de la mise en oeuvre de ces moyens.

53 Dans le module 1: Collecter de l information Nous tentons de décrire le contexte général: interne: l organisme (sa description, ses ressources, ses aptitudes, ses métiers,...) externe: l environnement social et culturel, politique, légal...etc. les facteurs et tendances ayant un impact sur les objectifs les relations entre les parties prenantes.

54 Dans le module 1: Définition de périmétre d étude Cette phase tend à délimiter le contexte étudié et à démontrer son utilité. déterminer la fonction de ce périmètre formaliser sa contribution au processus métier déterminer une interface avec les autres processus définir les parties prenantes

55 Dans le module 1: Identifier les paramètres On doit prendre en compte le poids qui pèse sur les organismes en cas d échec ou de non respect des contraintes de conformités. Pour cela le système tente d identifier: Les références communautaires, légales et réglementaires; les références internes relatives à la sécurité de l information; les contraintes pesant spécifiquement sur le périmètre de l étude; les hypothèses.

56 Dans le module 1: Identifier les sources de menaces Cette phase vise à identifier les sources potentiels dont peut venir les menaces, leurs origines vis à vis du contexte Par exemple: la manière volontaire ou non de ces sources d agir sur le périmètre. Il faut également, après avoir identifier les sources possibles, retenir celles qui sont pertinentes et leur ajouter un exemple.

57 Dans le module 1: Les métriques et les biens Une fois toute les phases précédentes achevées, il faut préparer les métriques critères de sécurité (au nombre de trois: l intégrité, la disponibilité, la confidentialité). Plus particulièrement, les niveaux d échelles (le temps pour l indisponibilité, les besoins comme la maitrise ou de détectabilité, le niveau de confidentialité) et les niveaux de gravité et de vraisemblances associés aux menaces. Il faut identifier les biens et leur niveau de sensibilité. Pour plus de détails, voir le document original

58 Dans le module 2: Analyse de tous les événements redoutés Cela revient à établir un scénario avec ses besoins de sécurité (voir échelles), ses sources, ses impacts et leur gravités.

59 Dans le module 2: Evaluation de tous les événements redoutés Cela revient, par exemple, à classer les scénarios selon leur gravité.

60 Dans le module 3: Evaluation de tous les scénarios de menaces Cela reprend les différents scénarios, les sources auxquelles elles sont liées et à évaluer leur vraisemblance ( avec une échelle allant de Significative à Forte).

61 Merci pour votre attention