Disclamer

Encore un blog-post plein de mémes, mais tout de même avec du sérieux dedans ... comme d'habitude s'essaie de faire passer un message ! C'est aussi mon deuxième poste sur ce sujet, mais ce coup-ci abordé d'une autre manière !

Introduction

S'il y a bien un sujet commun à tous les domaines de la cybersécurité c'est bien l'analyse de risques, d'ailleurs ce n'est pas limité à la cybersécurité ;), et si une chose liées à l'analyse de risques qui est importante dans l'AppSec c'est le Threat Modeling.

Dans cet article je vais tenter de revenir aux bases, à expliquer où se situe ces activités dans le cycle de développement logiciel et aussi en quoi il est important (même si j'ai déjà abordé le sujet rapidement ici).

C'est parti je vous souhaite une bonne lecture, et n'hésitez pas à laisser un commentaire.

Quand ?

Commençons par déjà parler de quand faire ce type d'activité, donc attention ici je vais faire une généralité mais vous verrez lorsque nous irons dans le détail de ces activités que ce n'est pas forcément aussi simple. Alors dans un S-SDLC classique vous les mettriez ou vous les activités liées aux analyses de risques ?

... je suis sûr que vous avez une petite idée ...

Bien évidemment ce n'est pas la bonne réponse :).

Si nous prenons ce SDLC classique:

• Planification
• Conception
• Développement
• Tests
• Déploiement
• Maintenance

Alors nos activités auront lieu lors des phases de planification et de conception, et aurons aussi des impacts sur les tests, mais nous y reviendrons.

Profil de risque

La première étape est de définir le profil de risque de l'application et de le maintenir à jour. Alors qu'est-ce qu'un profil de risque ?

Globalement c'est une méthodologie à employer pour définir quels serait les impacts sur la société en cas d'incidents de sécurité sur l'application et aussi de définir l'éventuelle motivation des menaces.

En gros pour faire cela il faut définir un questionnaire, et pourquoi pas utiliser le même pour toutes les applications d'une même société, qui prend en compte plusieurs points, disons à minima:

• Les besoins d'intégrité, de confidentialité et de disponibilité de l'application
• Les besoins de conformité de l'application (y compris la gestion des données à caractère personnel)
• Les impacts (image, juridique, financier) en cas d'attaques réussies ou de non-conformités avérées
• La criticité des données gérées par l'application
• L'exposition
• L'éventuelle motivation pour des attaquants

Ce profil doit être revu régulièrement et des processus doivent être mis en place pour s'assurer qu'en cas de changement important ce profil soit revue. Exemple tout bête mais simple: une application normalement installée "on-premise" qui devient exposée sur Internet, son profil de risque change à coup sûr.

Alors à quoi sert ce profil, soyons clair la cybersécurité c'est aussi un gros problème de ressource, du coup certaines activités pas forcément considérées comme obligatoires peuvent être réservées à des applications avec des profil de risque considéré comme élevé !

Bon pour le coup, là il y a quelques informations, c'est un profil (bon tinder) mais pas sûr que ce soit un bon framework :).

Mais qui doit le définir ça ?

A minima:

• Product Owner
• Product Manager
• Dev Lead
• Un security officer ou quelqu'un de la GRC

Analyse des risques

Certainement un des points essentiels ! Et assez long à faire, et à revoir régulièrement.

En soit l'analyse de risque se fait au niveau produit et commence au niveau de la planification, se poursuit lors de la conception et a des impacts sur la conception et les tests !

Alors l'analyse des risques il existe beaucoup de framework pour faire cela, je ne vais pas en conseiller un, alors je sais on va me dire ... Ouin ouin EBIOS, ok mais en dehors de la France ?

Donc je vais définir les éléments qu'il faut revoir pour pouvoir faire une analyse de risques constructive. Déjà il vous faut le profil de risques ça va aider !

Ensuite: un risque c'est (quand on parle d'un attaquant humain, ou programmer par un humain):

• Une source de menace
  • Avec des caractéristiques: connaissances techniques, moyens, motivations
    • Le threat intelligence peut aider là
  • Qui va avoir un probabilité de vouloir et pouvoir lancer une:
• Evénement de menace
  • Avec certaines actions techniques ou non à exécuter
  • Qui vont avoir une probabilité de pouvoir exploiter:
• Une vulnérabilité (ou faiblesse)
  • Dans des conditions techniques (ou non) particulières
  • Avec des contrôles de sécurité avec un certain niveau de sécurité (ou pas)
  • Ce qui va causer:
• Des impacts
• Et donc la combinaison des différentes probabilités et de l'impact cela donne un risque !

A vous de définir vos matrices de calcul de risques, ou d'utiliser certaines déjà existantes !

