Application Security Monitoring: Das, wofür es in Firmen angeblich kein Budget gibt

Ebenso wie die letzten fünf bis zehn Jahre, die Sie in die Produktentwicklung gesteckt haben. Das Entwickler-Team hat die letzten Monate regelrecht Blut und Wasser geschwitzt und bis zuletzt unzählige Überstunden investiert, um das Unmögliche möglich zu machen. Es kommt die ungute Stimmung auf, ob vielleicht am falschen Ort gespart wurde.

Viele Unternehmen sind sich der wichtigen Rolle der IT Security schon bewusst. Wir haben nachgefragt und gleich zwei Probleme wurden von großen wie kleinen Unternehmen in diesem Zusammenhang genannt. Es mangelt grundsätzlich an der Zeit (um über IT Security nachzudenken). Und natürlich würde es gleichermaßen am Geld fehlen (um entsprechende Maßnahmen umzusetzen). Zugegebener Maßen macht es bestimmt mehr Spaß, die Sicherheitsfeatures eines neuen Dienstwagens auszuwählen, statt eine Securiy-Policy in der IT-Abteilung zu etablieren. Das Problem scheint weniger Geld oder Zeit zu sein, sondern liegt der Hund andernorts begraben. Ein möglicher Return-of-Investment (ROI) ist nicht direkt messbar, zu viele Faktoren spielen hier eine Rolle. Das macht das Thema IT-Security nicht nur auf der Agenda eines Buget-Meetings unbeliebt sondern erschwert insbesondere weniger Security-affinen Unternehmen den ersten wichtigen Schritt zu wagen.

Es vergeht kaum ein Tag, an dem die Medien nicht über eine weitere DDoS (Denial of Service) Attacke oder Datenveruntreuung berichten. Es wirkt fast so, als ob Unternehmen sich nicht um die Sichherheit ihrer Produkte und Kunden kümmern würden. Doch ist das wirklich so? Mit den nötigen finanziellen Mitteln kann man heutzutage vermutlich jedes Firmennetzwerk hacken lassen und das ist noch nicht einmal das Schlimmste, was einem Unternehmen am globalen Markt passieren kann…

Alexander Chvojka, Geschäftsführer bei ITdesign, und sein Team ist kürzlich mit der SEC Consult zusammengesessen, um über seine Standpunkte zu präventiven Maßnahmen in der IT-Security und Entwicklung neuer Produkte in einer vernetzten Welt zu sprechen. Aus eigener leidvoller Erfahrung gewährt er erstmals einen Einblick, wie stark sich sein Entwicklungsprozess in den letzten Monaten verändert hat und was er heute anders machen würde.

Wenn dir keine Lösung mehr einfällt, wird es Zeit für einen Neuanfang.

“Das Ergebnis der ersten Analyse des bestehenden Produktes war ein Faustschlag ins Gesicht”, erinnert sich Lukas Boldrino, Projektleiter und Scrum Master bei ITdesign, “die zugrundeliegende Softwarearchitektur und externe Libraries waren derart veraltet und unsicher, dass es tatsächlich einfacher war, noch einmal von vorne anzufangen…”.

Besonders für nicht-funktionelle Requirements sind Sicherheits-Audits eine sehr nervige Angelegenheit. Denn selbst dann, wenn alles nach Plan verläuft und nur Kleinigkeiten ausgebessert werden müssen, geht jeder Test mit einem unglaublichen Aufwand einher. Vor dem eigentlichen Test (durchschnittlich 5 Tage) müssen zunächst Angebote eingeholt und verglichen werden, anschließend der Test vorbereitet und die Ergebnisse ausgewertet und umgesetzt werden. In dieser Zeit verbrennen Sie effektiv Geld, weil Ihr Team nicht an der Produktentwicklung arbeiten kann, sondern regelrecht stillsteht. Und das bei jedem größeren Meilenstein!

Nun verläuft in der Software-Entwicklung nicht immer alles nach Plan. In der Regel ist eine kleine Verzögerung von ein paar Wochen ganz normal und fast lächerlich, wenn man es mit der Projektlaufzeit von 3 oder mehr Jahren vergleicht. Nur 1-2 Monate nach dem ursprünglichen Plan fertig zu werden ist in der Welt eines Programmierteams eigentlich sogar richtig gut. Marketing, Sales und die Geschäftsführung könnte dies freilich anders sehen, denn der globale Marktplatz für Softwareprodukte ist hart umkämpft. Eine längere Entwicklungszeit kann nicht nur finanziell zur Herausforderung werden, sondern auch bedeuten, dass die Konkurrenz schneller auf den Markt kommt oder das eigene Produkt bei Markteintritt vielleicht gar nicht mehr am letzten Stand der Technik ist.

