Angst und Hass in DevSecOps

Wir hatten 2 Code-Analyzer, 4 Werkzeuge für dynamisches Testen, eigene Bastelarbeiten und 250 Skripte. Es ist nicht so, dass das alles im aktuellen Prozess erforderlich war, aber wenn man erst einmal angefangen hat, DevSecOps einzuführen, muss man bis zum Ende gehen.

Quelle. Die Schöpfer der Charaktere: Justin Roiland und Dan Harmon.

Was ist SecDevOps? Und DevSecOps? Was sind die Unterschiede? Application Security – worum geht es dabei? Warum funktioniert der klassische Ansatz nicht mehr? Auf all diese Fragen weiß Yuri Shabalin aus Swordfish Security. Yuri wird ausführlich auf alles eingehen und die Herausforderungen des Übergangs von einem klassischen Modell der Application Security zu dem Prozess DevSecOps untersuchen: Wie man den Prozess der sicheren Softwareentwicklung richtig in den DevOps-Prozess integriert, ohne dabei etwas zu kaputtzumachen, wie man die Hauptphasen der Sicherheitstestung durchläuft, welche Werkzeuge anwendbar sind, wie sie sich unterscheiden und wie man sie richtig konfiguriert, um Fallstricke zu vermeiden.

Über den Sprecher: Yuri Shabalin ist Chief Security Architect bei der Swordfish Security. Er ist verantwortlich für die Einführung von SSDL und die allgemeine Integration von Analysetools für Anwendungen in ein einheitliches Entwicklungs- und Testökosystem. 7 Jahre Erfahrung in der Informationssicherheit. Er hat bei Alfa-Bank, Sberbank und bei Positive Technologies gearbeitet, die Software entwickelt und Dienstleistungen anbietet. Sprecher auf internationalen Konferenzen wie ZerONights, PHDays, RISSPA, OWASP.

Application Security: worum geht es dabei?

Application Security ist ein Bereich der Sicherheit, der für die Sicherheit von Anwendungen verantwortlich ist. Es bezieht sich nicht auf Infrastruktur oder Netzwerksicherheit, sondern speziell auf das, was wir schreiben und woran Entwickler arbeiten – es geht um die Schwachstellen und Verwundbarkeiten der Anwendung selbst.

Richtung SDL oder SDLC — Security Development Lifecycle – wurde von Microsoft entwickelt. In der Abbildung ist das kanonische Modell des SDLC dargestellt, dessen Hauptziel es ist, die Sicherheit in jeder Phase der Entwicklung zu berücksichtigen, von Anforderungen bis hin zur Veröffentlichung und dem Produktionsstart. Microsoft hat erkannt, dass es im Produkt zu viele Bugs gibt, die Anzahl zunimmt und dagegen etwas unternommen werden muss, und hat diesen Ansatz vorgeschlagen, der kanonisch geworden ist.

Application Security und SSDL sind nicht darauf ausgerichtet, Schwachstellen zu entdecken, wie allgemein angenommen wird, sondern darauf, deren Auftreten zu verhindern. Mit der Zeit wurde der kanonische Ansatz von Microsoft verbessert und weiterentwickelt, und es entstand eine tiefere, detaillierte Auseinandersetzung damit.

Der kanonische SDLC ist in verschiedenen Methodologien stark detailliert – OpenSAMM, BSIMM, OWASP. Die Methodologien unterscheiden sich, sind jedoch insgesamt ähnlich.

Building Security In Maturity Model

Am meisten liegt es mir am Herzen BSIMM — Building Security In Maturity Model. Die Grundlage der Methodologie ist die Aufteilung des Prozesses der Anwendungssicherheit in 4 Bereiche: Governance, Intelligence, SSDL Touchpoints und Deployment. In jedem Bereich gibt es 12 Praktiken, die als 112 Aktivitäten dargestellt werden.

Jede der 112 Aktivitäten hat 3 Reifegrade: Einstieg, Mittelstufe und Fortgeschritten. Alle 12 Praktiken können nach Kapiteln studiert werden, um wichtige Aspekte für Sie auszuwählen, zu verstehen, wie sie implementiert werden, und schrittweise Elemente hinzuzufügen, wie statische und dynamische Codeanalyse oder Code-Review. Sie erstellen einen Plan und arbeiten ruhig im Rahmen der Implementierung der gewählten Aktivitäten.

Warum DevSecOps

DevOps ist ein umfassender Prozess, der auch Sicherheitsaspekte berücksichtigt.

Ursprünglich DevOps waren Sicherheitsüberprüfungen vorgesehen. In der Praxis war die Anzahl der Sicherheitsteams jedoch viel geringer als heute, und sie traten nicht als Teilnehmer des Prozesses auf, sondern als Kontroll- und Aufsichtsbehörde, die Anforderungen stellt und die Produktqualität am Ende des Releases überprüft. Dies ist ein klassischer Ansatz, bei dem Sicherheitsteams von der Entwicklung abgeschottet waren und nicht am Prozess teilnahmen.

