Virtualisierung als Schutz vor schädlichen E-Mail-Attachments

Das Viren-/Trojanerrisiko durch Attachments soll dadurch wirksam ausgeschlossen werden, dass die Bearbeitung (Anzeige) der Dateien in eine spezielle virtuelle Maschine verlagert wird und der Benutzer sich ohne jedes Risiko für seinen Rechner anzeigen lassen kann, was die Datei enthält.

Ausgangslage das Problem des Kunden — Übersicht

E-Mail-Attachments sind eine zweischneidige Sache, einerseits nicht mehr wegzudenken, andererseits immer wieder Einfallstor für Schädlinge aller Art. Die Maßnahme, einem E-Mail-Programm die Möglichkeit zu nehmen, ein Attachment direkt zu starten, löst das Problem nicht: Wenn der Empfänger wissen will, was er da bekommen hat, speichert er den Anhang und startet ihn direkt. Das ist sogar schlechter als der Start aus dem Mailprogramm heraus, weil das System im letzteren Fall immerhin wissen könnte, dass die Quelle der Datei unsicher ist und entsprechend reagieren könnte.

Problembewusstsein

Ziel — Übersicht

Auch der ahnungslose User sollte bedenkenlos Attachments öffnen können, ohne damit Schaden anzurichten.

technische Umsetzung — Übersicht

Anforderungen

Realisierung

Schäden können wirksam vermieden werden, indem Attachments in einer Box ausgeführt werden. Man bräuchte also eine geeignete Windows-Installation in einer virtuellen Maschine, der man die fragliche Datei übergibt. In diese virtuelle Maschine (read only, temporäre Änderungen werden verworfen; also ein Snapshot) müsste man dann alles installieren, was man typischerweise zum Öffnen von Attachments benötigt: Bildbetrachter, Acrobat Reader, MS-Office(-Viewer).

Eine speziell daran angepasste virtuelle Maschine würde sinnvollerweise auch nur das intern geöffnete Fenster anzeigen, um dem Anwender möglichst weitgehend das gewohnte Bild zu bieten (d.h., er sollte von der VM nichts merken).

Einschränkung der Mailprogramme

Um diesen Mechanismus wirklich sicher zu machen, müsste man verhindern, dass das Mailprogramm andere Programme als diese virtuelle Maschine bzw. ihr Wrapperscript starten kann. Ob und wie (einfach) das realisierbar ist, hängt vermutlich vom jeweiligen Betriebssystem ab. Alternativ könnten die Mailprogramme eine Option bekommen, Attachments immer nur mit diesem speziellen Programm zu starten. Diese Änderung sollte annähernd trivial und zumindest für die Open-Source-Programme in kürzester Zeit einzurichten sein - sinnvollerweise auch auf Administratorebene, global für alle Benutzer. Allerdings dürfte hier mit Microsofts Kooperation zu rechnen sein, da die Virenplage deren größtes Problem ist, technisch wie imagemäßig.

Warnung bei verdächtigem Verhalten

Dem Anwender kann zwar nichts Ernstes passieren, aber da er die Datei oftmals in sein richtiges System übernehmen will, ist es sinnvoll, zumindest heuristisch zu prüfen, ob sie in Ordnung ist. Der Anwender sollte daher informiert werden, wenn irgendwas Kritisches passiert: Schreibvorgänge im Dateisystem, Leseversuche im Datenbereich des Benutzers, versuchte Internetverbindungen u.ä. Wenn nichts dergleichen passiert, kann die Datei kaum gefährlich sein - wenn sie nicht gerade einen Timer enthält, der diese "Quarantänezeit" überbrücken soll.

Derartiges gibt es aber schon bei anderer Software, so dass hier bezüglich der elenden Softwarepatente Vorsicht gefordert ist.

mögliche Probleme

Startzeit

Natürlich hätte dieser Umweg der Attachmentdarstellung gewisse Auswirkungen auf die Reaktionszeit des Systems. Es mag – auf entsprechend ausgestatteten Rechnern – dadurch etwas Abhilfe geschaffen werden, dass man diese Box im Hintergrund lädt, sobald das Mailprogramm läuft, und auch nicht komplett beendet, wenn der Nutzer das Fenster schließt, sondern lediglich die virtuelle Maschine "resettet" wird.

Erkennbarkeit durch Schädlinge

Wenn ein solches Produkt größere Verbreitung erreicht, wäre denkbar, dass Schädlinge prüfen, ob sie in einer Box gestartet werden und sich dann anders verhalten. Dies würde sich aber lediglich auf ihre Erkennung auswirken. Denkbar ist natürlich, dass das Ausbleiben einer Warnung den Nutzer dazu bringt, die Datei regulär zu öffnen. Daher wäre zu überlegen, wie man die Konfiguration dieser virtuellen Maschine mit einigen zufälligen Elementen "garniert", so dass sie der vom typischen Windows-User kaputtgespielten Installation ähnelt.

