 Ich erzähle heute was da rüber, ja wie kriegt man eigentlich Security in Entwicklerteams? Meistens haben die was anderes zu tun als sich um Security zu kümmern. Das ist gar nicht mehr vielleicht nicht so einfach, aber vielleicht auch nicht so schwer. Da werde ich ein bisschen drüber reden. Ich mache das auch im beruflichen Umfeld, wo ich mich quasi um Security kümmere und halt auch dieses Modell im Unternehmen mit Einsätze, um das irgendwie beides zusammenzubringen. Genau, ja da steht auch oberst rüber, wer weiß was oberst ist, ja habe ich mir gedacht. Aber die machen ja nicht nur die RIS, genau also kurz zu mir Kontaktdaten. Ich mache das wie gesagt auch beruflich und genau ich mache auch immer ein bisschen Werbung für oberst, weil das ist ja auch so ein Community-Projekt, das von Freiwilligen lebt. Und die machen halt nicht nur diese Top 10-Risks, die halt so das bekannteste sind von der oberst, was auch viele benutzen, sondern es gibt jede Menge andere Tools, Dokumentationen, Guidelines. Das fällt jetzt so ein bisschen in die Guideline-Kategorie. Aber da sind ein paar Sachen aufgezählt, die man vielleicht kennen sollte, weil die auch alle entweder helfen Sicherheit zu verbessern. Aber es gibt noch viel mehr Projekte von der oberst und es gibt auch eine Gruppe in Karlsruhe und in ein paar anderen deutschen Städten. Und da kann man einfach mal vorbeischauen, lokale Meetup-Gruppe suchen und dann mal mit hinkommen, da gibt es auch immer spannende Vorträge. Hier in Karlsruhe ist es im Moment noch der erste Montag, jeden Monat, aber das ändert sich vielleicht am Zumal. Aber wenn man in der Meetup-Gruppe ist, kriegt man es auf jeden Fall mit. Genau, wie sieht so der Tag eines Programmierers oder einer Programmiererin aus? Vielleicht, die müssen sich, das jetzt so ein bisschen Beispiel, weblastig, aber das macht ja nichts. Da sind ganz viele Bubbles mit ganz vielen Abkürzungen. Ich glaube, ich kann nicht mehr alle Akronöme, die da drin stehen, auflösen. Also sieht man, die sind irgendwie mit vielen Dingen beschäftigt den ganzen Tag und jetzt sollen sie auch noch Security mitmachen. Es ist vielleicht nicht so einfach. Man sieht hier allein ein HTML, CSS, das ist schon eine Komplexität in den ganzen LPI's, die man beherrschen und können muss, um überhaupt mal die Funktionalität auf die Straße zu bringen. Oder hier sieht man mal so ein Release-Zugus für ein beliebiges JavaScript-Framework. Das ist mit anderen Frameworks, die heutzutage oft zum Einsatz kommen ja nicht anders. Das Zeug ist ja entschädigt, das bewegt sich ständig nach vorn. Da muss man ja erst mal einen Überblick behalten. Und das ist natürlich eine Challenge, weil es gibt auch noch irgendwie, im echten Leben gibt es Deadlines, die man einhalten muss. Man hat eine ganze Menge drum herum. Es gibt irgendwie Meetings, es gibt allgiele Entwicklungen, je nachdem, wie auch immer das aufgebaut ist. Ich muss die ganzen Frameworks, die User-Agenz, die Browser, die Standards, muss ich kennen. Ich muss mich um die eigentliche Funktionalität kümmern und dann gibt es eine ganze Menge crossfunktionale Anforderungen. Ich nenne das nicht mehr nicht funktionale Anforderungen oder non-functional Requirements. Das ist eher der etablierte Begriff, aber der ist halt ein bisschen schwierig, weil er das immer so ein bisschen runterrated. Und eigentlich sind das ja übergeordnete Anforderungen unter anderem aus dem Sicherheitsbereich, die ich immer berücksichtigen muss. Deswegen finde ich den Begriff crossfunctional Requirements oder halt übergreifende Anforderungen dann besser als diese negierte Variante. Genau, und dann muss man wahrscheinlich auch noch Bugs fixen. Und man hat noch DevOps heutzutage und dann ist irgendwann der Tag zu Ende. Nix mit Security. Dann kommen aber der CCC und sagt, ja, es muss aber sicher sein. Und wie kann man das eigentlich nicht hinkriegen? Aber wir gerade gesehen haben, naja, vielleicht ist das gar nicht so einfach. Ja, dann kommt halt hier irgendwie die Ladesäulen sind nicht sicher. Die hat man ja jetzt gerade erst aufgestellt. Wie kann man im Jahr 2017 das noch falsch machen? Ja, das ist genau das Problem. Ja, dann kommt noch dazu, wie sieht das auf Konferenzen auf? Also auf Entwicklerkonferenzen, jetzt nicht auf Konferenzen, die Security als Schwerpunkt haben, sondern auf den ganz normalen. Wie viele Security Tracks gibt es da? Wie viele Talks gibt es in diesen Security Tracks für die normalen Entwickler? Gehen die dahin, fordern die das ein. Und selbst wenn es das auf der Konferenz gibt, was passiert, wenn die zurückkommen in ihre Organisation, dann fängt wieder diese Trädmühler an, die ich gerade auf der Slide davor gezeigt habe. Dieses Security Champions Ansatz, den ich heute ein bisschen vorstellen möchte, der kommt halt auch aus dem Oversumfeld. Der Denise Cruz hat das schon 2015 so ein bisschen promoted. Und jetzt letztes Jahr auf der, die Overs hat ja auch immer so eine Hauskonferenz, aber das ist halt wieder so eine security-fokussierte Konferenz natürlich. Da gehen wieder alle hin, die Security machen, aber nicht die Entwickler, die Ladesäulen bauen oder sowas. Wobei das auch mehr wird, aber im Prinzip trifft sich da die Community immer unter sich. Und die haben das nochmal ein bisschen weiterentwickelt. Und im Prinzip stelle ich heute diese Ansätze vor, was für Möglichkeiten hat man und wie kann man das in der eigenen Organisation vielleicht etablieren, einbauen? Deswegen switche ich jetzt mal das Slide Deck. So, genau, das ist von Alexander Eintrug. Und der hat das da vorgestellt. Der ist Head of AppSec bei Oprah. Und genau, was für Champions. Ich habe das ja eben schon so ein bisschen angedeutet. Hier ist nochmal zwei Links für die vorherigen Slide Decks, die es dafür von der Overs schon gibt. Genau, viele Projekte, man hat viele Teams, verschiedene Technologien. Ich habe jetzt mal gezeigt, HTML5, CSS, alle möglichen JavaScript-Frameworks und das ist ja nur das Frontend. Und im Backend sieht es nicht besser aus. Alle möglichen Arten von Speichertechnologien, Containergeschichten und so weiter. Und Security Culture ist halt schwierig in der normalen Entwickler-Community oder auch allgemein im Unternehmen. Das ist ja eher immer so ein Ballast, was man noch irgendwie mitmachen muss, das ist nicht integriert. Alle sind offen dafür. Alle setzen sich für Security ein. Fühlen sich auch alle zuständig dafür und verantwortlich. Das Wissen wird natürlich immer getauscht unter den Teams und das Management steht da auch voll dahinter. Das ist ja die Realität, in der wir uns bewegen. Wahrscheinlich muss man da oft ja Know hinmachen, aber eigentlich sollten wir versuchen, da hinzukommen und wie kann man das machen? Genau, das funktioniert. Was sind die üblichen Antworten darauf? Das betrifft mich nicht. Das Risiko ist nicht groß genug. Da wird ja oft im Unternehmensumfeld ein risikobasierter Ansatz gefahren. Okay, wenn was schief geht, dann macht was anderes. Oder das ist noch ne Neutig. Das ist ein Pilotprojekt. Das brauchen wir jetzt noch nicht machen wir später. Oder diese Woche benutzen wir dieses Framework. Nächste Woche muss man ja schon wieder das neue Framework einbauen. Dann bleibt auch keine Zeit, Security zu machen. Oder das haben wir nicht selber geschrieben, third-party-Komponente. Nicht unser Problem. Und dann noch ein Formalismus extra dazu. Herzlichen Glückwunsch. Wir machen doch jetzt DevOps, da brauchen wir das alles nicht. Was ist jetzt mit den Champions? Was ist das eigentlich? Worum geht es da? Wer kann da mitmachen? Welchen Background braucht man da? Das ist völlig egal. Das ist die Idee dahinter. Es geht darum, dass es schon ein gewisses Interesse bei denjenigen, die da mitmachen vorhanden sein sollte. Und dass es nicht eine Pflicht ist, die jemanden zusätzlich auferlegt wird. Genau. Wichtig ist, dass das eine Person, die ein Security-Champion wird, das Projekt kennt und weiß, wo die Baustellen sind und wo man mal schnell eben so was dahin gelegt hat. Da aber eigentlich noch mal was tun müsste. Und so weiter. Und die Idee dahinter ist auch, genauso wie es heute in so cross-funktionalen Teams ja auch hier in Deutschland geht. Und so cross-funktionalen Teams ja auch jemanden gibt, der sich besonders gut mit den Testen auskennt und jemanden mit einer bestimmten Technologie. Dass es halt auch eine Person gibt, die sich besonders gut dann halt mit Security auskennt oder zumindest schon mal grundlegende Einschätzung vornehmen kann im Team selber, die Entwickler untereinander sich unterstützen können. Und dann aber auch weiß okay, ich bin jetzt auch wieder nicht. Jetzt gehe ich mal zum dedizierten Security-Team und bin die mit ein, weil das übersteigt jetzt halt auch meine oder die allgemeine Kompetenz im Team, wenn es um bestimmte Themen geht. Genau. Und was hat Besonderes geht darum, dass das jemand ist, der das auch voranbringen will. Also die Security besser machen will, als der aktuell in dem jeweiligen Projekt ist. Das heißt also auch, der Ansatz verfolgt so die Idee, dass sich in jedem Team so ein Security-Champion mindestens einhabt. Je nach Teamgröße sind es vielleicht auch mehr, um dort genau diese Security direkt im Team zu verankern und nicht ein dediziertes Security-Team irgendwo zu haben, was dann vielleicht noch was macht und wieder eine Checkliste durchgeht und so weiter, sondern dass das aus dem Team selber kommt. Auf dem Overster mit letztes Jahr gab es so eine kleine Umfrage, also das ist jetzt nicht besonders repräsentativ, aber um so einen kleinen Eindruck zu vermitteln, wie die Lage ist. Genau, was so die Erwartungen sind und dann halt auch, wie man das umsetzen kann, gibt es so ein kleines Playbook gleich. Also die meisten haben gesagt, okay, die wollen überhaupt erreichen, dass man Wissen austauscht über Security-Methoden vorgehen, wie programmiert man das richtig. Entscheidungsunterstützung, wie ich gerade schon gesagt habe, dass das Team auch selber entscheidungsfähig ist in bestimmten Rahmen, die Best Practices in der Organisation kennt oder vielleicht auch von außerhalb und sicherstellt, dass sie zum Einsatz kommen, dass sie auch mal ein Thread-Model bauen können, das ist nicht so trivial, muss man auch üben und einüben und benutzen, dass sie selber Security-Reviews machen können und hinten dann natürlich, ja, also Forschung und Research ist dann vielleicht weniger die Aufgabe von einem dedizierten Projektteam, aber wir natürlich schön, wenn die das mitmachen und wenn es ein Bug-Bounty-Programm in Internis oder in Externis ist, dass sie das auch mitbetreuen. Genau, dann gibt es noch weitere Ideen, dass dann solche appointed champions irgendwie auch mal auf eine Spezialkonferenz gehen, einfach um das Niveau zu heben, dass sie selber an der Ausarbeitung der Best Practices in der Organisation beteiligt sind, dass sie bei der Priorisierung helfen und auch bei den Updates auch mein Auge darauf haben, ja, wenn ich jetzt schon drei Releases lang meine externen Referenzen nicht nachgezogen habe, dann ist das nicht nur funktionär aus normaler Bugsicht, vielleicht nicht die beste Idee, sondern halt auch wegen der Security und so weiter. Also es sind schon eine ganze Menge Sachen, die man sich da vorstellen kann, die so eine Person macht. Genau, jo, viel Spaß, eine ganze Menge Erwartungen und die Idee ist ja schon immer, das ist ja ein normaler Entwickler, der macht das dann zusätzlich. Und alle haben was davon. Okay, aber wie kriegen wir das jetzt wirklich auf die Straße? Was braucht man dafür? Also das ist jetzt auch eine Ideensammlung, die hat sich halt in den letzten Jahren so dazu entwickelt. Ein paar Unternehmen machen das auch so, auch ein paar größere. Und genau, also man braucht sechs Punkte jetzt hier und zwar in welchen Teams will ich das ausrollen. Ich muss das ja nicht überall machen, aber es gibt bestimmten, das weiß jeder in seiner Organisation, wo man das braucht, wo man da vielleicht nicht so gut aufgestellt ist, das nochmal für sich selber definieren, welche dieser Aspekte, die ich auch gerade gezeigt habe, soll diese Rolle denn dann abdecken und wie können diese Leute untereinander kommunizieren? Wie kann das Team untereinander kommunizieren? Also dieses Security Champions, wie vernetzt man die untereinander? Wie kriegt man das Wissen da rein? Weil wir haben ja vorhin gesehen, das können alle möglichen Leute sein, die eben genau keinen Security Background haben und das auch nicht als ihre Hauptaufgabe haben. Weil so viele Security-Spezialisten kriege ich in der Regel nicht in den Unternehmen, aber ich muss das ja trotzdem irgendwie in den Entwicklerteam ausrollen. Und dann muss man die alle bei Laune halten und sicherstellen, dass sie das auch weiter kontinuierlich machen können, dass das nicht so ein Eintagesfliege wird oder so, jetzt haben wir mal was gemacht und dann ist es gut. Genau, wie kann man jetzt bei den einzelnen Punkten vorgehen? Ja, was ist ein Team? Das ist immer so eine Frage. Es kommt darauf an, nach was unterscheidet man das? Es sind jetzt ein paar Kriterien. Also das heißt, in welcher Entwicklergruppe, wo brauche ich ein Security-Champion, wo ist die Abgrenzung, aber das muss halt jeder für sich selber rausfinden. Es sind jetzt ein paar Punkte aufgeführt, die als Entscheidungshilfe dienen können an der Stelle. Genau. Und wenn man das dann gemacht hat, was auch immer das Team ist, dann hat man irgendwie so eine Übersicht. Man weiß, was dafür Technologien sind. Man hat ein Security-Contact. Man weiß, wer der eigentliche Team-Lead ist, der das Team verantwortet. Es gibt ein Produktmanager und das ist jetzt ein Beispiel, wie das bei Opera gemacht wird. Die Spalten, die man dann an der Tabelle sieht. Aber das kann halt jeder für sich definieren. Aber im Prinzip hat man dann hinterher eine Liste von Teams, je nach, egal wie die definiert wurden, und halt eine Liste von den Security-Contact, steht halt jetzt hier, aber das sind dann die Champions. Und jetzt haben wir hier okay, jetzt haben wir diese Gruppe von Entwicklern, die uns dabei in Zukunft unterstützen werden, sichere Stromtankstellen zu bauen zum Beispiel. Es gibt noch ein paar mehr. Oversprojekte, das ist hier auch noch eins, OpenSam, da steht für, jetzt muss ich kurz überlegen, es gibt nämlich noch ein zweites Modell, Software Assurity, Majority Modell heißt das Sam. Das ist auch wieder ein Hilfsmittel, um diese Komplexität runterzubrechen. Was muss man alles berücksichtigen? Ich muss die Leute schon, ich habe Governance, ich muss in der Entwicklung irgendwie ein Spread-Modell bauen, ich muss ein Security-Code-Review machen und ich muss im Deployment dann wieder darauf achten, dass ich bestimmte Maßnahmen in der Produktionsumgebung hinbekomme und so weiter. Das umschreibt dieses Security-Modell, also dieses Majority Modell, Majority deswegen, weil ich kann darüber sehr schön definieren, wo bin ich gerade, welche Aktivitäten habe ich schon, da sind zwölf Bereiche, mit die wir zwei Aktivitäten und dann kann ich mich da selber raten und dann sagen, okay, an der an der Stelle will ich irgendwie noch mehr Dinge tun, um besser zu werden und wie komme ich dahin, über welchen Zeitraum, also so ein bisschen auch ein Management-Tool an der Stelle. Und das wird halt auch von der Overs Maintenance, da gibt es auch, das wird regelmäßig weiterentwickelt, das im Moment auf 1,5 oder 1,6, in der Versionierung dieses Modell. Da gibt es auch, sage ich mal, eine kommerzielle Variante dazu, die nennt sich Bison. Es ist aber fast deckungsgleich, man kann die Modelle gegeneinander mapen und das ist halt im Hintergrund, das macht dann eher das Security-Team, aber man definiert das dann mit den anderen Teams, was man für das spezifische Produkt oder einen Team erreichen will und wie man damit umgehen kann. Und jetzt auf die Security-Champions zurückzukommen, ist dann natürlich die, die sollen das ja nicht alles selber machen, die werden dabei ja unterstützt, aber welche Punkte aus dem Modell, vor allem natürlich während der Entwicklung und Testphase, vielleicht auch beim Rollout, wenn man Dev Ops Geschichten macht, liegen dann zum Beispiel in der Teamverantwortung und dann halt auch bei diesem Champion. Ja, genau. Also hier sind jetzt ein paar Beispiele aufgelistet, auf was man alles achten sollte und habe ich ja auch schon zum Teil angesprochen, also die Security-Reviews, aber dafür müssen die Leute oder ja auch wissen, auf was achten, worauf muss man gucken. Was sind Best Practices? Da gibt es halt auch das, was ich auf der zweiten Slide hatte, die beschreiben ja zum Beispiel, wie baue ich eine bestimmte Log in sich, auf was muss ich da alles achten, wenn ich ja sowas in meiner Anwendung einbaue und wie mache ich das richtig. Die können natürlich, wenn sie schon mal dabei sind und sehen, oh, ich habe ja hier schon eine Log in Funktion, die Anwendung existiert schon eine Weile und jetzt führt man dieses Security-Champions-Modell neu ein, dass sie dann auch erkennen, wo man vielleicht Baustellen hat, dass entweder selber ein Team angehen oder halt zumindest auch sich untereinander austauschen und dem Security-Team Informationen übergeben, wo man vielleicht noch was tun muss, die kann man trainieren, wie man solche Tools nutzt, die Scans durchführen und dann auch die Ergebnisse solcher Scans zu bewerten. Das ist ja nicht alles nur, weil das Tool sagt, da ist was kaputt, das ist vielleicht nicht kaputt oder das Tool sieht es als nicht so kritisch an, aber in dem Kontext, in dem man sich bewegt, weiß man, dass das vielleicht doch ein Problem ist. Genau. Hier steht Nominate, Not a Point, habe ich auch schon gesagt. Also, das wird sich natürlich nicht immer durchhalten lassen. Je nach Größe und Menge werden da jetzt nicht so viele Leute sagen, hey, ja klar, ich mache auch noch die Security mit. Das war schon immer mein Steckenpferd. Es hilft ungemein, wenn die Leute das natürlich freiwillig und von sich aus tun wollen und da Lust drauf haben. Es ist ein wichtiges Kriterium, aber das wird sich nicht komplett durchhalten lassen, je nach Organisation und Größe. Ja, das ist wieder der Klassiker, ich kenne das auch. Wenn man so was macht und eigentlich ist es eine verdammte gute Idee heutzutage, so ein Konzept zu etablieren, aber man braucht natürlich das OK und die Rückendeckung der Management-Ebenen, die dafür zuständig sind und die das im Zweifel wieder sterben lassen können. Und wenn das nicht da ist, dann endet man bei dem Klassischen, ich hatte keine Zeit dafür, ich hatte ein Projekt Deadline, ich muss dies machen, ich muss jenes machen, wenn man die Technologie gewechselt, das Ding muss laufen und die Security wird als erstes rausgestrichen, vielleicht als zweites, als erstes Dokumentation und dann die Security. Ja, aber das ist halt ein Problem. Dann hat man halt schlecht unsichere Ladestationen in der Landschaft, drum stehen kriegt man mindestens schlechte Presse. Und die Idee ist halt, dass man besser wird, aber ich kann halt jetzt nicht 100 Security-Leute einstellen, die die Projekte nicht kennen, deswegen diese Idee, man rekrutet quasi die normalen Entwickler, schaut wer hat Lust drauf und die kriegen so ein bisschen eine Zusatzausbildung. Genau, wenn die schon mal da sind, dann sollen die sich auch irgendwie als Champion führen und nicht nur jetzt hast du noch ein bisschen was extra zu tun, aber mehr Zeit hast du nicht. Das Bild ist auch noch aus dem ersten Slide Deck vom Denise, dass man halt irgendwelche G-Mix, also dass man so eine Gruppenidentität schafft, sagt, das sind halt diese Champions, dass die sich auch so fühlen und dass die irgendwie das Wiedererkennungselemente gibt. Genau. Ja, dann müssen die irgendwie miteinander kommunizieren, weil wenn jeder in seinem Projektteam dann versucht, das alleine zu machen, das wird nicht besonders gut funktionieren. Das heißt, wenn man jetzt so ein Team hat, haben das auch bei uns sind das irgendwie 20 Leute von 80 Entwicklern, dass sie miteinander reden können. Das hängt natürlich von dem, welche Tools benutzt man intern, was dafür angemessen ist, aber auf jeden Fall sollte es diese Kanäle geben, die sollten da alle drauf subscribt oder integriert sein, dann auch Austauschen gegenseitig zu helfen, eine Frage zu stellen und so weiter. So, kommen wir zu fünftens, was nicht unwichtig ist, die Standard-Entwicklerinnen und Entwicklern, sage ich jetzt mal, die kommen nicht mit einem Security Background. Das ist ja auch okay so, aber das muss man sich auch bewusst machen und da drauf eingehen. Das heißt, man hat die da jetzt irgendwie, alle sagt, hey, du bist jetzt Security Champion, viel Spaß. Da ist irgendwie ein Overslide Deck und da sind die Top 10 Risken und da sind die Productive Controls und da sind die Security Header, mach mal. Das wird nicht funktionieren, weil die denken anders. Man muss dieses Wissen aufbauen und vermitteln und trainieren und wahrscheinlich auch regelmäßig erneuern. Ich habe vorgestern den Vortrag über die Security Header gemacht und da kommen jedes Jahr irgendwie zwei dazu. Das reicht halt nicht, das einmal zu tun und man muss ja auch auf die verschiedenen Themen fit machen und natürlich ist es super, Checklisten zu benutzen. Da muss man auch motivieren, dass die Leute das verstehen, wofür ist die Checkliste da? Wir haben sowas auch, aber es ist immer wieder interessant festzustellen, wie schwer es zu vermitteln ist, was der Sinn davon ist und wo kommt jetzt so eine Checkliste her? Da sieht man, die kann man auch ein bisschen differenzieren. Da gibt es auch noch ein schönes Oversprojekt, das ist jetzt nicht auf dem Slide Deck, das nennt sich Security Rat, machen ein paar Leute aus Karlsruhe und Ratchet for Requirements Automation Tool und das ist im Prinzip eine interaktive Checkliste, da kann man über ein paar Parameter sagen, das ist ein Backend, das ist ein Frontend, das hat eine Authorisation oder nicht und so weiter und dann fallen da, da liegt noch ein... Dann fällt eine Menge an Tickets raus, die man dem Projekt geben kann, das hat auch eine Kopplung an Jira und dann kann man da Tickets generieren und das Projekt kann das ganz normal in seinem Backlock abarbeiten von den Themen, die da drin sind. Da gibt es auch eine vorgefertigte Liste, die basiert auch wieder. Tooling ist wichtig. Es gibt auch noch, ich glaube, das kommt auch noch später auf den Slide Deck ASVS, das ist ein Application Security Verification Standard, das ist auch ein Oversprojekt. Also was würde ein Security Pen-Tester jetzt gegen so eine Anwendung testen und dafür, dies ist alles aufgeschrieben und das hat auch in diesem Security Rat als Baseline drin und dann kann man das mit eigenen Checks, Best Practices und so weiter erweitern und dann entsprechend in den Teams benutzen. Genau, hier ist es ja noch mal schön aufgelistet. Es gibt noch mehr Standards, vom Zert von allen möglichen Organisationen aber das ist wichtig, dass die Security Champions da gemeinsam mit draufschaut und die auch dahin bringt, dass die Dinge kennen und verstehen, die da drin stehen um das dann auch im jeweiligen Team umsetzen zu können. Genau. Dann gibt es noch eine ganze Menge Aktivitäten, die man drum herum machen will und kann und soll. Ja, also dass man im regelmäßigen Austausch ist, wir haben das jetzt bei uns so, dass die sich alle drei Wochen treffen und da wird halt auch ein aktives Training gemacht, die kriegen auch eine interne Zertifizierung. Das heißt, ich habe dann Entwickler mit Security Background irgendwann in der Zukunft, die das dann auch wirklich können und man kann so verschiedene Dinge sich überlegen, wie man sagt, wer hat den coolsten Back gefunden oder so was diesen Monat und dann halt schaut, dass das Thema ja aktiv vorangetrieben wird und nicht liegen bleibt. Aber dieses kleine Wort All Levels, was da vorhin war, das ist ganz wichtig. Man kann das vorschlagen, aber man muss dafür sorgen, dass das auch etabliert wird, dass die Leute auch die Zeit dafür haben. In der Version des Sleidigs 1.0 vom Denise Cruz, der schlägt 20% vor, das ist schon hart, das ist ein Tag pro Woche. Das wird man in vielen Organisationen so nicht hinkriegen, wo die Leute die entsprechende Zeit dafür auch werden können. Wir haben das bei uns ein bisschen reduziert. Aber es ist immerhin da. Die haben Zeit, sich das Wissen anzueignen, in den Project in Code anzuschauen und das entsprechend umzusetzen. Das ist wichtig, um das hinzukriegen. Dann ist die Chance höher, dass am Ende nicht nur eine funktionierende Ladesäule irgendwo in der Landschaft steht, sondern die auch noch sicher ist mit dem Bezahlen und so weiter und mit der Anmeldung, dass das keiner missbrauchen kann. Weil die Leute, die es gebaut haben, auch die Möglichkeit hatten, Security in dieses Konzept einzubauen und umzusetzen. Genau, dann gibt es alle möglichen Dinge außerhalb. Wie gesagt, hier in Karlsruhe haben wir auch den Overs-Stammtisch. Da kann man die Leute mit einladen, dass sie da mal hingehen oder von dort wieder Infos mitbringen. Da hatten wir jetzt nicht in jeder Stadt. Aber dann gibt es verschiedene andere Aktivitäten. Man kann ja auch remote oder online sich in Overs-Sachen einbringen. Genau, das ist jetzt wieder etwas für das Security-Team selber. Das macht aber auch Arbeit, so ein Newsletter zu bauen. Aber es hat auch eine Möglichkeit, die Dinge sichtbar und das zu halten bei Management aber auch in den Teams. Die die Anwendung bauen oder die Produkte und dort zu zeigen, was kommt als Nächstes, was sind die nächsten Schritte, was hat man erreicht, wo muss man noch besser werden, wo es hat, was nicht funktioniert. Security-Konferenzen sind gut und für die Security-Champions ist es auch gut, die dahin zu schicken. Aber ich habe das vorhin schon gesagt, es ist glaube ich auch wichtig, dass die Security-Community auch aus ihrer Blase rausgeht und auf Entwicklerkonferenzen geht und dort Vorträge hält und dort Security-Tracks etabliert, weil das ist glaube ich immer noch ein zusätzlicher Schritt. Wenn die Leute überhaupt schon auf Konferenzen können, je nach Organisation, dann gleich immer auf eine Spezialkonferenz, ist wahrscheinlich schwierig umsetzbar und deswegen denke ich, es ist zwar auch wieder ein Vortrag hier auf, sage ich mal, eine Fachkonferenz, wenn man so will, aber ich mache das in ein paar Tagen. Es gibt auch die Karlsruher Entwicklertage, da ziehe ich auch wieder über die Security-Header, aber als Workshop, das geht dann vier Stunden und so, weil das muss in die Entwickler-Community rein, sonst wird das nicht besser werden. Ich wollte sagen, die haben es mal wieder falsch gemacht oder nicht hingekriegt, aber wir müssen halt auch dabei helfen, dass das besser wird. Genau, aus den ganzen Sachen ist jetzt so eine Art Playbook entstanden, das ist das, was ich gerade erzählt habe, nochmal zusammengefasst auf ein DINna 4 Blatt sozusagen und Overs Maintained inzwischen auch alle Sachen auf GitHub, deswegen ist hier unten auch der GitHub-Link zu dem Playbook, liegt aber auch auf der Overs-Seite selber und da sind die verschiedenen Aktivitäten schön zusammengefasst, kann man irgendwie auf den Tisch legen, sagen hier, lasst uns das mal ausprobieren. Ich sage, wir haben das bei uns auch angefangen zu tun und das ist wichtig, aber ich habe halt auch gelernt, wie wenig Grundlagen vorhanden sind und dass man wirklich viel Wissen vermitteln und aufbauen muss in der Entwicklung, um ein gewisses Basis-Level zu erreichen. Man kriegt dann auch immer mal Antworten, ich habe ja gar keinen Formular auf meiner Seite, es ist kein User-Input und das ist ja okay, weil das ist erstmal eine Perspektive, die muss man zur Kenntnis nehmen und da muss man daran arbeiten, um den Leuten vermitteln, dass da sehr wohl ein Haufen User-Input zurückkommt, mit dem das Backend zum Beispiel arbeitet, das kann man nicht voraussetzen. Genau, also da ist wirklich viel Arbeit dran zu tun, genau. Was setzt der Vorteil von dem Ansatz? Das ist eine Möglichkeit, das ist eigentlich größt und unabhängig von der Organisation, aber das in der Regel, wenn es überhaupt ein dediziertes Sicherheitsteam gibt, also für IT-Sicherheit oder Informationssicherheit, das in die Breite zu tragen, konkrete Anstrengpartner zu etablieren und die Basis hinzukriegen. Ganz natürlich auch schön zu sehen, wenn die Leute dann von sich aus Sachen tun und machen, das kann ich auch bestätigen, aber es ist schon ein anstrengender Weg dahin. Genau, jetzt bin ich mit dem Deck durch und ich glaube bei mir ist jetzt auch nichts weiter drin. Schau nochmal, genau. Ich habe hier nochmal zusammengefasst, ja. Man muss auch in die Entwickler-Community, in die Entwicklungs-Community reingehen und das dort propagieren und aufbauen, wenn es ist, glaube ich schon, zu einem deutlich größeren Teil vorhanden, aber ich habe das selbst hier gestern, habe ich gefragt, wer kennt Observatory von Mozilla, so ein Tool zum Scannen von Seiten zu schauen, wie sind Cookie Security Settings und HTTPS Settings, da waren vier von 80 Händen oben, das ist verdammt wenig und das ist, glaube ich, denkt man, ja, das weiß doch jeder, das stimmt aber nicht und deswegen muss man es vielen Leuten erzählen. Genau, also die eigene Community, ich schreibe viel zu korrigieren, in Organisationen voranbringen, wenn das nicht existiert oder keine anderen Ansätze im Unternehmen oder in der Organisation vorhanden sind, kann man das ja vielleicht mal als Idee einbringen, das auszuprobieren und natürlich gibt es auch für DevOps ähnliche Ideen, das nennt sich dann DevOpssec, kann an einer beliebigen Stelle stehen, aber wenn man nach DevOpssec googelt, findet man, glaube ich, die meisten Informationen dazu, das heißt, wenn man schon DevOps macht, kann man noch ein bisschen mehr machen und dann noch Security mit als integralen Teil dort einbauen. Da gibt es auch ein schönes, sagen wir zumindest freies eBook von Aurelie, da hat das jemand mal auf 80 Seiten auch verschiedene Ansätze von verschiedenen größeren Unternehmen durch Interviews mal zusammengeführt, kann man Google, kann man sich so runterladen, ist ganz spannend, da sind viele gute Ideen drin, kann man auch übernehmen, das hilft auch, neben den Security Champions selber, genau, und genau, nicht gerade, wir müssen es überhaupt erstmal ins Funktionieren bringen, auch wenn es schon 2018 ist, das ist halt immer noch eine große Herausforderung und wichtig, da weiterzukommen. Genau, jetzt Zeit für Fragen. Du hast gerade auch schon das Tooling erwähnt, das ist natürlich wichtig und hier das Obersplug Infusionar, aber wird das nicht auch die Gefahr, dass die Leute dann sagen, okay, so nah als Grün ist alles in Ordnung, ja, deswegen habe ich, ich kann das ja mal kurz aufmachen, das habe ich jetzt nicht im Slide Deck, aber deswegen ist ja das zumindest drin, wo ist es? Sorry, das ist ein Vortrock, Moment. Ja, da kann man alles benutzen. Ich will hier nur mal ein, genau, also warum ist das, das jetzt ein bisschen klein, ein bisschen größer machen, funktioniert das auch? Genau, kann man das lesen, ja, das ist doch super. Also diese Software Assurance-Majority-Modell, das hat diese ganzen Elemente drin, die du vielleicht suchst, das heißt, da sind schon so vier, kann ich mal noch kurz was sagen, wir haben noch ein bisschen Zeit, so vier Hauptaspekte, Governance, Construction, Verification, Deployment, wie gesagt, das ist fokussiert auf die Entwicklung, da hinten fehlt halt jetzt der Betrieb, es wird halt bei Deployment auf und da sind halt diese 12 Bereiche, diese Security Practices und damit muss man sich schon komplett beschäftigen, das macht Arbeit, ja, und das ist nicht nur, also das Tool ist irgendwie dann die eine Box von 12, dann hast du ein 12. fertig, ich finde noch 11, 12. Also und da ist hinter jeder grünen Box sind zwei Ziele und zwei Aktivitäten versteckt im Prinzip, also relativ überschaubar, sehr einfach zu benutzen, also weil es wenig ist, da ist man an einem Tag mit einem Self-Assessment sozusagen durch, um sich mal selber zu raten, wo steht man an den Stellen und wie lange kann man da rüber? Ich scroll mal hier mal kurz durch, da sind unten noch ein paar schöne Charts. Das ist ja alles wunderbar beschrieben und erklärt, es gibt auch einen Excel-Sheet dazu, wo man dann die Aktivitäten bewerten kann, wo man da steht. Also hier sieht man, es hat dann beschrieben, was macht man da, was braucht man für Level 1, 2, 3, das kann da unterschiedlich sein, aber da wollte ich nicht hin. Und dann kann man halt dieses Modell benutzen, wenn man sich mal selber benutzen hat und die Aktivitäten alle angeschaut hat, die da definiert sind, genau. Um dann zu sagen, okay, in welchen der Bereiche stehe ich gerade irgendwo und wo will ich mal hin und dann kann man darüber das Plan und schauen, wie komme ich dann und weiß dann, okay, in einem Jahr bin ich besser, weil ich dann noch ein oder zwei Aktivitäten werde. Da habe ich meine Metriken definiert, dann kann ich die auch messen und dann habe ich da auch hinten Aktivitäten dranstehen, wenn ich die nicht erreiche und so. Genau, das kann man halt für diese ganzen Dinge machen und das ist ein sehr schönes Toolkit, um das zu benutzen. Das wird auch aktiv gepflegt und überarbeitet. Wie gesagt, da gibt es halt noch eine Alternative. Genau, Building Security in Majority Modell, die machen im Prinzip das Gleiche, ist aber ein anderer, das ist jetzt nicht Community getrieben, sondern da stehen halt 15 Unternehmen dahinter, glaube ich. Die Modelle sind aber, gibt es hier auch irgendwo ein schönes Bild, die sind quasi deckungsgleich, die heißen nur ein bisschen anders. Ja, könnt ihr ja selber nachschauen. Da habe ich dann halt oben, die Namen sind ein bisschen anders, aber wenn man das nebeneinanderlegt, dann sieht man, das ist im Prinzip, das sind das komplett die gleichen Ansätze und man hat irgendwie 112 Sachen, die man sich anschaut und dann entscheidet, was man da macht. Mache ich halt nur ein Training oder mache ich auch noch ein Test über das Training. Genau, wo sind sie jetzt? Oh, war eine schöne Bild. Genau, also anschauen, da sind, da ist viel gute Input drin, aber also das muss halt auch irgendwer lesen, verstehen, in die Anwendung bringen. Da hat man ein bisschen Arbeit mit, aber es gibt sehr gute Hilfsmitte. Und ich mach mal noch das Security Red auf. Das ist auch super Security Red. Ist auch ein Oversprojekt inzwischen offizielles. Ja, da gibt es sogar schon Docker Image, kann man einfach runterladen, benutzen. Wie gesagt, kann man sehr leicht an Gira anhängen, hat dann da komplett seine Tickets im Entwicklungsteam, hat ein zentrales Ticket für Security Team. Die können auch gucken, welchen Zustand die related Tickets sind. Super, einfach, sehr schöne Sache. Sollte man sich anschauen, genau das sind die zwei Leute, die sind hier auch im KZ Raum. Und die sind da auch aktiv dran, die nutzen das auch in ihren Unternehmen. Also kann ich nur empfehlen, da mal einen Blick reinzuwerfen. Und da gibt es halt dann hier auch, also einmal das Tool, das ist eine Web-Anwendung einfach. Und dann gibt es halt irgendwo sind die Requirements, genau. Die kann man dann importieren. Ich glaube, mit Docker Container sind die schon drin. Und die basieren halt auf dem ASVS-Standard. Also Application Security Verification Stunner. Das ist quasi ein Tool für Security Tester, wenn sie Anwendungen auf Security testen, auf was dort man achten. Und dann hat man es hier gleich als Anforderung gegen die Entwicklung. Weil wenn die Entwicklung die Dinger nicht als Anforderung hat, was bauen die da? Die bauen zu frei, was die Security angeht. Und dann kann man gezielt ja auch die Dinger einbauen. Und dann gibt es halt, wie gesagt, die Top 10 RIS, die kennt jeder. Dann gibt es noch die Proactive Controls. Da ist nochmal der Fokus auch auf die Entwicklung. Controls, Oversp. Da sind natürlich genau wie in den Top 10 RIS ganz viele der Sheetsheets. Das ist auch ein Oversprojekt, wo dann halt immer drin steht, wie gehe ich mit bestimmten Anforderungen um, wie setze ich das um, auch in allen möglichen Programmiersprachen. Da sind dann immer Codebeispiele. Da habe ich letztes Jahr auch mal einen Vortrag drüber gemacht. Und das wird dann jetzt auch wieder auf die neuen Top 10 RIS angepasst. Ja, da gibt es weitere Fragen, wir haben noch ein bisschen Zeit. Welche Argumente kann man denn gegenüber Führungskräften hervorbringen, um da Ressourcen zu bekommen für Security, für Risk Assessment? Na ja, schlechte Presse? Nein. Kommt natürlich darauf an, in welchem Kontext man unterwegs ist. Aber was ein sehr gutes Argument jetzt ist, ist natürlich der Datenschutz. Wie mache ich Datenschutz? Ein Teil davon ist natürlich neben der Blauen Governance Box. Ich muss die Leute schulen und darüber belehren und so weiter, auch, dass ich die Informationssicherheit hinbekomme. Und vor der EU-Geschichte war der Datenschutz zwar ein schönes Persönlichkeitsrecht, aber der Betroffene musste nachweisen, dass die anderen das falsch gemacht haben. Die Strafen waren vernachlässigbar klein, es hat keinen interessiert. Jetzt ist das ja auch so ein bisschen, ich mache noch ein bisschen Datenschutz, deswegen kann ich direkt darauf antworten, dass wahrscheinlich das größte Zugpfertheit über den Datenschutz, weil das ja jetzt auch ein bisschen Wettbewerbsrecht geworden ist mit den Strafen, weil die orientieren sich ja auch von der Höhe her an nicht Konsortien, sondern an Strafen fürs, jetzt fällt mir das Wort nicht ein, andere Wettbewerbsrechtliche Regelungen, wo es bis 10% geht. Kartelle, genau, jetzt ist mir das Wort Kartell nicht eingefallen. Im Kartellrecht gehen die Strafen halt bis 10% vom Jahresumsatz und im Datenschutz ist man jetzt bis 4% gegangen, aber das ist ja Absicht. Das heißt, wenn ich mitspielt, da erleidet halt einen größeren Nachteil. Und das Wichtige an der neuen EU-Verordnung ist halt, da ist eine Beweislastumkehr. Das heißt, die Unternehmen müssen jetzt nachweisen, dass sie es richtig machen und die Aufsichtsbehörde kann theoretisch oder auch praktisch hingehen und sagen, zeig mal, wie du das machst. Und wenn die dann sagen, ihr macht das aber nicht schön. Also auch wenn es gar keinen Datenschutzvorfall gab, dann kann ich oder kann die Aufsichtsbehörde natürlich Strafen verhängen. Ich meine, diese Summen, die da im Raum stehen, das ist immer die höchste Strafe, aber die können auch ein Audit verhängen oder ein regelmäßigen Audit. Deswegen, der Datenschutz ist wahrscheinlich im Moment das Argument, was am meisten zieht, weil da steht halt ein echter potenzieller Schaden hinten dran und ich muss halt jetzt auf Zufuhr auch nachweisen können, dass ich die Sachen habe. Und dann ist es gut zu sagen, hey, ich habe so einen, ich benutze das Open-Send oder das B-Send-Modell, um das zu managen. Und ich habe hier so ein Konzept, wie ich das in den Entwicklerteams unterbringe. Und weil das muss ich jetzt im Prinzip auch irgendwie zeigen können, dass ich da was Sinnvolles tue, um das hinzukriegen. Ich sage ja, ich mache irgendwas, sondern dass das größte Zug fährt. Und natürlich ist es einfacher, das vorher richtig zu machen, als hinterher zu reparieren, wenn was kaputt geht. Und man hat halt viele Aktivitäten, die man braucht, um das hinzukriegen. Und das ist ja die Frage, machen die Entwicklerteams das schon? Haben die sich das alle selber beigebracht? Es kann ja sein, dass da gute Leute sind, die sowohl super Entwickler sind oder Entwicklerinnen und halt parallel auch die ganze Security noch können neben ihren Spezialgebieten in der Entwicklung. Aber das ist halt relativ unwahrscheinlich. Und hier kann man sagen, das macht nicht ganz so viel Arbeit. Man hat ein paar Leute, die ich zusätzlich trainiere. Und dann habe ich viele, die ein bisschen mehr wissen, als, sage ich mal, die reine Entwicklung. Und die sind dann auch im aktiven Austausch mit dem Security-Team. Da brauche ich nicht so viele Security-Experten, weil die sind selten und teuer und kriege darüber auch die Skalierung hin. Aber ich glaube, das ist schon sehr organisationsspezifisch, dann, wie man da rangehen sollte. Man kann ja auch klein anfangen. Man macht es erst mal in einem Kern-Team. Und wenn das da gut funktioniert, dann geht man vielleicht besonders in einem Team, das sehr präsent ist oder wo ein wichtiges Produkt hinten ist. Keine Ahnung, das muss man dann halt schauen. Ja, gibt es noch Fragen? Ja, dann vielen Dank fürs zahlreiche Erscheinen und Zuhören. Ich hoffe, in Zukunft gibt es in mehr Unternehmen Security-Champions. Ja, dann vielen Dank.