Peur et dégoût DevSecOps

Nous avions 2 analyseurs de code, 4 outils de tests dynamiques, nos propres crafts et 250 scripts. Non pas que tout cela était nécessaire dans le processus actuel, mais une fois que vous avez commencé à implémenter DevSecOps, vous devez aller jusqu'au bout.

Source. Personnages créés par Justin Roiland et Dan Harmon.

Qu'est-ce que SecDevOps ? Qu'en est-il de DevSecOps ? Quelles sont les différences? Sécurité des applications - de quoi s'agit-il ? Pourquoi l'approche classique ne fonctionne plus ? Toutes ces questions connaissent la réponse Yuri Shabalin de Sécurité de l'espadon. Yuriy répondra à tout en détail et analysera les problèmes de transition du modèle classique de sécurité applicative vers le processus DevSecOps : comment aborder correctement l'intégration du processus de développement sécurisé dans le processus DevOps et ne rien casser, comment passer par les principales étapes des tests 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 du haut-parleur : Yuri Shabalin - Architecte en chef de la sécurité dans l'entreprise Sécurité de l'espadon. Responsable de la mise en œuvre de SSDL, pour l'intégration globale des outils d'analyse d'applications dans un écosystème unique de développement et de test. 7 ans d'expérience en sécurité de l'information. A travaillé chez Alfa-Bank, Sberbank et chez Positive Technologies, qui développe des logiciels et fournit des services. Conférencier des conférences internationales ZerONights, PHDays, RISSPA, OWASP.

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

Sécurité des applications est la section de sécurité qui est responsable de la sécurité des applications. Il ne s'agit pas d'infrastructure ou de sécurité réseau, mais de ce que nous écrivons et sur quoi travaillent les développeurs - ce sont les défauts et les vulnérabilités de l'application elle-même.

Direction SDL ou SDLC - Cycle de vie du développement de la sécurité - Développé par Microsoft. Le diagramme montre le modèle SDLC canonique, dont la tâche principale est la participation de la sécurité à chaque étape du développement, des exigences à la publication et de la publication à la production. Microsoft s'est rendu compte qu'il y avait trop de bogues dans le bal, il y en avait plus et il fallait faire quelque chose à ce sujet, et ils ont proposé cette approche, qui est devenue canonique.

Application Security et SSDL ne visent pas à détecter les vulnérabilités, comme on le croit généralement, mais à prévenir leur apparition. Au fil du temps, l'approche canonique de Microsoft a été améliorée, développée, elle a une immersion détaillée plus profonde.

Le SDLC canonique est très détaillé dans diverses méthodologies - OpenSAMM, BSIMM, OWASP. Les méthodologies diffèrent, mais sont généralement similaires.

Construire la sécurité dans le modèle de maturité

je l'aime le plus BSIMM - Construire la sécurité dans le modèle de maturité. La base de la méthodologie est la division du processus de sécurité applicative en 4 domaines : Gouvernance, Intelligence, Points de contact SSDL et Déploiement. Chaque domaine compte 12 pratiques, qui sont représentées par 112 activités.

Chacune des 112 activités a 3 niveaux de maturité: débutant, intermédiaire et avancé. Vous pouvez étudier les 12 pratiques dans des sections, sélectionner les choses qui sont importantes pour vous, comprendre comment les mettre en œuvre et ajouter progressivement des éléments, par exemple, l'analyse de code statique et dynamique ou la révision de code. Vous établissez un plan et vous y travaillez sereinement dans le cadre de la mise en œuvre des activités choisies.

Pourquoi DevSecOps

DevOps est un processus global important dans lequel la sécurité doit être prise en charge.

Initialement DevOps implique des contrôles de sécurité. Dans la pratique, le nombre d'équipes de sécurité était beaucoup plus petit qu'aujourd'hui, et elles n'agissaient pas en tant que participants au processus, mais en tant qu'organe de contrôle et de surveillance qui lui impose des exigences et vérifie la qualité du produit à la fin de la version. Il s'agit d'une approche classique dans laquelle les équipes de sécurité étaient derrière un mur de développement et ne participaient pas au processus.

