Procédure de Développement Sécurisé

SOMMAIRE

1. GÉNÉRALITÉ 3

2. RÈGLES DE DÉVELOPPEMENT 4
1. Généralité
1. Objet
Cette procédure décline les exigences de sécurité relatives aux développements des
applications ou de l’implémentation de solutions intégrées externes (progiciels, systèmes
clés en main, etc.) au sein de la NOM ENTREPRISE.

2. Domaine d’application

L’objectif de cette procédure est de traduire la prise en compte des contraintes de sécurité
pendant l’élaboration de projets de Développement, d’Ingénierie et d’intégration de nouvelles
applications au SI de la NOM ENTREPRISE, tout au long du cycle de vie du projet et durant
sa maintenance. Ceci permettra d’atteindre les objectifs de sécurité, sans se limiter aux
seuls aspects de disponibilité.

2. Règles de développement
Les collaborateurs concernées (chef de Projet de Développement, d’Ingénierie ou
d’intégration de l’Application, ….) et le responsable Sécurité du SI procéderont à une
évaluation des risques qui pèsent sur l’application concernée, en termes d’informations, de
traitements, etc. ce qui permet d’en déduire la définition des exigences de sécurité du projet.

La définition des exigences de sécurité doit permettre d’identifier la nature des contrôles à
mettre en œuvre, de façon automatisée et/ou manuelle, et d’en déduire les schémas
éventuels d’adaptation nécessaires.

1. Qualité de développement
Le développement des nouveaux composants doit se faire en respectant les bonnes
pratiques en vigueur dans les phases d’analyse, de conception, de mise en œuvre, de
documentation et de tests d’intégration avec les composants existants, ce qui permet
d’assurer la qualité idoine du SI et de faciliter la maintenance de ces composants.

Il est important lors du développement des applications de mettre en relief les critères
suivants:
 Les contrôles de sécurité (contre les attaques d’injection SQl, XSS, Buffer
Overflow…) ;
 La gestion des sessions utilisateurs ;
 La méthode d’authentification ;
 Traçabilité ;
 La gestion et le control d’intégrité des données ;
 Simplicité des mécanismes ;
 Réutilisation de code.

2. Qualité de développement
Lors du développement d’un module ou d’une application, il est nécessaire d’inclure de façon
systématique les contrôles suivants:
 S'assurer que toutes les composantes de système et tous les logiciels du système
disposent des correctifs de sécurités les plus récentes ;
 Installer les correctifs de sécurité dans un délai d’un mois suivant leur publication
 Mettre en place un processus destiné à identifier les vulnérabilités en matière de
