La plupart des problèmes de sécurité commencent bien avant le premier init git. Ils sont liés à des décisions d'architecture, à des hypothèses négligées et à des exigences manquantes. La planification est le point de départ du développement sécurisé, non pas parce que c'est amusant, mais parce que c'est bon marché. Rattraper un modèle d'authentification défectueux lors d'une session de tableau blanc est plus rapide que de corriger une faille de production deux sprints plus tard. Cette section vous montre comment concevoir en gardant à l'esprit la sécurité dès le départ. Vous apprendrez à exécuter une modélisation légère des menaces qui ne craint pas, à rédiger des récits d'utilisateur axés sur la sécurité et à classer les données comme un pro. Pas de blabla. Pas de doctorat requis.

Image de remplacement : Description de l'image : Flux de la phase de conception avec des icônes pour la modélisation des menaces, la classification des données et les modèles de récits d'utilisateurs sécurisés, superposés sur un tableau de planification de sprint.

Modélisation légère des menaces pour les équipes de développement - Pas besoin de doctorat ou d'un atelier de trois jours

Il n'est pas nécessaire de passer des jours à élaborer des arbres d'attaque ou à organiser un atelier de modélisation des menaces avec 14 parties prenantes. Il suffit de s'arrêter et de poser les bonnes questions au bon moment.

Qu'est-ce qui pourrait mal tourner ?

C'est la question qui importe. Que se passe-t-il si un jeton fuit ? Si quelqu'un modifie les données saisies ? Si un utilisateur contourne un contrôle côté client ? Parcourez les flux de base de votre fonctionnalité et percez-en les failles. Vous ne concevez pas pour des utilisateurs idéaux, vous vous défendez contre des abus créatifs. Même 10 minutes de réflexion peuvent permettre de déceler des failles logiques, des validations manquantes ou des limites de confiance évidentes.

Des gains rapides : STRIDE-per-Feature, séances de tableau blanc

Il n'est pas nécessaire de modéliser l'ensemble de l'application. Il suffit de modéliser les nouveaux éléments. Essayez STRIDE par fonctionnalité. Prenez cinq minutes pour vous demander si la fonctionnalité en question introduit des risques d'usurpation, de falsification, de fuite d'informations, de problèmes de privilèges ou de déni de service. Ou prenez un tableau blanc et dessinez le flux de données. Qui parle à quoi ? Où les données de l'utilisateur entrent-elles ? Où devriez-vous mettre en place des contrôles ? Vous serez surpris de voir tout ce que vous pourrez découvrir en ralentissant la cadence et en traçant des lignes.

Intégrer la sécurité dans les récits d'utilisateurs et les exigences

La sécurité ne peut pas se limiter aux documents d'architecture ou au carnet de commandes de l'équipe de sécurité. Elle doit faire partie du flux de travail des développeurs, en commençant par la façon dont vous écrivez les histoires.

"En tant qu'utilisateur, je veux que mes données soient..."

Les récits d'utilisateurs sont un excellent moyen d'intégrer des attentes. Ne vous contentez pas d'écrire "En tant qu'utilisateur, je veux réinitialiser mon mot de passe". Essayez plutôt "En tant qu'utilisateur, je veux que la réinitialisation de mon mot de passe soit sécurisée et protégée contre la force brute". Cette phrase déclenche des discussions sur la limitation du débit, l'expiration des jetons et la journalisation, avant même que le code ne soit écrit. La sécurité devrait faire partie de la définition de ce qui est fait, et non pas être une réflexion après coup, ajoutée à l'assurance qualité.

Classification des données : Savoir ce qui nécessite Fort Knox ou un simple cadenas

Toutes les données ne sont pas égales. Certains champs, comme les noms d'utilisateur, sont publics. D'autres, comme les numéros de sécurité sociale ou les jetons d'authentification, nécessitent un cryptage, un contrôle d'accès et une journalisation stricte. Lors de la planification, posez-vous les questions suivantes : quelles sont les données que nous collectons ? Où sont-elles stockées ? Quel est l'impact d'une fuite de données ? Étiquetez-les en conséquence. Cela vous aidera à concevoir des protections adaptées au risque. Vous n'avez pas besoin d'une stratégie complète de gouvernance des données pour commencer - il suffit d'un peu d'étiquetage et de bon sens.

Le développement sécurisé ne consiste pas à arrêter l'innovation. Il s'agit de poser les bonnes questions dès le début, afin de ne pas avoir à résoudre les problèmes tardivement. 

Passons à la phase du code et parlons de la manière d'écrire une logique sécurisée sans transformer chaque requête en incident de sécurité.