DevSecOps craint et déteste

Nous avions 2 analyseurs de code, 4 outils pour les tests dynamiques, notre propre artisanat et 250 scripts. Non pas que tout cela était nécessaire dans le processus actuel, mais depuis que j'ai commencé à implémenter DevSecOps, nous devons aller jusqu'au bout.



Source Auteurs de personnages: Justin Royland et Dan Harmon.

Qu'est-ce que SecDevOps? Et DevSecOps? Quelles sont les différences? Sécurité des applications - de quoi s'agit-il? Pourquoi l'approche classique ne fonctionne-t-elle plus? Yury Shabalin de Swordfish Security connaît la réponse à toutes ces questions . Yuri répondra à tout en détail et analysera les problèmes de passage du modèle de sécurité d'application classique au processus DevSecOps: comment aborder 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, quels ils diffèrent et comment les configurer correctement pour éviter les pièges.


À propos de l'orateur: Yuri Shabalin - architecte en chef de la sécurité chez Swordfish Security . Il est responsable de la mise en œuvre de SSDL, de l'intégration générale des outils d'analyse d'application dans un seul écosystème de développement et de test. 7 ans d'expérience en sécurité de l'information. Il a travaillé chez Alfa Bank, Sberbank et Positive Technologies, qui développe des logiciels et fournit des services. Conférencier de conférences internationales ZerONights, PHDays, RISSPA, OWASP.

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

La sécurité des applications est la section de sécurité qui est responsable de la sécurité des applications. Cela ne s'applique pas à la sécurité de l'infrastructure ou du réseau, à savoir ce que nous écrivons et ce sur quoi les développeurs travaillent - ce sont les failles et les vulnérabilités de l'application elle-même.

La direction de SDL ou SDLC - Cycle de vie du développement de la sécurité - a été développée 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 mise en production et à la mise en production. Microsoft s'est rendu compte qu'il y avait trop de bogues dans le bal, il y en avait plus et quelque chose devait être fait, et ils ont proposé cette approche, qui est devenue canonique.



La sécurité des applications et SSDL ne visent pas à détecter les vulnérabilités, comme on le pense généralement, mais à empêcher leur apparition. Au fil du temps, l'approche canonique de Microsoft a été améliorée, développée et une immersion détaillée plus profonde y est apparue.



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

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

J'aime BSIMM le plus - Building Security In Maturity Model . La base de la méthodologie est la séparation du processus de sécurité des applications en 4 domaines: gouvernance, intelligence, points de contact SSDL et déploiement. Chaque domaine a 12 pratiques, qui sont représentées comme 112 activités.



Chacune des 112 activités a 3 niveaux de maturité : élémentaire, intermédiaire et avancé. Les 12 pratiques peuvent être étudiées en sections, sélectionner des éléments importants 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 peignez le plan et travaillez calmement dessus dans le cadre de la mise en œuvre des activités sélectionnées.

Pourquoi DevSecOps

DevOps est un gros processus courant dans lequel vous devez prendre soin de la sécurité.

Au départ, DevOps comprenait des contrôles de sécurité. Dans la pratique, le nombre d'équipes de sécurité était beaucoup plus réduit qu'aujourd'hui et elles n'ont pas agi en tant que participants au processus, mais en tant qu'organe de contrôle et de surveillance qui lui fixe des exigences et vérifie la qualité du produit à la fin de la publication. Il s'agit d'une approche classique dans laquelle les équipes de sécurité étaient derrière le mur depuis le développement et n'étaient pas impliquées dans le processus.



Le principal problème est que la sécurité de l'information est distincte du développement. Habituellement, c'est une sorte de circuit IB et il contient 2-3 gros outils coûteux. Tous les six mois, le code source ou l'application arrive, qui doit être vérifié, et une fois par an, des pentests sont produits. Tout cela conduit au fait que les délais pour entrer dans le bal sont reportés et qu'un grand nombre de vulnérabilités des outils automatisés tombent sur le développeur. Tout cela ne peut pas être démonté et réparé, car les résultats des six mois précédents n'ont pas été triés, et voici un nouveau lot.

Dans le processus de notre entreprise, nous voyons que la sécurité dans tous les domaines et toutes les industries comprend qu'il est temps de vous tirer et de tourner avec le développement dans une seule roue - en Agile . Le paradigme DevSecOps s'intègre parfaitement à la méthodologie de développement agile, à l'implémentation, au 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'incorporer des outils dans le processus DevOps - l'interaction et la compréhension entre les participants au processus sont importantes.

Plus important que les gens, pas les outils

