Hélène Batard – Responsable Marketing
Le choix de développer sa propre solution logicielle (application lourde, site Internet, embarqué…) est bien souvent un facteur différenciant pour une entreprise. Il lui permet de mettre en valeur sa différence et sa valeur ajoutée.
Pourtant, le développement d’un tel logiciel est avant tout une aventure humaine. Elle va partir d’une idée pour aboutir, dans le meilleur des cas, à un produit. Comme toute aventure, elle possède une part de risques et aujourd’hui le plus important pour un développement logiciel est celui de la sécurité.
Il est important de noter, qu’ici, le mot sécurité, est pris au sens large et pas restreint à une facette de la sécurité logicielle. L’application doit être sécurisée dans sa conception, son développement et son exécution.
L’affaire Solarwinds de 2020 prouve qu’une erreur dans la sécurisation du code source de son application peut conduire à une cyberattaque de premier plan à l’échelle internationale et entacher pour de nombreuses années la réputation d’une entreprise.
Les attaques DDOS régulières par des réseaux de bots d’objets connectés démontrent le besoin de développer de vraies sécurités opérationnelles pour ces objets, mais également de former/forcer les utilisateurs finaux à éviter les comportements à risques (ignorer les mises à jour, ne pas changer les mots de passe par défaut…)
Les fuites de données récentes, comme celles d’une entreprise russe de covoiturage qui a mis en place du stockage externe un peu trop ouvert et qui permettait à tout un chacun de récupérer les documents d’identité des usagers de la plateforme, sont un bon exemple de problèmes de déploiement d’une application et probablement de gestion du passage à l’échelle.
Ces quelques exemples montrent que négliger la sécurité lors de la conception, le développement, le déploiement ou l’utilisation d’une application peut avoir de très lourdes conséquences sur une entreprise, un projet, un produit… les risques encourus vont du déficit d’image, à la faillite de l’entreprise en passant par toutes les problématiques juridiques possibles et imaginables quand on manipule des données sensibles.
Le développement sécurisé, c’est donc deux mots d’ordre : paranoïa et pragmatisme. Cela peut paraitre très antithétique, mais c’est à ce prix qu’une solution sera sécurisée.
Les pratiques DevSecOps (Development Security Operations) consistent en une évolution des pratiques DevOps qui met la sécurité des applications ainsi que des infrastructures au cœur de chaque étape, du développement à la mise en production puis à l’opération.
Cette approche consiste notamment à placer la sécurité comme une pratique essentielle durant les phases de développement, mais aussi dans la mise en place d’outils de vérification automatique du code applicatif avant la mise en production, et enfin d’outils vérifiant la sécurité de l’application en production, mais également des infrastructures ; et ce, quel que soit l’environnement.
L’objectif premier de cette approche est de réduire au maximum la surface d’attaque exposée à de potentiels acteurs malveillants.
Pour accomplir cet objectif premier, cette pratique peut être découpée en plusieurs sous-objectifs, notamment et de façon non-exhaustive :
L’approche DevOps (Development Operations) a ouvert – il y a de nombreuses années – la voie au rapprochement des équipes de Développement (R&D – Recherches et Développements ou équipes produits) et d’Opérations.
Ce rapprochement a permis notamment d’itérer plus rapidement sur une solution et à chacune de ces équipes de comprendre et prendre en compte les problématiques de l’autre.
Ainsi, avec ces pratiques DevOps, le temps avant les mises en production des nouvelles fonctionnalités (features) d’une application ou de nouveaux éléments d’infrastructure ont été considérablement réduits.
Cette approche a notamment introduit et démocratisé de nombreux outils d’automatisation au sein des équipes, permettant notamment de construire ou compiler, de tester et de déployer le tout automatiquement.
Néanmoins, cette approche laissait de côté la sécurité, venant trop souvent contrôler l’application ou l’infrastructure uniquement une fois déployée, et pas à la source, laissant de nombreuses failles potentielles non-visibles par les équipes de sécurité lors de ces tests.
Il était donc essentiel d’introduire la sécurité à toutes les étapes du cycle de vie d’une application ou de son infrastructure en contrôlant la sécurité de façon continue.
Avant le DevOps, il était courant que le développement d’une application soit très long initialement, mais aussi durant son évolution.
De fait, les équipes de Développement et celles d’Opérations communiquaient peu entre elles, se blâmant parfois mutuellement lors des incidents ou des mises en production.
Pour des raisons d’agilité, mais également de l’évolution de la façon d’utiliser les applications et d’avoir des retours d’expérience des utilisateurs, il était nécessaire de pouvoir accélérer le développement des applications et donc la façon de les opérer.
Il était donc crucial de rétablir une communication entre le monde du développement et celui des opérations en créant un pont entre ces équipes, permettant d’itérer et ainsi de faire évoluer plus rapidement les applications et d’améliorer les méthodes d’opération et de surveillance de ces dernières.
Évidemment, les méthodes de gestion de projets ont été amenées à évoluer avec l’arrivée de ces nouvelles pratiques.
Bien que l’utilité d’une équipe de sécurité soit indiscutable, il parait compliqué de faire reposer à cette équipe l’entière responsabilité de la sécurité de toutes les applications d’une entreprise, de la première ligne de code jusqu’aux mises en production.
Il est donc indispensable d’utiliser des outils d’automatisation afin de faciliter chaque étape du cycle de vie de l’application.
Il existe de nombreux outils d’automatisation, certains Open Source, d’autres avec des licences, ici sera présenté seulement le fonctionnement de ces outils.
Parce qu’un code sécurisé est avant tout un code propre, il est nécessaire que chaque développeur ait un outil ou une extension de type “lint” installé dans son éditeur de code (IDE – Integrated Development Environment).
Cet outil permettra notamment de détecter de nombreux problèmes de syntaxe basiques :
Il existe des outils de linting pour presque chaque langage dans tous les IDE. Certains IDE intègrent par défaut ces outils lorsqu’ils sont spécialisés sur un langage en particulier (IntelliJ pour Java avec ESLint par exemple).
La pénurie de talents dans le domaine de la cybersécurité est un défi de plus en plus important pour les entreprises, les gouvernements et les organisations du monde entier. Avec la croissance rapide de la technologie et la dépendance accrue des organisations à l’égard des systèmes informatiques, la demande pour des professionnels qualifiés en cybersécurité ne cesse d’augmenter.
Mais on peut voir dans cette réalité inquiétante des opportunités sur le marché de l’emploi. Les métiers de la cybersécurité étant très recherchés, sont mis sur le devant de la scène. La mise en lumière de ce secteur, a donné naissance à de nouvelles vocations pour les jeunes et même des professionnels qui souhaitent se reconvertir, ou simplement muter vers un nouveau poste.
On retrouvera souvent un linter dans le pipeline en première étape afin de remonter les erreurs aux développeurs si certaines ont pu être oubliées.
Ceci permettra dans certains cas de bloquer l’avancée du pipeline si des erreurs de syntaxes affectant la sécurité sont trouvées.
Cet outil, souvent nommé SAST, est en charge de trouver et faire remonter les vulnérabilités du code source.
Il peut dans certains cas faire remonter des failles de sécurité potentielles telles que :
À noter : chaque outil SAST est adapté à un ou plusieurs langages et permettra pour chaque langage un éventail de détections possible. Référez-vous à la documentation officielle de l’outil choisi pour avoir la liste complète des possibilités.
Ces failles de vulnérabilités sont – dans la plupart des outils – classées selon une criticité : Info, Low, Medium, High, Critical permettant aux équipes de se situer vis-à-vis de la sécurité du code source et des failles à corriger en priorité.
Il existe de nombreux outils SAST adaptés à chaque usage, très peu sur le marché couvrent tous les langages. Il sera donc nécessaire d’utiliser l’outil correspondant à l’usage, par exemple :
Il s’utilise en général juste après une étape de lint et avant toute compilation ou déploiement. Il est supposé couper l’exécution du pipeline en cas de faille trouvée ayant une criticité supérieure ou égale au niveau choisi (par exemple arrêter l’exécution en cas de High ou en cas de Critical).
Le DAST est un outil permettant d’effectuer des tests de sécurité en “boîte opaque”, donc sans connaissance du fonctionnement ou du code source.
Il s’exécute une fois l’application déployée dans un environnement proche de celui de production.
Il permet par exemple, en donnant l’URL[¹] de l’application Web ou bien l’IP et le port du service à tester, de tester les failles les plus communes auxquelles l’application est sensible, par exemple les 10 catégories d’attaques représentant le plus de risque de sécurité selon l’OWASP[²].
Les tests effectués par un outil DAST permettent ensuite d’avoir un rapport détaillé de toutes les failles détectées et classées selon leur criticité, en général : Info, Low, Medium, High, Critical
[¹] URL : Uniform Resource Locator, l’adresse http ou https d’un site internet
[²] OWASP : Open Web Application Security Project, une organisation caritative travaillant en communauté afin d’améliorer la sécurité des applications Web
Le IAST représente les outils capables de combiner les capacités d’un SAST et d’un DAST afin d’analyser d’un côté le code source et de l’autre, l’application, une fois déployée et de pouvoir établir des corrélations et des suggestions entre les deux.
Cette méthode, nommée IaC, consiste à utiliser un outil permettant le déploiement d’élément de l’infrastructure écrit sous la forme descriptive à l’aide d’un langage.
Bien que cet outil ne soit pas obligatoire à la mise en place des pratiques DevSecOps, ce dernier permet, lorsqu’il est utilisé, de les mettre en place depuis le code source au déploiement de l’infrastructure.
On pourra notamment utiliser un outil de SAST dédié permettant de faire remonter des problèmes de sécurité par exemple :
On citera notamment Terraform et Pulumi qui permettent le déploiement sur plusieurs Cloud Provider tels qu’AWS, Azure, GCP, etc.
Les outils précédemment abordés dans cette leçon doivent être exécutés de façon séquentielle et automatiquement lorsqu’une nouvelle version du code source est envoyée sur le dépôt git.
Cette pratique d’automatisation prend place au sein d’une chaîne d’intégration et de déploiement continus nommé couramment une chaîne CI/CD (Continuous Integration/Continuous Deployment).
Le pipeline CI/CD est un outil qui, à l’aide d’un fichier descriptif, va exécuter des étapes séquentielles dans un environnement temporaire de développement permettant par exemple de :
Plusieurs pipelines peuvent s’enchaîner et dans le cas ci-dessus, le suivant pourrait être en charge de déployer l’application dans un environnement de démo ou de QA (Quality Assurance – Contrôle qualité) afin de tester de façon manuelle et humaine l’application avant sa mise en production.
Il est également possible dans la plupart des outils de pipeline de mettre en “pause” des exécutions ou d’attendre une intervention humaine. Par exemple, une fois l’étape de contrôle qualité humaine réalisée, une pipeline finale pourrait attendre une approbation d’un chef de projet afin de lancer la mise en production automatique de l’application.
On retrouvera souvent un linter dans le pipeline en première étape afin de remonter les erreurs aux développeurs si certaines ont pu être oubliées.
Ceci permettra dans certains cas de bloquer l’avancée du pipeline si des erreurs de syntaxes affectant la sécurité sont trouvées.
Cet outil, souvent nommé SAST, est en charge de trouver et faire remonter les vulnérabilités du code source.
Il peut dans certains cas faire remonter des failles de sécurité potentielles telles que :
Non-validation des paramètres d’entrée (saisies des utilisateurs ou variables passées entre les fonctions)
Permissions accordées trop larges
Ouverture des accès au réseau trop larges
Sensibilité aux attaques les plus communes (Injection SQL, XSS etc.)
À noter : chaque outil SAST est adapté à un ou plusieurs langages et permettra pour chaque langage un éventail de détections possible. Référez-vous à la documentation officielle de l’outil choisi pour avoir la liste complète des possibilités.
Ces failles de vulnérabilités sont – dans la plupart des outils – classées selon une criticité : Info, Low, Medium, High, Critical permettant aux équipes de se situer vis-à-vis de la sécurité du code source et des failles à corriger en priorité.
Il existe de nombreux outils SAST adaptés à chaque usage, très peu sur le marché couvrent tous les langages. Il sera donc nécessaire d’utiliser l’outil correspondant à l’usage, par exemple :
Il s’utilise en général juste après une étape de lint et avant toute compilation ou déploiement. Il est supposé couper l’exécution du pipeline en cas de faille trouvée ayant une criticité supérieure ou égale au niveau choisi (par exemple arrêter l’exécution en cas de High ou en cas de Critical).
Le DAST est un outil permettant d’effectuer des tests de sécurité en “boîte opaque”, donc sans connaissance du fonctionnement ou du code source.
Il s’exécute une fois l’application déployée dans un environnement proche de celui de production.
Il permet par exemple, en donnant l’URL[¹] de l’application Web ou bien l’IP et le port du service à tester, de tester les failles les plus communes auxquelles l’application est sensible, par exemple les 10 catégories d’attaques représentant le plus de risque de sécurité selon l’OWASP[²].
Les tests effectués par un outil DAST permettent ensuite d’avoir un rapport détaillé de toutes les failles détectées et classées selon leur criticité, en général : Info, Low, Medium, High, Critical
[¹] URL : Uniform Resource Locator, l’adresse http ou https d’un site internet
[²] OWASP : Open Web Application Security Project, une organisation caritative travaillant en communauté afin d’améliorer la sécurité des applications Web
Le IAST représente les outils capables de combiner les capacités d’un SAST et d’un DAST afin d’analyser d’un côté le code source et de l’autre, l’application, une fois déployée et de pouvoir établir des corrélations et des suggestions entre les deux.
Cette méthode, nommée IaC, consiste à utiliser un outil permettant le déploiement d’élément de l’infrastructure écrit sous la forme descriptive à l’aide d’un langage.
Bien que cet outil ne soit pas obligatoire à la mise en place des pratiques DevSecOps, ce dernier permet, lorsqu’il est utilisé, de les mettre en place depuis le code source au déploiement de l’infrastructure.
On pourra notamment utiliser un outil de SAST dédié permettant de faire remonter des problèmes de sécurité par exemple :
On citera notamment Terraform et Pulumi qui permettent le déploiement sur plusieurs Cloud Provider tels qu’AWS, Azure, GCP, etc.
Les outils précédemment abordés dans cette leçon doivent être exécutés de façon séquentielle et automatiquement lorsqu’une nouvelle version du code source est envoyée sur le dépôt git.
Cette pratique d’automatisation prend place au sein d’une chaîne d’intégration et de déploiement continus nommé couramment une chaîne CI/CD (Continuous Integration/Continuous Deployment).
Le pipeline CI/CD est un outil qui, à l’aide d’un fichier descriptif, va exécuter des étapes séquentielles dans un environnement temporaire de développement permettant par exemple de :
Plusieurs pipelines peuvent s’enchaîner et dans le cas ci-dessus, le suivant pourrait être en charge de déployer l’application dans un environnement de démo ou de QA (Quality Assurance – Contrôle qualité) afin de tester de façon manuelle et humaine l’application avant sa mise en production.
Il est également possible dans la plupart des outils de pipeline de mettre en “pause” des exécutions ou d’attendre une intervention humaine. Par exemple, une fois l’étape de contrôle qualité humaine réalisée, une pipeline finale pourrait attendre une approbation d’un chef de projet afin de lancer la mise en production automatique de l’application.
Formez vos équipes !
Formation
Carrière
Cybersécurité
100% en ligne
Discutons ensemble de votre projet
La certification qualité a été délivrée au titre de la catégorie
« ACTIONS FORMATION »
© Seela – 24/11/2022
Organisme de formation
N°11755030075
Cet enregistrement ne vaut pas agrément de l’Etat.
Le certificat Qualiopi est disponible sur ce lien
A propos
Ressources
Le groupe
Une question ?
information@seela.io
Si vous avez des besoins d’adaptation en lien avec un handicap, contactez notre mission handicap à l’adresse suivante : inclusion@seela.io
