![[externer Link]](../../../../images/link.gif)
www.dfn-cert.de/events/ws/2007/cfp.html verfügbar.Vor 10 Jahren startete mit der DFN-PCA ein Projekt, das Kryptographie populärer machen sollte – dies ist heute zweifellos geschehen. Allerdings sind weiter gehende Hoffungen, dass nämlich damit auch die Anzahl der Sicherheitsvorfälle abnehmen würde, nicht eingetreten. Oder vielleicht doch?! Womöglich gäbe es ja sonst noch viel mehr davon?
Abseits aller Spekulation stellt sich auf jeden Fall die Frage, warum kryptographische Verfahren in bestimmten Bereichen, in denen sie eine deutliche Verbesserung der Sicherheitslage bedeuten könnten, dennoch nicht eingesetzt werden. Ein vordergründiger Aspekt ist sicherlich: Anbieter und Betreiber scheuen den Aufwand, also die Kosten. Doch auch darüber hinaus bleiben Bedenken.
Die mangelnde Sicherung von Integrität und Authentizität der grundlegendsten Protokolle im Internet hat weitreichende Folgen. So gibt es bei der Namensauflösung im Domain Name System (DNS), die quasi bei jeder Verbindung gebraucht wird, keinen Schutz vor gefälschten Antworten und somit auch keine Garantie, dass man beim richtigen Server landet.
Abhilfe schafft DNSsec mit Kryptographie, um die Echtheit von DNS-Antworten zu bestätigen. Der Standard ist in verschiedenen Versionen seit den 90er-Jahren diskutiert und zuletzt im März 2005 in RFC 4033–4035 gefasst worden. DNSsec wird allerdings nicht angewendet. Einige Gründe für fehlenden DNSsec-Einsatz sind:
Diese Argumente sind zwar zutreffend, zeigen aber vor allem Defizite bei Herstellern und Anbietern. Dass trotz DNSsec Angriffsmöglichkeiten offen blieben, sollte wohl kaum als Argument gelten, die jetzige Situation nicht zu verbessern (würde z. B. der Anwendung selbst eine falsche Adresse untergeschoben, hilft auch die sichere Auflösung nicht – Angriffe auf das Routing blieben ebenfalls möglich). Und dass sich mit DNSsec auch neue Angriffsmöglichkeiten entwickeln würden, ist eine banale Erkenntnis, die auf jede "Rüstungsspirale" zutrifft.
Auch bei Datenpaketen und -verbindungen fehlen Sicherungsmechanismen. E-Mail-Nachrichten sind ein gutes Beispiel für die Folgen gefälschter Angaben: Es ist trivial, E-Mails unter fremdem Namen zu schreiben und auszuliefern. Und in aller Regel ist auch nur sehr schwer nachvollziehbar, welcher Rechner oder Benutzer für eine gefälschte Nachricht verantwortlich zu machen ist. Ebenso kann jeder Angreifer mit Zugriff auf Systeme des Transportwegs E-Mails und ihre Anhänge mitlesen, kopieren und womöglich manipulieren, sofern diese nicht durch Sicherungen der Anwendungsschicht geschützt wurden.
Abhilfe schafft hier die Verwendung von stark authentifizierten Kommunikationsprotokollen, wo immer dies möglich ist. Mit den aus dem Web-Browser bekannten SSL/TLS könnte ohne große Umstände auch der Versand von E-Mails (SMTP mit TLS, RFC 3207) und der Abruf von Postfächern (POP oder IMAP über SSL, RFC 2595) abgesichert werden. Auch für die Basisprotokollschicht IP gibt es mit den Sicherheitserweiterungen IPsec für IPv4 (RFC 4301ff) beziehungsweise IPv6 die Möglichkeit, alle Pakete zu verschlüsseln und durch digitale Signaturen auch zu authentifizieren (zu IPv6 s. u. a. RFC 2460 und <kes> 2005 #5. S. 12).
Einige Gründe für den Nicht-Einsatz dieser Maßnahmen sind:
Kryptographie konzentriert sich heute auf die Anwendungsebene. Verschlüsselungsprogramme für E-Mail (PGP/GPG oder S/MIME) und Authentifizierungslösungen für das Web (SSL/TLS) schieben jedoch dem Endanwender die Verantwortung zu, der damit meist überfordert ist. Natürlich ist sicheres Arbeiten damit möglich, aber dazu gehört viel Erfahrung – und wo wird die schon vermittelt?! Ratschläge, wie etwa in E-Mails keine Anhänge zu öffnen oder keine Nachrichten "von Fremden" aufzumachen, muten skurril an angesichts der offensichtlichen Hilflosigkeit, die sich darin ausdrückt.
Ein Technikansatz, der Anwendern die Verantwortung in einer Art und Weise aufbürdet, die sie überfordert, kann nicht hilfreich sein. In diesem Sinne muss auch endlich das "versus" in dem bekannten Ausdruck "Sicherheit vs. Bedienbarkeit" in ein klares "und" verwandelt werden.
Alle Betreiber müssen hierzu, auch wenn es Geld kostet und schwierig ist, eine sichere Infrastruktur schaffen. Dort müssen technische Lösungen eingesetzt werden, weil eben dort das technische Know-how verfügbar ist. Vorfälle müssen verhindert und Angriffspunkte geschlossen werden, ohne dass dies ein Anwender überhaupt bemerkt oder einfordern muss. Gleichzeitig müssen Anwender in die Lage versetzt werden, Software so zu bedienen, dass einerseits Sicherheit gegenüber Bedienerfehlern gegeben ist und andererseits kein falsches Sicherheitsgefühl aufkommt (à la "ich hab doch einen Viren-Scanner").
IT-Sicherheit kann hier aus anderen Bereichen noch sehr viel lernen: Auch ein Airbag ist technisch sehr komplex, die Sensorik muss exakt kalibriert sein und an den richtigen Stellen im richtigen Moment in Bruchteilen von Sekunden reagieren. Die Anwender wissen davon (in der Regel) nichts und müssen das auch gar nicht – solange keine Warnleuchte einen Fehler im Airbag-System anzeigt, ist alles okay. Auch der Sicherheitsgurt kann als Beispiel gelten: Einfache Bedienung, grundlegende Regeln, die bereits in der Fahrschule und sogar schon vorher durch andere Autofahrer gelehrt werden, ergeben ein erhebliches Plus an Sicherheit. Unfälle passieren dennoch; allerdings ist recht klar, wie die Gesellschaft urteilt, wenn kein Sicherheitsgurt angelegt war.
In diesem Sinne müssen auch wir Sicherheitsexperten uns umorientieren: nicht den Anwender zum Techniker erziehen, sondern die Infrastruktur absichern und bessere Systeme entwerfen, die Sicherheit einfach machen.
Mit dem "Call for Papers" zum 14. DFN-CERT Workshop "Sicherheit in vernetzten Systemen" haben die Vorbereitungen für diese Veranstaltung begonnen, die am 7. und 8. Februar 2007 in Hamburg stattfinden und sicherlich, wie in den Vorjahren, 300 bis 400 Teilnehmer aus der Praxis zusammenführen wird.
Der Workshop richtet sich an alle, die Interesse am Thema Computer- und Netzwerksicherheit haben. Im Vordergrund steht in jedem Fall der Praxisbezug; alle Teilnehmer sollen mindestens ein bis zwei Ratschläge erhalten, die sie am Arbeitsplatz oder zu Hause direkt anwenden können. Reine "Produktpräsentationen" sind dabei unerwünscht – Beiträge zu aktuellen Forschungsprojekten im Bereich Computer- und Netzwerksicherheit sind gerne gesehen. Wer glaubt, hier etwas beitragen zu können, ist eingeladen, seine Idee bis Ende August einzureichen! Details und Themenvorschäge sind über www.dfn-cert.de/events/ws/2007/cfp.html verfügbar.
Die <kes>-Rubrik CERT News berichtet über aktuelle Entwicklungen aus dem Umfeld von Computer Emergency bzw. Security Incident Response Teams (CERTs/CSIRTs). Betreuer dieser Kolumne ist Klaus-Peter Kossakowski ( www.kossakowski.de), der bereits ab 1992 mit dem Aufbau des ersten CERTs in Deutschland betraut und bis Juni 2005 Vorsitzender des internationalen Dachverbands FIRST ( www.first.org) war.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006#4, Seite 45
| 