Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Sécurité informatique sur le Web
  3. Établir un cycle de développement sécurisé
Extrait - Sécurité informatique sur le Web Apprenez à sécuriser vos applications (management, cybersécurité, développement et opérationnel)
Extraits du livre
Sécurité informatique sur le Web Apprenez à sécuriser vos applications (management, cybersécurité, développement et opérationnel) Revenir à la page d'achat du livre

Établir un cycle de développement sécurisé

Introduction

Après avoir étudié l’environnement de la sécurité web, les risques majeurs et les concepts à connaître pour sécuriser une application, nous allons pouvoir orchestrer tout cela à travers un cycle de développement sécurisé.

Un S-SDLC (Secure Software Development Life Cycle) a pour objectif d’intégrer des actions et des contrôles de sécurité dans un processus de développement des applications, le but étant d’améliorer la sécurité et de réduire les coûts de maintenance et de remise en marche d’une application après incident. Microsoft, qui a beaucoup contribué dans le domaine des cycles de développement sécurisés avec son process model Security Development Lifecycle (SDL), estime qu’une vulnérabilité corrigée dans le code est en moyenne cent fois moins chère après incident et que son framework lui aurait permis de faire baisser son taux de vulnérabilités de 91 % en 36 mois sur Windows Vista.

Plutôt populaire chez les grands comptes, le S-SDLC est pourtant adaptable à toute société voulant intégrer de la sécurité au sein de son cycle de développement même si des particularités sont à souligner pour les méthodes...

Sensibilisation des parties prenantes

1. Thèmes à enseigner

Voici les entrées à utiliser pour cette section :

images/05EP03.png

Le prérequis pour commencer un cycle de développement sécurisé est la formation des parties prenantes du projet. Les développeurs, testeurs (QA) et idéalement les managers doivent être sensibilisés aux bases de la sécurité applicative telles que :

  • Les risques autour d’une application,

  • La sécurisation du code,

  • La conception d’une application sécurisée,

  • La modélisation des menaces,

  • L’audit de la sécurité d’une application,

  • Les bonnes pratiques en matière de données privées.

L’idéal pour une sensibilisation dans un axe d’amélioration continue est de faire une formation annuelle des équipes, d’impliquer les parties prenantes dans la sécurité et d’apporter de la veille technologique. Voici un exemple de programme établi suivant les branches métier des personnes impliquées dans un S-SDLC :

Programme développeur

Plan de cours (idéal 5 jours)

  • Présentation des différentes lois, normes, guide des bonnes pratiques

  • Étude du TOP 10 OWASP

  • Sécurité des navigateurs, serveurs

  • SAST, WAF, DAST

  • Revue de code, conception d’une architecture sécurisée

  • Test de la sécurité d’une application web

  • Modélisation des menaces

  • Respect de la vie privée

Programme administrateur/système

Plan de cours (idéal 3 jours)

  • Présentation des différentes lois, normes, guides des bonnes pratiques

  • Étude du TOP 10 OWASP

  • Sécurité des navigateurs, serveurs

  • SAST, WAF, DAST

  • Conception d’une architecture sécurisée

  • Modélisation des menaces

Programme testeur QA

Plan de cours (idéal 2 jours)

  • Présentation des différentes lois, normes, guides des bonnes pratiques

  • Étude du TOP 10 OWASP

  • Sécurité des navigateurs, serveurs

  • Respect de la vie privée

Program manager, chef de projet

Plan de cours (idéal 1 jour)

  • Présentation des différentes lois, normes, guides des bonnes pratiques

  • Étude du TOP 10 OWASP

  • Respect de la vie privée

Les programmes présentés ci-dessus sont des exemples...

Exigences

1. Définition du projet

Voici le schéma représentant les entrées pour cette phase du S-SDLC :

images/05EP07.png

Maintenant que les équipes sont formées aux bases de la sécurité applicative, il est nécessaire de définir le projet avec les parties prenantes (manager, décideur, chef de projet, développeur, etc.) en charge du développement des applications. L’étude des coûts d’un S-SDLC, la nomination des responsables et conseillers en sécurité et les exigences en protection des données personnelles seront intégrées dans cette phase. Toutes les étapes présentées dans ce chapitre doivent être adaptées suivant la méthode de travail de l’organisation. En effet, une société ne pourra pas utiliser de la même façon les actions et contrôles à mettre dans un S-SDLC suivant les méthodes de travail (Agile, Waterfall, Lean, etc.). Une précision sera apportée pour chaque action et contrôle à mettre en place dans le S-SDLC sur la manière de faire pour une méthode agile et une méthode classique.

