Angst und Hass in DevSecOps

Wir hatten 2 Code-Analyzer, 4 Werkzeuge für dynamisches Testen, eigene Bastelarbeiten und 250 Skripte. Nicht dass all dies im aktuellen Prozess notwendig war, aber wenn man einmal mit der Implementierung von DevSecOps begonnen hat, sollte man es auch zu Ende bringen.

Quelle. Die Charaktere wurden von Justin Roiland und Dan Harmon kreiert.

Was ist SecDevOps? Und DevSecOps? Wo liegen die Unterschiede? Was ist Application Security? Warum funktioniert der klassische Ansatz nicht mehr? Auf all diese Fragen hat er Antworten. Juri Schabalin von Swordfish Security. Juri wird ausführlich auf alles eingehen und die Probleme des Übergangs vom klassischen Modell der Application Security zum DevSecOps-Prozess erläutern: wie man den Prozess der sicheren Softwareentwicklung korrekt in den DevOps-Prozess integriert, ohne dabei etwas kaputt zu machen, welche grundlegenden Phasen der Sicherheitstests durchlaufen werden sollten, welche Werkzeuge verwendet werden können, wie sie sich unterscheiden und wie sie richtig konfiguriert werden, um Fallstricke zu vermeiden.

Über den Sprecher: Juri Schabalin ist Chief Security Architect bei der Swordfish Security. Ist verantwortlich für die Implementierung von SSDL und für die gesamte Integration von Analysetools in ein einheitliches Entwicklungs- und Test-Ökosystem. 7 Jahre Erfahrung in der Informationssicherheit. Hat bei Alfa-Bank, Sberbank und Positive Technologies gearbeitet, einem Unternehmen, das Software entwickelt und Dienstleistungen anbietet. Sprecher auf internationalen Konferenzen wie ZerONights, PHDays, RISSPA, OWASP.

Anwendungssicherheit: Worum geht es?

Anwendungssicherheit ist ein Bereich der Sicherheit, der sich mit der Sicherheit von Anwendungen befasst. Er umfasst nicht die Infrastruktur oder Netzwerksicherheit, sondern konzentriert sich darauf, was wir schreiben und woran die Entwickler arbeiten – das sind die Schwachstellen und Verwundbarkeiten der Anwendungen selbst.

Bereich SDL oder SDLC — Sicherheitsentwicklungslebenszyklus wurde von Microsoft entwickelt. In der Abbildung sehen Sie das kanonische Modell des SDLC, dessen Hauptaufgabe es ist, die Sicherheit in jedem Schritt der Entwicklung zu berücksichtigen, von den Anforderungen bis zur Veröffentlichung und dem Produktionsstart. Microsoft erkannte, dass es in der Industrie zu viele Bugs gibt, deren Anzahl steigt und dass man etwas dagegen unternehmen muss. Daher wurde dieser Ansatz vorgeschlagen, der zum kanonischen Modell wurde.

Application Security und SSDL zielen nicht darauf ab, Schwachstellen zu entdecken, wie häufig angenommen, sondern darauf, deren Entstehung zu verhindern. Im Laufe der Zeit wurde der klassische Ansatz von Microsoft verbessert und vertieft, um ein detaillierteres Verständnis zu ermöglichen.

Der klassische SDLC ist stark in verschiedenen Methoden detailliert — OpenSAMM, BSIMM, OWASP. Die Methoden unterscheiden sich, sind jedoch im Großen und Ganzen ähnlich.

Building Security In Maturity Model

Es liegt mir am meisten am Herzen BSIMM — Building Security In Maturity Model. Die Grundlage der Methodik ist die Aufteilung des Application Security Prozesses in 4 Domänen: Governance, Intelligence, SSDL Touchpoints und Deployment. Jede Domäne umfasst 12 Praktiken, die in Form von 112 Aktivitäten dargestellt werden.

Jede der 112 Aktivitäten hat 3 Reifegrade: initial, mittel und fortgeschritten. Alle 12 Praktiken können modular studiert werden, um wichtige Aspekte auszuwählen, zu verstehen, wie sie implementiert werden können, und schrittweise Elemente wie statische und dynamische Codeanalyse oder Code-Reviews hinzuzufügen. Erstellen Sie einen Plan und arbeiten Sie ruhig im Rahmen der Umsetzung der gewählten Aktivitäten.

Warum DevSecOps

DevOps ist ein umfassender Prozess, der die Sicherheitsaspekte mit einbezieht.

Ursprünglich DevOps Die Sicherheitsüberprüfungen waren anfänglich nicht optimal organisiert. In der Praxis war die Größe der Sicherheitsgruppen deutlich geringer als heute, und sie agierten eher als Kontroll- und Aufsichtsinstanz, die Anforderungen stellt und die Qualität des Produkts nach der Veröffentlichung überprüft. Dies ist der klassische Ansatz, bei dem Sicherheitsgruppen von der Entwicklung getrennt waren und nicht am Prozess teilnahmen.

