La peur et la haine de DevSecOps

Nous avions 2 analyseurs de code, 4 outils de test dynamique, nos propres créations et 250 scripts. Ce n'est pas que tout cela était nécessaire dans le processus actuel, mais comme j'ai commencé à intégrer le DevSecOps, il fallait aller jusqu'au bout.

Source. Les créateurs des personnages : Justin Roiland et Dan Harmon.

Qu'est-ce que SecDevOps ? Et DevSecOps ? Quelle est la différence ? La sécurité des applications - de quoi s'agit-il ? Pourquoi l'approche classique ne fonctionne-t-elle plus ? Toutes ces questions ont des réponses. Youri Chabaly de Swordfish Security. Youri répondra à toutes ces questions et analysera les problèmes de transition du modèle classique de la sécurité des applications vers le processus DevSecOps : comment bien intégrer le processus de développement sécurisé dans le processus DevOps sans rien casser, comment passer par les principales étapes de test de sécurité, quels outils peuvent être utilisés, en quoi ils diffèrent et comment les configurer correctement pour éviter les pièges.

À propos de l'intervenant : Youri Chabaly - Chief Security Architect dans l'entreprise Swordfish Security. Il est responsable de l'implémentation du SSDL, de l'intégration générale des outils d'analyse d'applications dans un écosystème unifié de développement et de test. 7 ans d'expérience en sécurité informatique. A travaillé chez Alfa-Bank, Sberbank et Positive Technologies, qui développe des logiciels et fournit des services. Intervenant lors de conférences internationales telles que ZerONights, PHDays, RISSPA, OWASP.

Sécurité des applications : de quoi s'agit-il ?

Sécurité des applications — est un domaine de la sécurité qui est responsable de la sécurité des applications. Cela ne concerne pas l'infrastructure ou la sécurité du réseau, mais spécifiquement ce que nous écrivons et sur quoi travaillent les développeurs — il s'agit des défauts et des vulnérabilités de l'application elle-même.

Direction SDL ou SDLC — Cycle de vie de développement de la sécurité — a été développé par Microsoft. Sur le schéma se trouve le modèle canonique SDLC, dont l'objectif principal est d'impliquer la sécurité à chaque étape du développement, des exigences jusqu'à la sortie en production. Microsoft a réalisé qu'il y avait trop de bogues dans le produit, que leur nombre augmentait et qu'il fallait faire quelque chose à ce sujet, et a proposé cette approche, qui est devenue canonique.

La sécurité des applications et le SSDL ne visent pas à détecter les vulnérabilités, comme on le pense souvent, mais à prévenir leur apparition. Au fil du temps, l'approche canonique de Microsoft a été améliorée et développée, offrant une immersion plus profonde et détaillée.

Le SDLC canonique est fortement détaillé dans différentes méthodologies - OpenSAMM, BSIMM, OWASP. Les méthodologies diffèrent, mais dans l'ensemble, elles se ressemblent.

Modèle de Maturité pour la Sécurité Intégrée

Ce qui me convient le mieux BSIMM — Modèle de Maturité pour la Sécurité Intégrée. La base de la méthodologie consiste à diviser le processus de sécurité des applications en 4 domaines : Gouvernance, Intelligence, Points de Contact SSDL et Déploiement. Dans chaque domaine, il y a 12 pratiques, représentées sous forme de 112 activités.

Chacune des 112 activités a 3 niveaux de maturité: débutant, intermédiaire et avancé. Les 12 pratiques peuvent être étudiées par sections, en sélectionnant les éléments importants pour vous, en apprenant comment les intégrer et en ajoutant progressivement des éléments, tels que l'analyse statique et dynamique du code ou la revue de code. Vous élaborez un plan et travaillez tranquillement dans le cadre de l'implémentation des activités choisies.

Pourquoi DevSecOps

DevOps est un grand processus global, dans lequel il est nécessaire de se soucier de la sécurité.

À l'origine DevOps de prévisions de sécurité. En pratique, le nombre d'équipes de sécurité était beaucoup plus faible qu'aujourd'hui, et elles intervenaient non pas en tant que participants au processus, mais comme un organe de contrôle et de supervision, qui impose des exigences et vérifie la qualité du produit à la fin de la sortie. C'est l'approche classique, où les équipes de sécurité étaient séparées du développement et n'intervenaient pas dans le processus.

