Réalisation d’un audit de sécurité

Réalisation d’un audit de sécurité

PHASE 3: EXECUTION 

Dans cette phase, l’auditeur doit collecter des données et des preuves à travers des tests et des opérations. Les données collectées et des résultats des tests seront analysés et examiner afin de dégager les insuffisances et faire des jugements.
Les résultats préliminaires seront documentés et communiqués aux responsables.

La preuve
C’est toute information utilisée par l’auditeur pour justifier/renforcer un jugement porté sur un composant du SI audité. C’est le résultat des tests menés sur les composants du SI. Les jugements faits par l’auditeur doivent être basés sur des preuves pertinentes et suffisantes.
La preuve peut inclure :  Les observations de l’auditeur.  Les notes prises suite aux entretiens menés avec le personnel concerné.  Les informations collectées à partir de la documentation relative à l’entreprise.  Les résultats obtenus suite à l’exécution des procédures de test et l’exécution des outils d’audit.

Classification des preuves

Il existe plusieurs catégories de preuves qui sont :  Preuve physique : obtenue généralement suite à l’observation du personnel, d’un événement et peut être sous forme de photos, cartes, plans, etc.  Preuve par témoignage : peut-être des comptes rendus, des questionnaires. Ces types de preuves ne sont pas concluants en elles-mêmes car elles représentent l’opinion d’une autre personne.  Preuve sous forme de document : peut-être des lettres, des accords, contrats, directives, note, et d’autres documents utilisés au sein de l’entreprise. La source du document affecte le niveau de fiabilité du document.  Preuve analytique : généralement dégagée à partir des traitements sur des données, suite à des comparaisons par rapport à des standards, par rapport à des opérations précédentes ou similaires.

Critères de fiabilité de la preuve
Les critères qui doivent être satisfont pour considérer une preuve fiable :  L’indépendance du fournisseur de la preuve : les preuves obtenues à partir des sources externes sont plus fiables par rapport à celles de l’organisme audité.  Information ou preuve fournie par une personne qualifiée.  Une preuve qui ne nécessite pas un jugement ou une interprétation considérable.  Conservation de la validité de la preuve à travers le temps.
Les preuves dégagées à partir des données stockées dans des structures telles que les fichiers, peuvent ne pas être récupérées après une période de temps si les changements sur ces derniers ne sont pas contrôlés ou si les preuves ne sont pas sauvegardées.

Protection de la preuve
L’auditeur doit être conscient de l’importance des contrôles qui doivent être appliqués sur les preuves collectées. Des contrôles doivent être appliqués sur ses preuves assurant la protection de :  La confidentialité.  La disponibilité.  L’intégrité.
Exemples de moyens pour assurer ses propriétés pour les preuves électroniques :  Le cryptage pour assurer la confidentialité.  La sauvegarde pour assurer la disponibilité.  La signature pour assurer l’intégrité.

Techniques de collecte de preuves
La collecte des preuves se fait en examinant:  Les politiques et procédures du SI : Vérifier si les politiques et les procédures appropriées sont élaborés. Déterminer si le personnel comprend les procédures et les politiques implémentées. Vérifier si le personnel suit/respecte les procédures et politiques existantes au sein du SI. Vérifier que la révision régulière est réalisée pour ces documents.  Les structures organisationnelles du SI : Vérifier si les structures organisationnelles (SO) sont mises en place et qu’ils appliquent de façon adéquate la séparation des responsabilités. Vérifier le niveau de contrôle assuré par ces SO.  La documentation du SI : Cette documentation inclut au moins : o Les documents de spécification et de développement. o Les plans de test. o Les manuels d’utilisation des applications. o Les documents de sécurité (les plans de sécurité, l’analyse des risques, etc.).  Le personnel : Faire des entretiens avec le personnel approprié. Préparation des questionnaires à l’avance.  Les processus: Observation du déroulement des processus du SI.

Table des matières

