klar denken können, wie die meisten Frauen sind willkommen.
Ja, schönen guten Abend. Auch von mir hier bei
Otto. Mein Name ist Ralf Kleinfeld. Ich bin verantwortlich
für die IT-Security und Netzwerkinfrastruktur innerhalb der IT bei Otto.
Und ich weiß ein bisschen unhöflich, hätte ihn zuerst vorstellen sollen.
Benjamin Fender, der Sicherheitstestmanager bei Otto ist und ja,
das Thema Sicherheit bei der neuen Plattform,
die Johannes eben schon erwähnt hat für Otto,
versucht oder nicht übersucht, sondern das Sicherheit innerhalb des Otto-Shops bereits integriert.
Dieser Shop ist auch im Moment schon erreichbar unter beta.ortto.de und Benjamin
wird da einen kleinen Einblick geben, was wir dort alles tun.
Ja, Dedos war eben schon mal erwähnt worden.
Ich glaube, in der Presse ist das mittlerweile völlig normal,
dass über Angriffe in der IT berichtet wird.
Ich habe ja einfach mal ein paar Beispiele aufgenommen,
was so erkennbar ist, dass sich das mehr und mehr wandelt von
DDoS, ist ja eher so ein Infrastrukturangriff, hin zu Applikationen.
Hier haben wir Facebook mit einer Cross-Site-Scripting-Lücke.
Wird Benjamin gleich auch noch was zu sagen.
Gestern kam PayPal mit einer ähnlichen Lücke um die Ecke.
Das heißt, das Thema begleitet uns mehr oder weniger täglich.
Und ja, wie schützen wir uns davor?
Für gegen Infrastrukturangriffe kann man sich mit System schützen,
die wir auch gleich in der Vorstellung sehen werden.
Aber bei Anwendungen wird es halt
ein bisschen aufwendiger
Und was ganz wichtig ist, dass neben dem,
was man infrastrukturell tut, an Schutzsystem,
dass man ein Bewusstsein erzeugt und eine Sicherheitskultur etabliert.
Das heißt, die Mitarbeiter im Unternehmen und alle Administratoren vor allem müssen natürlich
sich dessen bewusst sein, wie sie Sicherheit in ihren Anwendungen integrieren.
Und um das zu erreichen, ist es wichtig,
dass man das Thema strukturiert angeht und nicht eben nur auf Infrastrukturebene agiert,
sondern gesamtheitlich betrachtet, dass man versucht darzustellen,
In drei größeren Blöcken, das heißt Informationssicherheit strukturiert,
heißt für uns, man muss sich um die Organisation kümmern,
also wie baue ich insgesamt das Thema Security in einer, in einem Unternehmen auf.
Da gehört es dazu eben zu sagen, wer verantwortet welche Bereiche, wer hat welche Zuständigkeiten. Es geht darum,
Standards zu schaffen, Vorgaben zu machen und eine übergreifende Kommunikation,
die meiner Ansicht nach in dem Thema Sicherheit ganz wichtig ist,
zum Beispiel eben über die IT hinaus,
die Versicherung mit einzubinden, die Standardsicherheit, also die,
die nicht klassisch mit IT zu tun hat,
mit reinzunehmen,
um eben wirklich eine ganzheitliche Betrachtung zu haben
Wichtig ist es, eine Klassifikation vorzunehmen,
weil nur wenn ich klassifiziert habe, weiß ich auch,
was ich schützen möchte. Und um das Ganze dann umzusetzen,
brauche ich Prozesse und Maßnahmen, die, wie gesagt,
in der Entwicklung schon ganz wichtig sind, umzusetzen.
Die Prozesse und Maßnahmen sollten eben zum Beispiel
auch zur Prävention genutzt werden und Prävention von was?
Da wird uns Benjamin jetzt erzählen,
wie Otto innerhalb des neuen Shops Prävention zur Sicherheit der E-Commerce-Plattform
Ja, hört man mich, ja. Danke. Prävention von was
will ich ganz kurz darauf eingehen, von was eigentlich?
Nee, das war falsch. Auch nicht. Ich muss
da umklicken. Von was? Zum Beispiel von Oberst
Top Ten. Kennen wahrscheinlich einige von euch schon.
Oberst Top Ten, nickt mal oder schüttelt den Kopf.
Daumen hoch. Also Oberst. Oberst Open Web Application
Security Project. Das ist eine Organisation
Die unregelmäßig die Top 10 Sicherheitslücken in Web-Anwendungen aufstellt und beschreibt.
Und einer von diesen Top 10 Sicherheitslücken sind zum Beispiel auch Injection-Attacken, Injection-Angriffe.
Hier in Form von SQL Injection. Das heißt,
ein Angreifer versucht vorbei an einen Firewalls,
an einen Load-Building-Sting-System, an allen Autorisierungs- oder Authentifizierungssystemen,
versucht von Angreifer die Kundendatenbank abzuziehen.
Hier zum Beispiel irgendwie die Kontonummer und die Bankleitzahl von
so einem User. Das ist ein ganz normales Stück Code
aus einer Web-Applikation
Eine SQL-Abfrage und die nimmt irgendwie einen Parameter aus so einem Web-Formular,
so ein Request-Parameter entgegen und packt ihn so ein SQL-Stream.
Eine Angreifer gibt sich natürlich nicht damit zufrieden,
irgendwie seinen Namen da reinzuschreiben, sondern will da irgendwie SQL-Meter-Zeichen unterbringen.
Unsere Aufgabe ist es eben, sowas zu verhindern,
beispielsweise durch Encoding oder Escaping von solchen Meterzeichen. Anderes Beispiel,
Sessions, Session-ID, die erratbar sind,
das ist jetzt eine ziemlich triviale Session,
die besteht irgendwie nur aus einem Benutzernamen und einem Timestamp,
irgendwie ein Datum, Zeitwert und so ein Angreifer kann relativ wenig Aufwand,
so eine Benutzer-Session erraten.
Er braucht dazu nur den Benutzernamen und probiert einfach mal alle Sekunden durch.
Wenn man weiß, dass so eine Session über ein,
zwei Stunden geht, wenn das irgendwie 7000 Requests,
die so einen Angreifer durchführen muss.
Anderes Beispiel. Schlechter Zugriffsschutz. Ich glaube,
sowas kennt auch jeder irgendwie. Es gibt eine interne oder
eine Atmin-URL und irgendjemand hat da so einen Gruppenaccount angelegt,
mit relativ schwachen Passwort.
Ist natürlich nicht so gut.
Was tut man dagegen
Keine Gruppenaccounts, personalisierte Accounts, starke Passwörter. Passwörter,
die rotieren, die eben nicht fünf Jahre gültig sind.
Logging, Logging von Zugriffsversuchen, von Zugriffen. Das sind so Beispiele,
was wir versuchen zu verhindern mit unseren Maßnahmen und wie verhindern wir das?
Ralf hat es eben schon erwähnt, durch standen da als Vorgaben,
konkret in unserem Webprojekt machen wir das durch Vorgaben,
wir nennen die Sicherheitsrichtlinien. Und zwar ist es da wichtig,
dass diese Sicherheitsrichtlinien nicht durch irgendein so ein Experten-Team vom Elfenbeinturm
ausgearbeitet werden in ihrem stillen Kämmerlein und dann in das Team gekippt werden,
sondern es ist wichtig, dass man das mit dem Team zusammen erarbeitet,
dass man das im Dialog erarbeitet, dass man erklärt und transparent macht,
wozu haben wir überhaupt diese Richtlinien?
Was sichern die ab? Und Best Practices aufzeigt,
wie kann man solche Richtlinien umsetzen? Wie kann man seine
Applikation absichern? Ich gebe mal ein paar Beispiele dazu,
Sicherheitsrichtlinien, zum Beispiel Session-IDs müssen in Cookies übertragen werden.
Wieso nicht in der URL, eine Session-ID kann ja
auch in der URL übertragen oder in einem Hiddenfield von so
einem Formular
URLs haben allerdings die Angewohnheit oder User und die Angewohnheit,
URLs als Links zu verschicken oder irgendwo zu verlinken, inklusive ihrer Session-IG.
Gucke ich es einmal auf den Vorteil, man kann Parameter bei Cookies
setzen, dass die nicht mehr über JavaScript abrufbar sind.
Stichwort XSS, das ist eine XSS-Injection oder eine JavaScript-Injection, die User-Cookies abzieht.
Anderes Beispiel. So eine Session muss irgendwie mal ablaufen,
nach einer oder zwei Stunden,
dass so ein Angreifer eben nicht unendlich Zeit hat,
so eine Session zu erraten.
Na gut, die Session von eben,
die kann man ja von einer Minute erraten.
Aber es gibt ja
auch kompliziertere Session-IDs
Ein anderes schönes Beispiel. Aktuell auf Platz 9 von den Oberst
Top Ten. Wir setzen ganz viele Frameworks und Bibliotheken,
das Meister von Open Source, in unserem Programmcode ein.
Die wäre natürlich auch irgendwann, treten Sicherheitslücken auf.
Die werden meistens ganz schnell gefixt. Wir müssen allerdings auch,
wenn die gefixt werden, die richtige und aktuelle Version einsetzen.
Wenn wir alte Versionen einsetzen mit bestehenden Sicherheitslücken,
nützt das niemanden, zumindest uns nicht, außerdem Angreifer vielleicht.
Eine andere Maßnahme zur Prävention von Sicherheitsvorfällen,
um unsere Applikation sicherer zu machen
Ist die sichere Entwicklung. Vielleicht sogar das Wichtigste.
Damit meine ich nicht nur irgendwie Befolgen von Best Practices,
von Coding Conventions, von welcher Programmiersprache auch immer.
Damit meine ich auch nicht guten Quellcode, gut kommentierten Quellcode,
gut definierte Schnittstellen oder den Ansatz von entsprechenden Frameworks, Spring Security oder Overspezapi.
Damit meine ich auch sowas wie Logging. Wir müssen loggen,
besonders sicherheitskritische Aufrufe, um eben Um eben Angriffsversuche zu erkennen,
vielleicht mit einem nachgelagerten Monitoring-Tool,
um forensische Analysen machen zu können, wenn irgendwas schiefgelaufen ist,
damit wir wissen, was schiefgelaufen ist,
ob vielleicht Daten abgeflossen sind an irgendeinen Angreifer.
Und vielleicht zu erkennen, wer das war. Um auch interne Angreifer abzuschrecken,
wenn ich als interne Angreifer weiß, mein Versuch,
die Datenbank jetzt abzuziehen, Userdatenbank abzuziehen,
wird von vier verschiedenen Systemen gelockt, dann überlege ich mir das vielleicht nochmal.
Aber auch ein hoher automatisierter Testgrad, nicht so funktional,
funktionale Tests,
sondern auch Sicherheitstests
Form von Test der Maßnahmen,
die die Sicherheitsrichtlinien umsetzen oder automatisierte Tests, Initration-Tests,
die nicht nur einmal ausgeführt werden,
sondern im Rahmen von so einem Continuous Integration,
die mehrmals oft ausgeführt werden, bei jedem Check-in,
bei jedem Code-Ad-Check-in von einem Entwickler, werden die Tests ausgeführt.
Die Sicherheitstests und wenn irgendetwas schief geht, dann gibt es gleich
eine Mail, entweder ein Entwickler oder an das Team.
Ich weiß nicht, gibt es an das Team eine E-Mail von euch?
Wenn Tests fehlschlägt, Vielleicht wäre es eine gute Motivation.
Eine andere, eine andere gute Motivation. Auch um das,
um das Sicherheitsbewusstsein zu stärken, sind Trainings.
Wir führen das in Form von einem Tagestrainings durch,
speziell Sicherheitstrainings, wo speziell auf Webanwendung Sicherheitslücken drauf eingegangen wird,
was es so gibt, wie man die ausnutzen kann.
Und vor allen Dingen, was man dagegen tun kann
So ein Ein-Tagestraining ist gut, aber das muss wiederholt werden.
Trainings müssen wiederholt werden, sonst bleibt das nicht hängen.
Deswegen, naja, geplant zumindest, E-Learning-Module, dass E-Learning-Module
wiederholt eingesetzt werden, um eben das gelernte Wissen zu festigen.
Teams treffen sich zu Hacking-Sessions. Vergreifen Sie Webapplikationen an als Training,
jetzt nicht unbedingt die Konkurrenten, Amazon oder Zalando,
sondern es gibt spezielle Selbapplikationen, die extra dafür gebaut wurden,
irgendwie Obers, Obers, wie nennt sich das,
Webcode oder Google Greyer, Das ist so eine Art Käse, also Käse.
Löchriger Käse. Das tun wir noch. Wir haben Sicherheits-Champions in
den Teams. Das ist ein Entwickler oder ein Tester oder ein Betriebler.
Jemand, der sich für das Thema Sicherheit interessiert,
der das Thema Sicherheit in das Team mit reinträgt.
Der Ansprechpartner für das Team ist und eben nicht nur in der Stabsstelle,
nicht nur die Sicherheitsexperten, die irgendwo sitzen,
sondern wirklich Sicherheit in das Team reintreiben.
Und wir führen Risiko und Bedrohungsanalysen durch.
Das klingt jetzt so
ein bisschen akademisch
Da versuchen wir, die Bedrohung der Webapplikationen, der Systeme herauszufinden.
Was würde ein Hacker tun, ein Angreifer tun?
Wo würde der angreifen? Was hätte das für Auswirkungen?
Auch das machen wir nicht nur mit den Sicherheitsexperten,
sondern das machen wir mit den Teams zusammen,
mit den Entwicklern, mit den Testern, dass das Kernteam,
das ganz tief drinsteckt im Code und in ihrem System.
Die wissen am besten, wo ist ihr System angreifbar?
Was ist am kritischsten? Wo sind vielleicht die langlaufenden Operationen
? Wo findet vielleicht noch keine Validierung von irgendwelchen Eingabedaten ab
statt?
Stichwort Injection
Mit den Teams zusammen finden wir Bedrohungen raus, kategorisieren,
die priorisieren die und erarbeiten Maßnahmen daraus und setzen die dann um.
Das Ganze natürlich mit Unterstützung der Experten. Mit den ganzen Maßnahmen
und mit der Stärkung des Sicherheitsbewusstseins schaffen wir sowas wie eine Sicherheitskulturbauauto.
Also weg von dem Sicherheit gehört auch mit dazu,
sondern eher hin zu Sicherheit ist ein Teil von Auto,
ein Teil von mir.
In einer immer immer komplexer werden, in Wellen wird immer komplexer werden,
in Systemen, in komplexer werdenden Bedrohungsszenarien, Angriffsszenarien.
Müssen wir eben nicht irgendwann sagen, müssen wir uns irgendwie
dazu kaufen? Verteidigung dagegen, sondern können sagen,
wir begegnen denen direkt in der Applikation direkt auf unserer Ebene.
Ja, Ralf, hast du sonst noch was dazu hinzuzufügen?
Nee, dann bedanke ich mich