Das Hauptproblem besteht darin, dass die Informationssicherheit separat von der Entwicklung steht. Normalerweise handelt es sich um einen Sicherheitsrahmen mit 2–3 großen und teuren Werkzeugen. Alle sechs Monate wird der Quellcode oder die Anwendung zur Überprüfung geliefert, und einmal im Jahr werden Penetrationstests. Dies führt dazu, dass sich die Produktionsfristen verlängern, während auf die Entwickler eine enorme Anzahl von Schwachstellen aus automatisierten Mitteln hereinbricht. All dies ist nicht zu reparieren, weil die Ergebnisse der vorhergehenden sechs Monate noch nicht ausgearbeitet wurden und nun eine neue Charge kommt.

Im Laufe der Arbeit unseres Unternehmens sehen wir, dass Sicherheit in allen Bereichen und Branchen erkennt, dass es an der Zeit ist, aufzuholen und sich mit der Entwicklung im selben Rhythmus zu bewegen – in Agile. Das Paradigma DevSecOps passt hervorragend zur Methodologie der agilen Entwicklung, zur Implementierung, Unterstützung und Teilnahme an jedem Release und jeder Iteration.

Übergang zu DevSecOps

Das wichtigste Wort im Security Development Lifecycle ist „Prozess“. Sie müssen dies verstehen, bevor Sie an den Kauf von Werkzeugen denken.

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

Wichtiger sind die Menschen, nicht die Werkzeuge.

Oft beginnt die Planung eines sicheren Entwicklungsprozesses mit der Auswahl und dem Kauf eines Werkzeugs und endet mit dem Versuch, das Werkzeug in den aktuellen Prozess zu integrieren, der oft nur ein Versuch bleibt. Das führt zu traurigen Konsequenzen, da jedes Werkzeug seine eigenen Besonderheiten und Einschränkungen hat.

Ein häufiger Fall ist, dass die Sicherheitsabteilung ein gutes, teures Werkzeug mit umfassenden Funktionen auswählt und zu den Entwicklern kommt – um es in den Prozess einzubinden. Aber das klappt nicht – der Prozess ist so gestaltet, dass die Einschränkungen des bereits gekauften Werkzeugs nicht in die aktuelle Paradigmen passen.

Beschreiben Sie zuerst, welches Ergebnis Sie wollen und wie der Prozess aussehen soll. Das hilft dabei, die Rollen des Werkzeugs und der Sicherheit im Prozess zu verstehen.

Beginnen Sie mit dem, was bereits verwendet wird.

Bevor Sie teure Werkzeuge kaufen, schauen Sie sich an, was Sie bereits haben. In jedem Unternehmen gibt es Sicherheitsanforderungen, die an die Entwicklung gestellt werden, es gibt Prüfungen, Penetrationstests – warum nicht all dies in eine verständliche und für alle nützliche Form umwandeln?

In der Regel sind Anforderungen ein Papierdokument, das im Regal liegt. Es gab einen Fall, als wir in ein Unternehmen kamen, um die Prozesse zu betrachten, und baten, die Sicherheitsanforderungen für die Software zu zeigen. Der Spezialist, der sich damit beschäftigte, suchte lange:

– Moment, irgendwo in meinen Notizen war ein Weg, wo dieses Dokument liegt.

Am Ende haben wir das Dokument nach einer Woche erhalten.

Für Anforderungen, Prüfungen und anderes erstellen Sie eine Seite, zum Beispiel auf Confluence – das ist für alle praktisch.

Es ist einfacher, das, was bereits existiert, umzuformatieren und für den Start zu verwenden.

Nutzen Sie Security Champions.

In einem durchschnittlichen Unternehmen mit 100-200 Entwicklern arbeitet normalerweise ein Sicherheitsexperte, der mehrere Funktionen erfüllt und physisch nicht alles prüfen kann. Selbst wenn er sich große Mühe gibt – allein wird er nicht allen Code prüfen können, den die Entwicklung generiert. Für solche Fälle wurde das Konzept – Security Champions.

Security Champions sind Personen im Entwicklungsteam, die an der Sicherheit Ihres Produkts interessiert sind.

Der Security Champion ist der Zugangspunkt zum Entwicklungsteam und ein Sicherheitsevangelist in einer Person.

Normalerweise, wenn ein Sicherheitsbeauftragter ins Entwicklungsteam kommt und auf einen Fehler im Code hinweist, erhält er eine verwunderte Antwort:

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

