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

1. Thèmes à enseigner

Voici les entrées à utiliser pour cette section :

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 :

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 :

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

1. Définition du projet

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

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.

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 :

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.

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 :

1. Revue de code manuelle

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

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é :

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 :

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...

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

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

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 :

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