Das Hauptproblem besteht darin, dass die Informationssicherheit getrennt von der Entwicklung ist. Üblicherweise gibt es einen Sicherheitsrahmen, der aus 2-3 großen und teuren Werkzeugen besteht. Alle sechs Monate wird der Quellcode oder die Anwendung geliefert, die geprüft werden müssen, und einmal im Jahr finden Pentestsstatt. Das alles führt dazu, dass sich die Markteinführungsfristen verzögern und Entwickler mit einer riesigen Anzahl von Schwachstellen aus automatisierten Tools konfrontiert werden. All das lässt sich nicht bewältigen und beheben, da die Ergebnisse aus den letzten sechs Monaten noch nicht ausgewertet wurden und bereits eine neue Charge ansteht.

Im Verlauf unserer Tätigkeit haben wir festgestellt, dass die Sicherheitsanforderungen in allen Bereichen und Branchen verstanden haben, dass es an der Zeit ist, sich anzupassen und gemeinsam mit der Entwicklung aktiv zu werden – in Agile. Das DevSecOps-Paradigma passt hervorragend zu agilen Entwicklungsmethoden, zur Implementierung, zum Support und zur Beteiligung an jedem Release und jeder Iteration.

Der Übergang zu DevSecOps

Das wichtigste Wort im Security Development Lifecycle ist „Prozess“. Sie sollten das verstehen, bevor Sie darüber nachdenken, Werkzeuge zu kaufen.

Es reicht nicht aus, Werkzeuge einfach in den DevOps-Prozess einzufügen – wichtig ist die Interaktion und das Verständnis zwischen den Beteiligten.

Menschen sind wichtiger als Werkzeuge

Häufig beginnt die Planung eines sicheren Entwicklungsprozesses mit der Auswahl und dem Kauf eines Werkzeugs, und endet mit dem Versuch, das Werkzeug in den bestehenden Prozess zu integrieren, was häufig nicht gelingt. Das führt zu unerfreulichen Ergebnissen, da jedes Werkzeug seine eigenen Besonderheiten und Einschränkungen hat.

Ein häufiges Szenario ist, dass die Sicherheitsabteilung ein gutes, teures Tool mit umfangreichen Funktionen auswählt und dann zu den Entwicklern kommt, um es im Prozess zu integrieren. Doch das funktioniert nicht – der Prozess ist so gestaltet, dass die Einschränkungen des bereits gekauften Tools nicht in das aktuelle Paradigma passen.

Beginnen Sie damit, das gewünschte Ergebnis und den Ablauf des Prozesses zu beschreiben. Dies hilft, die Rollen des Tools und der Sicherheit im Prozess klarzustellen.

Starten Sie mit dem, was bereits verwendet wird.

Bevor Sie teure Tools kaufen, schauen Sie sich an, was Sie bereits haben. Jedes Unternehmen hat Sicherheitsanforderungen, die an die Entwicklung gestellt werden, sowie Prüfungen und Penetrationstests – warum nicht alles in eine verständliche und für alle nützliche Form bringen?

In der Regel sind Anforderungen ein Papierdokument, das im Regal steht. Es gab einen Fall, in dem wir in ein Unternehmen kamen, um die Prozesse zu betrachten, und nach den Sicherheitsanforderungen für die Software fragten. Der zuständige Spezialist suchte lange:

— Moment, irgendwo in meinen Notizen war der Weg, wo dieses Dokument aufbewahrt wird.

Letztendlich erhielten wir das Dokument nach einer Woche.

Für Anforderungen, Prüfungen und Ähnliches erstellen Sie beispielsweise eine Seite auf Confluence — das ist für alle praktisch.

Es ist einfacher, das Vorhandene umzustrukturieren und als Ausgangspunkt zu nutzen.

Nutzen Sie Security Champions

In der Regel gibt es in einem durchschnittlichen Unternehmen mit 100-200 Entwicklern einen Sicherheitsexperten, der mehrere Funktionen ausübt und physisch nicht in der Lage ist, alles zu überprüfen. Selbst wenn er sein Bestes gibt, kann er nicht den gesamten Code überprüfen, den die Entwickler generieren. Für solche Fälle wurde das Konzept entwickelt — Security Champions.

Security Champions sind Personen innerhalb des Entwicklungsteams, die sich für die Sicherheit Ihres Produkts einsetzen.

Ein Security Champion ist der Ansprechpartner im Entwicklungsteam und ein Sicherheitsevangelist in einer Person.

Normalerweise, wenn ein Sicherheitsexperte in ein Entwicklungsteam kommt und auf einen Fehler im Code hinweist, erhält er erstaunte Antworten:

— Und wer sind Sie? Ich sehe Sie zum ersten Mal. Bei mir ist alles in Ordnung — mein Mentor hat bei der Code-Überprüfung "apply" gesetzt, wir machen weiter!

Das ist eine typische Situation, denn die Entwickler haben viel mehr Vertrauen in ihre unmittelbaren Kollegen oder Vorgesetzten, mit denen sie ständig in Kontakt stehen und Code-Reviews durchführen. Wenn anstelle des Sicherheitsexperten ein Security Champion auf einen Fehler und seine Konsequenzen hinweist, hat dessen Wort mehr Gewicht.

Zudem kennen Entwickler ihren Code besser als jeder Sicherheitsexperte. Für jemanden, der in der Regel an mindestens fünf Projekten in einem statischen Analysewerkzeug arbeitet, ist es oft schwierig, sich an alle Details zu erinnern. Security Champions hingegen kennen ihr Produkt: Sie wissen, wie die verschiedenen Komponenten interagieren und worauf sie zuerst achten müssen – sie sind effizienter.