Das ist eine typische Situation, da ältere oder einfach nur Kollegen des Entwicklers, mit denen er ständig bei der Arbeit und in der Code-Überprüfung interagiert, viel mehr Vertrauen genießen. Wenn anstelle des Sicherheitsbeauftragten der Security Champion auf den Fehler und die Folgen hinweist, hat sein Wort mehr Gewicht.

Auch verstehen die Entwickler ihren Code besser als jeder Sicherheitsbeauftragte. Für jemanden, der mindestens 5 Projekte im statischen Analysetool hat, ist es normalerweise schwierig, sich an alle Nuancen zu erinnern. Security Champions kennen ihr Produkt: was mit was interagiert und worauf man zuerst achten sollte – sie sind effizienter.

Überlegen Sie also, Security Champions einzuführen und den Einfluss des Sicherheitsteams zu erweitern. Das ist auch für den Champion selbst von Nutzen: berufliche Entwicklung in einem neuen Bereich, Erweiterung des technischen Horizonts, Stärkung technischer, organisatorischer und Führungsfähigkeiten sowie Erhöhung des Marktwerts. Es ist eine Art soziale Ingenieurkunst, Ihre "Augen" im Entwicklungsteam.

Testphasen

Das 20-zu-80-Prinzip besagt, dass 20% der Anstrengungen 80% des Ergebnisses liefern. Diese 20% sind die Praktiken der Anwendung Analyse, die automatisiert werden können und sollten. Beispiele für solche Aktivitäten sind statische Analyse – SAST, dynamische Analyse – DAST, und Open Source Kontrolle. Ich werde näher auf die Aktivitäten eingehen, sowie auf die Werkzeuge und die Besonderheiten, mit denen wir normalerweise bei ihrer Implementierung im Prozess konfrontiert sind, und wie man dies richtig macht.

Hauptprobleme der Werkzeuge

Ich werde die aktuellen Probleme aller Werkzeuge hervorheben, die Aufmerksamkeit erfordern. Ich werde diese detaillierter analysieren, um mich nicht weiter zu wiederholen.

Lange Analysezeit. Wenn es 30 Minuten von dem Commit bis zum Produktionsrelease für alle Tests und den Build dauert, werden die Überprüfungen auf Informationssicherheit einen Tag in Anspruch nehmen. Niemand wird den Prozess so aufhalten. Berücksichtigen Sie dieses Merkmal und ziehen Sie Ihre Schlussfolgerungen.

Hohe Rate von False Negatives oder False Positives. Alle Produkte sind unterschiedlich, sie verwenden verschiedene Frameworks und ihren eigenen Stil beim Schreiben von Code. Bei unterschiedlichen Codebasen und Technologien können die Werkzeuge unterschiedliche Raten von False Negatives und False Positives zeigen. Daher schauen Sie, was genau in Ihrem Unternehmen und für Ihre Anwendungen gute und verlässliche Ergebnisse liefert.

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

Fehlende oder übermäßige Komplexität der Anpassung. Wenn ein Werkzeug keine API hat, wozu braucht man es dann? Alles, was im Interface möglich ist, sollte auch über die API zugänglich sein. Ideal wäre es, wenn das Werkzeug die Möglichkeit zur Anpassung der Prüfungen bietet.

Kein Entwicklungsroadmap des Produkts. Die Entwicklung steht niemals still; wir nutzen ständig neue Frameworks und Funktionen, und schreiben alten Code in neuen Sprachen um. Wir möchten sicher sein, dass das Werkzeug, das wir kaufen, neue Frameworks und Technologien unterstützt. Daher ist es wichtig zu wissen, dass das Produkt eine reale und korrekte Roadmap Entwicklung hat.

Besonderheiten des Prozesses

Neben den Eigenschaften der Werkzeuge sollten Sie auch die Besonderheiten des Entwicklungsprozesses berücksichtigen. Zum Beispiel ist es ein typischer Fehler, die Entwicklung zu stören. Lassen Sie uns sehen, welche weiteren Besonderheiten zu berücksichtigen sind und worauf das Sicherheitsteam achten sollte.

Um die Fristen für die Entwicklung und den Release nicht zu gefährden, erstellen Sie verschiedene Regeln und verschiedene Show Stopper — Kriterien für den Stop des Build-Prozesses bei Vorhandensein von Schwachstellen — für verschiedene Umgebungen. Zum Beispiel verstehen wir, dass der aktuelle Branch auf einem Entwicklungsstand oder UAT ist, daher halten wir nicht an und sagen nicht:

— Sie haben hier Schwachstellen, Sie kommen nicht weiter!

An diesem Punkt ist es wichtig, den Entwicklern zu sagen, dass es Sicherheitsprobleme gibt, auf die man achten sollte.