Le principal problème est que la sécurité de l'information est distincte du développement. Habituellement, il s'agit d'une sorte de circuit IB et il contient 2-3 outils volumineux et coûteux. Une fois tous les six mois, le code source ou l'application arrive pour être testé, et une fois par an Pentests. Tout cela conduit au fait que les dates de sortie pour l'industrie sont reportées et qu'un grand nombre de vulnérabilités des outils automatisés tombent sur le développeur. Il est impossible de démonter et de réparer tout cela, car même au cours des six mois précédents, les résultats n'ont pas été démontés, et voici un nouveau lot.

Dans le processus de travail de notre entreprise, nous constatons que la sécurité dans tous les domaines et industries comprend qu'il est temps de rattraper son retard et de tourner avec le développement en une seule roue - en Agile. Le paradigme DevSecOps s'intègre parfaitement dans la méthodologie de développement agile, la mise en œuvre, le support et la participation à chaque version et itération.

Transition vers DevSecOps

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

Il ne suffit pas d'inclure des outils dans le processus DevOps ; la communication et la compréhension entre les participants au processus sont importantes.

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, et se termine par des tentatives d'intégration de l'outil dans le processus en cours, qui restent des tentatives. Cela entraîne de tristes conséquences, car tous les outils ont leurs propres caractéristiques et limites.

Un cas courant est lorsque le service de sécurité a choisi un bon outil coûteux avec un large éventail de fonctionnalités et est venu voir les développeurs pour l'intégrer au processus. Mais cela ne fonctionne pas - le processus est conçu de telle manière que les limites d'un instrument déjà acheté ne correspondent pas au paradigme actuel.

Tout d'abord, décrivez le résultat que vous souhaitez et à quoi ressemblera le processus. Cela aidera à comprendre les rôles 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 contrôles, des tests d'intrusion - pourquoi ne pas transformer tout cela sous une forme compréhensible et pratique pour tout le monde ?

Habituellement, les exigences sont un Talmud papier qui se trouve sur une étagère. Il y a eu un cas où nous sommes venus voir l'entreprise pour examiner les processus et leur demander de montrer les exigences de sécurité pour le logiciel. Le spécialiste qui a fait ça cherchait depuis longtemps :

- Maintenant, quelque part dans les notes, il y avait un chemin où se trouve ce document.

En conséquence, nous avons reçu le document une semaine plus tard.

Pour les exigences, les vérifications et plus encore, créez une page, par exemple à Confluence - c'est pratique pour tout le monde.

Il est plus facile de reformater ce qui est déjà là et de l'utiliser pour commencer.

Utilisez des champions de la sécurité

Habituellement, dans une entreprise moyenne de 100 à 200 développeurs, il y a un responsable de la sécurité qui remplit plusieurs fonctions et n'a pas physiquement le temps de tout vérifier. Même s'il fait de son mieux, lui seul ne vérifiera pas tout le code généré par le développement. Pour de tels cas, un concept a été développé - Champions de la sécurité.

Security Champions est une personne au sein de l'équipe de développement qui s'intéresse à la sécurité de votre produit.

Security Champion est un point d'entrée pour l'équipe de développement et un évangéliste de la sécurité tout en un.

Habituellement, lorsqu'un agent de sécurité vient voir l'équipe de développement et signale une erreur dans le code, il reçoit une réponse surprise :

- Et qui êtes-vous? Je te vois pour la première fois. Tout va bien pour moi - mon ami senior a mis "appliquer" sur la révision du code, nous passons à autre chose !

C'est une situation typique, car il y a beaucoup plus de confiance dans les seniors ou simplement les coéquipiers avec lesquels le développeur interagit constamment au travail et dans la révision du code. Si, au lieu d'un agent de sécurité, le champion de la sécurité signale l'erreur et les conséquences, alors sa parole aura plus de poids.

De plus, les développeurs connaissent leur code mieux que n'importe quel gars de la sécurité. Pour une personne qui a au moins 5 projets dans un outil d'analyse statique, il est généralement difficile de retenir toutes les nuances. Les champions de la sécurité connaissent leur produit : ce qui interagit avec quoi et ce qu'il faut regarder en premier lieu - ils sont plus efficaces.