Denken Sie darüber nach, Security Champions einzuführen und den Einfluss Ihres Sicherheitsteams zu erweitern. Es ist auch für den Champion selbst von Vorteil: berufliche Weiterentwicklung in einem neuen Bereich, Erweiterung des technischen Horizonts, Verbesserung technischer, organisatorischer und Führungsfähigkeiten sowie Steigerung des Marktwerts. Es ist eine Art soziale Ingenieurskunst, Ihre 'Augen' im Entwicklungsteam.

Testphasen

Paradigma 20 zu 80 sagt, dass 20% des Aufwands 80% des Ergebnisses bringen. Diese 20% sind Praktiken der Analyse von Anwendungen, die automatisiert werden können und sollten. Beispiele für solche Aktivitäten sind statische Analyse — SAST, dynamische Analyse — DAST, und Kontrolle von Open Source. Ich werde näher auf die Aktivitäten eingehen und auch auf die Werkzeuge, welche Besonderheiten wir normalerweise bei deren Implementierung im Prozess berücksichtigen und wie man dies richtig umsetzt.

Wesentliche Probleme der Werkzeuge

Ich werde die für alle Werkzeuge relevanten Probleme herausstellen, die Aufmerksamkeit erfordern. Ich werde sie im Detail erläutern, um Wiederholungen zu vermeiden.

Lange Analysezeiten. Wenn von der Commits bis zur Production 30 Minuten für alle Tests und den Build benötigt werden, wird die Überprüfung der Informationssicherheit einen Tag in Anspruch nehmen. Niemand möchte den Prozess dadurch verlangsamen. Berücksichtigen Sie dieses Merkmal und ziehen Sie Ihre Schlüsse.

Hoher Anteil an False Negatives oder False Positives. Alle Produkte sind unterschiedlich, alle verwenden unterschiedliche Frameworks und ihren eigenen Schreibstil. Je nach Codebasis und Technologien können die Werkzeuge unterschiedliche Werte für False Negatives und False Positives anzeigen. Daher sollten Sie darauf achten, was genau in Ihrem Unternehmen und für Ihre Anwendungen werden gute und zuverlässige Ergebnisse zeigen.

Keine Integrationen mit bestehenden Tools.. Betrachten Sie Tools aus der Perspektive der Integrationen mit dem, was Sie bereits verwenden. Wenn Sie beispielsweise Jenkins oder TeamCity haben, überprüfen Sie die Integration der Tools genau mit dieser Software und nicht mit GitLab CI, das Sie nicht verwenden.

Fehlende oder übermäßig komplexe Anpassungsmöglichkeiten. Wenn das Tool keine API hat, wozu ist es dann gut? Alles, was im Interface möglich ist, sollte auch über die API zugänglich sein. Idealerweise sollte das Tool die Möglichkeit zur Anpassung von Prüfungen bieten.

Kein Entwicklungs-Roadmap für das Produkt. Die Entwicklung steht nicht still; wir nutzen ständig neue Frameworks und Funktionen, überarbeiten alten Code in neue Programmiersprachen. Wir möchten sicherstellen, dass das Tool, das wir kaufen, neue Frameworks und Technologien unterstützt. Daher ist es wichtig zu wissen, dass das Produkt einen echten und klaren Roadmap der Entwicklung hat.

Besonderheiten des Prozesses.

Berücksichtigen Sie neben den Funktionen der Werkzeuge auch die Besonderheiten des Entwicklungsprozesses. Ein typischer Fehler ist, die Entwicklung zu stören. Lassen Sie uns betrachten, welche weiteren Besonderheiten zu beachten sind und worauf das Sicherheitsteam achten sollte.

Um Termine für Entwicklung und Release nicht zu gefährden, erstellen Sie verschiedene Regeln und verschiedene Showstoppers — Kriterien, die den Prozess der Zusammenstellung bei Vorhandensein von Schwachstellen stoppen — für verschiedene Umgebungen.Zum Beispiel verstehen wir, dass der aktuelle Branch in die Entwicklungsumgebung oder UAT geht, daher stoppen wir nicht und sagen nicht:

— Sie haben hier Schwachstellen, Sie kommen nicht weiter!

An dieser Stelle ist es wichtig, den Entwicklern zu sagen, dass es Sicherheitsprobleme gibt, auf die sie achten sollten.

Das Vorhandensein von Schwachstellen ist kein Hindernis für weitere Tests: ob manuelle, Integration oder manuelle Tests. Auf der anderen Seite müssen wir die Sicherheit des Produkts irgendwie erhöhen, und wir möchten nicht, dass die Entwickler ignorieren, was die Sicherheitsteams finden. Daher gehen wir manchmal folgendermaßen vor: Wenn auf dem Stand, wenn wir in die Entwicklungsumgebung ausrollen, benachrichtigen wir einfach die Entwicklung:

— Bitte, falls Sie Probleme haben, achten Sie darauf.

In der UAT-Phase zeigen wir wieder Warnungen zu Sicherheitsanfälligkeiten, und in der Produktionsphase sagen wir:

— Wir haben Sie bereits mehrmals gewarnt, Sie haben nichts unternommen – damit werden wir Sie nicht freigeben.

