La sécurité informatique en mode projet Préface d’Éric ... · nance des projets liés à la sécurité de l’infor-mation et les conseillent dans l’amélioration de leurs

La sé

curi

té in

form

atiq

ue e

n m

ode

proj

et

isbn

: 978

-2-4

09-0

0628

-9

Pour plus d’informations :

45 €

2e édition

Nouvelle édition

Alexandre PLANCHEJérôme DEL DUCA

La sécurité informatique en mode projet Organisez la sécurité du SI de votre entreprisePréface d’Éric SALLOU - Expert Cyber Sécurité Gérant de la société DAALA

La sécurité informatique en mode projet Organisez la sécurité du SI de votre entreprisePréface d’Éric SALLOU - Expert Cyber Sécurité - Gérant de la société DAALACe livre sur la sécurité informatique est destiné autant à l’informaticien opération-nel qu’au chef de projet, au responsable IT ou au RSSI nouvellement nommé qui cherche à donner une impulsion à son département ou qui a hérité d’un projet en sécurité informatique (Plan de Reprise d’Activité, déploiement d’un antivirus, gestion du cycle de vie d’un collaborateur dans l’entreprise, chiffrement d’une flotte d’ordina-teurs portables, etc.). L’informatique est le système nerveux central des entreprises ; une panne, un manque de réactivité, une indisponibilité, une perte d’informations affectent considérablement leur mécanisme. La gestion de la sécurité de l’information au-trefois réservée aux grandes entreprises ou aux PME matures, s’étend à toutes les structures, quels que soient leur taille et leur domaine d’activité.

Pour rendre la mise en œuvre de la sécurité accessible au plus grand nombre et notamment aux PME/PMI et TPE, les auteurs détaillent dans ce livre une méthode de gestion de projet qu’ils ont simplifiée et optimisée pour l’adapter à tout projet lié à la protection de leurs informations (gestion des mots de passe, des habilita-tions d’accès, sauvegardes automatiques et restaurations, déploiement d’un antivirus, chiffrement des postes, cycle de vie d’un collaborateur, révision du système de fichiers, approche d’un Plan de Reprise d’Activité, normes de sécurité et certifications, charte informatique, guides, règles et procédures, etc.).

Pour chaque type de projet lié à la sécurité, le lecteur apprend à définir précisément le projet, à identifier ses points-clefs (quels sont les intervenants ? les livrables ? les risques ? le coût ?) et à préciser les spécificités liées à la sécurité. Riche de retours d’expérience et de bonnes pratiques, ce livre se veut pragmatique et permettra au lecteur d’appréhender les difficultés les plus courantes ainsi que d’anticiper et d’éviter les pièges fréquents et habituels rencontrés durant la gestion de ce type de projet.

Alexandre PLANCHE possède plus de 15 années d’expérience dédiées à la protec-tion de l’information. Ancien RSSI pour de grands groupes, puis consultant sécurité senior, Alexandre a piloté la création de plusieurs départements sécurité pour des organismes d’importance vitale ou pour leurs filiales. À ce titre, il a su adapter sa démarche de pilo-tage, d’organisation et de déploiement de la protection de l’information conformément aux exigences réglementaires comme la LPM et l’ISO/CEI 27001.Expert en pilotage des Systèmes d’Information, Jérôme DEL DUCA a été ces 15 dernières années Chef de projet puis Responsable des Systèmes d’Information dans l’industrie, la santé et l’édition logicielle. Il est récemment intervenu en tant que consultant expert en sé-curité de l’information pour une organisation française de premier plan dans le secteur du numérique, pour le pilotage de projets sécu-rité pour de grands groupes ou encore dans une entreprise industrielle jusqu’à obtention de la certification ISO27001:2013.Aujourd’hui, Jérôme, associé LX Conseil, et Alexandre, associé LX Conseil et KIREM, ac-compagnent les entreprises dans la création, l’adaptation et la consolidation de la gouver-nance des projets liés à la sécurité de l’infor-mation et les conseillent dans l’amélioration de leurs pratiques de sécurité. C’est cette expé-rience de terrain qui est mise à disposition des lecteurs pour rendre la sécurité accessible aux besoins et aux moyens des entreprises de toutes tailles.

