Bei der Softwareentwicklung lauert ein vielfach unterschätztes Sicherheitsrisiko: Schwachstellen und Sicherheitslücken in den Anwendungen können schnell zur Gefahr für die gesamte Unternehmens-IT werden. Dabei sind es meist weniger die Eigenentwicklungen, die dieses Risiko fördert, sondern die Nutzung von Programmelementen Dritter - auch als Third-Party-Software bezeichnet.

Eine nicht unbedeutende Bedrohung, denn immerhin 70 Prozent der intern in Firmen entwickelten Software enthält externen Code. Das bedeutet, dass beispielsweise bestimmte Libraries oder Open Source-Bestandteile von externen Entwicklern implementiert werden, um den gesamten Entwicklungsaufwand klein zu halten. Die Integration von externen Bestandteilen in die eigenen Software-Entwicklungen ist sehr verführerisch, denn dadurch lassen sich (Entwicklungs-)Zeit und Geld sparen.

Third-Party-Software - doch was ist mit der Sicherheit?

Für viele Funktionalitäten gibt es bereits verfügbare Module oder Libraries. Durch ihre Nutzung ersparen sich Entwickler eine eigene Programmierung und können darüber hinaus sogar häufig Standards nutzen, die einen Datenaustausch erheblich erleichtern. Durch die so eingesparte Entwicklungsleistung ist lediglich ein kleines R&D-Team zur Softwareentwicklung erforderlich. Zudem setzen Unternehmen dadurch auf vermeintlich ausgereifte Programmmodule, die vielfach im Markt erprobt werden. Die wenigsten Unternehmen bedenken allerdings die eklatanten Nachteile, die ihnen durch diese scheinbare Abkürzung entstehen können: Dazu zählen mitunter längst bekannte Schwachstellen in diesen Modulen, die relativ einfach von Angreifern genutzt werden können.

Auch das Patch-Management bei derartiger Software ist oftmals ein kritischer Faktor, weil die eigenen Entwickler darauf keinen Einfluss nehmen können. Fehlende oder nur mit Verzögerung verfügbare Patches tragen gewiss nicht dazu bei, das Sicherheitsrisiko zu minimieren. Hinzu kommt, dass viele Patches zwar einige Bugs der ursprünglichen Anwendung eliminieren, dafür aber neue Schwachstellen einschleusen können.

Unternehmen vergessen oft die Gefahren

Experten wissen längst, dass Drittanbieter-Software häufig das größte Sicherheitsproblem darstellt. So warnt beispielsweise das OWASP (Open Web Application Security Project) vor dem Einsatz von Komponenten wie Libraries, Frameworks und Software-Modulen mit bekannten Schwachstellen. Denn die meisten dieser Module werden mit vollen Rechten betrieben. Die Folge: Wenn sich ein Unbefugter in diesem Fall über einen Exploit Zugang zu der betreffenden Komponente verschafft, ist meist das komplette System betroffen und gefährdet.

Wer nun allerdings glaubt, dass Komponenten mit entsprechender Verwundbarkeit von Unternehmen nicht verwendet werden, wird von einer aktuellen Aspect Security-Studie eines Besseren belehrt: Rund 26 Prozent der von den 60.000 für die Studie untersuchten Unternehmen geladenen 113 Millionen Library-Downloads enthielten Schwachstellen, die von externen Angreifern genutzt werden können. Die Secunia Vulnerability Review 2014 zeigt das gesamte Ausmaß der Bedrohung: Von rund 1.200 Schwachstellen in 50 untersuchten populären Anwendungen gehen 76 Prozent auf das Konto von Third-Party-Komponenten.

Heartbleed-Bug und Poodle: Zwei prominente Sicherheitslücken

