RSA-Konferenz Europa in Nizza
Sicherheit fürs Kerngeschäft
Die RSA-Konferenz Europa hat sich als wichtiges Ereignis der Sicherheitsszene etabliert. Ein eindrucksvolles Programm an Vorträgen und Diskussionen am wunderschönen Veranstaltungsort Nizza samt perfekter Organisation machten die drei Konferenztage 2006 zu einem nachhaltigen Erlebnis.
Die RSA-Konferenz Europa fand in diesem Jahr vom 23. bis 25. Oktober statt
(2006.rsaconference.com/europe). 1100 Teilnehmer und sieben bis acht parallele Tracks mit 52
Fachvorträgen nebst Keynotes, Seminaren und Tutorials sowie einer Firmenausstellung garantierten,
dass jeder Besucher mit einer Fülle von neuen Ideen und Informationen heimreisen konnte.
Zwangsläufig kann der folgende Artikel nur einige Rosinen aus der Themenvielfalt herauspicken.
Einige Erwartungen waren an die Keynote von Ben Fathi (Microsoft) über die Sicherheit von
Windows Vista geknüpft. Leider hatte dieser Vortrag mehr Übersichtscharakter und brachte kaum Neues
für jemanden, der sich bereits mit dem Thema auskannte. Aufschlussreicher waren ein Interview mit
Stephen Toulouse von der Microsoft Security Technology Unit (STU) und danach ein Gespräch am
Microsoft-Stand der Ausstellung zum verschlüsselten Dateisystem Bitlocker. Im Ergebnis sind doch
Zweifel angebracht, ob der Schlüssel wirklich in der Hardware sicher versteckt wird: Auf jeden Fall
muss er während seiner Nutzung die Hardware (den TPM) verlassen, und die Frage ist, ob ihn ein
cleverer Hacker nicht auch selbst extrahieren kann. Mehr Details zu diesem Thema folgen in einem
separaten LANline-Artikel.
Unter den Keynotes war der Vortrag von Security-Guru Bruce Schneier wie immer kurzweilig. Für
mich neu war der Gedanke, dass gewissermaßen die Evolution auch Sicherheitsstrategien durchspielt
und dabei die erste übernimmt, die halbwegs funktioniert. Auf dem Sicherheitsmarkt scheint oft
Evolution dieser Art vorzuherrschen.
Die Router absichern
Ein Diskussionsforum versuchte sich der Frage zu nähern, was Sicherheit für das Business
bedeutet – wie erreicht man Kapitalrendite (ROI)? Die Hoffnung, für Software ähnliche Metriken wie
für materielle Güter zu definieren, wurde zerschlagen. Die Probleme beginnen bereits mit der
Definition, was beispielsweise überhaupt als Fehler einer Hard- oder Software anzusehen ist.
Außerdem werden Fehler erst nach ihrer Entdeckung zur abschätzbaren Größe, und selbst dann hängt es
noch von der Art der Nutzung und den Ansprüchen des Kunden ab, welche Bedeutung ein Fehler hat. So
bestimmen auch Qualifikation, Erfahrung und Tätigkeitsfeld des Käufers, welches Niveau von
Sicherheit von einem Produkt gefordert wird. Das trifft zwar auch für materielle Güter zu, doch
sind dort die Anforderungen ungleich konkreter.
Was die Kostenfrage angeht, so sind Schadenshöhen in der Regel nicht berechenbar, weil man die
nötigen Daten einfach nicht kennt – Analogien zu Versicherungen liegen hier nahe. Auch bleibt es
eine auf Intuition und Erfahrung basierende Entscheidung, wieviel in Sicherheit während der
Entwicklungsphase investiert werden muss (Code Review, Werkzeuge, Planung und so weiter). Als
schlechte Idee schien sich herauszukristallisieren, die Zahl der Support Tickets als Maßstab für
Qualität zu nehmen, denn diese hängt zu sehr von der Art der Kunden ab und sagt vor allem wenig
über die Auswirkung von Fehlern.
Insgesamt lieferte die Diskussion zwar nicht viel Neues, brachte aber etwas Klarheit. Man wird
auf diesem Gebiet weiterhin nur mit Größenordnungen arbeiten und sollte sich mehr Gedanken darüber
machen, wie man seinen Kunden erklärt, was ein Man-in-the-middle-Angriff ist.
Einen praxisnahen und interessanten Vortrag hielt Michael Behringer von Cisco. Er wies darauf
hin, dass die Sicherheit von Routern viel zu sehr vernachlässigt wird. Nicht nur durch Angriffe,
sondern auch durch Fehlkonfiguration entstehen leicht Tunnel in andere Netze. Während der Ausfall
eines Services bei Angriffen oder infolge von Konfigurationsfehlern sicherlich bemerkt wird, ist
dies bei "versehentlichen" Umleitungen nicht so. Behringer meint, dass nicht nur Intrusion
Detection wichtig ist, sondern auch das Aufdecken von Fehlkonfigurationen (wenigstens durch Loggen
der Änderungen von Konfigurationsdateien) und das Aufspüren ehlerhafter Arbeitsweisen in einem
System.
Es wird stillschweigend immer vorausgesetzt, dass jeder Router ausreichend sicher und seine
Software weit gehend fehlerfrei ist, kein unautorisierter Zugriff möglich ist, und dass
autorisierte Nutzer keine Fehler machen und auch nicht bösartig sind. Man fragt sich, welche
wirksamen Gegenmaßnahmen es hier gibt. Behringer schlägt vor:
Login-Versuche auf Routern sollten protokolliert werden,
alle Änderungen der Konfigurationsdateien auf Routern müssen in Logs
festgehalten werden,
Router dürfen mit Ausnahme des Routing-Protokolls und eventuell ICMP (Ping)
nicht erreichbar sein,
Router müssen individuell gesichert und ihre Arbeit muss überwacht werden
(dies ist am schwierigsten).
Teilweise lassen sich die Ziele erreichen, wenn kein Router von außen erreichbar ist. In der
Praxis allerdings lässt sich der Adressraum der Router oft kaum definieren, insbesondere in "
gewachsenen Netzwerken". Man benötigt im Grunde aber nur die Fähigkeit, Pakete durchzuleiten zu
(auch "Traceroute" funktioniert damit noch). Der Nachbar eines Routers sollte sich beim Kontakt
immer authentifizieren. Außerdem empfiehlt Behringer, die Kontrollschicht nicht auf IP zu stützen
und einen AAA-Server (Authentication, Authorization, Accounting) zu nutzen – schon deshalb, weil
dieser Logdateien produziert.
Social Engineering
Mit dem Problem des boshaften Administrators wird man am besten mittels "dual control" fertig,
im Deutschen bekannt als "Vier-Augen-Prinzip". Einen inhaltlich nicht ganz so gewichtigen, dafür
noch praxisnäheren Vortrag hielt Peter Wood von First Base Technologies
(www.fbtechies.co.uk) über die fünf wichtigsten Insider-Angriffe. An erster Stelle wurde zu
große Hilfsbereitschaft angeführt. Allzu oft verraten selbst privilegierte Nutzer Passwörter, nur
weil sie jemandem in einer Notlage glauben helfen zu müssen. Auf dem Gebiet des Social Engineering
erfahrene Angreifer nutzen dies aus. Ein sicheres Gegenmittel gibt es nicht, zumal kein Betrieb
ohne gegenseitige Hilfsbereitschaft funktionieren kann. Nur Awareness-Schulung vermag das Problem
zu mildern, indem sie Anwendern hilft, die Sicherheitsproblematik verstehen.
Nach wie vor werden außerdem stupide Passwörter für privilegierte Benutzerkonten vergeben und –
was weniger bekannt ist – in über 50 Prozent aller Fälle lautet dann das Passwort des Kontos adm324
ebenfalls "adm324". Der Referent nannte ein drei Milliarden Dollar schweres Fortune-500-Unternehmen
mit 26.000 Passwörtern, wovon 43 Prozent schwach waren. Das Programm "crack" brauchte 146 Sekunden
Rechenzeit, um dies festzustellen. Selbst die so leicht zu umgehenden Passwortrichtlinien wären
hier schon ein Fortschritt.
Auch der nächste Punkt sollte kein Thema mehr sein, dennoch präsentiert sich die betriebliche
Praxis oft geradezu als Paradies für bösartige Insider: Die Infrastruktur ist oft ungeschützt. Da
haben Nutzerkonten leere Passwörter, SNMP ist per Default aktiviert, der innerbetriebliche
Datenverkehr wird nicht chiffriert (denn die Bösen sitzen ja außen), Nutzerkonten werden nach
Kündigung eines Angestellten nicht gelöscht oder wenigstens ihre Passwörter geändert. Das lässt
sich durch eine klare Sicherheits-Policy ziemlich leicht abstellen.
Als vierten Punkt nannte Wood aktive, aber ungenutzte Dienste und das Nicht-Einspielen von
Patches. Auch das ist nichts Neues. Der letzte Punkt dürfte ebenfalls wohlbekannt sein: Laptops
sind nicht geschützt. Wie die Reaktion im Saal zeigte, war anscheinend nicht allen Anwesenden klar,
dass man Root-Passwörter leicht mittels einer Knoppix-CD zurücksetzen kann, wenn man physischen
Zugriff auf das Gerät hat. Setzt der Hacker oder Spion das Passwort nach seiner Aktion zurück, ist
er binnen weniger Minuten fertig und hat praktisch keine Spuren hinterlassen, außer vielleicht ein
paar Schuppen auf der Tastatur.
Ein weiteres Diskussionsforum beschäftigte sich mit der Praxis der
Zwei-Faktor-Authentifizierung, also dem Ausweisen gegenüber einem System unter Verwendung
spezieller Hardware-Tokens wie zum Beispiel Secur-ID von RSA. Der Sicherheitsgewinn ist ohne Frage
beträchtlich, und bei Risiken redet man meist von Phishing-Angriffen, gegen die auch solche
Hardware nicht schützt. Doch es gibt ganz praktische Probleme, die kaum erwähnt werden. Das
einfachste davon ist, dass man sein Token vergessen kann. Bei einer Umfrage im Saal, wem dies schon
passiert sei, hob sich ein großer Teil der Arme. Weiter ist es ein Problem, für jeden Anbieter ein
gesondertes Token mit sich herumzutragen und sich dafür gegebenenfalls noch eine gesonderte PIN zu
merken. Viele Nutzer mögen auch keine zusätzliche Hardware. Obendrein würden Updates einen
Firmwarewechsel bedingen, der aus Sicherheitsgründen nur vom Hersteller selbst vorgenommen werden
könnte. Auch die Zusatzkosten fallen an: Anwendungen sind zu modifizieren, ein Helpdesk muss
eingerichtet werden, die Schulung der Anwender und die Hardware selbst kosten Geld.
Eine Antwort auf die Frage, wie man mit verschiedenen Anbietern zurecht kommen soll, ist die so
genannten "federated authentication": In einem Token werden die Passwortgeneratoren für mehrere
Anbieter untergebracht. Ein solches Gerät ist der USB-Stick Stealth MXP von MXI, der zudem einen
Fingerabdrucksensor integriert (wobei die Frage ist, wie Anwender mit zu schwachen oder
abgescheuerten Papillen diese Geräte nutzen sollen). Sandisk bringt im November einen USB-Stick
heraus, der ohne Aufpreis Einmal-Passwort-Generatoren nebst Kryptoprozessor und verschlüsseltem
Dateisystem enthält.
Solche All-in-One-Lösungen wecken allerdings neues Misstrauen, wie die einzelnen Identitäten
sauber getrennt werden sollen: Welche ID wird denn nun bei der Authentifizierung wirklich gesendet?
Was erfahren die einzelnen Anbieter, die das Token bedient, voneinander? Muss für jeden Anwender
ein anderer Algorithmus implementiert werden? Hier erscheint das Upgrade-Problem besonders akut.
Eine Antwort könnte das Konzept "VIP" von Verisign (Verisign Identity Protection) sein. Hier
arbeitet das Token nach dem OATH-Standard (www.openauthentication.org). Die Token-IDs werden von
Verisign gehostet, wobei dieser Anbieter aber nicht als direkter Partner beim Endanwender auftritt,
sondern zum Beispiel eben Ebay. Der Anwender sendet seine Token-ID zusammen mit dem Einmalkennwort
dann an Ebay, und Ebay richtet eine (im eigenen Interesse anonyme) Anfrage an Verisign: Gehören
diese Token-ID und dieses Passwort zusammen, wurde es noch nicht gesendet? Damit sollten die
einzelnen Identitäten ausreichend gegeneinander geschützt sein, die Komplexität des Problems wird
in das Netzwerk verschoben. Wenn Kosten und Akzeptanz dieses Modells stimmen, könnte sich dieses
robuste Konzept durchaus durchsetzen.
Lesen Sie mehr zum Thema