Téléchargementwww.editions-eni.fr.fr

sur www.editions-eni.fr : b Exemple d’un fichier de gestion des risques.

Préambule • Préface • Qu’est-ce qu’un projet en sécurité informatique ? • Qu’est-ce qu’un système d’information ? • Qu’est-ce que la sécurité ? • Prérequis : un peu d’organi-sation numérique • Introduction à la gestion de projet • Les spécificités des projets sécurité

Les chapitres du livre

1Table des matières

Préface

Préambule

Chapitre 1

Qu’est-ce qu’un projet en sécurité informatique ?

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. Les différentes populations d'une Direction des Systèmes d'Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Le chef de projet en sécurité informatique . . . . . . . . . . . . . . . . . . . . . 16

4. La compétence chef de projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1 La gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 L’organisation de l’information . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.1 La prise de notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2 L’accès constant aux informations. . . . . . . . . . . . . . . . . . 224.2.3 La gestion et le suivi des tâches . . . . . . . . . . . . . . . . . . . . 25

4.3 Dernière compétence clé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5. La compétence responsable système d’information . . . . . . . . . . . . . . 345.1 La connaissance du parc informatique . . . . . . . . . . . . . . . . . . . . 345.2 La connaissance des applicatifs . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Les exemples à télécharger sont disponibles à l'adresse suivante :http://www.editions-eni.fr

Saisissez la référence ENI de l'ouvrage DP2PROSEC dans la zone de recherche et validez. Cliquez sur le titre du livre puis sur le bouton

de téléchargement.

2en mode projet

La sécurité informatique

6. La compétence responsable de la sécurité des systèmes d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.1 La sensibilisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Les quatre composants principaux du métier de RSSI

et les compétences clés associées . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.1 La sécurité organisationnelle. . . . . . . . . . . . . . . . . . . . . . . 396.2.2 La sécurité pédagogique . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2.3 La sécurité juridique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2.4 La sécurité technique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7. Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapitre 2

Qu'est-ce qu'un système d'information ?

1. Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2. Où croise-t-on le "système d’information" ? . . . . . . . . . . . . . . . . . . . . 482.1 Le SI dans les moyennes entreprises et plus . . . . . . . . . . . . . . . . 48

2.1.1 Taille/temps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.1.2 Conscience technologique. . . . . . . . . . . . . . . . . . . . . . . . . 49

2.2 Le système d’information sur le marché de l’emploi . . . . . . . . . 502.2.1 Le recrutement classique. . . . . . . . . . . . . . . . . . . . . . . . . . 502.2.2 Recruter un consultant . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.2.3 Gardez à l’esprit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.3 Le système d’information dans les livres . . . . . . . . . . . . . . . . . . 53

3. Les acteurs du système d’information. . . . . . . . . . . . . . . . . . . . . . . . . 543.1 La Direction des SI et le management au sens large. . . . . . . . . . 553.2 Support opérationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3 Les centres d'appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


4. Les composantes "métier" du système d’information . . . . . . . . . . . . 584.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Exemples de composantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.1 GRH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.2 GRC ou CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.3 SCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5. Point d’étape intermédiaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.1 Compréhension du positionnement

d’un chef de projet sécurité dans l'entreprise . . . . . . . . . . . . . . . 605.2 Le numérique arrive au foyer, incompréhensions. . . . . . . . . . . . 615.3 L'affaire de tous. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6. Informatique, vue spécifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.1 Naissance de l'informatique d'entreprise. . . . . . . . . . . . . . . . . . . 636.2 Développement informatique de l'entreprise . . . . . . . . . . . . . . . 646.3 Intégration dans l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7. La montée croissante dans l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . 687.1 Multiplication des couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.2 Organisation des couches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.3 Management des couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.4 Conclusion : la partie émergée de l'iceberg . . . . . . . . . . . . . . . . . 73