Le problème principal est que la cybersécurité est séparée du développement. Cela prend généralement la forme d'un certain cadre de cybersécurité comprenant 2-3 grands et coûteux outils. Une fois tous les six mois, le code source ou l'application à vérifier arrive, et une fois par an des tests de pénétration. Tout cela conduit à des retards dans le passage à la production, et un grand nombre de vulnérabilités issues des outils automatisés s'accumulent sur les développeurs. Il est impossible de tout déchiffrer et de corriger, car les résultats des six mois précédents n'ont même pas été analysés, et une nouvelle série arrive.

Dans le cadre de notre travail, nous constations que la sécurité dans tous les secteurs et industries reconnaît qu'il est temps de s'adapter et de s'aligner sur le développement dans un même cycle - dans l' Agile. La paradigme DevSecOps s'intègre parfaitement à la méthodologie de développement agile, à l'implémentation, au soutien et à la participation à chaque version et itération.

La transition vers DevSecOps

Le mot le plus important dans le cycle de vie du développement sécurisé est « processus ». Vous devez comprendre cela avant de penser à acheter des outils.

Il ne suffit pas d'intégrer des outils dans le processus DevOps — l'interaction et la compréhension entre les participants au processus sont cruciales.

Les gens sont plus importants que les outils

Souvent, la planification d'un processus de développement sécurisé commence par le choix et l'achat d'un outil, puis se termine par des tentatives d'intégration de l'outil dans le processus existant, qui n'aboutissent souvent qu'à des échecs. Cela conduit à des conséquences malheureuses, car chaque outil a ses spécificités et limitations.

Un cas fréquent est celui où le département de sécurité choisit un bon outil coûteux avec de grandes capacités et vient voir les développeurs pour l'incorporer dans le processus. Mais cela ne fonctionne pas — le processus est construit de manière à ce que les limitations de l'outil déjà acheté ne s'intègrent pas dans la paradigme actuel.

Commencez par décrire quel résultat vous voulez et à quoi ressemblera le processus. Cela aidera à comprendre le rôle de l'outil et de la sécurité dans le processus.

Commencez par ce qui est déjà utilisé

Avant d'acheter des outils coûteux, regardez ce que vous avez déjà. Chaque entreprise a des exigences de sécurité qui s'appliquent au développement, il y a des vérifications, des pentests — pourquoi ne pas transformer tout cela en une forme compréhensible et utile pour tous ?

En général, les exigences sont un long document qui traîne sur une étagère. Il y a eu un cas où nous sommes allés dans une entreprise pour examiner les processus et avons demandé à voir les exigences de sécurité pour le logiciel. Le spécialiste responsable a cherché longtemps :

— Maintenant, je sais qu'il y a quelque part dans mes notes le chemin vers ce document.

Au final, nous avons obtenu le document après une semaine.

Pour les exigences, les vérifications et autres, créez une page, par exemple sur Confluence — c'est pratique pour tout le monde.

Il est plus facile de reformater ce qui existe déjà et de l'utiliser comme point de départ.

Utilisez des Security Champions

En général, dans une entreprise moyenne, pour 100-200 développeurs, il y a un spécialiste de la sécurité qui remplit plusieurs fonctions et qui ne peut physiquement pas tout vérifier. Même s'il fait de son mieux — il ne peut pas inspecter tout le code généré par le développement tout seul. Pour de tels cas, le concept de Security Champions.

Les Champions de la Sécurité sont des personnes au sein de l'équipe de développement qui se soucient de la sécurité de votre produit.

Le Champion de la Sécurité est un point d'entrée dans l'équipe de développement et un évangéliste de la sécurité en une seule personne.

En général, lorsque quelqu'un de l'équipe de développement vient avec un expert en sécurité et signale une erreur dans le code, il reçoit une réponse étonnée :

— Et vous êtes qui ? Je vous vois pour la première fois. Tout va bien pour moi — mon senior a validé lors de la revue de code, nous continuons !

C'est une situation typique, car il y a beaucoup plus de confiance envers les seniors ou simplement les collègues avec qui le développeur interagit constamment au travail et lors des revues de code. Si c'est un Champion de la Sécurité qui indique une erreur et ses conséquences, sa parole aura plus de poids.

Les développeurs connaissent également mieux leur code qu'un expert en sécurité. Pour une personne ayant au minimum 5 projets dans un outil d'analyse statique, il est généralement difficile de se souvenir de toutes les nuances. Les Champions de la Sécurité connaissent leur produit : ce qui interagit avec quoi et quoi surveiller en premier — ils sont plus efficaces.