Vorhandensein von Schwachstellen ist kein Hindernis für weitere Tests.: manuelles, integratives oder manuelles Testen. Auf der anderen Seite müssen wir irgendwie die Sicherheit des Produkts erhöhen, und die Entwickler sollten nicht ignorieren, was Sicherheit findet. Deshalb handeln wir manchmal so: Wenn wir eine neue Version für die Entwicklungsumgebung bereitstellen, benachrichtigen wir einfach die Entwickler:

— Leute, ihr habt Probleme, bitte achtet darauf.

In der UAT-Phase zeigen wir erneut Warnungen über Schwachstellen, und in der Produktionsphase sagen wir:

— Leute, wir haben euch mehrmals gewarnt, ihr habt nichts unternommen – damit lassen wir euch nicht raus.

Wenn es um Code und Dynamik geht, sollten wir nur die Schwachstellen der Features und des Codes anzeigen und warnen, die gerade in diesem Feature geschrieben wurden. Wenn ein Entwickler einen Button um 3 Pixel verschoben hat und wir ihm sagen, dass er dort eine SQL-Injektion hat und dringend etwas ändern muss – das ist falsch. Schaut nur auf das, was jetzt geschrieben ist, und auf die Veränderung, die in die Anwendung kommt.

Angenommen, wir haben einen funktionalen Defekt - wie die Anwendung nicht funktionieren sollte: Geld wird nicht überwiesen, beim Klicken auf den Button erfolgt kein Übergang zur nächsten Seite oder das Produkt lädt nicht. Sicherheitsdefekte sind solche Defekte, aber nicht im Kontext des Anwendungsbetriebs, sondern der Sicherheit.

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

Da alle Schwachstellen solche Defekte sind, sollten sie dort sein, wo auch alle Entwicklungsfehler sind. Vergesst also Berichte und erschreckende PDFs, die niemand liest.

Als ich für ein Unternehmen arbeitete, das Software entwickelte, erhielt ich einen Bericht von einem statischen Analysewerkzeug. Ich öffnete ihn, erschrak, machte mir einen Kaffee, blätterte durch 350 Seiten, schloss ihn und machte weiter mit der Arbeit. Große Berichte sind tote Berichte. Normalerweise gehen sie nirgendwo hin, E-Mails werden gelöscht, vergessen, verloren oder das Geschäft sagt, dass es die Risiken akzeptiert.

Was tun? Die bestätigten Fehler, die wir gefunden haben, wandeln wir einfach in ein entwicklungsfreundliches Format um, zum Beispiel indem wir sie im Backlog in Jira ablegen. Wir priorisieren die Fehler und beheben sie nach Dringlichkeit, gleichwertig mit funktionalen Fehlern und Testfehlern.

Statische Analyse - SAST

Dies ist eine Analyse des Codes auf Schwachstellen., aber das ist nicht dasselbe wie SonarQube. Wir überprüfen nicht nur nach Mustern oder Stil. Bei der Analyse kommen verschiedene Ansätze zur Anwendung: nach dem Schwachstellenschema, nach DataFlow, nach der Analyse von Konfigurationsdateien. Das betrifft alles, was direkt den Code angeht.

Vorteile des Ansatzes: die Aufdeckung von Schwachstellen im Code in einer frühen Phase der Entwicklung, wenn es noch keine Stände und kein fertiges Werkzeug gibt, und die Möglichkeit einer inkrementellen Analyse: die Analyse des Codes, der sich geändert hat, und nur der Funktion, an der wir gerade arbeiten, was die Analysezeit verkürzt.

Nachteile – das Fehlen der Unterstützung benötigter Sprachen.

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

• Integrationswerkzeuge: Jenkins, TeamCity und Gitlab CI.
• Entwicklungsumgebung: Intellij IDEA, Visual Studio. Es ist für Entwickler einfacher, nicht durch eine unverständliche Benutzeroberfläche zu navigieren, die man sich erst merken muss, sondern direkt an ihrem Arbeitsplatz in ihrer eigenen Entwicklungsumgebung alle notwendigen Integrationen und Schwachstellen, die sie gefunden haben, zu sehen.
• Code-Review: SonarQube und manuelles Review.
• Fehlerverfolgungssysteme: Jira und Bugzilla.

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

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

SAST Open Source finden möglicherweise nicht eine große Anzahl von Schwachstellen oder komplexe DataFlows, aber sie können und sollten beim Aufbau des Prozesses verwendet werden. Sie helfen zu verstehen, wie der Prozess aufgebaut wird, wer für die Bugs verantwortlich ist, wer reportet und wer Bericht erstattet. Wenn Sie die erste Phase der Sicherstellung der Sicherheit Ihres Codes durchführen möchten, verwenden Sie Open-Source-Lösungen.

Wie kann man das integrieren, wenn Sie am Anfang stehen und nichts haben: weder CI, noch Jenkins, noch TeamCity? Lassen Sie uns die Integrationen in den Prozess betrachten.

Integration auf CVS-Ebene

