Anwendungssicherheit und Sicherheitslücken Open Source vs. Closed Source: Was ist sicherer?

Open Source vs. Closed Source – ein Streit, der von vielen Anwendern mit religiösem Eifer ausgefochten wird. IT-Entscheider denken da pragmatischer: Sie suchen nach Lösungen, die ihrem Unternehmen den größten Nutzen bringen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Insider Research

Veracode Limited

Beim Abwägen der Vor- und Nachteile von Open Source und proprietärer Software rückt immer häufiger die Sicherheit in den Mittelpunkt. Spektakuläre Hacks haben in den letzten Monaten zu Verunsicherung geführt.

Sind Open-Source-Anwendungen inhärent unsicher, weil jeder den Quellcode einsehen kann? Oder stellt in Wirklichkeit Closed-Source-Software eine Gefahr dar, weil behäbige Entwicklungshäuser Sicherheitslücken oft zu langsam schließen – oder sie gar nicht erst entdecken?

Open Source vs. Closed Source – aus Unternehmenssicht

Open-Source-Plattformen geben Entwicklern die Freiheit, Anwendungen flexibel an die Anforderungen ihres Unternehmens oder ihrer Kunden anzupassen. Neue oder veränderte Erfordernisse des Tagesgeschäfts lassen sich unmittelbar in Programmcode übertragen. Auf diese Weise entstehen Anwendungen, die perfekt zugeschnitten und immer auf der Höhe der Zeit sind. Gerade für innovative Unternehmen ist Open Source deshalb attraktiv. Befürworter offener Software verweisen außerdem auf einen vermeintlichen Vorsprung in Sachen Sicherheit: Weil mehr Entwickler und Teams ein Auge auf den Quellcode haben können, würden Schwachstellen zuverlässiger entdeckt und schneller beseitigt.

Befürworter von Closed-Source-Modellen argumentieren genau umgekehrt. Dass der Quellcode von Anwendungen nicht von jedermann eingesehen werden kann, ist ihrer Ansicht nach ein Vorteil. Denn Cyberkriminelle hätten es auf diese Weise wesentlich schwerer, Sicherheitslücken aufzuspüren. Außerdem halten sie es für sinnvoller, die Weiterentwicklung des Codes in die Hände eines spezialisierten Kernteams zu legen – anstatt sie wie bei vielen Open-Source-Projekten an eine Horde externer Entwickler auszulagern.

Beide Seiten haben gute Argumente, keine hat die Wahrheit für sich gepachtet. IT-Entscheider tun deshalb gut daran, in jedem Einzelfall sorgfältig abzuwägen, welche Lösung sich am besten eignet. Insbesondere sollten sie sich fragen, welche Maßnahmen sie ergreifen müssen, um ein Höchstmaß an Sicherheit zu gewährleisten.

Streitthema Security

Was ist sicherer – Open Source oder Closed Source? Wirft man einen Blick auf die spektakulären Hacks der letzten Monate und Jahre, dann muss konstatiert werden, dass keines der beiden Konzepte besonders gut abschneidet. Als „Heartbleed“ wurde eine Lücke in der quelloffenen Verschlüsselungsbibliothek Open SSL bekannt. Millionen von Webservern waren betroffen, alle Arten von Daten und Anwendungen wurden für Hacker zugänglich. Ähnlich dramatische Effekte hatte eine Sicherheitslücke im proprietären Code von Microsoft Windows, die im November 2014 bekannt wurde. Cyberkriminelle nutzten sie, um die Kreditkarteninformationen von 56 Millionen des amerikanischen Einzelhändlers Home Depot zu stehlen. Microsoft schloss die Lücke erst, nachdem der Hack bekannt wurde. Diese besonders prägnanten Beispiele zeigen, wie gefährdet Unternehmen und Anwender nach wie vor sind.

Veracode hat im laufenden Jahr seinen siebten State of Software Security (SoSS) Report vorgestellt. Basierend auf 300.000 Security-Assessments und weiteren Daten fungiert der Report als eine Bestandsaufnahme aktueller Trends und Standards. Erstmals geht es auch um die Risiken, die durch den Einsatz von Open-Source-Komponenten bei der Anwendungsentwicklung entstehen können.

Open-Source-Komponenten sind in der Anwendungsentwicklung omnipräsent. In den seltensten Fällen ist es für Unternehmen wirtschaftlich sinnvoll, Anwendungen vollständig selbst zu entwickeln, vor allem aber führt es zu zeitlichen Verzögerungen, wenn Entwicklerteams unnötige Extrarunden drehen. Angesichts der Innovationsgeschwindigkeit in vielen Branchen wäre das oft fatal. Es verwundert deshalb nicht, dass Anwendungen heute im Durchschnitt aus 46 Komponenten bestehen.

Obwohl der Einsatz von Open-Source-Komponenten dem Industriestandard entspricht, sind damit doch immense Sicherheitsrisiken verbunden. Die Auswertung von 5.300 Unternehmensanwendungen hat ergeben, dass Komponenten von Drittanbietern im Durchschnitt 24 bekannte Schwachstellen in Web-Anwendungen reißen. Und die unsicheren Komponenten sind nicht etwa nur in Ausnahmefällen im Einsatz, sondern beinahe allgegenwärtig: Eine systematische Untersuchung von Java-Anwendungen ergab, dass 97 Prozent von ihnen mindestens eine Komponente enthalten, die eine oder mehrere Schwachstellen aufweist.

Ein immenses Risiko, das Unternehmen nicht ignorieren dürfen, wenn sie an der Sicherheit ihrer Daten und Anwendungen interessiert sind. Aber müssen sie deshalb auf den Einsatz von Open-Source-Komponenten verzichten? Nein – und sie können es auch gar nicht, wenn sie Entwicklungskosten und -zeiten nicht explodieren lassen wollen. Stattdessen sollten sie sich um mehr Transparenz bemühen: Welche Komponenten setzen wir ein? Sind diese auf dem neuesten Stand? Existieren in den Komponenten bekannte Schwachstellen? Antworten auf diese Fragen müssen bekannt sein, wenn ein Höchstmaß an Sicherheit gewährleistet werden soll.

Fazit

Nicht Open Source oder Closed Source sind der Schlüssel zu mehr Sicherheit, sondern eine Kombination aus proaktiven Maßnahmen und mehr Transparenz. Ob der Quellcode von Drittanbieter-Komponenten proprietär ist oder nicht, spielt keine besondere Rolle. Entscheidend ist viel mehr, ob eine Komponente bekannte Schwachstellen aufweist und ob sie auf dem neuesten Stand ist. Dies lässt sich nicht manuell überprüfen – die Komplexität des Themas und die große Zahl an Komponenten verlangt ein systematisches Vorgehen. Analysetools, die Komponenten von Drittanbietern und den eigenen Code auf Sicherheitslücken untersuchen, schaffen hier Abhilfe.

Über den Autor

Julian Totzek-Hallhuber ist Solution Architect beim Spezialisten für Anwendungssicherheit Veracode und bringt mehr als 15 Jahre Erfahrung im IT-Sicherheitsumfeld mit. In seinen verschiedenen Funktionen war er für die Anwendungsentwicklung, für Penetrationstests sowie für die Sicherheit von Webanwendungen zuständig. Zudem ist er Autor zahlreicher Artikel, ist regelmäßig als Sprecher auf Messen anzutreffen und hat bei Projekten des Web Appplication Security Consortium (wie zum Beispiel WAFEC) mitgewirkt.

(ID:44499355)