Vorschlag für eine Produktinnovation

Universelle Virenerkennung durch Zusatzhardware

Version 1.0/1.4, 05.01.2005

Hauke Laging, Grazer Platz 22, 12157 Berlin, Tel.: 030/32603660, mobil: 0172/7630883, E-Mail: hauke@laging.de
Student des Wirtschaftsingenieurwesens und Mitarbeiter des Lehrstuhls für Technologie- und Innovationsmanagement an der Technischen Universität Berlin.

Übersicht


Ausgangslage – das Problem des Kunden – Übersicht

Die Bedrohung durch Schädlinge aller Art wird immer größer – zumindest in der öffentlichen Wahrnehmung (die sich natürlich wieder ändern kann). Technische Gegenmaßnahmen wie Virenscanner sind zwar verbreitet, aber nicht völlig sicher. Lücken entstehen durch die teilweise nicht täglichen Aktualisierungen und die Möglichkeit mancher Schädlinge, Antivirensoftware gezielt zu deaktivieren.

Das grundsätzliche Problem insbesondere ahnungsloser Benutzer ist der Umstand, dass man dem Rechner leider nicht ansehen kann, ob er gerade "heil" und "vertrauenswürdig" ist, denn der Rechner kommuniziert mit dem Anwender nur über seine Bildschirmausgabe. Diese aber ist manipulierbar und muss im Zweifelsfall vom Anwender erst mal richtig interpretiert werden.

Ziel – Übersicht

Ich schlage vor, das Unsicherheitsproblem der Anwender durch eine Zusatzhardware zu mindern, die eine trivial verständliche Ausgabe aus einer kaum manipulierbaren Rechnerausgabe erzeugt. Hardware ist dabei auf die Erkennung von Virenbefall beschränkt, säubern kann sie einen infizierten Rechner nicht, aber das Wissen, wann das nötig ist, also die zusätzliche Sicherheit, dass der Rechner gerade "sauber" ist, dürfte für viele Anwender einen erheblichen Wert besitzen.

Dieses Produkt soll dabei Virenscanner nicht ersetzen, sondern ergänzen; außerdem kann es sie unterstützen, indem es ihre unbemerkte Deaktivierung drastisch erschwert.

technische Umsetzung – Übersicht

Realisierung

Die zusätzliche Erkennungssicherheit soll über die Prozessliste des Betriebssystemkernels erreicht werden. Unter "sicheren" Umständen soll der Kernel zuverlässig veranlasst werden, die aktuelle Prozessliste an externe Hardware auszugeben, wo die einzelnen Einträge geeigneten Überprüfungen unterzogen werden.

Dieser Ansatz basiert auf folgenden Annahmen:

  1. Die Möglichkeit, dass Viren usw. in der Lage sind, einen Betriebssystemkern zu manipulieren, wird als irrelevant angesehen.

  2. Eine sichere (also nicht durch Schädlingssoftware manipulierbare) Kommunikation zwischen externer Hardware und Benutzer auf der einen und dem Kernel auf der anderen Seite ist möglich.

  3. Die Identifizierung von Schädlingsprogrammen auf Basis des Pfads einer ausgeführten Datei ist praktikabel.

    1. Dies beinhaltet insbesondere die Möglichkeit, dass zulässige Programme überschrieben werden, um unter ihrem unverfänglichen Namen aktiv zu werden.

Softwareunterstützung

Die externe Hardware könnte die unbemerkte Deaktivierung von Antivirensoftware stark erschweren. Trivialerweise könnte die Hardware regelmäßig die Prozessliste anfordern und daraufhin überprüfen, ob die fragliche Anwendung gerade läuft. Dies ließe sich aber im Prinzip durch Überschreiben mit einem eigenen Programm aushebeln. Die Software könnte deshalb außerdem beim Start eine Zufallszahl generieren und diese in regelmäßigen Abständen an die externe Hardware schicken. Wenn ein Schädling es schaffte, die Antivirensoftware zu beenden, bekäme die externe Hardware diese Zufallszahl nicht mehr und könnte leicht über einen Timeout Alarm schlagen. Um diesen Mechanismus auszutricksen, müsste der Schädling

Beides dürfte, wenn es überhaupt machbar ist, die Komplexität der fraglichen Funktion in einem Schädling um mindestens zwei Größenordnungen in die Höhe treiben, so dass das Risiko als eher klein einzustufen ist.

