Différences

Ci-dessous, les différences entre deux révisions de la page.

--- sio:bloc3:agile_security [2023/10/20 01:09] – jcheron
+++ sio:bloc3:agile_security [2024/10/04 08:42] (Version actuelle) – [2 - Sources de risque] jcheron
@@ Ligne 1: / Ligne 1: @@
 ====== Conception Agile et sécurité ======
-<WRAP round bloc>
+<WRAP round bloc info>
 Inspiré du guide "Conception Agile et sécurité" pulié par l'ANSSI.
+[[https://github.com/betagouv/securite-numerique-agile|Repository GitHub]]
 </WRAP>
-===== Besoins de sécurité =====
+Démarche d'identification et de traitement des risques dans un contexte AGILE.
+<html><div class="imageB"></html>{{:sio:bloc3:pasted:20241003-194731.png}}<html></div></html>
+===== 1 - Besoins de sécurité =====
 Pour chaque US, identifier les besoins de sécurité en utilisant la matrice DICP :
@@ Ligne 19: / Ligne 25: @@
-===== Sources de risque =====
+===== 2 - Sources de risque =====
+<WRAP round bloc info>
-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é.
+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é.
+</WRAP>
 Le schéma ci-dessous résume quelques-unes des motivations à l’origine d’attaques intentionnelles :
 <html><div class="imageB"></html>{{:sio:bloc3:pasted:20231020-005917.png?500px}}<html></div></html>
-===== Evènements redoutés et conséquences =====
+===== 3 - Evènements redoutés et conséquences =====
-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.
+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 :
 <html><div class="imageB"></html>{{:sio:bloc3:pasted:20231020-010844.png?500px}}<html></div></html>
-===== Ecosystème et composants vulnérables =====
+===== 4 - Ecosystème et composants vulnérables =====
-<html><div class="imageB"></html>{{:sio:bloc3:pasted:20231020-005917.png?500px}}<html></div></html>
-===== Scénarii de risque : abuser stories =====
+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.
+<html><div class="imageB"></html>{{:sio:bloc3:pasted:20231020-011041.png?500px}}<html></div></html>
+===== 5 - Scénarii de risque : abuser stories =====
 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.
@@ Ligne 42: / Ligne 58: @@
 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.
+<html><div class="imageB"></html>{{:sio:bloc3:pasted:20231020-011156.png?500px}}<html></div></html>
+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