Wir hatten 2 Code-Analysatoren, 4 dynamische Testtools, unsere eigenen Bastelarbeiten und 250 Skripte. Nicht, dass all dies im aktuellen Prozess nötig gewesen wäre, aber sobald Sie mit der Implementierung von DevSecOps begonnen haben, müssen Sie bis zum Ende vorgehen.
. Von Justin Roiland und Dan Harmon geschaffene Charaktere.
Was ist SecDevOps? Was ist mit DevSecOps? Was sind die Unterschiede? Anwendungssicherheit – worum geht es? Warum funktioniert der klassische Ansatz nicht mehr? Auf all diese Fragen gibt es eine Antwort Juri Schabalin von Swordfish-Sicherheit. Yuriy wird alles im Detail beantworten und die Probleme des Übergangs vom klassischen Anwendungssicherheitsmodell zum DevSecOps-Prozess analysieren: wie man die Integration des sicheren Entwicklungsprozesses in den DevOps-Prozess richtig angeht und nichts kaputt macht, wie man die Hauptphasen durchläuft von Sicherheitstests, welche Tools verwendet werden können, wie sie sich unterscheiden und wie man sie richtig konfiguriert, um Fallstricke zu vermeiden.
Über den Sprecher: Juri Schabalin - Chef-Sicherheitsarchitekt im Unternehmen Swordfish-Sicherheit. Verantwortlich für die Implementierung von SSDL und für die Gesamtintegration von Anwendungsanalysetools in ein einziges Entwicklungs- und Testökosystem. 7 Jahre Erfahrung in der Informationssicherheit. Arbeitete bei Alfa-Bank, Sberbank und Positive Technologies, die Software entwickeln und Dienstleistungen anbieten. Sprecher internationaler Konferenzen ZerONights, PHDays, RISSPA, OWASP.
Anwendungssicherheit: Worum geht es?
Application Security ist der Sicherheitsbereich, der für die Anwendungssicherheit verantwortlich ist. Dabei geht es nicht um Infrastruktur- oder Netzwerksicherheit, sondern darum, was wir schreiben und woran Entwickler arbeiten – das sind die Mängel und Schwachstellen der Anwendung selbst.
Richtung - Lebenszyklus der Sicherheitsentwicklung - Entwickelt von Microsoft. Das Diagramm zeigt das kanonische SDLC-Modell, dessen Hauptaufgabe die Beteiligung der Sicherheit in jeder Entwicklungsphase ist, von den Anforderungen über die Veröffentlichung und Veröffentlichung bis hin zur Produktion. Microsoft erkannte, dass der Abschlussball zu viele Fehler enthält, es gibt mehr davon und es muss etwas dagegen getan werden, und schlug diesen Ansatz vor, der kanonisch wurde.
Anwendungssicherheit und SSDL zielen nicht darauf ab, Schwachstellen zu erkennen, wie allgemein angenommen wird, sondern deren Auftreten zu verhindern. Im Laufe der Zeit wurde der kanonische Ansatz von Microsoft verbessert, weiterentwickelt und bietet ein tieferes und detailliertes Eintauchen.
Der kanonische SDLC ist in verschiedenen Methoden sehr detailliert – OpenSAMM, BSIMM, OWASP. Die Methoden unterscheiden sich, sind aber im Allgemeinen ähnlich.
Gebäudesicherheit im Reifegradmodell
Mir gefällt es am besten BSIMM - . Die Grundlage der Methodik ist die Aufteilung des Anwendungssicherheitsprozesses in vier Domänen: Governance, Intelligence, SSDL-Touchpoints und Bereitstellung. Jede Domäne verfügt über 4 Praktiken, die als 12 Aktivitäten dargestellt werden.
Jede der 112 Aktivitäten hat 3 Reifegrade: Anfänger, Mittelstufe und Fortgeschrittene. Sie können alle 12 Praktiken in Abschnitten studieren, Dinge auswählen, die für Sie wichtig sind, herausfinden, wie Sie sie umsetzen und nach und nach Elemente hinzufügen, zum Beispiel statische und dynamische Codeanalyse oder Codeüberprüfung. Sie erstellen einen Plan und arbeiten danach in aller Ruhe im Rahmen der Umsetzung der ausgewählten Aktivitäten.
Warum DevSecOps
DevOps ist ein insgesamt großer Prozess, bei dem auf Sicherheit geachtet werden muss.
Ursprünglich mit Sicherheitskontrollen verbunden. In der Praxis war die Anzahl der Sicherheitsteams deutlich geringer als heute und sie agierten nicht als Prozessbeteiligte, sondern als Kontroll- und Aufsichtsorgan, das Anforderungen an sie stellt und am Ende der Veröffentlichung die Qualität des Produkts überprüft. Dabei handelt es sich um einen klassischen Ansatz, bei dem Sicherheitsteams von der Entwicklung ferngehalten wurden und nicht am Prozess beteiligt waren.
Das Hauptproblem besteht darin, dass Informationssicherheit von der Entwicklung getrennt ist. Normalerweise handelt es sich hierbei um eine Art IB-Schaltung, die 2-3 große und teure Werkzeuge enthält. Alle sechs Monate und einmal im Jahr trifft der Quellcode oder die Anwendung zum Testen ein . All dies führt dazu, dass sich die Veröffentlichungstermine für die Branche verschieben und eine Vielzahl von Schwachstellen durch automatisierte Tools auf den Entwickler fallen. Es ist unmöglich, das alles zu demontieren und zu reparieren, da die Ergebnisse auch in den letzten sechs Monaten nicht demontiert wurden, und hier ist eine neue Charge.
Im Laufe der Arbeit unseres Unternehmens stellen wir fest, dass die Sicherheitskräfte in allen Bereichen und Branchen verstehen, dass es an der Zeit ist, mit der Entwicklung Schritt zu halten und mit ihr Schritt zu halten . Das DevSecOps-Paradigma passt perfekt in die agile Entwicklungsmethodik, Implementierung, Unterstützung und Teilnahme an jeder Veröffentlichung und Iteration.
Übergang zu DevSecOps
Das wichtigste Wort im Security Development Lifecycle ist "Verfahren". Sie müssen dies verstehen, bevor Sie über den Kauf von Werkzeugen nachdenken.
Die bloße Einbeziehung von Tools in den DevOps-Prozess reicht nicht aus – Kommunikation und Verständnis zwischen den Prozessbeteiligten sind wichtig.
Menschen sind wichtiger als Werkzeuge
Die Planung eines sicheren Entwicklungsprozesses beginnt oft mit der Auswahl und dem Kauf eines Tools und endet mit Versuchen, das Tool in den aktuellen Prozess zu integrieren, die Versuche bleiben. Dies führt zu traurigen Konsequenzen, da alle Tools ihre eigenen Eigenschaften und Einschränkungen haben.
Ein häufiger Fall ist, dass die Sicherheitsabteilung ein gutes, teures Tool mit einem breiten Funktionsumfang auswählt und sich an die Entwickler wendet, um es in den Prozess zu integrieren. Aber es klappt nicht – der Prozess ist so konzipiert, dass die Einschränkungen eines bereits gekauften Instruments nicht in das aktuelle Paradigma passen.
Beschreiben Sie zunächst, welches Ergebnis Sie wünschen und wie der Prozess aussehen wird. Dies wird dazu beitragen, die Rolle des Tools und der Sicherheit im Prozess zu verstehen.
Beginnen Sie mit dem, was bereits verwendet wird
Schauen Sie sich vor dem Kauf teurer Werkzeuge an, was Sie bereits haben. Jedes Unternehmen hat Sicherheitsanforderungen, die für die Entwicklung gelten, es gibt Kontrollen, Pentests – warum das alles nicht in eine für alle verständliche und bequeme Form bringen?
Normalerweise handelt es sich bei den Voraussetzungen um einen Talmud in Papierform, der auf einem Regal liegt. Es gab einen Fall, in dem wir in das Unternehmen kamen, um uns die Prozesse anzusehen und sie zu bitten, die Sicherheitsanforderungen für die Software aufzuzeigen. Der Spezialist, der das gemacht hat, hat lange gesucht:
- Irgendwo in den Notizen gab es einen Pfad, wo dieses Dokument liegt.
Daraufhin erhielten wir das Dokument eine Woche später.
Für Anforderungen, Prüfungen und mehr erstellen Sie eine Seite, zum Beispiel unter Zusammenfluss - es ist für jeden praktisch.
Es ist einfacher, das, was bereits vorhanden ist, neu zu formatieren und zum Starten zu verwenden.
Nutzen Sie Security Champions
Normalerweise gibt es in einem durchschnittlichen Unternehmen mit 100 bis 200 Entwicklern einen Sicherheitsbeauftragten, der mehrere Funktionen ausführt und physisch keine Zeit hat, alles zu überprüfen. Selbst wenn er sein Bestes gibt, wird er allein nicht den gesamten Code überprüfen, der von der Entwicklung generiert wird. Für solche Fälle wurde ein Konzept entwickelt - .
Security Champions ist eine Person innerhalb des Entwicklungsteams, die an der Sicherheit Ihres Produkts interessiert ist.
Security Champion ist ein Einstiegspunkt in das Entwicklungsteam und ein Sicherheitsevangelist in einem.
Wenn ein Sicherheitsbeauftragter zum Entwicklungsteam kommt und ihn auf einen Fehler im Code hinweist, erhält er normalerweise eine überraschte Antwort:
- Und wer sind Sie? Ich sehe dich zum ersten Mal. Bei mir ist alles in Ordnung – mein älterer Freund hat bei der Codeüberprüfung „Bewerben“ angegeben, wir machen weiter!
Dies ist eine typische Situation, da das Vertrauen in Vorgesetzte oder einfach nur in Teamkollegen, mit denen der Entwickler bei der Arbeit und bei der Codeüberprüfung ständig interagiert, viel größer ist. Wenn statt eines Wachmanns der Security Champion auf den Fehler und die Folgen hinweist, hat sein Wort mehr Gewicht.
Außerdem kennen Entwickler ihren Code besser als jeder Sicherheitsmann. Für eine Person, die mindestens 5 Projekte in einem statischen Analysetool hat, ist es normalerweise schwierig, sich alle Nuancen zu merken. Security Champions kennen ihr Produkt: Was mit was interagiert und worauf man überhaupt achten muss – sie sind effizienter.
Erwägen Sie daher die Implementierung von Security Champions und die Erweiterung des Einflusses des Sicherheitsteams. Für den Champion selbst ist dies auch nützlich: berufliche Weiterentwicklung in einem neuen Bereich, Erweiterung des technischen Horizonts, Förderung technischer, Management- und Führungsfähigkeiten, Steigerung des Marktwerts. Dies ist ein Element des Social Engineering, Ihre „Augen“ im Entwicklungsteam.
Testphasen
sagt, dass 20 % der Bemühungen 80 % der Ergebnisse liefern. Bei diesen 20 % handelt es sich um Anwendungsanalysepraktiken, die automatisiert werden können und sollten. Beispiele für solche Aktivitäten sind statische Analysen − SAST, dynamische Analyse – DAST и Open-Source-Steuerung. Ich erzähle Ihnen mehr über Aktivitäten sowie über Tools, welche Funktionen uns normalerweise begegnen, wenn sie in den Prozess eingeführt werden, und wie man sie richtig macht.
Hauptprobleme des Werkzeugs
Ich werde die Probleme hervorheben, die für alle Instrumente relevant sind, die Aufmerksamkeit erfordern. Ich werde sie genauer analysieren, um sie nicht noch einmal zu wiederholen.
Lange Analysezeit. Wenn vom Commit bis zur Veröffentlichung für alle Tests und die Montage 30 Minuten vergehen, dann dauern die Informationssicherheitsprüfungen einen Tag. Es wird also niemand den Prozess verlangsamen. Betrachten Sie diese Funktion und ziehen Sie Schlussfolgerungen.
Hohe Falsch-Negativ- oder Falsch-Positiv-Werte. Alle Produkte sind unterschiedlich, alle verwenden unterschiedliche Frameworks und ihren eigenen Codierungsstil. Auf verschiedenen Codebasen und Technologien können Tools unterschiedliche Grade von Falsch-Negativ und Falsch-Positiv anzeigen. Schauen Sie also, was drin ist Ihre Unternehmen und für dein Anwendungen zeigen ein gutes und zuverlässiges Ergebnis.
Keine Integrationen mit vorhandenen Tools. Schauen Sie sich die Tools im Hinblick auf die Integration mit dem an, was Sie bereits verwenden. Wenn Sie beispielsweise Jenkins oder TeamCity haben, überprüfen Sie die Integration von Tools mit dieser Software und nicht mit GitLab CI, das Sie nicht verwenden.
Mangelnde oder übermäßige Komplexität der Anpassung. Wenn das Tool keine API hat, warum wird sie dann benötigt? Alles, was in der Schnittstelle getan werden kann, sollte über die API verfügbar sein. Idealerweise sollte das Tool über die Möglichkeit verfügen, Prüfungen individuell anzupassen.
Keine Produktentwicklungs-Roadmap. Die Entwicklung steht nicht still, wir nutzen immer neue Frameworks und Funktionen, schreiben alten Code in neue Sprachen um. Wir möchten sicherstellen, dass das von uns gekaufte Tool neue Frameworks und Technologien unterstützt. Daher ist es wichtig zu wissen, dass das Produkt echt und korrekt ist Entwicklung.
Prozessmerkmale
Berücksichtigen Sie neben den Funktionen der Tools auch die Funktionen des Entwicklungsprozesses. Beispielsweise ist es ein typischer Fehler, in die Entwicklung einzugreifen. Sehen wir uns an, welche weiteren Funktionen berücksichtigt werden sollten und worauf das Sicherheitsteam achten sollte.
Um die Entwicklungs- und Veröffentlichungsfristen nicht zu stören, erstellen Sie unterschiedliche Regeln und anders Showstopper - Kriterien zum Stoppen des Build-Prozesses bei Vorhandensein von Schwachstellen - für verschiedene Umgebungen. Wir wissen zum Beispiel, dass der aktuelle Zweig zu einem Entwicklungsstand oder UAT geht, also halten wir nicht inne und sagen:
- Sie haben hier Schwachstellen, Sie werden nirgendwo weitergehen!
An dieser Stelle ist es wichtig, den Entwicklern mitzuteilen, dass es Sicherheitsprobleme gibt, auf die sie achten müssen.
Das Vorhandensein von Schwachstellen stellt kein Hindernis für weitere Tests dar: Handbuch, Integration oder Handbuch. Andererseits müssen wir die Sicherheit des Produkts irgendwie verbessern, damit die Entwickler nicht aufgrund der Sicherheitsergebnisse punkten. Deshalb machen wir manchmal Folgendes: Wenn es am Stand in die Entwicklungsumgebung eingeführt wird, benachrichtigen wir einfach die Entwicklung:
- Leute, ihr habt Probleme, bitte achtet darauf.
In der UAT-Phase zeigen wir erneut Warnungen vor Schwachstellen an, und in der Exit-Phase im Prom sagen wir:
„Leute, wir haben euch mehrmals gewarnt, ihr habt nichts getan – wir lassen euch damit nicht raus.“
Wenn wir über Code und Dynamik sprechen, ist es notwendig, nur Schwachstellen der Funktionen und des Codes anzuzeigen und vor ihnen zu warnen, der gerade in dieser Funktion geschrieben wurde. Wenn der Entwickler den Button um 3 Pixel verschoben hat und wir ihm sagen, dass er dort eine SQL-Injection hat und daher dringend behoben werden muss, ist das falsch. Schauen Sie sich nur an, was jetzt geschrieben steht, und sehen Sie sich die Änderungen an, die sich in der Anwendung ergeben.
Nehmen wir an, wir haben einen Funktionsfehler – die Art und Weise, wie die Anwendung nicht funktionieren sollte: Es wird kein Geld überwiesen, wenn Sie auf die Schaltfläche klicken, erfolgt kein Übergang zur nächsten Seite oder das Produkt wird nicht geladen. Sicherheitsmängel - Es handelt sich um die gleichen Mängel, allerdings nicht im Zusammenhang mit der Anwendung, sondern der Sicherheit.
Nicht alle Softwarequalitätsprobleme sind Sicherheitsprobleme. Aber alle Sicherheitsprobleme hängen mit der Qualität der Software zusammen. Sherif Mansour, Expedia.
Da es sich bei allen Schwachstellen um dieselben Mängel handelt, sollten sie an derselben Stelle liegen wie alle Entwicklungsfehler. Vergessen Sie also Berichte und gruselige PDFs, die niemand liest.
Als ich für ein Entwicklungsunternehmen arbeitete, erhielt ich einen Bericht von statischen Analysetools. Ich öffnete es, war entsetzt, kochte Kaffee, blätterte in 350 Seiten, schloss es und machte mich an die Arbeit. Große Berichte sind tote Berichte. Normalerweise gehen sie nirgendwo hin, E-Mails werden gelöscht, vergessen, gehen verloren oder das Unternehmen gibt an, dass es Risiken eingeht.
Was zu tun ist? Wir wandeln die bestätigten Fehler, die wir gefunden haben, einfach in eine für die Entwicklung geeignete Form um und fügen sie beispielsweise dem Backlog in Jira hinzu. Mängel werden in der Reihenfolge ihrer Priorität priorisiert und beseitigt, ebenso wie Funktionsmängel und Prüfmängel.
Statische Analyse – SAST
Dies ist eine Codeanalyse auf Schwachstellen., aber es ist nicht dasselbe wie SonarQube. Wir prüfen nicht nur Muster oder Stil. Die Analyse verwendet eine Reihe von Ansätzen: nach Schwachstellenbaum, nach , durch Analyse von Konfigurationsdateien. Das ist alles für den Code selbst.
Vorteile des Ansatzes: Identifizierung von Schwachstellen im Code in einem frühen Entwicklungsstadiumwenn es keine Ständer und fertigen Werkzeuge gibt, und inkrementelle Scanfunktion: Scannt einen Codeabschnitt, der sich geändert hat, und nur die Funktion, die wir gerade ausführen, wodurch die Scanzeit verkürzt wird.
Cons ist die mangelnde Unterstützung der erforderlichen Sprachen.
Erforderliche Integrationen, was meiner subjektiven Meinung nach in den Werkzeugen sein sollte:
- Integrationstool: Jenkins, TeamCity und Gitlab CI.
- Entwicklungsumgebung: Intellij IDEA, Visual Studio. Für einen Entwickler ist es bequemer, nicht in eine unverständliche Schnittstelle zu klettern, die man sich noch merken muss, sondern alle notwendigen Integrationen und Schwachstellen, die er gefunden hat, direkt am Arbeitsplatz in seiner eigenen Entwicklungsumgebung zu sehen.
- Codeüberprüfung: SonarQube und manuelle Überprüfung.
- Fehler-Tracker: Jira und Bugzilla.
Das Bild zeigt einige der besten Vertreter der statischen Analyse.
Es kommt nicht auf die Tools an, sondern auf den Prozess. Daher gibt es Open-Source-Lösungen, die sich auch für die Ausführung des Prozesses eignen.
SAST Open Source wird keine große Anzahl von Schwachstellen oder komplexen Datenflüssen finden, aber sie können und sollten beim Erstellen eines Prozesses verwendet werden. Sie helfen zu verstehen, wie der Prozess aufgebaut sein wird, wer auf Fehler reagiert, wer Bericht erstattet und wer Bericht erstattet. Wenn Sie die erste Phase des Aufbaus der Sicherheit Ihres Codes durchführen möchten, verwenden Sie Open-Source-Lösungen.
Wie kann das integriert werden, wenn Sie am Anfang der Reise stehen und nichts haben: weder CI, noch Jenkins, noch TeamCity? Erwägen Sie die Prozessintegration.
Integration auf CVS-Ebene
Wenn Sie Bitbucket oder GitLab haben, können Sie die Integration auf der Ebene durchführen .
Nach Ereignis Pull-Anfrage, Commit. Sie scannen den Code und zeigen im Build-Status an, dass die Sicherheitsprüfung bestanden oder fehlgeschlagen ist.
Feedback. Natürlich ist immer Feedback nötig. Wenn Sie es nur aus Sicherheitsgründen getan haben, es in eine Kiste gesteckt haben, niemandem etwas davon erzählt haben und dann am Ende des Monats einen Haufen Bugs rausgeworfen haben, dann ist das nicht richtig und nicht gut.
Integration mit Code-Review-System
Einmal haben wir den technischen AppSec-Benutzer in einer Reihe wichtiger Projekte als Standardprüfer festgelegt. Abhängig davon, ob Fehler im neuen Code gefunden wurden oder keine Fehler vorliegen, setzt der Prüfer den Status des Pull-Requests auf „Akzeptieren“ oder „Arbeit erforderlich“ – entweder ist alles in Ordnung, oder Sie müssen finalisieren und auf was genau verlinken zu finalisieren. Für die Integration mit der veröffentlichten Version haben wir die Zusammenführung deaktiviert, wenn der IS-Test nicht bestanden wird. Wir haben dies in die manuelle Codeüberprüfung einbezogen und die übrigen Prozessteilnehmer sahen den Sicherheitsstatus für diesen bestimmten Prozess.
Integration mit SonarQube
Viele haben in Bezug auf die Codequalität. Hier ist es dasselbe – Sie können dieselben Gates nur für SAST-Instrumente erstellen. Es wird dieselbe Schnittstelle geben, dasselbe Qualitätstor, nur wird es aufgerufen Sicherheits-Tor. Und wenn Sie einen Prozess mit SonarQube eingerichtet haben, können Sie dort auch alles problemlos integrieren.
Integration auf CI-Ebene
Auch hier ist alles ganz einfach:
- Auf Augenhöhe mit Autotests, Unit-Tests.
- Aufteilung nach Entwicklungsstadien: Entwickler, Test, Produkt. Es können unterschiedliche Regelsätze oder unterschiedliche Fehlerbedingungen enthalten sein: Wir stoppen die Assembly, wir stoppen die Assembly nicht.
- Synchroner/asynchroner Lauf. Wir warten auf das Ende der Sicherheitstests oder wir warten nicht. Das heißt, wir haben sie einfach gestartet und weitergemacht, und dann bekommen wir den Status, dass alles gut oder schlecht ist.
Es ist alles in einer perfekten rosa Welt. Im wirklichen Leben ist das nicht der Fall, aber wir bemühen uns. Das Ergebnis der Durchführung von Sicherheitsüberprüfungen sollte den Ergebnissen von Unit-Tests ähneln.
Wir haben zum Beispiel ein großes Projekt genommen und beschlossen, es jetzt mit SAST zu scannen – OK. Wir haben dieses Projekt in SAST verschoben, es hat uns 20 Schwachstellen beschert und wir haben eine starke Entscheidung getroffen, dass alles in Ordnung ist. 000 Schwachstellen sind unsere technische Schuld. Wir werden die Schulden in eine Kiste stecken, sie langsam anhäufen und Fehler in den Fehler-Trackern beheben. Beauftragen Sie ein Unternehmen, machen Sie alles selbst oder lassen Sie sich von Security Champions helfen, und die technische Verschuldung wird sinken.
Und alle neu auftretenden Schwachstellen im neuen Code sollten ebenso beseitigt werden wie Fehler in einer Unit oder in Autotests. Relativ gesehen begann die Versammlung, fuhr davon, zwei Tests und zwei Sicherheitstests fielen zusammen. OK - wir sind hingegangen, haben geschaut, was passiert ist, haben eines korrigiert, das zweite korrigiert, sind das nächste Mal gefahren - alles ist in Ordnung, es sind keine neuen Schwachstellen aufgetaucht, die Tests sind nicht fehlgeschlagen. Wenn diese Aufgabe tiefer geht und Sie sie gut verstehen müssen, oder wenn die Behebung von Schwachstellen große Schichten dessen betrifft, was unter der Haube liegt: Ein Fehler wird in den Fehler-Tracker eingebracht, er wird priorisiert und behoben. Leider ist die Welt nicht perfekt und Tests scheitern manchmal.
Ein Beispiel für ein Sicherheitstor ist ein Analogon eines Qualitätstors im Hinblick auf das Vorhandensein und die Anzahl von Schwachstellen im Code.
Wir integrieren SonarQube – das Plugin ist installiert, alles ist sehr praktisch und cool.
Integration der Entwicklungsumgebung
Integrationsmöglichkeiten:
- Starten Sie bereits vor dem Commit einen Scan aus der Entwicklungsumgebung.
- Ergebnisse anzeigen.
- Analyse der Ergebnisse.
- Synchronisierung mit dem Server.
So sieht es aus, Ergebnisse vom Server zu erhalten.
In unserer Entwicklungsumgebung es erscheint lediglich ein zusätzlicher Eintrag, der besagt, dass beim Scan solche Schwachstellen gefunden wurden. Sie können den Code sofort bearbeiten, Empfehlungen anzeigen und . All dies befindet sich am Arbeitsplatz des Entwicklers, was sehr praktisch ist – Sie müssen nicht den restlichen Links folgen und sich etwas extra ansehen.
Open Source
Das ist mein Lieblingsthema. Jeder nutzt Open-Source-Bibliotheken – warum einen Haufen Krücken und Fahrräder schreiben, wenn man eine fertige Bibliothek nehmen kann, in der alles bereits implementiert ist?
Das stimmt natürlich, aber Bibliotheken werden auch von Menschen geschrieben, bergen auch bestimmte Risiken und es gibt auch Schwachstellen, über die regelmäßig oder ständig berichtet wird. Daher gibt es einen nächsten Schritt in der Anwendungssicherheit – dies ist die Analyse von Open-Source-Komponenten.
Open-Source-Analyse – OSA
Das Tool umfasst drei Hauptschritte.
Schwachstellen in Bibliotheken finden. Das Tool weiß zum Beispiel, dass wir eine Art Bibliothek verwenden, und zwar in oder in Bugtrackern gibt es einige Schwachstellen, die sich auf diese Version der Bibliothek beziehen. Wenn Sie versuchen, sie zu verwenden, warnt Sie das Tool, dass die Bibliothek angreifbar ist, und empfiehlt Ihnen, eine andere Version zu verwenden, in der keine Schwachstellen vorliegen.
Analyse der Lizenzreinheit. Dies ist bei uns noch nicht sehr beliebt, aber wenn Sie mit einem fremden Land arbeiten, kann es dort regelmäßig zu Angriffen wegen der Verwendung einer Open-Source-Komponente kommen, die nicht verwendet oder geändert werden kann. Gemäß den Richtlinien der lizenzierten Bibliothek ist dies nicht möglich. Oder wenn wir es geändert haben und verwenden, müssen wir unseren Code veröffentlichen. Natürlich möchte niemand den Code seiner Produkte veröffentlichen, aber auch davor kann man sich schützen.
Analyse von Komponenten, die im industriellen Umfeld eingesetzt werden. Stellen Sie sich eine hypothetische Situation vor, in der wir die Entwicklung endlich abgeschlossen und die neueste Version unseres Microservices für die Branche freigegeben haben. Er lebt dort wunderbar – eine Woche, einen Monat, ein Jahr. Wir sammeln es nicht, wir führen keine Sicherheitskontrollen durch, alles scheint in Ordnung zu sein. Doch plötzlich, zwei Wochen nach der Veröffentlichung, taucht eine kritische Schwachstelle in der Open-Source-Komponente auf, die wir in dieser speziellen Assembly im industriellen Umfeld nutzen. Wenn wir nicht aufzeichnen, was und wo wir verwenden, wird diese Schwachstelle einfach nicht erkannt. Einige Tools verfügen über die Möglichkeit, Schwachstellen in Bibliotheken zu überwachen, die derzeit in Prom verwendet werden. Es ist sehr nützlich.
Features:
- Unterschiedliche Richtlinien für unterschiedliche Entwicklungsstadien.
- Überwachen Sie Komponenten in einer industriellen Umgebung.
- Kontrolle von Bibliotheken im Rahmen der Organisation.
- Unterstützung für verschiedene Build-Systeme und Sprachen.
- Analyse von Docker-Images.
Einige Beispiele von führenden Unternehmen auf diesem Gebiet, die sich mit der Analyse von Open Source beschäftigen.
Das einzig kostenlose ist von OWASP. Sie können es in den ersten Phasen einschalten, sehen, wie es funktioniert und was es unterstützt. Im Grunde handelt es sich dabei alles um Cloud-Produkte bzw. On-Premise-Produkte, aber hinter ihrer Basis verbirgt sich immer noch das Internet. Sie senden nicht Ihre Bibliotheken, sondern Hashes oder deren Werte, die sie berechnen, und Fingerabdrücke an ihren Server, um Nachrichten über das Vorhandensein von Schwachstellen zu erhalten.
Prozessintegration
Kontrolle der Perimeterbibliothekdie von externen Quellen heruntergeladen werden. Wir verfügen über externe und interne Repositories. Wir haben beispielsweise Nexus in Event Central und möchten sicherstellen, dass es in unserem Repository keine Schwachstellen mit dem Status „kritisch“ oder „hoch“ gibt. Sie können Proxying mit dem Nexus Firewall Lifecycle-Tool einrichten, sodass solche Schwachstellen abgeschnitten und nicht in das interne Repository aufgenommen werden.
CI-Integration. Auf gleicher Ebene mit Autotests, Unit-Tests und der Unterteilung in Entwicklungsstufen: Dev, Test, Prod. In jeder Phase können Sie beliebige Bibliotheken herunterladen und alles verwenden. Wenn jedoch etwas mit dem Status „kritisch“ nicht stimmt, sollten Sie die Entwickler wahrscheinlich schon beim Betreten des Abschlussballs darauf aufmerksam machen.
Artefaktintegration: Nexus und JFrog.
Integration in die Entwicklungsumgebung. Die von Ihnen ausgewählten Tools sollten in Entwicklungsumgebungen integriert sein. Der Entwickler muss von seinem Arbeitsplatz aus Zugriff auf die Scanergebnisse haben oder die Möglichkeit haben, den Code zu scannen und auf Schwachstellen zu prüfen, bevor er ihn in CVS festschreibt.
CD-Integration. Das ist eine coole Funktion, die mir wirklich gefällt und über die ich bereits gesprochen habe – die Überwachung der Entstehung neuer Schwachstellen in einer industriellen Umgebung. Es funktioniert so.
Wir haben Öffentliche Komponenten-Repositorys - einige Tools außerhalb und unser internes Repository. Wir möchten, dass nur vertrauenswürdige Komponenten darin enthalten sind. Beim Weiterleiten einer Anfrage prüfen wir, ob die heruntergeladene Bibliothek keine Schwachstellen aufweist. Wenn es unter bestimmte Richtlinien fällt, die wir festlegen und unbedingt mit der Entwicklung abstimmen, dann laden wir es nicht hoch und erhalten eine Abweisung, eine andere Version zu verwenden. Wenn die Bibliothek also etwas wirklich Kritisches und Schlechtes enthält, erhält der Entwickler die Bibliothek nicht einmal in der Installationsphase – lassen Sie ihn eine höhere oder niedrigere Version verwenden.
- Beim Bau achten wir darauf, dass niemand etwas Schlimmes verrutscht, alle Komponenten sicher sind und niemand etwas Gefährliches auf den USB-Stick gebracht hat.
- Wir haben nur vertrauenswürdige Komponenten im Repository.
- Beim Deployment überprüfen wir noch einmal das Paket selbst: war, jar, DL oder Docker-Image, ob es der Richtlinie entspricht.
- Beim Betreten des industriellen Umfelds überwachen wir, was im industriellen Umfeld passiert: Kritische Schwachstellen treten auf oder nicht.
Dynamische Analyse – DAST
Dynamische Analysewerkzeuge unterscheiden sich grundlegend von allem bisher Gesagten. Dies ist eine Art Nachahmung der Arbeit des Benutzers mit der Anwendung. Wenn es sich um eine Webanwendung handelt, senden wir Anfragen, die die Arbeit des Kunden imitieren, klicken auf die Schaltflächen auf der Vorderseite und senden künstliche Daten aus dem Formular: Anführungszeichen, Klammern, Zeichen in verschiedenen Kodierungen, um zu sehen, wie die Anwendung funktioniert und externe Prozesse verarbeitet Daten.
Mit demselben System können Sie in Open Source nach Vorlagenschwachstellen suchen. Da DAST nicht weiß, welche Open Source wir verwenden, wirft es einfach „bösartige“ Muster aus und analysiert die Antworten des Servers:
- Ja, hier gibt es ein Deserialisierungsproblem, aber nicht hier.
Das birgt große Risiken, denn wenn Sie diesen Sicherheitstest am selben Stand durchführen, an dem auch die Tester arbeiten, können unangenehme Dinge passieren.
- Hohe Belastung des Anwendungsservernetzwerks.
- Keine Integrationen.
- Die Möglichkeit, die Einstellungen der analysierten Anwendung zu ändern.
- Es gibt keine Unterstützung für die notwendigen Technologien.
- Schwierigkeiten beim Einstellen.
Als wir AppScan endlich starteten, hatten wir eine Situation: Wir haben den Zugriff auf die Anwendung für lange Zeit gesperrt, 3 Konten erhalten und waren begeistert – endlich werden wir alles überprüfen! Wir haben einen Scan gestartet, und das erste, was AppScan getan hat, war, in das Admin-Panel einzudringen, alle Schaltflächen zu durchsuchen, die Hälfte der Daten zu ändern und dann den Server mit seinen eigenen vollständig zu zerstören -Anfragen. Entwicklung mit Testen sagte:
„Leute, macht ihr Witze?! Wir haben Ihnen Rechenschaft gegeben, und Sie haben Stellung bezogen!
Berücksichtigen Sie mögliche Risiken. Bereiten Sie idealerweise einen separaten Stand zum Testen der Informationssicherheit vor, der zumindest irgendwie vom Rest der Umgebung isoliert ist, und überprüfen Sie das Admin-Panel bedingt, vorzugsweise im manuellen Modus. Dies ist ein Pentest – die verbleibenden Prozentsätze der Bemühungen, die wir derzeit nicht berücksichtigen.
Es ist zu bedenken, dass Sie dies als Analogon zum Lasttest verwenden können. In der ersten Phase können Sie den dynamischen Scanner in 10-15 Threads einschalten und sehen, was passiert, aber normalerweise, wie die Praxis zeigt, nichts Gutes.
Einige Ressourcen, die wir normalerweise verwenden.
Hervorhebenswert ist das „Schweizer Messer“ für jeden Sicherheitsprofi. Jeder nutzt es und es ist sehr praktisch. Nun ist eine neue Demoversion der Enterprise Edition erschienen. War es früher nur ein eigenständiges Dienstprogramm mit Plugins, erstellen Entwickler jetzt endlich einen großen Server, von dem aus mehrere Agenten verwaltet werden können. Es ist cool, ich empfehle dir, es auszuprobieren.
Prozessintegration
Die Integration ist ziemlich gut und einfach: Starten Sie den Scan nach erfolgreicher Installation Anwendungen am Stand und Scannen nach erfolgreichem Integrationstest.
Wenn die Integrationen nicht funktionieren oder Stubs und Mock-Funktionen vorhanden sind, ist das bedeutungslos und nutzlos – egal welches Muster wir senden, der Server wird immer noch auf die gleiche Weise reagieren.
- Idealerweise ein separater Prüfstand.
- Notieren Sie sich vor dem Test die Anmeldesequenz.
- Das Testen des Verwaltungssystems erfolgt ausschließlich manuell.
Prozess
Ein wenig allgemeiner Überblick über den Prozess im Allgemeinen und über die Funktionsweise der einzelnen Tools im Besonderen. Alle Anwendungen sind unterschiedlich – eine funktioniert besser mit dynamischer Analyse, eine andere mit statischer Analyse, die dritte mit OpenSource-Analyse, Pentests oder etwas ganz anderem, zum Beispiel mit Events .
Jeder Prozess muss kontrolliert werden.
Um zu verstehen, wie der Prozess funktioniert und wo er verbessert werden kann, müssen Sie Metriken von allem sammeln, was Ihnen in die Finger kommt, einschließlich Produktionsmetriken, Metriken von Tools und Fehlerverfolgungsgeräten.
Alle Informationen sind hilfreich. In verschiedenen Abschnitten muss untersucht werden, wo dieses oder jenes Werkzeug besser eingesetzt wird, wo der Prozess konkret durchhängt. Es kann sich lohnen, einen Blick auf die Reaktionszeit der Entwicklung zu werfen, um herauszufinden, wo sich der Prozess zeitlich verbessern lässt. Je mehr Daten, desto mehr Schnitte können von der obersten Ebene bis zu den Details jedes Prozesses erstellt werden.
Da alle statischen und dynamischen Analysatoren über eigene APIs, eigene Startmethoden und Prinzipien verfügen und einige über Scheduler verfügen, andere nicht, schreiben wir ein Tool AppSec Orchestrator, was es Ihnen ermöglicht, vom Produkt aus einen einzigen Einstiegspunkt für den gesamten Prozess zu schaffen und ihn von einem Punkt aus zu verwalten.
Manager, Entwickler und Sicherheitsingenieure haben einen zentralen Einstiegspunkt, von dem aus sie sehen können, was gerade ausgeführt wird, Scans konfigurieren und ausführen, Scan-Ergebnisse abrufen und Anforderungen einreichen können. Wir versuchen, von Papierstücken wegzukommen und alles in eine menschliche Sprache zu übersetzen, die die Entwicklung verwendet – Seiten zu Confluence mit Status und Metriken, Fehler in Jira oder in verschiedenen Fehler-Trackern oder die Einbettung in einen synchronen/asynchronen Prozess in CI/CD.
Key Take Away
Die Werkzeuge spielen keine Rolle. Denken Sie zuerst über den Prozess nach und implementieren Sie dann die Tools. Die Tools sind gut, aber teuer, sodass Sie mit dem Prozess beginnen und die Interaktion und das Verständnis zwischen Entwicklung und Sicherheit verfeinern können. Aus Sicht der Sicherheit besteht keine Notwendigkeit, alles hintereinander zu „stoppen“. Aus Sicht der Entwicklung gilt: Wenn es etwas Mega-Superkritisches gibt, muss dieses beseitigt und nicht dem Problem verschlossen werden .
Produktqualität - gemeinsames Ziel sowohl Sicherheit als auch Entwicklung. Wir tun eines: Wir versuchen sicherzustellen, dass alles ordnungsgemäß funktioniert und keine Reputationsrisiken und finanziellen Verluste entstehen. Deshalb fördern wir den Ansatz von DevSecOps, SecDevOps, um Kommunikation aufzubauen und das Produkt besser zu machen.
Beginnen Sie mit dem, was bereits vorhanden ist: Anforderungen, Architektur, Teilprüfungen, Schulungen, Richtlinien. Es ist nicht notwendig, alle Praktiken sofort auf alle Projekte anzuwenden – iterativ bewegen. Es gibt keinen einheitlichen Standard Experiment und probieren Sie verschiedene Ansätze und Lösungen aus.
Gleiches Vorzeichen zwischen IS-Mängeln und Funktionsmängeln.
Automatisieren Sie allesdas ist bewegend. Alles, was sich nicht bewegt, bewegt und automatisiert. Wenn etwas von Hand gemacht wird, ist das kein guter Teil des Prozesses. Vielleicht lohnt es sich, es noch einmal zu überdenken und zu automatisieren.
Wenn die Größe des IB-Teams klein ist – Verwenden Sie Sicherheitschampions.
Vielleicht passt das, worüber ich gesprochen habe, nicht zu Ihnen und Sie lassen sich etwas Eigenes einfallen – und das ist gut so. Aber Wählen Sie Werkzeuge entsprechend den Anforderungen Ihres Prozesses aus. Schauen Sie nicht darauf, was die Community sagt, dass dieses Tool schlecht und dieses gut ist. Vielleicht ist es bei Ihrem Produkt umgekehrt.
Werkzeuganforderungen.
- Niedrig falsch positiv.
- Ausreichende Analysezeit.
- Benutzerfreundlichkeit.
- Verfügbarkeit von Integrationen.
- Verstehen der Produktentwicklungs-Roadmap.
- Möglichkeit zur individuellen Anpassung von Tools.
Yuriys Bericht wurde auf der DevOpsConf 2018 zu einem der besten gewählt. Um noch mehr interessante Ideen und praktische Fälle kennenzulernen, kommen Sie am 27. und 28. Mai nach Skolkovo im Rahmen . Noch besser ist es, wenn Sie bereit sind, Ihre Erfahrungen zu teilen Reichen Sie Ihren Bericht bis zum 21. April ein.
Source: habr.com