Souvent, la planification d'un processus de développement sûr commence par la sélection et l'achat d'un outil et se termine par des tentatives d'intégration de l'outil dans le processus actuel, 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 où le département de la sécurité a choisi un bon outil coûteux, avec de grandes fonctionnalités, et est venu aux développeurs - pour l'intégrer dans le processus. Mais cela ne fonctionne pas - le processus est structuré de telle sorte que les limites de l'outil déjà acheté ne correspondent pas au paradigme actuel.

Décrivez d'abord le résultat souhaité et l'apparence du processus. Cela vous aidera à comprendre les rôles de l'outil et de la sécurité dans le processus.

Commencez avec 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é pour le développement, il y a des contrôles, des pentests - pourquoi ne pas transformer tout cela en une forme compréhensible et pratique pour tout le monde?

En règle générale, les exigences sont un Talmud papier, qui repose sur une étagère. Il y a eu un cas où nous sommes venus dans l'entreprise pour voir les processus et demander de montrer les exigences de sécurité pour le logiciel. Le spécialiste qui a fait cela cherchait depuis longtemps:

- Maintenant, quelque part dans les notes, il y avait un moyen de trouver ce document.

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

Pour les exigences, les vérifications et d'autres choses, 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 pour commencer.

Utiliser des champions de la sécurité

Habituellement, dans une entreprise de taille moyenne pour 100 à 200 développeurs, un responsable de la sécurité travaille, qui remplit plusieurs fonctions et n'a physiquement pas 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.

Le champion de la sécurité est le point d'entrée de l'équipe de développement et l'évangéliste de la sécurité en un seul.

Habituellement, lorsqu'un coffre-fort arrive à l'équipe de développement et indique une erreur dans le code, il reçoit une réponse surprise:

"Qui êtes-vous?" Je te vois pour la première fois. Je vais bien - mon ami aîné sur le jeu de révision de code "appliquer", nous allons plus loin!

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

De plus, les développeurs connaissent mieux leur code que tout autre fournisseur de sécurité. Pour une personne qui a au moins 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 regarder en premier lieu - ils sont plus efficaces.

Pensez donc à mettre en œuvre des champions de la sécurité et à é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, renforcement des compétences techniques, managériales et de leadership, augmentation de la valeur de marché. Ceci est un élément de l'ingénierie sociale, vos «yeux» dans l'équipe de développement.

Étapes de test

Le paradigme 20 à 80 indique que 20% de l'effort produit 80% du résultat. Ces 20% sont des pratiques d'analyse d'application 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 vous en dire plus sur les activités, ainsi que sur les outils, les fonctionnalités que nous rencontrons généralement lorsqu'elles sont introduites dans le processus et comment le faire correctement.

Les principaux problèmes des outils

Je vais souligner les problèmes qui sont pertinents pour tous les outils qui nécessitent une attention. Je les analyserai plus en détail pour ne pas répéter davantage.

Analyse longue durée. S'il faut 30 minutes pour terminer tous les tests et l'assemblage depuis la validation jusqu'à la publication, les contrôles de sécurité des informations prendront une journée. Personne ne ralentira donc le processus. Considérez cette fonctionnalité et tirez des conclusions.

Haut faux négatif ou faux positif. Tous les produits sont différents, chacun utilise des cadres différents et son propre style d'écriture de code. Sur différentes bases de code et technologies, les outils peuvent afficher différents niveaux de faux négatif et de faux positif. Par conséquent, voyez exactement ce qui dans votre entreprise et pour vos applications affichera un résultat bon et fiable.

Aucune intégration avec les outils existants . Regardez les outils en termes d'intégrations pour que vous les utilisiez 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.

L'absence ou la 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 accessible via l'API. Idéalement, l'outil devrait pouvoir personnaliser les chèques.

Pas de développement de produit de feuille de route. Le développement ne s'arrête pas, nous utilisons toujours de nouveaux cadres et fonctions, réécrivons l'ancien code dans de nouveaux langages. Nous voulons être sûrs que l'outil que nous achetons prendra en charge de nouveaux cadres et technologies. Par conséquent, il est important de savoir que le produit a une feuille de route de développement réelle et appropriée.

Caractéristiques du processus

En plus des fonctionnalités des outils, tenez compte des fonctionnalités 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 ce à quoi l'équipe de sécurité doit prêter attention.

Afin de ne pas perturber les dates de développement et de publication, créez différentes règles et différents arrêts de spectacle - critères pour arrêter le processus de construction en présence de vulnérabilités - pour différents environnements . Par exemple, nous comprenons que la branche actuelle va au stand de développement ou UAT, donc nous ne nous arrêtons pas et ne disons pas:

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

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