Voici la présentation des différentes étapes pour la définition du projet.

  • Réunir les informations (Agile et méthode classique - cette étape est à effectuer une fois durant le processus) : regrouper toutes les informations sur la politique de sécurité de l’organisation (analyse de risque, Business Impact Analysis, Privacy Impact Assessment, schéma directeur, SLA). En effet, il est important d’avoir connaissance en amont des exigences de l’organisation en termes de sécurité de l’information. Toutes les entreprises ne sont pas sensibles aux risques. Dans ce cas de figure, il est nécessaire de passer à la prochaine étape, le but étant d’obtenir un maximum d’information sur le contexte de l’entreprise et sur sa vision du risque et de la sécurité de l’information en général. Un S-SDLC n’a pas vraiment de sens si l’organisation ne sait pas où elle veut aller en matière de sécurité et pourquoi elle le fait. Si la société n’est pas du tout sensible...

Conception

1. Définition des exigences de conception

La phase de conception a pour objectif d’aligner les exigences établies lors de la phase précédente sur l’architecture de l’application. L’intérêt est de démarrer la création d’une application avec les bonnes pratiques afin de réduire au maximum les risques dès le départ. La plupart des attaques et vulnérabilités peuvent être évitées si les bonnes pratiques sont adoptées par l’organisation et l’équipe de développement. L’idée est de "prévenir avant de guérir" en utilisant les technologies, les procédures et les analyses adaptées.

Voici une illustration représentant les entrées pour la phase conception :

images/05EP12.png

Pour démarrer avec la phase Conception, il est nécessaire de réfléchir aux spécifications techniques et d’architecture à attribuer à l’application pour respecter les exigences de l’organisation en termes de sécurité et de protection des données à caractère personnel.

images/05EP13.png

Une méthode assez simple consiste à créer une liste de spécifications qui indique à l’équipe autour du S-SDLC les bonnes pratiques à utiliser et les obligations lors de la conception de l’application. Cette liste a pour particularité de prendre en compte le refus implicite, c’est-à-dire que ce qui n’est pas dans la liste est automatiquement refusé et nécessite l’accord du conseiller en sécurité pour être inséré, le but étant de créer dès le départ une architecture autour de la sécurité et du respect des données personnelles. Il est aussi possible d’utiliser la liste pour des modifications dans une architecture existante mais cela nécessite une analyse des surfaces d’attaque, qui sera vue dans la prochaine section.

Cette liste peut contenir les items suivants :

  • règles de chiffrement

  • règles d’authentification

  • gestion des sessions

  • gestion des entrées et sorties

  • gestion des erreurs

  • gestion des services web

  • contrôle d’accès

  • protection des données

  • règles...

Code

1. Revue de code manuelle

Voici une illustration représentant les entrées pour la phase de code :

images/05EP21.png

La phase de code dans un S-SDLC doit permettre de développer une application de qualité et de mettre en place des contrôles de sécurité. Sachant que les vulnérabilités trouvées dans le code sont beaucoup moins coûteuses que celles découvertes lors d’un test de pénétration, cette phase est essentielle.

Deux méthodes sont utilisées pour contrôler la sécurité dans le code, la première étant manuelle avec l’utilisation d’une check-list afin de vérifier que le code est conforme aux exigences de sécurité. Celle-ci est le plus souvent appelée "revue de code manuelle". L’autre méthode est dynamique avec l’utilisation d’outils dédiés à cet effet.

La création d’une check-list de revue de code doit se faire avec le responsable et le conseiller en sécurité en respectant les exigences de la société en sécurité. Plusieurs code reviews sur Internet et documentations éditeur permettent la création de sa propre check-list. Voici un exemple inspiré du TOP 10 OWASP déjà introduit dans le chapitre Les concepts du développement sécurisé :

Id

Objet

Contrôle de sécurité

Check-list

1

Utilisation de mots de passe forts

Les mots de passe dépassent-ils dix caractères minimum ?

Oui/non