Wenn Sie Bitbucket oder GitLab haben, können Sie die Integration auf Concurrent Versions System.

Nach der Ereignis — Pull-Request, Commit. Sie scannen den Code und zeigen im Status des Builds, ob die Sicherheitsprüfung bestanden oder nicht bestanden wurde.

Feedback. Natürlich ist Feedback immer notwendig. Wenn Sie einfach auf der Sicherheitsseite gearbeitet, alles in eine Box gepackt und niemandem davon erzählt haben, und am Ende des Monats eine Menge Bugs herausgekommen sind – das ist nicht richtig und nicht gut.

Integration mit dem Code Review System

Einmal haben wir in einigen wichtigen Projekten als Standard-Reviewer einen technischen Benutzer von AppSec eingesetzt. Abhängig davon, ob Fehler im neuen Code gefunden wurden oder nicht, weist der Reviewer im Pull-Request den Status „accept“ oder „need work“ zu – entweder alles in Ordnung oder es muss nachgebessert werden, mit Verweisen dazu, was genau ausgearbeitet werden muss. Für die Integration mit der Version, die in der Produktion läuft, haben wir das Merge-Verbot aktiviert, wenn der Test für die Informationssicherheit nicht bestanden wurde. Dies haben wir in das manuelle Code Review integriert, und die anderen Beteiligten im Prozess konnten die Sicherheitsstatus genau für diesen spezifischen Prozess sehen.

Integration mit SonarQube

Viele haben Quality Gate . Hier ist es dasselbe – man kann die gleichen Gates nur für SAST-Tools erstellen. Es wird dasselbe Interface, dasselbe Quality Gate sein, nur wird es Security Gategenannt. Und ebenso, wenn Sie einen Prozess mit SonarQube eingerichtet haben, können Sie alles problemlos integrieren.

Integration auf CI-Ebene

Hier ist auch alles ziemlich einfach:

• Auf der gleichen Ebene wie die automatisierten Tests, den Unit-Tests.
• Teilen nach Entwicklungsphasen: dev, test, prod. Unterschiedliche Regelsets oder unterschiedliche Fehlbedingungen können aktiviert werden: Wir stoppen den Build, oder wir stoppen ihn nicht.
• Synchroner/asynchroner Start. Wir warten auf das Ende der Sicherheitsprüfungen oder wir warten nicht. Das heißt, wir haben sie einfach gestartet und machen weiter, und dann 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 Sicherheitsprüfungen sollte den Ergebnissen der Unit-Tests entsprechen.

Zum Beispiel haben wir ein großes Projekt übernommen und beschlossen, dass wir es jetzt mit SAST scannen werden – in Ordnung. Wir haben dieses Projekt in die SAST eingefügt, es hat uns 20.000 Sicherheitsanfälligkeiten ausgegeben, und nach einem entschlossenen Beschluss haben wir akzeptiert, dass alles gut ist. 20.000 Sicherheitsanfälligkeiten sind unsere technische Schuld. Diese Schuld packen wir in eine Box, werden sie nach und nach abarbeiten und Bugs in die Fehlerverfolgung eintragen. Wir werden ein Unternehmen einstellen, alles selbst machen oder uns von Security Champions unterstützen lassen – und die technische Schuld wird abnehmen.

Alle neu entstehenden Sicherheitsanfälligkeiten im neuen Code müssen ebenfalls behoben werden, wie Fehler in Unit-Tests oder automatisierten Tests. Vereinfacht gesagt, das Build läuft, zwei Tests sind fehlgeschlagen und zwei Sicherheitstests sind fehlgeschlagen. In Ordnung – wir haben geschaut, was passiert ist, haben das eine und das andere behoben, beim nächsten Mal haben wir es erneut getestet – alles gut, es sind keine neuen Sicherheitsanfälligkeiten aufgetaucht, die Tests sind nicht fehlgeschlagen. Wenn diese Aufgabe tiefergehender ist und wir sie gut verstehen müssen, oder die Behebung von Sicherheitsanfälligkeiten große Teile dessen betrifft, was hinter den Kulissen passiert: Wir tragen den Bug in die Fehlerverfolgung ein, er wird priorisiert und behoben. Leider ist die Welt nicht perfekt und Tests fallen manchmal aus.

Ein Beispiel für ein Security Gate – analog zum Quality Gate, bezogen auf die Anzahl und das Vorhandensein von Sicherheitsanfälligkeiten im Code.

Wir integrieren mit SonarQube – das Plugin wird installiert, alles ist sehr praktisch und klasse.

Integration in die Entwicklungsumgebung

Integrationsmöglichkeiten:

• Scannen aus der Entwicklungsumgebung noch vor dem Commit starten.
• Ergebnisse anzeigen.
• Ergebnisse analysieren.
• Synchronisierung mit dem Server.