Wenn es um Code und Dynamik geht, sollten wir nur über Sicherheitsanfälligkeiten der Funktionen und des Codes informieren, die gerade in dieser Funktion geschrieben wurden. Wenn ein Entwickler einen Button um 3 Pixel verschoben hat und wir ihm mitteilen, dass er eine SQL-Injektion hat, die dringend behoben werden muss – das ist nicht richtig. Schauen Sie sich nur an, was jetzt geschrieben wurde, und die Änderungen, die in die Anwendung kommen.

Nehmen wir an, wir haben einen funktionalen Defekt – etwas, das die Anwendung nicht korrekt macht: Geld wird nicht überwiesen, beim Klicken auf einen Button wird nicht zur nächsten Seite navigiert oder das Produkt wird nicht geladen. Sicherheitsdefekte – sind ebenso Defekte, jedoch nicht im Hinblick auf die Funktion der Anwendung, sondern auf die Sicherheit.

Nicht alle Probleme der Softwarequalität sind Sicherheitsprobleme. Aber alle Sicherheitsprobleme hängen mit der Softwarequalität zusammen. Sherif Mansour, Expedia.

Da alle Sicherheitslücken ebenso wie andere Fehler betrachtet werden, sollten sie dort sein, wo auch alle Entwicklungsfehler zu finden sind. Vergessen Sie also Berichte und gruselige PDFs, die niemand liest.

Als ich für ein Softwareentwicklungsunternehmen tätig war, erhielt ich einen Bericht von den statischen Analysetools. Ich öffnete ihn, war entsetzt, machte mir einen Kaffee, blätterte durch 350 Seiten, schloss ihn und machte mit meiner Arbeit weiter. Umfangreiche Berichte sind tote Berichte.Normalerweise verschwinden sie irgendwo, E-Mails werden gelöscht, vergessen, verlieren sich oder das Unternehmen sagt, es akzeptiere die Risiken.

Was tun? Die bestätigten Fehler, die gefunden wurden, wandeln wir einfach in ein entwicklerfreundliches Format um, indem wir sie zum Beispiel in den Backlog in Jira einfügen. Wir priorisieren die Fehler und beheben sie der Rangfolge nach, ebenso wie funktionale Fehler und Testfehler.

Statische Analyse – SAST

Dies ist eine Analyse des Codes auf Sicherheitsanfälligkeiten, aber es ist nicht dasselbe wie SonarQube. Wir überprüfen nicht nur anhand von Mustern oder Stilen. Bei der Analyse kommen verschiedene Ansätze zur Anwendung: anhand des Schwachstellenschemas, basierend auf DataFlow, sowie durch die Analyse von Konfigurationsdateien. Dies betrifft alles, was direkt mit dem Code zu tun hat.

Vorteile des Ansatzes: Identifikation von Schwachstellen im Code in einer frühen Entwicklungsphase, wenn es noch keine Stände und kein fertiges Tool gibt, und die Möglichkeit des inkrementellen Scannens: Scannen des Codeabschnitts, der sich geändert hat, und nur der Funktion, an der wir gerade arbeiten, was die Scandauer verkürzt.

Nachteile — es fehlt die Unterstützung für die erforderlichen Programmiersprachen.

Notwendige Integrationen, die meiner subjektiven Meinung nach in den Tools vorhanden sein sollten:

• Integrationswerkzeuge: Jenkins, TeamCity und Gitlab CI.
• Entwicklungsumgebung: IntelliJ IDEA, Visual Studio. Es ist für den Entwickler bequemer, nicht in eine unverständliche Oberfläche, die zusätzlich zu merken ist, zu navigieren, sondern direkt an seinem Arbeitsplatz in seiner eigenen Entwicklungsumgebung alle notwendigen Integrationen und die gefundenen Schwachstellen zu sehen.
• Code-Review: SonarQube und manuelle Überprüfung.
• Fehlerverfolgungssysteme: Jira und Bugzilla.

Auf dem Bild sind einige der besten Vertreter der statischen Analyse zu sehen.

Wichtig sind nicht die Werkzeuge, sondern der Prozess, daher gibt es Open-Source-Lösungen, die ebenfalls gut geeignet sind, um den Prozess zu erproben.

SAST Open Source wird zwar nicht eine Vielzahl von Schwachstellen oder komplexe Datenflüsse finden, aber bei der Entwicklung des Prozesses können sie sinnvoll eingesetzt werden. Sie helfen zu verstehen, wie der Prozess aufgebaut wird, wer für Bugs verantwortlich ist, wer sie meldet und wer darüber Bericht erstattet. Wenn Sie den ersten Schritt zur Sicherstellung der Sicherheit Ihres Codes gehen möchten, nutzen Sie Open Source Lösungen.

Wie lässt sich das integrieren, wenn Sie am Anfang stehen und nichts haben: kein CI, keinen Jenkins, kein TeamCity? Lassen Sie uns die Integrationen in den Prozess betrachten.

Integration auf CVS-Ebene

Wenn Sie Bitbucket oder GitLab haben, kann eine Integration auf dieser Ebene erfolgen. Concurrent Versions System.

Nach Ereignis – Pull-Request, Commit. Sie scannen den Code und zeigen im Build-Status an, ob der Sicherheitstest bestanden wurde oder nicht.

