Ajout supports formation DIIAGE (DEV & RES 3)

diiage/C3-2_Sécurité_SI/Sécurité_Informatique_Entreprise/prepa.md

@@ -0,0 +1,7 @@
+# DIIAGE Dev: préparation de la session du 17/11/2017
+
+## Problématiques
+
+- Qu'est ce que la sécurité informatique dans l'entreprise ?
+- Quels sont les objectifs de la sécurité informatique ?
+- Quelles sont les principales failles touchant les applicatifs Web ? Quels sont les risques associés ?

diiage/C3-2_Sécurité_SI/Sécurité_Informatique_Entreprise/qcm.md

@@ -0,0 +1,80 @@
+<style>
+* {
+  font-size: 0.9em !important;
+}
+</style>
+
+# Sécurité des SI et applications Web: questionnaire
+
+- **Nom**
+- **Prénom**
+- **Classe**
+- **Date**
+
+## Consigne
+
+Pour chaque question, entourer **la ou les bonnes réponses, si il y en a**.
+
+**Attention**, certaines questions sont volontairement rédigées sous la forme plurielle. Cela n'implique pas forcément qu'il y a plusieurs bonnes réponses.
+
+## Questions
+
+### A. Dans le contexte de la sécurité informatique, que représente le concept général de "menace" ?
+
+1. Une cause potentielle d'incident, qui peut résulter en un dommage au système ou à l'organisation
+2. Une faiblesse dans un système informatique permettant à un attaquant de porter atteinte à l'intégrité de ce système
+3. Une mauvaise manipulation ou une malveillance entraînant une perte de matériel et/ou de données
+
+### B. Parmi ces réponses, lesquelles sont des objectifs de la sécurité informatique en entreprise ?
+
+1. Maintenir l'intégrité des données
+2. S'assurer du niveaux d'authentification et d'autorisation
+3. Maintenir la disponibilité des services
+
+### C. Qu'est ce que la modélisation de menace ?
+
+1. Un processus permettant d'identifier les menaces mettant en péril un système et d'évaluer les risques et les impacts potentiels de celles ci.
+2. Un document faisant un état des lieux des vulnérabilités d'une application
+3. Un processus de simulation d'attaque organisé pendant un audit de sécurité
+
+### D. Quel est aujourd'hui le principal vecteur d'attaque sur les systèmes d'informations ?
+
+1. La méconnaissance humaine
+2. Les failles "0-day"
+3. La mauvaise sécurisation des environnements "intranet"
+
+### E. Quels sont les risques associés à une mauvaise définition du périmètre d'application de la politique de sécurité en entreprise ?
+
+1. L'application de règles non adaptées aux spécificités des différents contextes fonctionnels/techniques
+2. Une mauvaise formation des collaborateurs face aux risques liés à la sécurité en entreprise
+3. Une mauvaise évaluation des risques liés à chaque contexte de l'entreprise
+
+### F. Parmi ces acronymes, lesquels sont des catégories de failles impactant les applications Web ?
+
+1. SQLI
+2. CSRF
+3. AJAX
+
+### G. Une faille XSS...
+
+1. ...permet d'injecter du code HTML/Javascript dans une page d'une application Web tierce
+2. ...permet d'exploiter les sessions HTTP de l'utilisateur en cours de validité
+3. ...permet d'accéder à des fichiers du serveur en parcourant l'arborescence du système de fichier
+
+### H. Parmi ces pratiques, quelles sont celles qui sont des catalyseurs de risques ?
+
+1. La mauvaise gestion du cycle de vie des dépendances de l'application
+2. Une mauvaise politique de journalisation des opérations de l'application
+3. L'utilisation de plateformes SaaS
+
+### I. Dans le cadre du développement d'une application web, la sécurité de l'infrastructure devraient être abordée:
+
+1. Dès les premières itérations de développement
+2. En conjugant le travail des équipes de développement et les équipes opérationnelles
+3. Analysée par une entité externe à la fin de chaque cycle de développement
+
+### J. Quelles sont les différences fondamentales entre une requête HTTP "POST" et "GET" dans le cadre général des failles de type "Cross Site Request Forgery" (CSRF) ?
+
+1. Les requêtes POST sont chiffrées par défaut par les navigateurs
+2. Une requête POST ne peut pas être automatiquement initiée par la simple inclusion d'une balise HTML
+3. Il n'y a aucune différence

diiage/C3-2_Sécurité_SI/Sécurité_Informatique_Entreprise/tp.md

@@ -0,0 +1,21 @@
+# TP - Réaliser un audit de code
+
+## Objectifs
+
+- Découvrir les différents critères d'analyse d'une base de code tel que préconisés par l'OWASP
+- S'initier à la démarche d'audit de code en reproduisant la démarche proposée par le référentiel ASVS sur une application open-source.
+
+## Contexte et contraintes
+
+- L'audit devra suivre la méthodologie et la classification préconisées par le référentiel [ASVS](https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf). À vous d'en prendre connaissance
+avant de vous lancer dans l'audit réel.
+- Vous pouvez sélectionner n'importe qu'elle application Web à condition qu'elle soit open-source et/ou que vous pouvez fournir un lien vers le dépôt des sources (GIT, SVN, Mercurial...) avec le numéro de version que vous avez audité.
+- Un exemple de rapport d'audit de code est disponible dans votre espace de partage afin de vous aider à construire votre document.
+
+## Production attendue
+
+_Il est bien entendu que je n'attend pas de vous un audit d'une application complète. Dans le temps alloué au TP ce serait impossible (sauf si vous êtes réellement des surdoués dans ce domaine...). Prenez le temps de lire le référentiel dans son ensemble et focalisez vous sur les points qui concernent des failles applicatives._
+
+- Un rapport d'audit de sécurité calqué sur le modèle fourni avec le sujet de ce TP. Pensez bien à identifier l'application testée et sa version. Prenez le temps de rédiger, la qualité primera sur la quantité.
+
+_A l'issu de ce TP, nous ferons un debrief ensemble sur les difficultés que vous avez rencontré et sur les points d'incompréhension._