La présence de vulnérabilités n'est pas un obstacle pour d'autres tests : manuel, intégration ou manuel. D'autre part, nous devons en quelque sorte augmenter la sécurité du produit, et pour que les développeurs n'oublient pas ce qu'ils trouvent sûr. Par conséquent, nous le faisons parfois: sur le stand, lorsqu'il se déploie dans l'environnement de développement, nous informons simplement le développement:

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

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 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 de mettre en garde contre les vulnérabilités uniquement des fonctionnalités et du code qui viennent d'être écrits 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. Regardez seulement ce qui est écrit maintenant et le changement qui vient à l'application.

Supposons que nous ayons un certain 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. Les défauts de sécurité sont les mêmes défauts, mais pas dans le contexte de l'application, mais de 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 les mêmes défauts, elles doivent être situées au même endroit que tous les défauts de développement. Alors oubliez 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 j'ai continué à travailler. Les gros rapports sont des rapports morts . Habituellement, ils ne vont nulle part, les lettres sont supprimées, oubliées, perdues ou l'entreprise dit qu'elle prend des risques.

Que faire Nous transformons simplement les défauts confirmés que nous avons trouvés en une forme pratique pour le développement, par exemple, les ajoutons au backlog de Jira. Nous priorisons et éliminons les défauts par ordre de priorité ainsi que 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 vérifions non seulement les motifs ou le style. Dans l'analyse, un certain nombre d'approches sont utilisées: dans l'arbre de vulnérabilité, dans DataFlow , dans l'analyse des fichiers de configuration. Tout cela est directement lié au code.

Avantages de l'approche : identifier les vulnérabilités du code à un stade précoce de développement , lorsqu'il n'y a pas de support et un outil fini, et la possibilité de numérisation incrémentielle : numérisation d'une section de code qui a changé, et uniquement la fonctionnalité que nous faisons maintenant, ce qui réduit le temps de numérisation.

Inconvénients - c'est le manque de prise en charge des langues nécessaires.

Les intégrations nécessaires qui devraient ê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 le développeur de ne pas pénétrer dans une interface incompréhensible dont il faut encore se souvenir, mais directement sur le lieu de travail dans son propre environnement de développement pour voir toutes les intégrations et vulnérabilités nécessaires qu'il a trouvées.
  
• Revue de code: SonarQube et revue manuelle.
  
• Détecteurs de défauts: Jira et Bugzilla.
  

La photo montre certains des meilleurs représentants de l'analyse statique.



Ce ne sont pas les outils qui sont importants, mais le processus, donc il existe 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 vous pouvez et devez les utiliser lors de la construction d'un processus. Ils aident à comprendre comment le processus sera construit, qui répondra aux bogues, qui signaler, qui signaler. Si vous souhaitez réaliser la phase initiale de construction de la sécurité de votre code, utilisez des solutions Open Source.

Comment intégrer cela si vous êtes au début de la route, vous n'avez rien: ni CI, ni Jenkins, ni TeamCity? Envisagez l'intégration dans le processus.

Intégration CVS

Si vous avez Bitbucket ou GitLab, vous pouvez faire l'intégration au niveau du système de versions simultanées .

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

Rétroaction. Bien sûr, une rétroaction est toujours nécessaire. Si vous avez simplement joué sur le plan de la sécurité, mettez-le dans une boîte et n'en parlez à personne, puis jetez un tas de bugs à la fin du mois - ce n'est ni bon ni bon.

Intégration avec la révision de code

Une fois, dans un certain nombre de projets importants, nous avons défini le réviseur par défaut de l'utilisateur technique AppSec. Selon que des erreurs ont été détectées dans le nouveau code ou s'il n'y a pas d'erreurs, le réviseur met le statut sur «accepter» ou «besoin de travail» sur la demande d'extraction - soit tout est OK, soit vous devez affiner et établir des liens vers exactement ce qu'il faut finaliser. Pour l'intégration avec la version qui va au prod, nous avons activé l'interdiction de fusion si le test IB n'est pas réussi. Nous l'avons inclus dans un examen manuel du code, et d'autres participants au processus ont vu les statuts de sécurité pour ce processus particulier.

Intégration SonarQube

Beaucoup ont une porte de qualité pour la qualité du code. La même chose ici - vous ne pouvez faire les mêmes portes que pour les outils SAST. Il y aura la même interface, la même porte de qualité, seulement elle sera appelée porte de sécurité . Et aussi, si vous avez un processus utilisant SonarQube, vous pouvez facilement tout y intégrer.

Intégration CI

Ici aussi, tout est assez simple:

• Au même niveau avec les autotests , les tests unitaires.
  