8. Système d'information, vue globale . . . . . . . . . . . . . . . . . . . . . . . . . . 748.1 Le système nerveux central de l'entreprise . . . . . . . . . . . . . . . . . 748.2 Nécessité de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.2.1 Gestion d'un portefeuille de projets . . . . . . . . . . . . . . . . . 758.2.2 Anticipation et Direction . . . . . . . . . . . . . . . . . . . . . . . . . 768.2.3 Susciter la collaboration entre les acteurs du SI . . . . . . . 78

8.3 Particularité de la sécurité du SI . . . . . . . . . . . . . . . . . . . . . . . . . 798.3.1 Pourquoi une singularité ? . . . . . . . . . . . . . . . . . . . . . . . . 798.3.2 Positionnement spécifique . . . . . . . . . . . . . . . . . . . . . . . . 81

8.4 Conclusion : niveaux de maturité . . . . . . . . . . . . . . . . . . . . . . . . 828.4.1 Type 1, résoudre le problème informatique. . . . . . . . . . . 838.4.2 Type 2, optimiser les investissements informatiques . . . 84

4en mode projet


8.4.3 Type 3, transformer les entreprises à l’aide du système d’information . . . . . . . . . . . . . . . . . . 85

9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869.1 Définition d'aujourd'hui. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869.2 Et déjà demain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapitre 3

Qu'est-ce que la sécurité ?

1. De la sécurité d'hier... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

2. ... à la sécurité d'aujourd'hui. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3. Les enjeux de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4. La sécurité de l'information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5. La boîte à outils sécurité pour les collaborateurs . . . . . . . . . . . . . . . . 955.1 Le comportement et l’éducation . . . . . . . . . . . . . . . . . . . . . . . . . 965.2 Les mots de passe et leur gestion. . . . . . . . . . . . . . . . . . . . . . . . . 98

5.2.1 L’authentification simple . . . . . . . . . . . . . . . . . . . . . . . . . 985.2.2 L’authentification forte. . . . . . . . . . . . . . . . . . . . . . . . . . 1045.2.3 La biométrie de confort . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.3 Les mises à jour logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.4 La sauvegarde automatique et la restauration en toute autonomie1135.5 Conclusions sur la boîte à outils sécurité du collaborateur . . . 113

6. Le domaine d'application de la SSI . . . . . . . . . . . . . . . . . . . . . . . . . . 1146.1 La communication dans l’entreprise . . . . . . . . . . . . . . . . . . . . . 117

6.1.1 La Direction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.1.2 Le middle management . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.1.3 Les équipes opérationnelles. . . . . . . . . . . . . . . . . . . . . . . 1206.1.4 Synthèse de la communication dans l’entreprise . . . . . 121

6.2 Synthèse du domaine d’application de la SSI . . . . . . . . . . . . . . 121


7. Les normes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227.2 Les normes certifiantes en sécurité informatique. . . . . . . . . . . 123

7.2.1 ISO 27001. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247.2.2 ISO 27002. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.2.3 Le fonctionnement d'une certification ISO 27001 . . . . 1267.2.4 SAS 70 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Les certifications personnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8. Les outils méthodologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.1 EBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.2 MEHARI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.3 Les logiciels d’aide à la mise en place

des méthodologies sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

9. Les différentes conformités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299.1 La conformité réglementaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299.2 La conformité légale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

9.2.1 La Loi de Programmation Militaire (LPM) . . . . . . . . . . . 1319.2.2 Le Règlement Général sur la Protection

des Données (RGPD). . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

10. L'organisation des politiques, règles et procédures de sécurité dans l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13410.1 La Politique de Sécurité du Système d'Information (PSSI) . . . 13710.2 La charte informatique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.3 Les Politiques Thématiques (PTH) . . . . . . . . . . . . . . . . . . . . . . 140

11. Les Procédures Techniques de Réalisation (PTR) . . . . . . . . . . . . . . . 144

