BLOG
18/03/2015 07:04 CET | Aktualisiert 18/05/2015 07:12 CEST

Sicherheitslücken: Schweigen ist Silber, Reden ist Gold.

2015-03-16-1426529882-3629480-ZeroDayLckenSchweigenistGold.jpg

Verschleppte Fehlerbehebung: Ab wann sollte die Öffentlichkeit informiert werden? Das sagen die Experten.

Kritischen Schwachstellen in Software, die von unabhängigen Sicherheitsforschern gefunden werden, stellen Anbieter wie Sicherheitsexperten immer wieder vor eine zwiespältige Frage: Wie sieht ein verantwortungsvoller Umgang mit Sicherheitslücken aus? Damit sind besonders die sogenannten Zero-Day-Schwachstellen gemeint, von denen die Softwarehersteller erstmalig von den Sicherheitsforschern in Kenntnis gesetzt werden und für die noch keine Fehlerbehebung vorliegt, die die Sicherheitslücke wirksam schließt.

Aus Sicht der Softwareanbieter besteht daher ein großes Interesse, die Sicherheitslücke vor der Öffentlichkeit zu verbergen, bis die Schwachstelle behoben und ein Software-Update verfügbar ist. Dem halten die Sicherheitsexperten entgegen, dass sich die Softwarehersteller nicht beliebig viel Zeit mit der Fehlerbehebung lassen dürften, denn schließlich bestehe die Gefahr, dass eine kritische Sicherheitslücke bereits von Hackern oder staatlichen Institutionen ausgenutzt würde.

Um Druck auf die Softwarehersteller auszuüben, müssten daher Fristen gesetzt und eingehalten werden. Ließe also ein Softwarehersteller die Frist verstreichen, würde im Gegenzug die Sicherheitslücke der Öffentlichkeit bekannt gemacht. Die Folge: Der Softwareanbieter gerät unter öffentlichen Druck seiner Kunden und Nutzer.

Zuletzt wurde dieser Standpunkt am Beispiel von Microsoft exerziert. Sicherheitsforscher vom Google Project Zero Team veröffentlichten nach Ablauf einer 90-Tage-Frist Details zu mehreren Windows-Lücken, obwohl Microsoft vor Verstreichen der Frist Google informiert hatte, die Fehlerbehebung mit dem nächsten turnusgemäßen Software-Update bereitzustellen, das nur wenige Tage über der Frist lag.

Das Vorgehen brachte Google in die Kritik, mit der allzu genauen Auslegung seiner Veröffentlichungsrichtlinien die Sicherheitssituation der Microsoft-Anwender bedroht zu haben. Google stand plötzlich als Buhmann dar, Microsoft als moralischer Gewinner.

Inzwischen hat das Google Project Zero Team eingelenkt und seine Disclosure Policy, also die selbstauferlegten Regeln für den Umgang mit entdeckten Sicherheitslücken, angepasst. Der Microsoft-Vorfall wäre damit abgedeckt. Nach den angepassten Regeln hätte Microsoft zusätzlich bis zu 2 Wochen Zeit erhalten, um das Software-Update auszuliefern, sofern es Google vor Ablauf der Frist über das bevorstehende Update informiert hätte.

Nun ist doch alles gut, oder? Die Frage bleibt, ob kürzere oder längere Fristen für Softwareanbieter zur Behandlung einer Sicherheitssituation überhaupt sinnvoll sind. Wäre es für die Nutzer und Anwender nicht besser, wenn Sicherheitsforscher Zero-Day-Lücken unverzüglich nach Entdeckung der Öffentlichkeit preisgeben würden?

So könnten schneller Maßnahmen ergriffen werden, um Software-Schwachstellen bis zu deren Behebung zu umgehen oder gar zu deaktivieren, wie im Falle Heartbleed oder kritischer Fehler in Adobe's Flash Player erst kürzlich geschehen.

Ich habe 3 Sicherheitsexperten um ihre Einschätzung gebeten.

Lars Kripko (Profil auf XING), Berater Datenschutz, T-Systems Multimedia Solutions

Hr. Kripko, als externer Datenschutzbeauftragter helfen Sie Ihren Auftraggebern, kritische Daten und Schnittstellen zu identifizieren und wirksame Schutzmaßnahmen umzusetzen. Sie vertreten in dieser Rolle also eher die Anwenderseite. Können Sie Microsoft's Kritik an das Google Project Zero Team nachvollziehen?