• Séparation par stades de développement : dev, test, prod. Différents ensembles de règles peuvent être inclus ou différentes conditions d'échec: arrêtez l'assemblage, n'arrêtez pas l'assemblage.
  
• Démarrage synchrone / asynchrone . Nous attendons la fin du test de sécurité ou n'attendons pas. Autrement dit, nous venons de les lancer et de passer à autre chose, puis nous recevons le statut 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 décidé que nous allons maintenant le numériser avec SAST'om - OK. Nous avons poussé ce projet dans SAST, il nous a donné 20 000 vulnérabilités, et avec une décision ferme, nous avons accepté que tout allait bien. 20 000 vulnérabilités sont notre devoir technique. Nous mettrons la dette dans une boîte, et nous ratifierons lentement et commencerons les bogues dans les trackers de défauts. Nous embauchons une entreprise, faisons tout nous-mêmes ou les champions de la sécurité nous aideront - et notre dette technique diminuera.

Et toutes les vulnérabilités nouvellement émergentes dans le nouveau code devraient être corrigées ainsi que les erreurs dans l'unité ou dans les autotests. Relativement parlant, l'assemblée a commencé, s'est éloignée, deux tests et deux tests de sécurité sont tombés. OK - ils sont allés, ont regardé ce qui s'est passé, corrigé une chose, corrigé la seconde, l'ont chassé la prochaine fois - tout va bien, il n'y a pas eu de nouvelles vulnérabilités, les tests n'ont pas échoué. Si cette tâche est plus approfondie et que vous devez bien la comprendre, ou la correction de vulnérabilités affecte de grandes couches de ce qui se cache sous le capot: elles ont apporté un bogue dans le traqueur de 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é, par la présence et le nombre de vulnérabilités dans le code.

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

Intégration de l'environnement de développement

Capacités d'intégration:

• Démarrage d'une analyse à partir de l'environnement de développement avant validation.
  
• Afficher les résultats.
  
• Analyse des résultats.
  
• Synchronisation avec le serveur.
  

Cela ressemble à obtenir des résultats du serveur.



Intellij IDEA , , . , Flow Graph . , — - .

Open Source

. Open Source — , , ?



, , , , , , . Application Security — Open Source .

Open Source — OSA

.

. , , - , CVE - - , . , , , .

. , , , . , . , , . , , .

, . , . — , , . , , . Open Source , , -. , , . , . .

:

• .
  
• .
  
• .
  
• .
  
• Docker-.
  

, Open Source.


— Dependency-Check OWASP. , , . , on-premise, . , , , , .

, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .

CI . , - : dev, test, prod. , , , - «critical» -, .

: Nexus JFrog.

. , , . , CVS.

CD. , — . .



Public Component Repositories — , . , trusted components. , . , , . , - , — .

• build' , , .
  
• trusted components.
  
• : war, jar, DL Docker- , .
  
• , : .
  

— DAST

, . . -, , , , : , , , , .

Open Source. DAST , Open Source , «» :

— , , .

, , — .

• \ .
  
• .
  
• .
  
• .
  
• .
  

, AppScan: , 3 — - ! , , AppScan — -, , , mailform -. :

— , ?! , !

. , -, . — , .

, . 10-15 , , , , .

, .



Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .

: .

mock-, — , .

• — .
  
• .
  
• — .
  

, . — , , OpenSource, - , , Waf .

.

, , , , -.

. , , . , , . , .



API, , , , — AppSec , .

, security- , , , , , . , , — Confluence , Jira -, / CI/CD.

Key Takeaways

. — . , , . — «» , — - high mega super critical, , .

— , . , , . DevSecOps, SecDevOps, .

, : , , , , . — . — .

.

, . , — . - , . , .

— Security Champions .

, , , - — . choisissez des outils en fonction des exigences de votre processus . Ne regardez pas ce que la communauté dit que cet outil est mauvais et que celui-ci est bon. C'est peut-être exactement le contraire sur votre produit.

Exigences relatives aux outils.

• Faible Faux Positif.
  
• Temps d'analyse adéquat.
  
• Facilité d'utilisation.
  
• Disponibilité des intégrations.
  
• Comprendre le développement de produits Roadmap.
  
• La possibilité de personnaliser les outils.
  

Le rapport de Yuri a été choisi comme l'un des meilleurs du DevOpsConf 2018. Pour vous familiariser avec des idées et des cas pratiques encore plus intéressants, venez à Skolkovo les 27 et 28 mai au DevOpsConf dans le cadre du festival RIT ++ . Mieux encore, si vous êtes prêt à partager votre expérience, demandez un rapport avant le 21 avril.