Réfléchissez donc à la possibilité d'implémenter des Champions de la Sécurité pour élargir l'influence de l'équipe de sécurité. Pour le champion lui-même, c'est également bénéfique : développement professionnel dans un nouveau domaine, élargissement des connaissances techniques, amélioration des compétences techniques, managériales et de leadership, augmentation de la valeur sur le marché. C'est un élément de l'ingénierie sociale, vos « yeux » dans l'équipe de développement.

Étapes de test

La règle des 20 sur 80 stipule que 20 % des efforts génèrent 80 % des résultats. Ces 20 % concernent les pratiques d'analyse des applications qui peuvent et doivent être automatisées. Des exemples de telles activités sont l'analyse statique — SAST, l'analyse dynamique — DAST, et le contrôle Open Source. Je vais expliquer plus en détail les activités, ainsi que les outils, et les spécificités auxquelles nous faisons généralement face lors de leur intégration dans le processus, et comment le faire correctement.

Problèmes principaux des outils

Je vais mettre en évidence les problèmes pertinents pour tous les outils qui nécessitent une attention particulière. Je vais les examiner plus en détail pour ne pas avoir à me répéter.

Longue durée d'analyse. Si le temps écoulé entre le commit et le passage en production est de 30 minutes pour tous les tests et la compilation, alors les vérifications de sécurité prendront une journée. Personne ne fera traîner le processus. Prenez en compte cette spécificité et tirez-en des conclusions.

Niveau élevé de faux négatifs ou de faux positifs. Tous les produits sont différents, chaque équipe utilise différents frameworks et son propre style de codage. Sur différentes bases de code et technologies, les outils peuvent montrer un niveau varié de faux négatifs et de faux positifs. Donc, regardez ce qui est pertinent dans votre entreprise et pour vos applications qui montrera un bon et fiable résultat.

Pas d'intégrations avec les outils existants. Examinez les outils en fonction des intégrations avec ce que vous utilisez déjà. Par exemple, si vous utilisez Jenkins ou TeamCity, vérifiez l'intégration des outils précisément avec ce logiciel, et non avec GitLab CI que vous n'utilisez pas.

Absence ou complexité excessive de personnalisation. Si un outil n'a pas d'API, à quoi bon ? Tout ce qui peut être fait dans l'interface doit être accessible via l'API. Idéalement, l'outil devrait permettre de personnaliser les vérifications.

Pas de feuille de route pour le développement du produit. Le développement ne stagne pas, nous utilisons toujours de nouveaux frameworks et fonctionnalités, et réécrivons l'ancien code dans de nouveaux langages. Nous voulons être sûrs que l'outil que nous achèterons supportera de nouveaux frameworks et technologies. Il est donc important de savoir que le produit a une véritable et correcte feuille de route de développement.

Particularités du processus

En plus des particularités des outils, prenez également en compte les spécificités du processus de développement. Par exemple, gêner le développement est une erreur classique. Voyons quelles autres particularités doivent être prises en compte et sur quoi l'équipe de sécurité doit se concentrer.

Pour ne pas retarder les délais de développement et de mise en production, créez différentes règles et différents show stoppers — des critères d'arrêt du processus de compilation en cas de vulnérabilités — pour différents environnements. Par exemple, nous comprenons que la branche actuelle est destinée à un environnement de développement ou UAT, donc nous ne devons pas arrêter et ne pas dire :

— Vous avez ici des vulnérabilités, vous n'irez nulle part !

À ce stade, il est important d'informer les développeurs qu'il existe des problèmes de sécurité auxquels il convient de prêter attention.

La présence de vulnérabilités n'est pas un obstacle à des tests ultérieurs.: manuel, intégration ou manuel. D'un autre côté, nous devons somehow améliorer la sécurité du produit, et pour que les développeurs ne négligent pas ce que la sécurité trouve. C'est pourquoi parfois nous procédons ainsi : sur le stand, lorsque cela est publié dans l'environnement de développement, nous informons simplement le développement :

— Les gars, vous avez des problèmes, veuillez y prêter attention.

À l'étape UAT, nous montrons à nouveau les avertissements sur les vulnérabilités, et à l'étape de lancement, nous disons :

— Les gars, nous avons averti plusieurs fois, vous n'avez rien fait — nous ne vous laisserons pas sortir avec ça.

En parlant de code et de dynamique, il faut montrer et avertir uniquement au sujet des vulnérabilités des fonctionnalités et du code qui viennent d'être écrits dans cette fonctionnalité. Si le développeur a déplacé un bouton de 3 pixels et que nous lui disons qu'il a une injection SQL et qu'il doit donc corriger cela immédiatement — c'est incorrect. Regardez uniquement ce qui a été écrit maintenant, et le changement qui arrive dans l'application.

Supposons que nous ayons un certain défaut fonctionnel — comment l'application ne doit pas fonctionner : l'argent n'est pas transféré, en cliquant sur le bouton, il n'y a pas de redirection vers la page suivante ou le produit ne se charge pas. Les défauts de sécurité — ce sont des défauts similaires, mais non pas dans le cadre du fonctionnement de l'application, mais de la sécurité.

Tous les problèmes de qualité logicielle ne sont pas des problèmes de sécurité. Mais tous les problèmes de sécurité sont liés à la qualité du logiciel. Sherif Mansour, Expedia.

Étant donné que toutes les vulnérabilités sont des défauts similaires, elles doivent se trouver là où se trouvent tous les défauts de développement. Donc oubliez les rapports et les PDF effrayants que personne ne lit.

Quand je travaillais dans une entreprise de développement, j'ai reçu un rapport d'outils d'analyse statique. Je l'ai ouvert, j'ai été horrifié, j'ai préparé un café, j'ai feuilleté 350 pages, je l'ai fermé et je suis retourné travailler. Les grands rapports sont des rapports morts. Ils ne vont généralement nulle part, les emails sont supprimés, oubliés, perdus ou les affaires disent qu'elles acceptent les risques.

Que faire ? Les défauts confirmés que nous avons trouvés sont simplement transformés en un format adapté au développement, par exemple en les rassemblant dans le backlog de Jira. Nous priorisons et corrigeons les défauts selon leur priorité, en parallèle avec les défauts fonctionnels et ceux des tests.

Analyse statique - SAST

Il s'agit d'une analyse du code à la recherche de vulnérabilités., mais ce n'est pas la même chose que SonarQube. Nous vérifions non seulement selon des motifs ou un style. Lors de l'analyse, plusieurs approches sont appliquées : selon l'arbre des vulnérabilités, par DataFlow, par l'analyse des fichiers de configuration. C'est tout ce qui concerne directement le code.

Avantages de l'approche: détection des vulnérabilités dans le code à un stade précoce du développement, lorsqu'il n'y a pas encore de stands et d'outils prêts, et possibilité de scan incrémental: scanner la partie du code qui a changé et uniquement la fonctionnalité sur laquelle nous travaillons actuellement, ce qui réduit le temps de scan.

Inconvénients — c'est l'absence de support pour les langages nécessaires.

Intégrations nécessaires, qui, à mon avis subjectif, doivent être dans les outils :

• Outils d'intégration : Jenkins, TeamCity et Gitlab CI.
• Environnement de développement : Intellij IDEA, Visual Studio. Il est plus pratique pour le développeur de ne pas fouiller dans une interface incompréhensible qu'il doit encore mémoriser, mais de voir directement sur son lieu de travail, dans son propre environnement de développement, toutes les intégrations nécessaires et les vulnérabilités qu'il a trouvées.
• Revue de code : SonarQube et revue manuelle.
• Suivi des défauts : Jira et Bugzilla.

Sur l'image, quelques-uns des meilleurs représentants de l'analyse statique.

Ce ne sont pas les outils qui comptent, mais le processus, c'est pourquoi il existe des solutions Open Source qui sont également très bonnes pour tester le processus.

Les SAST Open Source ne trouveront pas un nombre énorme de vulnérabilités ou des DataFlow complexes, mais lors de la construction du processus, ils peuvent et doivent être utilisés. Ils aident à comprendre comment le processus sera établi, qui sera responsable des bugs, qui signalera, qui rendra compte. Si vous souhaitez réaliser la première étape dans l'établissement de la sécurité de votre code, utilisez des solutions Open Source.

Comment l'intégrer si vous êtes au début du chemin, que vous n'avez rien : ni CI, ni Jenkins, ni TeamCity ? Examinons les intégrations dans le processus.

Intégration au niveau du CVS

Si vous avez Bitbucket ou GitLab, vous pouvez faire une intégration au niveau Concurrent Versions System.

Sur événement — pull request, commit. Vous scannez le code et dans le statut de construction, vous montrez si le contrôle de sécurité a réussi ou échoué.

Retour d'information. Il est essentiel d'avoir toujours un retour d'information. Si vous avez simplement exécuté quelque chose du côté de la sécurité, que vous l'avez rangé dans une boîte sans en parler à personne, et que vous déversez une multitude de bogues à la fin du mois, ce n'est ni correct ni bon.

