Liste de contrôle pour la sécurité de l'information lors

du développement de projets
Information Security Policy
Version 2.00 3/11/20101

ISMS
(Information Security Management System)

Liste de contrôle pour la sécurité de

l'information lors du développement
de projets

Version control – please always check if you’re using the latest version
Doc. Ref. : isms_021_checklist_project_fr_2_00.doc

Release Status Date Written by Approved by

FR_1.30 Final 10/10/2007 Johan Costrop Groupe de Travail
Sécurité de l’information
FR_2.00 Final 3/11/2010 Patrick Bochart Groupe de Travail
Sécurité de l’information
Remarque : Ce document intègre les remarques formulées par un groupe de travail auquel ont participé les
personnes suivantes: messieurs Bochart (BCSS), Costrop (Smals), Noël (BCSS), Petit (FMP), Quewet (SPF
Santé publique), Symons (ONEm), Van Cutsem (ONSS-APL), Van der Goten (INAMI) , …
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

Table des matières

1. INTRODUCTION .................................................................................................................................... 3

2. PORTÉE ................................................................................................................................................. 3

3. DÉFINITIONS ......................................................................................................................................... 3

4. EXIGENCES DE SÉCURITÉ DANS LE CADRE DU DÉVELOPPEMENT DE PROJETS ................... 3

4.1. CLASSIFICATION DES DONNÉES .............................................................................................................. 3
4.2. EXIGENCES RÉGLEMENTAIRES................................................................................................................ 4
4.2.1. Loi vie privée et loi Banque Carrefour de la Sécurité Sociale ..................................................... 4
4.2.2. Autorisations du Comité Sectoriel................................................................................................ 4
4.2.3. Force probante............................................................................................................................. 4
4.2.4. Dossier unique ............................................................................................................................. 4
4.2.5. Conventions Banque Carrefour de la sécurité sociale ................................................................ 4
4.3. NORMES MINIMALES DE SÉCURITÉ .......................................................................................................... 4
4.3.1. Sous-traitance.............................................................................................................................. 4
4.3.2. Communication ............................................................................................................................ 4
4.3.3. Gestion des accès ....................................................................................................................... 5
4.3.4. Checklist....................................................................................................................................... 5
4.3.5. Contrôle avant mise en production .............................................................................................. 5
4.3.6. Approche structurée..................................................................................................................... 6
4.3.7. Loggings....................................................................................................................................... 6
4.3.8. Sauvegarde.................................................................................................................................. 6
4.3.9. Gestion de la continuité ............................................................................................................... 6
4.3.10. Gestion des incidents ............................................................................................................... 7
4.3.11. Documentation ......................................................................................................................... 7
4.3.12. Inventaire.................................................................................................................................. 7
4.3.13. Audit ......................................................................................................................................... 7
4.4. PROJECT LIFE CYCLE ............................................................................................................................ 7
4.4.1. Initialisation .................................................................................................................................. 7
4.4.2. Planification.................................................................................................................................. 7
4.4.3. Réalisation ................................................................................................................................... 8
4.4.4. Clôture.......................................................................................................................................... 9

P2
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

1. Introduction

Ce document s'inscrit dans le développement de l'ISMS (Information Security Management System). Dans le
cadre d'une bonne organisation de la sécurisation des projets informatiques, il est nécessaire de définir des
exigences de sécurité à partir de la phase de conception d'un projet. Cette recommandation est fixée par la
Politique de sécurité de l'information (ISP). Il est référé aux articles concernés de l'ISP.
Il est également essentiel de tenir compte des normes minimales de sécurité que doivent observer les
institutions sociales en vue de leur connexion au réseau de la Banque Carrefour de la Sécurité Sociale.
Celles-ci sont indiquées dans le texte par la mention « norme minimale ».

2. Portée

Ce document relatif aux aspects de sécurité dans le cadre de développements et de maintenance de projets
ICT ne s'adresse pas seulement aux responsables de projets mais également à l’ensemble des parties
prenantes (par exemple : membres des équipes développements, opérationnelles et achats).

3. Définitions

Certains termes, relatifs à la classification des données, utilisés dans le présent document sont définis dans
le document « ISMS.022 Policy Dataclassification » ; par exemple : données à caractère personnel, données
confidentielles, ...

4. Exigences de sécurité dans le cadre du

développement de projets

4.1. Classification des données