12. Les règles, les guides et les procédures . . . . . . . . . . . . . . . . . . . . . . . . 14612.1 Les règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14612.2 Les guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14712.3 Les procédures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14812.4 Les règles groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

12.4.1 L’objectif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14812.4.2 La politique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

6en mode projet


12.4.3 Les responsabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14912.5 Les systèmes d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

12.5.1 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15012.5.2 Windows postes de travail . . . . . . . . . . . . . . . . . . . . . . . 15112.5.3 Windows Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15612.5.4 Les bonnes pratiques usuelles . . . . . . . . . . . . . . . . . . . . . 158

12.6 Les procédures fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 16012.6.1 La sécurité des ordinateurs portables . . . . . . . . . . . . . . . 16112.6.2 Les communications électroniques . . . . . . . . . . . . . . . . 162

13. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Chapitre 4

Prérequis : un peu d’organisation numérique

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

2. La nomenclature des documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682.1 Types de documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682.2 La gestion des versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692.3 Le référencement des documents . . . . . . . . . . . . . . . . . . . . . . . 1692.4 La page de garde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

3. La gestion du partage et de la sauvegarde des documents . . . . . . . . 1723.1 G suite by Google Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

3.1.1 Google Docs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743.1.2 Google Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

3.2 Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1813.2.1 La synchronisation des fichiers. . . . . . . . . . . . . . . . . . . . 1823.2.2 L’accès aux fichiers dans toutes les conditions . . . . . . . 1843.2.3 Un endroit unique de stockage et

de partage des fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863.2.4 Une sauvegarde automatique des fichiers . . . . . . . . . . . 187

4. Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188


Chapitre 5

Introduction à la gestion de projet

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

2. Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

3. Qu’est-ce qu’un projet ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913.1 Les objectifs réels d’un projet. . . . . . . . . . . . . . . . . . . . . . . . . . . 1933.2 Le niveau de détail du découpage des tâches d’un projet . . . . . 1943.3 Les quatre composantes d’un projet . . . . . . . . . . . . . . . . . . . . . 1953.4 Le ou les objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1953.5 Le budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963.6 La durée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963.7 Le périmètre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1963.8 Les acteurs du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

3.8.1 Le maître d’ouvrage (MOA) . . . . . . . . . . . . . . . . . . . . . . 1973.8.2 Le sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1973.8.3 L’équipe projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983.8.4 Le maître d’œuvre (M.O.E.) ou chef de projet. . . . . . . . 1983.8.5 Synthèse des liens entre

les différents acteurs d’un projet . . . . . . . . . . . . . . . . . . 2003.9 Les composantes du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013.10 Le cycle de vie du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2053.11 Vue globale d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

4. Document préalable : la lettre de mission. . . . . . . . . . . . . . . . . . . . . 2094.1 Le nom de code du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2094.2 Contenu de la lettre de mission. . . . . . . . . . . . . . . . . . . . . . . . . 210

5. Étape 1 : la préparation de projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125.1 Le cahier des charges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125.2 Le plan de maîtrise du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

5.2.1 Contenu d’un plan de maîtrise du projet. . . . . . . . . . . . 2185.2.2 Le PMP c’est bien mais... . . . . . . . . . . . . . . . . . . . . . . . . . 224

5.3 Le document de cartographie des risques . . . . . . . . . . . . . . . . . 2245.3.1 Rappel de ce qu’est un risque . . . . . . . . . . . . . . . . . . . . . 225

8en mode projet


5.3.2 Création de la liste des risques . . . . . . . . . . . . . . . . . . . . 2255.3.3 Classement et organisation des risques . . . . . . . . . . . . . 2265.3.4 Gestion des risques identifiés . . . . . . . . . . . . . . . . . . . . . 2285.3.5 Communication par les risques . . . . . . . . . . . . . . . . . . . 230

5.4 Le planning prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2305.5 Préparation de la logistique et installation de l’équipe. . . . . . . 2315.6 Synthèse des livrables et de l’étape . . . . . . . . . . . . . . . . . . . . . . 2325.7 Jalon de l’étape : "réunion de lancement" ou "kick off" . . . . . . 232

