Cologne Intelligence bei der // heise devSec()

Unser CI-Team berichtet vom Besuch der // heise devSec() 2019 in Heidelberg.

Es ist ein grauer Morgen in Heidelberg, als das fünfköpfige CI-Team am ersten Tag der // heise devSec() zu den Workshops bei der Print Media Academy eintrifft. Da einer der vier Workshops kurzfristig ausgefallen ist, müssen sich die Teilnehmer auf die anderen drei Workshops verteilen.

1. Webapplication Security Crash-Kurs: Für unsere Entwicklerin war das „Highlight der Konferenz“.  Durch den Capture The Flag (CTF) artig aufgebauten, „sehr lehrreichen“, Workshop hatten die Teilnehmer nicht nur sehr viel Spaß, sondern auch die Einsicht in die Denkweise eines Angreifers. Diese Erfahrung macht es Entwicklern einfacher, bei zukünftigen Projekten Sicherheitsaspekte von Anfang an zu berücksichtigen und es steigert die Kreativität bei der Durchführung von Thread Modelings im Entwicklungsteam.
2. Java Security Sins: Die Erwartung, dass generelle Schwächen der JVM im Detail erläutert würden, wurde für unsere beiden Kollegen, die am Workshop teilnahmen, voll erfüllt. In besonderer Erinnerung geblieben ist die Ausnutzung einer Deserialisierungsschwachstelle über mehrere Bibliotheken hinweg. Beispiele zur Ausnutzung einer Deserialisierungsschwachstelle gibt es viele. In den meisten Fällen wird die verwundbare Bibliothek aber direkt angesprochen. Der besondere Aspekt im Workshop war die Ausnutzung einer Schwachstelle in einer transitiven Abhängigkeit des Applicationservers über das Netzwerk. Die kontinuierliche Prüfung der eingesetzten Open Source Bibliotheken auf bekannte Schwachstellen kann solchen Angriffen vorbeugen.
3. Kryptografie sicher nutzen: Als Kryptograph hatte ich mich auf diesen Workshop gefreut, weil ich erwartet hatte, hier eine gewisse Methodik für die Kryptographie-Nutzung in der Praxis zu lernen. Die vermittelten Inhalte gingen allerdings kaum über Grundlagen hinaus und das im Rahmen des Workshops vorgestellte Tool CogniCrypt zeigt zwar interessante Ansätze, schwächelt aber in der Umsetzung. Fehler, die den Einsatz des Tools bei einigen Teilnehmern unmöglich machten, sowie die Tatsache, dass das Eclipse Plugin den Einsatz von Java 8 für die IDE voraussetzt, machten die Nutzung nicht einfacher. In Summe hätte man in einem siebenstündigen Workshop tiefer gehen können und müssen.

Die eigentliche Konferenz ging am Tag nach den Workshops mit der spannenden KeyNote: „Informationssicherheitsrisiken von vernetzten Fahrzeugen“, los.  Fazit: Ungewöhnlich tiefe Einblicke in eine ansonsten sehr verschlossene Industrie. Um den Redner zu zitieren: „Ich habe mal alle Logos der Hersteller weggemacht, sonst rennen die uns die Bude mit ihren Anwälten ein“.
Die anschließende Kaffeepause wurde für eine kurze Begrüßung unserer Kollegen von n-design genutzt. Mit n-design verbindet uns eine langjährige Firmenfreundschaft.

Interessant ist die // heise devSec() vor allem auch aufgrund ihrer Bandbreite. Von prozessgetriebenen Themen über sehr entwicklungsnahe Themen, von Vorgehensmodellen zum Absichern der eigenen Anwendung bis hin zu Einblicken, wie Schutzmechanismen zu überwinden sind.

Kim Hartmann empfiehlt in ihrem Vortrag, einen Security Champion (in Ihren Worten: einen Security Manager) ins Entwicklungsteam zu integrieren. Denn Sicherheit muss während des Entwicklungsprozesses kontinuierlich berücksichtigt werden und nicht als „Security Sandwich“ vor und nach der Entwicklung angesetzt werden. Damit spricht sie genau das an, was wir durch unseren Security Champion anbieten.

Generell konnte man in allen Vorträgen die Betonung für die Sensibilisierung der Entwickler in Sachen Sicherheit aber auch die Notwendigkeit eines Security Experten in einem Entwicklerteam erkennen. Das bestätigt uns darin, dass CI mit ihrem Webapplication Security-Angebot die richtige Richtung eingeschlagen hat.

Ganz anders wurde das aber am Tag 3 mit der Keynote: „Developers are not the Enemy! – On usability issues for secure software development“ dargestellt.  Der Redner von der Uni-Bonn stellte seine Studie vor, in der man „herausgefunden“ habe, dass „Softwareentwickler, die keine Ahnung von Sicherheit haben, auch keine sichere Software programmieren können“  - wie Bruce Schneier die Studie so schön zusammenfasst. Die Forschung des Redners ging in die Richtung, dass man mehr und mehr automatisieren solle, um den Entwicklern die „Last“ der Sicherheit abzunehmen. Aus unserer Sicht ist dies der falsche Ansatz und der falsche Weg.

Wir meinen: Um IT Security effektiv umzusetzen, braucht es fokussierte Spezialisten. Es braucht konkrete Anforderungen und Vorgehensweisen, Technologien und Konzepte. Diese Sichtweise ist spürbar auf dem Vormarsch: Strukturierte Herangehensweisen an konzeptionelle IT-Security und Security-by-Design, wie von CI als Beratungsleistung angeboten, erfreuen sich zunehmender Verbreitung. Die Frameworks werden besser und bieten starke Sicherheitsmaßnahmen, trotzdem werden sie oftmals nicht oder nicht korrekt verwendet. Security out-of-the-box gibt es weiterhin nicht.

Diese Meinung hatten glücklicher Weise auch andere Teilnehmer der Konferenz, wie wir in der Kaffeepause nach dem Vortrag erfahren durften.

Ebenfalls eine sehr positive Erfahrung ist, dass auch auf einer Security-Konferenz in Heidelberg der regionale Fokus gewahrt bleibt. Dank unserer eigens für die Konferenz gedruckten T-Shirts hatten wir viele Gespräche, die mit: „Ach, ihr kommt auch aus Köln?“ begonnen haben. Netter Nebeneffekt: Die Kollegen waren in der Masse leichter wiederzufinden.