 Ich freue mich euch zwei vorzustellen der automatisierte Sicherheitsverprüfung von Software vorstellt für Leute, die überhaupt nichts von Sicherheit verstehen. Hattet ihr die letzten Monate daran gearbeitet und ich freue mich auch über dieses Thema und ich freue mich schon darauf, was er uns über dieses Projekt erzählt und darüber, was wir in unseren Projekten, wie wir unsere Projekte sicher machen können, willkommen fürs Psy. Ich kann euch nicht wirklich sehen, aber es sieht so aus, als würde es relativ voll geworden sein für einen zwei Uhr Nachmittagstalk mit ein bisschen Java. Ein kurz bisschen darüber, wer ich bin, ich werde euch erklären, wieso und was und wie ihr diese ganze automatisierte Sicherheitstesten durchführen könnt. Es ist nicht unbedingt notwendigerweise in dieser Reihenfolge. Wenn ihr irgendwelche Fragen habt, könnt ihr eure Hand hochhalten und vielleicht sehe ich euch, aber wahrscheinlich nicht, also schreit sehr einfach. Ja, ich bin Chris. Ich bin ein Systementwickler mit Java hinter Backend-Sachen und Cloud und ich möchte so ein bisschen in Richtung Sicherheit mich weiterentwickeln und ich bin eine Organizatorin der Karlsruhe DevOps. Ich arbeite für Cynics. Wir machen meistens Java-Entwicklungen für unsere Kunden mit deren speziellen Anforderungen. Unser Name ist Code Mit Attitude. Wir arbeiten nicht mit Nuklear-Energie-Leuten zusammen, wir arbeiten nicht mit Waffenhändlern zusammen und wir machen auch Konsalteen. Und wenn ihr euch hiermals in Süddeutschland seid und nach dem Job sucht, dann ja. Ich habe Fragen. Habt ihr irgendwelche Fragen? Ich habe einfach Fragen. Hat irgendjemand von euch arbeitet an einem Softwareprodukt? Irgendwie involviert. Oh, Überraschung, das waren ziemlich viele. Wer von euch benutzt Java? Okay, der erste Teil des Vortrags wird hauptsächlich über Maven sein. Ich hoffe, dass es nicht komplett aussehen wollten, gegriffen ist für Leute, die das noch nicht gearbeitet haben, aber das sollte relativ gut erklärbar sein. Wer benutzt Docker oder Kubernetes oder irgendetwas andere Container in Produktion? Okay, wer scanns eure Software regelmäßig vor Sicherheitsproblemen? Wer benutzt Software in Produktionssystemen, wo er wisst, dass es Sicherheitsprobleme gibt? Okay, vielleicht können wir da später wieder drauf ein. Also, was ist das Problem mit Software-Sicherheitsproblemen? Was ist das Problem mit Software, die nicht nur technisch ist, sondern auch Sicherheitsprobleme haben, wo Menschen eingebrechen könnten und schlechte Sachen machen können? Also, zu meinen könnte man die Daten verlieren. Die Konsumardaten oder die Endkonsumenten können auch veröffentlicht werden. In 2018 gibt es in Deutschland strengere Richtlinien und viele Firmen haben bisher noch nie darüber nachgedacht, wie man die persönlichen Daten der Konsumardaten schützen kann. Und Sicherheitsprobleme könnten auch Service unterbrechen. Wenn der Webserver aus ist, dann kann es immer auch ein Problem werden. Ihr könnt nicht mit euren Kunden interagieren, ihr kriegt kein Geld. Ihr könnt halt Industriefunktionen haben, die schief laufen. Wir haben diese kritische Infrastruktur in Deutschland, Kritis. Das ist Infrastruktur, die dafür für tägliche Leben benutzt wird, die absolut notwendig ist. Zum Beispiel Abwassersäuberung, Stromherstellung und Bereitstellung. Vielleicht habt ihr von Todesfällen gehört, die wirklich passiert sind, weil automatisierte Autos über irgendjemanden gefahren sind, weil sie dachten, vielleicht ist das eher ein Papiertüter, die über die Tasche fliegt. Das ist ein technischer Fehler, aber das könnte auch von einem Hacker benutzt werden, wenn ein automatisiertes Auto ein Sicherheitsproblem hat. Menschen haben schon gezeigt, dass man schon über ein Netzwerk Autos anhalten und neu starten kann. Hat irgendjemand von euch was von Equifax gehört? Das ist in Deutschland wäre, dass sie Schufa, sie machen Monitoring für die Leute. Wenn man irgendwie einen Kredit beantragt oder wenn man Schwierigkeiten hat, Rechnungen zu bezahlen, das könnte passieren, wenn du in den USA lebst, dann tauchst du in deren Datenbanken auf. 2017 wurden sie angegriffen von Hackern, die ihren Webserver übernommen haben. Es stellt sich raus, dass die Servers zwar gepatched wurden. Es gab einen offiziellen Patch for Stretch für vier Wochen, aber die Firma Equifax hat das nicht gewusst oder es hat einfach keinen interessiert. Und Leute konnten die Server eintringen und persönliche Daten abschaufeln. Ich glaube, 143 Millionen Sozialversicherungsnummern. Wenn man das amerikanische Sozialversicherungssystem kennt, dann weiß man, das ist eine Nummer, die kriegt man bei Geburt und die kann man niemals wieder ändern. Und wenn du irgendwo anrufst bei ganz vielen verschiedenen Services und du möchtest deinen Passwort benutzen, dann fragen sie nach den letzten vier Stellen deiner SSN und dann kannst du deinen Passwort ändern. Das ist also ziemlich schlimm. Außerdem sind ziemlich viele Kreditkarten-Nummern involviert gewesen und ein Haufen anderer Sachen. Verwundbarkeiten können natürlich auch in anderen Plattformen passieren, die man zum Beispiel benutzt, um seinen Server laufen zu lassen. Die Deutschen kennen das vielleicht unter dem Namen Panama Paper oder vielleicht auch jeder. Ich glaube, wir haben dafür keine Zeit, aber die hatten eine schlechte TruePull-Version auf dem Web-Server, den sie nicht aktualisiert haben und naja, das war wohl nicht so gut für sie. Okay, warum würde man die Software nicht aktualisieren? Man kann einfach leugnen und das interessiert mich nicht. Ich habe nicht die Zeit, das ist nicht die Priorität jetzt gerade. Dein Produktmanager sagt, hey, wir brauchen das Feature. Vielleicht hast du ja Vorurteile, vielleicht musst du ja irgendwie Performance-Tests machen und sagen, ich habe andere Sachen, die sind wichtiger. Vielleicht bist du gar nicht trainiert. Als ich angefangen habe, mich dafür zu interessieren für Sicherheit, da hatte ich eigentlich überhaupt keine Ahnung, was ich machen soll. Ich meine, ich habe das jetzt schon zwei Jahre gemacht und ich habe nicht das Gefühl, ein Experte zu sein in Software Security. Ich bin eher so der durchschnittliche Mittelwissen-Mensch. Vielleicht fehlt einem Information oder man kann einfach sagen, Security ist nicht meine Angelegenheit, Sicherheit ist nicht das, was ich mache. Ich bin Software-Entwickler und die Firma hat einen Security-Team und einen Test-Team für Ingenieurs-Tests und auch für Security-Tests-Sicherheit-Tests und das sind dann vielleicht die Leute und ich weiß auch nicht. Okay, um all diese Probleme anzugehen, da gibt es diese Open-Web-Applikation Security Project. Das ist, glaube ich, eine Non-Profit-Organisation. Sie sagen, die eine Liste mit den Top-10-Sicherheitslücken. Ich glaube, das letzte Mal 2017 und was wir versuchen, heute zu machen, ist die ersten 9. Es geht darum, Komponenten zu benutzen, bei denen man von Schwachstellen schon weiß, dass es irgendwie jemand hat eine Verbunderung gefunden, zum Beispiel Struts und dann wird es berichtet an zum Beispiel Apache oder das Stretch Project. Der Report ist öffentlich einsehbar, so jeder kann es sehen, jeder kann einen Scanner dafür schreiben. Du kommst vielleicht auf die Idee zu fragen, warum sollten wir mit der neuen Anfang und nicht mit den Top-1-Problemen, du kannst alle Top-8-Probleme haben und viele mehr innerhalb von Drittpartei Bibliotheken, die du einfach benutzt. Wir suchen uns jetzt einfach den leichtesten Weg aus, dieses Problem anzugehen und außerdem können wir davon eine ganze Menge lernen. Okay, was können wir tun, um Sicherheitsproblematiken anzugehen? Wir können natürlich bekannte Schwachstellen suchen. Es gibt öffentliche Datenbanken, wo jeder, also auch die Bösen, aber auch die Guten nachschauen können, welche Verwundbarkeiten existieren, ob man die ausbessern kann, was man tun muss, damit man zu welcher Mission man patchen soll. Das ist technischerweise ziemlich einfach, weil es dafür Werkzeuge gibt. Wir müssen nur ein Prozess implementieren, der das irgendwie wirklich hinkriegt. Also du hast eine Schwachstelle gefunden, aber jetzt brauchst du die Zeit, um dich zu fixen. Du hast deine Prioritäten, du hast Feature, hoffen andere Sachen, die du adressieren musst und du brauchst einen Weg, wer wann, wo wie die verwundbarer Software aktualisiert. Und ich glaube, das ist für Firmen das schwierigste, der schwierigste Teil. Persönlich würde ich Sicherheitsfeature betrachten als technische Sachen. Wenn du Sicherheitsblicken hast, dann wird jeder Patch und jeder Erweiterung sehr viel schwerer sein. Es wird ein neues Sicherheitsproblem gehabt. Jeder, das schon mal ausprobiert hat, der weiß es. Wenn man wochenlang wartet für Patches wegen Technik oder auch Softwareverwundbarkeit, das wird unfassbar viel schwerer, die Software zu aktualisieren und nachher die Probleme zu lösen. Ich glaube, das Beste ist alles immer automatisieren. Es ist Montagmorgen, 10 Uhr morgen und ich möchte nicht ein Verwundbarkeitstest laufen lassen. Nein, der sollte automatisch laufen. Es ist genau das Gleiche wie mit Unitests und Integration-Tests und Performance-Tests. Es gibt Software, die verändert sich. Es sollte automatisch gebaut werden, automatisch getestet werden und automatisch nach Sicherheitsproblemen durchsucht werden. Lass uns mal anschauen, wie wir Sicherheitsblicken in den von anderen bereitgestellten Bibliotheken uns anschauen können. Ich hoffe, wenn ihr auch für den Java und Schmaven noch nicht benutzt habt, dann versteht ihr das trotzdem. Wir werden nach Docker-Image-Komponenten anschauen. Z.B. Docker-Drupal könnte ein Element von einem Docker sein, wo man seine eigene Webseite hinzufügt. Wenn wir Zeit haben, können wir auch eine Web-Anwendung, die API, hinterher noch mal anschauen. Zuerst wollen wir automatisieren. Das heißt, ich zeige euch jetzt etwas, wie z.B. in einer Continuous Integrations-Werkzeug sein kann. Jeder Java-Entwickler sollte das ja schon mal benutzt haben. Das sind die unterschiedlichen Komponenten, die notwendig sind für moderne Software-Entwicklungen. Wir wollen Unitests machen, wir wollen neue Software-Pakete erstellen, wir wollen das Ergebnis hochladen, wir wollen ein Docker-Bild bauen, wenn wir Docker benutzen und dann das Docker-Bild hochschieben oder buschen, damit es automatisiert installiert werden kann. Das ist ein Demoprojekt. Normalerweise würde man mehr Tests hinzufügen und vielleicht starten wir das Automatisch-of-Tests-System in diesem automatisierten Werkzeug. Also wir könnten zusätzliche Schritte hinzufügen, um die um die Sicherheitsscan zu erhöhen. Ich habe hier drei zusätzliche Demo-Schritte hinzugefügt. Das eine ist ein Dependency-Check, also ein Abhängigkeits-Check. Ein Containersicherheits-Check und dann zuletzt ein API, also Programmier-Interface-Sicherheits-Check. Es könnte aber auch so aussehen. Gelb bedeutet in der Regel in Jenkins, dass der Bauvorgang unstabil ist. Das heißt, es baut, es gibt nichts Großes, was kaputt ist, aber es ist irgendwas nicht ganz in Ordnung, dann soll sich das Ganze nochmal anschauen. Wir schauen uns das besser genauer an. Die Software sollte immer durchlaufen und immer bauen. Wenn Menschen sagen, wenn man schlechte Tests hat oder Sicherheitslücken, dann ist es auch so ein bisschen problematisch. Vielleicht muss man zwei Sicherheitslücken auf einmal fixen und man kann nicht beide gleichzeitig machen. Manchmal eine davon hat ein Patch, aber man möchte trotzdem die andere Sicherheitslücke fixen. In meiner Meinung sollte es eine Warnung geben, dass die Pipeline nicht vollständig durchgelaufen ist, z.B. durch das man es anstabil deklariert. Die Teams, mit denen ich normalerweise zusammenarbeit, haben wir große Dashboards und Anzeigen für unsere Prozesse, für unsere Fitnessprozesse und wir haben quasi eine Ampel, was darauf angezeigt wird. Man sieht anhand der Farbe, ob der aktuellste Software-Version ordentlich gebaut wurde und ordentlich kompelliert wurde und wir sehen visuell, ob da irgendwas schief gelaufen ist. Das heißt, man muss nicht manuell hingehen und jeden Kompelliervorgang anschauen, aber man kriegt ein visuelles Zeichen, was schief gelaufen ist. Und dann muss man diesen Prozess implementieren, wie man dann das Problem wirklich fixt. So, was ist eine Sicherheitslücke? Es gibt eine Wikipedia-Definition, die jetzt auf Englisch vorgelesen wurde. Aber so im Endeffekt ist es kann sein, dass etwas passiert ist, dass vielleicht sogar öffentlich bekannt ist, weil von einer anderen Quelle kommt. Jetzt die Frage, woher könnten wir das wissen? Es gibt eine öffentliche oder mehrere Referenz-Datenbanken, die bekannte Sicherheitslücken auflösten. Oder eine CVE, eine Common Vulnerability und Veröffentlichung ist eine Erklärung für eine Sicherheitslücke. Also jetzt schauen wir uns mal das Equifax Beispiel an mit Struts. Hier sehen wir, dass es die Sicherheitserklärung von der Sicherheitslücke für Apache Struts links und links ist. Hier sehen wir eine Basis-Score. Es muss kein Sicherheits-Experte sein, dass wenn da jetzt Critical steht, dass man das vielleicht sich anschauen soll. Oder was man was machen muss. Man sieht ein paar zusätzliche Informationen. Was jetzt das wirkliche Problem in dieser Struts-Version ist da ein spezielles Paket, was man hinsenden kann auf der Web-Server eines anderen Personen ausführen kann. Es gibt noch ein paar Zusatzwerte und komische, viele Informationen, die man eigentlich so in der allerersten Stelle nicht dringend braucht. Es ist mehr so tiefere Informationen, die später benötigt werden. Okay. Okay. Ich werde jetzt mal schnell zu Maven und den Abhängigkeiten springen. Hier können wir sehen, wie Maven-Abhängigkeiten in einer modernen Java-Anwendung funktionieren oder wie die aussehen. Ich habe hier ein automatisch generierten Test-Maven-Projekt und ich habe ein paar Abhängigkeiten und dritte Parteien, also öffentliche Bibliotheken hinzugefügt. Und das sind so die minimalen Anforderungen an eine Java Spring Boot-Applikation, die ein Webservice anbietet. Also wir haben hier diesen Spring Boot-Start Software, das ist eine Umgebung, die auf Java läuft und die viele Sachen für einen erledigt. Das heißt, man muss viele Sachen nicht selber programmieren, sondern man muss sich darüber nachdenken, was es wirklich tun soll. Das ist das am häufigsten benutztes Java-Frame-Work aktuell. Und kann dieses Starter-Software hinzufügen, die gewisse Funktionalität mit hinzufügen. Zum Beispiel, wir machen eine API, das heißt, wir müssen sie absichern. Das heißt, wir brauchen ein Starter für Sicherheit, die Authentifikation und Macht, dass wir einfach kleine Bestandteile hinzufügen müssen und der ganze Rest wird ordentlich gesichert werden. Wir brauchen eine API, das heißt, wir brauchen einen Starter, um ein Web-Saver zu starten oder Web-Saver zu haben. Actrator kann Laufzeitenformationen zurückgeben. Man kann sehen, wie gut die Software läuft. Das ist notwendig, wenn wir später uns anschauen müssen, wie es funktioniert. Hier ist ein Test-Scope, das heißt, es läuft nicht in der Produktions-Version. Hier können wir die Spring Boot-Frame-Work testen und auch diese Sicherheitsoptionen, die da mitgekommen sind. Man muss nicht alle Teile davon verstehen, ein Java-Fektor zu werden, um das zu benutzen, weil die meisten Software, die eine Abhängigkeits-Management-Systeme haben, kann man sowas benutzen. Hier unten haben wir die Sicherheitslücke oder die unsichere Java-Strux-Version, oder Herp-Patches-Strux-Version, die wir uns anschauen wollen. Das Problem hier ist, dass diese sechs oder sieben Abhängigkeiten, wenn sie links und sie führen dazu, dass es 80 weitere Abhängigkeiten gibt, nur für die indirekte Abhängigkeiten. Und jede Abhängigkeit bringt nur Bibliotheken, die benötigt werden, und die bringen weitere Bibliotheken, und das wird zu einem großen, aufgeblasenen Bibliothek. Da, Spring Boot ist sehr gut, hat nur schnelle Antwortzeiten, wenn sie eine Sicherheitslücke finden. Wir haben sechs Maven-Abhängigkeiten, und wir können das auf GitHub finden, und wir werden später darüber reden. Wir haben auch um die 70 indirekte Abhängigkeiten, da gibt es eine ganze Menge Verwundbarkeiten, und du möchtest auf jeden Fall mindestens die Patchen, die öffentlich bekannt sind, dass sie Schwachstellen haben. Also es geht hier wirklich um die niedrig hängenden Früchte. Jeder kann das finden, und du solltest es auch schaffen. Was können wir tun, um verwundbar Abhängigkeiten zu finden? Da gibt es Werkzeuge, und das ist ein richtig großer Hype in der Softwareindustrie. Es gibt ein Haufen Hersteller und Produkte dafür, GitHub. Ich bin nicht wirklich dafür, Sachen zu bewerben, die man bezahlen muss, aber GitHub macht das für öffentliche Open-Source-Software. Also wenn du der Owner bist von GitHub, dann wirst du mitbekommen, wenn GitHub eine Verwundbarkeit in deinem Abhängigkeitssystem findet, wenn du einen der großen Programmi-Frameworks benutzt. Sie werden dir einen Alarm anzeigen, und du die richtigen Notifications hast, dann kriegst du sogar eine E-Mail dafür. Das ist ziemlich gut, und vor ein paar Monaten haben sie auch noch ein System dazu gebaut, dass deine Verbundbarkeit in Patchen, oder deine Bibliotheken Patchen, kann. Naja, jetzt fragt man sich, wenn der Owner eine dieser Probleme sieht, dann ist es okay, dann sieht es niemand außer der Owner, aber wenn jemand deinen Repository forkt, dann kann er plötzlich auch die Sache der Kriterie nachrichten, und das wird dann vielleicht problematisch, weil er das ja dann mitbekommt. Für die Demo und für den ganzen Vortrag benutze ich Dependency Check, weil das ein Open-Source-Tool ist, Web-Zack, ein Open-Web-Application-Sicherheitsprojekt. Wenn man Geld spendet, dann ... manche erlauben, maintainer von Dependency Check, die Software besser zu machen. Wenn du sie was fragst, dann reagieren sie sehr schnell. Das ist klasse. Okay, wie funktioniert das? Es gibt diese Datenbank, die von einem amerikanischen Regierungsorganisation betrieben wird. Da kannst du die CVE-Daten herbekommen. Also die Datenbank mit den tatsächlichen Verwundbarkeiten, mit den Beschreibungen, mit dem Scoring, den Werten. Und dann kannst du einen Abhängigkeitscheck-Überprüfung machen. Im Maven kannst du es natürlich auch in den Docker machen, wenn du Maven nicht benutzt. Du kannst einen Kommando-Zeientool benutzen, um deine Software zu testen. Ich denke, für Maven oder Cradle macht das selbe für Java. Für solche Software ist es sehr einfach, es auf diese Art und Weise zu nutzen. Aber es kommt echt drauf an, wie es dir passt. Weil du solltest testen, und es ist nicht unbedingt wichtig, wie. Okay, lass uns mal anschauen, wie das funktioniert. Für die Leute, die Java und Maven kennen, ich habe ein Maven-Projekt programmiert hier. Und wir laufen diesen Test durch, und es dauert ein paar Sekunden. Im Demorepo gibt es kein automatisches Update. Wenn man das jetzt laufen lässt, und man hat es noch nie gemacht, Abhängigkeitsüberprüfung, dann wird man gefragt, die Datenbank zu aktualisieren vorneweg. Okay, da gibt es ein paar Verwundbarkeiten, also wir sind ein bisschen kaputt. Das wird also Exitcode 1 zurückgeben. Und alles, was nicht null ist, ist ein Problem, ist schlecht. Hier kann man die Verwundbarkeiten sehen, die gefunden wurden. Wir haben irgendwie JSON-DataBind-Datenbindung. Kann man das hinten lesen? Bin mal daumen hoch oder runter? Das ist ein JSON-Parser, den man benutzen kann in einer Anwendung, das ist ziemlich bekannt. Und das ist eine dieser indirekten Abhängigkeiten. Ich habe den nicht wirklich da reingepackt, also nicht bewusst, aber eine der Spring Boot Abhängigkeiten hat das mitgebracht. Und das ist eine echte Verwundbarkeit, eine echte Sicherheitslücke. Es gibt ein Patch dafür in 2.991 Hotfix, aber die Spring Boot Version, die diese Abhängigkeit mit sich bringt, hat das noch nicht als Upgrade erhalten. Das ist also, wenn man ein Prozess hat, diese Sachen zu fixen, dann könnte man das manuell aktualisieren zu Version 2.991 und dann würde das funktionieren. Wenn wir später Zeit haben oder wenn ihr morgen zum Workshop kommt, dann können wir damit ein bisschen rumspielen. Da gibt es Spring Security Core, das ist ein falscher Alarm. Da gab es irgendwie in Version 5.0 irgendein Problem und es wurde auch gefixt, aber es ist irgendwie immer noch in der Verwundbarkeitsdatenbank. Und deswegen sagen sie, das wäre ein Problem, aber das ist eigentlich nicht mehr der Fall. Es geht um Authentifizierung, Autorisierungskram. Wenn das immer noch ein Problem wäre und du würdest Autorisierung darüber nutzen und du würdest Autorisierungssachen in Java benutzen, dann solltest du das aktualisieren. Und dann gibt es natürlich die Strutsverwundbarkeit. Das sind zehn wirklich alte aus 2017 kommende Sicherheitslücken und kommende File Upload ist auch etwas, was mit Struts herkommt. Das wird jetzt nicht Fokus sein. Das coole Anabhängigkeitsüberprüfung ist, oh, ich habe vergessen. Die Anwendung an sich macht nichts. Die macht noch nicht mal Hallo Welt. Das ist was du kriegst. Wenn du diese Abhängigkeiten einbindest, dann kriegst du das und das. Du kriegst ein Lock-in-Screen im Server und du kannst dich aber niemals anloggen, weil wir haben gar keine Nutzerdaten. Okay. Abhängigkeitsüberprüfung gibt dir nicht nur die Kommando-Zeilenreferenzen, sondern generiert auch ein HTML-Report, den du benutzen kannst für andere Sachen. Wenn man für das Struts-Problem sucht, dann findet man hier eine Beschreibung, was eigentlich das wirkliche Problem ist. Das ist jetzt gepasst für Struts. Und hier gibt es mehr Informationen, was eigentlich gerade abgeht, was passiert. Die haben eine Liste mit allen Sicherheitslücken, die gefunden wurden. Da gibt es eine sehr gute Beschreibung, was eigentlich wirklich gerade passiert hier und eine Wertung. Hier kann man übrigens lernen, nur wenn man diese Abhängigkeitsüberprüfung nutzt und diesen Report anguckt, dann wirst du verwundbare Drittpartei-Bibliotheken finden. Und die Bibliothek würde ich auch noch warnen, was potenziell passieren kann. Manchmal gibt es sogar ein Link zur Exploit-Datenbank. Exploit-Datenbank ist der ganz große, der kritische 10.0-Paser. Die Schwachstelle, die ich vorher schon erwähnt hatte, man kann auch funktionierende Exploits finden, die man testen kann, zum Beispiel auf deinem eigenen Server, bitte, nur auf eurem eigenen, nicht auf anderen Leuten. Das ist ein sehr, sehr guter Weg, um Schwachstein kennenzulernen. Wenn du keine Ahnung hast, wie groß das Problem ist, dann schauen in den Report, guck nach Exploit-Dibis oder anderen Beschreibungen. Und manche von denen sind sehr, sehr hilfreich, das Verständnis für die Situation zu verbessern. Eine weitere Sache, der Bericht lässt dich auch, hat vorbereitete XML-Statements um Forstpositives zu weitlisten, also, dass man sie erlauben kann. Spring Security. Spring Security. Hier, das ist doch. Also, wenn wir jetzt zum Beispiel das weitlisten wollen, weil wir uns darüber nachgelesen haben, wir haben Berichte gelesen, dass das ein falscher Alarm ist, dann können wir hier den Suppression-Unterdrückungsknopf drücken. Und wenn das jetzt funktioniert, dann gibt es XML-Dattenschnipsel, den wir für unser Konfigurations-File benutzen können. Dann können wir das kopieren und hinzufügen. Ich glaube, ich habe es irgendwo aufgemacht in dieses Unterdrückungs-File, Suppression-File, unsere Java-File. Da können wir das hinzufügen. Suppressed here. Und ja, genau um diese Verundbarkeit geht. Ich habe die jetzt unterdrückt. Und jetzt taucht sie nicht mehr auf, weil abhängig jetzt die Überprüfung das jetzt auf eine positive Liste gesetzt hat. Okay, irgendwie habe ich jetzt was übersehen. Aber ich habe nicht aktualisiert, das Dependency-Check-Plugin habe ich nicht aktualisiert vor dem Talk. Und jetzt ist irgendwas in der XML-Beschreibung anders geworden. Also jetzt müsst ihr mir einfach vertrauen, dass das normalerweise funktioniert würde. Okay, lasst uns weitermachen mit anderen spannenden Sachen. Okay, ihr könnt auch das den Output benutzen, um in anderen Werkzeugen zu benutzen. Also zum Beispiel hier so nahe ein Code-Qualitätswerkzeug, das eine Hinrichtung ansehen kann. Aber von weg kriegt es keine Zeit. Also Docker, wer hat seine Docker-Container nach Sicherheitslücken untersucht? Drei Menschen. Okay. Docker. Ich benutze Docker. Ihr wisst wie es funktioniert. Ihr habt einen Container oder eine Software-Beschreibung, die ihr irgendwo im Internet habt. Ihr ladet ihn herunter, das ist den moderne Weg, wenn man Software ausführt. Und es ist ein Scanner, der heißt Claire, der gehört zu CoreOS. Inzwischen gehört er zu Redhead und IBM. Die machen Container-Dinger und Kubernetes-Dinger und sie brauchen irgendwie so ein Container-Scanning-Werkzeug und es funktioniert ähnlich. Sie fragen auch die NIST-Datenbank von diesen Sicherheits-CV-E-Tons an. Ihre haben lokale Software, die sie da laufen lassen. Wir haben ein Client, der die Docker-Container das hinzufügt und die Scannen die ganzen Schichten, die Docker-Schichten und sagen, was das Problem ist. Also, ich habe hier ein Clare-Server schon mal gestartet und eine Clare-Datenbank. Normalerweise möchte man, dass dieses Server irgendwo in der Infrastruktur laufen lassen. Und ich habe hier diese Anwendung paketiert in ein Container, also diese Mavenanwendung, die wir, beispielsweise Anwendung, und ich habe ein einfaches Java-Image für Java 8, das ist eines der offiziellen Images vom OpenJDK. Und ich soll uns mal schauen, was passiert, was damit passiert. Das dauert ein paar Sekunden und es ist ziemlich spät und sieht ziemlich viel Rotis und ich habe es hier früher schon mal gelaufen lassen und man sieht hier unten, das ist das Image, das das Bild 99 Images hat, sich als Fehler hat. Aber das sind alle im Basis Image. Das sind keine Probleme, die bei unserer Anwendung sind, sondern die sind einfach da, wenn man ein OpenJDK-Image herunter lädt, zum Beispiel G-Lib C ist Problemat hier und JuicyLinux. Man kann auch foldpositives weitlisten oder man kann eine Liste erstellen von Software, wo man sagt, hey, das gehört, das ist bei unserer Software irrelevant. Also, wenn man ein Problem mit dem SSH-Demon hat, dann könnte man vielleicht in den Server einbauen, aber vielleicht macht man einfach den Port zu und dann ist es einfach nicht mehr relevant. Und dann kann man sich hier ab Grenzen definieren, wie man sagt, zum Beispiel, hey, vielleicht halten wir uns nur kritische und hohe oder mittel Sachen anschauen und nicht die ganzen vielen kleinen. Und das Ganze in einer Continuous Integration-System zu haben, braucht noch vielleicht noch ein bisschen weitere Werkzeuge. Normalerweise, wenn man moderne Bildwerkzeuge benutzt, Github, CAE und so weiter, dann wird man potenziell nicht die Zeit zu haben, die ganze Infrastruktur aufzubauen. Manchmal möchte man kein Erklär-Server laufen lassen, dem man die ganze Zeit laufen hat. Und vielleicht möchte man sich nach der Datenbank administrieren. Und was man innerhalb von den Continuous Integration-Werkzeugen machen kann, bevor der Scan wirklich durchläuft, kann man ein Datenbank-Container starten und ein Clare-Scanner-Container starten und Armin zieht something. Ich hatte einen französischen Namen und ich kann ihn nicht aussprechen, man kann den Rebus auf Github finden. Der hat diese Lösung erstellt. Bevor man den Scan startet, lasst man starten bei dieser Docker-Container und nach dem Scan fährt man sie einfach wieder runter oder stoppt sie. Und ich habe sie offiziell auf meiner Maschine gerade gestartet. Das heißt, nach dem Scan werde ich sie einfach anhalten. Das Demorepo beinhaltet dieses Jenkins-Datei. Das heißt, wenn man Jenkins benutzt, dann kann man diese ganzen Werkzeuge auch benutzen, diese Tests auch benutzen. Man kann vielleicht ein bisschen rumschauen, wie das Jenkins so genau macht. Mit den Rechten, die die Produkte haben und so weiter. Es gibt auch öffentliche Repositories, die diesen Scan fürein machen. Zum Beispiel Quay ist eine Attative für Docker Hub. Das heißt, man kann seinen Repository auf Quay haben und sie scannen es fürein. Github, bzw. GitLab, hat auch so einen Service oder eine Methode, wie man die Container scannen lässt und geben einen Hinweis, was schon kaputt sein könnte. Ich glaube, wir haben noch eine kurze Zeit, um einen kurzen API-Scan durchzuführen. Wie ich schon vorhin gesagt habe, ich habe diese Anwendung auf meiner lokalen Maschine gestartet. Und ich könnte jetzt einen Zap ... I'm out of time. Die Zeit. Okay, so, let's start over. Noch mal von vorne. Wir können jetzt ein anderes Werkzeug von OWASP, Zap Attacks Anriffsboxie, wo die automatisch gescannt wird, um Sicherheitslücken zu finden, die dort vorhanden sind. Das sind Sachen, wo eine SQL Insection möglich ist oder Crosshead Scripting. Und das ist jetzt nicht so relevant. Und was wir jetzt hier machen, ist, wir nutzen wieder Docker, weil wir Docker mögen und Container mögen. Und wir können jetzt ... ein Docker-Container herunterladen, der von Ihnen veröffentlicht wird, wo der Scanner schon drin ist. Dann können wir Ihnen einfach gegen die Webseite laufen lassen. Und ich werde das Ergebnis kurz zeigen, was davon erstellt wird. Und ich habe das vor ... diese Software schon vorher mal ... aber prüft. Und das ist das Coole von diesem Werkzeug. Das ist auch eine große Erklärung, was die Sicherheitslücke wirklich ist. Also, ich weiß gar nicht, was die X-Frame-Mission-Option-Header ist. Weißt das jemand von euch? Zwei Menschen? Oh, sehr gut. Das ist ... in der Lösung ist immer eine Erklärung, was das wirkliche Problem ist und was man machen kann, um es zu reparieren. Wo eine Erklärung dafür ist und wo man ... weitere Optionen oder Lösungsoptionen finden kann. Also, ein weiterer Angriff. Es dauert auch eine Weile, also habe ich das schon mal für euch gemacht. Und wenn man das Ganze gegen die Cynic-Seite laufen lässt, zwischen WordPress, das ist für viele Warnings, die potenziell kritisch sein können. Wir haben eine Firma, die die Seite für uns macht und vielleicht sollten wir den mal darüber reden. Das hier ist einfach nur eine Spider, also ein Web-Scanner, der geht zu einer Startseite, Cynics.de, hier unten ist konfiguriert. Und das fängt bei Cynic-Seite an. Und es wird alle Links, die da drauf sind, ausprobieren. Es wird tiefer und tiefer in die Webseite gehen, die da zu viel gestellt wird. Also, wenn man eine Webseite hat, dann wissen wir in der Regel, was für Endpoints sind. Das heißt, man könnte das generieren, z.B. mit Swagger. Das ist, wenn man drei Endpoints hat, z.B. Lock-In, vielleicht ein Shop, eine Webseite und so was, dann könnte man dem Werkzeug sagen, hey, hier sind die APIs, und diese URL, mit denen man das benutzen könnte. Das heißt, es würde viel Zeit sparen. Je länger es läuft, desto mehr kann es auch finden. Okay. Okay. Leider habe ich jetzt nicht wirklich Zeit. Mir leid. Wenn ihr es euch genauer anschauen wollt, dann werden Daniel und ich einen zweistudigen Workshop anbieten. Und wir weitere Benutzungsaspekte vor den Werkzeugen zeigen. Vielleicht könnt ihr es auch ausprobieren. Morgen, glaube ich, ist 3.15 Uhr am Nachmittag. Es ist ein bisschen ein paar Mal verschoben worden. Das heißt, ich sollte euch nochmal beide anschauen. Wenn ihr nicht hinkommt, dann könnt ihr bei unserem Village vorbeikommen und dort nochmal die Fragen stellen. Ja. Normalerweise würde ich am Ende sagen, wie man darauf reagieren soll, was der Prozess, was kann man denn jetzt machen? Vielleicht noch einen Satz darüber im aktuellen Team, wenn ein Sicherheitsdruck gefunden wird, dann ist der Ersteller des aktuellen Reported Requests dafür verantwortlich, dass so schnell wie möglich gefixt wird. Wir haben eine Policy, die sagt, keine Sicherheit zu dücken. Das ist alles, was gefunden wird, muss sofort repariert, abgesichert werden. Wenn wir etwas finden in unserem Produktionscode, dann haben wir ein Job, der das jede Nacht überprüft. Und der Erste, der am Morgen kommt, oder derjenige, der auf Abruf da ist, muss sich das mindestens mal anschauen. Sie können aber auch herausfinden, das ist ein false positive. Sie können herausfinden, dass es eine riesige, riesige, schlimme Möglichkeit ist, um das gesamte Netzwerk zu unterbrechen. Vielleicht muss das sofort gefixt werden. Aber das ist, was ihr genau macht, müsst ihr selber entscheiden. Das ist das interessanteste Teil für eine Firma und das Produktionsteam. Vielen Dank. Auch vielen Dank fürs Zuhören aus der Übersetzerkabine. Wir sind Franz T. Mr. Browns. Es gibt ein paar Minuten Restzeit für Fragen. Also wer Fragen hat, bitte an die Mikros. Und dann einfach die Frage stellen. Okay, es scheint keine Fragen für den Moment zu geben. Ah, okay, da kommt einer. Ja, bitte. Vielen Dank für den Vortrag. Meine Frage ist, wie man mit den falschen positiven Ergebnissen umgeht. Du hast ein Beispiel gezeigt. Zum Beispiel, wenn man es selbst benutzt, dann kriegt man viele falsche positive und manchmal ist es ziemlich kompliziert, wenn es Zeug in Bibliotheken ist, die man nicht mal benutzt. Zum Beispiel, wenn man APIs benutzt, die gar nicht verwundbar sind, wenn ich jetzt mit Entwicklungsteams gesprochen habe, dann reden die meistens darum, Ausnahmen zu behandeln. Hast du eine generelle Empfehlung oder hast du Erfahrungen, die du gerne teilen möchtest, diesbezüglich? Insbesondere bei dynamischem Scanning, bei URLs, APIs oder Webservern, ist es echt zeitaufwendig. Ich kann vielleicht ein Beispiel teilen, dass ich in einem Team bei einem Freund von mir gesehen habe. Die haben API-Tests jede Nacht und als sie angefangen haben, haben sie sich ein paar Tage hingesetzt und bei denen sie eine sehr große Anwendung haben, die über Jahre gewachsen ist, ganz, ganz große API und die haben das durchscannen lassen. Mit dem API-Spezifikation, die sie vorher generiert haben, haben sie die App gescannt und sie haben jede einzelne Verwundbarkeit berufend und die ausgespuckt wurde und das ist, glaube ich, die einzige Möglichkeit, die du es machen kannst. Du musst sie die Zeit nehmen und alle durchlaufen lassen. Entschuldigung, wenn du keine neuen, null neue Verwundbarkeiten hast, die sich lohnen zu fixen, dann kannst du zum Beispiel eine wöchentliche oder nächtliche Aufgabe machen, die immer die API überprüft, ob etwas Neues da ist und wenn etwas Neues da ist, dann musst du das entsprechend deiner Richtlinien bearbeiten. Aber ich glaube, es gibt keinen guten Weg, das anders zu machen. Aber natürlich, man kann immer gucken, wenn man Bibliotheken hat, die Verwundbarkeiten mit sich bringen und man die nicht unbedingt braucht, dann ich würde sagen, wenn man die APIs schmeißt, die du nicht brauchst, das ist, wenn du neu bist, dann solltest du immer mit deinem Sicherheitsteam reden oder wenn du nicht sicher bist mit dem Netzwerkteam oder wenn du das Netzwerkteam selber bist, dann solltest du über deine Firewall-Regeln nachdenken und so was, aber man sollte jede Verwundbarkeit, die man findet, das tut weh, ja. Okay, eine letzte Frage von hinten. Danke für den Vortrag. Hast du Erfahrung bei Crocos wenn man das Zeug in den Containern hat, dann ist man schnell durcheinander und nur die wahren Notwendigkeiten rauszufinden könnte natürlich schwer sein. Aber man muss nicht nur bear-Code-Container ohne Betriebssystem als generelle Möglichkeit benötigen, so wenig Software wie möglich um deine Software laufen zu lassen. Das ist ein Docker-Best-Practice. Im Dockerkammer oder im Java kann man das OpenJDK App-Image die Offiziellen benutzen und wenn du die jetzt runterlehnt, dann kommen die ohne Verwundbarkeiten. Ein kleines Problem mit den Scanners, die ich benutzt habe Zeug wie Grail-BM die haben keine Container oder Sachen, die Google anobietet, Chip, falls du das kennst es macht dynamisch Container das sind nicht wirklich Container im Docker-Sinn also kann der Scanner die nicht wirklich durchsuchen. Ich denke das sind Projekte wo man bei der Pflege darauf achten muss dass man die Verwundbarkeiten findet und löst. Aber es ist natürlich auch leichter die Sachen zu anzugehen, weil man die Systeme einfach wöchentlich stündlich aktualisieren könnte. Okay, wir sind am Ende der Zeit angekommen. Vielen Dank für deinen Vortrag.