Ein prominentes Beispiel für ein derartiges Sicherheitsproblem ist der „Heartbleed“-Bug in OpenSSL. Bei OpenSSL handelt es sich um eine freie Software für Transport-Layer-Security, die für Webserver, Netzwerk-Appliances sowie Client-Software verwendet wird. Durch Ausnutzung des Heartbleed-Bugs erlangen Kriminelle Zugriff auf Daten auf dem betroffenen System und sind somit in der Lage, hochsensible Informationen zu stehlen. Das Problem ist deshalb so umfassend, weil 66 Prozent der weltweiten SSL-geschützen Webseiten OpenSSL benutzen – ein Sicherheitsgau gigantischen Ausmaßes ist die Folge. Nur kurze Zeit später folgte Poodle: Über SSL 3.0 können mittels Paddding sensible Daten gehackt werden.

Wie Hacker vorgehen

Trotzdem ist es wichtig im Auge zu behalten, dass Zero Day Exploits noch lange nicht die größte Bedrohung sind. Sie erscheinen zwar besonders spektakulär, weil viele Hacker in einem Wettstreit sind, wer der Erste ist, der eine derartige Schwachstelle entdeckt. Jedoch darf nicht vergessen werden, dass bekannte Schwachstellen in Programmen oftmals viel gefährlicher sind. Denn wenn Hacker wissen, wo sie ansetzen müssen, können sie mit relativ überschaubarem Aufwand immensen Schaden anrichten.

Mittlerweile nutzen sie dazu bereits Bot-Netze, die öffentliche Server nach Schwachstellen abscannen. Sie injizieren Hijack- oder Drive-By-Code in identifizierte Systeme und vergrößern damit das eigene Bot-Netz. Dadurch gelingt es diesen Netzen dann beispielsweise bei Brute-Force-Attacken – wie einer DDoS-Attacke – so viel Rechenpower verfügbar zu machen, dass selbst leistungsfähige Serversysteme in die Knie gezwungen werden können.

Sicherheit auch für Drittanbieter-Software: Was ist zu tun?

Am einfachsten wäre es sicherlich, völlig auf den Einsatz von Drittanbieter-Software zu verzichten, um so das Sicherheitsrisiko zu minimieren. Das jedoch dürfte für die meisten Unternehmen nicht möglich sein. Denn Third-Party-Software ist in vielen Entwicklungsprozessen schlichtweg unverzichtbar, um das Ziel pünktlich und kosteneffizient zu erreichen. Daher ist es erforderlich, dass diese Komponenten verantwortungsbewusst eingesetzt werden. Versionen und Abhängigkeiten sollten bei der Implementierung sorgfältig verfolgt werden. Darüber hinaus sollte die mit den Third-Party-Komponente erstellte Software immer gründlichen Pentests unterzogen werden. Pentests sind Untersuchungen, bei denen die Verwundbarkeit und Möglichkeiten geprüft werden, mit denen Hacker eine Applikation angreifen können.

Unnötige Module abschalten - Miminierung von Sicherheitsrisiken

Eine wichtige Methode, mögliche Angriffspunkte zu eliminieren, ist es, überflüssige Funktionen in Modulen abzuschalten. Denn viele Funktionalitäten werden in der Softwareumgebung, in die sie integriert sind, gar nicht benötigt. Nach dem einfachen Grundsatz „was nicht vorhanden ist, kann nicht angegriffen werden“ lassen sich auf diese Weise bestimmte Lücken bereits im Vorfeld ausschließen.

Bei ihren Sicherheits-Policies sollten Unternehmen unbedingt sowohl rechtliche als auch technische Aspekte berücksichtigen. Das betrifft besonders die Prozesse, in denen Third-Party-Software genutzt wird. Diese Richtlinien müssen genau festlegen, in welchem Umfang solche Software eingesetzt wird und welche Zugriffe im Rahmen von Anwendungen erlaubt werden sollen. Wer diese Bestimmungen dann noch regelmäßig auf ihre Einhaltung kontrolliert und sich bei dem Einsatz von Third-Party-Software auf das Notwendigste beschränkt, ist anderen Unternehmen in punkto Sicherheit garantiert ein gutes Stück voraus.