Feedback. Natürlich ist Feedback immer notwendig. Wenn Sie lediglich etwas im Bereich Sicherheit durchgeführt haben, es in eine Box gelegt und niemandem davon erzählt haben, und dann am Ende des Monats eine Menge Bugs auftauchen, ist das nicht richtig und auch nicht gut.

Integration mit dem Code-Review-System

Einmal haben wir in einer Reihe wichtiger Projekte den technischen Benutzer AppSec als standardmäßigen Reviewer eingesetzt. Je nachdem, ob Fehler im neuen Code entdeckt werden oder nicht, setzt der Reviewer im Pull-Request den Status auf "akzeptiert" oder "muss überarbeitet werden" – entweder alles in Ordnung oder es muss nachgebessert werden mit Hinweisen, was genau verbessert werden sollte. Für die Integration mit der Version, die in Produktion geht, haben wir das Merge-Verbot aktiviert, wenn der Sicherheitstest nicht bestanden ist. Dies haben wir in das manuelle Code-Review eingebaut, und die anderen Teilnehmer des Prozesses konnten die Sicherheitsstatus für diesen spezifischen Prozess einsehen.

Integration mit SonarQube

Viele haben Qualitätsschwellen für die Qualität des Codes. Hier ist es dasselbe – man kann die gleichen Schwellen nur für SAST-Tools erstellen. Es wird die gleiche Schnittstelle sein, die gleiche Qualitätsschwelle, nur wird sie Sicherheitsschwellegenannt. Und wenn Sie einen Prozess mit SonarQube eingerichtet haben, können Sie alles ganz einfach integrieren.

Integration auf CI-Ebene

Hier ist auch alles recht einfach:

• Auf derselben Ebene wie die automatisierten Tests, Unit-Tests.
• Aufteilung nach Entwicklungsphasen: dev, test, prod. Verschiedene Regelsets oder unterschiedliche Fehlermeldungen können aktiviert werden: Wir stoppen den Build oder wir stoppen ihn nicht.
• Synchroner/Asynchroner Start. Wir warten auf den Abschluss der Sicherheitsüberprüfungen oder wir warten nicht. Das heißt, wir haben sie einfach gestartet und machen weiter, und später erhalten wir den Status, dass alles gut oder schlecht ist.

Das alles ist in einer idealen, rosaroten Welt. In der realen Welt gibt es das nicht, aber wir streben danach. Das Ergebnis der Sicherheitsüberprüfungen sollte mit den Ergebnissen der Unit-Tests vergleichbar sein.

Zum Beispiel haben wir ein großes Projekt genommen und entschieden, dass wir es jetzt mit SAST scannen werden – in Ordnung. Wir haben dieses Projekt in SAST geladen und es hat uns 20.000 Schwachstellen ausgegeben, und durch eine willentliche Entscheidung haben wir angenommen, dass alles gut ist. 20.000 Schwachstellen sind unsere technische Schuld. Diese Schuld stecken wir in eine Box, und wir werden sie nach und nach abarbeiten und Bugs in die Fehlerverfolgung einpflegen. Wir stellen eine Firma ein, machen alles selbst oder bekommen Unterstützung von Security Champions – und die technische Schuld wird abnehmen.

Alle neu auftretenden Schwachstellen im neuen Code müssen ebenso behoben werden wie Fehler in Unit- oder Autotests. Wenn die Build läuft, werden zwei Tests und zwei Sicherheitstests durchgeführt. In Ordnung – wir schauen uns an, was passiert ist, korrigieren das eine und das andere, beim nächsten Mal läuft alles gut, keine neuen Schwachstellen und alle Tests bestehen. Wenn die Aufgabe komplexer ist und eine tiefere Analyse erfordert, oder wenn die Behebung von Schwachstellen große Teile des zugrundeliegenden Systems betrifft, wird ein Bug im Fehlertracker erstellt, priorisiert und behoben. Leider ist die Welt nicht perfekt und Tests fallen manchmal aus.

Beispiel für ein Security Gate – analog zum Quality Gate, basierend auf der Anzahl und Art der Schwachstellen im Code.

Integration mit SonarQube – das Plugin wird installiert, alles ist sehr praktisch und funktioniert hervorragend.

Integration mit der Entwicklungsumgebung

Integrationsmöglichkeiten:

• Start des Scanvorgangs aus der Entwicklungsumgebung noch vor dem Commit.
• Überprüfung der Ergebnisse.
• Analyse der Ergebnisse.
• Synchronisation mit dem Server.

So sieht die Ergebniserfassung vom Server aus.

In unserer Entwicklungsumgebung Intellij IDEA Es wird einfach ein zusätzlicher Punkt angezeigt, der mitteilt, dass während des Scannens bestimmte Schwachstellen gefunden wurden. Man kann sofort den Code korrigieren, Empfehlungen einsehen und Flow Graph. All dies ist am Arbeitsplatz des Entwicklers angeordnet, was sehr praktisch ist – man muss nicht durch andere Links navigieren und etwas zusätzlich überprüfen.

Open Source

Das ist mein Lieblingsthema. Alle nutzen Open-Source-Bibliotheken – warum sollte man eine Menge von Hacks und selbstgebauten Lösungen schreiben, wenn man eine fertige Bibliothek verwenden kann, in der alles bereits umgesetzt ist?