Virenbeseitigung

Natürlich ist der Anwender nicht nur daran interessiert, zu erfahren, dass auf dem Rechner irgendwelche Prozesse ihr Unwesen treiben, sondern auch daran, diese loszuwerden. Wenn im Hintergrund eine Software läuft, bestünde die Möglichkeit, als Reaktion auf den Alarm die externe Hardware zu veranlassen, die kritischen Prozesse diesem Hintergrundprozess zu übermitteln, der sie dann killt und deren Dateien umbenennt, so dass sie beim nächsten Booten/Login nicht wieder automatisch gestartet werden können. Dass dieser Prozess korrekt läuft, kann die Hardware über den oben geschilderten Mechanismus (Softwareunterstützung) prüfen. Für den Fall, dass dieser Hintergrundprozess vorher bereits gekillt wurde, könnte man einen Treiber oder so was installieren, der nur schwer zu manipulieren (überschreiben, deaktivieren usw.) ist und sehr früh im Bootprozess aufgerufen wird. Nach dem von der Hardware angeforderten Reboot bekäme dieser Treiber die Information, welche Dateien umzubenennen sind. Diese bereits vorher zu starten, wäre mit einem zusätzlichen, erheblichen Aufwand verbunden.

Softwareüberprüfung

In kritischen Situationen (insbesondere bei der Virenbeseitigung nach dem Reboot) mag es angebracht sein, die Integrität der installierten Software sicherzustellen, auch wenn es theoretische Möglichkeiten geben mag, durch früher gestartete Prozesse auch eine korrekt installierte Software zu kompromittieren, ohne deren Dateien zu ändern. Dies könnte trivial mit einer bootbaren CD (z.B. Linux) geschehen. Die Software würde mit einer digital signierten Datei ausgeliefert, die die Prüfsummen der einzelnen Dateien enthielte.

mögliche Probleme

Kernelmodifikation

Das Kernproblem dieses Vorschlags ist natürlich, dass auf den Windows-Kernel nur Microsoft Zugriff hat. Es wäre zu überlegen, ob es ähnlich manipulationssichere Wege gibt, die Funktionalität zu implementieren (z.B. über Treiber).

Es stellt sich die Frage, welches Interesse Microsoft daran hätte, eine derartige Änderung vorzunehmen. Folgende Aspekte sprechen dafür:

sichere Kommunikation

Es muss sichergestellt sein, dass die Eingaben der externen Hardware ausschließlich vom Kernel kommen und die Ausgaben ausschließlich bei ihm landen. Dabei hilft möglicherweise TCPA. Ansonsten müsste irgendwie sichergestellt werden, dass Anwendungssoftware das Gerät nicht (in dieser Weise) adressieren kann. Schlecht wäre natürlich, wenn dazu jeder einzelne USB-Treiber geändert werden müsste. Mit etwas Glück kann dies von einer zentralen, zu Windows gehörigen Instanz erledigt werden. Problematisch ist dabei natürlich, dass Microsoft dann schon die zweite Änderung an Windows vornehmen müsste.

Die Anwendereingaben müssten sicher sein, d.h., dürften nicht abgefangen werden können. Es böte sich an, dafür den Affengriff zu verwenden, den Windows sowieso unabfangbar an eine eigene Komponente weiterleitet.

Die externe Hardware muss programmiert werden können, und das vom fraglichen Rechner aus. Irgendwie muss sichergestellt sein, dass dieser Umstand nicht von Schädlingen ausgenutzt werden kann. Ansätze wäre ein Hardware-Schreibschutz und ein Alarm, falls während dessen Aktivsein Schreibversuche unternommen werden. Dann müsste ein Schädling (seltene) zulässige Operationen abwarten und manipulieren, was unpraktikabel und kompliziert wäre.

Dem Anwender kann zuverlässig signalisiert werden, dass ein Problem vorliegt, nämlich über die externe Hardware. Schwierig wäre es dagegen, den Anwender sicher mit komplexeren Inhalten zu versorgen, etwa der dann stark nachgefragten Information, was denn nun zu tun sei. Das Dilemma: Natürlich kann man eine Software auf dem Rechner installieren, die diese Informationen parat hält, aber wie viel Vertrauen soll man der Bildschirmausgabe eines Rechners entgegenbringen, der gerade als (vermutlich) virenverseucht identifiziert wurde? Ein Ansatz wäre, dieses Programm vom Affengriff-Menü aus zu starten. Das wäre sicher, und die User würden es wohl kapieren.

