Runder Tisch Security, Teil II – Welche Alltagsprobleme im Sicherheitsbereich bereiten einem großen Unternehmen wie SAP Kopfzerbrechen? Welche Funktionen vermisst es schmerzhaft? Und wie schließt es diese Lücken? Fragen, die der runde Tisch mit dem CSO von SAP und Vertretern von fünf Security-Anbietern ausführlich diskutiert hat.

Mit knapp 36 000 Mitarbeitern zählt SAP definitiv zu den großen Unternehmen in Deutschland. Als Chief-Security-Officer (CSO) prägt Sacher Paulus alle wichtigen IT-Entscheidungen, vor allem im Bereich IT-Sicherheit. Grund genug, mit ihm Probleme aus seinem Aufgabenfeld zu diskutieren und fünfHersteller entsprechender Produkte mit der Praxis zu konfrontieren. Klaus Lenssen von Cisco, Sebastian Rohr von Computer Associates (CA), Esther Donatz von F5 Networks, Toralv Dirro von McAfee sowie Klaus Gheri und Wieland Alge von Phion stellten sich der Diskussion. Wie jedes IT-betreibende Unternehmen, so muss auch SAP seine Applikationen permanent mit Patches flicken.Ein Bereich, der Sacher Paulus bei der Vorbesprechung besonders am Herzen lag. Wirkt er sich doch direkt auf die Verfügbarkeit und Sicherheit seiner wichtigen Komponenten im Netz aus. »Ein Beispiel: Eine Applikation nutzt Features einer Plattform, die jedoch einen Softwarefehler haben und somit zum Sicherheitsproblem werden. Der betroffene Hersteller der Plattform möchte einen Patch ausrollen. Dann aber läuft meine Applikation nicht mehr.« Darauf Sebastian Rohr von CA: »Ein Verantwortlicher darf nicht mehr blind Patches irgendeines Betriebssystem-Herstellers einspielen. Das schließt die Sicherheitslücke zwar, aber die Applikation läuft dann nicht mehr.Wir haben selbst als großer Anwender mit 16000 Mitarbeitern genau dieses Problem und daher ein eigenes Team ins Leben gerufen, das jeden Hersteller prüft, von Adobe bis Winzip. Wo gibt es neue Schwachstellen und Informationen dazu? Die erste Quelle sind natürlich die Hersteller selbst.

Dann CVE, Bugtrack und andere. Diese Informationen sammeln wir. Dann prüfen wir, ob es Patches oder Workarounds gibt.Dies geben wir kondensiert weiter.« Alle waren sich schließlich einig, dass niemand trotz dieser guten Vorarbeit bewerten könne,welche Effekte ein Patch in der Praxis auslösen wird. Wieland Alge von Phion wirft ein: »Darum geht der Markt stark in Richtung Appliances, da sie über einen einheitlichen Patch aktualisiert werden, Software und Betriebssystem inklusive.Dadurch ist ein einheitliches Systemverhalten erreicht. « Toralv Dirro erläutert: » Wir leben als Anbieter von Sicherheitslösungen zu einem großen Teil vom Thema Testen und Einspielen von Patches. Denn es ist extrem schwer, von vornherein zu sagen,wie kritisch ist dieser Patch ist.Daher muss er in jeder Infrastruktur erstmal getestet werden.

Und da kommen wir ins Spiel. Denn wir schließen das Zeitfenster zwischen Patch und Aufspielen mit unseren Lösungen.Beispielsweise per IPS.« Klaus Lenssen von Cisco kontert: »Sind die aktuellen Sicherheitstechniken, die wir zurzeit einsetzen, nicht die falschen? Denn wir rennen dem Problem nur hinterher, statt die Systeme grundsätzlich sicherer zu machen.« Als Beispiel nennt er die Konzepte, die Cisco bei eigenen Voice-Pro-dukten verfolgt, die ja auf einen Multi-Purpose- Betriebssystem aufsetzen. »Dort haben wir das Patch-Problem. Daher sichern wir diese Plattform mit einer Sandbox ab, die das Betriebssystem und die Applikation gegen unbefugte Benutzung schützt. Es gibt klare Listen und Regeln, was die einzelnen Anwendungen tun dürfen.Alles, was gegen diese Positiv-Liste verstößt, ist automatisch ein Ausschlusskriterium und sorgt dafür, dass diese fehlgeleitete Anwendung terminiert wird.« Sacher Paulus wirft ein: »Und was geschieht, wenn die Sandbox selbst ein Sicherheitsproblem hat?« Lenssen: »Dann haben Sie nur noch die Sandbox, die Sie an der Stelle anfassen müssen.