Natürlich ist das so, aber Bibliotheken werden auch von Menschen geschrieben, enthalten bestimmte Risiken und haben ebenfalls Schwachstellen, über die gelegentlich oder ständig berichtet wird. Daher gibt es den nächsten Schritt in der Anwendungssicherheit – die Analyse von Open-Source-Komponenten.

Open Source Analyse – OSA

Das Tool umfasst drei große Phasen.

Suche nach Schwachstellen in den Bibliotheken. Zum Beispiel weiß das Tool, dass wir eine bestimmte Bibliothek verwenden und dass in CVE Oder es gibt in Bugtrackern irgendwelche Schwachstellen, die zu dieser Version der Bibliothek gehören. Bei dem Versuch, sie zu verwenden, gibt das Tool eine Warnung aus, dass die Bibliothek anfällig ist, und empfiehlt, eine andere Version zu verwenden, in der keine Schwachstellen vorhanden sind.

Analyse der Lizenzkonformität. Bei uns ist das bisher nicht besonders populär, aber wenn Sie mit dem Ausland arbeiten, kann es dort gelegentlich zu Problemen kommen, wenn Sie Komponenten mit offenem Quellcode verwenden, die Sie nicht nutzen oder modifizieren dürfen. Gemäß der Lizenzpolitik der Bibliothek dürfen wir das nicht tun. Oder, wenn wir sie modifiziert haben und verwenden, müssen wir unseren Code veröffentlichen. Natürlich möchte niemand den Code seiner Produkte veröffentlichen, aber es gibt Möglichkeiten, sich auch davor zu schützen.

Analyse von Komponenten, die in der Industrie genutzt werden. Stellen Sie sich vor, wir haben endlich die Entwicklung abgeschlossen und die letzte Version unseres Mikrodienstes produktiv veröffentlicht. Er läuft dort hervorragend – eine Woche, einen Monat, ein Jahr. Wir führen keine Zusammenführungen durch, keine Sicherheitsprüfungen, scheinbar ist alles gut. Doch plötzlich, zwei Wochen nach der Veröffentlichung, tritt eine kritische Schwachstelle in der Open-Source-Komponente auf, die wir genau in dieser Version in der Produktionsumgebung verwenden. Wenn wir nicht dokumentieren, was und wo wir verwenden, werden wir diese Schwachstelle einfach nicht bemerken. Einige Tools bieten die Möglichkeit, Schwachstellen in den Bibliotheken zu überwachen, die derzeit in der Produktion genutzt werden. Das ist sehr nützlich.

Möglichkeiten:

• Verschiedene Richtlinien für verschiedene Entwicklungsphasen.
• Überwachung von Komponenten in der Produktionsumgebung.
• Kontrolle von Bibliotheken im Unternehmensnetzwerk.
• Unterstützung verschiedener Build-Systeme und Programmiersprachen.
• Analyse von Docker-Images.

Einige Beispiele für führende Unternehmen, die Open-Source-Analyse betreiben.

Der einzige kostenlose unter ihnen ist Dependency-Check von OWASP. Es kann in den frühen Phasen aktiviert werden, um zu sehen, wie es funktioniert und was es unterstützt. Grundsätzlich handelt es sich um Cloud-Produkte oder On-Premise-Lösungen, aber selbst mit ihrer Basis werden sie dennoch ins Internet gesendet. Sie senden nicht Ihre Bibliotheken, sondern Hashes oder eigene Werte, die berechnet werden, sowie Fingerabdrücke an ihren Server, um Informationen über vorhandene Sicherheitslücken zu erhalten.

Integration in den Prozess

Kontrolle der Bibliotheken im Perimeter, die aus externen Quellen heruntergeladen werden. Wir haben externe und interne Repositories. Zum Beispiel läuft innerhalb von Event Central Nexus, und wir möchten sicherstellen, dass innerhalb unseres Repositories keine Sicherheitslücken mit dem Status 'kritisch' oder 'hoch' vorhanden sind. Es ist möglich, das Proxieren mithilfe des Nexus Firewall Lifecycle-Tools so einzurichten, dass solche Sicherheitslücken blockiert und nicht ins interne Repository gelangen.

Integration in CI. Auf der gleichen Ebene wie Auto-Tests, Unit-Tests und Phasentrennung: dev, test, prod. In jeder Phase können beliebige Bibliotheken heruntergeladen und verwendet werden. Wenn jedoch etwas Kritisches mit dem Status „critical“ vorhanden ist, sollten die Entwickler möglicherweise darauf achten, bevor es in die Produktion geht.

Integration mit Artefakt-Repositorys: Nexus und JFrog.

Integration in die Entwicklungsumgebung. Die Tools, die Sie wählen, sollten eine Integration mit Entwicklungsumgebungen haben. Der Entwickler sollte von seinem Arbeitsplatz aus Zugriff auf die Scannergebnisse haben oder die Möglichkeit, den Code selbst auf Schwachstellen zu überprüfen, bevor er ihn in das CVS committet.

Integration in CD. Das ist eine tolle Funktion, die ich sehr mag und über die ich bereits gesprochen habe – die Überwachung neuer Schwachstellen in der Produktionsumgebung. So funktioniert es.

