Conception Agile et sécurité

Démarche d'identification et de traitement des risques dans un contexte AGILE.

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 courte permettant de comprendre facilement le préjudice lié à la user story concernée.

Exemple :

Identification des composants du produit :

• infrastructures physiques : bâtiments, locaux, espaces physiques permettant l’activité et les échanges de flux ;
• organisations : structures organisationnelles, processus métiers et supports, ressources humaines ;
• systèmes numériques matériels et logiciels : systèmes informatiques et de téléphonie, réseaux de communication.

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.

Pour chaque abuser story répertoriée, définir si besoin l’option de traitement du risque la plus appropriée

• Eviter,
• Réduire,
• Transférer
• Accepter