Teufelskreis Entwicklung: Warum Software nicht sicher ist

So verwundert es kaum, dass die Zahl sicherheitskritischer Programmfehler weiter zunimmt. Mit der Veröffentlichung von „Zero-Day„-Bugs nehmen von finanziellen Motiven angetriebene Angreifer die Hersteller weiter in den Schwitzkasten. „Während noch diskutiert wird, ob die Veröffentlichung eines sicherheitskritischen Bugs ohne Vorabinformationen des Herstellers und ohne Anstandsfrist vertretbar ist, zwingen einige Cracker die Hersteller in einen Wettlauf mit den Entwicklern von Exploit-Code“, gibt Dirk Fox, Geschäftsführer von Secorvo Security Consulting, zu bedenken.

Auch der deutsche Softwarekonzern SAP hat seine Lektionen gelernt. Immerhin stünden durch unzureichendes Produkt-Engineering die Vermögenswerte der Kunden in Milliardenhöhe auf dem Spiel. „Alle Schwachstellen nur aufzulisten bringt kaum weiter, da es auf eine kontextabhängige Betrachtung ankommt“, sagte Gunter Bitz, Sicherheitsexperte Corporate Security bei SAP auf der diesjährigen RSA Conference. Auch die vom Konzern selbst entwickelte ERP-Software sei keineswegs bugfrei, so die ernüchternde Bilanz. SAP versucht größeren Schäden vorzubeugen, indem es die jeweiligen Kundenanforderungen frühzeitig in die Entwicklung der Funktionalitäten einbezieht.

Standards sind eine Lösung, aber auch das Problem

Einen hundertprozentigen Schutz garantiert aber auch das intensive Zuhören beim Kunden nicht. Hinzu kommt, dass sich IT-Sicherheit und Softwareentwicklung ohnehin konträr statt komplementär verhalten. Die Software muss Funktionen bereitstellen und dabei definierte Sicherheitsziele beachten. „Die Möglichkeiten und der Aufwand zur Umsetzung dieser Sicherheitsziele differieren natürlich durch das konkrete Szenario“ sagt Christoph Meinel. „Entwickle ich einfache Desktop-Software oder aber Webanwendungen, die von Millionen von Anwendern weltweit genutzt werden? Das ist schon ein Unterschied.“

Durch gute Sicherheitsstandards kann man typische Sicherheitsprobleme zwar quasi wegstandardisieren, und je weiter die Standardisierung nach oben voranschreitet, desto mehr Verbesserungen sind theoretisch möglich. Auf der anderen Seite müsste es den Entwicklern viel leichter gemacht werden, diese Standards dann auch richtig anzuwenden.

Und dieses Prinzip der einfachen Handhabung von Security-Funktionalitäten ist immer noch eine weit entfernte Zielscheibe. „Eine Entwicklungsabteilung, die jeden Patch für heterogene Umgebungen testen muss, bevor sie ihn ausrollen kann, hat gegen Tausende vom Ehrgeiz getriebene Cracker keine faire Chance, auch wenn die Hersteller die zur Patchentwicklung benötigte Zeit halbieren könnten“, so Dirk Fox.