Envisagez donc de mettre en place des champions de la sécurité et d'étendre l'influence de l'équipe de sécurité. Pour le champion lui-même, cela est également utile : développement professionnel dans un nouveau domaine, élargissement des horizons techniques, pompage des compétences techniques, managériales et de leadership, augmentation de la valeur marchande. C'est un élément d'ingénierie sociale, vos "yeux" dans l'équipe de développement.

Étapes de test

Paradigme 20 par 80 dit que 20% des efforts donnent 80% des résultats. Ces 20 % sont des pratiques d'analyse d'applications qui peuvent et doivent être automatisées. Des exemples de telles activités sont l'analyse statique − SAST, analyse dynamique — DAST и contrôle de source ouverte. Je vais vous en dire plus sur les activités, ainsi que sur les outils, les fonctionnalités que nous rencontrons habituellement lorsqu'elles sont introduites dans le processus et comment le faire correctement.

Principaux problèmes d'outils

Je soulignerai les problèmes qui sont pertinents pour tous les instruments qui nécessitent une attention. Je vais les analyser plus en détail pour ne pas me répéter davantage.

Temps d'analyse long. S'il faut 30 minutes pour tous les tests et l'assemblage, de la validation à la mise en production, les contrôles de sécurité des informations prendront une journée. Ainsi, personne ne ralentira le processus. Considérez cette fonctionnalité et tirez des conclusions.

Haut faux négatif ou faux positif. Tous les produits sont différents, tous utilisent des frameworks différents et leur propre style de codage. Sur différentes bases de code et technologies, les outils peuvent afficher différents niveaux de faux négatif et de faux positif. Alors regarde ce qu'il y a dedans votre entreprises et pour votre les applications montreront un résultat bon et fiable.

Aucune intégration avec les outils existants. Regardez les outils en termes d'intégrations avec ce que vous utilisez déjà. Par exemple, si vous avez Jenkins ou TeamCity, vérifiez l'intégration des outils avec ce logiciel, et non avec GitLab CI, que vous n'utilisez pas.

Absence ou complexité excessive de la personnalisation. Si l'outil n'a pas d'API, pourquoi est-il nécessaire ? Tout ce qui peut être fait dans l'interface doit être disponible via l'API. Idéalement, l'outil devrait avoir la capacité de personnaliser les vérifications.

Aucune feuille de route de développement de produit. Le développement ne s'arrête pas, nous utilisons toujours de nouveaux frameworks et fonctions, réécrivons l'ancien code dans de nouveaux langages. Nous voulons nous assurer que l'outil que nous achetons prendra en charge de nouveaux frameworks et technologies. Par conséquent, il est important de savoir que le produit a une valeur réelle et correcte Feuille de route développement.

Caractéristiques du processus

En plus des caractéristiques des outils, tenez compte des caractéristiques du processus de développement. Par exemple, interférer avec le développement est une erreur typique. Voyons quelles autres fonctionnalités doivent être prises en compte et à quoi l'équipe de sécurité doit prêter attention.

Afin de ne pas perturber les délais de développement et de release, créer règles différentes et différent montrer les bouchons - critères d'arrêt du processus de construction en présence de vulnérabilités - pour différents environnements. Par exemple, nous comprenons que la branche actuelle va à un stand de développement ou UAT, donc nous ne nous arrêtons pas et disons :

- Vous avez des vulnérabilités ici, vous n'irez pas plus loin !

À ce stade, il est important de dire aux développeurs qu'il y a des problèmes de sécurité à surveiller.

La présence de vulnérabilités n'est pas un obstacle à des tests supplémentaires: manuel, intégration ou manuel. D'un autre côté, nous devons améliorer d'une manière ou d'une autre la sécurité du produit, et pour que les développeurs ne marquent pas sur ce que la sécurité trouve. Par conséquent, nous faisons parfois ceci : sur le stand, lors du déploiement dans l'environnement de développement, nous informons simplement le développement :

- Les gars, vous avez des problèmes, faites-y attention.

Au stade UAT, nous affichons à nouveau des avertissements sur les vulnérabilités, et au stade de sortie du bal, nous disons :

"Les gars, nous vous avons prévenu plusieurs fois, vous n'avez rien fait - nous ne vous laisserons pas sortir avec ça.