6. Étape 2 : élaboration de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 2336.1 La conception générale et détaillée . . . . . . . . . . . . . . . . . . . . . . 2346.2 Les actions en parallèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

6.2.1 Le plan de démarrage de secours. . . . . . . . . . . . . . . . . . . 2356.2.2 Le plan de conduite du changement. . . . . . . . . . . . . . . . 2356.2.3 Initialisation des scénarios de test . . . . . . . . . . . . . . . . . 235

6.3 Jalon de l’étape "revue de fin de conception" . . . . . . . . . . . . . . 2366.4 Synthèse des livrables et de l’étape . . . . . . . . . . . . . . . . . . . . . . 2366.5 Jalon : la "validation" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

7. Étape 3 : déploiement de la solution . . . . . . . . . . . . . . . . . . . . . . . . . 2377.1 La réalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2377.2 Les tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2387.3 Approvisionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2387.4 Rédaction des scénarios de test . . . . . . . . . . . . . . . . . . . . . . . . . 238

7.4.1 Les scénarios de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2387.4.2 La fiche de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

7.5 La formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2397.5.1 Le plan de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2407.5.2 La fiche d’évaluation du transfert des compétences . . . 240

7.6 Transfert des compétences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2417.6.1 Le plan de transfert des compétences. . . . . . . . . . . . . . . 2417.6.2 La fiche d’évaluation du transfert des compétences . . . 242

7.7 Les tests d’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2427.8 Les tests de non-régression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2427.9 Synthèse des livrables et de l’étape . . . . . . . . . . . . . . . . . . . . . . 243


7.10 Jalon : la "revue de fin de construction" . . . . . . . . . . . . . . . . . . 243

8. Étape 4 : validation pré-opérationnelle . . . . . . . . . . . . . . . . . . . . . . . 2448.1 La recette pré-opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 2448.2 Le plan de formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2458.3 Le plan de démarrage de secours . . . . . . . . . . . . . . . . . . . . . . . . 2458.4 Synthèse des livrables de l’étape . . . . . . . . . . . . . . . . . . . . . . . . 2458.5 Jalon : "Go / No Go" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

9. Étape 5 : démarrage opérationnel et stabilisation. . . . . . . . . . . . . . . 2469.1 Mise en exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2479.2 Mise à jour de la documentation . . . . . . . . . . . . . . . . . . . . . . . . 2479.3 La stabilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2479.4 Synthèse des livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2489.5 Jalon "passage en maintenance" . . . . . . . . . . . . . . . . . . . . . . . . . 249

10. Étape 6 : clôture du projet et passage en MCO . . . . . . . . . . . . . . . . 24910.1 La revue de fin de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24910.2 Clôture et passage en Maintenance

en Conditions Opérationnelles ou MCO . . . . . . . . . . . . . . . . . 25010.2.1 Synthèse des livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . 25010.2.2 Jalon 6 : clôture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Chapitre 6

Les spécificités de projets sécurité

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

2. Les bons réflexes à appliquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2542.1 Les principes directeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2542.2 Durant la "préparation de projet" . . . . . . . . . . . . . . . . . . . . . . . 2552.3 Quelques spécificités dans le cadre

d’une prestation externalisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 2552.4 Durant "l’élaboration de la solution" . . . . . . . . . . . . . . . . . . . . . 2572.5 Durant "le déploiement de la solution" . . . . . . . . . . . . . . . . . . . 258

10en mode projet


2.6 Durant "la validation pré-opérationnelle" . . . . . . . . . . . . . . . . . 2592.7 Durant "le démarrage opérationnel et la stabilisation" . . . . . . 2592.8 Durant "la clôture et le passage en MCO" . . . . . . . . . . . . . . . . 259

