Risiko Netzwerk: Teil 5 – Exploits und Programmierung

Der letzte Teil der kurzen “Risiko Netzwerk”-Reihe befasst sich eher mit der software-seitigen Gefährdung und der Gefahr, die sich aus einer Mischung aus Unachtsamkeit, Unwissen und Naivität zusammensetzt: Softwareengineering und Exploits.
Anwendungen und Systeme wachsen stets und werden von Tag zu Tag, von Version zu Version und Release zu Release umfangreicher. Es werden stetig Code-Zeilen ergänzt, Module und Funktionen erweitert und der Funktionsumfang PR-wirksam ergänzt. Hierbei ist manchmal die Qualitäts- und Sicherheitsprüfung nur teilweise erfolgt, das Produkt muss schleunigst auf den Markt (teils, bevor es eigentlich frei von Fehlern ist, bekannt unter der Beta-Tester-Methodik). 
Für dieses rasante, Modul- und Funktionen-erweiternde Wachstum ist der Software-Gigant SAP das beste Beispiel. Hat man in der grundsätzlichen Software mit User-GUI und dem Backend bereits von Haus aus etliche Funktionen, werden diese zumeist bei Implementierungen in Unternehmens-Umgebungen erneut angepasst, auf die Geschäftsprozesse maßgeschneidert, um  ja jeden Prozess korrekt abbilden zu können. Dass das eventuell über andere Tools oder Medien erheblich einfacher gehen kann, wird da oft außer Acht gelassen – man will ja einen Single-Point-of-Management erlangen. Alles Prozessgesteuerte muss also irgendwie via ABAP in die SAP-Logik eingefrickelt werden. Dass SAP teils auf für das Gesamtprodukt sinnvolle Erweiterungen stößt, hat den Nebeneffekt, dass diese, vorerst kundenspezifischen Module in universell gehaltener Form ebenfalls in das Grundprodukt einfließen. Und so wächst und wächst die Software immer weiter, es entstehen nicht sofort erkennbare Abhängigkeiten im Code, die sich gegenseitig beeinflussen – und schon bekommen Folge-Releases Fehler und Abstürze an Stellen, die vorher reibungslos funktioniert haben.
Diese Entwicklung kann man auch beim Entwickeln neuer Betriebssystem-Releases beobachten. In den Anfangszeiten von Apple Inc. hat Steve Jobs gemeinsam mit Mitbegründer Steve Wozniak jede Zeile Code auseinandergenommen, die Syntax, das Design und die Implementierung in das bestehende System geprüft. Heutzutage ist das alleine aufgrund der Komplexität der Systeme, den tausenden bis mehreren Millionen Zeilen Code pro OS-Release in zig unterschiedlichen Sprachen nicht mehr realisierbar. Hatte Windows NT 3.5 noch “nur” 5 Millionen Code-Zeilen (ohne Kommentarzeilen), hatte bereits Windows XP bereits 40 Millionen Zeilen Code. Der Quelltext des Linux Kernels in Version 2.6 belief sich auf 5,2 Millionen Zeilen und ist bis zur Kernelversion 3.6 auf 15,9 Millionen Zeilen angewachsen. Da Debian in Version 5.0 bereits über 324 Millionen Zeilen verfügt hat, ist eine realistische Schätzung bei Debian 7.0 von ca. 420 Millionen Zeilen anzusetzen.
 
Dieser gewaltigen Text- und Abhängigkeitsmenge können Menschen nicht ohne Weiteres begegnen, sodass schnell Abhängigkeiten im Quelltext entstehen, die man entweder lange vernachlässigt oder gar nicht erst bedacht hat.
Umso wichtiger wird das Prüfen von Abhängigkeiten innerhalb der Software-Entwicklung, das Testen unterschiedlicher Konstellationen von Hard- und Software, unterschiedlichen Versionsständen und zwingend das Dokumentieren der Arbeitsergebnisse. Nichts ist frustrierender, als der Gedanke, die letzten Wochen getestet und getüftelt zu haben – aber nichts notiert zu haben, um es vergleichen oder auswerten zu können.
Nicht nur einzelne Produkte und Versionen müssen fortwährend geprüft, sondern auch das Zusammenspiel der Entwicklungsergebnisse getestet werden, um ungewollte Nebeneffekte in bestimmten Konstellationen im Produktivbetrieb zu vermeiden bzw. ausschließen zu können.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.