Dans chaque phase du développement, une attention particulière doit être accordée aux mesures de
protection appliquées au traitement des données manipulées en fonction de leur classification..
Dès le départ de tout projet, il est nécessaire de réaliser une analyse des risques encourus dans le cadre du
traitement des informations en regard de leur catégorisation/classification.
Cette analyse déterminera, par exemple, le besoin éventuel de méthodes cryptographiques afin d’assurer la
confidentialité, l’autenticité et l’intégrité des données traitées. Ces techniques peuvent également contribuer
à établir la non-répudiation des transactions (ISP).
Une attention particulière doit être accordée à la protection des données liées aux paramètres
cryptographiques (clés, certificats, …) qui ne doivent jamais être enregistrées sous une forme non sécurisée
(ISP).
Des mesures doivent être prises entre autre pour éviter la perte, la modification ou le vol d'informations
échangées avec d'autres institutions (ISP / Normes minimales).

P3
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

4.2. Exigences réglementaires

4.2.1. Loi vie privée et loi Banque Carrefour de la Sécurité Sociale

Il est nécessaire de veiller au respect des exigences en matière de sécurité, légales ou autres, auxquelles
sont soumis les systèmes d'information (ISP). Par exemple, la protection de la vie privée et la législation
dans le cadre de la sécurité sociale.

4.2.2. Autorisations du Comité Sectoriel

Une autorisation du Comité Sectoriel compétent est obligatoire pour permettre à une institution d'exploiter
des données à caractère personnel lorsqu’elle n'est pas propriétaire de ces données.

4.2.3. Force probante

Lorsque la force probante est requise, un dossier sera constitué et soumis pour approbation aux instances
compétentes. Le cadre de la force probante est défini dans les arrêtés royaux s’y référents.

4.2.4. Dossier unique

La sécurité sociale a mis en oeuvre un processus de contrôle des aspects légaux et sécuritaires lors de la
mise en production d’une application en son sein. Cette validation est formalisée par un « Dossier Unique
(aspects légaux) pour la mise en production d’une application Sécurité Sociale ».
Le dossier unique centralise des informations nécessaires aux gestionnaires des systèmes d’information de
la sécurité sociale pour la mise en production d’une application conformément aux dispositions
réglementaires en matière de sécurité de l’information et de protection des données.
Ce dossier doit être introduit lorsque les utilisateurs finaux ne font pas uniquement partie de l’institution
responsable de traitement / propriétaire des données.

4.2.5. Conventions Banque Carrefour de la sécurité sociale

Lorsque des services électroniques de la BCSS sont utilisés, une autorisation adéquate est requise
préalablement.

4.3. Normes minimales de sécurité

L’ensemble des points suivants devront être appliqués comme prescrits par les Normes Minimales de la
Sécurité Sociale imposées par le Comité Sectoriel de la Sécurité Sociale et de la Santé.

4.3.1. Sous-traitance

En cas de sous-traitance d’activité ICT, il est important de contractualiser les aspects de sécurités (ISP) et
entre autre les aspects de confidentialité et de continuité.

4.3.2. Communication

Une communication efficace et constructive doit être établie entre les différentes parties concernées par le
projet (clients et fournisseurs inclus) et essentiellement envers le/les conseillers en sécurité afin de garantir
un niveau de sécurité adéquat connu de tout un chacun. Cette communication permet de respecter les
principes décrits dans l'Information Security Management System (ISMS) sur base de l’Information Security
Policy (ISP),

P4
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

De même ces acteurs doivent être informés quant à leurs responsabilités personnelles telles que décrites
dans l'ISP, et développées notamment dans le document « Code de bonne conduite des gestionnaires
d’informations », ou inhérentes à leur déontologie spécifique :
• la limitation de la consultation de données confidentielles aux fins strictement professionnelles ;
• le secret des données confidentielles.

4.3.3. Gestion des accès

