Was bleibt nach Heartbleed? Open-Source-Software sicher in Unternehmen betreiben

Heartbleed hat die Debatte um die Sicherheit von Open Source neu angefacht. Dabei war Open Source gar nicht die Ursache des Heartbleed-Bugs.

Laut einer Studie aus dem April diesen Jahres sind Sicherheit und Qualität die zwei wichtigsten Gründe, wegen der...

Unternehmen Open-Source-Software einsetzen. Nach Heartbleed blicken viele Unternehmen allerdings mit einem mulmigen Gefühl auf Open-Source-Software.

Die Entdeckung der Heartbleed-Lücke hat die sehr emotional geführte Debatte um die Sicherheit von Open-Source- vs. proprietärer Software wieder aufflammen lassen. Das Hauptargument für den Einsatz von Open-Source-Software in Unternehmen ist dabei das sogenannte Linus´sche Gesetz, wonach bei genügend Beteiligten alle Software-Fehler entdeckt werden. Anders gesagt: Bei einer genügend großen Anzahl an Entwicklern sollte eigentlich jeder Fehler und Bug gefunden und behoben werden. Das Linux-Betriebssystem zum Beispiel profitiert von einer enorm großen Anzahl an Entwicklern auf der ganzen Welt, die durchschnittlich neun Verbesserungen und Patches pro Stunde besteuern.

Das große Problem mit OpenSSL, der Open-Source-Software, die dem Heartbleed-Bug zugrunde lag, ist dabei, dass OpenSSL zwar weitflächig im Einsatz ist, aber offensichtlich keine große Unterstützung aus der Community erfahren hat.

In diesem Tipp werde ich der Wahrheit über die Sicherheit von Open-Source-Software nachgehen und zeigen, was Unternehmen von Heartbleed lernen können.

So entstehen Sicherheitsrisiken beim Einsatz von Open-Source-Software

Nur weil der Quellcode einer Software frei verfügbar ist, heißt das noch lange nicht, dass es auch genügend Entwickler gibt, die den Code lesen und verstehen und vor allem regelmäßig überprüfen können. Obwohl OpenSSL geschätzt von zwei Dritteln aller Webserver eingesetzt wird, hat sich offenbar kaum jemand Gedanken darüber gemacht, den Quellcode auf seine Sicherheit hin zu überprüfen und zu testen. Daher bestand der Heartbleed-Bug wohl auch schon unbemerkt seit einigen Jahren.

Es gibt sogar viele Stimmen, die gerade wegen Heartbleed der Meinung sind, das Modell Open Source funktioniere, weil der Heartbleed-Fehler ja schließlich gefunden wurde. Mit proprietärer Software wäre das vielleicht nicht gelungen.

Nicht-unterstützte Software im Unternehmen einzusetzen verstößt gegen viele Regeln und Standards, und trotzdem haben tausende große Unternehmen auch für geschäftskritische Projekte nur zu gern OpenSSL eingesetzt, obwohl das Projekt bis dahin lediglich um die 2.000 US-Dollar pro Jahr an Zuwendungen erhalten hat und nur einen Vollzeitmitarbeiter beschäftigt. Diese Ressourcen entsprechen natürlich nicht auch nur annähernd der Summe, die für die Verwaltung eines so komplexen Projektes nötig wäre.

Andere Open-Source-Projekte wie Linux oder OpenStack können für gewöhnlich auf Vollzeitbeschäftigte aus beteiligten Unternehmen zurückgreifen, die sich dem Projekt in irgendeiner Art und Weise verschrieben haben und Beiträge dazu liefern.

Es ist dabei wichtig zu verstehen, dass die Heartbleed-Lücke nicht deshalb auftrat, weil OpenSSL Open Source ist. Sie ist aufgetreten, weil das OpenSSL-Projekt nicht genügend Unterstützung erfahren hat. Aus diesem Grund fordert die OpenSSL Foundation jetzt auch mehr Geld, mit dem die nötigen Ressourcen geschaffen werden sollen, um den Code in regelmäßigen Abständen zu reviewen und zu testen, die Komplexität zu verringern und eine bessere Kommunikation mit der Community sicherzustellen. Speziell fragt die Foundation auch genau die Unternehmen und staatlichen Stellen an, die OpenSSL seit Jahren im Einsatz haben und dessen Existenz bisher immer als gegeben betrachtet haben.

Es wird Millionen von US-Dollar kosten, die Heartbleed-Lücke endgültig zu schließen, während es nur einige Tausend Dollar gekostet hätte, sie von vorneherein zu verhindern. Immerhin haben sich inzwischen führende Unternehmen wie Google, Facebook, IBM und Microsoft mit der Linux Foundation zur Core Infrastructure Initiative zusammengeschlossen, um die finanzielle Unterstützung bestimmter Kern-Technologien der Open-Source-Welt, inklusive OpenSSL, zu sichern. Auch wenn diese Initiative dabei helfen wird, die Sicherheit von Open-Source-Software im Unternehmen zu verbessern, sollten sich Unternehmen nur auf Tests, nicht auf irgendwelche Aussagen verlassen. Das wiederum gilt aber eigentlich für alle Arten von Software, egal ob Open Source oder proprietär.

Best Practices zur Sicherheit von Open-Source-Software in Unternehmen

Als wichtigste Lektion aus der Heartbleed-Lücke sollten Unternehmen also mitnehmen, dass man sich nie auf die Versicherung eines anderen verlassen sollte, wenn es um die Sicherheit von Software geht. Unternehmen müssen beim Einsatz von Open-Source-Software eigene Risikobewertungen vornehmen und eigene Software-Tests durchführen, um die gängigsten Schwachstellen und Bedrohungen ausschließen zu können. Unternehmen sollten ihre Ergebnisse dabei auch dokumentieren, damit andere sie nachvollziehen können. Die Risikobewertung sollte auch Aufschluss darüber geben, wie schnell Sicherheitspatches nach Bekanntwerden einer Schwachstelle veröffentlicht werden und in welcher Form diese veröffentlicht werden.

Vor allem wenn es um Open-Source-Software geht, sollte eine ausgereifte Community um das Projekt herum entstanden sein, die klare Regeln und Richtlinien darüber hat, wie Beiträge zur Software evaluiert und integriert werden. Genauso bedarf es einer zentralen Kontrollinstanz, die darüber entscheidet. Fallstudien über fehlerfreie, reale Deployment-Szenarien sind dabei weitaus hilfreicher als die Anzahl der bisherigen Downloads.

Software-Probleme kommen aber natürlich nicht nur im Open-Source-Umfeld vor. Auch bei proprietärer Software lohnt sich daher der Blick auf sichere Frameworks zum Development Lifecycle. Fragen Sie Ihre Anbieter doch einmal danach, wer gute Prozeduren entwickelt hat wird sich nicht scheuen, die Details mit Ihnen zu teilen oder Sie zumindest an die richtige Stelle verweisen.

Egal ob Unternehmen Open-Source-Software oder proprietäre im Einsatz haben, die zugrundeliegende Infrastruktur sollte immer so ausgelegt sein, dass kritische Teile ausfallen oder eine Bedrohung darstellen können. Das schließt selbstverständlich das Verständnis der gegenseitigen Abhängigkeiten verschiedener Komponenten ein, um im Ernstfall einzelne Teile austauschen zu können.

Folgen Sie SearchSecurity.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im August 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Webserver-Bedrohungen

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close