Si nous parlons de code et de dynamique, il est nécessaire de montrer et d'avertir des vulnérabilités uniquement des fonctionnalités et du code qui vient d'être écrit dans cette fonctionnalité. Si le développeur a déplacé le bouton de 3 pixels et que nous lui disons qu'il y a une injection SQL et qu'il doit donc être corrigé de toute urgence, c'est faux. Ne regardez que ce qui est écrit maintenant et le changement apporté à l'application.

Disons que nous avons un défaut fonctionnel - la façon dont l'application ne devrait pas fonctionner : l'argent n'est pas transféré, lorsque vous cliquez sur le bouton, il n'y a pas de transition vers la page suivante ou le produit ne se charge pas. Défauts de sécurité - ce sont les mêmes défauts, mais pas dans le cadre 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. Chérif Mansour, Expedia.

Étant donné que toutes les vulnérabilités sont les mêmes défauts, elles doivent être situées au même endroit que tous les défauts de développement. Oubliez donc les rapports et les PDF effrayants que personne ne lit.

Lorsque je travaillais pour une société de développement, j'ai reçu un rapport d'outils d'analyse statique. Je l'ai ouvert, j'ai été horrifié, j'ai fait du café, j'ai feuilleté 350 pages, je l'ai fermé et je me suis mis au travail. Les gros rapports sont des rapports morts. Habituellement, ils ne vont nulle part, les e-mails sont supprimés, oubliés, perdus ou l'entreprise dit qu'elle prend des risques.

Ce qu'il faut faire? Nous convertissons simplement les défauts confirmés que nous avons trouvés sous une forme pratique pour le développement, par exemple, l'ajoutons au backlog dans Jira. Les défauts sont classés par ordre de priorité et éliminés par ordre de priorité avec les défauts fonctionnels et les défauts de test.

Analyse statique - SAST

Il s'agit d'une analyse de code pour les vulnérabilités., mais ce n'est pas la même chose que SonarQube. Nous ne vérifions pas seulement les motifs ou le style. L'analyse utilise plusieurs approches : par arbre de vulnérabilité, par Flux de données, en analysant les fichiers de configuration. C'est tout pour le code lui-même.

Avantages de l'approche: identifier les vulnérabilités du code à un stade précoce du développementlorsqu'il n'y a pas de supports et d'outils prêts à l'emploi, et capacité de numérisation incrémentielle: scanne une section de code qui a changé, et uniquement la fonctionnalité que nous sommes en train de faire, ce qui réduit le temps de scan.

Moins est le manque de support pour les langues requises.

Intégrations requises, qui devrait être dans les outils, à mon avis subjectif :

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

L'image montre quelques-uns des meilleurs représentants de l'analyse statique.

Ce ne sont pas les outils qui comptent, mais le processus, il existe donc des solutions Open Source qui sont également bonnes pour exécuter le processus.

SAST Open Source ne trouvera pas un grand nombre de vulnérabilités ou de DataFlow complexes, mais ils peuvent et doivent être utilisés lors de la construction d'un processus. Ils aident à comprendre comment le processus sera construit, qui répondra aux bugs, qui signalera, qui signalera. Si vous souhaitez réaliser la première étape de construction de la sécurité de votre code, utilisez des solutions Open Source.

Comment intégrer cela si vous êtes au début du parcours, vous n'avez rien : ni CI, ni Jenkins, ni TeamCity ? Envisagez l'intégration des processus.

Intégration au niveau CVS

Si vous avez Bitbucket ou GitLab, vous pouvez faire une intégration au niveau Système de versions simultanées.

Par événement pull request, commit. Vous scannez le code et indiquez dans l'état de la construction que le contrôle de sécurité a réussi ou échoué.

Commentaires Bien sûr, les commentaires sont toujours nécessaires. Si vous l'avez juste fait du côté de la sécurité, que vous l'avez mis dans une boîte et que vous n'en avez rien dit à personne, puis que vous avez vidé un tas de bogues à la fin du mois, ce n'est pas bien et pas bon.

Intégration avec le système de revue de code

Une fois, nous avons défini l'utilisateur technique AppSec comme réviseur par défaut dans un certain nombre de projets importants. Selon que des erreurs ont été trouvées dans le nouveau code ou qu'il n'y a pas d'erreurs, l'examinateur place le statut de la demande d'extraction sur "accepter" ou "besoin de travail" - soit tout va bien, soit vous devez finaliser et établir des liens vers quoi exactement finaliser. Pour l'intégration avec la version en cours de publication, nous avons désactivé la fusion si le test IS n'est pas réussi. Nous l'avons inclus dans la révision manuelle du code, et le reste des participants au processus a vu les statuts de sécurité pour ce processus particulier.