Wir haben Öffentliche Komponenten-Repositorys — einige Werkzeuge von außen und unser internes Repository. Wir möchten, dass dort nur vertrauenswürdige Komponenten vorhanden sind. Bei der Proxy-Anfrage überprüfen wir, dass die heruntergeladene Bibliothek keine Sicherheitsanfälligkeiten aufweist. Wenn sie unter bestimmte von uns festgelegte Richtlinien fällt, die wir unbedingt mit der Entwicklung abstimmen, wird sie nicht heruntergeladen und es erfolgt eine Rückmeldung zur Verwendung einer anderen Version. Wenn die Bibliothek also tatsächlich etwas Kritisches und Schlechtes enthält, erhält der Entwickler bereits beim Installationsschritt nicht die Bibliothek – er muss eine höhere oder niedrigere Version verwenden.

• Bei jedem Build überprüfen wir, dass niemand etwas Schlechtes geschmuggelt hat, dass alle Komponenten sicher sind und niemand etwas Gefährliches auf einem USB-Stick mitgebracht hat.
• In unserem Repository befinden sich nur vertrauenswürdige Komponenten.
• Bei der Bereitstellung prüfen wir erneut das Paket: war, jar, DL oder das Docker-Image, ob es den Richtlinien entspricht.
• Bei der Markteinführung überwachen wir, was in der Produktionsumgebung passiert: ob kritische Sicherheitsanfälligkeiten auftauchen oder nicht.

Dynamische Analyse – DAST

Dynamische Analysetools unterscheiden sich grundlegend von allem, was zuvor gesagt wurde. Sie simulieren die Benutzerinteraktion mit der Anwendung. Bei einer Webanwendung senden wir Anfragen, die das Handeln eines Nutzers nachahmen, klicken auf Buttons und übermitteln fiktive Daten aus einem Formular: Anführungszeichen, Klammern, Zeichen in verschiedenen Kodierungen, um zu beobachten, wie die Anwendung funktioniert und externe Daten verarbeitet.

Das gleiche System ermöglicht es, gängige Sicherheitsanfälligkeiten in Open Source zu überprüfen. Da DAST nicht weiß, welche Open Source Software wir verwenden, schickt es einfach 'schadhafte' Muster und analysiert die Antworten des Servers:

— Aha, hier gibt es ein Deserialisierungsproblem, hier nicht.

Das birgt erhebliche Risiken, denn wenn Sie diesen Sicherheitstest auf demselben Stand durchführen, mit dem die Tester arbeiten, können unangenehme Dinge passieren.

• Hohe Belastung der Netzwerkserveranwendung.
• Keine Integrationen.
• Möglichkeit zur Anpassung der Einstellungen der zu analysierenden Anwendung.
• Keine Unterstützung der erforderlichen Technologien.
• Komplexität der Konfiguration.

Wir hatten eine Situation, in der wir endlich AppScan gestartet haben: Wir haben lange um den Zugang zur Anwendung gekämpft, drei Konten erhalten und waren begeistert – endlich konnten wir alles überprüfen! Wir haben den Scan gestartet und das Erste, was AppScan tat, war, in das Administrationsmenü zu gehen, alle Schaltflächen zu drücken, die hälften der Daten zu ändern und schließlich den Server mit seinen-mailform-Anfragen zu killen. mailform-Anfragen. Die Entwicklung mit dem Testing sagte:

– Leute, macht ihr Witze?! Wir haben euch die Konten gegeben, und ihr habt die Testumgebung kaputtgemacht!

Berücksichtigen Sie mögliche Risiken. Idealerweise sollte eine separate Testumgebung für die IT-Sicherheit vorbereitet werden, die zumindest irgendwie vom restlichen Umfeld isoliert ist, und das Überprüfen des Administrators sollte idealerweise manuell erfolgen. Dies ist ein Pen-Test – die verbleibenden Prozentsätze an Aufwand, die wir jetzt nicht betrachten.

Es ist zu beachten, dass man dies als eine Art Lasttest verwenden kann. In der ersten Phase kann man den dynamischen Scanner mit 10-15 Threads aktivieren und schauen, was passiert, aber normalerweise, wie die Praxis zeigt, kommt nichts Gutes dabei heraus.

Einige Ressourcen, die wir normalerweise verwenden.

Es ist erwähnenswert Burp Suite — ist das „Schweizer Taschenmesser“ für jeden Sicherheitsspezialisten. Es wird von allen verwendet und ist sehr benutzerfreundlich. Jetzt ist eine neue Demoversion der Enterprise Edition erschienen. Früher war es nur ein Standalone-Tool mit Plugins, jetzt entwickeln die Entwickler endlich einen großen Server, von dem aus mehrere Agenten verwaltet werden können. Das ist großartig, ich empfehle es auszuprobieren.

Integration in den Prozess

Die Integration funktioniert ausreichend gut und einfach: Start des Scans nach erfolgreicher Installation der Anwendung auf dem Stand und Scan nach erfolgreichem Abschluss der Integrationstests.

Wenn die Integrationen nicht funktionieren oder Platzhalter und Mock-Funktionen vorhanden sind, ist es sinnlos und nutzlos – egal welches Muster wir senden, der Server wird trotzdem identisch antworten.

• Idealerweise ist ein separater Stand für Tests erforderlich.
• Notieren Sie sich die Anmeldereihenfolge vor Beginn der Tests.
• Das Testen des Administrationssystems erfolgt ausschließlich manuell.

Prozess