So sieht der Abruf von Ergebnissen vom Server aus.

In unserer Entwicklungsumgebung Intellij IDEA erscheint einfach ein zusätzlicher Punkt, der anzeigt, dass beim Scannen solche Sicherheitsanfälligkeiten gefunden wurden. Man kann sofort den Code anpassen, Empfehlungen einsehen und Flow Graph. Das alles ist am Arbeitsplatz des Entwicklers verfügbar, was sehr praktisch ist – man muss nicht auf andere Links gehen und zusätzliche Informationen suchen.

Open Source

Das ist mein Lieblingsthema. Jeder nutzt Open Source-Bibliotheken – wozu eine Menge Hacks und Fahrräder bauen, wenn man eine fertige Bibliothek nutzen kann, in der schon alles umgesetzt ist?

Natürlich, das stimmt, aber Bibliotheken werden auch von Menschen geschrieben und beinhalten ebenfalls bestimmte Risiken und 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 Bibliotheken. Das Tool weiß beispielsweise, dass wir eine bestimmte Bibliothek verwenden und dass in CVE oder in Bug-Trackern Schwachstellen gemeldet sind, die sich auf diese Version der Bibliothek beziehen. 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, die keine Schwachstellen aufweist.

Analyse der Lizenzreinheit. Bei uns ist das noch nicht besonders populär, aber wenn Sie mit dem Ausland arbeiten, können Sie dort gelegentlich Ärger für die Verwendung einer Open Source-Komponente bekommen, die nicht verwendet oder modifiziert werden darf. Laut der Lizenzpolitik der Bibliothek können 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 auch dafür kann man sich schützen.

Analyse von Komponenten, die in der Industrie verwendet werden. Stellen wir uns eine hypothetische Situation vor: Wir haben endlich die Entwicklung abgeschlossen und die letzte Version unseres Mikrodienstes veröffentlicht. Er läuft dort wunderbar – eine Woche, einen Monat, ein Jahr. Wir sammeln ihn nicht ein, führen keine Sicherheitsprüfungen durch, alles scheint gut zu sein. Doch plötzlich, zwei Wochen nach der Veröffentlichung, kommt eine kritische Schwachstelle in der Open Source-Komponente heraus, die wir genau in diesem Build, in der Produktionsumgebung, verwenden. Wenn wir nicht aufzeichnen, was und wo wir verwenden, werden wir diese Schwachstelle einfach nicht sehen. In einigen Tools gibt es Möglichkeiten zur Überwachung von Schwachstellen in Bibliotheken, die derzeit in der Produktion verwendet werden. Das ist sehr nützlich.

Vollständig unstationäre, zeitgenaue Analyse;

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

Einige Beispiele von Marktführern, die sich mit Open Source-Analysen befassen.

Der einzige kostenlose von 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. Im Wesentlichen handelt es sich um alle Cloud-Produkte oder On-Premise, aber alle Daten werden dennoch ins Internet gesendet. Sie senden nicht Ihre Bibliotheken, sondern Hashes oder eigene Werte, die sie berechnen, sowie Fingerabdrücke an ihren Server, um Benachrichtigungen über bekannte Schwachstellen 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 steht innerhalb von Event Central Nexus, und wir möchten, dass in unserem Repository keine Schwachstellen mit dem Status "kritisch" oder "hoch" vorhanden sind. Man kann das Proxieren mit dem Tool Nexus Firewall Lifecycle so konfigurieren, dass solche Schwachstellen ausgeschlossen werden und nicht in das interne Repository gelangen.

Integration in CI. Auf einer Ebene mit automatisierten Tests, Unit-Tests und der Trennung der Entwicklungsphasen: dev, test, prod. In jeder Phase können beliebige Bibliotheken heruntergeladen und alles Mögliche verwendet werden, aber wenn dort etwas Strenges mit dem Status "critical" vorhanden ist, sollten die Entwickler möglicherweise in der Phase des Live-Gehens darauf hingewiesen werden.

Integration mit Artefakt-Repositories: Nexus und JFrog.

Integration in die Entwicklungsumgebung. Die Werkzeuge, die Sie auswählen, sollten Integration mit den Entwicklungsumgebungen haben. Der Entwickler sollte von seinem Arbeitsplatz aus Zugriff auf die Ergebnisse der Scans haben oder die Möglichkeit, selbst zu scannen und den Code auf Schwachstellen vor dem Commit in CVS zu überprüfen.

Integration in CD. Das ist eine coole Funktion, die mir sehr gefällt und über die ich bereits gesprochen habe – die Überwachung des Auftretens neuer Schwachstellen in der Produktionsumgebung. Das funktioniert ungefähr so.