Les mots de passe sont-ils complexes (majuscules, chiffres, caractères spéciaux) ?

Oui/non

2

La réinitialisation des mots de passe est-elle sécurisée ?

Un jeton unique est-il créé pour la réinitialisation ?

Oui/non

3

Changement des données personnelles

Une réauthentification est-elle demandée lors des changements des données personnelles sur l’application afin de prévenir les attaques de session ou CSRF ?

Oui/non

4

Le stockage des mots de passe

Les mots de passe sont-ils hachés en base de données ?

Oui/non

Les mots de passe sont-ils salés avant d’être envoyés en base ?

Oui/non

5

Message d’erreur

Les messages d’erreur qui apparaissent...

Test

1. Analyse dynamique

Avant d’envoyer l’application en production, ou du moins une nouvelle version, la phase de test est élémentaire afin de vérifier les différentes vulnérabilités que les cybercriminels pourraient utiliser. En effet, cette phase doit se dérouler de manière à se mettre dans la peau d’un pirate effectuant des attaques sur l’application. Des scans de vulnérabilité et des tests de fuzzing ou de pénétration vont être effectués et pour certains, automatisés. Voici les entrées à pratiquer :

images/05EP26.png

Pour commencer, l’indispensable est l’analyse dynamique de l’application à l’aide d’un scanner de vulnérabilités. Il existe de nombreux produits sur le marché, dont un assez réputé et gratuit pour les applications web : l’OWASP Zed Attack Proxy (ZAP), déjà présenté dans le chapitre Les concepts du développement sécurisé - Outils indispensables de la sécurité web.

L’idéal est l’automatisation de scans de vulnérabilités avant la mise en production de l’application, ce qui permet de gagner du temps.

Certains outils d’automatisation des scans de vulnérabilités sont utilisés en cloud à travers Internet, d’autres peuvent être configurés en local (on-premise) afin de lancer un scan dès le déploiement d’une application en préproduction. L’utilisation d’outils comme Docker, Travis ou Jenkins permet l’automatisation complète et le chaînage d’une préproduction avec les tests dynamiques de sécurité (Agile à chaque sprint et méthode classique à réaliser à chaque modification de l’application).

2. Test de fuzzing

Le test de fuzzing, quant à lui, permet une plus grande granularité dans la recherche de vulnérabilités sur une application. Tout comme l’analyse dynamique, cette méthode est étudiée au chapitre Les concepts du développement sécurisé. Pour rappel, le fuzzing a pour fonction d’envoyer des données aléatoires afin de provoquer des erreurs dans l’application...

Déploiement

1. Création d’un plan de réponse aux incidents

Voici les entrées pour cette phase du S-SDLC :

images/05EP30.png

Le plan de réponse à incident est un élément assez connu du monde de la sécurité de l’information car il permet de garder une certaine proactivité au sein d’un système d’information en cas d’échec de sécurité.

Certaines sociétés sont dotées d’équipes dédiées à cet effet, parfois nommées CSIRT (Computer Security Incident Response Team). Une bonne majorité de PME n’ont pas cet effectif et encore moins de plan de réponse à incident. Pourtant, il peut être judicieux d’instaurer un processus simple regroupant les procédures à suivre lors d’un incident et les responsabilités de chacun. La première étape consiste à former une équipe, généralement la même en charge du développement dans les petites structures avec les rôles suivants :

  • Le responsable d’équipe, dont l’approche consiste à superviser l’équipe en cas d’incident. Le bon déroulement de la procédure et les actions à mener pour rétablir l’application sont de sa responsabilité.

  • Le responsable de l’incident a pour tâche de communiquer, d’aller chercher l’information et d’épauler le responsable d’équipe dans la résolution de l’incident sur un aspect informatif. En effet, il va être chargé de trouver les informations autour des moyens juridiques et d’assurance, et toute autre mesure pour rétablir un ou des incidents de sécurité.

  • D’autres personnes extérieures peuvent avoir un rôle au sein d’un plan de réponse à incident telles qu’un juriste, un responsable des relations publiques ou une personne faisant partie du top management de l’organisation pour la stratégie à suivre si l’impact est sévère.

Une fois les responsabilités attribuées ou la construction d’une équipe CSIRT établie, un plan de réponse à incident doit être érigé....