3. Quelques exemples de projets sécurité et leurs spécificités . . . . . . . 2603.1 Déploiement antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2603.2 Sauvegardes et restaurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 2633.3 Chiffrer des postes de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 2733.4 Procédures d'entrée, mutation et sortie des collaborateurs . . . 2753.5 La revue des habilitations d’accès sur les postes de travail . . . 2783.6 La mise en place d’une charte informatique . . . . . . . . . . . . . . . 2813.7 Le Plan de Reprise d’Activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 2843.8 La révision du système de fichiers . . . . . . . . . . . . . . . . . . . . . . . 288

3.8.1 Mise œuvre de l’arborescence . . . . . . . . . . . . . . . . . . . . . 2903.8.2 Vue technique simplifiée. . . . . . . . . . . . . . . . . . . . . . . . . 2923.8.3 Permissions de partage . . . . . . . . . . . . . . . . . . . . . . . . . . 2943.8.4 Création des groupes locaux . . . . . . . . . . . . . . . . . . . . . . 2943.8.5 Création des Groupes Globaux. . . . . . . . . . . . . . . . . . . . 2953.8.6 Légitimer une demande d’accès utilisateur . . . . . . . . . . 2973.8.7 Risques identifiés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

4. Des difficultés propres à chaque secteur d'activité. . . . . . . . . . . . . . 2994.1 L’exemple du secteur de l'édition logicielle . . . . . . . . . . . . . . . . 2994.2 L’exemple du secteur industriel . . . . . . . . . . . . . . . . . . . . . . . . . 301

5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309

253

Chapitre 6

Les spécificités de projets sécurité

Les spécificités de projets sécurité1. Introduction

À chaque domaine les projets qui lui sont spécifiques avec des caractéristiquesqui lui sont propres. Ainsi, un chef ou un directeur de projet spécialisé dans ledomaine public et de la paie, par exemple, saura éviter ou du moins anticiperles écueils les plus courants dans son domaine mais sera démuni lors du pilo-tage d'un projet de déploiement de cash management international. Il neconnaît pas le domaine bancaire ainsi que les métiers associés.

Dans les paragraphes suivants, c’est ce que nous allons présenter : quelquesprojets en sécurité typiques et classiques, les pièges à éviter ainsi que lesbonnes pratiques à mettre en œuvre.

Nous irons du projet de déploiement d’un antivirus au pilotage d’un Plan deReprise d’Activité (PRA) en passant par la mise en œuvre de ce plan.

Remarque

Le PRA est un projet complexe qui donne lieu à un ouvrage dédié aux éditionsENI : Plan de Continuité d'Activité - Concepts et démarche pour passer du be-soin à la mise en œuvre du PCA.

Nous avons sélectionné des exemples de projets essentiellement techniques.Mais, comme nous l’avons vu, la protection de l’information est transverse àl’entreprise et ne représente qu’une partie des sujets à traiter.

© E

dit

ions

EN

I -

All r

ights

rese

rved

254en mode projet


Par exemple, à la période où j’écris ces lignes – fin 2016 –, je suis de plus en plussollicité pour des projets de mise en conformité relatifs à de nouvelles obliga-tions réglementaires ou légales. Ce type de projets sécurité est purement fonc-tionnel ; nous y analysons l’écart entre ce qui est en place, ce qui devrait l’êtreet ce qu’il va falloir mettre en œuvre. Ce qui doit être mis en œuvre du pointde vue de la sécurité fait ensuite l’objet de plans d’action spécifiques quiconcernent toute l’entreprise.

Il faut également garder à l’esprit que l’ensemble des projets SSI doit êtreconforme aux différentes politiques de l’entreprise (PSSI, PTH, PTR, etc.) oualors que ces politiques doivent être rendues conformes aux obligations desdifférents projets de façon à ce que l’impératif de sécurité ne pèse pas surl’activité de l’entreprise.

2. Les bons réflexes à appliquer

2.1 Les principes directeurs

La liste ci-dessous est une somme de bons réflexes qu’il convient, suivant lesbesoins et la taille du projet, d’appliquer en totalité ou de façon partielle. Celadit, dans tous les cas, vous devez vous poser la question de l’applicabilité dechacun de ces principes.