Wir haben öffentliche Komponenten-Repositories — einige Werkzeuge nach außen und unser internes Repository. Wir möchten, dass darin nur vertrauenswürdige Komponenten vorhanden sind. Beim Proxieren der Anfrage überprüfen wir, dass die heruntergeladene Bibliothek keine Schwachstellen aufweist. Wenn sie bestimmten Richtlinien unterliegt, die wir festlegen und unbedingt mit der Entwicklung abstimmen, wird sie nicht heruntergeladen, und es erfolgt eine Meldung zur Verwendung einer anderen Version. Dementsprechend erhält der Entwickler, wenn in der Bibliothek etwas wirklich Kritisches und Schlechtes vorhanden ist, die Bibliothek noch nicht in der Installationsphase – er soll eine höhere oder niedrigere Version verwenden.

• Beim Build überprüfen wir, dass niemand etwas Schlechtes hineingeschmuggelt 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.
• Beim Deployment überprüfen wir das Paket erneut: war, jar, DL oder Docker-Image, um sicherzustellen, dass es den Richtlinien entspricht.
• Beim Wechsel in die Produktion überwachen wir, was in der Produktionsumgebung passiert: ob kritische Schwachstellen auftreten oder nicht.

Dynamische Analyse – DAST

Werkzeuge der dynamischen Analyse unterscheiden sich grundlegend von allem, was bisher gesagt wurde. Es handelt sich um eine Simulation der Benutzerinteraktion mit der Anwendung. Wenn es sich um eine Webanwendung handelt, senden wir Anfragen, simulieren die Arbeit des Clients, klicken auf Schaltflächen im Frontend und senden künstliche Daten aus Formularen: Anführungszeichen, Klammern, Zeichen in verschiedenen Kodierungen, um zu sehen, wie die Anwendung funktioniert und externe Daten verarbeitet.

Dieses System ermöglicht es auch, bekannte Schwachstellen in Open Source zu überprüfen. Da DAST nicht weiß, welches Open Source wir verwenden, werden einfach "schadhafte" Muster eingesetzt und die Serverantworten analysiert:

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

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

• Hohe Belastung des Netzwerks des Anwendungsservers.
• Keine Integrationen.
• Möglichkeit zur Änderung der Einstellungen der analysierten Anwendung.
• Keine Unterstützung der erforderlichen Technologien.
• Schwierigkeiten bei der Konfiguration.

Wir hatten eine Situation, als wir endlich AppScan gestartet haben: es dauerte lange, um Zugang zur Anwendung zu erhalten, wir bekamen 3 Konten und freuten uns - endlich können wir alles überprüfen! Wir starteten den Scan, und das erste, was AppScan machte, war, in das Admin-Panel einzudringen, alle Knöpfe zu drücken, die Hälfte der Daten zu ändern und anschließend den Server mit seinen -Anfragen komplett abzuschalten. mailform-Anfragen. Die Entwicklung mit dem Testteam sagte:

— Leute, macht ihr Witze?! Wir haben euch Zugänge gegeben, und ihr habt die Standalone-Version zerstört!

Berücksichtigt mögliche Risiken. Idealerweise solltet ihr eine separate Testumgebung für Sicherheitstests vorbereiten, die zumindest irgendwie vom restlichen Umfeld isoliert ist, und das Admin-Panel vorzugsweise manuell überprüfen. Das ist ein Pentest - die verbleibenden Prozentsätze an Aufwand, die wir jetzt nicht betrachten.

Es sollte berücksichtigt werden, dass man dies als analoge Lastprüfung verwenden kann. In der ersten Phase kann man den dynamischen Scanner in 10-15 Threads aktivieren und sehen, was dabei herauskommt, aber normalerweise zeigt die Praxis, dass nichts Gutes herauskommt.

Einige Ressourcen, die wir normalerweise verwenden.

Es ist hervorzuheben Burp Suite — das ist das „Schweizer Taschenmesser“ für jeden Sicherheitsspezialisten. Es wird von allen verwendet und ist sehr benutzerfreundlich. Vor kurzem wurde eine neue Demoversion der Enterprise-Edition veröffentlicht. Früher war es einfach ein Standalone-Tool mit Plugins, aber jetzt entwickeln die Programmierer endlich einen großen Server, von dem aus mehrere Agenten verwaltet werden können. Das ist genial, ich empfehle es auszuprobieren.

Integration in den Prozess

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

Wenn die Integrationen nicht funktionieren oder dort Platzhalter und Mock-Funktionen stehen, ist das sinnlos und nutzlos – egal welches Muster wir senden, der Server wird immer gleich antworten.

• Ideal ist eine separate Umgebung für Tests.
• Vor Beginn der Tests solltet ihr die Anmeldefolge aufzeichnen.
• Die Testung des Administrationssystems erfolgt ausschließlich manuell.

Prozess