L’ensemble des collaborateurs, et particulièrement les collaborateurs externes, utilisant des outils ICT mis à
leur disposition par l’institution le font sur la base d'autorisations limitées à l'exécution de leur tâche.
Lors de l’évaluation de la sécurisation des accès, il est important de tenir compte des systèmes de gestion
déjà opérationnels (par exemple : le système de gestion des accès U&AM), ainsi que leurs évolutions. Leur
utilisation garantira une indépendance entre le système de gestion des autorisations des accès et les
systèmes développés.
Les exigences relatives à la sécurisation des accès (identification, authentification et autorisation) doivent
être définies et documentées (ISP). Le niveau de sécurisation des accès doit être adapté au degré de
confidentialité des données traitées et aux menaces potentielles sur base d’une analyse des risques (ex.
l’accès par des réseaux publics). Ces accès, seront tracés et enregistrés (voir paragraphe 4.3.7. Logging)
(norme minimale)
Sachant que dans le cadre d'une application, des groupes différents d'utilisateurs peuvent détenir des droits
distincts (ex. lecture, écriture, modification) en fonction des degrés de confidentialité des données, il est
nécessaire d’en tenir compte pour la granularité de l'accès aux données.
Il est conseillé d’éviter toute gestion des accès interne au projet. Néanmoins, si cette gestion interne devait
être implémentée, des procédures formelles doivent être définies au niveau de toutes les phases du cycle de
vie de la gestion des accès (introduction, contrôle sur base d’inventaire, mutation et suppression des
comptes utilisateurs) (ISP).
Lorsqu’un échange entre l'institution de sécurité sociale et la BCSS est réalisé par une application identifiée
par un numéro de programme mais qu'une personne physique est à la base de cette opération, l'institution
doit pouvoir établir la relation entre le numéro de programme, les informations échangées et l'identité de la
personne physique.

4.3.4. Checklist

Sur base de l’ensemble des recommandations présentées dans ce document, le chef de projet doit mettre
en œuvre une liste de contrôle lui permettant de s’assurer dans le cours du développement du projet que
l’ensemble des dites recommandations sont bien évaluées, et au nécessaire implémentées.

4.3.5. Contrôle avant mise en production

Dans le cadre de la mise en production du projet, le responsable du suivi, chef de projet, doit s’assurer que
le respect des exigences de sécurité établies au début de la phase de développement sont implémentées.

P5
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

4.3.6. Approche structurée

Une séparation doit exister tant au niveau des environnements de développement, test, acceptation,
production, qu’au niveau des responsabilités au sein du projet le tout sous la supervision d’un seul et unique
responsable : le chef de projet.

4.3.7. Loggings

Tout accès aux données personnelles et confidentielles à caractère social et/ou médical doit être enregistré
conformément aux normes minimales, à la politique de sécurité relative au loggings (ISMS.026 : Logs à
caractère sécuritaire dans les applications du réseau de la Sécurité Sociale) et aux législations applicables.
Les spécifications d'un projet détermineront comment l'accès et l’utilisation des systèmes et applications
doivent être enregistrés afin de participer à la détection des transgressions aux règles de sécurité en
vigeur (ISP); telles que la politique des accès, la détection des anomalies, ….
Ces traces doivent, par exemple, répondre aux objectifs suivants :
• l’obligation de pouvoir répondre à la question de base du QUI a fait QUOI, QUAND l’a-t-il fait, et
COMMENT y est il parvenu ? ;
• le besoin d’identifier les personnes responsables d’un éventuel délit,
• le besoin d’identifier les types de contenus d’information accédés,
• …
Lors de l’évaluation des besoins en matière de traces au sein du projet il est important de tenir compte, des
systèmes de logging dédicacés déjà opérationnels, et ce afin d’éviter le développement en interne au projet
d’un tel système. De plus l’utilisation de ces systèmes dédicacés garantira une indépendance entre le
système des loggings et le projet développé.
Les outils nécessaires doivent être disponibles ou être développés afin de permettre aux personnes
autorisées d’exploiter ces données de logging.
La règle générale veut que les données de logging soient conservées au minimum pendant 10 ans.
Les exigences relatives au logging de données autres que les données de sécurité (également connu sous
le nom de logging technique ou fonctionnel) doivent également être spécifiées

4.3.8. Sauvegarde

Le chef de projet doit s’assurer que son projet puisse être intégré dans la gestion des sauvegardes de
l’institution tel qu’imposée par les normes minimales. Cela comprend tant l’ensemble des informations qui
seront traitées, que les documentations y relative (sources, programmes, documents techniques, …).

4.3.9. Gestion de la continuité