– Un projet est placé sous la responsabilité d’un chef de projet ou, selon lescas, d’un responsable métier. Ce responsable est garant de l’intégration de lasécurité lors du projet et du respect de l’application de la présente instruc-tion.

– Le responsable du projet doit associer les équipes sécurité dès le début et àchaque étape du projet.

– Tout projet ou application doit faire l’objet d’une démarche sécurité adap-tée à son niveau de sensibilité, dont les risques résiduels et le plan d’actiondoivent être acceptés par le responsable métier avant mise en production.

– L’externalisation de tout ou partie du projet doit être spécifiquement priseen compte lors de l’analyse de risque.

255Les spécificités de projets sécuritéChapitre 6

– Les jalons sécurité, ainsi que les livrables correspondants (QES, soit Ques-tionnaire d’Évaluation de la Sensibilité, dossier de sécurité, audit de sécurité,fiche d’objectifs de sécurité...), sont à intégrer dans la gestion de projet.

2.2 Durant la "préparation de projet"

– La démarche sécurité doit être initiée dès le début du projet. Cela se concré-tise par la rédaction d’un QES.

– Ce questionnaire doit être réalisé durant les phases d’étude d’opportunitéset de cadrage à l’initiative du chef de projet, en collaboration avec la filièreSSI concernée, validé par le responsable métier, et mis à disposition du RSSI.Un comité projet doit s’assurer du remplissage et de la validation du QESavant la fin du cadrage.

– Toute application sensible doit disposer d’un dossier de sécurité. Dans lesautres cas de sensibilité remontés par le QES, le RSSI doit déterminer s’il estnécessaire de remplir un dossier de sécurité adapté pour l’application.

– En cas d’externalisation, une analyse de risque spécifique doit être conduiteet les risques résiduels remontés au responsable métier pour acceptation.

– L’acceptation, par le responsable métier, des risques résiduels liés à l’exter-nalisation doit être consignée en comité projet.

2.3 Quelques spécificités dans le cadre d’une prestation externalisée

Avec l’essor des solutions "Cloud", il me semble nécessaire de faire un pointspécifique sur le sujet des prestations externalisées et les questions/obliga-tions qu’il convient impérativement d’adresser dans le cahier des charges aufournisseur de la solution.

Une parenthèse cependant, je parle ici de solution "Cloud" – car c’est à lamode – ce qui correspond à du SaaS (Software as a Service). Mais avec un peud’adaptation, ces recommandations peuvent être élargies à n’importe queltype de "...aaS".

© E

dit

ions

EN

I -

All r

ights

rese

rved

256en mode projet


Pour mémoire, voici les grands types de "...aaS".

Les cases en vert représentent les couches intégrées dans le " ...aaS", les casesblanches ne le sont pas. En d’autres termes, dans une architecture IaaS parexemple, les couches réseaux, stockage, serveurs virtualisation définissent unservice IaaS, les couches blanches ne font pas partie de ce service.

Ainsi, il convient lors d’un projet "Cloud", du point de vue de la gestion de lasécurité, de vérifier que les points suivants sont pris en compte :

– Tout projet d’externalisation doit contenir les modèles de clauses contrac-tuelles de protection des SI et de sécurité de l’information.

– Les mesures de sécurité et leur suivi doivent être spécifiés contractuellementavec le fournisseur de service. Les exigences formulées par le responsablemétier en termes de sécurité doivent être traitées par des engagementscontractuels.

– Le fournisseur de service doit s’engager sur les mesures de sécurité et sa ca-pacité à protéger les informations qui lui sont confiées. Il doit apporter lapreuve (politique, certification...) de son niveau de conformité par rapportaux normes et montrer qu’il est capable de protéger les informations qui luisont confiées.

257Les spécificités de projets sécuritéChapitre 6

– Le cahier des charges de l’application doit prévoir une clause d’audit du codeou, à défaut, des certifications d’organismes indépendants reconnus.

– Le cahier des charges doit exiger une séparation (logique ou physique) entreles données spécifiques de l'entreprise et celles des autres clients.