Ein wenig zusammenfassend über den gesamten Prozess und über die Arbeit jedes Tools, insbesondere. Alle Anwendungen sind unterschiedlich – bei einer funktioniert die dynamische Analyse besser, bei einer anderen die statische, bei einer dritten die OpenSource-Analyse, Pentests oder sogar etwas ganz anderes, zum Beispiel Ereignisse mit Waf.

Jeder Prozess benötigt Kontrolle.

Um zu verstehen, wie ein Prozess funktioniert und wo man ihn verbessern kann, müssen Metriken von allem gesammelt werden, was in Reichweite ist, einschließlich Produktionsmetriken, Metriken von Tools und aus Fehlerverfolgern.

Alle Daten sind nützlich. Man muss aus verschiedenen Perspektiven betrachten, wo welches Tool besser eingesetzt wird und wo der Prozess konkret schwächelt. Vielleicht sollte man die Reaktionszeit der Entwicklung betrachten, um zu verstehen, wo der Prozess basierend auf der Zeit verbessert werden kann. Je mehr Daten vorhanden sind, desto mehr Perspektiven kann man von hochrangigen bis zu Detailansichten jedes Prozesses aufbauen.

Da jeder statische und dynamische Analyzer seine eigenen APIs, eigene Möglichkeiten der Ausführung und Prinzipien hat, einige mit Planern, andere ohne, schreiben wir ein Tool AppSec-Orchestrator, das einen einheitlichen Einstieg in den gesamten Prozess von der Entwicklung ermöglicht und ihn von einem Punkt aus steuern kann.

Manager, Entwickler und Sicherheitsingenieure haben einen Einstiegspunkt, von dem aus sie sehen können, was läuft, einstellen und Scans ausführen, Ergebnisse erhalten und Anforderungen stellen können. Wir versuchen, von Papierkram wegzukommen und alles in eine für die Entwicklung verständliche Form zu bringen – Seiten auf Confluence mit Status und Metriken, Fehler in Jira oder in verschiedenen Fehlerverfolgern, oder die Integration in einen synchronen/asynchronen Prozess in CI/CD.

Wesentliche Erkenntnisse

Werkzeuge sind nicht das Wichtigste. Zuerst den Prozess durchdenken – dann die Werkzeuge implementieren. Werkzeuge sind gut, aber teuer; darum kann man mit dem Prozess beginnen und die Interaktion sowie das Verständnis zwischen Entwicklung und Sicherheit gestalten. Aus der Sicht der Sicherheit: Man sollte nicht alles ohne weiteres blockieren. Aus der Sicht der Entwicklung: Wenn etwas hochgradig kritisch ist, muss es eliminiert werden und nicht ignoriert werden.

Produktqualität – das gemeinsame Ziel sowohl für die Sicherheit als auch für die Entwicklung. Wir machen dasselbe und bemühen uns, dass alles korrekt funktioniert und keine Reputationsrisiken oder finanziellen Verluste entstehen. Deshalb propagieren wir den Ansatz des DevSecOps und SecDevOps, um die Kommunikation zu verbessern und das Produkt qualitativ hochwertiger zu machen.

Beginnen Sie mit dem, was bereits vorhanden ist: Anforderungen, Architektur, Teilprüfungen, Schulungen, Richtlinien. Verwenden Sie nicht sofort alle Praktiken für alle Projekte – arbeiten Sie 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 – bewegen Sie es und automatisieren Sie es. Wenn etwas manuell erledigt wird, ist das kein guter Abschnitt im Prozess. Möglicherweise sollten Sie dies überdenken und ebenfalls automatisieren.

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

Möglicherweise passen die Dinge, von denen ich gesprochen habe, nicht zu Ihnen und Sie entwickeln etwas Eigenes – und das ist gut. Aber wählen Sie die Werkzeuge auf der Grundlage der Anforderungen Ihres Prozesses aus.Schauen Sie nicht darauf, was die Community sagt, dass dieses Werkzeug schlecht ist und dieses gut. Vielleicht ist es genau umgekehrt bei Ihrem Produkt.

Anforderungen an die Werkzeuge.

• Niedriger Anteil an False Positives.
• Angemessene Analysezeit.
• Benutzerfreundlichkeit.
• Vorhandensein von Integrationen.
• Verständnis des Entwicklungs-Roadmaps des Produkts.
• Möglichkeit zur Anpassung der Werkzeuge.

Der Vortrag von Yuri wurde als einer der besten auf der DevOpsConf 2018 ausgewählt. Um viele weitere interessante Ideen und praktische Fälle kennenzulernen, kommen Sie am 27. und 28. Mai nach Skolkovo zu DevOpsConf im Rahmen von Festival RIT++. Noch besser ist es, wenn Sie bereit sind, Ihre Erfahrungen zu teilen, dann bewerben Sie sich bis zum 21. April für einen Vortrag.

Quelle: habr.com