Petit exemple: imaginez une application interne, qui regroupe les avis des managers sur les employés ainsi que les salaires, développez par des devs non formés, sans SAST, DAST et code review, et pas de WAF pour la protéger. Dans une entreprise avec une très bonne sécurité IT (OS mise à jour, segmentation, EDR, ...) mais avec des problèmes sociaux. Du coup avec les premiers éléments on peut se dire que des vulnérabilités basiques type injections sont possibles.

Du coup:

• vulns: oui, et peu de moyens de sécurité
• Impact: fort en cas d'injection (OS command ou SQL disons)
• En cas d'événements de menace la possibilité d'exploitation est forte
• Reste la question de la source de menace:
  • Externe: en direct, avec la segmentation bien faite: peu de chance
  • Externe: via une compromission d'un poste utilisateur: possible voir certains, mais les évènements de menace seront moins probable sans détection
  • Interne (evil user): alors la oui ... je dirais même qu'il y a de grandes chances que cela arrive :)

J'avoue c'est un exemple assez con mais cela montre la philosophie. Et d'ailleurs peu de gens vont perdre du temps à faire des analyses de risques sur des applications internes s'ils travaillent dans une entreprise avec une ambiance de m***e et des problèmes sociaux (à part les RH et la finance peut être). Eh oui le facteur humain est très important dans le domaine de la cybersécurité.

Pour faire une bonne analyse de risques il vous faut les bonnes personnes et les bonnes données, donc une architecture logicielle à jour et aussi: un ou des architectes, dev lead, des développeurs, un ou des experts sécurité, product owner et manager et un modérateur, qui pourquoi pas est un expert cyber (technique ou GRC) et là vous pouvez bosser !

Préparer à l'avance des questions selon le type d'application mais les points à aborder:

• Le S-SDLC en place
• Revue de l'archi (j'en parle un peu ici)
• Gestion de l'authentification, des autorisations, contrôle d'accès et des sessions
• Gestion des entrées/sorties
• Gestion des erreurs et des traces
• Cryptographie (in transit ou at rest)
• Gestion des fichiers et des uploads
• Gestion des composants tiers
• Gestion des APO
• Environnement de déploiement

Et se référer à des standards bien connues (NIST/CIS/ASVS).

Vous l'avez compris ça peut être long et pénible mais c'est essentiel. Après devinez quoi il faut revoir cela de temps en temps et surtout le maintenir à jour, si dans la vie de l'application un nouveau risque est détecté alors il faut l'ajouter à l'analyse de risques globale de l'application !

Alors pourquoi c'est si important, j'en ai déjà parlé dans d'autres articles: si vous ne faites pas cela vous pouvez créer une application avec une architecture POURRIE ! Et là pour rattraper le coup bon courage !

Autant dire que vous allez vous arracher les cheveux et être bien dans la m !

Alors j'ai parlé de mettre à jour l'analyse des risques et une des réponses c'est le Threat Modeling et les Evil user stories !

Threat modeling et Evil user stories

Alors j'avoue les evil user stories j'en ai déjà parlé ici, mais comme toujours du rappel ça ne fait pas de mal !

Alors en soit le Threat Modeling c'est juste modéliser le risque, en gros faire des dessins (Wouah merci capitaine évidence), mais en réalité par abus de langage, lorsque l'on parle de threat modeling dans le milieu de l'AppSec on parle très souvent de petits threat assessments au niveau d'EPICs ou de Stories (dans le monde Agile).

Ici il y a plusieurs choses à faire: déjà revoir régulièrement avec les architectes et les experts cyber le backlog pour détecter les EPICs qui peuvent avoir un impact sécu et donc ceux sur lesquels il faut faire ce fameux threat assessment de manière systématique et avec les architectes: modéliser les risques, les valider (ou pas) et prendre des décisions, définir les spécifications à implémenter etc.

Quelques bonnes idées pour la modélisation:

• Les data-flow diagram
• Modélisation type Quality attribut
• Evil user story

Quoi qu'il en soit en plus de la validation du blacklog avec les experts sécurité il est vraiment nécessaire d'apprendre aux équipes de développement à penser à chaque fois ceci:

• Sur quoi travaillons nous ?
• Qu'est-ce qui peut partir en vrille ?
• Qu'est-ce que l'on fait pour pas que cela arrive ?
• Est-ce que l'on a fait du bon boulot ?

En cas de toute ils doivent contacter les équipes AppSec pour conseil !

Pour effectuer du threat modeling, et pour savoir si l'on fait du bon boulot il est aussi nécessaire de se faire des (mini-)checklists, par exemple basée sur STRIDE: 