Introduction générale
Chapitre I. Cadre du projet
I. Présentation du cadre
II. Entreprise d’accueil
II.1. Fiche d’identité de l’entreprise d’accueil
II.2. Fondation et développement du TVTC
II.3. Problématique
Conclusion
Chapitre II. Etat de l’art
Introduction
I. Audit de sécurité
I.1. Définition
I.2. Contenu de l’audit
I.3. Les approches d’audit de sécurité
I.4. Cycle de vie d’un audit de sécurité
I.5. Démarche de réalisation d’un audit de sécurité
I.5.1. Phase 1 : Définition de la mission d’audit
I.5.2. Phase 2 : Préparation à l’audit
I.5.3. Phase 3 : Exécution
I.5.4. Phase 4 : Elaboration du rapport
I.5.5. Phase 5 : Suivi des recommandations
I.6. Les références d’audit
I.6.1. La norme BS 7799
I.6.2. La norme ISO 13335
I.6.3. La norme ISO 15408
I.6.4. La norme ISO 15446
I.6.5. La norme ISO 17799
I.6.6. La norme ISO 27001
II. Les systèmes d’exploitation pour mobile
II.1. Android OS
II.2. iOS
II.3. Windows Phone
II.4. BlackBerry
III. Les applications mobiles
III.1. Description
III.2. Avantages
III.3. Tendance de téléchargement des applications mobiles
IV. Etude de l’existant
IV.1. ISS
IV.2. Saint
IV.3. Retina
IV.4. Nessus, NewT
V. Synthèse pour le choix de la solution
Conclusion
Chapitre III. Démarche et méthodologie du projet
Introduction
I. Description du sujet
II. Planification du projet
III. Méthodologie du projet
IV. Les méthodologies existantes
IV.1. Les méthodes classiques
IV.2. Les méthodes agiles
IV.2.1. La méthode 2TUP
IV.2.2. La méthode RUP
IV.2.3. La méthode XP
IV.3. Comparaison entre les deux méthodes de travail
V. Choix de la méthodologie
V.1. Définition de 2TUP
V.2. Description de la méthode 2TUP
Conclusion
Chapitre IV. Spécification des besoins
Introduction
I. Etude préliminaire
I.1. Présentation du projet à réaliser
I.2. Recueil des besoins fonctionnels
I.3. Identification des acteurs
I.4. Modélisation du contexte
II. Capture des besoins fonctionnels
II.1. Identification des cas d’utilisation
II.2. Diagramme des cas d’utilisation
III. Capture des besoins techniques
III.1. JEE
III.2. DAO
III.3. Bouncy Castle
IV. Choix de la plateforme
IV.1. Android SDK
IV.2. Les composants d’une application Android
Conclusion
Chapitre V. Analyse
Introduction
I. Vue statique
I.1. Diagramme de classes participantes
I.1.1. Cas d’utilisation « Créer un utilisateur »
I.1.2. Cas d’utilisation « Lancer un audit »
II. Vue dynamique
II.1. Diagrammes de séquences
II.1.1. Diagramme de séquence du cas « S’authentifier »
II.1.2. Diagramme de séquence du cas « Gérer les équipements »
II.1.3. Diagramme de séquence du cas « Gérer les utilisateurs »
II.1.4. Diagramme de séquence du cas « Gérer les vulnérabilités »
II.1.5. Diagramme de séquence du cas « Auditer un équipement »
II.1.6. Cas d’utilisation « Collecter les informations »
II.2. Diagramme d’activités
II.2.1. Cas d’utilisation « Créer un utilisateur »
II.2.2. Cas d’utilisation « Collecter les informations »
Conclusion
Chapitre VI. Conception
Introduction
I. Conception préliminaire
I.1. Le logo
I.2. L’identité visuelle
I.3. Gabarit de mis en page
II. Conception détaillée
II.1. Diagramme de classes côté serveur
II.2. Diagramme de classes côté client
III. Architecture des plateformes utilisées
III.1. Côté serveur
III.2. Côté client
Conclusion
Chapitre VII. Réalisation et Tests
Introduction
I. Description de l’environnement de développement
II. Architecture de l’application
III. Description de la solution finale
III.1. Interface d’authentification
III.2. Interface d’accueil
III.3. Interface « Settings »
III.3.1. Interface « My Profile »
III.3.2. Interface « Audit Tasks »
III.4. Interface des services « KMCT Audit »
III.4.1. Interface « Collect »
III.4.2. Interface « Tasks »
III.4.3. Interface « Setting Report »
III.4.4. Interface « Launch Audit »
III.5. Interface « Audit Report »
IV. Déploiement d’une application Android
Conclusion
Conclusion générale
Références
Annexes

Télécharger le rapport complet