Au cours du développement du projet, les besoins en matière de continuité sont identifiés, analysés et
formalisés afin d’assurer la continuité des services qui seront mis en production, conformément à la stratégie
de l’institution en la matière.
Les points suivants sont à respecter obligatoirement :
• Les programmes doivent intégrer des points de redémarrage clairement définis en cas de problèmes
opérationnels. Ces informations font partie du dossier d’exploitation du système d’information.
• Lors du développement du projet une attention particulière doit être apportée à l’obligation des
sauvegardes mises en œuvre ainsi qu’à leur qualité.

P6
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

• Les exigences de l’institution concernant la tolérance de pannes ainsi que la redondance de

l’infrastructure doivent être prises en compte pour l'environnement de production.
• Le plan de continuité et les procédures associées doivent être tenus à jour en relation avec le
développement du projet et ce y compris la réalisation des tests de continuités.
Des procédures d’urgence ou de crise doivent être définies, en fonction de l’analyse des risques réalisée à
la conception du projet, en reprenant par exemple :
• Le fonctionnement en mode dégradé du système d’information.
• La description des systèmes d’information alternatifs, reprenant leur déploiement, les modalités de
leur exploitation et leur utilisation, y compris le développement éventuel de ces systèmes de
secours.
• Les procédures business à appliquer en cas de panne de systèmes.
• Les missions, rôles clés à assurer et moyens à mettre en œuvre pour parvenir à une disponibilité
optimale.

4.3.10. Gestion des incidents

Lors du développement du projet, les procédures en matière de suivi des incidents doivent être définies afin
d’assurer l’intégration de ce système d’information au sein des procédures et systèmes de gestion et de suivi
des incidents standardisés et intégrés dans l’institution, de manière à ce que le conseiller en sécurité soit
informé des incidents de sécurité.

4.3.11. Documentation

Tout au long de la vie du projet, une documentation (documentation technique, procédures, manuels, …)
doit être développée et maintenue.

4.3.12. Inventaire

Tous les actifs, tant achetés que développés doivent être intégrés au système de gestion des moyens de
l’institution.

4.3.13. Audit

Dans le cadre d’audit interne ou externe, une collaboration appropriée sera assurée sous forme de la mise à
disposition de personnel, de documentation, de loggings et ainsi que tout autre information adéquate.

4.4. Project Life Cycle

4.4.1. Initialisation

En concertation avec le donneur d’ordre, les mesures de sécurité tant techniques qu’opérationnelles doivent
être analysées, définies et formalisées lors de nouveaux développements ou d’extension du système
d’information.
Le conseiller en sécurité du donneur d’ordre, ainsi que les conseillers en sécurité des institutions impactées
par le projet doivent être partie prenante dès le départ,

4.4.2. Planification

Lors de l’élaboration du planning, il est impératif de tenir compte du temps et des moyens nécessaires et
utiles à l’implémentation des aspects de sécurité.

P7
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

Dès lors, la réaffectation du temps alloué à ces aspects ne peut se faire afin de tenir le planing annoncé
sans que ce choix soit argumenté et formellement validé sur base d’une analyse des risques. Toute
dérogation sera suivie d’actions correctrices afin de restaurer le niveau de sécurité initialement visé.

4.4.3. Réalisation

A. Développements et tests