Intégration avec le système de révision de code

Un jour, nous avons défini comme réviseur par défaut sur des projets importants un utilisateur technique d'AppSec. Selon que des erreurs sont détectées dans le nouveau code ou non, le réviseur du pull request attribut un statut 'accept' ou 'need work' — soit tout va bien, soit des améliorations sont nécessaires avec des liens indiquant ce qu'il faut précisément améliorer. Pour l'intégration avec la version mise en production, nous avons activé l'interdiction de fusion si le test de sécurité n'a pas été réussi. Nous avons inclus cela dans la révision de code manuelle, et les autres participants au processus pouvaient voir les statuts de sécurité pour ce processus particulier.

Intégration avec SonarQube

Beaucoup en ont quality gate pour la qualité du code. Ici, c'est pareil — on peut établir les mêmes gates uniquement pour les outils SAST. Il y aura la même interface, le même quality gate, mais cela s'appellera security gate. Et de plus, si vous avez un processus utilisant SonarQube, tout peut être intégré sans problèmes.

Intégration au niveau CI

C'est assez simple ici:

• Au même niveau que les autotests, les tests unitaires.
• Séparation par étapes de développement: dev, test, prod. Différents ensembles de règles peuvent être activés, ou différentes conditions d'échec: nous arrêtons la construction, nous ne l'arrêtons pas.
• Lancement synchrone/asynchrone. Nous attendons que les tests de sécurité soient terminés ou non. C'est-à-dire que nous les avons simplement lancés et continuons, puis nous recevons le statut que tout va bien ou mal.

Tout cela dans un monde idéal. Dans la vie réelle, cela n'existe pas, mais nous aspirons à cela. Le résultat des contrôles de sécurité doit être similaire aux résultats des tests unitaires.

Par exemple, nous avons pris un grand projet et décidé que désormais nous allons le scanner avec SAST — OK. Nous avons chargé ce projet dans SAST, il nous a fourni 20 000 vulnérabilités et par une décision volontaire, nous avons accepté que tout soit en ordre. 20 000 vulnérabilités représentent notre dette technique. Nous allons ranger cette dette dans une boîte, et nous allons progressivement la résoudre et ouvrir des tickets dans les traqueurs de défauts. Nous allons engager une entreprise, tout faire nous-mêmes ou nous faire aider par des Security Champions — et notre dette technique va diminuer.

Quant à toutes les vulnérabilités nouvellement apparues dans le nouveau code, elles doivent être corrigées comme les erreurs dans les tests unitaires ou les tests automatisés. Pour le dire autrement, la compilation se lance, des tests passent et deux tests de sécurité échouent. OK — nous avons regardé ce qui s'est passé, corrigé le premier, corrigé le second, la prochaine fois tout fonctionne — pas de nouvelles vulnérabilités et les tests ne sont pas échoués. Si cette tâche est plus complexe et nécessite une bonne compréhension, ou si le correctif des vulnérabilités concerne des couches importantes du système : un ticket est ouvert dans le traqueur de défauts, il est priorisé et corrigé. Malheureusement, le monde n'est pas parfait et les tests échouent parfois.

Exemple de sécurité gate — analogue de quality gate, en fonction de la présence et du nombre de vulnérabilités dans le code.

Intégration avec SonarQube — le plugin est installé, tout est très pratique et excellent.

Intégration avec l'environnement de développement

Fonctionnalités d'intégration :

• Lancement du scan depuis l'environnement de développement avant le commit.
• Consultation des résultats.
• Analyse des résultats.
• Synchronisation avec le serveur.

Voici à quoi ressemble l'obtention des résultats depuis le serveur.

Dans notre environnement de développement Intellij IDEA apparaît simplement un point supplémentaire, qui informe que des vulnérabilités ont été détectées lors du scan. On peut corriger le code immédiatement, voir les recommandations et Flow Graph. Tout cela est situé sur le poste de travail du développeur, c'est très pratique — pas besoin d'aller sur d'autres liens et de chercher des éléments supplémentaires.

Open Source

C'est mon sujet préféré. Tout le monde utilise des bibliothèques open source — pourquoi écrire une multitude de solutions de contournement et de vélos, quand on peut utiliser une bibliothèque prête, dans laquelle tout est déjà implémenté ?

Bien sûr, c'est vrai, mais les bibliothèques sont également écrites par des personnes, elles comportent aussi des risques et présentent des vulnérabilités dont on parle régulièrement, ou constamment. C'est pourquoi il y a une étape suivante dans la sécurité des applications : l'analyse des composants Open Source.