1. Spoofing (usurpation d'identité)

• Est-ce que le système authentifie correctement les utilisateurs ?
• Y a-t-il des mécanismes pour éviter l'usurpation d'identité (ex. : authentification multifactorielle) ?
• Les certificats ou tokens d'authentification sont-ils protégés contre le vol ou la falsification ?
• Les utilisateurs internes sont-ils soumis aux mêmes standards de sécurité que les utilisateurs externes ?
• Les sessions sont-elles bien gérées (ex. : expiration, renouvellement) pour éviter leur détournement ?

2. Tampering (altération)

• Les données sont-elles protégées contre la modification non autorisée (ex. : intégrité des données, hachage) ?
• Les messages ou les fichiers échangés sont-ils signés ou chiffrés pour éviter leur modification en transit ?
• Les contrôles de version ou d’intégrité sont-ils en place pour détecter les altérations ?
• Les journaux sont-ils protégés contre les modifications non autorisées ?
• Y a-t-il des mesures en place pour protéger l'intégrité du code source ou des exécutables ?

3. Repudiation (dénégation)

• Le système enregistre-t-il correctement toutes les actions importantes (audit log) ?
• Les journaux sont-ils immuables ou protégés contre les altérations ?
• Les actions critiques sont-elles associées de manière unique à un utilisateur ?
• Les utilisateurs peuvent-ils prétendre ne pas avoir effectué une action, et si oui, comment cela est-il géré ?
• Le système fournit-il des preuves (ex. : signatures numériques) pour les transactions critiques ?

4. Information Disclosure (divulgation d'informations)

• Les données sensibles sont-elles chiffrées en transit et au repos ?
• Les autorisations d'accès aux données sont-elles correctement définies et appliquées ?
• Y a-t-il des mécanismes pour détecter ou empêcher la fuite de données ?
• Les utilisateurs ont-ils accès seulement aux informations qui leur sont nécessaires ?
• Les informations sensibles (ex. : mots de passe, numéros de carte de crédit) sont-elles masquées dans les interfaces utilisateur ?

5. Denial of Service (déni de service)

• Le système est-il protégé contre les attaques de type DDoS (Distributed Denial of Service) ?
• Y a-t-il des mécanismes de limitation de taux pour éviter l'épuisement des ressources (ex. : CPU, mémoire) ?
• Les services critiques disposent-ils de redondance ou de sauvegardes pour maintenir la disponibilité ?
• Les ressources critiques sont-elles surveillées pour détecter une surcharge ou un usage anormal ?
• Le système peut-il détecter et répondre aux tentatives d'épuisement des ressources (ex. : basculement, mise en cache) ?

6. Elevation of Privilege (élévation de privilèges)

• Les utilisateurs et les processus disposent-ils du minimum de privilèges nécessaires pour accomplir leurs tâches ?
• Les mécanismes de contrôle d'accès sont-ils robustes et testés contre les tentatives d'escalade de privilèges ?
• Les privilèges d'administration sont-ils bien contrôlés et accordés uniquement lorsque nécessaire ?
• Y a-t-il des mesures pour prévenir les exploits utilisant des vulnérabilités connues pour élever des privilèges ?
• Les processus d'approbation ou de revue pour les demandes d'élévation de privilèges sont-ils en place et efficaces ?

Et enfin pour être optimal quelques derniers conseils:

• Faites des questionnaires communs à toutes les applications (pourquoi par type d'application)
• Faites en sorte que ce soit une action obligatoire dans le SDLC de toutes les équipes
• Partager les retours, les correctifs et les bonnes pratiques de sécurité et RETEX
• Former et sensibiliser les équipes à cette pratique
• Utiliser des outils de modélisation comme Threat Dragon

Que faire par suite

Je l'ai déjà dit dans d'autres articles mais je vais le répéter, un risque peut être:

• Accepté
• Réduit
• Eliminé
• Transféré

Mais en gros si le risque n'est pas éliminé il doit alors être validé par le business !

Mais aussi n'oubliez pas pour valider la correction, ou la gravité d'un risque quelques actions supplémentaires :

• Pentest
• DAST scan
• Secure code review

Ce qu'il faut éviter ...

• Ne pas rendre cela trop lourd, faire le l'over-engineering
• Former et expliquer le pourquoi aux différents acteurs
• Ne pas envoyer en tant que security experts soit:
  • Des gens personnes trop techniques non motivées (ou alors les motivées pour le faire: en disant que par la suite ça servira à des actions techniques)
  • Des juniors vendus comme des experts GRC qui finalement n'apporteront rien

Pour résumer

Faites des analyses de risques et maintenez les à jour !

Et sinon:

• Une évaluation de base du risque de l'application est effectuée
• Mettre en place des checklists
• Toutes les applications sont contrôlées et les risques centralisés
• Standardiser les actions de threat modeling/assessment
• Revoir régulièrement les profils de risques et les risques
• Revoir et optimiser les processus de gestion de risques et outils utilisés, essayer d'automatiser au maximum même si cela n'est pas forcément facile

Legal

Voilà, ce texte est bien sûr en licence CC BY-SA 4.0 (legal)

Les images de type mémes ont été générées avec memegenerator, les autres images sont libres de droits et/ou appartiennent à leurs propriétaires respectifs.