Vous avez identifié le besoin auquel votre application web doit répondre ? Profitons de cet élan pour concevoir l’application et son fonctionnement !
Étape 3 : Design / Conception
L'étape de conception, ou "Design", représente un moment charnière dans le développement de votre application. C'est à ce stade que les spécifications recueillies et analysées précédemment se transforment en un plan d'action concret. Le but est de définir de manière précise comment l'application va fonctionner et interagir tant avec ses utilisateurs qu'avec les autres systèmes.
Ce processus mène à la création de documents essentiels comme les diagrammes de flux de données et l'architecture générale du système, jetant ainsi les bases d'une conception sécurisée.
Quelles sont les étapes clés à intégrer lors de la conception ?
Définition de l'architecture : Créer un plan détaillé qui spécifie la structure générale de l'application, incluant la manière dont le code est organisé, les pratiques à suivre, et l'utilisation de modèles ou de structures réutilisables.
Interfaces utilisateur et système : Concevoir des interfaces intuitives pour les utilisateurs et définir les protocoles de communication entre différents systèmes pour assurer une intégration fluide.
Gestion des données : Planifier les instances de bases de données nécessaires, en tenant compte des exigences de stockage, de récupération, et de sécurité des données.
Choix des technologies : Sélectionner les langages de programmation, les plateformes, et les outils qui seront utilisés pour développer l'application, en fonction de leurs capacités à répondre aux besoins du projet.
Sécurité : Intégrer les considérations de sécurité dès la conception en prévoyant des mesures telles que le chiffrement des communications, la gestion sécurisée des sessions, et la protection des données utilisateur.
Scénario peu mature
Dans un scénario peu mature, l'équipe de conception se précipite dans le développement sans planification adéquate, négligeant l'importance d'une architecture bien définie et d'une analyse de sécurité préalable.
Les décisions technologiques sont prises ici sur la base de préférences personnelles plutôt que sur l'adéquation aux besoins du projet. La sécurité est traitée comme une réflexion tardive, sans modélisation des menaces ou considérations pour la protection des données dès le début. Ce manque de rigueur conduit à des révisions coûteuses en cours de route et à une application finale vulnérable et peu intuitive.
Scénario mature
Dans un scénario mature, l'équipe adopte une approche méthodique dès le début de l’étape de conception. Un plan d'architecture détaillé est élaboré en tenant compte de l'organisation du code, des meilleures pratiques de l'industrie.
La sécurité est intégrée dès la conception, avec une modélisation des menaces réalisée pour identifier et atténuer les risques potentiels, garantissant ainsi une application sécurisée et bien conçue dès le départ.
Quel aspect particulier du SSDLC doit intervenir lors de cette étape ?
C'est lors de cette étape que vous mettez en place les bases pour identifier et contrer les menaces potentielles grâce à la modélisation des menaces. Une étape essentielle pour garantir la sécurité de l'application tout au long de son cycle de vie. Voyons cela ensemble dans la prochaine section.
Modélisez les menaces lors de la conception de votre application
Imaginez la modélisation des menaces comme la création d'une carte détaillée de tout ce qui pourrait affecter la sécurité de votre application. C'est une représentation structurée, une sorte de lunette de sécurité, qui nous permet d'examiner notre application et son environnement.
Un modèle de menace typique comprend :
Description du sujet : Qu'est-ce qu'on modélise exactement ?
Hypothèses : Quelles sont les suppositions que nous pourrions remettre en question à l'avenir ?
Menaces potentielles : Quels dangers guettent notre système ?
Actions de mitigation : Comment pouvons-nous contrer ces menaces ?
Validation et vérification : Comment s'assurer que notre modèle et nos actions sont efficaces ?
La modélisation des menaces est un processus d'organisation et d'analyse de toutes ces informations, permettant de prendre des décisions éclairées sur les risques de sécurité de l'application.
Quel est l’objectif d’une telle démarche ?
L'objectif principal est d'améliorer la sécurité en identifiant les menaces et en définissant des contre-mesures pour prévenir ou atténuer leurs effets. Que la menace soit malveillante, comme une attaque DDoS, ou accidentelle, comme une défaillance de matériel, le but est le même : protéger le système.
Plusieurs méthodes supportent ce processus. Le cours Analysez et gérez des risques SI est construit autour de l’ISO 27005. OCTAVE, STRIDE ou encore PASTA peuvent aussi être utilisées.
Quelle que soit la méthode utilisée, le processus consiste à répondre progressivement à quatre questions clés :
Sur quoi travaillons-nous ?
Qu'est-ce qui pourrait mal tourner ?
Qu'allons-nous faire à ce sujet ?
Avons-nous suffisamment bien agi ?
Bien exécutée, la modélisation des menaces offre une ligne de mire claire sur un projet, justifiant les efforts de sécurité. Elle permet de rationaliser les décisions de sécurité, avec toutes les informations nécessaires à portée de main.
Quelles ressources puis-je utiliser à cette étape ?
Pour s’aider dans l’établissement d’un modèle de menace, l’entreprise peut s’aider d’outils ou de bases de connaissances comme le MITRE ATT&CK (pour “Adversarial Tactics, Techniques and Common Knowledge”).
Il s’agit d’une base de connaissances qui a pour but de documenter diverses techniques utilisées par des attaquants au cours des différentes étapes d’une cyberattaque : enquêter, outiller, déployer, exploiter, contrôler, exécuter et maintenir.
L'OWASP, par ses articles sur la modélisation des menaces et ses cheatsheets (en anglais) fournit des ressources précieuses pour intégrer la sécurité dans la conception architecturale.
De plus, l'OWASP SAMM (Software Assurance Maturity Model) inclut une section sur l'évaluation des menaces (en anglais), offrant un cadre pour évaluer et atténuer les risques dès les premières étapes du projet.
La société américaine CloudFlare propose également un article concernant la modélisation de menace (en français) très intéressant.
Après avoir beaucoup réfléchi, je suis maintenant prêt pour le développement ! Quand est-ce qu’on commence ??!
Vous êtes impatient de pouvoir donner vie à votre application ? Eh bien figurez-vous que c’est la prochaine étape de notre cycle ! Allons-y !
Étape 4 : Implémentation (ou développement)
L’étape de développement est le moment où l'application prend vie, basée sur les fondations posées lors des étapes précédentes de définition des besoins et de conception de l'architecture.
Le développement d'applications sécurisées, en particulier dans un contexte agile, a fait l'objet de nombreuses discussions. L'approche adoptée dépend largement des spécificités de chaque organisation, telles que la culture d'ingénierie, la taille et la compétence des équipes, les outils disponibles et la maturité du programme de sécurité. Il est essentiel de reconnaître que le développement sécurisé ne suit pas un modèle unique mais doit être adapté aux besoins et aux capacités de chaque organisation.
Voyons ensemble par l’exemple ce que peut être une implémentation sécurisée ou non !
Scénario peu mature
Dans un scénario peu mature, l'équipe de développement choisit d'utiliser NodeJS dans sa forme la plus basique pour créer les fonctionnalités demandées. Pour vérifier la connectivité avec les systèmes backend, ils implémentent une requête interne à /healthcheck?remoteHost=<xx.xx.xx>, qui exécute une commande ping vers l'adresse IP spécifiée.
Cette approche rudimentaire ne tient pas compte des pratiques sécurisées de validation de la connectivité et expose potentiellement l'application à des vulnérabilités liées à l'injection de commandes.
Et quel peut-être un bon exemple à suivre alors ?
Par exemple, au lieu d'accepter directement les adresses IP via des paramètres de requête non sécurisés, l'application pourrait utiliser une liste blanche d'adresses IP autorisées ou des expressions régulières pour valider les entrées. Cela minimise les risques d'injection de commande et renforce la sécurité de l'application.
Et plus largement, adopter une approche prudente en matière de développement signifie accorder une attention particulière à tous les aspects de la sécurité, ce que je vous détaille tout de suite dans un scénario mature.
Scénario mature
Dans un environnement de développement mature, l'équipe bénéficie d'une documentation riche et d'une collection de code prêts à l'emploi. Cela accélère le développement tout en assurant la qualité et la sécurité du code.
Avant toute modification sur la branche principale, chaque morceau de code est minutieusement examiné grâce à des revues par les pairs, encouragées par l'utilisation de linters intégrés avant même que le développeur commit. Ces outils vérifient automatiquement le code pour s'assurer qu'il respecte des standards de qualité et de sécurité avant d'être intégré.
Avant de fusionner le code dans la branche principale, des tests préalables sont menés, incluant des tests unitaires, d'acceptation et de régression, pour garantir que les nouvelles fonctionnalités répondent aux exigences sans introduire de régressions ou de vulnérabilités.
Chaque jour, une analyse statique automatique du code est réalisée sur les fonctionnalités récemment ajoutées, et si besoin une équipe de sécurité formée évalue les résultats pour identifier et corriger rapidement les failles potentielles. De plus, des analyses dynamiques régulières sur l'environnement de pré-production aident à repérer les vulnérabilités qui pourraient échapper aux contrôles statiques.
Un linter est un outil qui analyse automatiquement le code source pour détecter les erreurs, les bugs potentiels, et les écarts par rapport aux conventions de codage, aidant ainsi à améliorer la qualité et la sécurité du code.
Qu’est-ce que l’analyse de code statique ou dynamique ?
L'analyse de code statique (SAST - Static Application Security Testing) et l'analyse de code dynamique (DAST - Dynamic Application Security Testing) sont deux méthodes complémentaires utilisées pour identifier les vulnérabilités de sécurité dans les applications.
La SAST examine votre code source sans exécuter le programme, offrant ainsi la possibilité de détecter les failles de sécurité au niveau de l'implémentation avant la compilation et le déploiement. Cette approche, dite de test en boîte blanche, analyse directement votre code pour y repérer des vulnérabilités potentielles, permettant leur correction en amont de la mise en production.
SonarQube est un outil populaire pour l’analyse de la qualité du code et la détection des vulnérabilités dans le code source
À l'inverse, la DAST examine l'application lorsqu'elle est en cours d'exécution, adoptant une méthode de test en boîte noire pour identifier les vulnérabilités qui se manifestent uniquement durant l'exécution du programme. Cette approche simule des attaques automatisées contre votre application pour découvrir des issues que les attaquants pourraient exploiter, sans nécessiter d'accès au code source interne.
Vous vous souvenez de ZAP Proxy dont nous avions parlé rapidement dans la première partie ? Cet outil va vous permettre de trouver des vulnérabilités dans votre application web pendant son exécution !
Quelles ressources puis-je utiliser à cette étape ?
Le modèle SAMM (Software Assurance Maturity Model) notamment dans l'étape implémentation, propose des considérations d'implémentation génériques pour cette étape, soulignant l'importance des linters pour garantir l'ajout de code cohérent.
Avec des intégrations IDE, les ingénieurs logiciels peuvent valider la correction du code en temps réel, et plusieurs linters incluent des règles spécifiques à la sécurité, permettant des vérifications de sécurité de base avant même que le code ne soit commit.
L’utilisation de linters est-elle suffisante pour m’assurer d’avoir une application sécurisée ?
Il est important de noter que les linters ne peuvent pas détecter les vulnérabilités dans les bibliothèques tierces. Avec la montée des attaques via la chaîne d'approvisionnement logiciel (supply chain attacks), surveiller l'utilisation des bibliothèques tierces et auditer leur sécurité devient crucial. Des outils comme Dependency Check et Dependency Track peuvent être utilisés à cette fin.
Pour renforcer la sécurité du code que vous développez en interne, l'OWASP fournit une collection exhaustive de Cheatsheets, montrant comment implémenter des fonctionnalités de manière sécurisée.
En résumé
Lorsque vous créez le plan de votre application, pensez à la sécurité. Utilisez des guides et des outils comme ceux proposés par l'OWASP pour vous aider à éviter les risques dès la conception.
Le modèle de menace peut vous permettre d’identifier les potentiels attaquants et d’ajuster vos défenses.
L'utilisation de l'Analyse Statique d'Application de Sécurité (SAST) durant l’étape d'implémentation permet d'identifier et de résoudre les vulnérabilités de sécurité avant que le code ne soit déployé.
L'Analyse Dynamique d'Application de Sécurité (DAST) joue un rôle complémentaire en détectant les vulnérabilités qui ne se manifestent lorsque l'application est en cours d'exécution.
Dans le chapitre suivant nous allons nous concentrer sur les tests et le déploiement de votre application, qui prend désormais vie !