Intégration avec SonarQube

Beaucoup ont portail de qualité en termes de qualité de code. C'est la même chose ici - vous ne pouvez créer les mêmes portes que pour les instruments SAST. Il y aura la même interface, le même portail de qualité, seulement il s'appellera porte de sécurité. Et aussi, si vous avez un processus configuré à l'aide de SonarQube, vous pouvez facilement tout y intégrer.

Intégration au niveau CI

Ici aussi, tout est assez simple :

• À égalité avec les autotests, tests unitaires.
• Division par étapes de développement: dev, test, prod. Différents ensembles de règles peuvent être inclus, ou différentes conditions d'échec : nous arrêtons l'assemblage, nous n'arrêtons pas l'assemblage.
• Exécution synchrone/asynchrone. On attend la fin des tests de sécurité ou on n'attend pas. Autrement dit, nous venons de les lancer et de passer à autre chose, puis nous obtenons un statut indiquant que tout est bon ou mauvais.

Tout est dans un monde rose parfait. Dans la vraie vie, ce n'est pas le cas, mais nous nous efforçons. 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 avons décidé que nous allons maintenant le scanner avec SAST - OK. Nous avons poussé ce projet dans SAST, cela nous a donné 20 000 vulnérabilités, et nous avons pris la décision volontaire que tout allait bien. 20 000 vulnérabilités, c'est notre dette technique. Nous mettrons la dette dans une boîte, nous la ratisserons lentement et commencerons des bogues dans les traqueurs de défauts. Engagez une entreprise, faites tout nous-mêmes ou demandez à des champions de la sécurité de nous aider, et la dette technique diminuera.

Et toutes les vulnérabilités nouvellement apparues dans le nouveau code doivent être éliminées de la même manière que les erreurs dans une unité ou dans les autotests. Toutes proportions gardées, le montage a commencé, s'est éloigné, deux tests et deux tests de sécurité sont tombés. OK - nous y sommes allés, avons regardé ce qui s'est passé, corrigé un, corrigé le second, conduit la prochaine fois - tout va bien, aucune nouvelle vulnérabilité n'est apparue, les tests n'ont pas échoué. Si cette tâche est plus approfondie et que vous devez bien la comprendre, ou si la correction des vulnérabilités affecte de larges couches de ce qui se cache sous le capot : un bogue est introduit dans le suivi des défauts, il est priorisé et corrigé. Malheureusement, le monde n'est pas parfait et les tests échouent parfois.

Un exemple de porte de sécurité est un analogue d'une porte de qualité, en termes de présence et de nombre de vulnérabilités dans le code.

Nous intégrons SonarQube - le plugin est installé, tout est très pratique et cool.

Intégration de l'environnement de développement

Possibilités d'intégration :

• Démarrage d'un scan depuis l'environnement de développement avant même le commit.
• Voir les résultats.
• Analyse des résultats
• Synchronisation avec le serveur.

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

Dans notre environnement de développement IDÉE Intellectuelle il apparaît juste un élément supplémentaire indiquant que de telles vulnérabilités ont été trouvées lors de l'analyse. Vous pouvez immédiatement modifier le code, voir les recommandations et graphique de flux. Tout cela est situé sur le lieu de travail du développeur, ce qui est très pratique - vous n'avez pas besoin de suivre le reste des liens et de regarder quelque chose en plus.

Open source

C'est mon sujet préféré. Tout le monde utilise des bibliothèques Open Source - pourquoi écrire un tas de béquilles et de vélos quand vous pouvez prendre une bibliothèque toute faite dans laquelle tout est déjà implémenté ?

Bien sûr, c'est vrai, mais les bibliothèques sont également écrites par des personnes, comportent également certains risques, et il existe également des vulnérabilités qui sont signalées périodiquement ou constamment. Par conséquent, il y a une prochaine étape dans la sécurité des applications - c'est 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 sorte de bibliothèque, et que dans CVE ou dans les traqueurs de bogues, certaines vulnérabilités sont liées à cette version de la bibliothèque. Si vous essayez de l'utiliser, l'outil vous avertira que la bibliothèque est vulnérable et vous conseillera d'utiliser une autre version où il n'y a pas de vulnérabilités.