Praktikabilität des Ansatzes

Vorausgesetzt, die genannten Schwierigkeiten werden gelöst, stellt sich die Frage, was man mit der Prozessliste in der externen Hardware anfängt. Folgende Ansätze sind denkbar:

  1. Man überprüft die beim Booten bzw. nach dem Login gestartete Software. Dies ist relativ einfach. Besonders gut geht dies bei Bürogeräten, deren Softwareinstallation sich nur sehr selten ändert. Andererseits werden Büro-PCs wohl eher als Heim-PCs mit täglich aktualisierten Virensignaturen versehen als Heimrechner. Wenn sich von einem zum nächsten Bootvorgang ein Prozess hinzukäme, schlüge die externe Hardware Alarm.

    Die spannende Frage ist, wie man ohne Supportterror dafür sorgen kann, dass problemlos Software installiert werden kann:

    1. Der untechnische Ansatz:
      Der Anwender weiß, dass er neue Software installiert hat und veranlasst die Hardware (per Knopfdruck), die neuen Prozesse in die Whitelist aufzunehmen. Das einzige Risiko liegt darin, dass sich zufällig ausgerechnet in dem Moment ein Schädling installiert hat. Eher unwahrscheinlich, vor allem aber nicht gezielt ausnutzbar. Diese Überlegungen gelten nicht für den Fall, dass der Anwender sich eine infizierte Software installiert. Dies setzt aber weitaus mehr Aktivität auf Seiten der Angreifer voraus und macht es wegen des zusätzlichen Zeitaufwands wahrscheinlich, dass der fragliche Schädling den aktiven Virensignaturen schon bekannt ist.

    2. überwachte Installation

      1. Man könnte von den Standard-Installationsprogrammen die installierten (ausführbaren) Dateien protokollieren lassen und diese dann an die Hardware übermitteln (und wieder stellt sich die Frage nach der Authenzität der Informationen).

      2. Man könnte die Benutzer Installationsroutinen von einem eigenen Programm starten lassen, das dann die Erstellung von Dateien anfangen und protokollieren kann.

    3. Mitgelieferte Whitelists
      Da Speicherplatz nicht so teuer ist, könnte man natürlich auch eine Menge Software der Hardware ab Werk bekanntmachen. Es stellt sich dann die Frage, ob man diese Liste durch Updates erweitern können will und wie diese Updates so realisiert werden sollen, dass sie nicht kompromittiert werden können (Signaturen?).

Unsicherheit des Entwicklungserfolgs

Das größte Risiko sehe ich darin, dass man im theoretischen Teil irgendwelche Fehler macht und sich irgendwann herausstellt, dass dieses System irgendwie, womöglich sogar relativ leicht, zu überlisten ist. Ob die Schädlingsprogrammierer das dann wirklich machen, ist natürlich eine andere Frage, die wohl auch von der Verbreitung abhinge. In dem Fall wäre aber damit zu Rechnen, dass irgendwann Tools für Schädlingsentwickler auftauchen, die schnell zu einer massenhaften "Immunisierung" führten.

Entwicklungskosten und -dauer

Zu den Kosten kann ich nichts sagen, aber die Entwicklungszeit könnte im wesentlichen mit der Realisierungszeit auf Seiten Microsofts parallelisiert werden, so dass das Produkt verfügbar sein könnte, sobald Microsoft die technischen Voraussetzungen im Massenmarkt geschaffen hat.

Kosten

Benötigt werden in dem Produkt folgende Komponenten:

Marktchancen – Übersicht

Zielgruppen, Preisspanne, Umsatz, Deckungsbeitrag

Zielgruppen wären

Der realisierbare Preis richtet sich nach dem vom Anwender wahrgenommenen Zusatznutzen. In der Praxis wird das System womöglich nie eingreifen, was an für sich kein Problem ist, denn Airbags bezahlt man ja auch in der Hoffnung, dass sie nie aktiv werden; die allermeiste "Arbeit" übernähme nach wie vor die Antivirensoftware. Aber der Anwender bekäme zusätzliche, für ihn leicht und zuverlässig erkennbare Sicherheit. Im Gegensatz zu Antivirensoftware müsste er die Hardware nur einmal kaufen, und die Beteiligung von Hardware sollte an sich schon eine höhere Zahlungsbereitschaft als bei einer Softwarelösung auslösen.