Analyse Open Source – OSA

L'outil comprend trois grandes étapes.

Recherche de vulnérabilités dans les bibliothèques. Par exemple, l'outil sait que nous utilisons une certaine bibliothèque, et que dans CVE ou dans les bug trackers, il existe des vulnérabilités liées à cette version de la bibliothèque. Lors de son utilisation, l'outil signalera que la bibliothèque est vulnérable et conseillera d'utiliser une autre version sans vulnérabilités.

Analyse de la conformité des licences. Pour l'instant, ce n'est pas très populaire chez nous, mais si vous travaillez avec l'étranger, vous pouvez parfois rencontrer des problèmes pour avoir utilisé un composant Open Source qui ne peut pas être utilisé ou modifié. Selon la politique de la bibliothèque sous licence, nous ne pouvons pas faire cela. Ou, si nous l'avons modifié et l'utilisons, nous devons rendre notre code public. Bien sûr, personne ne veut publier le code de ses produits, mais il existe des moyens de se protéger contre cela.

Analyse des composants utilisés dans l'environnement industriel. Imaginons une situation hypothétique où nous avons enfin terminé le développement et sorti la dernière version de notre microservice en production. Il fonctionne parfaitement – une semaine, un mois, un an. Nous ne le mettons pas à jour, nous ne faisons pas de vérifications de sécurité, tout semble bien. Mais soudain, deux semaines après la sortie, une vulnérabilité critique est découverte dans le composant Open Source que nous utilisons dans cette version, en production. Si nous ne notons pas ce que nous utilisons et où, nous ne verrons tout simplement pas cette vulnérabilité. Certains outils offrent une possibilité de surveillance des vulnérabilités dans les bibliothèques actuellement utilisées en production. C'est très utile.

Fonctionnalités :

• Différentes politiques pour différentes étapes de développement.
• Surveillance des composants dans l'environnement industriel.
• Contrôle des bibliothèques au sein de l'organisation.
• Prise en charge de divers systèmes de construction et langues.
• Analyse des images Docker.

Quelques exemples de leaders dans le domaine qui s'occupent de l'analyse Open Source.

Le seul gratuit parmi eux est Vérification de dépendances d'OWASP. Il peut être intégré dès les premières étapes pour voir comment il fonctionne et ce qu'il prend en charge. Cela concerne principalement tous les produits cloud, ou sur site, mais pour leur base, ils doivent quand même envoyer des informations sur Internet. Ils n'envoient pas vos bibliothèques, mais des hachages ou leurs propres valeurs calculées, ainsi que des empreintes vers leur serveur pour obtenir des nouvelles sur les vulnérabilités.

Intégration dans le processus

Contrôle des bibliothèques dans le périmètre, qui sont téléchargées depuis des sources externes. Nous avons des dépôts externes et internes. Par exemple, notre instance Event Central utilise Nexus, et nous souhaitons qu'il n'y ait pas de vulnérabilités de statut « critique » ou « élevé » dans notre dépôt interne. Il est possible de configurer le proxy à l'aide de l'outil Nexus Firewall Lifecycle pour que ces vulnérabilités soient bloquées et ne pénètrent pas dans le dépôt interne.

Intégration dans le CI. Sur un même niveau que les tests automatisés, les tests unitaires et la séparation par étapes de développement : dev, test, prod. À chaque étape, il est possible de télécharger n'importe quelle bibliothèque, d'utiliser ce que l'on veut, mais s'il y a quelque chose de sérieux avec un statut « critique », il pourrait être judicieux d'attirer l'attention des développeurs à l'étape de la mise en production.

Intégration avec les artefacts: Nexus et JFrog.

Intégration dans l'environnement de développement. Les outils que vous choisissez doivent s'intégrer aux environnements de développement. Les développeurs doivent pouvoir accéder aux résultats de l'analyse depuis leur poste de travail ou avoir la possibilité de scanner et vérifier le code pour détecter les vulnérabilités avant de le valider dans le CVS.

Intégration dans le CD. C'est une fonctionnalité géniale que j'apprécie beaucoup et dont j'ai déjà parlé : la surveillance de l'apparition de nouvelles vulnérabilités dans l'environnement de production. Cela fonctionne plus ou moins comme ça.

