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 !