Ein allgemeiner Überblick über den Prozess und die Funktionsweise jedes einzelnen Werkzeugs. Jedes Tool ist unterschiedlich – bei dem einen funktioniert die dynamische Analyse besser, beim anderen die statische, bei einem dritten die Open-Source-Analyse, Penetrationstests oder etwas ganz anderes, wie zum Beispiel Ereignisse. WAF.

Jeder Prozess benötigt Kontrolle.

Um zu verstehen, wie der Prozess funktioniert und wo Verbesserungen möglich sind, müssen Metriken aus allen erreichbaren Bereichen gesammelt werden, einschließlich Produktionsmetriken, Metriken aus den Werkzeugen und aus Defekt-Trackern.

Jede Art von Daten ist nützlich. Man sollte die verschiedenen Perspektiven betrachten, um zu sehen, wo ein bestimmtes Werkzeug am besten eingesetzt wird und wo der Prozess konkret schwächelt. Vielleicht sollte man auch die Reaktionszeit der Entwicklung betrachten, um herauszufinden, wo der Prozess zeitlich optimiert werden kann. Je mehr Daten vorhanden sind, desto mehr Perspektiven können von oberen Ebenen bis zu den Details jedes Prozesses aufgebaut werden.

Da alle statischen und dynamischen Analysatoren ihre eigenen APIs, ihre eigenen Ausführungsarten und Prinzipien haben – einige haben Scheduler, andere nicht – erstellen wir ein Tool. AppSec Orchestrator, die einen einheitlichen Zugang zu allen Prozessen ermöglicht und die Verwaltung von einem einzigen Punkt aus erlaubt.

Für Manager, Entwickler und Sicherheitsingenieure gibt es einen zentralen Zugang, von dem aus sie sehen können, was läuft, Einstellungen vornehmen und Scans starten, die Scan-Ergebnisse abrufen und Anforderungen einreichen können. Wir versuchen, von Papierkram wegzukommen und alles in ein verständliches Format zu übertragen, das die Entwicklung nutzt – Seiten auf Confluence mit Status und Metriken, Defekte in Jira oder in verschiedenen Fehlerverfolgungssystemen, oder durch Integration in den synchronen/asynchronen Prozess im CI/CD.

Wichtige Erkenntnisse

Werkzeuge sind nicht alles. Zuerst den Prozess durchdenken – dann die Werkzeuge implementieren. Werkzeuge sind nützlich, aber teuer, daher kann man mit dem Prozess beginnen und die Interaktion und das Verständnis zwischen Entwicklung und Sicherheit einrichten. Aus Sicht der Sicherheit ist es nicht notwendig, alles zu stoppen; aus Sicht der Entwicklung muss, wenn etwas hochgradig kritisch ist, es behoben werden, anstatt die Augen vor dem Problem zu schließen.

Produktqualität ist das gemeinsame Ziel. Wir konzentrieren uns sowohl auf Sicherheit als auch auf Entwicklung. Wir setzen alles daran, dass alles reibungslos funktioniert und es keine Reputationsrisiken oder finanziellen Verluste gibt. Deshalb fördern wir den Ansatz von DevSecOps und SecDevOps, um die Kommunikation zu verbessern und das Produkt qualitativ hochwertiger zu gestalten.

Starten Sie mit dem, was bereits vorhanden ist: Anforderungen, Architektur, Teilprüfungen, Schulungen, Richtlinien. Es ist nicht notwendig, sofort alle Praktiken auf alle Projekte anzuwenden – bewegen Sie sich iterativ. Es gibt keinen einheitlichen Standard – experimentieren Sie und probieren Sie verschiedene Ansätze und Lösungen aus.

Zwischen Sicherheitsdefekten und funktionalen Defekten besteht ein Gleichheitszeichen..

Automatisieren Sie alles, was sich bewegt. Alles, was sich nicht bewegt – machen Sie es beweglich und automatisieren Sie es. Wenn etwas manuell erledigt wird, ist das kein guter Abschnitt des Prozesses. Vielleicht sollten Sie es überdenken und auch automatisieren.

Wenn die Größe des Sicherheitsteams klein ist – nutzen Sie Security Champions..

Vielleicht ist das, was ich beschrieben habe, nicht für Sie geeignet und Sie erfinden etwas Eigenes – und das ist gut. Aber wählen Sie die Werkzeuge basierend auf den Anforderungen Ihres Prozesses.. Lassen Sie sich nicht von der Community beeinflussen, die sagt, dass dieses Tool schlecht und jenes gut ist. Möglicherweise sehen Sie in Ihrem Produkt alles anders herum.

Anforderungen an Tools.

• Niedriges Niveau von False Positives.
• Angemessene Analysezeit.
• Benutzerfreundlichkeit.
• Verfügbarkeit von Integrationen.
• Verständnis des Produktentwicklungs-Roadmaps.
• Möglichkeiten zur Anpassung von Tools.

Yuri's Vortrag wurde als einer der besten auf der DevOpsConf 2018 ausgewählt. Um noch mehr interessante Ideen und praktische Fallstudien kennenzulernen, kommen Sie am 27. und 28. Mai nach Skolkovo zu DevOpsConf im Rahmen von dem RIT++ Festival. Noch besser, wenn Sie bereit sind, Ihre Erfahrungen zu teilen, dann reichen Sie Ihre Anmeldung ein für den Vortrag bis zum 21. April.

Quelle: habr.com