Nous avons des Dépôts de composants publics — certains outils externes et notre dépôt interne. Nous souhaitons qu'il ne contienne que des composants fiables. Lors du proxy des requêtes, nous vérifions que la bibliothèque téléchargée ne présente pas de vulnérabilités. Si elle est soumise à certaines politiques que nous établissons et que nous validons avec le développement, elle n’est pas téléchargée et un message indique d'utiliser une autre version. Par conséquent, si la bibliothèque contient quelque chose de réellement critique et de mauvais, le développeur ne recevra pas la bibliothèque lors de l'installation — il devra utiliser une version antérieure ou ultérieure.

• Lors de la construction, nous vérifions que personne n'a injecté quoi que ce soit de mauvais, que tous les composants sont sûrs et que personne n'a apporté sur une clé USB quoi que ce soit de dangereux.
• Dans notre dépôt, nous n'avons que des composants fiables.
• Lors du déploiement, nous vérifions encore une fois le paquet lui-même : war, jar, DL ou image Docker, pour nous assurer qu'il respecte la politique.
• Lors de la mise en production, nous surveillons ce qui se passe dans l'environnement industriel : des vulnérabilités critiques apparaissent-elles ou non.

Analyse dynamique — DAST

Les outils d'analyse dynamique diffèrent radicalement de tout ce qui a été évoqué auparavant. C'est une sorte de simulation du travail d'un utilisateur avec l'application. S'il s'agit d'une application web, nous envoyons des requêtes en imitant le travail du client, nous cliquons sur les boutons en front-end, nous envoyons des données artificielles à partir de formulaires : guillemets, parenthèses, caractères dans différents encodages, afin d'observer comment l'application fonctionne et traite les données externes.

Ce même système permet de vérifier les vulnérabilités modèles dans les logiciels open source. Étant donné que le DAST ne sait pas quel open source nous utilisons, il envoie simplement des modèles « malveillants » et analyse les réponses du serveur :

— Aha, il y a un problème de désérialisation ici, et ici il n'y en a pas.

Il y a de grands risques, car si vous effectuez ce test de sécurité sur le même environnement que celui utilisé par les testeurs, des problèmes désagréables peuvent survenir.

• Charge élevée sur le serveur d'application réseau.
• Pas d'intégrations.
• Possibilité de modifier les paramètres de l'application analysée.
• Pas de support pour les technologies nécessaires.
• Complexité de la configuration.

Nous avons eu une situation où nous avons finalement lancé AppScan : il a fallu longtemps pour obtenir l'accès à l'application, obtenir 3 comptes et nous étions contents - enfin nous pourrions tout vérifier ! Nous avons lancé le scan, et la première chose qu'AppScan a faite - il est allé dans le panneau d'administration, a cliqué sur tous les boutons, a changé la moitié des données, et ensuite il a carrément tué le serveur avec ses mailform-requêtes. Le développement avec les tests a dit :

— Les gars, vous rigolez ?! Nous vous avons donné des comptes, et vous avez mis le stand hors service !

Prenez en compte les risques potentiels. Idéalement, préparez un stand séparé pour tester la sécurité informatique, qui sera isolé de l'environnement pour au moins un certain temps, et il est préférable de vérifier l'admin manuellement. C'est un pentest - ces quelques pourcents d'efforts que nous ne prenons pas en compte maintenant.

Il vaut la peine de considérer que cela peut être utilisé comme une analogie aux tests de charge. À la première étape, vous pouvez activer un scanner dynamique avec 10-15 flux et voir ce que cela donne, mais généralement, comme le montre la pratique, rien de bon.

Quelques ressources que nous utilisons habituellement.

Il convient de souligner Burp Suite — c'est le « couteau suisse » pour tout spécialiste de la sécurité. Tout le monde l'utilise, et il est très pratique. Une nouvelle version démo de l'édition entreprise est maintenant sortie. Auparavant, c'était simplement un utilitaire stand alone avec des plugins, mais maintenant, enfin, les développeurs créent un grand serveur, à partir duquel il sera possible de gérer plusieurs agents. C'est génial, je recommande d'essayer.

Intégration dans le processus

L'intégration se fait assez bien et simplement : lancer le scan après une installation réussie de l'application sur le stand et scan après la réussite des tests d'intégration.

Si les intégrations ne fonctionnent pas ou s'il y a des bouchons et des fonctions mock, c'est inutile et sans valeur - quel que soit le pattern que nous envoyons, le serveur répondra toujours de la même manière.

• Idéalement - un stand séparé pour les tests.
• Avant de commencer les tests, enregistrez la séquence de connexion.
• Les tests du système d'administration - uniquement manuels.