Lors de tout développement et test, il est important de tenir compte des faiblesses qui pourront être
exploitées.
Un programme de formation adapté aux différentes responsabilités devrait toujours être prévu. L’attention
nécessaire doit être accordée aux risques liés aux applications web et aux contre-mesures possibles.
Il est donc très important de vérifier que les collaborateurs aient suivi les formations nécessaires pour
prendre conscience des menaces existantes et de l’importance de la sécurisation de l’information, et qu’ils
aient à leur disposition les moyens, connaissances et aptitudes adéquats pour protéger les systèmes.
L’attribution des rôles et droits d’accès spéciaux et critiques (ex. pour la gestion de versions de logiciels) doit
être limitée et leurs utilisations contrôlées (ISP).
• Les méthodes d'authentification (ex. mots de passe) et les niveaux d’autorisation doivent être gérés
selon un processus formel (ISP).
• Les collaborateurs doivent être sensibilisés à leur responsabilité quant au maintien d'une
sécurisation efficace des accès, notamment en ce qui concerne l'usage des mots de passe et la
protection du matériel des utilisateurs (ISP).
Lors du développement de systèmes, une attention particulière doit être consacrée à l'intégrité des données,
par exemple par la validation des données dès leur introduction, par la sécurisation du traitement interne et
par la validation des données en sortie. Des traces auditables doivent être intégrées (ISP).
Lors du développement de systèmes, il doit être tenu compte des points faibles de sécurité inhérents aux
langages de programmation. La vérification des logiciels par des tiers, autres que les développeurs,
constitue une méthode pour réduire ces risques (ISP). Si un tiers se charge de la vérification, il y a lieu d’en
vérifier la déontologie.
Pendant le développement, l'intégrité et la cohérence du logiciel sont garanties par une gestion procédurale
des versions du logiciel et la sécurisation des accès aux bibliothèques software (ISP).
Des mesures maximales doivent être prises pour éviter que des canaux de communication secrets ("covert
channels")1 et des Chevaux de Troie2 ne se cachent dans les logiciels développés (ISP).
L'accès aux systèmes et leur utilisation doivent être contrôlés pour détecter les dérogations à la politique
d'accès, ou les anomalies (ISP) (norme minimale).
La documentation des développements de nouveaux systèmes et de la maintenance de systèmes existants
est obligatoire (norme minimale). Ceci comprend la réalisation par le chef de projet d’une cartographie
fonctionnelle et d’une cartographie technique. Chacune de ces cartographies décrit, avec le niveau de détail
propre à chacune d’elle, les divers flux de données, les différents éléments (serveurs,…) concernés par ces
flux, ainsi que leur fonction dans le cadre de ce projet (serveur d'applications, base de données,…).
Les données de test doivent être manipulées avec précaution de manière à éviter tout danger lié à leur
confidentialité (ISP). A des fins de développement, seules des données de tests spécialement prévues à cet
effet (ISP) seront utilisées.

1
Ces canaux de communication secrets permettent d'utiliser par la suite ces logiciels à mauvais escient.
2
Les Chevaux de Troie désignent généralement un code non autorisé qui fait accomplir au logiciel autorisé
(dans lequel est dissimulé le dit code) d'autres fonctions que celles auxquelles il est initialement destiné.

P8
 Liste de contrôle pour la sécurité de l'information lors
du développement de projets
Information Security Policy
Version 2.00 3/11/20101

B. Mise en production

A ce stade, les aspects suivants auront dû être abordés, analysés et validés avec les personnes
responsables de la mise en production et de l’exploitation des systèmes d’information et ce conformément
aux exigences de l’utilisateur.
• La désignation d’un collaborateur ayant le rôle « d’Application Owner » qui aura la responsabilité du
système développé (évolution, documentation, point de contact,...).
• La finalisation par le chef de projet d’une version définitive d’une cartographie fonctionnelle et
technique (As Built).
Ces documents vont permettre aux différents gestionnaires des systèmes d’information
(gestionnaire réseaux, DBA, …) de tenir à jour leur propre cartographie des flux supportés par les
systèmes qu’ils gèrent.
• La conformité du projet, ainsi que les flux de données associés aux autorisations délivrées par le
Comité sectoriel.
• La conformité du projet aux nécessités de continuité de services définis.
• La disponibilité de la documentation et de manuels ; dont, entre autres, le dossier de production.
• Le respect des exigences en matière d’archivage.
• Le respect des exigences de sécurité en situation de production (confindentialité, intégrité,
disponibilité, force probante)
Par exemple :
• Les moyens de sauvegarde et d’exploitation des données de logging doivent être prévus (voir
paragraphe 4.3.7. Logging) en collaboration avec le service responsable de la production et le
conseiller en sécurité.
Remarques :
• En vue du respect des dispositions légales concernant la sauvegarde et l'utilisation des données
archivées, il convient de vérifier, à chaque évolution de l'infrastructure informatique et du système
d'information si l'archivage, les données archivées, les supports et les applications utiles sont
toujours en adéquation.
• De plus, et le cas échéant, les méthodes décrites dans le dossier de force probante seront, et
resteront, scrupuleusement respectées.
• La mise en production d’une application sur le portail de la Sécurité Sociale nécessite l’obtention
d’une autorisation de la BCSS (Utilisation du Dossier Unique).
• Les moyens et compétences nécessaires doivent pouvoir être mis à disposition pour une
intervention urgente en cas de problème survenant dans le cadre de la production.

4.4.4. Clôture

Le responsable du traitement, le responsable du projet, ainsi que les responsables d’exploitation des
systèmes d’information doivent veiller ensemble à ce que le système mis en oeuvre soit en phase avec les
autorisations accordées. (par exemple : ouverture des flux, …)

P9