hasematzel.de

In den Zeiten allerortens entstehender Portale, die ihren Schwerpunkt auf dem sogenannten user generated content haben, die zwangsweise mit Benutzerdaten jonglieren müssen, wie mit brennenden Bällen, scheint das Thema Sicherheit ein in der Planung oftmals vernachlässigtes zu sein. Immer mehr Menschen – nicht nur die Portalseigner und -entwickler scheinen scharf auf Datenerfassung zu sein. Für die Funktion von Webseiten und Applikationen, die unter dem grossartigen Nicht-Wort Web 2.0 zusammengefasst werden können, ist die Erhebung von Benutzerdaten von der E-Mail bis hin zu Zahlungsinformationen unabdingbar. Dennoch erscheint es mir oft, dass unter dem Zugzwang des frühen Releases (“wir waren die Ersten, nicht die Besten, aber die Ersten”) und des für mich sehr fragwürdigen Konzeptes release early, release often, der Standard eines Sicherheits-Qualitätslevel immer mehr unter nice to have in der Planung Berücksichtigung findet.Dabei schützt auch der beliebte Stempel Beta nicht vor der Erwartungshaltung der Benutzer, die von einer öffentlich zugänglichen Applikation die Einhaltung gewisser Grundsätze bezüglich Sicherheit und Verschwiegenheit einfordern, auch wenn Sie nicht die Allgemeinen Geschäftsbedingungen gelesen haben – was allgemein als Fehler gilt. Nicht falsch verstehen: Dieser Artikel ist keine neue Art von shoppero-bashing oder -rant, das ist eher eine ganzheitlichere Herangehensweise an das Thema.

Einfach mal den Profi fragen

Da die Anzahl der auf Communities basierenden Applikationen sicherlich nicht abnehmen wird, ist für die Projektplanung der Abschnitt der security-certification ein äusserst wichtiger Bestandteil, um nicht nach verfrühtem Release (aus welchen Gründen auch immer) in Argumentationszwang zu kommen. Ein Zwang, der in der Blogosphäre kaum unbeachtet bleiben wird. Gerade Firmen, die sich über E-Business oder E-Services identifizieren, geraten so schnell ins Rudern und haben Schwierigkeiten, neben dem ganzen Präventions-Marketing noch vernünftig und sinnhaft zu entwickeln. In diesen Situationen will ich nicht in das Änderungslog des Subversion-Repositories schauen müssen, geschweige denn die Qualität der Änderungen beurteilen.Der unausgesprochene Satz “was der Benutzer nicht weiss, macht ihn nicht heiss” ist in Zeiten des Internets als Kommunikationsmedium obsolet geworden. Sicherheitslücken werden schneller bekannt als die Farbe von Paris Hiltons(bitte den Namen eines beliebigen, weiblichen Klatschpresse-Stars einfügen) Unterwäsche auf der Oskarverleihung (scnr). Der vielzitierte PR-Gau wartet und lauert nur auf seinen grossen Auftritt auf der Blog-Bühne. Die Sicherheit eines Portals selbst ist dabei äußerst komplex, oft so komplex, dass die durchschnittlich geschulten Entwickler in der Fülle der Anforderungen eventuell mit einem Sicherheits-Qualitätsstandard überfordert sein mögen (Achtung: Keine Wertung hier!). Derartige Aufgaben benötigen Profis, source code testing, stress tests, gezielte Suche nach Exploits, mit Werkzeugen, die dafür vorgesehen sind.Die Marktlücke ist längst erkannt, jetzt ergeben sich auch die ersten Business-Ansätze daraus (ich beziehe mich auf Business-Ansätze, mit denen ich auch etwas anfangen kann und nicht auf den Passus “Test, Abnahme und Dokumentation”, der sich pro forma in den Projektangeboten vieler Dienstleister finden lässt). Björn (der Mann mit den mir bekanntlich meisten XING-Kontakten ;) berichtet vom Startup der Kooperationsfirma SektionEins die mit der Mayflower GmbH und Stefan Esser ein Expertenteam liefert, das sich auf Sicherheit in Webapplikationen, -seiten und -portalen spezialisiert hat. Ich bin mir sicher, dass das Angebotspaket für die 1-day-security-factory für in die Beta gehende, aufstrebende Web2.0 – Geschäftsideen zum Pauschalpreis nicht lange auf sich warten lässt :)Ich wünsche Björn und allen Beteiligten viel Glück mit der (für mich pflückreifen) Frucht :-) Mehr Infos gibt’s auf der Webseite SektionEins.de.

Sicherheit als ROI

Zum Abschluss eine kleine Rechnung (die am Ende leider gar keine ist): Ein Sicherheitstest mit Experten ist ein zu kalkulierender Faktor in der Release-Phase eines Software-Projektes. Ganz im Gegensatz zum PR-Gau, dessen Aufkommen ein sprachlich hervorragend talentiertes Team benötigt (im Support, im Marketing), damit das Produkt nicht in der Luft zerrissen wird und die Wogen der Empörung geglättet werden.Ich schätze einfach mal, dass man mit ca. 2 Experten vor Ort an einem Tag einen qualitativ recht guten Test hinbekommt (man möge mich gerne berichtigen, ich weiss, dass die Skala nach oben offen ist). Daraus erfolgt dann vielleicht nochmal ein 2-3 Tage dauerndes Überarbeiten, auf jeden Fall aber ein Patch-Katalog für weitere Releases. Planbar, kalkulierbar, transparent.Der PR-Gau kann hier nicht beziffert werden, man weiss aber anhand von Beispielen in der Vergangenheit, dass die Auswirkungen erheblich sein können, bis hin zu geschäftsschädigen Ausmaßen, je nachdem, wie sicherheitsrelevant die Applikation ist (das Online-Buchungssystem eines Händlers ist hier sicher mehr in der Aufmerksamkeit, als ein social bookmarking-Tool). Nur “der Erste” mit einem Produkt auf dem Markt zu sein, bedeutet nicht, vor Kritik und Beschwerden gefeit zu sein, insbesondere, wenn man in kurzer Zeit nicht oder kaum reagieren kann.Ich behaupte, dass kalkulierbarer Sicherheitstest und PR-Gau in Zahlen ausgedrückt nicht im Verhältnis zueinander stehen – mit einem bedeutenden Ungleichgewicht in Richtung des PR-Gaus. Ich kann mir vorstellen, dass es unter Umständen schwer sein kann, ein Sicherheits-Review einzuplanen oder zu fordern. Dabei schätze ich, dass vor allem die Shareholder hier ein einschränkender Faktor sind – nicht böse gemeint – auf Shareholder-Ebene gelten meist andere Wertigkeiten, bzw. werden Wertigkeiten anders priorisiert. Die Aufgabe des Projektteams und unweigerlich des Projektleiters ist dann die Visualisierung von Zahlen, um eine gute Entscheidungsbasis zu formulieren. Wie beziffert man also einen PR-Gau? Ab in die Kommentare. Jetzt!