Processus

Un peu en général sur le processus et sur le fonctionnement de chaque outil, en particulier. Toutes les applications sont différentes - certaines fonctionnent mieux avec l'analyse dynamique, d'autres avec l'analyse statique, d'autres avec l'analyse OpenSource, les pentests ou même quelque chose d'autre, par exemple, les événements avec Waf.

Chaque processus a besoin d'un contrôle.

Pour comprendre comment fonctionne un processus et où il peut être amélioré, il est nécessaire de collecter des métriques de tout ce qui est à portée de main, y compris des métriques de production, des métriques d'outils et des données des traqueurs de défauts.

Toute donnée est utile. Il faut analyser sous différents angles où tel ou tel outil est mieux appliqué et où le processus connaît des faiblesses. Peut-être faut-il examiner le temps de réponse du développement pour identifier les améliorations possibles en fonction du temps. Plus il y a de données, plus on peut établir des analyses allant des niveaux supérieurs aux détails de chaque processus.

Étant donné que chaque analyseur statique et dynamique a ses propres API, ses propres méthodes de lancement et principes, certains ont des planificateurs, d'autres non - nous développons un outil AppSec Orchestrateur, qui permet de créer un point d'entrée unique pour tout le processus à partir du produit et de le gérer à partir d'un seul endroit.

Les managers, développeurs et ingénieurs en sécurité ont un point d'entrée unique à partir duquel ils peuvent voir ce qui est en cours, configurer et lancer des scans, obtenir les résultats de ces scans et formuler des exigences. Nous essayons de nous éloigner des documents et de tout traduire dans un langage compréhensible, comme celui utilisé par le développement — des pages sur Confluence avec des statuts et des métriques, des défauts dans Jira ou dans divers traqueurs de défauts, ou bien l'intégration dans un processus synchrone/asynchrone dans CI/CD.

Principaux enseignements

Les outils ne sont pas l'essentiel. D'abord penser au processus - ensuite déployer des outils. Les outils sont bons, mais coûteux, donc on peut commencer par le processus et établir une interaction et une compréhension entre le développement et la sécurité. Du point de vue de la sécurité - il ne faut pas 'ralentir' tout à la fois. Du point de vue du développement - s'il y a quelque chose de hautement critique, cela doit être résolu, et non ignoré.

Qualité du produit — un objectif commun pour la sécurité et le développement. Nous faisons tous le même travail, nous nous efforçons de garantir que tout fonctionne correctement et qu'il n'y a pas de risques de réputation ou de pertes financières. C'est pourquoi nous promouvons l'approche DevSecOps, SecDevOps pour établir la communication et améliorer la qualité du produit.

Commencez par ce qui existe déjà: exigences, architecture, vérifications partielles, formations, lignes directrices. Il n'est pas nécessaire d'appliquer toutes les pratiques à tous les projets immédiatement — avancez de manière itérative. Il n'y a pas de norme unique — expérimentez et essayez différentes approches et solutions.

Il y a une égalité entre les défauts de sécurité de l'information et les défauts fonctionnels.

Automatisez tout, ce qui bouge. Tout ce qui ne bouge pas — faites-le bouger et automatisez-le. Si quelque chose est fait manuellement, ce n'est pas un bon segment du processus. Il vaut peut-être la peine de le revoir et de l'automatiser aussi.

Si la taille de l'équipe de sécurité de l'information est petite — utilisez des Security Champions.

Peut-être que ce dont je vous ai parlé ne vous conviendra pas et vous inventerez quelque chose de propre — et c'est bien. Mais choisissez les outils en fonction des exigences de votre processus spécifique. Ne vous laissez pas influencer par ce que dit la communauté, que cet outil est mauvais et que celui-ci est bon. Peut-être que sur votre produit, ce sera l'inverse.

Exigences pour les outils.

• Faible niveau de faux positifs.
• Temps d'analyse adéquat.
• Facilité d'utilisation.
• Disponibilité des intégrations.
• Compréhension de la feuille de route de développement du produit.
• Possibilité de personnalisation des outils.

La présentation de Yuri a été sélectionnée comme l'une des meilleures lors de DevOpsConf 2018. Pour découvrir encore plus d'idées intéressantes et de cas pratiques, venez les 27 et 28 mai à Skolkovo pour DevOpsConf dans le cadre de le festival RIT++. Mieux encore, si vous êtes prêt à partager votre expérience, alors soumettez une demande pour une présentation avant le 21 avril.

Source : habr.com