– Le cahier des charges doit exiger la protection des accès aux données de l’en-treprise pour tout accédant aux plateformes hébergeant l’application.

– Le cahier des charges doit exiger une administration des comptes et des habi-litations par l’entreprise. Le fournisseur de service ne doit pas pouvoir créerdes comptes et fournir des droits directement aux usagers de la solution.

– Le cahier des charges doit exiger une protection des traces réalisées par toutaccédant aux plateformes hébergeant l’application. Le fournisseur de ser-vice, en particulier ne doit pas pouvoir modifier ces traces.

– Le cahier des charges doit exiger une protection des échanges d’informationsentre le système d’information du fournisseur de service et le système d’in-formation de l’entreprise. Ces échanges doivent respecter les règles émisespar la société sur les flux réseau, les dispositifs de protection et de filtrageainsi que les règles de protection de l’information (telles que définies dansles politiques thématiques).

2.4 Durant "l’élaboration de la solution"

– Si le niveau de sensibilité défini par le QES pour le projet ou l’applicationl’exige, une analyse de risque doit être réalisée durant la phase de concep-tion. Des mesures de sécurité doivent être proposées pour pallier les risques.Ces éléments doivent être consignés dans le dossier de sécurité. Les mesuresde sécurité doivent être adaptées aux impacts métiers et respecter les be-soins de sécurité établis par le responsable métier.

– Les mesures de sécurité à mettre en place doivent être décrites dans les spé-cifications générales et/ou techniques.

– Les mesures de sécurité doivent en priorité être recherchées dans les solu-tions existantes au sein de l’entreprise. Dès qu’une solution de sécurité estdisponible au sein de l’entreprise et utilisable dans le contexte du projet, elledoit être privilégiée. Le choix d’une solution alternative doit être validé parle RSSI.

© E

dit

ions

EN

I -

All r

ights

rese

rved

258en mode projet


– Les mesures de sécurité doivent être construites conformément aux élé-ments validés au sein du dossier de sécurité et aux spécifications du cahierdes charges.

– Les équipes de développement ne doivent pas avoir accès à l’environnementde production. Les équipes en charge du développement et des tests ne doi-vent pas avoir de comptes actifs dans l’environnement de production.

– Les cahiers de tests techniques et fonctionnels doivent intégrer les mesuresde sécurité. Les mesures de sécurité doivent être testées au même titre queles fonctionnalités classiques de l’application. Tout dysfonctionnementdoit donner lieu à une fiche d’anomalie.

– L’application doit être testée dans un environnement conforme à l’environ-nement de production mais disjoint de ce dernier.

– Les fichiers de test ne doivent pas contenir d’informations sensibles. Lestests doivent être réalisés sur des données non sensibles. En particulier, lesdonnées personnelles devront être anonymisées.

– Dans l’environnement d’homologation technique, l’accès au code sourcedoit être restreint aux seules personnes habilitées afin de réduire les risquesde compromission. Les platesformes de test et de recette comportent sou-vent tout ou partie du code associé à l’application. Elles doivent être proté-gées pour éviter une modification indue de ces éléments (bombe logique...)ou la récupération d’informations.

– Dans le cas des applications sensibles, tout retrait de mesures de sécuritédoit être identifié, et ses risques résiduels validés par le RSSI, acceptés par leresponsable métier et périodiquement réévalués. Dans le cas d’un retraittemporaire, un planning de remise en place doit y être associé. Si les mesuresde sécurité envisagées ne peuvent pas être déployées pour des raisons deplanning, de complexité, de budget, etc., elles doivent être identifiéescomme telles. Le retrait de fonctionnalités doit être analysé. Cette analysedoit être fournie au RSSI qui la valide.

2.5 Durant "le déploiement de la solution"

Les processus de mise en production de l’entreprise doivent être respectés.

Documents

La sécurité informatique en mode projet Préface d’Éric ... · nance des projets liés à la sécurité de l’infor-mation et les conseillent dans l’amélioration de leurs