Conception Agile et sécurité

Pour chaque US, identifier les besoins de sécurité en utilisant la matrice DICP :

• [D] Disponibilité : la fonctionnalité peut être utilisée au moment voulu
• [I] Intégrité : les données sont exactes et complètes
• [C] Confidentialité : les informations ne sont divulguées qu’aux personnes autorisées
• [P] Preuve : les traces de l’activité du système sont opposables en cas de contestation

Il est également possible de partir d'un besoin (DICP), et de déterminer les US qui sont concernées par lui.

Recensement des sources de risques –accidentelles ou intentionnelles, externes ou internes– susceptibles d’impacter la valeur d’usage : qui ou quoi pourrait porter atteinte aux besoins de sécurité.

Le schéma ci-dessous résume quelques-unes des motivations à l’origine d’attaques intentionnelles :

Un événement redouté (ER) correspond au non-respect d’un besoin de sécurité. Il peut être exprimé sous la forme d’une expression courtequi permet de comprendre facilement le préjudice lié à la user story concernée.

Exemple :

Consiste à identifier les risques numériques de référence à prendre en compte pour bâtir ou compléter la politique de sécurité du produit.

L’équipe commence par dresser une liste de scénarios de risques –abuser stories– en confrontant les sources de risques , les événements redoutés et les composants vulnérables.