{"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. Es ist nicht so, dass das alles im aktuellen Prozess erforderlich war, aber wenn man erst einmal angefangen hat, DevSecOps einzuf\u00fchren, muss man bis zum Ende gehen.<\/p>\n

\"Angst
\n
\nQuelle<\/a><\/noindex>. Die Sch\u00f6pfer der Charaktere: Justin Roiland und Dan Harmon.<\/i><\/p>\n

Was ist SecDevOps? Und DevSecOps? Was sind die Unterschiede? Application Security \u2013 worum geht es dabei? Warum funktioniert der klassische Ansatz nicht mehr? Auf all diese Fragen wei\u00df Yuri Shabalin<\/b> aus\u00a0Swordfish Security. <\/b>Yuri wird ausf\u00fchrlich auf alles eingehen und die Herausforderungen des \u00dcbergangs 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\u00e4uft, welche Werkzeuge anwendbar sind, wie sie sich unterscheiden und wie man sie richtig konfiguriert, um Fallstricke zu vermeiden.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\n\u00dcber den Sprecher:<\/b> Yuri Shabalin ist <\/b>Chief Security Architect bei der Swordfish Security<\/b>. Er ist verantwortlich f\u00fcr die Einf\u00fchrung von SSDL und die allgemeine Integration von Analysetools f\u00fcr Anwendungen in ein einheitliches Entwicklungs- und Test\u00f6kosystem. 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.<\/p>\n

Application Security: worum geht es dabei?<\/h2>\n

\nApplication Security<\/b>\u00a0ist ein Bereich der Sicherheit, der f\u00fcr 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 \u2013 es geht um die Schwachstellen und Verwundbarkeiten der Anwendung selbst.<\/p>\n

Richtung SDL oder SDLC<\/a><\/noindex>\u00a0\u2014 Security Development Lifecycle<\/b>\u00a0\u2013 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\u00fccksichtigen, von Anforderungen bis hin zur Ver\u00f6ffentlichung 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.<\/p>\n

\"Angst
\n
\nApplication 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.<\/p>\n

\"Angst
\n
\nDer kanonische SDLC ist in verschiedenen Methodologien stark detailliert \u2013 OpenSAMM, BSIMM, OWASP. Die Methodologien unterscheiden sich, sind jedoch insgesamt \u00e4hnlich.<\/p>\n

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

\nAm meisten liegt es mir am Herzen BSIMM<\/b>\u00a0\u2014 Building Security In Maturity Model<\/a><\/noindex>. 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\u00e4ten dargestellt werden.<\/p>\n

\"Angst
\n
\nJede der 112 Aktivit\u00e4ten hat 3 Reifegrade<\/b>: Einstieg, Mittelstufe und Fortgeschritten. Alle 12 Praktiken k\u00f6nnen nach Kapiteln studiert werden, um wichtige Aspekte f\u00fcr Sie auszuw\u00e4hlen, zu verstehen, wie sie implementiert werden, und schrittweise Elemente hinzuzuf\u00fcgen, wie statische und dynamische Codeanalyse oder Code-Review. Sie erstellen einen Plan und arbeiten ruhig im Rahmen der Implementierung der gew\u00e4hlten Aktivit\u00e4ten.<\/p>\n

Warum DevSecOps<\/h2>\n

<\/p>\n

DevOps ist ein umfassender Prozess, der auch Sicherheitsaspekte ber\u00fccksichtigt.<\/p><\/blockquote>\n

\nUrspr\u00fcnglich DevOps<\/b><\/a><\/noindex> waren Sicherheits\u00fcberpr\u00fcfungen 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\u00f6rde, die Anforderungen stellt und die Produktqualit\u00e4t am Ende des Releases \u00fcberpr\u00fcft. Dies ist ein klassischer Ansatz, bei dem Sicherheitsteams von der Entwicklung abgeschottet waren und nicht am Prozess teilnahmen.<\/p>\n

\"Angst
\n
\nDas Hauptproblem besteht darin, dass die Informationssicherheit separat von der Entwicklung steht. Normalerweise handelt es sich um einen Sicherheitsrahmen mit 2\u20133 gro\u00dfen und teuren Werkzeugen. Alle sechs Monate wird der Quellcode oder die Anwendung zur \u00dcberpr\u00fcfung geliefert, und einmal im Jahr werden Penetrationstests<\/a><\/noindex>. Dies f\u00fchrt dazu, dass sich die Produktionsfristen verl\u00e4ngern, w\u00e4hrend 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.<\/p>\n

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 \u2013 in\u00a0Agile<\/b><\/a><\/noindex>. Das Paradigma DevSecOps passt hervorragend zur Methodologie der agilen Entwicklung, zur Implementierung, Unterst\u00fctzung und Teilnahme an jedem Release und jeder Iteration.<\/p>\n

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

\u00dcbergang zu DevSecOps<\/h2>\n

\nDas wichtigste Wort im Security Development Lifecycle ist \u201eProzess\u201c<\/b>. Sie m\u00fcssen dies verstehen, bevor Sie an den Kauf von Werkzeugen denken.<\/p>\n

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

<\/p>\n

Wichtiger sind die Menschen, nicht die Werkzeuge.<\/h3>\n

\nOft 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\u00fchrt zu traurigen Konsequenzen, da jedes Werkzeug seine eigenen Besonderheiten und Einschr\u00e4nkungen hat.<\/p>\n

Ein h\u00e4ufiger Fall ist, dass die Sicherheitsabteilung ein gutes, teures Werkzeug mit umfassenden Funktionen ausw\u00e4hlt und zu den Entwicklern kommt \u2013 um es in den Prozess einzubinden. Aber das klappt nicht \u2013 der Prozess ist so gestaltet, dass die Einschr\u00e4nkungen des bereits gekauften Werkzeugs nicht in die aktuelle Paradigmen passen.<\/p>\n

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.<\/p><\/blockquote>\n

<\/p>\n

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

\nBevor 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\u00fcfungen, Penetrationstests \u2013 warum nicht all dies in eine verst\u00e4ndliche und f\u00fcr alle n\u00fctzliche Form umwandeln?<\/p>\n

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\u00fcr die Software zu zeigen. Der Spezialist, der sich damit besch\u00e4ftigte, suchte lange:<\/p>\n

\u2013 Moment, irgendwo in meinen Notizen war ein Weg, wo dieses Dokument liegt.<\/i><\/p>\n

Am Ende haben wir das Dokument nach einer Woche erhalten.<\/p>\n

F\u00fcr Anforderungen, Pr\u00fcfungen und anderes erstellen Sie eine Seite, zum Beispiel auf\u00a0Confluence<\/b>\u00a0\u2013 das ist f\u00fcr alle praktisch.<\/p>\n

Es ist einfacher, das, was bereits existiert, umzuformatieren und f\u00fcr den Start zu verwenden.<\/p><\/blockquote>\n

<\/p>\n

Nutzen Sie Security Champions. <\/h3>\n

\nIn einem durchschnittlichen Unternehmen mit 100-200 Entwicklern arbeitet normalerweise ein Sicherheitsexperte, der mehrere Funktionen erf\u00fcllt und physisch nicht alles pr\u00fcfen kann. Selbst wenn er sich gro\u00dfe M\u00fche gibt \u2013 allein wird er nicht allen Code pr\u00fcfen k\u00f6nnen, den die Entwicklung generiert. F\u00fcr solche F\u00e4lle wurde das Konzept \u2013 Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions sind Personen im Entwicklungsteam, die an der Sicherheit Ihres Produkts interessiert sind.<\/p><\/blockquote>\n

\"Angst
\n
\nDer Security Champion ist der Zugangspunkt zum Entwicklungsteam und ein Sicherheitsevangelist in einer Person.<\/p>\n

Normalerweise, wenn ein Sicherheitsbeauftragter ins Entwicklungsteam kommt und auf einen Fehler im Code hinweist, erh\u00e4lt er eine verwunderte Antwort:<\/p>\n

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

Das ist eine typische Situation, da \u00e4ltere oder einfach nur Kollegen des Entwicklers, mit denen er st\u00e4ndig bei der Arbeit und in der Code-\u00dcberpr\u00fcfung interagiert, viel mehr Vertrauen genie\u00dfen. Wenn anstelle des Sicherheitsbeauftragten der Security Champion auf den Fehler und die Folgen hinweist, hat sein Wort mehr Gewicht.<\/p>\n

Auch verstehen die Entwickler ihren Code besser als jeder Sicherheitsbeauftragte. F\u00fcr 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 \u2013 sie sind effizienter.<\/p>\n

\u00dcberlegen Sie also, Security Champions einzuf\u00fchren und den Einfluss des Sicherheitsteams zu erweitern. Das ist auch f\u00fcr den Champion selbst von Nutzen: berufliche Entwicklung in einem neuen Bereich, Erweiterung des technischen Horizonts, St\u00e4rkung technischer, organisatorischer und F\u00fchrungsf\u00e4higkeiten sowie Erh\u00f6hung des Marktwerts. Es ist eine Art soziale Ingenieurkunst, Ihre \"Augen\" im Entwicklungsteam.<\/p>\n

Testphasen<\/h2>\n

\nDas 20-zu-80-Prinzip<\/a><\/noindex>\u00a0besagt, dass 20% der Anstrengungen 80% des Ergebnisses liefern. Diese 20% sind die Praktiken der Anwendung Analyse, die automatisiert werden k\u00f6nnen und sollten. Beispiele f\u00fcr solche Aktivit\u00e4ten sind statische Analyse \u2013 SAST<\/b>, dynamische Analyse \u2013 DAST,<\/b> und\u00a0Open Source Kontrolle<\/b>. Ich werde n\u00e4her auf die Aktivit\u00e4ten 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.<\/p>\n

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

Hauptprobleme der Werkzeuge<\/h3>\n

\nIch werde die aktuellen Probleme aller Werkzeuge hervorheben, die Aufmerksamkeit erfordern. Ich werde diese detaillierter analysieren, um mich nicht weiter zu wiederholen.<\/p>\n

Lange Analysezeit. <\/b>Wenn es 30 Minuten von dem Commit bis zum Produktionsrelease f\u00fcr alle Tests und den Build dauert, werden die \u00dcberpr\u00fcfungen auf Informationssicherheit einen Tag in Anspruch nehmen. Niemand wird den Prozess so aufhalten. Ber\u00fccksichtigen Sie dieses Merkmal und ziehen Sie Ihre Schlussfolgerungen.<\/p>\n

Hohe Rate von False Negatives oder False Positives. <\/b>Alle Produkte sind unterschiedlich, sie verwenden verschiedene Frameworks und ihren eigenen Stil beim Schreiben von Code. Bei unterschiedlichen Codebasen und Technologien k\u00f6nnen die Werkzeuge unterschiedliche Raten von False Negatives und False Positives zeigen. Daher schauen Sie, was genau in\u00a0Ihrem<\/b> Unternehmen und f\u00fcr Ihre<\/b> Anwendungen gute und verl\u00e4ssliche Ergebnisse liefert.<\/p>\n

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

Fehlende oder \u00fcberm\u00e4\u00dfige Komplexit\u00e4t der Anpassung. <\/b>Wenn ein Werkzeug keine API hat, wozu braucht man es dann? Alles, was im Interface m\u00f6glich ist, sollte auch \u00fcber die API zug\u00e4nglich sein. Ideal w\u00e4re es, wenn das Werkzeug die M\u00f6glichkeit zur Anpassung der Pr\u00fcfungen bietet.<\/p>\n

Kein Entwicklungsroadmap des Produkts. <\/b>Die Entwicklung steht niemals still; wir nutzen st\u00e4ndig neue Frameworks und Funktionen, und schreiben alten Code in neuen Sprachen um. Wir m\u00f6chten sicher sein, dass das Werkzeug, das wir kaufen, neue Frameworks und Technologien unterst\u00fctzt. Daher ist es wichtig zu wissen, dass das Produkt eine reale und korrekte Roadmap<\/a><\/noindex> Entwicklung hat.<\/p>\n

Besonderheiten des Prozesses<\/h3>\n

\nNeben den Eigenschaften der Werkzeuge sollten Sie auch die Besonderheiten des Entwicklungsprozesses ber\u00fccksichtigen. Zum Beispiel ist es ein typischer Fehler, die Entwicklung zu st\u00f6ren. Lassen Sie uns sehen, welche weiteren Besonderheiten zu ber\u00fccksichtigen sind und worauf das Sicherheitsteam achten sollte.<\/p>\n

Um die Fristen f\u00fcr die Entwicklung und den Release nicht zu gef\u00e4hrden, erstellen Sie verschiedene Regeln<\/b> und verschiedene Show Stopper\u00a0<\/b>\u2014 Kriterien f\u00fcr den Stop des Build-Prozesses bei Vorhandensein von Schwachstellen \u2014 f\u00fcr verschiedene Umgebungen<\/b>. Zum Beispiel verstehen wir, dass der aktuelle Branch auf einem Entwicklungsstand oder UAT ist, daher halten wir nicht an und sagen nicht:<\/p>\n

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

An diesem Punkt ist es wichtig, den Entwicklern zu sagen, dass es Sicherheitsprobleme gibt, auf die man achten sollte.<\/p>\n

Vorhandensein von Schwachstellen ist kein Hindernis f\u00fcr weitere Tests.<\/b>: manuelles, integratives oder manuelles Testen. Auf der anderen Seite m\u00fcssen wir irgendwie die Sicherheit des Produkts erh\u00f6hen, und die Entwickler sollten nicht ignorieren, was Sicherheit findet. Deshalb handeln wir manchmal so: Wenn wir eine neue Version f\u00fcr die Entwicklungsumgebung bereitstellen, benachrichtigen wir einfach die Entwickler:<\/p>\n

\u2014 Leute, ihr habt Probleme, bitte achtet darauf.<\/i><\/p>\n

In der UAT-Phase zeigen wir erneut Warnungen \u00fcber Schwachstellen, und in der Produktionsphase sagen wir:<\/p>\n

\u2014 Leute, wir haben euch mehrmals gewarnt, ihr habt nichts unternommen \u2013 damit lassen wir euch nicht raus.<\/i><\/p>\n

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 \u00e4ndern muss \u2013 das ist falsch. Schaut nur auf das, was jetzt geschrieben ist, und auf die Ver\u00e4nderung, die in die Anwendung kommt.<\/p>\n

Angenommen, wir haben einen funktionalen Defekt - wie die Anwendung nicht funktionieren sollte: Geld wird nicht \u00fcberwiesen, beim Klicken auf den Button erfolgt kein \u00dcbergang zur n\u00e4chsten Seite oder das Produkt l\u00e4dt nicht. Sicherheitsdefekte<\/b>\u00a0sind solche Defekte, aber nicht im Kontext des Anwendungsbetriebs, sondern der 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 Schwachstellen solche Defekte sind, sollten sie dort sein, wo auch alle Entwicklungsfehler sind. Vergesst also Berichte und erschreckende PDFs, die niemand liest.<\/p>\n

\"Angst
\n
\nAls ich f\u00fcr ein Unternehmen arbeitete, das Software entwickelte, erhielt ich einen Bericht von einem statischen Analysewerkzeug. Ich \u00f6ffnete ihn, erschrak, machte mir einen Kaffee, bl\u00e4tterte durch 350 Seiten, schloss ihn und machte weiter mit der Arbeit. Gro\u00dfe Berichte sind tote Berichte<\/b>. Normalerweise gehen sie nirgendwo hin, E-Mails werden gel\u00f6scht, vergessen, verloren oder das Gesch\u00e4ft sagt, dass es die Risiken akzeptiert.<\/p>\n

Was tun? Die best\u00e4tigten 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.<\/p>\n

Statische Analyse - SAST<\/h2>\n

\nDies ist eine Analyse des Codes auf Schwachstellen.<\/b>, aber das ist nicht dasselbe wie SonarQube. Wir \u00fcberpr\u00fcfen nicht nur nach Mustern oder Stil. Bei der Analyse kommen verschiedene Ans\u00e4tze zur Anwendung: nach dem Schwachstellenschema, nach\u00a0DataFlow<\/a><\/noindex>, nach der Analyse von Konfigurationsdateien. Das betrifft alles, was direkt den Code angeht.<\/p>\n

Vorteile des Ansatzes<\/b>: die Aufdeckung von Schwachstellen im Code in einer fr\u00fchen Phase der Entwicklung<\/b>, wenn es noch keine St\u00e4nde und kein fertiges Werkzeug gibt, und\u00a0die M\u00f6glichkeit einer inkrementellen Analyse<\/b>: die Analyse des Codes, der sich ge\u00e4ndert hat, und nur der Funktion, an der wir gerade arbeiten, was die Analysezeit verk\u00fcrzt.<\/p>\n

Nachteile<\/b>\u00a0\u2013 das Fehlen der Unterst\u00fctzung ben\u00f6tigter Sprachen.<\/p>\n

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