Ein Großteil der dem Produkt zuzurechnenden Umsätze wären zusätzlich verkaufte Softwarelizenzen (durch den PR-Effekt und den Einsatz mit dieser Hardware). Damit ist das Produkt für einen kleinen Anbieter besonders reizvoll.

Vermarktung

Auch wenn durch die (absehbar von Microsoft erzwungen) offene Schnittstelle andere Softwareanbieter die Dienste dieser Hardware nutzen könnten, täten sie dies möglicherweise erst mit Verzögerung, so dass die Anschaffung dieser Hardware einige Nutzer auf die Antivirensoftware des Anbieters umsteigen ließe, um den vollen Nutzen aus ihrer Anschaffung zu ziehen. Es böte sich an, "ohne Aufpreis" die eigene Software (möglicherweise als Demoversion oder sonstwie eingeschränkt) der Hardware beizulegen. Ein guter PR-Effekt ist dem Anbieter durch die Entwicklung einer ganz neuen Gerätegruppe sowieso gewiss.

Der Umgang mit PC-Peripherie kann wohl als "intensiveres" Erlebnis betrachtet werden als die Nutzung irgendwelcher Hilfsprogramme. Somit ist mit einer stärkeren Markenbindung als bei reinen Softwarekunden zu rechnen, auch wenn Software anderer Anbieter nach einiger Zeit kombatibel wäre und die Hardware in vergleichbarer Weise nutzen könnte. Für viele (gerade ahnungslose) Nutzer läge der Verdacht nahe, dass die Hardware mit der Software vom selben Anbieter am besten funktioniert.

Risiko Microsoft

Für den Stand der Wettbewerber zur Markteinführung wäre sicher die Zeit ausschlaggebend, die Microsoft bräuchte, um die technischen Voraussetzungen zu schaffen. Wenn die ein fertiges Konzept bekommen, abnicken, umsetzen und kurz vor Fertigstellung bekanntmachen, hätte man ein zeitlich begrenztes Monopol. Wenn Microsoft die Idee erst mit der ganzen Branche diskutiert, dann zwei Jahre liegen lässt und dann erst realisiert, sähe man gegen größere Anbieter und deren Marketingmöglichkeiten womöglich schlecht aus. Auch ließe sich der Imagegewinn des Innovationsführers schlechter einfahren, wenn zwischen Ankündigung und Produkteinführung viel Zeit vergeht.

Portfoliobetrachtung

Für einen Softwarehersteller ist es generell nicht unproblematisch, Hardware ins Programm zu nehmen, weil dadurch für einen relativ kleinen Teil des Geschäfts neues Know-How und neue Prozesse (Beschaffung, Vertrieb, Support) aufgebaut werden müssen.

Imitationsrisiko

Es ist davon auszugehen, dass es nach kurzer Zeit Imitate gäbe. Die Verwendung einer offenen Schnittstelle (sowohl zum Betriebssystem als auch zur Hardware) wäre vermutlich Voraussetzung für Microsoft, überhaupt in dieser Weise aktiv zu werden.

Alternativen

Zur Verwendung zusätzlicher Hardware gibt es bis zur Einführung von Trusted Computing keine Alternative, wenn das Problem überwunden werden soll, dass der Anwender der Maschine, die ja kompromittiert sein kann, nicht traut. Und ob Trusted Computing bei Anwendern, die immer als Superuser arbeiten, dieses Problem zu lösen vermag, sei mal dahingestellt.

Erweiterungen – Übersicht

Zusatzinformationen zu den Prozessen

Vielleicht kann man noch einen Mehrwert dadurch generieren, dass man den Kernel nicht nur den Pfad, sondern auch weitere Informationen über die laufenden Prozesse ausgeben lässt, etwa eine Prüfsumme der ausgeführten Dateien und Netzwerkaktivitäten (genutzte Sockets/Ports).

unterschiedliche Betriebsarten

Wenn man dem Gerät noch einen Auswahlschalter spendiert, könnte man manipulationssicher bestimmte Betriebsarten unterscheiden. So könnte man etwa eine gesonderte Whitelist anlegen, die die Programme enthält, die im angesicherten Modus laufen dürfen, falls der hilfreich wäre, um eine infizierte Maschine zu säubern, wenn man sich nur darauf verlassen könnte, dass


Änderungen am Dokument – Übersicht

1.1