Selbstverständlich gibt es dann noch Plan B: Hoffen hoch Drei. Hoffen, dass die verwendeten Bibliotheken selbst schon sicher genug sind. Hoffen, dass die eigenen Entwickler an alles gedacht haben. Hoffen, dass nichts passiert. Wenn Sie einen Blick in die letzten Veröffentlichungen des SEC Consult Vulnerabiltiy Labs werfen, wird schnell klar, dass Plan B keine Option sein sollte. Viel zu offensichtlich bewahrheitet sich das Gesetz von Murphy viel zu oft, wenn es um IT-Sicherheit geht.

Boldrino befand sich mit seinem Projekt in einer prekären Lage und entschloss sich, die Notbremse zu ziehen. Er entschied sich für einen zweiten Wurf. Diesmal sollte sich das Team jedoch ab dem ersten Tag (mit der Unterstützung von Experten) der Applikationssicherheit widmen. Diesmal sollte es keine Überraschungen mehr geben.

Was haben Sie beim zweiten Mal anders gemacht? Worin genau bestand der “Neuanfang”?

Boldrino: Um nicht bei Null anfangen zu müssen, haben wir uns das Team der SEC Consult als externe Berater ins Boot geholt. Der erste Schritt war noch recht einfach, es sind alle veralteten Bibliotheken und Strukturen rausgeflogen. Dann kam die Knochenarbeit, nämlich das Definieren von Sicherheitsanforderungen für alle betroffenen Software- und Betriebssystemkomponenten. Wir waren hier sehr streng, haben eigentlich eine ganz neue Architektur entworfen und dabei auch gleich unseren internen Entwicklungsprozess komplett umgekrempelt.

Wie hat das Team darauf reagiert?

Boldrino: Ja, das war nicht ganz einfach. Es brauchte natürlich die Unterstützung und den Willen aller Beteiligten. Und jede Menge Kommunikation. Früher hatten die Teams für Frontend und Backend wenig Kontakt miteinander, wie man es in der Software-Entwicklung eben so kennt. Aber genau das hat uns das Genick gebrochen. Wir mussten unsere Arbeitsweise also nicht nur auf Prozess-Ebene verändern, sondern auch beide Teams von Anfang an in den Prozess einbinden. Somit saßen dann also alle Entwickler in den Sprint-Meetings, und bestimmte Probleme, die vielleicht erst ganz zum Schluss aufgetaucht wären, konnten wir schon frühzeitig erkennen und vermeiden.

Welche Aufgabe hatte das Team der SEC Consult im Entwicklungsprozess?

Boldrino: SEC Consult kümmerte sich um Sicherheit auf technischer Ebene, während wir die Datenschutzmechanismen auf logischer Ebene intern umgesetzt haben. Wir konnten durch geplante Security Gates vor jedem Release sehr viel wertvolle Zeit gewinnen, und gleichzeitig fiel der zusätzliche Aufwand und Stress für die Audits einfach weg. Das ganze Projekt war sowohl finanziell als auch terminlich besser planbar. Kostenklarheit und Termintreue sind eine unschlagbare Kombination und ganz klarer Marktvorteil in unserer Branche.

Das klingt perfekt. Aber IT-Spezialisten auf einem Niveau der SEC Consult kosten bestimmt auch eine Stange Geld. Das fällt finanziell bestimmt aus dem Rahmen?

Boldrino (lacht): Ja, das würde man meinen, aber die Zahlen schauen ganz anders aus. Die Kosten für das Application Security Monitoring der SEC Consult waren wirklich überschaubar, vielleicht 10% vom Gesamtbudget? Schlimm wären hingegen die Folgen, das Release-Datum verschieben zu müssen. Selbst ein kleiner Security Fail kann schnell einmal 1 Monat mehr Entwicklungszeit kosten und dann hat sich die Investition bereits amortisiert. Und das sind gerade einmal 2 Sprints auf eine Projektlaufzeit von 1-2 Jahren, das ist gar nichts. Ein Programmierer zuckt bei vier Wochen Planabweichung noch nicht einmal mit der Wimper. Umgekehrt wird der ganze Prozess transparenter, eben durch automatisierte Tests während der Entwicklung. Zusätzliche Kosten für unerwarteten Mehraufwand, wie zum Beispiel Gehälter der Mitarbeiter, können einen nicht mehr aus der Bahn werfen, weil einfach alles auf Schiene läuft und laufend getestet wird. Insofern ist  Application Security Monitoring nicht nur leistbar sondern hilft sogar dabei Stress und Kosten zu minimieren.