Wenn das Google-Team einen Fehler in einem Microsoftprodukt meldet und Microsoft den Fehler behebt, kämpfen zwei Schwergewichte der IT für unsere Sicherheit. Super. Deshalb werden sie aber offenbar noch lange nicht Freunde. Wir sehen hier eine Formalienrempelei von Mitbewerbern, die aber trotz allem zu unserem Schutz gemeinsam an einer Fehlerbeseitigung arbeiten. Meine persönlichen Sympathien sind dann offen gestanden eher bei dem, der sein Regelwerk prüft und selbstkritisch anpasst, als bei dem, der laut Foul ruft.

Fehlerberichte sollten aus meiner Sicht grundsätzlich veröffentlicht werden, damit wir in den Unternehmen die existierenden Risiken kennen und reagieren können. Schließlich ist die Fehlerbeseitigung durch den Hersteller nicht die einzige Reaktionsmöglichkeit im Anwenderunternehmen. Im Extremfall könnte man die Software bspw. vorübergehend nicht nutzen.

Ich teile die Auffassung, nach der ein nicht veröffentlichter Fehler nur weniger gefährlich ist, solange ausschließlich die Guten den geheimen Fehler kennen. Auf dieser Hoffnung sollte jedoch kein Sicherheitskonzept aufgebaut sein. Auf der anderen Seite gebe ich aber auch gern zu, dass eine Veröffentlichung von Fehlerberichten die Bösen informiert. Insofern sehe ich in einer definierten Schweigefrist einen gelungenen Kompromiss.

- - -

Jean Pascal Pereira (Profil auf XING), IT-Security Spezialist, SECBIZ

Hr. Pereira, Sie gerieten in eine ähnliche Kritik wie das Google Project Zero Team, als Sie eine Sicherheitslücke in einem sozialen Netzwerk entdeckten und offenlegten. Dem Betreiber des Dienstes hatten Sie einige Monate zuvor einen Proof-of-Concept zur Verfügung gestellt, der nachvollziehbar zeigte, wie die Schwachstelle ausgenutzt werden konnte, um die Kontrolle über Benutzerkonten zu erlangen. Lange Zeit passierte nichts. Nach Veröffentlichung der Schwachstelle aber wurde sie noch am selben Tag behoben. Warum nicht gleich so?

Ab dem Zeitpunkt, als ich die Sicherheitslücke in dem sozialen Netzwerk entdeckte, war mir klar, dass jeder, der diese Schwachstelle auch entdecken würde, Zugriff auf all meine persönlichen Daten erhalten wird, und auch in der Lage sein wird, Informationen die ich erhalte oder versende, zu manipulieren. Bei dem sozialen Netzwerk waren auch Kreditkarten hinterlegt.

Deshalb entschloss ich mich dazu, die Schwachstelle zu veröffentlichen. Dabei habe ich allerdings keine Details zu der Sicherheitslücke veröffentlicht, welche es einem fremden Hacker ermöglicht hätten, die Schwachstelle auszunutzen. Ich habe lediglich einen Proof-of-Concept und ein Video veröffentlicht, um die Existenz der Sicherheitslücke nachzuweisen.

Eine Sicherheitslücke betrifft nicht nur das eigene Unternehmen, sondern auch die Privatsphäre der Benutzer. Eine unveröffentlichte Sicherheitslücke in einer Software oder einem Produkt, welches im betrieblichen Umfeld eingesetzt wird, ist eine Einladung zur Industriespionage.

Sobald eine Sicherheitslücke öffentlich ist, besteht auch ein öffentliches Interesse, diese zu beheben. Dadurch sinkt automatisch die Gefahr der Bedrohung durch die Sicherheitslücke, die von Tag zu Tag steigt, solange diese geheim gehalten wird. Deshalb hat Google meiner Meinung nach an dieser Stelle vollkommen richtig reagiert.

- - -

Dr. Markus Schumacher (Profil auf XING), CEO, Virtual Forge

Hr. Dr. Schumacher, Ihr Unternehmen Virtual Forge konzentriert sich seit Jahren auf die Erforschung von Sicherheitsrisiken in SAP-Geschäftsanwendungen und -Systemen. Vor dem Hintergrund der milliardenschweren Transaktionen, die Anwender täglich mit SAP-Anwendungen abwickeln, sollte das Kunden-Interesse an einem schnellen wirksamen Schutz höchste Priorität haben.

Sie aber decken regelmäßig Zero-Day-Lücken in SAP auf und haben noch nie eine vor ihrer offiziellen Fehlerbehebung durch SAP veröffentlicht. Ist es aus Ihrer Sicht verantwortungsvoll den Anwendern gegenüber, dem Anbieter beliebig viel Zeit zu lassen?

Beliebig viel Zeit ist sicher nicht der richtige Weg, aber eben auch nicht das Offenlegen von Zero-Day-Lücken, sobald eine bestimmte Frist überschritten wurde, wie im Falle des Google-Teams - damit ist m. E. außer dem Ego keinem geholfen. Wenn wir und andere SAP-Sicherheitsexperten regelmäßig neu entdeckte Probleme an SAP melden, wollen wir vor allem sicherstellen, dass die SAP-Anwendungen der Kunden nicht durch offensichtliche Lücken angreifbar sind. Hier findet grundsätzlich ein aktiver Austausch mit SAP statt.

In Summe werden aber folgende Problemfelder noch nicht hinreichend adressiert:

1) Nicht jede Zero-Day-Schwachstelle wird gemeldet. Zum einen spielen hier kriminelle Motive eine Rolle. Ein bösartiger Hacker hat kein Interesse daran, dass seine Eintrittstüren in ein SAP-System geschlossen werden.

Zum anderen sehe ich bezüglich der Incentives für die „Guten" noch Verbesserungsbedarf. Es muss also davon ausgegangen werden, dass es eine Dunkelziffer von Sicherheitslücken gibt, sodass es umso wichtiger ist, das Thema SAP-Sicherheit in den Unternehmen deutlich höher zu priorisieren und mit den bestehenden Sicherheitsmaßnahmen zu verzahnen.

2) Der Zeitpunkt zwischen Entdeckung einer Lücke und der Veröffentlichung ist ein weiteres Problem. Denn während diesem „Window of Exposure" wächst unweigerlich die Anzahl der Mitwisser, da in der Szene darüber gesprochen wird und es einen Austausch zwischen dem Researcher und SAP gibt.

Es ist mir bisher nicht bekannt, dass es in der Diskussion um „Responsible Disclosure" Konzepte für eine proaktive Kommunikation bezüglich Workarounds gibt. Hier würde ich einen echten Mehrwert solcher Initiativen wie von Google & Co sehen.

3) Wenn die Patches dann veröffentlicht sind, entsteht folgendes Dilemma: im Patch steht prinzipiell drin, was vorher angreifbar war. Und diese Information steht jedem zur Verfügung, der auf den SAP Service-Marktplatz zugreifen kann. Es ist daher sehr wichtig, die Patches schnell einzuspielen und dafür die entsprechenden Ressourcen bereit zu stellen.

Die andere Seite ist, dass jeder Patch nicht zu unterschätzende Testaufwände nach sich ziehen kann. Wenn immer alle Patches eingespielt werden, wird es schnell sehr teuer. Wie stellen Sie also sicher, dass die relevanten Patches eingespielt werden? Hier rege ich an, dass sich Unternehmen z. B. pro Industrie oder Applikationsdomäne zusammenschließen, um sich einerseits die Expertise, aber auch die Arbeitslast der notwendigen Patch-Analyse zu teilen.

4) Vergessen Sie bei aller öffentlich stimulierten Diskussion um Zero Days nicht, die eigenen Hausaufgaben zu machen. Jede neue Zeile neuentwickelter Code, jedes Add-On, jede SAP-Konfigurationsänderung und jede zusätzliche Berechtigung kann zu einer Sicherheitslücke führen. Darauf werden weder SAP noch die Zero-Day-Researcher fokussieren - denn die Verantwortung dafür liegt ausschließlich beim Unternehmen, das SAP einsetzt.

* * *

Weiterführende Links:

Heartbleed disclosure timeline: who knew what and when - The Sydney Morning Herald

2 nützliche Lehren aus dem Heartbleed-Bug - Huffington Post


Sie haben auch ein spannendes Thema?

Die Huffington Post ist eine Debattenplattform für alle Perspektiven. Wenn Sie die Diskussion zu politischen oder gesellschaftlichen Themen vorantreiben wollen, schicken Sie Ihre Idee an unser Blogteam unter blog@huffingtonpost.de.


Video: 7 grandiose Fakten über Google, die Sie sicher noch nicht kennen