Analyse de la pureté des licences. Ce n'est pas encore très populaire chez nous, mais si vous travaillez avec un pays étranger, vous pouvez périodiquement subir une attaque pour avoir utilisé un composant open source qui ne peut pas être utilisé ou modifié. Selon la politique de la bibliothèque agréée, nous ne pouvons pas le faire. Ou, si nous l'avons modifié et l'utilisons, nous devons poster notre code. Bien sûr, personne ne veut afficher le code de ses produits, mais vous pouvez aussi vous en protéger.

Analyse des composants utilisés dans un environnement industriel. Imaginez une situation hypothétique où nous avons enfin terminé le développement et publié la dernière version de notre microservice pour l'industrie. Il y vit à merveille - une semaine, un mois, un an. Nous ne le récupérons pas, nous n'effectuons pas de contrôles de sécurité, tout semble aller bien. Mais soudain, deux semaines après la sortie, une vulnérabilité critique dans le composant Open Source apparaît, que nous utilisons dans cet assemblage particulier, dans l'environnement industriel. Si nous n'enregistrons pas quoi et où nous utilisons, cette vulnérabilité ne sera tout simplement pas visible. Certains outils ont la capacité de surveiller les vulnérabilités dans les bibliothèques actuellement utilisées dans prom. C'est très utile.

Caractéristiques:

• Différentes politiques pour différents stades de développement.
• Surveiller les composants dans un environnement industriel.
• Contrôle des bibliothèques dans le contour de l'organisation.
• Prise en charge de divers systèmes de construction et langages.
• Analyse des images Docker.

Quelques exemples de leaders dans le domaine qui sont engagés dans l'analyse de l'Open Source.

Le seul gratuit est Contrôle de dépendance de l'OWASP. Vous pouvez l'activer dès les premières étapes, voir comment cela fonctionne et ce qu'il prend en charge. Fondamentalement, ce sont tous des produits cloud, ou sur site, mais derrière leur base, ils vont toujours sur Internet. Ils n'envoient pas vos bibliothèques, mais des hashes ou leurs valeurs qu'ils calculent, et des empreintes digitales à leur serveur afin de recevoir des nouvelles de la présence de vulnérabilités.

Intégration de processus

Contrôle de la bibliothèque de périmètrequi sont téléchargés à partir de sources externes. Nous avons des référentiels externes et internes. Par exemple, nous avons Nexus dans Event Central, et nous voulons nous assurer qu'il n'y a pas de vulnérabilités avec un statut "critique" ou "élevé" dans notre référentiel. Vous pouvez configurer le proxy à l'aide de l'outil Nexus Firewall Lifecycle afin que ces vulnérabilités soient supprimées et non incluses dans le référentiel interne.

Intégration IC. Au même niveau avec les autotests, les tests unitaires et le découpage en étapes de développement : dev, test, prod. À chaque étape, vous pouvez télécharger n'importe quelle bibliothèque, utiliser n'importe quoi, mais s'il y a quelque chose de difficile avec le statut «critique», vous devriez probablement attirer l'attention des développeurs sur cela au stade de l'entrée dans le bal.

Intégration d'artefacts: Nexus et JFrog.

Intégration dans l'environnement de développement. Les outils que vous choisissez doivent être intégrés aux environnements de développement. Le développeur doit avoir accès aux résultats de l'analyse depuis son lieu de travail, ou la possibilité d'analyser et de vérifier le code pour détecter les vulnérabilités avant de le valider dans CVS.

Intégration CD. C'est une fonctionnalité intéressante que j'aime beaucoup et dont j'ai déjà parlé - surveiller l'émergence de nouvelles vulnérabilités dans un environnement industriel. Cela fonctionne comme ça.

Nous avons Référentiels de composants publics - quelques outils extérieurs, et notre référentiel interne. Nous voulons que seuls des composants de confiance y figurent. Lors du proxying d'une requête, nous vérifions que la bibliothèque téléchargée ne présente aucune vulnérabilité. S'il relève de certaines politiques que nous définissons et coordonnons nécessairement avec le développement, nous ne le téléchargeons pas et nous obtenons un refus d'utiliser une version différente. En conséquence, s'il y a quelque chose de vraiment critique et mauvais dans la bibliothèque, le développeur ne recevra pas la bibliothèque même au stade de l'installation - laissez-le utiliser une version supérieure ou inférieure.

• Lors de la construction, nous vérifions que personne n'a glissé quoi que ce soit de mauvais, que tous les composants sont sûrs et que personne n'a apporté quoi que ce soit de dangereux sur le lecteur flash.
• Nous n'avons que des composants de confiance dans le référentiel.
• Lors du déploiement, nous vérifions à nouveau le paquet lui-même : image war, jar, DL ou Docker pour s'assurer qu'il est conforme à la politique.
• En entrant dans l'environnement industriel, nous surveillons ce qui se passe dans l'environnement industriel : des vulnérabilités critiques apparaissent ou n'apparaissent pas.

Analyse dynamique - DAST

Les outils d'analyse dynamique sont fondamentalement différents de tout ce qui a été dit auparavant. C'est une sorte d'imitation du travail de l'utilisateur avec l'application. S'il s'agit d'une application web, nous envoyons des requêtes imitant le travail du client, cliquons sur les boutons en façade, envoyons des données artificielles depuis le formulaire : guillemets, parenthèses, caractères dans différents encodages pour voir comment l'application fonctionne et traite les externes données.

Le même système vous permet de vérifier les vulnérabilités des modèles dans Open Source. Étant donné que DAST ne sait pas quel Open Source nous utilisons, il lance simplement des modèles "malveillants" et analyse les réponses du serveur :

- Ouais, il y a un problème de désérialisation ici, mais pas ici.

Il y a de gros risques à cela, car si vous effectuez ce test de sécurité sur le même stand que celui avec lequel les testeurs travaillent, des choses désagréables peuvent se produire.

• Charge élevée sur le réseau du serveur d'applications.
• Aucune intégration.
• La possibilité de modifier les paramètres de l'application analysée.
• Il n'y a pas de support pour les technologies requises.
• Difficulté de réglage.

Nous avons eu une situation lorsque nous avons enfin lancé AppScan : nous avons coupé l'accès à l'application pendant longtemps, reçu 3 comptes et étions ravis - enfin, nous allons tout vérifier ! Nous avons lancé une analyse, et la première chose qu'AppScan a faite a été d'accéder au panneau d'administration, de percer tous les boutons, de modifier la moitié des données, puis de tuer complètement le serveur avec les siens. formulaire de courrier-demandes. Development with Testing a dit :

"Les gars, vous vous moquez de moi ? ! On t'a rendu des comptes, et tu as mis le stand !

Considérez les risques possibles. Idéalement, préparez un stand séparé pour tester la sécurité des informations, qui sera au moins isolé du reste de l'environnement, et vérifiez conditionnellement le panneau d'administration, de préférence en mode manuel. Il s'agit d'un pentest - ces pourcentages d'efforts restants que nous ne considérons pas maintenant.

Cela vaut la peine de considérer que vous pouvez l'utiliser comme un analogue du test de charge. Au premier stade, vous pouvez activer le scanner dynamique dans 10 à 15 threads et voir ce qui se passe, mais généralement, comme le montre la pratique, rien de bon.

Quelques ressources que nous utilisons habituellement.

À souligner Suite Burp est le "couteau suisse" de tout professionnel de la sécurité. Tout le monde l'utilise et c'est très pratique. Une nouvelle version de démonstration de l'édition entreprise est maintenant disponible. Si auparavant ce n'était qu'un utilitaire autonome avec des plugins, maintenant les développeurs font enfin un gros serveur à partir duquel il sera possible de gérer plusieurs agents. C'est cool, je vous conseille d'essayer.

Intégration de processus

L'intégration est assez bonne et simple : lancer l'analyse après une installation réussie applications sur le stand et analyse après un test d'intégration réussi.

Si les intégrations ne fonctionnent pas ou s'il y a des stubs et des fonctions fictives, cela n'a aucun sens et est inutile - quel que soit le modèle que nous envoyons, le serveur répondra toujours de la même manière.

