Open-Source und die Auswirkungen auf die Sicherheit

Open-Source und die Auswirkungen auf die Sicherheit

Marc Ruef
von Marc Ruef
Lesezeit: 6 Minuten

Seit jeher wird debattiert, ob und inwiefern Quelloffenheit Einfluss auf die Sicherheit eines Produkts haben kann. Es gibt hier theoretisch drei Standpunkte, die vertreten werden können:

Generell kann gesagt werden, dass alle drei Annahmen richtig sein können. Die Aussage ist aber massgeblich vom Standpunkt und den mit ihm einhergehenden Eigenschaften abhängig. Diese können den Aussagen entsprechend wie folgt zusammengefasst werden:

Verhalten der Fehlerquote

Gehen wir davon aus, dass ein System eine Anzahl Fehler Total hat. Diese können grösser oder gleich gross der Anzahl Fehler Unentdeckt sein. Diese können ihrerseits grösser oder gleich gross der Anzahl Fehler Entdeckt sein. Und diese können ebenfalls grösser oder gleich gross Fehler öffentlich sein:

Fehler Total ≥ Fehler Unentdeckt ≥ Fehler Entdeckt ≥ Fehler Öffentlich

Die Reihenfolge dieses Vergleichs bestimmt ebenso die Gefahr eines Fehlers. Umso entdeckter/öffentlicher er ist, desto eher kann und wird er behoben werden. Dies ist im Grunde sowohl für den Hersteller als auch für die Nutzer/Kunden von Vorteil.

In so manchen Publikationen wird davon ausgegangen, dass die Anzahl Fehler Entdeckt bzw. Fehler Öffentlich eine direkte Aussage zur Sicherheit eines Systems (und damit über die Anzahl der Fehler Total) gemacht werden kann. Dies ist jedoch, wie der Vergleich zeigt, nicht zwingend der Fall. Es kann höchstens aus den Daten der Vergangenheit ein möglicher Trend aufgezeigt werden.

Eine hohe Anzahl öffentlich gemachter Fehler ist in diesem Fall aber nicht zwingend nur ein Hinweis auf die fehlende Qualität eines Produkts. Ebenso können diese, sind sie denn behoben worden, Aufschluss über die gegenwärtig erhöhte Sicherheit geben. Gute Beispiele hierfür sind die Microsoft-Produkte IIS und Internet Explorer. Beide Lösungen sind jahrelang aufgrund der überdurchschnittlich hohen Anzahl Sicherheitslücken/Patches in der Kritik gestanden. Der gegenwärtige statistische Vergleich (siehe auch) mit konkurrierenden Produkten attestiert diesen Lösungen mittlerweile eine bessere durchschnittliche Sicherheitsqualität. Es darf sich also nicht nur auf Daten der Vergangenheit in unumstösslicher Weise verlassen werden.

Modell für hochsichere Umgebungen

Es wurde nun gezeigt, dass sowohl offene als auch geschlossene Systeme einen sicherheitstechnischen Vorteil versprechen können. Damit stellt sich nun aber die Frage, welches Modell in hochsicheren Umgebungen bevorzugt werden sollte.

Eine geschlossene Lösung kann dann empfohlen werden, wenn ein kurzfristiger Vorteil – und nur ein solcher! – erreicht werden will. Kann die Lösung durch eigene Spezialisten umfangreich geprüft werden, kann sich damit ein Vorsprung herausgeholt werden (dies kann bei den Anpassungen von DES durch die NSA vermutet werden). Die Angreifer werden jedoch längerfristig in der Lage sein, diesen aufzuholen und damit den Vorteil des geschlossenen Systems in dessen Nachteil umzuwandeln (so geschehen bei der in GSM eingesetzten Verschlüsselung A5).

Längerfristig gesehen sollten deshalb stets offenen Systemen den Vorrang gegeben werden. Durch das etwaige Mitarbeiten einer Community – vor allem in Kombination mit den eigenen Spezialisten – können Fehler schneller eliminiert werden. Das Ziel sollte sein, irgendwann – möglichst schnell – den Zustand eines möglichst sicheren Systems zu erreichen, in dem keine unbekannten und untragbaren Schwachstellen mehr existieren.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie brauchen professionelles Vulnerability Management?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv