Bei Abhängigkeit vom Drittanbieter droht Kontrollverlust Schwachstellen in der digitalen Wertschöpfungskette
Mittels sicherer Software-Konfiguration und Patch-Management kann man lokale Systeme grundlegend gegen Cyberattacken absichern. Angriffe können aber auch außerhalb des eigenen Wirkungsbereichs erfolgen. Deshalb muss man auch aktiv für mehr Sicherheit beim Service-Anbieter sorgen.
Anbieter zum Thema

In dem praxisorientierten IT-Sicherheits-Framework „20 Critical Security Controls“, das kürzlich beim Council for CyberSecurity eine neue Heimat gefunden hat, werden Konfigurations- und Patch-Management hoch priorisiert. Die beiden Aufgaben werden gleich nach der Hardware- und Software-Inventarisierung in den Kontrollen 3 und 4 behandelt.
Mit Patches und richtigen Konfigurationen sichern wir jedoch nur die erste Stufe unserer digitalen Wertschöpfungskette ab, und wir müssen auch auf die indirekteren Beziehungen in unserer Infrastruktur achten. Unter den Patches, die Microsoft im August bereitstellte, war eine neue Version von Microsoft Exchange – ein interessantes Beispiel dafür das, worauf wir achtgeben müssen.
Microsoft musste eine neue Version der Exchange Mail Server Software herausbringen, um eine Anfälligkeit in einer der Komponenten zu beheben, die das Unternehmen nicht selbst unter Kontrolle hat. Microsoft lizenziert diese Komponente von einem Drittanbieter und muss sie daher selbst auf Patches überwachen.
Microsoft leistet dabei zwar gute Arbeit, die betreffende Software („Outside In“ von Oracle) wird aber auch von anderen Unternehmen und Produkten verwendet. Dort unterliegt sie mitunter weniger strikten Prozessen. Im Augenblick sind mir keine anderen Software-Anbieter bekannt, die aufgrund dieser Anfälligkeit in Outside In neue Versionen ihrer Produkte herausgebracht hätten.
Angriff auf Umwegen
Ein weiteres Glied in unserer digitalen Wertschöpfungskette rückt durch die Angriffe ins Blickfeld, die die Syrian Electronic Army (SEA) jüngst auf die Websites der New York Times, der Huffington Post und Twitter durchgeführt hat. Die SEA attackierte diese Unternehmen nicht direkt, sondern über deren Domain-Registrar – einen Drittanbieter, den jedes Unternehmen mit einer Internet-Präsenz benötigt.
Der Domain-Registrar ist zuständig für die Beziehung zwischen der NY Times und dem Verwalter der Top-Level-Domain (.com) und überwacht insbesondere auch das Mapping von Nameservern. Im Falle der NY Times heißt der Nameserver normalerweise „dns.ewr1.nytimes.com“.
Der SEA gelang es, beim Domain-Registrar einzudringen und den Nameserver auf „m.sea.sy“ zu setzen. So konnte die SEA nun den Internetzugriff auf alle Server von nytimes.com kontrollieren – neben dem Webserver waren davon auch alle anderen Server wie etwa mail.nytimes.com betroffen. Damit war die SEA in der Lage, die Website teilweise zu manipulieren und lahmzulegen.
Twitter konnte den gleichen Angriff wesentlich besser abwehren, weil das Unternehmen bei VeriSign, dem Verwalter der Top-Level-Domain, ein Werkzeug namens „Registry Lock“ (Registrierungssperre) implementiert hat. Wenn diese Sperre aktiviert ist, überprüft ein Mitarbeiter Nameserver-Änderungen und holt bei dem anfordernden Unternehmen eine telefonische Bestätigung ein.
Wäre Twitters normale Einstellung „ns1.p34.dynect.net“ zu „m.sea.sy“ geändert worden, hätte dies jeder zuständige Mitarbeiter als verdächtig erkannt. Die Angreifer hätten somit zusätzlich Social Engineering einsetzen und sich als legitime Twitter-Mitarbeiter ausgeben müssen, was kaum zu bewerkstelligen sein dürfte.
Services in die Planung mit einbeziehen
Nehmen Sie dieses Beispiel zum Anlass, um sich einen Überblick zu verschaffen, wo Ihre Anfälligkeiten liegen und wie Sie sie gegebenenfalls minimieren können. Übrigens gelten ähnliche Überlegungen für alle Domains, die in Ihrem Unternehmen verwendet werden, also auch .net, .de, .co.uk und alle anderen Top-Level-Domains.
Für uns in der IT-Sicherheit wird dies zu einem weiteren Aspekt unseres Asset-Inventars. Wir müssen uns fragen, auf welche Ressourcen das Unternehmen angewiesen ist und welche potenziellen Probleme Auswirkungen auf sie haben könnten. Wir können nicht an den Grenzen des Unternehmens Halt machen, sondern müssen die Kartierung der Ressourcen auch auf unsere Dienstanbieter ausweiten und deren Infrastrukturen in unsere Abwehr- und Kontrollmaßnahmen einbeziehen.
Über den Autor
Wolfgang Kandek ist Chief Technical Officer bei Qualys.
(ID:42347535)