Man reduziert das Problem sehr stark, damit überwiegt der direkte Nutzen.« Aber den Patch dieser Sandbox müssen die Kunden doch genauso analysieren, unter Zeitdruck und dem Wissen, das ein kritisches System betroffen ist. Das Problem ist doch so nicht aus der Welt geschafft. Sacher Paulus verschärft: »Es kommen ja auch gesetzliche Vorschriften ins Spiel, wie die FDACompliance für Pharmaunternehmen.Wenn eine Softwarekomponente, die für den Produktionsbetrieb notwendig ist, ein Sicherheitsproblem hat, fällt mit seiner Bekanntmachung die Zertifizierung weg. Streng genommen dürften diese Unternehmen gar nicht mehr produzieren. Umgekehrt dürfen Sie keinen Patch einspielen, weil das Einspielen einen aufwändigen Testzyklus erfordert, damit die Zertifizierung wiederum erteilt werden kann.« Und selbst wenn ein Unternehmen seine Systeme mit entsprechenden präventiven Mechanismen ausrüstet, bleibt ein Problem unbeseitigt.

Dazu Toralv Dirro von McAfee: »Es ist relativ schwer, eine entsprechende Zertifizierung für ein beispielsweise per Host-IPS abgesichertes System zu bekommen. Denn die Dokumentation des Ganzen ist nicht gerade einfach.« Wieland Alge wirft ein: »Wir machen einen großen konzeptionellen Fehler.Als Security-Hersteller konzentrieren wir uns auf Probleme, die einfach zu lösen sind. Es ist beispielsweise relativ simpel, eine Sandbox für Windows zu schreiben. Es ist viel, viel schwieriger, das Ganze für ein Embedded-Device zu entwickeln. Seien es Drucker,Kopierer oder Echtzeitsteuerungen an Maschinen.« Klaus Gheri von Phion ergänzt: »Sie dürfen manchmal auch gar nichts auf ein System aufspielen, auch wenn es technisch problemlos gelänge. Sie verlieren aber den Zertifizierungsstatus.

Gutes Beispiel sind die SB-Automaten bei Banken. Da ist ein Windows drin. Der Hersteller der Software übernimmt keine Garantie,wenn Sie nur 1 Bit am installierten System verändern. Da etwas zuzugeben heißt automatisch für die Bank ein Risiko einzugehen, weil der Hersteller keine Garantie übernimmt«.

Mängel bei der Programmierung

Sacher Paulus spitzt zu: »Alle Sicherheitshersteller, die hier am Tisch sitzen, verdienen ihr Geld damit, dass die Applikationshersteller keine gute Software bauen.« Esther Donatz beschwichtigt: »Die Softwareentwickler sind unter Druck, dass Security nicht ihr erstes Anliegen ist. Sicherheit wird nachgezogen,wenn es denn nötig ist, oder über die Mauer geworfen.Nach dem Motto:Unsere Netzwerktruppe soll da mal was vorstellen, und dann wird es schon hinhauen.« Sacher Paulus stimmt zu:»Wir versuchen aber, die Wahrnehmung zu ändern, indem wir an die Universitäten gehen. Es ist ärgerlich, dass diese Institutionen in ihren Kolloquien oder Ausbildungsprogrammen nichts über sicheres Programmieren anbieten. Es kann doch nicht sein, dass die Industrie der Universität erklären muss, wie man sicher programmiert.« Sebastian Rohr von CA führt aus: »Die TU Darmstadt und Darmstadt insgesamt sind ein gutes Beispiel. Das dortige Zentrum für IT-Sicherheit und der Lehrstuhl von Frau Prof. Eckhard lehren sicheres Programmieren, unterstützt durch lokale Hersteller wie CA und SAP. Wir müssen den jungen Menschen nahe legen, dass Sicherheit von Anfang an dabei sein muss.« Sacher Paulus: »Es wird aber niemals eine 100 Prozent sichere Software geben.Deswegen müssen wir Prozesse etablieren, die solche Löcher schließen. Die Unternehmen werden also einen Zwischenschutz aufsetzen müssen, bis die Anwendung wieder sauber ist.« Sebastian Rohr antwortet: » Es geht darum, den Administrator, der für das Produkt oder System verantwortlich ist, richtig zu informieren.

Die Dienstleistung muss beispielsweise einen Workaround beschreiben, mit dessen Hilfe eine Plattform zwischendurch abgesichert ist. So lange, bis abends das nächste Wartungsfenster kommt.« Esther Donatz ergänzt: »Die Dienstleistung ist sicher ein Teil. Es bleibt aber ein Hase- und Igelspiel. Denn es wird immer jemanden geben, der sich noch einen tollen Hack ausdenkt und die Abwehrstruktur überlistet. Neben der puren Netzwerk-Security nach dem Signaturenprinzip ist in der positiven Security nach Türsteherprinzip auch ein gewisses Know-how über die Anwendung wichtig.Nur mit der Dienstleistung oder der Netzwerk-Security allein kommt niemand weiter.«

