1. Les processus d`intégration de la sécurité dans les projets SI 1.0

Transcription

12 mai 2014
QSE : qualité et gouvernance des systèmes d’information
Module n°1 : les processus d'intégration de la sécurité dans les projets SI
Agenda
► 1. Introduction
2. Une démarche-type d'ISP
12 mai 2014 - Propriété de Solucom, reproduction interdite
2
Introduction
Pourquoi la sécurité dans les nouveaux projets ?
Tout changement sur le SI induit de nouveaux risques de sécurité de
l’information


Introduction d’un nouveau composant
Modification d’un composant existant
Des risques pour
l’ensemble du SI
Des risques pour le Métier

Si les besoins de sécurité du Métier ne
sont pas pris en compte

Ex: ouverture du SI à l’extérieur,
nouvelles vulnérabilités techniques, etc.
Ex: divulgation de données sensibles,
indisponibilité d’une application, etc.

Le Métier doit être partie prenante de
la démarche
Si le changement induit de nouvelles
failles de sécurité sur le SI

Le RSSI doit garantir le niveau global
de sécurité pour le SI
La réflexion liée à la sécurité doit être réalisée
lors de tout changement sur le SI,
notamment lors de la conduite de projets SI
3
Introduction
Application de la démarche d’Intégration de la Sécurité dans les Projets
 Généralement tous les nouveaux projets SI
HORS
PERIMETRE
PERIMETRE



Applicatifs et d’infrastructure
Réalisés en interne et externalisés
Basé sur un développement spécifique et basé sur un outil de marché
 Idéalement, les maintenances évolutives importantes


Maintenances menées en mode projet
Traitement de l’intégration de sécurité sur le périmètre de
maintenance
 Les changements mineurs



Maintenances correctives
Montées de versions mineures
Modification de données en
production
 Le SI existant
4
Introduction
Enjeux de la méthodologie ISP
1
Prendre en compte au plus tôt les risques SSI dans les
projets SI
• Pour prévenir les incidents de sécurité
• Pour mettre en place un SI intrinsèquement sécurisé, plutôt que de sécuriser un SI
déjà en place
2
Disposer d’un SI offrant un niveau de sécurité en adéquation
avec les besoins Métiers et de l’entreprise
• En adéquation avec la sensibilité sécurité exprimée par les Métiers et le niveau de
risques accepté par le Métier
• En adéquation avec les standards de sécurité de l’entreprise
3
Aider les chefs de projets à acquérir les réflexes pour intégrer
les aspects de la sécurité de l’information
• Sans que la sécurité n’apparaisse seulement comme une contrainte (complexité,
délai; coût…)
5
Introduction
Comment s’inscrit l’ISP dans une gouvernance sécurité ?
1 Dans la Politique de Sécurité du SI
 Pour les politiques alignées ISO 27002, souvent une directive dédiée à la sécurité
dans les projets informatiques

Chapitre 12 : mesures 12.1 : exigences de sécurité applicables aux SI et 12.2 : bon fonctionnement des applications
2 Dans le Plan d’actions sécurité
 Après avoir mené les principaux chantiers transverses de sécurisation de
l’infrastructure…


Antivirus, gestion des accès, etc.
… le RSSI décide souvent de sécuriser les applications sensibles de manière
spécifique
3 Lors d’une certification ISO 27001
 L’ISP est un chantier généralement obligatoire lorsque des activités de
développement sont dans le périmètre de certification
6
Agenda
1. Introduction
► 2. Une démarche-type d'ISP
7
Une démarche type d’intégration de la sécurité dans les projets
 Objectif : s’assurer que la sécurité est prise en compte tout au long du projet
Livrables
Phases Intégration de la Sécurité dans les
Projets
Phases
projet
 Un pré-requis facilitateur : disposer d’une méthode de gestion de projet d’entreprise
Étude préalable
Etude
opportunité
Etude de
faisabilité
Production
Réalisation du Projet
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Pré-analyse sécurité
Définition des
exigences de
sécurité
Analyse de risque SSI
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Participation aux Comités Projet
 Fiche de
qualification
sécurité
 Expression des besoins
de sécurité
 Scénarios de risques
 Spécifications
fonctionnelles
sécurité
 Spécifications  Cahier de
techniques
recette
sécurité
sécurité
 Dossier
d’exploitation
 Processus Métiers
Aspects sécurité intégrés dans les documents existants
8
Phases
projet
Appréciation de la sensibilité du produit
Projets
Détails de la démarche type d’ISP
Étude préalable
Etude
opportunité
Production
Etude de
faisabilité
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Analyse de risque
Définition des
exigences de
sécurité
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Objectif
 Une première étape incontournable : l’identification des projets les plus sensibles en termes de
sécurité, afin de prioriser et d’optimiser les efforts


 Risques IT : utilisation de
nouvelles technologies,
ouverture sur des
réseaux extérieurs,
Décision de la fonction sécurité de suivre la méthode ISP en fonction de la sensibilitéexternalisation…
Appréciation par les Métiers / les MOA sur la base d’un questionnaire simple
lors du démarrage des projets

Avec un mode dérogatoire lors de la phase de mise en place de la méthode
 Dans le cas de projets non sensibles : Pas de suite
 Exigences métiers :
besoin de confidentialité,
de dispo…
 Dans le cas de projets sensibles : La méthode ISP doit être appliquée

De manière complète ou simplifiée en fonction de la sensibilité
Points d’attention
 S’assurer d’avoir une vue exhaustive des projets SI lors de leur démarrage
 Construire le questionnaire de manière à pouvoir faire varier la taille de la « maille » de sélection
des projets éligibles à la méthode ISP

Afin de pouvoir démarrer par le suivi des projets les plus sensibles en termes de sécurité et généraliser la
démarche progressivement
9
Phases
projet
Analyse de risques SSI du produit
Projets
Étude préalable
Etude
opportunité
Production
Etude de
faisabilité
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Analyse de risque
Définition des
exigences de
sécurité
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Objectif
 Une analyse de risques SSI à réaliser seulement pour les projets identifiés comme sensibles
 Permettant d’identifier et de quantifier les risques portant sur le produit
 Impliquant à la fois





Les Métiers pour analyser les enjeux et les attentes particulières
Le Chef de Projet MOA transverse pour s’assurer de la complétude de la réflexion
Les responsables MOE et l’exploitation pour identifier les menaces et les vulnérabilités potentielles pesant
sur le produit
Eventuellement les risk-managers pour valider le niveau de gravité des risques et pour comparer les
niveaux de gravité d’un projet à l’autre
Un support sécurité pour expliquer et faciliter la démarche d’analyse de risques
 Les résultats de l’analyse de risques peuvent alimenter l’étude d’opportunité en chiffrant les coûts
liés à la sécurité
 Une méthodologie à définir en cohérence avec les démarches de classification et d’analyse de
risques de l’entreprise (notamment pour les échelles de classification)
 Un effort particulier pour faire accepter les risques résiduels par les Métiers eux-mêmes
10
Analyse de risques SSI du produit – un livrable type
TRAITEMENT DU
RISQUE SSI
APPRECIATION DU RISQUE SSI
Probabilité
Impact
retenu
Gravité
Interception des flux echangés par
l'application par un internaute X
Pas de chiffrement des flux (http)
1
1
1
x
1
1
1
x
1
1
1
x
2
2
2
x
Gestion de Profil non déterminé ou mal déterminé
3
2
3
x
Pas de suivi des journaux
2
1
1
Pas de changement régulier des mots de passe
Pas de gestion durcie de la politique des mots de
passe
2
2
2
Absence de PCIT pour l'application
1
1
1
Pas de test de montée en charge
2
3
3
x
incidents récurrents sur l'outil Caméléon
3
3
3
x
Actifs impactés
Réduire
Vulnérabilités
Scénarios de risque
Refuser
Critères
impactés
Accepter
Menaces
Transférer
Option de traitement
Thème 3 – Compromission des informations et des traitements
7. Écoute passive
C
C
interception courrier postaux ou email
email non chiffrés, et courrier envoyé en non
recommandé
9. Vol de matériels
D, C
Utilisation de données présentes sur les
serveurs
Pas de cryptage des données
10. Récupération de supports recyclés
ou mis au rebus
N/A
Les supports recyclés sont
systématiquement effacés
N/A
I
Erreur d'utilisation au niveau des flux
utilisateurs (exemples : suppression
d'utilisateur, saisies d'informations
erronées, …)
12. Abus de droit / Divulgation
I,C
Attribution de droits à des personnes non
habilitées (ex. visibilité ou accès en
modification sur certaines données
"sensibles" : données de rémunération)
12. Abus de droit / Divulgation
I,C
13. Usurpation de droit
C
Connexion avec le profil d'un autre
administrateur
16. Panne matérielle /
Dysfonctionnement du matériel
D,I
Panne de l'application suite à souci
matériel
17. Saturation du système informatique
D,I
Sous-dimensionnement de l'application
18. Dysfonctionnement logiciel
D,I
8. Vol de supports ou de documents
11. Erreur d'utilisation
Interfaces d'utilisation sont compliquées pour
la MOA
Diffulté d'utilisation des journaux des
événements
x
x
x
Thème 4 – Défaillances techniques
18.1. Mauvaise conception ou
installation des logiciels
Ensemble des actifs
x
11
Phases
projet
Définition et mise en œuvre des exigences de sécurité
Projets
Étude préalable
Etude
opportunité
Production
Etude de
faisabilité
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Analyse de risque
Définition des
exigences de
sécurité
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Objectif
 Identification des exigences de sécurité à prendre en compte pour chacun des acteurs



La MOA pour le cahier des charges ou l’appel d’offres dans le cas du choix d’un outil du marché
La MOE pour les spécifications fonctionnelles et techniques, le développement et l’intégration
L’exploitation
 Sur cette base, l’expert sécurité a en charge de valider les aspects sécurité des différents livrables


Spécifications fonctionnelles et techniques, dossier d’architecture technique…
Dossier d’exploitation, processus d’exploitation Métiers (habilitations, formation des utilisateurs, PCA…)
 Le choix des mesures de sécurité doit se baser sur un catalogue de spécifications fonctionnelles
de sécurité, associées à chaque niveau de risques
 Les solutions de sécurité implémentées dans un projet peuvent être rationalisées et réutilisées
dans d’autres projets (ex: PKI, cloisonnement, etc.)
Des projets connexes à mener dans un second temps
 Définition d’un catalogue standard de solutions de sécurité (en collaboration avec les architectes)
 Rédaction de guides de développement (J2EE, .net…)
 Rédaction de guides de sécurisation (OS, IIS, Websphere…)
12
Phases
projet
Recette sécurité et mise en production
Projets
Étude préalable
Etude
opportunité
Production
Etude de
faisabilité
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Analyse de risque
Définition des
exigences de
sécurité
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Objectif
 Réalisation d’une recette sécurité lors des recettes fonctionnelle et technique


Pour valider la prise en compte des mesures définies
Pour valider leur efficacité
 Conduite de tests d’intrusion pour les projets les plus sensibles

Notamment pour les applications ouvertes à l’extérieur
 Avis de la fonction sécurité avant la mise en production


Bloquant ou consultatif pour la mise en production
Portant notamment sur les risques impactant globalement le SI
Des projets connexes à mener dans un second temps
 Intégration des scénarios sécurité dans les plans de tests
 Mise en place d’un outil d’audit sécurité du code
 Mise en place d’un outil de scan de vulnérabilité
13
Phases
projet
Participation aux Comités de Pilotage
Projets
Étude préalable
Etude
opportunité
Production
Etude de
faisabilité
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Analyse de risque
Définition des
exigences de
sécurité
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Objectif
 Participation de la fonction sécurité aux Comités de Pilotage de suivi des projets phare

Pour avoir la vision des projets en cours
 En parallèle de toutes les étapes de l’ISP, implication de la fonction sécurité dans les
Comités de Pilotage importants de chacun des projets suivis



Pour pouvoir fournir les recommandations sécurité lors des étapes de validation du projet
(spécifications, dossier d’architecture, etc.)
Pour pouvoir participer au Comité de validation de la mise en production
Pour être reconnu comme un acteur à part entière d’un projet SI
14
Suivi des déclarations CNIL
Objectif
 La phase d’appréciation de la sensibilité du projet a permis de valider si le projet
manipule des données à caractère personnel
 Dans certains contextes, le RSSI assure le suivi de la réalisation des déclarations CNIL
 Les déclarations CNIL doivent être rédigées par le propriétaire de l’application, qui n’est
pas toujours un interlocuteur de l’équipe projet de la DSI
 La déclaration CNIL doit être rédigée avant la mise en production
Et demain ?
Projet de règlement européen sur les données à caractère personnel
Privacy by design : la protection des données à caractère personnel dès la conception des
traitements
 Passage d’une bonne pratique à une obligation règlementaire
 Passage d’une étape au sein de l’ISP à un processus en tant que tel
15
Phases
projet
Suivi et contrôle du déploiement de la méthode ISP
Projets
Étude préalable
Etude
opportunité
Production
Etude de
faisabilité
Analyse
fonct.
Conception
détaillée
Réalisation
Qualif.
Recette
Mise
en prod.
Maintenance
(MCO)
Analyse de risque
Définition des
exigences de
sécurité
MOE des
exigences de
sécurité
Recette des
exigences de
sécurité
Audit de
conformité
Avis du RSSI
avant mise en
prod
Prise en
compte de la
sécurité en
MCO
Objectif
 Assurer le suivi et le contrôle du déploiement de la méthode ISP



Parmi tous les projets, pointer ceux qui doivent suivre la méthodologie
Pour ceux qui suivent la méthodologie, valider que toutes les étapes sont réalisées
Tracer l’avis de la fonction sécurité relatif à la mise en production
 Insérer ces indicateurs dans les tableaux de bord sécurité existants
 Un livrable type
16
Une démarche type d’ISP
Les facteurs clés de succès
Adopter une méthodologie pragmatique et outillée

S’intégrer dans la méthode existante de gestion de projet de l’entreprise et
définir une documentation lisible et simple

Réaliser un catalogue des spécifications fonctionnelles de sécurité, puis un
catalogue des solutions de sécurité disponibles
Impliquer et faire adhérer les acteurs

Une adhésion des Métiers pour obtenir une vision claire des besoins et des
équipes opérationnelles qui voient surtout les contraintes de délai et de budget

Un accompagnement par des experts sécurité indispensable pour la mise en
application de la méthodologie ISP
Mettre en œuvre progressivement la méthodologie

Ancrer les actions de sensibilisation dans les processus existants
17
www.solucom.fr
Contact
Etienne CAPGRAS
Consultant Sénior
Tel : +33 (0)1 49 03 24 51
Mobile : +33 (0)6 67 49 45 35
Mail : [email protected]
Une démarche classique de déploiement d’une méthode ISP
Définition
des
volets
sécurité
Analyse du processus
de gestion des projets

Analyser la
documentation
existante

Rencontrer les
acteurs principaux
des équipes SI

Synthétiser l’existant
et définir les
orientations de la
méthode
Entretiens
Synthèse et
orientations



Réalisation
d’un pilote
(facultatif)
Définir la
méthodologie ISP
Définir le Dossier
Sécurité et les outils
Intégrer la
méthodologie ISP
dans la démarche de
gestion de projets de
l’entreprise


Tester sur un projet
en cours
d’initialisation
Mettre à jour la
méthodologie en
fonction des retours
Formation

Former les CP à la
méthodologie ISP
Réunions pilote
Méthodologie v0
Dossier Sécurité v0
Accompagnement à la
mise en
œuvre
Méthodologie v1


Support de
formation
Définir l’outillage de
suivi de la mise en
oeuvre
Accompagner les
projets dans la mise
en oeuvre
Outillage de suivi
du déploiement
Dossiers Sécurité
renseignés
Dossier Sécurité v1
19

1. Les processus d`intégration de la sécurité dans les projets SI 1.0

Transcription

Documents pareils

Journée Internationale de la Francophonie

Le squelette humain : les os

Calendrier de la formation Admission Gardien de la Paix concours

Les Échos, 07 octobre 2011

Algeria ISP - Le Réseau des Pages Franco Orientales

Mineure SOA – Etude de Cas

lettre de condoléances

IAMRECON 23 et 24 avril 2015

Consultant en Cybercriminalité et gestion de crise (h/f)

Français