Sichere Softwareentwicklung
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 84 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32418 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computer programmingSoftware developerScrum (software development)XMLUMLLecture/Conference
01:03
Software developerInternetFunction (mathematics)
02:20
Software developerAutomationPenetrationstestComputer programmingCodePlane (geometry)Musical ensemblePDF <Dateiformat>Computer programComputer animation
06:45
Operating systemRoute of administrationLecture/Conference
07:27
SoftwareSoftware developerRoute of administrationSpring (hydrology)InternetLibrary catalogMonster groupWeb applicationInformationProgramming languageSupremumListe <Informatik>CryptanalysisSoftware bugWeb-AnwendungWEBComputer animation
11:21
CryptanalysisLibrary catalogStatische AnalyseMatrix (mathematics)Focus (optics)outputSoftware developerLimit (category theory)Route of administrationProgram flowchartComputer animation
14:32
Computer programmingRoute of administrationOpen sourceWikiPlug-in (computing)Error messageSoftware developerQuery languageField extensionFocus (optics)Stack (abstract data type)DatabaseInformationCarriagewayLibrary catalogWeb pageVersion <Informatik>FRAMEWORK <Programm>RoundingPhysical quantityInternetFrequencySpring (hydrology)Parameter (computer programming)Computer data loggingLagEckeLecture/ConferenceComputer animation
21:37
Achse <Mathematik>DatabaseCodeBewertung <Mathematik>Dynamic rangeVersion <Informatik>Parameter (computer programming)PriorityWeb-AnwendungJavaScriptGirderLibrary catalogRoute of administrationSoftware developerPort scannerGraph (mathematics)Software bugPlug-in (computing)Jenkins CIWeb applicationError messageForceOpen sourceComputer animation
28:29
Statische AnalyseRoute of administrationConcurrency (computer science)Web pagePort scannerCodeLoginUniform resource locatorProxy serverHTMLLaufzeitWeb browserExplosionGraphical user interfaceDatabaseStatisticsSound <Multimedia>Query languageParameter (computer programming)Computer animation
35:22
Open sourceControl flowUnit testingFlagMischung <Mathematik>Software developerComputer data loggingUniform resource locatorDevice driverPhysical quantityFRAMEWORK <Programm>Version <Informatik>Sign (mathematics)Apache <Programm>Run-time systemRoundingSelenium <Software>Route of administrationPlug-in (computing)Parameter (computer programming)Table (information)Lecture/ConferenceComputer animation
42:08
Web serviceClefRoute of administrationSoftware bugWeb applicationWeb portalFacebookCross-site scriptingOpen sourceEncryptionRun-time systemALT <Programm>Software developerFRAMEWORK <Programm>CodeApache <Programm>Graphical user interfaceSupremumWeb-AnwendungDirection (geometry)JBossLink (knot theory)Single sign-onDynamischer TestComputer animation
48:44
Software developerWeb browserUniformer RaumLibrary catalogPasswordPenetrationstestNumberIterationComputer animationLecture/Conference
54:09
Computer animation
Transcript: German(auto-generated)
00:08
So, 10.01 Uhr, denke wir fangen an. Einen wunderschönen guten Morgen. Schön, dass so viele erschienen sind zum Thema sichere Softwareentwicklung. Klingt ein bisschen global, ist aber jetzt heute von mir erstmal nur ein praktischer Einstieg.
00:26
Das heißt, ich will euch ein bisschen was erzählen, wie wir das gemacht haben, uns dem Thema gewidmet haben und quasi zum ersten Mal überhaupt uns Gedanken gemacht darüber, wie machen wir das eigentlich, was wollen wir da tun und womit und wie und wie oft und warum überhaupt.
00:42
Davon will ich euch heute erzählen. Mein Name ist Stefan Kapps. Ich leite die Softwareentwicklung im Bundesversicherungsamt in Bonn in einer Behörde. Ja, aber wir arbeiten sehr agil, machen das komplette Scrum Paket, machen Continuous Delivery und wollten uns deshalb auch um Sicherheit mal kümmern.
01:10
Morgen. Das Bild kennt vielleicht schon der ein oder andere, das kursiert im Internet zu vielen verschiedenen Themen rum,
01:21
kann man viel hinein interpretieren, vor allem denke ich auch IT Security, denn egal was für Regeln wir uns irgendwie aufstellen, wenn wir die nicht prüfen und kontinuierlich überprüfen, ob sie dann auch eingehalten werden, dann können wir es auch gleich sein lassen, dann ergibt das wenig Sinn, dann sind es irgendwie ARRIBY Funktionen.
01:45
Eins der größten Probleme bei dem ganzen Thema ist natürlich irgendwie das Verhältnis. Wir haben ziemlich viele Entwickler meistens, dann einen größeren Teil noch von Operations, aber bei Security ist es dann ganz dünn besetzt. Und die, die da sitzen, sind auch meistens, kommen nicht aus der Entwicklung
02:01
und wissen also erstmal nicht, was man denn eigentlich auch in der Entwicklung machen müsste und könnte, um sich um Sicherheit deutlich mehr zu kümmern. Die Flughöhe ist also ein bisschen zu hoch für Entwickler meistens. Und wenn dann noch das Thema Agile und Continuous Delivery dazukommt, wir also irgendwie häufig, nicht unbedingt mehrmals täglich,
02:22
aber zumindest nicht nur einmal im Jahr ausliefern wollen, dann ist sowas wie PEN-Tests wird dann echt schwierig, weil wann wollen wir die machen? Dann halten wir dann die Pipeline an oder was passiert dann?
02:41
Ein möglicher Schritt dahin, da eine Verbesserung zu erreichen, ist Continuous Security Testing. Also alles, was wir bisher schon kontinuierlich machen, machen wir eben auch mit Testing, mit Security Testing. Was heißt das? Wir wollen also statische und dynamische Analysen, das ist die Aufteilung bei den Security Tests,
03:01
so in ganz groben, irgendwie während der Entwicklung schon durchführen. Das am besten frühzeitig, regelmäßig, um dann das, was bei dem Penetrationstest passiert, nämlich die manuellen Dinge, wo man sich irgendwelche Dinge genauer angucken muss, was man da für mehr Zeit hat, weil man die einfachen Sachen eben schon rausgefiltert hat. Das heißt automatisiert hier irgendwelche Programmierschwachstellen rausgefiltert hat.
03:26
Ansonsten ist das, was man, weiß nicht, vielleicht schon mal so ein Ergebnis von so einem Penetrationstest gesehen hat, das können 3, 5, 600 Seiten PDFs sein, die erstmal auch meistens, kommt auch an wen ihr gestellt habt, aber nicht so gut sortiert und auch viele false positives drin sind,
03:42
also Dinge, die eigentlich keine Probleme sind. Und bis man da durch ist, dauert ewig und bis man das überhaupt verstanden hat, was da drin erklärt wird, ist nicht handhabbar, also versuchen, so viel wie möglich vorher rauszufiltern. Aber um dazu in der Lage zu sein, brauchen wir ein paar Voraussetzungen.
04:02
Das ist dann der zweite große Bereich, um den es dann eigentlich heute geht. Wir brauchen so einen Secure Coding Guide. Wir brauchen Programmierrichtlinien, die wir uns selber auferlegen, um Schwachstellen im Code zu vermeiden. Das Ganze müssen wir auch irgendwie in den Bildprozess integrieren, damit wir den Punkt Automatisierung auch durchführen können.
04:21
Das ist regelmäßig bei jedem Bildprozess, bei jedem Deployment vorher passiert. Und dann kommt das Entscheidende vielleicht noch dazu. Das, was man jetzt in der DevOps ja alles schon kennt, müssten wir eigentlich noch ein bisschen erweitern, nämlich um Security, also sowas wie SecDevOps. Und das haben wir auch getan.
04:41
Ich habe mich mit der IT-Sicherheitsbeauftragten dann zusammengetan, die jetzt von Softwareentwicklung keine Ahnung hat, aber mir dafür viele andere Dinge erklären konnte, womit ich mich als ursprünglicher Entwickler noch nie so wirklich beschäftigt habe. Und das, was dabei rausgekommen ist, will ich euch heute zeigen.
05:02
Zuerst mal noch die Frage, warum sollen wir uns eigentlich darum kümmern? Das ist eigentlich ganz klar. Ich komme jetzt hier aus einer Behörde. Das heißt, wir müssen es tun. Wir haben sowas wie BSI-Grundschutz, an dem wir uns halten müssen. Da geht es einzuhalten, die Grundschutzmaßnahmen. Da gehört sowas wie sichere Softwareentwicklung dazu, was auch immer das dann im Konkreten bedeutet.
05:24
Aber viel wichtiger ist vielleicht noch, dass wir das auch proaktiv machen wollen. Wir wollen dieses Mysterium enträtseln, was versteckt sich eigentlich hinter diesen ganzen Dingen wie SQL-Injection und die ganzen anderen tollen Begriffe. Und im Ergebnis wollen wir die Security-Tests dann eben nach vorne verschieben, also to the left.
05:43
Das heißt, im Entwicklungsprozess deutlich nach vorne nehmen und nicht wie bisher erst kurz vor Produktionsaufnahme. Das ist so das klassische Bild, was man eben kennt aus der Entwicklung, nur wenn man agil arbeiten möchte und vielleicht sogar Continuous Delivery bis hin zur Produktion macht,
06:05
muss man sich über Security-Tests auf den verschiedenen Ebenen eben Gedanken machen. Wenn man denn schon mal so weit ist und hat sich diese Stages schon mal so weit vorbereitet von der Infrastruktur und von dem, was darauf passieren soll, und Gedanken gemacht, welche Tests da stattfinden,
06:21
dann können wir uns jetzt noch darüber Gedanken machen, welche Tests lassen wir denn da auf diesen Stages laufen. Security-Tests. Häufig kommt dann aber erst mal so der Einwand Continuous Delivery auch von Sicherheitsexperten. Ja, das ist ja gefährlich, wenn jetzt jeder Entwickler einfach eincheckt und danach geht das Ding in Produktion.
06:44
Das ist uns ja viel zu gefährlich. Auf der anderen Seite sage ich dann immer dazu, eigentlich ist das ein Vorteil, Continuous Delivery zu machen. Denn wenn uns eine Schwachstelle auffällt, auch von diesen ganzen Meldungen, die vom BSI rumgehen, die CVE-Nummern, falls sich schon mal jemand gesehen hat, welche Schwachstellen in welcher konkreten Anwendung vorkommen
07:01
oder in Betriebssystemen oder so, können wir das ja hier auch schneller wieder beheben. Also wenn wir einfach diese Schwachstelle, die aufgetreten ist, uns bekannt wird, wir den Fehler beheben, können wir ihn halt eben auch viel schneller wieder ausrollen, weil wir nicht auf das nächste Release in einem Jahr warten müssen, sondern es morgen machen können.
07:20
Aber wie fängt man denn eigentlich an? Was haben wir denn hier eigentlich? Wer ist denn hier Entwickler? Super. Operations? Okay. Security?
07:43
Okay, also hier muss ich vorsichtig sein, ansonsten machen. Es gibt viele Quellen im Internet. Und die bekannteste ist vielleicht so etwas wie OWASP, was einem schon mal begegnet ist. Aber wenn man da mal tiefer in die Kataloge und Listen rein guckt, die da so kursieren,
08:05
dann tauchen viele Begriffe auf, die man erst mal verstehen und zueinander in Beziehung setzen muss. Sowas wie Angriffe, Attacken, Schwachstellen und Verwundbarkeiten und eben dann Fehler. Es ist eben die Frage, was sind denn mögliche Angriffe und aufgrund welcher Schwachstellen sind diese möglich?
08:24
Welche Softwarefehler sind dafür verantwortlich und wie kann man diese vermeiden? Das ist so das Grundgerüst, an dem wir uns dann orientieren. Ich sage immer vorsichtig, es kommen ja noch nach und nach welche, es dürfen auch gerne welche gehen,
08:41
weil ich möchte nicht, dass jemand danach sagt, Stunde verschwendet. Es geht gleich um Java-Web-Anwendungen. Wer den abstract nicht vorher gelesen hat und jetzt überrascht ist, weil Java ja jetzt nicht so positioniert ist, kann sich noch überlegen zu gehen. Ansonsten seid ihr gerne willkommen euch das anzuhören. Das meiste ist ja allgemeingültig, aber wenn es nachher auf ein bisschen konkrete Sachen der Entwicklung geht,
09:06
geht es auf Java und Web-Anwendungen. So, wie fängt man an? Ovas Top Ten hat vielleicht der eine oder andere schon mal was von gehört. Die werden glaube ich alle drei oder vier Jahre aufgestellt. So eine Liste der von Ihnen eingestuften Top Risiken sind das in dem Fall.
09:26
Da taucht dann sowas an Stelle eins meistens auf wie Injection und darunter ist dann eben so Unterbereich wie SQL Injection, OS Injection und sowas. Also die haben wir uns auf jeden Fall rangezogen, weil die sind weit verbreitet. Dazu aber noch diese Mitre Top 25, sind jetzt schon ein bisschen älter,
09:43
aber das, was da hinten am Katalog steht, sind aktuell. Das sind nämlich diese CWEs, einen Schwachstellen-Katalog, der in anderen Bereichen auch wieder verwendet wird. Da werden die einzelnen Schwachstellen eben allgemein beschrieben,
10:01
was ist eine Injection und wie häufig kommt das vielleicht vor, wie oft benutzen das die Angreifer, was für Auswirkungen hat das, was für finanzielle und Business Auswirkungen hat das und durch welche Attacken werden diese Schwachstellen eben versucht auszunutzen.
10:22
Und dann gibt es das Ganze auch nochmal weiter mit so einem Web Application Security Konsortium. Die haben auch einen Katalog aufgestellt. Das Ganze ist meistens relativ einfach aufgebaut, sowas wie hier. Einfach nur eine Liste von Attacken und eine Liste von Schwachstellen. Dahinter verbirgt sich dann immer eine konkrete Seite mit mehr oder weniger vielen Informationen,
10:44
was das jetzt genau ist, wie man das beheben kann in der einen oder anderen Programmiersprache sogar, teilweise mit Beispielen erklärt. Aber alles relativ lose gesammelt und dann untereinander wild verlinkt. Um sich erstmal einen Überblick zu verschaffen, ist sowas vielleicht hilfreich.
11:05
Wie baut sich das Ganze eigentlich auf? Oder zusammen hier ist das Risiko, was bei OWAS das Hauptkriterium ist. Wenn man hier sagt, das ist eigentlich das Produkt aus einem Schaden, multipliziert mit der Eintrittswahrscheinlichkeit.
11:22
Und dieser Schaden kann sich zusammensetzen aus einer Schwachstelle. Diese Schwachstelle kann eine Verwundbarkeit beinhalten, also es kann ein Teil davon sein, mit der Attacke. Ja, so weit, so gut. Dazu vielleicht noch als Ergänzung diese Kataloge, wie hier, ist ja eine Rangliste.
11:44
Auch das ist eine Rangliste. Die haben natürlich irgendwelche Bewertungskriterien, um zu dieser Rangliste zu kommen. Das ist sehr unterschiedlich, kann man manchmal schwer miteinander vergleichen. Hat auch einen komplett anderen Ansatzpunkt, hier bei den Risiken und hier bei der Liste der Schwachstellen.
12:01
Wenn man sich aber hier mal die Matrix anguckt, wie die das bewerten, das ist schon sehr, sehr umfangreich, was da alles mit reinspielt. Aber wenn man sich das jetzt dann eben im Konkreten anguckt, landet man eigentlich bei erstmal so einem Bildchen. Wir haben irgendwie diese ganzen einzelnen Risiken, Attacken, Schwachstellen,
12:26
Verbundbarkeiten und die sind eigentlich alle mit allen mehrfach verlinkt. Das heißt, ein Risiko kann also entstehen aus einer oder mehreren Schwachstellen oder Verbundbarkeiten. Eine Verbundbarkeit wiederum kann Ursache einer oder mehrer Risiken sein.
12:42
Verbundbarkeiten repräsentieren Schwachstellen, die über mehrere bekannte Attacken ausgenutzt werden usw. Kurz ein kleines Beispiel aus diesen Katalogen. Wenn man jetzt hier das A1 nimmt, das ist die Injection bei OWASP, dann kann das eben verknüpft sein hier mit diversen Verbundbarkeiten aus anderen Katalogen,
13:05
was das jetzt genau bedeutet, das gar nicht so wichtig ist, nämlich auch gar nicht vollständig. Das sind noch deutlich mehr. Aber sowas wie dieses WASC 20 ist Improper Input Handling und Validation ist die CWE 20. Das Blaue ist dann ein zweites Beispiel, aber so könnte man das Ganze dann aufbauen,
13:25
macht es aber im Endeffekt nicht einfacher, das Ganze zu verstehen und irgendwie eindeutig zuzuordnen, womit kann ich mich dann jetzt beschäftigen und was macht Sinn, was ist das Wichtigste. Deswegen ist irgendwie den Fokus irgendwo drauf zu legen.
13:41
Das haben wir dann eben getan und sagen, okay, wir nehmen jetzt erstmal als Basis die Top Ten. Wir nehmen die anderen Sachen dazu, wo es passt, aber das ist erstmal die Ausgangsbasis. Wir kümmern uns um Java-Web-Anwendungen und wir suchen uns jetzt da die erstmal raus, weil wir wollen ja einen praktischen Einstieg haben, für die wir auch eindeutige Vorgaben formulieren können in der Entwicklung
14:02
und die wir auch durch statische Analysen testbar machen können, weil statische Analysen sind erstmal extrem einfach umzusetzen, sind schnell in der Ausführung und haben einen riesen Mehrwert. Und sie lassen sich dann eben auch, und das ist dann auch ein Fokus, in den Bildprozess integrieren.
14:24
Daraus geworden ist dann erstmal ein Projekt. Sinn des Ganzen ist, es war kein riesen Projekt, das Fokus war jetzt gelegt auf erstmal drei Monate, auch da nicht Vollzeit dran arbeiten wäre gut, aber erstmal die Sichtbarkeit davon natürlich auch erhöhen.
14:41
Wir wollen nämlich auch Ziele damit verfolgen, wollen dann sagen, wir haben da jetzt was getan und damit haben wir auch wirklich was erreicht. Wir wollen Programmierrichtlinien aufstellen. Die sollen der sicheren Softwareentwicklung helfen und wir wollen das mit QuickWinds ganz schnell erstmal an den Start kommen.
15:01
Das ist natürlich immer ein Ziel von einem Projekt, erstmal schnell was zu erreichen und das Ganze am besten auch mit wenig Aufwand, aber das ist halt wirklich der Fokus hier mit einfachen Tools nachher irgendwas auch zu machen, denn diese Richtlinien sollen leicht und schnell testbar sein. Das Ganze jetzt noch gepackt in ein ordentliches Vorgehen.
15:23
Das heißt, wir müssen uns ja erstmal darum kümmern, die ganzen Dinge da zu verstehen, die in diesen Katalogen auftauchen. Dann müssen wir uns ja was raussuchen. Also wir wählen uns ein paar aus und definieren so ein paar Richtlinien, stellen einen Katalog auf, schulen und sensibilisieren die Entwickler. Was ist denn zu tun, wenn wir das hier nicht mehr machen wollen, diesen Fehler?
15:46
Kümmern uns dann um die Integration in den Bildprozess und machen danach, wenn das Ganze steht, noch ein paar Wochen lang eine Evaluation, ob das denn jetzt auch das Richtige ist, was wir da tun. Das Ganze eben für den Fokus Secure Coding und Security Testing
16:02
und erstmal Schritt 1. Das heißt, das soll iterativ sein, danach soll Schritt 2 kommen. Wenn wir jetzt 10 Regeln aufstellen, damit haben wir noch keinen großen Secure Coding Guide. Das Ganze müssen wir mehrmals machen und uns ein paar Runden da durchquellen und am Ende vielleicht 40, 50 Regeln haben.
16:22
Aber das ist ja schon mal der Anfang. Und das ist das Ergebnis. Eine ganz primitive Liste. Die Regeln sind einfach auch in Aufforderungen formuliert, also verhindere das Injizieren von Shard Code in SQL-Befehl. Wenn man das da hinten nicht so gut lesen kann, ist eigentlich gar nicht so wichtig, was da drin steht.
16:42
Ich habe es auch nochmal auf Papier, wer es dann wirklich inhaltlich haben will. Es geht eher so um das Vorgehen dabei. Darunter haben wir dann die Risiken, Verwundbarkeiten und Attacken verlinkt, also wirklich mit den Einträgen aus den Katalogen, dass man sehen kann, um welche dieser Dinge, eben auch nicht um alle Auswirkungen dieses Risikos,
17:03
um welche konkret kümmern wir uns jetzt in diesem Fall und hier ist schon was vorweggenommen, was wir gleich noch deutlicher sehen, womit testen wir das, mit welchem Tool. Wir können trotzdem mal eine von da oben, die bekannteste auch, direkt mal ein bisschen genauer betrachten.
17:21
Das, was sich dann dahinter verbirgt, hinter dieser Liste, dann noch quasi eine Seite im Wiki oder so, was auch immer, ganz simpel, noch erklärt, was ist denn dann zu tun für die Entwickler. Erstmal die Erklärung, was ist denn die Ursache von solchen Dingen wie SQL-Injection, also ungeprüfte Übernahme von User-Eingaben oder Input-Parametern, den SQL-Abfragen.
17:42
Und was ist die Auswirkung? Das ist eben so der Bereich Sensibilisierung, damit jeder weiß, was bewirkt das denn eigentlich, wenn ich diesen Fehler in meiner Anwendung habe, was kann der Schaden sein? Manipulation von Daten, unberechtigte Abfragen. Und jetzt das Entscheidende, wie kann ich es verhindern? Hier muss natürlich ein bisschen Überlegung
18:01
reingesteckt werden, was passt zur Architektur, was passt zu meinem Software-Design. Es gibt halt auch diverse verschiedene Möglichkeiten, vielleicht, das zu lösen. Und in dem Fall wäre es so was Einfaches wie Prepared-Seal-Statements oder eine Hibernate-Criteria. Und man ist aus der Geschichte heraus erstmal.
18:20
Ein zweites Beispiel, vielleicht ein bisschen schwammigeres. Anzeige von technischen Fehlermeldungen vermeiden. Warum eigentlich? Ursache? Ja, technische Fehlermeldungen werden bis zum Anwender durchgereicht, aber nicht ordentlich abgefangen. Ergebnis ist, dass sensible Informationen bekannt werden. Über die Infrastruktur, über konkrete Daten.
18:42
Unberechtigte können diese plötzlich einsehen. Das wollen wir eigentlich verhindern. Und das können wir zum Beispiel verhindern durch schonmal Standard-Error-Pages in WebXML. Dass da nicht irgendein Stack Trace plötzlich auf der Webseite steht oder eben vor allem auch die Stack Traces in separate Log-Dateien auslagern.
19:09
Das war es eigentlich schon in dem ersten Schritt für Regeln aufstellen und die Entwickler dafür sensibilisieren. Dann wären wir schon bei dem Schritt,
19:20
wie integrieren wir das in den Bildprozess, um das auch kontinuierlich machen zu können. Der Herr da oben ist wahrscheinlich jedem bekannt. Und für Jenkins gibt es viele Plugins. Und wir wollen uns aber jetzt ja nur fokussieren auf einen kleinen Bereich. Und somit haben wir hier eine Erweiterung
19:41
von FindBugs gefunden. FindSecBugs ist quasi ein Plugin für FindBugs, der sich konkret um Security-Regeln kümmert. Läuft dann eben genauso mit in FindBugs wie alle anderen Regeln.
20:00
Nur was man dann jetzt eben auch machen sollte, weil das kann ständig mehr, inzwischen über 80 verschiedene Security-Prüfungen eben darauf beschränken, was man jetzt in seinem Katalog auch aufgestellt hat. Also wir haben glaube ich sieben der zehn Regeln lassen sich mit FindBugs prüfen. Und genau die sind auch hier nur aufgeführt und eingeschaltet, quasi aktiviert.
20:23
Es gilt halt eben den Fokus immer nur genau auf das zu legen, was ich gerade aufprüfen kann und was ich beheben kann. Also es nützt mir nichts, wenn ich jetzt noch 200 andere Meldungen bekomme, die aber sowieso jedes Mal ignoriere, weil ich erstmal noch nicht weiß, um was es da geht und ich weiß, wie ich es beheben kann.
20:42
Der zweite Kandidat ist eins, was ich absolut jedem ans Herz legen will, ist der OWASP Dependency Check. Also es ist natürlich alles Open Source und wird hergestellt von der OWASP und ist ein Tool, das eine Datenbank im Internet anzapft.
21:01
Und zwar die National Vulnerability Database. Dort wird von der US-Regierung die über 80.000 konkrete Verwundbarkeiten in Anwendungen, Frameworks und Tools gesammelt. Da kommen die konkreten CVE-Nummern her, die dann umgeschickt werden
21:21
als BSI-Warnung und sonst irgendwas, wenn plötzlich im Cisco-Router was aufgefallen ist, wenn plötzlich bei, und das war mein Beispiel, in ActiveMQ in der Version 5.7 sind bekannte Verwundbarkeiten, und zwar sogar 14 Stück.
21:40
Und dieser Dependency Check als Plugin im Jenkins zieht sich dann einmal, das kann man dann eben auch zentral für alle Projekte machen und zentral ablegen lassen, diese komplette Datenbank runter, das dauert ein bisschen, es sind 300 MB oder so, und checkt gegen diese Datenbank dann die abhängigen Jars, die ich in meiner Anwendung habe. Und das ist viel wert.
22:03
Wir sehen hier, dass diese Version zum Beispiel schon vier hoch eingestufte Verwundbarkeiten hatte. Der rote Balken hier zum Beispiel, Improper Input Validation, hier werden auch schön genau die Dinge aus den Katalogen wieder aufgezählt, was da genau gefunden wurde. Und Ergebnis ist eben ganz einfach,
22:22
dass man dann sagen kann, okay, wir haben jetzt hier Version 5.7 eingesetzt, mal gucken, ob denn nicht eine Neue draußen ist, mal gucken, ob die nicht die Verwundbarkeiten beruhen hat. Und es ist in dem Beispiel dann eben auch so, Version 5.8 hat genau diese 14 Dinge behoben und hat dann gar keine mehr. Wenn man das dann eben so einstellt,
22:40
dass es zentral verfügbar ist, dann aktualisiert sich das eben quasi bei jedem Bildlauf einmalig, ob denn was Neues drin ist, das dauert dann eben nicht mehr lang, das sind dann nur noch Kilobytes. Und jedes Tool, jede Anwendung kann diese Datenbank benutzen und diese Auswertungen bekommen. Im Jenkins ist es ja auch immer schön, dass diese Auswertungen immer gleich aussehen,
23:00
man kann sich immer direkt orientieren, wie viele Warnungen hat man und kann hier die ganzen Kategorisierungen durchgehen, in den Code reinspringen und so weiter. Das Schöne bei den Jenkins-Plugins ist ja auch noch, dass ich hier Quality-Gates setzen kann. Ich kann mir also sagen,
23:20
oder auferlegen, wenn ich entdecke, dass in meinem, in dem Fall, eben abhängigen Jazz Verwundbarkeiten mit hoher Priorität drin sind und nur eine einzige, lasse ich eben den Bildprozess abbrechen und muss das erstmal beheben. Dann liefer ich diese Anwendung mit dieser Schwachstelle eben nicht aus. Würde ich am Anfang jetzt nicht machen, wenn man startet,
23:41
weil das könnte dann schwierig werden, überhaupt noch irgendwas zu deployen. Aber wenn man irgendwann mal eine schöne Baseline gezogen hat und das meiste rausgefiltert hat, zumindest irgendwie so alle hohen oder so, dann kann man sich so ein Quality-Gate setzen und damit kontinuierlich sagen, wir sind sauber und sobald was drin ist, beheben wir es auch so schon. Weil der Bildprozess eben abbrechen, wir gar nicht weiter kommen.
24:02
Das dritte Tool auf der Liste soll eine Eigenentwicklung werden. Leider stockt die Entwicklung ein wenig, da ich nicht dazu komme. Also einen ganz simplen WebXML-Checker, der dann das fehlende Element in der Richtlinienliste noch vervollständigt. Indem ich einfach sage, ich will hier checken, ob in der WebXML
24:21
die ganz simplen Parameter eigentlich alle gesetzt sind, die ich brauche, um irgendwie zumindest das Kröpste und einfachste an Security schon mal einzubauen. Kann man jetzt sagen, okay, wenn man nur ein Produkt herstellt, dann kann man das einmalig händisch machen. Klar, keine Frage. Wir machen glaube ich 60, 70 Web-Anwendungen. Da will ich nicht ständig irgendwie nachgucken
24:40
und merken, wo ich das schon geguckt habe. Dann würde ich gerne hier so einen Jenkins-Plugin haben, in dem ich sage, das muss drin sein und mir dann ausgeben lasse, ob das oder der Bildprozess abbrechen, wenn es dann nicht so ist. Also wer noch sich beteiligen will, gerne danach Bescheid sagen. Man könnte noch Unterstützung brauchen.
25:02
Für die einzelnen kleinen Fehlermeldungen, die wir dann haben wollten, gibt es dann so ein ganz Mini-Code-Beispiel in Java. Das steht dann da auch, um genau diese zu produzieren, die in dem Katalog drinstehen. Es gibt noch ein bisschen mehr so in der weiten Welt.
25:22
Ich war mal auf der Konferenz, habe den Vortrag gehalten. Dann kam einer zu mir und meinte, ja, das mit dem WebXML, das ist ja cool. Aber das haben wir schon. Wir haben nämlich da so ein Tool-Sanitizer, heißt das Ding. Ist kostenlos. Es ist nicht open source. Es ist sehr umfangreich.
25:40
Deswegen bezweifle ich, dass es kostenlos bleiben wird. Aber aktuell ist es noch so. Könnt ihr euch mal anschauen. Da ist nämlich genau das drin, was wir alles einzeln gemacht haben. Also hier ist Find Zag Bugs drin. Hier ist der Oberst Dependency-Check drin. Und diverse andere Sachen noch. Hier ist auch so ein Call Graph drin, wer was wo aufruft.
26:00
Und es ist nicht ganz selbsterklärend. Da muss man sich schon ein bisschen durcharbeiten. Aber es ist noch kostenlos. Das haben wir auch erreicht und wollten das auch so. Wir wollten nicht, dass jeder Entwickler sich lokal um alles Mögliche kümmert. Wie stelle ich meine Find Bugs-Regeln ein?
26:21
Wie komme ich an die Plugins? Wann lasse ich die laufen? Muss ich die ständig laufen lassen? Wir haben das erstmal alles zentral gemacht, wir haben das alles zentral im Jenkins abgelegt. Und sobald der Entwickler einfach seinen Code eincheckt, wird in seinem Bildjob das alles durchgeführt über die Standard-Konfiguration, die dann auf allen Projekten liegt.
26:40
Und der Entwickler selbst muss sich erst mal um nichts kümmern. Das Argument, ich habe keine Zeit, mich jetzt um Security-Sachen zu kümmern, ich muss entwickeln, war erst mal damit eliminiert.
27:01
Jetzt kommt ein kleiner ein bisschen ein Ausschweif. Das Ganze, was wir jetzt da schon mal gemacht haben, kann man auch ein bisschen bewerten. Dann hat ein Kollege, Christian Schneider, der ist auch viel als White-Hacker unterwegs und so, hat da mal aus Spaß so ein Maturity-Model aufgestellt. Das würde ich euch gerne mal
27:21
auch zeigen. Das ist nämlich ziemlich cool, er hat das so verglichen mit den Gürteln. Wir kümmern uns also irgendwie um die vier inneren Gürtel. Wir sind nicht Totalanfänger und nicht Master-Guru. Aber wir kümmern uns um vier Stufen. Und das auf vier Achsen. Auf der Achse Konsolidierung,
27:41
dynamische Tiefe, statische Tiefe und Intensität. In den Bereichen kann man das irgendwie bewerten, was wir da tun und was noch zu tun wäre, um die nächste Stufe zu erreichen. Und wenn wir uns das bei der statischen Tiefe mal anschauen, taucht da schon genau das auf, was wir getan haben. Stufe eins.
28:01
Wir wollen die Third-Party-Libraries überprüfen. Haben wir gemacht. Toolvorschlag ist hier auch dieser Dependency-Check. Es gibt auch was Äquivalentes für JavaScript. Und können jetzt Stufe zwei erreichen, indem wir unseren wichtigen Code scannen. Sowas wie FindSackBugs. Hier das ScanJS
28:21
für JavaScript. Haben wir auch getan. Jetzt können wir Stufe drei eigentlich auch erreichen, indem wir einfach alles scannen. Dauert vielleicht zwei Minuten länger, aber können wir machen. Genau mit dem gleichen Tool. Und wenn wir jetzt noch eine Schippe drauflegen wollen, dann können wir eigentlich auch das machen, was wir da geliefert bekommen, können wir auch selber machen.
28:40
Wenn wir dem nicht vertrauen, weil wir sagen, wir wollen alles, was wir an Libraries haben, externe, wollen wir einfach selber den Code checken. Dann lassen wir eben FindSackBugs über den Source-Code dieser Third-Party-Libraries laufen. Und wir denken, in diesem Katalog sind noch nicht alle Verwundbarkeiten drin. Wir checken das lieber mal selber. Können wir auch tun. Jetzt wird es leider ein bisschen
29:02
trauriger. Bei der dynamischen Tiefe haben wir nämlich noch nicht viel gemacht. Eher gesagt gar nicht. Denn hier kommt sowas ins Spiel, wie wir testen eine laufende Anwendung. Und da gibt es auch schöne Open-Source-Tools. Sepp ist so mein Favorit. Video-Dee-Security ist immer gleich noch. Das ist eigentlich nur ein Aufsatz noch quasi
29:22
für Sepp. Arachni ist so die Konkurrenz dazu. Und hier gibt es jetzt auch verschiedene Möglichkeiten. Das ganze Ding hat einen Spider. Das heißt, ich lasse das Ding einfach auf meine Anwendung los. Im einfachsten Fall, bei Sepp gibt es auch da eine Gui-Führer, sehen wir nachher noch, gebe ich eine URL ein und dann beschießt er diese Webseite. Bitte
29:41
nicht mit öffentlichen Webseiten tun. Das gibt es in der ersten Stufe erstmal gegen den nicht-autentifizierten Bereich. Das heißt also ohne Login. Einfach alles, was so erreichbar ist, wird irgendwie beschossen. Dafür hat es eben Standard-Attacken schon vorgesehen, die es dann darauf ablässt.
30:00
In Stufe 2 das Ganze eben gegen den authentifizierten Bereich. Ich muss also irgendwelche Session-Parameter mitnehmen. Womit logge ich mich ein? Mit welchen Usern? Um dann bestimmte Bereiche auf der Anwendung erst zu erreichen. Und die mache ich dann mit diesem Spider. In Stufe 3 kann ich das Ganze ausweiten. Das Ganze hier geht ja über eine Gui. Über die
30:21
URL der Hauptanwendung quasi. Und alles, was dahinter passiert, kann ich ja auch checken. Also alles, was mit Web-Service-Aufrufen zum Beispiel auf dem Layer passiert, kann ich auch beschießen und da alles zerstören. Also er zerstört wirklich alles. Also wenn irgendwo Formulare sind, die dann irgendwas in der Datenbank speichern, einfach so, die werden auch wirklich vollgemüllt.
30:41
Also da echt aufpassen. Da kann man sich auch im Testumgebung komplett zerschießen. Und Stufe 4 wäre dann noch das gezielte Scannen. Das hier ist ja alles quasi so vorgefertigt. Und wenn ich dann noch irgendwas Spezielles brauche, weil ich ja auch zum Beispiel ein Formular erst mit richtigen Daten füllen muss,
31:01
um auf irgendwie weiterzukommen in der Anwendung, auf die nächste Seite zu kommen, muss ich das natürlich selber machen. Und das Ganze dann vielleicht zum Beispiel über Silendium-Tests oder ähnliches mit ZAP über Silendium-Tests laufen lassen. Also Funktionsweise von ZAP ist einfach, dass es ein Interzapting Proxy ist. Also ich klemme ihn zwischen den Browser und er fängt
31:21
alle abfragen, fängt er ab und manipuliert sie. Das ist das einfache Prinzip dabei. Und das kann ich auch Headless über den Rest API auch steuern. Alles ziemlich cool aus Skript bar.
31:41
Dann kann ich mich darum kümmern, wie intensiv mache ich meine Tests. Bei den statischen Tests wäre es relativ einfach zu beschreiben, wenn ich eben sowas einsetze wie CheckStyle, FindBugs usw. Nehme ich eben das Standardregelwerk, kümmer mich nicht darum, welche Auswirkungen die einzelnen Fehler haben oder
32:01
wann sie genau greifen sollen. Das wäre Stufe 1. Stufe 2 passe ich es eben an und individualisiere mit das. Bei den dynamischen ist es das passive Scannen. Das heißt, ich starte den Scanner eben einfach so, wie er vorkonfiguriert mitgeliefert wird.
32:21
Bei den dynamischen mache ich dann eben hier ein bisschen genauer, also wo genau soll was getestet werden. Leichtgewichtig, schwergewichtig bedeutet dabei das gleiche wie das, was man vielleicht aus anderen Tools hier eben kennt, wie bei FindSectBugs. Ich kann eben einstellen, wie
32:41
intensiv nachgeschaut werden muss. Das kann die Laufzeit deutlich erhöhen, auch selbst bei statischen Analysen. Aber es ist eben möglich. Es gibt auch noch den Modus insane. Das ist dann mit allem drum dran.
33:00
Und dann haben wir noch die letzte Stufe. Bei statisch kann man sich natürlich auch irgendwann Gedanken machen. Vielleicht wird es auch irgendwann wichtig, eigene Regeln zu programmieren. Die kann ich ja auch dann einfach in CheckStyle oder FindBugs einbauen. Und bei dynamischen teste ich eben nachher alles. Das kann so viel schon mal vorweg bei
33:21
sowas wie SEP und dynamischen Analysen auf einer komplexeren Anwendung kann das mehrere Stunden dauern. Das kann ein Problem werden. Und dann haben wir noch den Bereich Konsolidierung. Das heißt einfach, wie gehe ich mit den Ergebnissen um? Bei Stufe 1 kann ich mir einfach HTML
33:41
Reports zum Beispiel erzeugen oder in Jenkins so eine Statistik anzeigen lassen. Erstmal ganz nett. Stufe 2 haben wir auch schon gesehen. Ich kann hoffentlich Quality Gates setzen. Was akzeptiere ich noch an Fehlern? Und bei Stufe 3 wird es dann schon spannend, wenn ich natürlich jetzt mehrere solcher Tools einsetze, dann können die sich irgendwie überschneiden.
34:01
Die können identische Meldungen bringen, die ich irgendwie zusammenführen muss. Ich muss die Duplikate konsolidieren. Und dann sollte ich mich natürlich irgendwann, wenn ich weiß, dass was da rauskommt, ist auch wirklich sinnvoll und das will ich und muss ich beheben, dann sollte ich das auch nachverfolgen, dann mache ich daraus Tickets. Vielleicht nicht ganz am Anfang, wenn da 2000
34:21
Sachen rauskommen, das macht keinen Sinn. Das guckt sich kein Mensch mehr an. Aber irgendwann, wenn es einen guten Stand erreicht hat. Und jetzt kommt noch was Abgefahrenes. Ich kann das ganze, was ich da tue, die Security Tests auf meinem Code, kann ich auch eine Code Coverage drauf machen. Da gibt es ein großes Tool von Oberspür,
34:40
Code Pulse, ob ich denn all meinen Code auch wirklich mit Security Tests versehen habe. So, kann man machen. Aber das Positive an dem ganzen ist, wir haben jetzt mit dem Miniprojekt, was wir jetzt hier quasi gemacht haben, schon relativ viel erreicht in kürzester Zeit. Wir können bei der statischen Tiefe
35:01
Level 3 bis 4 erreichen. Bei der dynamischen Tiefe leider gar nichts. Schade eigentlich. Intensität können wir aber auch Level 4 noch erreichen und Konsolidierung zumindest mit den Quality Gates bis zur Stufe 2 kommen. Ja, so viel dazu. Das ist erstmal das
35:21
der praktische Einstieg, das Mindeste, was man schon mal irgendwie mit wenig Aufwand machen kann. Das war leider noch lange nicht alles. Denn wie gesagt, das war ja am Anfang schon klar, das sind jetzt erstmal 10 Regeln, da brauchen wir noch deutlich mehr. Wir müssen die Runde ein paar mal drehen und wir müssen Tests entwickeln.
35:41
Wir können nachher wahrscheinlich nicht mehr alles mit irgendwelchen kleinen Tools machen, sondern müssen dann halt über Unit-Tests oder sonstiges die einzelnen Security-Dinger prüfen. Und wir müssen das Ganze auch kontinuierlich irgendwie verbessern. Kommt was Neues dazu, kommt Java 8 dazu, brauchen wir vielleicht andere Sachen und so weiter.
36:01
Aber, um wieder was Positives zu sagen, was ich dann kurz danach irgendwann gefunden habe, ist, was noch nicht so lange her als das rauskam hier, ist noch von 2016, irgendwann März oder so, kam von OWASP diese Proactive Controls raus. Und die wollen damit so eine Top 10 aufstellen,
36:22
die 10 wichtigsten Dinge, die jeder Entwickler kennen und umsetzen sollte. Und das kam nach unserem Projekt raus und dann habe ich die Liste gesehen, habe ich gedacht, ja, yes. Wir haben Punkt 1, Security-Tests früh und häufig machen. Ja, genau, das war nämlich unser Ziel. Das steht da ganz oben drin.
36:41
Das ist jetzt eine bunte Mischung irgendwie aus Methoden und aus konkreten Dingen. Dann sowas wie parametrisierte Abfragen, ja, haben wir, wollten wir uns auch ganz oben drum kümmern, SQL, Injection. Dann kommen noch ein paar andere konkrete Prüfungen, um die wir uns kümmern wollten. Auch sowas wie Identity und Authentification Controls, sehen wir gleich auch noch was.
37:03
Logging haben wir uns auch drum gekümmert, genau, wir haben das Logging standardisiert mit einem Framework, mit einem Pattern, wie es aussehen soll, wie, welche Log-Dateien erstellt werden, welche Log-Dateien separiert werden voneinander und so weiter. Wir können dann noch ein Logs-Dash-Kibana draufsetzen, um das Ganze noch zentral auszuwerten
37:22
und Security- Frameworks und Libraries prüfen und Error- und Exception-Handling einsetzen. Wunderbar, genau das wollten wir tun. Aber dann nochmal in das schwierige Kapitel und das große Kapitel Dynamische Analysen.
37:40
Den Zap haben wir vorhin schon mal kurz angesprochen. So sieht das Ding aus, es gibt es als Desktop-Anwendung tatsächlich. Und hier ist das, was man tun kann, einfach eine URL eingeben und beschießen. Dann baut sich hier so ein Seitenbaum auf, ich kann da reinschauen, was der da gemacht hat. Es taucht auf, welche
38:01
Warnungen, welche Risiken und Schwachstellen er gefunden hat. Und die kann ich mir auch anschauen und das ist eben dann verknüpft mit so einem Katalog, sodass dann hier auch irgendwo drin steht, womit man diese Schwachstelle auch beheben könnte. Das ist tatsächlich ein Tool, was so Penetration-Tester benutzen.
38:22
Und das lässt sich dann eben auch jetzt in eine Continuous Integration, Continuous Delivery Pipeline einbauen, weil es eben Headless läuft, über Rest API ansprechbar ist und über Phantom JS oder irgendwas steuerbarer wäre. Ja, nochmal Achtung, Post wird
38:41
attackiert, also Formulareingaben werden losgeballert. Auch hier gibt es Jenkins-Plugins, wo ich wieder in der Lage bin, Quality Gates zu setzen und das Ding auch automatisch zu starten, sogar
39:01
automatisch zu runterzuladen, installieren, glaube ich sogar. Und das Problem ist nur, dass wird nicht wirklich gut gepflegt, das Plugin, das seit der neuesten Version von SEP funktioniert das nicht mehr, müsste man eine ältere Version noch nehmen, aber das wird aber bald repariert. Dann hatten wir auf der Liste
39:20
noch BDD Security. Und das ist auch Open Source natürlich. Baut ein bisschen auf SEP auf, es benutzt es nämlich im Hintergrund und erstellt über Cucumber, weiß nicht, wer Cucumber kennt, als Behavior Driven und Development Methode.
39:41
Es werden Stories formuliert im given-when-then Schema. Das Ganze dann eben BDD Security liefert solche Stories für Security Tests aus. Die kann ich einfach benutzen, die sind schon vorformuliert mit ganz vielen Szenarien. Also hier sieht man, es sind 49 Szenarien
40:00
schon vorformuliert für diese Bereiche. Alles, was so wichtig ist. Und testet dann eben die Anwendung, auch die Umgebung der Anwendung, also welche Ports sind offen, welche dürfen nur offen sein und sowas mit Hilfe von Cucumber, SEP und gegebenenfalls Selenium. Kann man sich mal anschauen.
40:22
Das Ganze sieht dann zum Beispiel so aus, so ist eine Story formuliert, given-when-then, muss nicht alles immer vorkommen, aber hier ist eben die Frage, es wird überprüft, ob nach der Anmeldung eines Users das SecureFlag gesetzt ist. Hier werden halt über Parameter, über so eine Usertabelle
40:41
die Credentials mitgegeben, dann meldet er sich an und als Ergebnis sieht man dann eben, weil es läuft dann wie ein Unit-Test, dass das Ding hier fehlgeschlagen ist, weil das Flag eben nicht true gesetzt ist, sondern auf false. Und so kann ich ganz einfache Unit-Tests quasi auf Security-Themen
41:01
erstellen. Ein zweites Beispiel, ein bisschen umfangreicher. Ich will prüfen, wenn zwei Login-Vorgänge hintereinander stattfinden, dass eine neue, unterschiedliche Session-ID erzeugt wurde. Und so passiert eben das gleiche wieder, Login-Page, Session-ID wird gemerkt, dann anmelden, User ist eingeloggt und was hier
41:22
passiert, weil es rot ist, natürlich wieder als Beispiel ist fehlgeschlagen, denn die Session-ID, wie man hier sieht, war exakt die gleiche. Dann haben wir den Bereich Security-Frameworks. Jetzt geht es dann wirklich in die Entwicklung. Apache Shiro ist da relativ
41:42
bekannt und wird auch, glaube ich, von Spring Security benutzt und diversen anderen Tools. Hier kann ich das eben ein bisschen unterstützt alles machen. Muss man natürlich immer noch um vieles selber kümmern, aber kriegt das schon eine gewisse Unterstützung bei. Ovas Bezapi ist hier kursiv geschrieben, weil es eigentlich nicht
42:01
mehr weiterentwickelt wird. Es gibt jetzt eine Ablösung dafür. Deswegen brauchen wir das hier eigentlich gar nicht mehr erwähnen. Was aber super spannend ist und was wir jetzt auch intensiv eingesetzt haben, produktiv und in allen Umgebungen ist JBoss Key Cloak. Kennt das schon jemand? Das ist zufrieden?
42:21
Okay. Das ist, vielleicht kennt ihr mal Picket Link. Das war dann auch ein Framework ähnlich wie Apache Shiro. Das ist quasi die Ablösung. Es wurde gemerged. Alles, was da aus den zwei Projekten war, ist jetzt zusammengekommen und entstanden ist, was ziemlich cool ist, nämlich quasi Apache Shiro mit einer GUI. Und das heißt, ich kann
42:41
hier über eine GUI kann ich LDAP-Dienste anzapfen, kann mir meine User und Gruppen einfach rausziehen, kann dann meine Anwendungen hier verwalten über auch URL-Patternen. Also es geht also nur um Web-Anwendungen und Web-Services. Aber eben auch um Web-Services. Das heißt, ich kann meine Rechte, die ich eine Anwendung
43:01
gebe und den dazugehörigen Web-Service dann eben weitergeben. Das Ganze passiert über Token, über Barrettoken. Und es werden halt keine User-Credentials von Anwendung zu Anwendung geschoben. Ich kann hier Single Sign-On eben für alle meine Web-Anwendungen machen. Das heißt, wir haben jetzt auch ein Portal entwickelt, die User kommt rein und die Rechte werden hier rausgezogen und man meldet sich
43:21
einmal an und ist in allen seinen Anwendungen authentifiziert. Dann kommen noch ein paar Spielereien mit. Ich kann mich auch mit Google-Konto anmelden und Facebook und ta-da-la. Ist jetzt für interne Hausanwendungen vielleicht nicht so spannend. Aber ziemlich cool. Und superschnell in Betrieb genommen.
43:43
Dann noch ein paar andere kleine Tools. OWASP Java-Encoder ist die Ablösung für das vorherige Gesehene, ESAPI. Es verhindert Cross-Site Scripting. Muss man eben gucken, ob man es braucht, wenn man nicht eh schon irgendein GUI-Framework benutzt, was das automatisch schon irgendwie alles macht.
44:00
Google-Kisa für Verschlüsselung, symmetrische, asymmetrische Schlüssel. Und hier nochmal das Tool für die Code-Coverage von Security-Tests, der OWAS CodePulse. Das war auch auf einer Konferenz, habe ich auch jemanden getroffen von eTerraTech und
44:21
der hatte dann was Tolles vorgestellt. Die sind dabei. Aktuell auch noch Open Source. Bin mal gespannt, ob das dabei bleibt. Was zu bauen, nämlich so eine komplette Umgebung, Security-Test-Farm mit Docker-Containern. Das Bild sieht dann so aus. Ziemlich abgefahren, aber wenn es klappt, wird es cool, weil hier haben wir dann so Dinge wie
44:41
eine Camunda-BPM zum Beispiel drin. Also hier wird gesteuert, was passiert, wenn ich jetzt irgendwo was finde. Wen muss ich ansteuern? Hier unten tauchen dann die Tools zum Beispiel auf. Hier ist der Z-Proxy von vorhin. Hier sind noch ein paar andere Tools für Security-Tests, für konkrete, speziellere Dinge. Dann haben wir hier eine Anwendung, die
45:01
eben getestet wird. Das Ganze wird dann wieder zusammengeführt in so einem Elasticsearch-Logstash-Kibana-Dashboard, um alles sich anzeigen zu lassen. Sieht vielversprechender aus. Ich werde es auf jeden Fall ausprobieren.
45:21
Was haben wir jetzt getan? Wir haben Richtlinien aufgestellt. Das ist schon mal gut. Und wir haben kurze, präzise Erläuterungen formuliert. Und durch kleine Tools in den Build-Prozess eingeführt. Und damit kontinuierlich einen automatisierten Sicherheitstest durchgeführt. Das ist schon mal gut.
45:41
Jetzt könnte man sich denken, es gibt doch fertige Secure Coding Guides. Ja, gibt es. Sowas wie von OVAS gibt es auch einen. Und von der Carnegie University. Die sind aber auch sehr umfangreich. Also wenn man sich damit einsteigen will, dann wird man ziemlich schnell frustriert, weil man erstmal irgendwie auch da 200 Seiten durchackern muss mit auch schon ganz konkreten
46:02
technischen Details. Ich finde es einfacher, aus der anderen Richtung zu kommen. Erstmal zu sagen, um was will ich mich eigentlich erstmal nur kümmern und das baue ich ein und das erweitere ich nach und nach. Ja, stratische Analysen sind wie gesagt ziemlich schnell. Auch in der Ausführung, was entscheidend ist, wenn man häufig
46:21
baut und ausliefert. Das ist bei dynamischen Tests kann das viel länger dauern. Wird es auch. Und das kann die Delivery Pipeline natürlich vor Schwierigkeiten stellen. Entweder liefe ich seltener aus oder ich mache diese Security-Tests dann aber auch nicht immer. Da muss man sich
46:41
fragen, was man da eingeht. Welchen Kompromiss. Und im Endeffekt geht es dann darum, dass sich das Ganze in den Entwicklungs-Workflow einklidern muss. Denn nur wenn diese Security-Bugs dann auch genauso aufgespürt und verbaltert und behoben werden wie normale Bugs, dann
47:01
wird sich das etablieren und einfach Standard werden. Und wenn man jetzt am Anfang eben mehrere Hundert gefunden hat und dann mal eine Baseline gezogen hat, dann ist man aber auch so in dem Thema drin, dass man diese, weil es sind halt im Endeffekt kleine Programmierfehler oder irgendwas, was man ein bisschen anders machen müsste, um diese Verbundbarkeit gar nicht erst zu erzeugen,
47:21
die wird man ja nachher nicht mehr machen. Wenn man das zehnmal in seinem Code behoben hat, das elfte Mal, wird man es nicht mehr programmieren. Geh ich von aus. Und zu dem ganzen Vortrag ist da ein Artikel erschienen. Ist jetzt schon ein Jahr her in der Objektspektrum.
47:43
Das war es eigentlich von mir. Hätten Zeit für Fragen. Ich fand den Vortrag echt gut. Vielen Dank. Ich hab am Anfang ein bisschen Angst gehabt bei Einführungen in Security
48:02
Software Development, dass der nächste Cross-Site-Scripting so nicht kommt. Ich fand es echt super, dass du den Rahmen geschlagen hast. Security ist mehr als nur Technik. Super Vortrag. Security ist mehr als nur Technik fand ich extrem wichtig.
48:21
Meiner Erfahrung nach ist es hilfreich manchmal noch einen Schritt weiter nach links zu gehen. Also auch die Produktdefinierende Seite, wie auch immer die jetzt aussieht, mit einzubeziehen. Denn ganz viele der Fehler, die man macht, sind ja halt nicht Technikfehler. Also auch das, aber Technikfehler kann man einfach fixen. Was man ganz schlecht fixen kann,
48:41
sind Produktkonzeptionsfehler im Produkt. Also sei es in irgendwelchen technischen Flows im Sinne von Passwort vergessen und man vergisst, dass vielleicht auch irgendwo noch ein Kundencenter ist, wo man das Passwort auch ändern kann. Und betrachtet das einfach nicht in diesem Fachprozess. Oder
49:00
was auch immer. Genau. Ja, genau. Also ein Teil ist natürlich auch, wenn man agil entwickelt, dann auch in den Stories schon irgendwie Security zu berücksichtigen. In große Hilfe kann BDD Security werden, weil da
49:21
sind vorgefertigte Stories. Er hat mal relativ allgemein, aber dann auch konkreter. 49 Szenarien sind da schon drin. Kann man sich mal angucken. Sind auch inzwischen gut strukturiert. Die haben quasi als Überschrift, wir können das mal, ich habe das extra aufgemacht. Mal gucken. So sieht das zum Beispiel aus, wie dann so ein
49:41
Szenario formuliert ist. Da ist auch eine C... Oh, sieht man nicht. Sind auch brav mit CWE-Nummern überschrieben. Das heißt, man findet es auch in den Katalogen sofort
50:00
wieder. Was soll da eigentlich gerade getestet werden? Das sind manchmal dann ganz grobe Dinge, wie wenn ich jetzt den Browser starte und mein Intercepting-Proxy ist richtig konfiguriert und ich kann jetzt nicht mehr in den Browser laufen, dann will ich bitte nichts finden. Das ist so die Hammer-Methode. Aber dann gibt es halt irgendwo auch ganz
50:21
konkrete Sachen in den einzelnen Stories, die man sich hier auch anschauen kann. Zum Beispiel, was haben wir hier? Authentification.
50:43
Ja, so ganz konkrete Sachen. Ein User ist angemeldet, meldet sich ab. Sein Token soll gelöscht werden. Wenn er sich dann wieder anmeldet, soll das funktionieren. So was in der Art. Und wenn das dann nicht klappt, dann
51:02
schlägt der U-Date-Test fehlen. Ja, so sieht das ungefähr aus.
51:20
Wie lange dauern die On-Commit-Checks ungefähr bei euch? Die erste Stage, die Commit-Stage, also die Tests hier, die wir jetzt da gemacht haben, mit Fein-Security-Bugs, die brauchen nicht lange. Also das sind ja auch nur ein paar am Anfang gewesen. Aber die Commit-Stage braucht zwei, drei Minuten.
51:56
Du hast eben angesprochen, dass wenn man zum Beispiel die Literatur
52:00
oder die Empfehlungen von welcher Universität war es? Carnegie Mellon? Ja, genau. Die fallen ja relativ umfangreich aus. Und du sagtest, die möchte man sich nicht unbedingt antun. Und dann fängt man quasi erstmal auf einem kleineren, bescheideneren Level an. Wie ist denn deine Meinung
52:21
zur Weiterentwicklung? Also sollte man nicht irgendwann quasi da ankommen? Weil wenn man den ganzen Aufwand fährt, diese ganzen Bildtests und so weiter automatisiert da mitmacht, dann kann das Management sagen, Security ist bei uns ein Thema, das wird gemacht. Da gibt es ganz viele bunte Bilder, alles ein Häckchen dran und
52:40
der Kunde ist zufrieden, weil der sieht, viele bunte Bilder werden produziert, also super. Aber wir machen das auf unserem Rahmen, so was wir gerade machen können, hast du ja erzählt. Und wenn da quasi gar kein Bestreben ist, das quasi auszuweiten, mindestens auf das Level von so einer Uni oder vielleicht darüber hinaus,
53:00
dann bringt das ja nichts. Dann ist das ja mehr Show, als quasi ich nachher wirklich da Nutzen von habe. Ja, ich muss halt gucken, was ich investieren kann. Klar, wenn ich viel investieren kann, da komme ich schneller voran. Grundsätzlich machen wir natürlich weitere Iterationen, stellen weitere Regeln auf. Ob das jemals abgeschlossen ist oder so einen
53:20
Stand erreicht, weiß ich nicht. Weiß ich aber auch nicht, ob es dann halt notwendig ist. Wir machen so viel wir machen können. Penetrationstests finden dann ja trotzdem noch irgendwann statt, zwischendurch, wo dann auch mal ein Externer das richtig checkt. Aber die Ergebnisse davon fallen halt viel kleiner aus. Also das, was da rauskommt, ist viel verständlicher,
53:40
weil den ganzen einfachen Kram, die false positives und so, die habe ich hoffentlich dann alle schon abgefangen. Und das ist das, was ich erstmal tun kann, aus Sicht der Entwicklung so viel wie mir möglich ist. Wenn keine Fragen mehr sind,
54:01
dann viel Spaß heute noch und Dankeschön.