sécurité nouvellement identifiées (par exemple, souscrire un abonnement à des
services d’alerte gratuit disponibles sur l'Internet).
 une seule session applicative simultanée par utilisateur
 La durée d’une session doit être limitée
 Mettre en place un bouton déconnexion dans l’application
  S’assurer que la fermeture d’une session se fait correctement (supprimer les
enregistrements dans la table session et supprimer l’environnement de session coté
serveur) pour limite le risque de vols de session (session hijacking, cookie
spoofing…)
 S’assurer de la manipulation correcte des données (Accès aux données partagées,
aux fichiers, au réseau, Etc.)
 Utiliser les listes blanches pour le contrôle des données
 Un contrôle de validation des entrées et sorties des données tant on-line comme off-
line.
o Valeurs au-delà des limites,
o Caractères non valides dans des champs de données,
o Données manquantes ou incomplètes,
o Etc.
 En cas d’anomalie de fonctionnement d’une application, une page d’erreur ne
contenant aucunes informations techniques sensibles (version du serveur, BD…) doit
être renvoyée à l’utilisateur
 Tester tous les correctifs de sécurité, ainsi que toutes modifications de configuration
de système ou de logiciel avant déploiement.

3. Gestion des accès

Les équipes de développement doivent s’assurer que le module mis en place pour
l’identification et l’authentification soit sûr et fiable et répond aux exigences de sécurité,
notamment :

 La transmission des identifiants soit résistante aux :

o Écoutes passives
 Afin que les identifiants et les mots de passe ne puissent pas être
capturés
o Tentatives de rejeu
 Afin que la séquence d’authentification ne puisse être rejouée
o Attaques de type « Man in the Middle »
 Afin que les données ne soient pas transmises à un tiers malveillant
o Attaques de type cryptanalytiques
 Afin que les données sensibles ne puissent pas être décryptées par un
tiers illégitime
 L’affichage d’un message d’avertissement qualifiant précisément le système
d’information accédé
 o Propriétaire, Caractère privé, Restrictions d’accès, Usage, etc.
 L’utilisation des outils de gestion des accès externes à l’application développée;
 Utilisation d’un mot de passe alphanumérique robuste
 La possibilité de changement du code d’accès à la première connexion ou à la
volonté de l’utilisateur;
 La validation de la complexité du code choisis et le masquage de la saisie à l’écran
du code secret;
 Interdiction d’accès a l’application aux utilisateurs non habilités.

4. Protection des informations

Les données à caractère confidentiel doivent être protégées en stockage et lors de la
transmission par des mécanismes de chiffrement.

Les informations d’authentification doivent être protégées en stockage et lors de la

transmission sur réseau.

Pour les données qui nécessitent un contrôle d’intégrité en stockage ou lors de la

transmission, il est nécessaire de mettre en place des mécanismes de checksum ou de
cryptographie.

Il est aussi nécessaire de mettre en place des mécanismes de protection des codes sources
contre tout accès non autorisé en particulier les codes sources de traitement des données
stratégiques et d’implémentation des mécanismes de sécurité.

5. Séparation des environnements

L’architecture des plates formes mise en place doit garantir un cloisonnement des
environnements de développement, de tests et de production.
Il faut :
 Supprimer les données et comptes de tests avant que les systèmes de production ne
deviennent actifs ;
 Supprimer les comptes d’application, noms d’utilisateur et mots de passe usuels
avant que les applications ne deviennent actives ou ne soient mises à la disposition
de clients.

Les équipes de développement ne sont pas autorisées à :

 Accéder à l’environnement de production
o Si ce n’est à l’information opérationnelle nécessaire dans le cadre du projet
applicatif encours;
  S’impliquer dans les opérations de production liées aux applications qu’elles ont
conçues.
 Tous les profils utilisateurs et administrateurs doivent avoir été définis, mis en place
et validés avant toute bascule d’une application en production.

6. Tests de développement
Les procédures de tests doivent intégrer le test et la validation des fonctionnalités de sécurité
suivantes :
 Examen du code personnalisé avant de mettre à la disposition de la production ou de
clients afin d’identifier toute vulnérabilité de cryptage éventuelle
 Validation des données d’entrée et sortie;
 Validation des mécanismes d’authentification;
 Validation des mécanismes de gestion des sessions
 Validation des interfaces d’échanges avec d’autres systèmes;
 Impacts sur les mécanismes de sécurité déjà en production;
 Test de performance et robustesse (test de monté en charge);
 La simulation de cas ou de situations complexes ;
 La simulation d’attaques

Les jeux d’essais constitués à partir de données de production doivent répondre aux
exigences suivantes :
 L’utilisation de toute donnée de production doit être conditionnée par un accord
formel du Responsable fonctionnel ;
 Les données privées doivent être rendues anonymes ;
 Les données sensibles ou critiques doivent être modifiées afin d’être déclassifiées ;
 En cas de maintien de valeurs sensibles, les données ne doivent être accessibles
qu’aux personnes habilitées et doivent faire l’objet d’une surveillance particulière.
 Les données de porteurs de cartes actives ne peuvent en aucun cas faire office de
données de tests

7. Tracabilité
La mise en place de la traçabilité applicative doit prendre en compte :
 Les conditions qui nécessitent la mise en œuvre de dispositifs de traçabilité ;
 Les attributs des enregistrements de journalisation;
 La durée et les conditions de conservation des informations journalisées.

8. Maintenance des applications

Lors des opérations de maintenance, il y a lieu de s’assurer que :
  les procédures en matière de contrôle des changements pour toutes les modifications
apportées au système et au logiciel sont respectées
 Les autorisations formelles pour effectuer les modifications ont bien été obtenues ;
 La perturbation du service est minimale ;
 Les dispositifs de sécurité en place au sein du système d’information concerné ne
risquent pas d’être compromis, pendant ou après la maintenance ;
 Les personnels de maintenance ont accès au seul environnement de travail dont ils
ont besoin ;
 La documentation et les procédures utilisateurs sont bien mises à jour.

Les interventions de maintenance applicative en environnement de production (application

de routines de correction, accès direct aux bases de données, etc.) doivent être validées par
les responsables fonctionnels ou le RSSI. Elles doivent donner lieu à un rapport détaillé
intégrant :

 La date et l’heure début/ fin de l’intervention, les nom/prénom de l’intervenant ;

 La nature et le bilan de l’intervention ;
 une copie des données avant et après l’intervention requise.

9. Documentation des applications

Une documentation complète doit être élaborée et tenue à jour pour l’ensemble des
applications du système d’information. Elle doit contenir :
 Une documentation technique incluant les aspects de sécurité
o Procédures d’installation, d’intervention en cas d’incident, de sauvegarde,
Gestion des versions, etc.
 Une documentation applicative (modèles de données et de traitements, interfaces
externes ...) ;
 Une documentation utilisateur, incluant également les aspects de sécurité.

10. Engagement fournisseur

Les contrats de sous-traitance de développement et les conventions de stage prévoyant le
développement d’applications doivent mentionner :
 Une clause de confidentialité afin de garantir le respect de la confidentialité de tout
livrable (codes sources, documentation, etc.) et de tout composant auquel le
fournisseur aura accès ou toute autre information auquel il aura pris connaissance
durant sa mission (procédures internes, autres livrables de développement,
architectures des SI, etc.) ;
 Une clause de transfert de propriété en faveur de la NOM ENTREPRISE ;
 Une clause de respect de la législation en vigueur.
 Identifier et corriger les vulnérabilités de codage avant la mise en production en se
basant sur les meilleurs pratiques des secteurs