• Idéalement, un banc d'essai séparé.
• Avant de tester, notez la séquence de connexion.
• Le test du système d'administration est uniquement manuel.

Processus

Un peu généralisé sur le processus en général et sur le travail de chaque outil, en particulier. Toutes les applications sont différentes - l'une fonctionne mieux avec l'analyse dynamique, une autre avec l'analyse statique, la troisième avec l'analyse OpenSource, les pentests ou autre chose en général, par exemple, les événements avec Waf.

Chaque processus doit être contrôlé.

Pour comprendre comment le processus fonctionne et où il peut être amélioré, vous devez collecter des métriques à partir de tout ce sur quoi vous pouvez mettre la main, y compris les métriques de production, les métriques des outils et les outils de suivi des défauts.

Toute information est utile. Il est nécessaire de regarder dans différentes sections où tel ou tel outil est mieux utilisé, où le processus s'affaisse spécifiquement. Il peut être utile d'examiner le temps de réponse du développement pour voir où améliorer le processus en fonction du temps. Plus il y a de données, plus il est possible de construire des coupes depuis le niveau supérieur jusqu'aux détails de chaque processus.

Étant donné que tous les analyseurs statiques et dynamiques ont leurs propres API, leurs propres méthodes de lancement, principes, certains ont des planificateurs, d'autres pas - nous écrivons un outil Orchestrateur AppSec, ce qui vous permet de créer un point d'entrée unique sur l'ensemble du processus à partir du produit et de le gérer à partir d'un point unique.

Les gestionnaires, les développeurs et les ingénieurs en sécurité disposent d'un point d'entrée à partir duquel ils peuvent voir ce qui est en cours d'exécution, configurer et exécuter des analyses, obtenir des résultats d'analyse et soumettre des exigences. Nous essayons de nous éloigner des morceaux de papier, de tout traduire en un document humain utilisé par le développement - pages sur Confluence avec statut et métriques, défauts dans Jira ou dans divers traqueurs de défauts, ou intégration dans un processus synchrone/asynchrone dans CI/CD.

Faits marquants

Les outils n'ont pas d'importance. Pensez d'abord au processus, puis mettez en œuvre les outils. Les outils sont bons, mais chers, vous pouvez donc commencer par le processus et affiner l'interaction et la compréhension entre le développement et la sécurité. Du point de vue de la sécurité, il n'est pas nécessaire de "tout arrêter" d'affilée. Du point de vue du développement, s'il y a quelque chose de très méga super critique, alors cela doit être éliminé, et non fermé au problème .

La qualité des produits - but commun à la fois la sécurité et le développement. Nous faisons une chose, nous essayons de nous assurer que tout fonctionne correctement et qu'il n'y a pas de risques de réputation ni de pertes financières. C'est pourquoi nous favorisons l'approche DevSecOps, SecDevOps afin d'établir la communication et d'améliorer le produit.

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

Signe égal entre défauts SI et défauts fonctionnels.

Tout automatiserça bouge. Tout ce qui ne bouge pas, bouge et s'automatise. Si quelque chose est fait à la main, ce n'est pas une bonne partie du processus. Peut-être vaut-il la peine de le reconsidérer et de l'automatiser aussi.

Si la taille de l'équipe de l'IB est petite - utiliser les champions de la sécurité.

Peut-être que ce dont j'ai parlé ne vous conviendra pas et que vous proposerez quelque chose de votre côté - et c'est bien. Mais choisir des outils en fonction des exigences de votre processus. Ne regardez pas ce que la communauté dit que cet outil est mauvais et celui-ci est bon. Ce sera peut-être l'inverse sur votre produit.

Besoins en outils.

• Faux positif faible.
• Temps d'analyse suffisant.
• Facilité d'utilisation
• Disponibilité des intégrations.
• Comprendre la feuille de route de développement de produits.
• Possibilité de personnaliser les outils.

Le rapport de Yuriy a été choisi comme l'un des meilleurs lors de la DevOpsConf 2018. Pour vous familiariser avec des idées et des cas pratiques encore plus intéressants, rendez-vous à Skolkovo les 27 et 28 mai Conférence DevOps dans festival RIT++. Encore mieux, si vous êtes prêt à partager votre expérience, alors appliquer Soumettez votre rapport avant le 21 avril.

Source: habr.com