Hilfe von außen

Stichwort Provider:Würde ein deutsches Unternehmen wie SAP einem amerikanischen Hersteller eine solche Dienstleistung anvertrauen? Dazu Sacher Paulus: » Ein so großes technikorientiertes Unternehmen wie wir wird das selbst im Griff haben wollen. Das heißt nicht, dass wir alles selbst machen, aber dass wir die kompletten Kontrollprozesse darüber weiter behalten.Ein kleiner Mittelständler aber braucht diese Dienstleistung noch viel dringender. Er besitzt kein so breites Wissen, um auch den Kontrollprozess selbst zu stemmen. Ich behaupte, dass entweder die ISPs oder die Applikationshersteller diese Aufgaben übernehmen.Wie genau, ist abhängig von der Branche und Industrie.« Das Ziel muss am Ende sein, das Window-of- Vulnerability zu schließen. Allgemeine, umfassende Kooperationen zwischen den Herstellern wären ein Weg, dieses Fenster zu verkleinern.Sind solche Allianzen realistisch? Dazu Sacher Paulus: »Nein, es geht wahrscheinlich nur über ganz harte, manuelle Kooperationen, die bestimmte Prozesse vereinbaren, auch über Herstellergrenzen hinweg.« Toralv Dirro ergänzt: »Es gibt ja schon Ansätze wie die CVE. Es existiert auch eine ganze Reihe von Pseudostandards. Bugtrag-ID ist wahrscheinlich in der Praxis fast wichtiger als die CVEInformationen.

« Klaus Lenssen relativiert: »Advisories sind eine Informationsquelle zu Sicherheitsrisiken. Allein im Jahr 2003 wurden jedoch mehr als 4300 Stück veröffentlicht.Wer nur fünf Minuten pro Vorfall investiert, ist bei acht Stunden pro Tag 45 Tage lang beschäftigt. Das ist uninteressant. Die Informationen müssen viel besser auf den Adressaten zugeschnittenen sein. Da ist eine Dienstleistung, die berücksichtigt,was beim Kunden steht, sicher der bessere Weg.« Wieland Alge ergänzt: » Wir müssen von den 4300 auf die 20, 30 kommen, die für ein Unternehmen tatsächlich relevant sind.«

Verbindung zu inneren Bedingungen

Sacher Paulus: »Das Advisory ist eine technische Beschreibung.Von einem technischen Finder,der einen technischen Sachverhalt beschreibt. Den Geschäftsführer interessiert aber, ob sein Netzwerk zwei Tage oder gar nicht ausfällt. Hat jemand schon mal die Verbindung zwischen Vulnerabilities und Security-Advisories und den Unternehmensbedingungen gesehen?« Es fehlt also die Übertragung externer Risikodefinitionen auf interne Prozesse,Applikationen und die Infrastruktur. Gibt es denn schon Ansätze, die einen externen Risikoindex mit internen Bedingungen abgleichen? Dazu Toralv Dirro: »Das können wir als Anbieter von entsprechenden Securitylösungen kaum machen.« Sacher Paulus ergänzt: »Da muss ein Mensch eingreifen und das einteilen.« Toralv Dirro: »Essenziell ist, dass die Systeme in dieser Schichtung Riskmanagement, Design und Betrieb vertikal bis nach oben wirklich durchmanagebar machen.« Klaus Lenssen:»Wir haben bereits angefangen, die Produkte mit Features auszustatten, um solche Prozesse überhaupt unterstützen zu können«.

Sacher Paulus: »Es existieren zwar Lösungen, die verschiedene Security-Events zusammenfassen, modellieren und auch nach Unternehmensrisiken klassifizieren. Es fehlt jedoch der Übergang in das Risikomanagementsystem.

Dort müssten dann die operativen und IT-Security- Risiken wie auch die physikalischen Maßnahmen zusammengefasst sein. Das ist natürlich Wunschdenken, denn von so einer Lösung sind wir noch fünf Jahre weg.« Toralv Dirro ergänzt:» Unsere Aufbereitungen und Betriebsverweise sind auf die eigenen Produkte beschränkt. Andere, generelle Lösungen wie HP-Open-View scheitern daran, dass sie entweder zu wenig mit Daten gefüttert werden oder zu komplex sind.Von der allumfassenden Konsole, die vom Technischen bis zum High-Level einen Überblick gibt, sind wir wirklich noch Jahre entfernt.« Ein ernüchterndes Fazit, werden Unternehmen doch auf Jahre hinaus mit dem Management-Problem allein gelassen.

pm@networkcomputing.de