Allerdings wäre auch bei einer Nichterkennung noch fraglich, warum der Empfänger die Datei nach dem Ansehen speichern und im Hostsystem öffnen sollte. Dafür müsste der Inhalt zumindest interessant/relevant genug sein. Auch in dem Fall aber wird der Nutzer die Datei normalerweise nicht gleich wieder öffnen (wenn man ihn nicht zum Bearbeiten und Weiterleiten verleitet), so dass der hoffentlich vorhandene Virenscanner ein paar Tage Zeit gewinnt, sich hinreichend zu aktualisieren.

Zeitfenster / Restriktionen der virtuellen Maschine

Ohne geeignete Gegenmaßnahmen ließe sich auch eine virtuelle Maschine missbrauchen, etwa als Spam-Relay. Es wäre also zu überlegen, ob man sie auf Netzwerkebene komplett zu macht; dagegen scheint nichts zu sprechen. Wenn man Internetverbindungen zulässt, wäre zu klären, wie lange man die VM laufen lässt (um das Missbrauchsrisiko wenigstens durch Zeitbeschränkung in den Griff zu bekommen).

Deaktivierung

Wie bei jeder Schutzsoftware besteht auch hier das prinzipielle Risiko, dass die Software deaktiviert wird, wenn ein Schädling mit Administratorrechten es darauf anlegt. Dafür müsste er es aber erst mal ins Hostsystem schaffen. Dann aber wäre die Deaktivierung besonders unauffällig, da sie ja gerade vor dem Nutzer versteckt werden soll.

Investitionsbedarf und variable Kosten

Für dieses Produkt müsste lediglich eine bereits vorhandene Virtualisierungssoftware leicht abgewandelt werden; man könnte sie also kostengünstig weiterverwerten. Kannibalisierungseffekte wären nicht zu befürchten, wenn man mit geeigneten Maßnahmen (etwa die maximale Laufzeit der VM bis zum Reset) dafür sorgt, dass sich dieses Produkt nicht als Ersatz für das reine VM-Produkt eignet. Es sollte also nichts dagegen sprechen, eine wertvolle Technologie sehr günstig zu verkaufen.

Inzwischen gibt es von VMware wie auch Virtual PC kostenlose Versionen. Das sollte also nicht zum Problem werden.

Eventuell wären gelegentlich Anpassungen vorzunehmen, wenn sich zeigt, dass sich die Schädlingsprogrammierer auf das Produkt einstellen und versuchen diese Softwareumgebung als solche zu erkennen. Dagegen kann man insofern wenig tun, als die simulierte Hardware nicht änderbar ist. Man könnte aber eine Software ins gastsystem installieren, die entsprechende Zugriffe entdeckt. Was geht es eine Bilddatei an, welcher SCSI-Hostadapter im Rechner steckt?

Problematisch ist dann noch die Frage nach dem Gastsystem. Nicht alle Viewer gibt es auch für Linux. Vielleicht zeigt Microsoft sich kooperativ, was die nötige Windows-Lizenz angeht. Man kann in dem Fall kaum behaupten, dass ihnen dadurch irgendwelche Lizenzeinnahmen entgehen. Außerdem kann man dafür natürlich auch alte Windows-Versionen nehmen (angesichts des VM-Ressourcenbedarfs sowieso besser).

Marktchancen — Übersicht

vorhandene ähnliche Produkte

Die norwegische Firma Norman setzt bereits auf Sandbox-Technologie, allerdings mit einem anderen Ziel: http://www.norman.com/Virus/Sandbox/de

Von VMware gibt es eine Sandbox (auf Linux-Basis) für einen Webbrowser. Der fundamentale Unterschied zu diesem Vorschlag liegt darin, dass die gesamte betroffene Anwendung (hier der Browser) in der Box läuft und die Interaktion mit dem eigentlichen System dadurch erheblich erschwert wird. Bei einem Browser ist das zu verschmerzen, man speichert selten Webseiten. Für einen Mailclient ist das inakzeptabel, selbst bei der Verwendung von IMAP. Hinzu kommt, dass viele Anwender nicht irgendein Mailprogramm verwenden wollen und VMware schlecht eine vorkonfigurierte virtuelle Maschine mit Windows anbieten kann.

Vorteile der Innovation und ihr Gewicht, Aufwand-Nutzen-Verhältnis

Das Produkt böte drei Vorteile, die alle von erheblichem Gewicht wären:

Attachments könnten völlig sorglos geöffnet werden. Nie wieder Panik.
Attachments könnten nach der "Prüfung" im Rahmen des Öffnens relativ gefahrlos gespeichert werden; dies gilt eben auch für noch kaum bekannte Schädlinge, die die Virenscanner nicht erfassen.
Das Produkt funktioniert dauerhaft zuverlässig mit einem Mechanismus, es lebt – anders als ein Virenscanner – nicht von Updates.

Nachteile der Innovation

Portfoliobetrachtung

Zielgruppen

Vermarktung

Für die Nutzer des Hauptprodukts sollte diese Funktionalität sinnvollerweise kostenlos bereitgestellt werden. Für die wichtigsten Open-Source-Mailprogramme sollte man eine entsprechende Erweiterung entwickeln (lassen), sofern es nicht mit noch weniger Aufwand für das Betriebssystem an sich zu lösen ist. Die vorhandenen Nutzer von Virtualisierungssoftware sind der Gruppe der technisch kompetenten Nutzer zuzuordnen, die benutzen mehrheitlich sowieso etwas anderes als Outlook. So könnte man mit wenig Aufwand das Produkt, die Idee an sich erst mal bekannt machen, auch wenn die technisch versierten Nutzer nicht die Hauptzielgruppe darstellen.

Die Zeit, in der das Produkt von selbst ein wenig an Bekanntheit gewinnt, könnte genutzt werden, um entweder abzuwarten, dass Microsoft es mit seiner üblichen Geschwindigkeit schafft, Outlook anzupassen, oder selber eine betriebsystembezogene Lösung zu entwickeln, die dann für alle Mailprogramme funktioniert.

Erklärungsbedürftigkeit

Die Erklärungsbedürftigkeit gegenüber den technisch nicht so gut informierten potentiellen Kunden erscheint gering, da die sich selten für die genaue Funktionsweise von Software interessieren. Wer von denen weiß schon, wie ein Paketfilter ("Firewall") oder ein Virenscanner funktioniert? Was man bräuchte, wäre eine Botschaft, die zumindest den Eindruck vermittelt, man verstehe die technischen Zusammenhänge, um das nötige Vertrauen in die Leistungsfähigkeit des Produkts zu schaffen, auch wenn die sicher von der Computerpresse bestätigt wird.

Wenn man dem Anwender erklärt, dass ein ganzes Betriebssystem in diese Box eingesperrt werde, wird er wohl glauben, dass auch ein Virus es da nicht herausschafft.

Kosten

Ein derart neues Produkt sorgte sicher für einen gewissen Pressewirbel, so dass vergleichsweise wenig Werbung gemacht werden müsste.

Anders als das originale Virtualisierungsprodukt wäre bei einem solchen "DAU-Produkt" die Lokalisierung unerlässlich, wenngleich die schon wegen des extrem beschränkten Umfangs des Produkts und damit seiner Benutzerschnittstelle sehr harmlos ausfallen dürfte.

Preisspanne, Umsatz, Deckungsbeitrag

Das untere Ende der Preisspanne liegt sehr niedrig, da die Entwicklung des Produkts an sich kaum Kosten verursacht. Die Zahlungsbereitschaft der Nutzer läge wohl in der Größenordnung von Virenscannern. Man kann zwar argumentieren, dass dieses Produkt keine Updatekosten verursacht, aber dennoch werden die meisten nicht so viel dafür zahlen wie für einen Virenscanner, weil der dadurch nicht automatisch verzichtbar wird, dafür wäre die Erkennungsheuristik einfach zu unsicher.

Wäre das Produkt wirklich günstig, hätte es auf Grund seines hohen Nutzens und seiner Benutzerfreundlichkeit durchaus das Potential für eine sehr hohe Verbreitung. Dieses Ziel wäre auch Voraussetzung dafür, Firmen wie Microsoft zu einer Anpassung ihrer Software zu bewegen, weil die sich für 0,1% ihrer Kunden diesen Aufwand lieber sparen.

Lebensdauer

Imitationsrisiko, Barrieren gegenüber (potentiellen) Wettbewerbern

Als Wettbewerber auf dieser technischen Basis kommen nur Firmen in Frage, die ebenfalls über geeignete Virtualisierungsprodukte verfügen (oder sie lizensieren), auf denen sie aufsetzen können. Dass mal ein anderer technischer Ansatz aufkommt, der das Problem ähnlich wirksam löst, ist zwar durchaus möglich, aber billiger könnte der kaum sein, da die Kosten dieses Produkts sehr gering wären und ein späterer Wettbewerber sich – voraussichtlich ohne echten Mehrnutzen – einem gesättigten Markt gegenübersähe, so dass er schon auf Grund seiner Stückzahlen kaum einen Preiskampf anzetteln könnte.