{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Angst und Hass in DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wir hatten 2 Code-Analyzer, 4 Werkzeuge f\u00fcr 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.<\/p>\n

\"Angst
\n
\nQuelle<\/a><\/noindex>. Die Charaktere wurden von Justin Roiland und Dan Harmon kreiert.<\/i><\/p>\n

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<\/b> von\u00a0Swordfish Security. <\/b>Juri wird ausf\u00fchrlich auf alles eingehen und die Probleme des \u00dcbergangs vom klassischen Modell der Application Security zum DevSecOps-Prozess erl\u00e4utern: 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\u00f6nnen, wie sie sich unterscheiden und wie sie richtig konfiguriert werden, um Fallstricke zu vermeiden.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\n\u00dcber den Sprecher:<\/b> Juri Schabalin ist <\/b>Chief Security Architect bei der Swordfish Security<\/b>. Ist verantwortlich f\u00fcr die Implementierung von SSDL und f\u00fcr die gesamte Integration von Analysetools in ein einheitliches Entwicklungs- und Test-\u00d6kosystem. 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.<\/p>\n

Anwendungssicherheit: Worum geht es?<\/h2>\n

\nAnwendungssicherheit<\/b>\u00a0ist 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 \u2013 das sind die Schwachstellen und Verwundbarkeiten der Anwendungen selbst.<\/p>\n

Bereich SDL oder SDLC<\/a><\/noindex>\u00a0\u2014 Sicherheitsentwicklungslebenszyklus<\/b>\u00a0wurde 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\u00fccksichtigen, von den Anforderungen bis zur Ver\u00f6ffentlichung 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.<\/p>\n

\"Angst
\n
\nApplication Security und SSDL zielen nicht darauf ab, Schwachstellen zu entdecken, wie h\u00e4ufig angenommen, sondern darauf, deren Entstehung zu verhindern. Im Laufe der Zeit wurde der klassische Ansatz von Microsoft verbessert und vertieft, um ein detaillierteres Verst\u00e4ndnis zu erm\u00f6glichen.<\/p>\n

\"Angst
\n
\nDer klassische SDLC ist stark in verschiedenen Methoden detailliert \u2014 OpenSAMM, BSIMM, OWASP. Die Methoden unterscheiden sich, sind jedoch im Gro\u00dfen und Ganzen \u00e4hnlich.<\/p>\n

Building Security In Maturity Model<\/h3>\n

\nEs liegt mir am meisten am Herzen BSIMM<\/b>\u00a0\u2014 Building Security In Maturity Model<\/a><\/noindex>. Die Grundlage der Methodik ist die Aufteilung des Application Security Prozesses in 4 Dom\u00e4nen: Governance, Intelligence, SSDL Touchpoints und Deployment. Jede Dom\u00e4ne umfasst 12 Praktiken, die in Form von 112 Aktivit\u00e4ten dargestellt werden.<\/p>\n

\"Angst
\n
\nJede der 112 Aktivit\u00e4ten hat 3 Reifegrade<\/b>: initial, mittel und fortgeschritten. Alle 12 Praktiken k\u00f6nnen modular studiert werden, um wichtige Aspekte auszuw\u00e4hlen, zu verstehen, wie sie implementiert werden k\u00f6nnen, und schrittweise Elemente wie statische und dynamische Codeanalyse oder Code-Reviews hinzuzuf\u00fcgen. Erstellen Sie einen Plan und arbeiten Sie ruhig im Rahmen der Umsetzung der gew\u00e4hlten Aktivit\u00e4ten.<\/p>\n

Warum DevSecOps<\/h2>\n

<\/p>\n

DevOps ist ein umfassender Prozess, der die Sicherheitsaspekte mit einbezieht.<\/p><\/blockquote>\n

\nUrspr\u00fcnglich DevOps<\/b><\/a><\/noindex> Die Sicherheits\u00fcberpr\u00fcfungen waren anf\u00e4nglich nicht optimal organisiert. In der Praxis war die Gr\u00f6\u00dfe der Sicherheitsgruppen deutlich geringer als heute, und sie agierten eher als Kontroll- und Aufsichtsinstanz, die Anforderungen stellt und die Qualit\u00e4t des Produkts nach der Ver\u00f6ffentlichung \u00fcberpr\u00fcft. Dies ist der klassische Ansatz, bei dem Sicherheitsgruppen von der Entwicklung getrennt waren und nicht am Prozess teilnahmen.<\/p>\n

\"Angst
\n
\nDas Hauptproblem besteht darin, dass die Informationssicherheit getrennt von der Entwicklung ist. \u00dcblicherweise gibt es einen Sicherheitsrahmen, der aus 2-3 gro\u00dfen und teuren Werkzeugen besteht. Alle sechs Monate wird der Quellcode oder die Anwendung geliefert, die gepr\u00fcft werden m\u00fcssen, und einmal im Jahr finden Pentests<\/a><\/noindex>statt. Das alles f\u00fchrt dazu, dass sich die Markteinf\u00fchrungsfristen verz\u00f6gern und Entwickler mit einer riesigen Anzahl von Schwachstellen aus automatisierten Tools konfrontiert werden. All das l\u00e4sst sich nicht bew\u00e4ltigen und beheben, da die Ergebnisse aus den letzten sechs Monaten noch nicht ausgewertet wurden und bereits eine neue Charge ansteht.<\/p>\n

Im Verlauf unserer T\u00e4tigkeit 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 \u2013 in\u00a0Agile<\/b><\/a><\/noindex>. Das DevSecOps-Paradigma passt hervorragend zu agilen Entwicklungsmethoden, zur Implementierung, zum Support und zur Beteiligung an jedem Release und jeder Iteration.<\/p>\n

\"Angst
\n<\/p>\n

Der \u00dcbergang zu DevSecOps<\/h2>\n

\nDas wichtigste Wort im Security Development Lifecycle ist \u201eProzess\u201c<\/b>. Sie sollten das verstehen, bevor Sie dar\u00fcber nachdenken, Werkzeuge zu kaufen.<\/p>\n

Es reicht nicht aus, Werkzeuge einfach in den DevOps-Prozess einzuf\u00fcgen \u2013 wichtig ist die Interaktion und das Verst\u00e4ndnis zwischen den Beteiligten.<\/p><\/blockquote>\n

<\/p>\n

Menschen sind wichtiger als Werkzeuge<\/h3>\n

\nH\u00e4ufig 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\u00e4ufig nicht gelingt. Das f\u00fchrt zu unerfreulichen Ergebnissen, da jedes Werkzeug seine eigenen Besonderheiten und Einschr\u00e4nkungen hat.<\/p>\n

Ein h\u00e4ufiges Szenario ist, dass die Sicherheitsabteilung ein gutes, teures Tool mit umfangreichen Funktionen ausw\u00e4hlt und dann zu den Entwicklern kommt, um es im Prozess zu integrieren. Doch das funktioniert nicht \u2013 der Prozess ist so gestaltet, dass die Einschr\u00e4nkungen des bereits gekauften Tools nicht in das aktuelle Paradigma passen.<\/p>\n

Beginnen Sie damit, das gew\u00fcnschte Ergebnis und den Ablauf des Prozesses zu beschreiben. Dies hilft, die Rollen des Tools und der Sicherheit im Prozess klarzustellen.<\/p><\/blockquote>\n

<\/p>\n

Starten Sie mit dem, was bereits verwendet wird.<\/h3>\n

\nBevor Sie teure Tools kaufen, schauen Sie sich an, was Sie bereits haben. Jedes Unternehmen hat Sicherheitsanforderungen, die an die Entwicklung gestellt werden, sowie Pr\u00fcfungen und Penetrationstests \u2013 warum nicht alles in eine verst\u00e4ndliche und f\u00fcr alle n\u00fctzliche Form bringen?<\/p>\n

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\u00fcr die Software fragten. Der zust\u00e4ndige Spezialist suchte lange:<\/p>\n

\u2014 Moment, irgendwo in meinen Notizen war der Weg, wo dieses Dokument aufbewahrt wird.<\/i><\/p>\n

Letztendlich erhielten wir das Dokument nach einer Woche.<\/p>\n

F\u00fcr Anforderungen, Pr\u00fcfungen und \u00c4hnliches erstellen Sie beispielsweise eine Seite auf\u00a0Confluence<\/b>\u00a0\u2014 das ist f\u00fcr alle praktisch.<\/p>\n

Es ist einfacher, das Vorhandene umzustrukturieren und als Ausgangspunkt zu nutzen.<\/p><\/blockquote>\n

<\/p>\n

Nutzen Sie Security Champions <\/h3>\n

\nIn der Regel gibt es in einem durchschnittlichen Unternehmen mit 100-200 Entwicklern einen Sicherheitsexperten, der mehrere Funktionen aus\u00fcbt und physisch nicht in der Lage ist, alles zu \u00fcberpr\u00fcfen. Selbst wenn er sein Bestes gibt, kann er nicht den gesamten Code \u00fcberpr\u00fcfen, den die Entwickler generieren. F\u00fcr solche F\u00e4lle wurde das Konzept entwickelt \u2014 Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions sind Personen innerhalb des Entwicklungsteams, die sich f\u00fcr die Sicherheit Ihres Produkts einsetzen.<\/p><\/blockquote>\n

\"Angst
\n
\nEin Security Champion ist der Ansprechpartner im Entwicklungsteam und ein Sicherheitsevangelist in einer Person.<\/p>\n

Normalerweise, wenn ein Sicherheitsexperte in ein Entwicklungsteam kommt und auf einen Fehler im Code hinweist, erh\u00e4lt er erstaunte Antworten:<\/p>\n

\u2014 Und wer sind Sie? Ich sehe Sie zum ersten Mal. Bei mir ist alles in Ordnung \u2014 mein Mentor hat bei der Code-\u00dcberpr\u00fcfung \"apply\" gesetzt, wir machen weiter!<\/i><\/p>\n

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

Zudem kennen Entwickler ihren Code besser als jeder Sicherheitsexperte. F\u00fcr jemanden, der in der Regel an mindestens f\u00fcnf 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\u00fcssen \u2013 sie sind effizienter.<\/p>\n

Denken Sie dar\u00fcber nach, Security Champions einzuf\u00fchren und den Einfluss Ihres Sicherheitsteams zu erweitern. Es ist auch f\u00fcr den Champion selbst von Vorteil: berufliche Weiterentwicklung in einem neuen Bereich, Erweiterung des technischen Horizonts, Verbesserung technischer, organisatorischer und F\u00fchrungsf\u00e4higkeiten sowie Steigerung des Marktwerts. Es ist eine Art soziale Ingenieurskunst, Ihre 'Augen' im Entwicklungsteam.<\/p>\n

Testphasen<\/h2>\n

\nParadigma 20 zu 80<\/a><\/noindex>\u00a0sagt, dass 20% des Aufwands 80% des Ergebnisses bringen. Diese 20% sind Praktiken der Analyse von Anwendungen, die automatisiert werden k\u00f6nnen und sollten. Beispiele f\u00fcr solche Aktivit\u00e4ten sind statische Analyse \u2014 SAST<\/b>, dynamische Analyse \u2014 DAST,<\/b> und\u00a0Kontrolle von Open Source<\/b>. Ich werde n\u00e4her auf die Aktivit\u00e4ten eingehen und auch auf die Werkzeuge, welche Besonderheiten wir normalerweise bei deren Implementierung im Prozess ber\u00fccksichtigen und wie man dies richtig umsetzt.<\/p>\n

\"Angst
\n<\/p>\n

Wesentliche Probleme der Werkzeuge<\/h3>\n

\nIch werde die f\u00fcr alle Werkzeuge relevanten Probleme herausstellen, die Aufmerksamkeit erfordern. Ich werde sie im Detail erl\u00e4utern, um Wiederholungen zu vermeiden.<\/p>\n

Lange Analysezeiten. <\/b>Wenn von der Commits bis zur Production 30 Minuten f\u00fcr alle Tests und den Build ben\u00f6tigt werden, wird die \u00dcberpr\u00fcfung der Informationssicherheit einen Tag in Anspruch nehmen. Niemand m\u00f6chte den Prozess dadurch verlangsamen. Ber\u00fccksichtigen Sie dieses Merkmal und ziehen Sie Ihre Schl\u00fcsse.<\/p>\n

Hoher Anteil an False Negatives oder False Positives. <\/b>Alle Produkte sind unterschiedlich, alle verwenden unterschiedliche Frameworks und ihren eigenen Schreibstil. Je nach Codebasis und Technologien k\u00f6nnen die Werkzeuge unterschiedliche Werte f\u00fcr False Negatives und False Positives anzeigen. Daher sollten Sie darauf achten, was genau in\u00a0Ihrem<\/b> Unternehmen und f\u00fcr Ihre<\/b> Anwendungen werden gute und zuverl\u00e4ssige Ergebnisse zeigen.<\/p>\n

Keine Integrationen mit bestehenden Tools.<\/b>. Betrachten Sie Tools aus der Perspektive der Integrationen mit dem, was Sie bereits verwenden. Wenn Sie beispielsweise Jenkins oder TeamCity haben, \u00fcberpr\u00fcfen Sie die Integration der Tools genau mit dieser Software und nicht mit GitLab CI, das Sie nicht verwenden.<\/p>\n

Fehlende oder \u00fcberm\u00e4\u00dfig komplexe Anpassungsm\u00f6glichkeiten. <\/b>Wenn das Tool keine API hat, wozu ist es dann gut? Alles, was im Interface m\u00f6glich ist, sollte auch \u00fcber die API zug\u00e4nglich sein. Idealerweise sollte das Tool die M\u00f6glichkeit zur Anpassung von Pr\u00fcfungen bieten.<\/p>\n

Kein Entwicklungs-Roadmap f\u00fcr das Produkt. <\/b>Die Entwicklung steht nicht still; wir nutzen st\u00e4ndig neue Frameworks und Funktionen, \u00fcberarbeiten alten Code in neue Programmiersprachen. Wir m\u00f6chten sicherstellen, dass das Tool, das wir kaufen, neue Frameworks und Technologien unterst\u00fctzt. Daher ist es wichtig zu wissen, dass das Produkt einen echten und klaren Roadmap<\/a><\/noindex> der Entwicklung hat.<\/p>\n

Besonderheiten des Prozesses.<\/h3>\n

\nBer\u00fccksichtigen Sie neben den Funktionen der Werkzeuge auch die Besonderheiten des Entwicklungsprozesses. Ein typischer Fehler ist, die Entwicklung zu st\u00f6ren. Lassen Sie uns betrachten, welche weiteren Besonderheiten zu beachten sind und worauf das Sicherheitsteam achten sollte.<\/p>\n

Um Termine f\u00fcr Entwicklung und Release nicht zu gef\u00e4hrden, erstellen Sie verschiedene Regeln<\/b> und verschiedene Showstoppers\u00a0<\/b>\u2014 Kriterien, die den Prozess der Zusammenstellung bei Vorhandensein von Schwachstellen stoppen \u2014 f\u00fcr verschiedene Umgebungen.<\/b>Zum Beispiel verstehen wir, dass der aktuelle Branch in die Entwicklungsumgebung oder UAT geht, daher stoppen wir nicht und sagen nicht:<\/p>\n

\u2014 Sie haben hier Schwachstellen, Sie kommen nicht weiter!<\/i><\/p>\n

An dieser Stelle ist es wichtig, den Entwicklern zu sagen, dass es Sicherheitsprobleme gibt, auf die sie achten sollten.<\/p>\n

Das Vorhandensein von Schwachstellen ist kein Hindernis f\u00fcr weitere Tests<\/b>: ob manuelle, Integration oder manuelle Tests. Auf der anderen Seite m\u00fcssen wir die Sicherheit des Produkts irgendwie erh\u00f6hen, und wir m\u00f6chten nicht, dass die Entwickler ignorieren, was die Sicherheitsteams finden. Daher gehen wir manchmal folgenderma\u00dfen vor: Wenn auf dem Stand, wenn wir in die Entwicklungsumgebung ausrollen, benachrichtigen wir einfach die Entwicklung:<\/p>\n

\u2014\u00a0Bitte, falls Sie Probleme haben, achten Sie darauf.<\/i><\/p>\n

In der UAT-Phase zeigen wir wieder Warnungen zu Sicherheitsanf\u00e4lligkeiten, und in der Produktionsphase sagen wir:<\/p>\n

\u2014\u00a0Wir haben Sie bereits mehrmals gewarnt, Sie haben nichts unternommen \u2013 damit werden wir Sie nicht freigeben.<\/i><\/p>\n

Wenn es um Code und Dynamik geht, sollten wir nur \u00fcber Sicherheitsanf\u00e4lligkeiten 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 \u2013 das ist nicht richtig. Schauen Sie sich nur an, was jetzt geschrieben wurde, und die \u00c4nderungen, die in die Anwendung kommen.<\/p>\n

Nehmen wir an, wir haben einen funktionalen Defekt \u2013 etwas, das die Anwendung nicht korrekt macht: Geld wird nicht \u00fcberwiesen, beim Klicken auf einen Button wird nicht zur n\u00e4chsten Seite navigiert oder das Produkt wird nicht geladen. Sicherheitsdefekte<\/b>\u00a0\u2013 sind ebenso Defekte, jedoch nicht im Hinblick auf die Funktion der Anwendung, sondern auf die Sicherheit. <\/p>\n

Nicht alle Probleme der Softwarequalit\u00e4t sind Sicherheitsprobleme. Aber alle Sicherheitsprobleme h\u00e4ngen mit der Softwarequalit\u00e4t zusammen. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nDa alle Sicherheitsl\u00fccken 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.<\/p>\n

\"Angst
\n
\nAls ich f\u00fcr ein Softwareentwicklungsunternehmen t\u00e4tig war, erhielt ich einen Bericht von den statischen Analysetools. Ich \u00f6ffnete ihn, war entsetzt, machte mir einen Kaffee, bl\u00e4tterte durch 350 Seiten, schloss ihn und machte mit meiner Arbeit weiter. Umfangreiche Berichte sind tote Berichte.<\/b>Normalerweise verschwinden sie irgendwo, E-Mails werden gel\u00f6scht, vergessen, verlieren sich oder das Unternehmen sagt, es akzeptiere die Risiken.<\/p>\n

Was tun? Die best\u00e4tigten Fehler, die gefunden wurden, wandeln wir einfach in ein entwicklerfreundliches Format um, indem wir sie zum Beispiel in den Backlog in Jira einf\u00fcgen. Wir priorisieren die Fehler und beheben sie der Rangfolge nach, ebenso wie funktionale Fehler und Testfehler.<\/p>\n

Statische Analyse \u2013 SAST<\/h2>\n

\nDies ist eine Analyse des Codes auf Sicherheitsanf\u00e4lligkeiten<\/b>, aber es ist nicht dasselbe wie SonarQube. Wir \u00fcberpr\u00fcfen nicht nur anhand von Mustern oder Stilen. Bei der Analyse kommen verschiedene Ans\u00e4tze zur Anwendung: anhand des Schwachstellenschemas, basierend auf\u00a0DataFlow<\/a><\/noindex>, sowie durch die Analyse von Konfigurationsdateien. Dies betrifft alles, was direkt mit dem Code zu tun hat.<\/p>\n

Vorteile des Ansatzes<\/b>: Identifikation von Schwachstellen im Code in einer fr\u00fchen Entwicklungsphase<\/b>, wenn es noch keine St\u00e4nde und kein fertiges Tool gibt, und\u00a0die M\u00f6glichkeit des inkrementellen Scannens<\/b>: Scannen des Codeabschnitts, der sich ge\u00e4ndert hat, und nur der Funktion, an der wir gerade arbeiten, was die Scandauer verk\u00fcrzt.<\/p>\n

Nachteile<\/b>\u00a0\u2014 es fehlt die Unterst\u00fctzung f\u00fcr die erforderlichen Programmiersprachen.<\/p>\n

Notwendige Integrationen, <\/b>die meiner subjektiven Meinung nach in den Tools vorhanden sein sollten:<\/p>\n