Vorschlag für eine Produktinnovation
Version 1.4/1.1, 15.08.2006
Ausgangslage – das Problem des Kunden
Problembewusstsein
Nebenziele, positive Nebeneffekte, weitere Betroffene
Anforderungen, Realisierung, mögliche Probleme, Entwicklungskosten und -dauer, Unsicherheit des Entwicklungserfolgs, Investitionsbedarf und variable Kosten
vorhandene ähnliche Produkte, Vorteile der Innovation und ihr Gewicht, Aufwand-Nutzen-Verhältnis, Nachteile der Innovation, Portfoliobetrachtung, Zielgruppen, Vermarktung, Marktforschungsbedarf, Preisspanne, Umsatz, Deckungsbeitrag, Vertrieb, Lebensdauer, rechtliche Probleme, Imitationsrisiko, Barrieren gegenüber (potentiellen) Wettbewerbern, Alternativen, Chancen & Risiken zusammengefasst
Dieser Ansatz soll die zuverlässige und schnellstmögliche spätere Erkennung von Schädlingen ermöglichen, die aus irgendeinem Grund nicht erkannt wurden, als sie auf den jeweiligen Rechner gelangten. Dies soll erreicht werden, indem die Dateien vor ihrer Prüfung (also noch bevor ein Schädling die Chance hat, einen Virenscanner auszutricksen) auf einen anderen Rechner kopiert werden. Dort werden die Dateien nach jedem Update der Virensignaturen erneut geprüft, so dass Infektionen auch dann entdeckt werden, wenn der Virenscanner auf dem Client ausgehebelt wurde.
Virenscanner sind nicht in der Lage, jede Bedrohung zuverlässig abzuwehren und werden dies vermutlich nie sein. Mehrere Gründe sind dafür verantwortlich:
Aktualität der Virensignaturen
Mutation des bekannten Schädlings
Designfehler (Daten können am Virenscanner vorbeigeschleust werden)
Sicherheitslöcher (Virenscanner wird geknackt, Code eingeschleust)
Natürlich will der Rechnerverantwortliche so bald wie möglich wissen, dass der Rechner kompromittiert wurde. Das große Problem in dieser Hinsicht ist nun, dass man sich nicht darauf verlassen kann, dass der ausgetrickste Virenscanner mit Hilfe aktualisierter Signaturen oder einer verbesserten Heuristik diesen Schädling finden wird, weil er sich derart im System breitgemacht haben kann, dass er seine Enttarnung verhindern oder massiv erschweren kann (Rootkits, (teilweise) Deaktivierung des Virenscanners). Es ist also nicht einmal realitätsfern, dass ein Rechner monatelang unentdeckt infiziert ist, obwohl alle üblichen Sicherheitsmaßnahmen ergriffen wurden.
Dass Virenschutz immer ein Spiel mit dem Feuer ist, ist den meisten Administratoren und auch vielen Endanwendern klar.
Von den drei oben genannten Problemauslösern sollen durch den folgenden Vorschlag 1) und 2) eliminiert werden (3) und 4) können erschwert werden). Es soll verlässlich dafür gesorgt werden, dass bereits erfolgte Infektionen so früh wie mit den Mitteln eines normalen Virenscanners möglich erkannt werden. Durch eine Erweiterung des Vorschlags wäre die Erkennung einer dauerhaften Infektions sogar möglich, bevor die verwendeten Virenscanner dazu in der Lage sind.
Der Virenscanner soll in die Lage versetzt werden, mit Hilfe von Updates Schädlinge zu erkennen, ohne dass diese ihm dazwischenfunken können. Zu diesem Zweck wird der Wächter um eine Kopierfunktion erweitert: Jedesmal, wenn er eine Datei als nicht infiziert erkennt und freigibt, kopiert er sie an einen Archivserver (auf ein Netzlaufwerk oder an einen FTP- oder Was-auch-immer-Server) - natürlich vor der Freigabe. Für den Schutz vor den oben genannten Problemen 3) und 4) müsste die Datei noch vor der Prüfung (Archive vor dem Entpacken) kopiert werden. Dieser Kopiervorgang wird natürlich nur nach Änderungen an der Datei durchgeführt. Es würde also sinnvollerweise lokal die Information hinterlegt, welche Hash-Werte die Dateien beim letzten Kopieren hatten (oder sicherer: Man fragt den Server, um lokale Manipulationen auszuschließen). Diese Beschränkung der Kopiervorgänge auf das Nötigste ist für die Beurteilung des Ansatzes von großer Bedeutung.
Auf dem Archivserver laufen ein oder mehrere Virenscanner, jeweils im On-demand-Modus. Außerdem hält der Server die geänderten Dateien der letzten Wochen oder Monate vor. Die sinnvolle Länge dieses Zeitraums wird durch die maximale (angenommene) Zeitspanne zwischen dem Auftreten eines Schädlings und seiner Erkennung durch einen der verwendeten Scanner bestimmt. Der beliebigen Verlängerung stehen aber nur der Speicherbedarf und der Zeitbedarf beim Scannen im Weg.
Nach jedem Update der Signaturen oder der Scanengine wird ein On-demand-Lauf des jeweiligen Virenscanners ausgelöst. Da die fraglichen Daten auf dem Rechner nicht von Anwendungssoftware verarbeitet werden, besteht keine Gefahr, dass der Rechner infiziert wird. Es besteht lediglich das Risiko von Sicherheitslücken im Virenscanner selber, vor allem der Handhabung von Archiven. Dieses Risiko kann möglicherweise systematisch reduziert werden; siehe die Erweiterungsmöglichkeiten am Ende dieses Dokuments.
Wenn nun eine infizierte Datei gefunden wird, ist klar, von welchem Rechner sie kam und wann die Infektion stattgefunden hat. Vor allem erfolgt diese Entdeckung zum frühesten realistischerweise möglichen Zeitpunkt.
Durch einen Nebeneffekt lässt sich feststellen, dass der Virenscanner nicht mehr aktiv ist (allerdings nicht umgekehrt mit Sicherheit sagen, dass er korrekt arbeitet; der Test ließe sich also austricksen). Wenn der Rechner läuft, aber keine Anfragen mehr an den Server schickt, weiß man, dass irgendwas nicht stimmt. Natürlich kann ein Schädling, der den Virenscanner ausgehebelt hat, nach dem Zufallsprinzip harmlose Daten schicken. Man könnte solches Verhalten entdecken, indem man bekannte Dateien oder E-Mails auf den Rechner schleust und dafür sorgt, dass sie aufgerufen werden. Wenn dann nicht diese Daten an den Server gemeldet werden, wurde der Virenscanner deaktiviert.
Performancebeeinträchtigung gering halten
Die Änderung am Wächter wäre – abgesehen von den unten aufgeführten Problemen – recht einfach. Er muss um die Kopierfunktion (und – wenn man möchte – die Hash-Speicherung) erweitert werden.
Auf Serverseite muss sichergestellt werden, dass mehrfache Übertragung derselben Datei keine früheren Versionen überschreibt. Das wäre über SMB, FTP und sicher auch andere Protokolle möglich, indem jede neue Instanz des gestarteten Serverdienstes ein neues, leeres Verzeichnis als einziges Ziel von Schreibzugriffen bekommt. Selbst wenn sich das mit Standardsoftware nicht machen ließe, wären die nötigen Quellcodeänderungen sicher gering. In den Ordner würden dann zwei Dateien kopiert: eine mit dem Pfad auf dem Client und die eigentliche Datei bzw. deren Veränderungen.
Um weitestmöglich auszuschließen, dass ein Schädling diesen Mechanismus unterläuft, indem er den laufenden Wächter knackt und eine unverfängliche Datei an seiner Stelle überträgt (oder die Übertragung ganz unterbindet), muss das Kopieren synchron erfolgen: Erst nach erfolgreichem Abschluss des Kopierens darf der lokale Zugriff auf die Datei erlaubt werden. Das hat natürlich grausige Folgen für das Zeitverhalten der Anwendungen aus Anwendersicht. Allerdings ist das Kopieren – wie das normale Scannen – nur beim ersten Lesen und nach Veränderungen nötig. Beim ersten Lesen könnte die Netzwerkübertragung gleich als erstes begonnen werden, um die Latenz zu verringern, und bei Veränderungen bräuchte man nur die veränderten Bereiche übertragen. Dies ginge allerdings nur, wenn die Datei so neu ist, dass der Server sie noch hat (und nicht nur noch – siehe unten – ihren Hash). Wenn die Datei auf der Whitelist des Servers steht (siehe unten) und einen passenden Hash hat, müsste sie nicht übertragen werden.
Das Problem der kopierbedingten Verzögerungen lässt sich ganz drastisch entschärfen, indem nicht die gesamte Datei synchron übertragen wird, sondern lediglich ihr Hash. Die Datei selber kann dann später kopiert werden, ohne dass der Anwender davon merklich beeinträchtigt wird. Zur weiteren Minimierung sollte zunächst versucht werden, den Hash per UDP zu verschicken. Die ganze synchrone Transaktion bestünde dann aus nur zwei IP-Paketen, deren Bearbeitung man auf dem Server leicht Priorität einräumen könnte. Um dem – eher theoretischen – Problem zu begegnen, dass dieser Schutzmechanismus durch manipulierte Rechner im Netz ausgehebelt wird (address spoofing), könnte die (Ein-Paket-)Antwort des Servers aus einer Art digitalen Signatur bestehen. Den gemeinsamen Schlüssel dafür könnten Wächter und Server beim Hochfahren des Clients aushandeln (und ggf. periodisch neu, wie bei SSH). Ein Sicherheitsproblem besteht da nicht, da es auch einem Virus, das sofort nach der Übermittlung des Hash die Kontrolle über den Rechner übernimmt, nicht möglich wäre, den Server zu täuschen. Bekommt er keine Datei, schlüge er Alarm. Bekommt er eine manipulierte (virenfreie), stellte er das über den Vergleich mit dem Hash fest.
Durch die Kommunikation mit dem Server kann der lokale Virenscanner sogar beschleunigt werden (gegenüber der heutigen Situation!). Dateien werden immer wieder geprüft, weil es sein könnte, dass die seit der letzten Prüfung hinzugekommenen Signaturen etwas finden. Nicht notwendigerweise ist dabei jede Software so clever, nur gegen die hinzugekommenen Signaturen zu testen, zumal man dafür für jede Datei vermerken müsste, wann sie zuletzt geprüft wurde. Der Archivserver kennt fast alle Dateien, die in Umlauf sind, und prüft diese gegen die neusten Signaturen. Wenn also eine Datei dem Virenserver schon bekannt ist, braucht sie nicht mehr geprüft zu werden. Man sollte deshalb ein paar hundert Megabyte RAM auf dem Archivserver zum Cachen der Hashwerte der vorhandenen Dateien verwenden. Der Client würde dann vor der Prüfung den Hash an den Server schicken, und der Server würde mit seiner Empfangsbestätigung die Information mitschicken, ob die Datei schon bekannt ist. Man kann während der Wartezeit mit der Prüfung beginnen, um die Latenzzeit für die wenigen Fälle zu verringern, in denen die Datei dem Server nicht bekannt ist. Die Prüfung kann in den meisten Fällen vorzeitig abgebrochen werden, sobald die Bestätigungsmeldung vom Server eintrifft. Wenn man dagegen lieber CPU-Zeit sparen möchte, verzögert man die lokale Prüfung bis zum Eintreffen der Rückmeldung. Das ergibt vor allem dann Sinn, wenn der Rechner in der Zeit sinnvollen Aktivitäten nachgehen kann (was man wiederum der Prozessliste entnehmen kann).
Wenn im Extremfall die Rückmeldung des Servers schneller kommt, als die lokale Überprüfung abgeschlossen werden kann (unter Berücksichtigung der prüfungsrelevanten, also neuen, Signaturen und der Opportunitätskosten der CPU-Zeit), dann ist ein Client unter Verwendung des Archivservers sogar schneller!
Natürlich ist für diesen Aspekt die Latenz der Netzwerkübertragung von größter Bedeutung. Aus diesem Grund können folgende Maßnahmen hilfreich sein:
Verwendung unterschiedlicher Netzwerkinterfaces für die Hashübertragung und das Kopieren der Dateien, um die Anzahl der Kollisionen (auf Ethernetebene) bzw. die Pufferzeiten (in den Switchen) zu minimieren.
Deaktivieren der ARP-Zugriffe durch festes Eintragen der Mac-Adresse des Servers auf den Clients (und der Clients auf dem Server).
Kommunikation direkt über Ethernetpakete statt auf IP/UDP-Ebene (eliminiert das ARP-Problem).
Das Limit für die Belastbarkeit des Servers wird durch die zeitlichen Abstände der Updates gesetzt. Die Durchläufe sollten nicht mehr Zeit in Anspruch nehmen als diese. Dabei hat die schnelle Versorgung der Netzwerkverbindungen wegen der Latenzen auf den Clients natürlich höchste Proirität. Die Serverperformance kann auf zwei Wegen verbessert werden: durch Verringerung der zu scannenden Datenmenge und durch eine Reduzierung der nötigen Tests.
Wie bereits eingangs erwähnt, erscheint es wenig sinnvoll, Dateien ein halbes Jahr vorrätig zu halten, weil nicht mir Schädlingen zu rechnen ist, die so lange von keinem Scanner erkannt werden. Dementsprechend würde man alle Dateien, deren Alter das selbstgewählte Sicherheitslimit übersteigt, auf dem Server löschen und lediglich ihren Pfad und Hash behalten.
Es ist natürlich sinnlos, Dateien immer wieder gegen dieselben Signaturen zu testen. Deshalb ist es wünschenswert, für jede Datei zu vermerken, wann sie zuletzt geprüft wurde und die Signaturen, die älter sind als der letzte Testzeitpunkt, beim Scan wegzulassen. Dabei muss nur zwischen den beiden Status alt und neu unterschieden werden. Da bei jedem Durchlauf alle Dateien geprüft werden, ist nur wichtig, zu wissen, ob eine Datei beim letzten Scan bereits auf dem Archivserver vorhanden war. Wenn ja, werden nur die neusten Signaturen auf sie angewendet, ansonsten alle. Und da der Kunde absehbarerweise mehrere On-demand-Scanner installieren will, sollte man irgendwie dafür sorgen, dass das auch bei den Konkurrenzprodukten klappt. Sofern das Format der Dateien bekannt ist, muss man sich einfach nur merken, an welchem Datum eine bestimmte Signatur hinzukam.
Darüber hinaus könnte man sich eine Whitelist für bekannte Dateien zulegen, die nach aktuellem Wissensstand keine Schädlinge enthalten können - wenn das relevant viele sind (oder häufig auf sie zugegriffen wird). Dazu könnte etwa die Registry gehören sowie alle Dateien unterhalb einer kritischen Größe.
Um den Ansatz nicht zu untergraben, muss man eigentlich auch alle gelöschten Dateien über den Beobachtungszeitraum hinweg archivieren. Dagegen könnte man argumentieren, dass ein Virus zwar seine Ursprungsdatei löschen kann, sich aber dann anderswo einnisten muss, wenn es sich nicht selber deinstallieren will (ein unrealistisches Szenario). Da ein aktiviertes Schädling aber den lokalen Virenscanner sabotieren kann, sollte man sich darauf nicht verlassen. Dies mag man optional gestalten und dem Anwender die Wahl lassen. Sollte ein derartiges Problem bekannt werden, ließen sich die Archivserver immer noch leicht umschalten.
Völlig unpraktikabel ist es natürlich, Logdateien jedes Mal zu kopieren, wenn eine Zeile angehängt wird. Da Logdateien aber wohl kaum für Schadsoftware missbraucht werden können, kann man diese auf die Whitelist setzen. Die Herausforderung liegt dann darin, die (Nichtstandard-)Logdateien alle automatisch korrekt als solche zu erkennen.
Große, häufig geänderte Dateien mag man inkrementell speichern, wobei es sehr vorteilhaft wäre, wenn man die einzelnen Versionen nicht komplett wiederherstellen müsste, um sie zuverlässig scannen zu können.
Bestimmte Dateien, die "garantiert" virenfrei sind, könnte man – mit ihrem Hash – auf eine Whitelist setzen, so dass der Speicherplatz (und Scanaufwand) gespart wird. Das wäre etwa die gesamte Standardsoftware: Windows, Office, Acrobat, Mozilla – was eben auf mehreren Rechnern installiert ist. Allerdings bräuchte man deren Hashes natürlich über alle (verwendeten) Sprachversionen und Patchlevel. Software fällt – solange sie nicht aktualisiert wird – sowieso irgendwann aus dem Beobachtungszeitraum heraus. Die Whitelist hätte also vor allem den Zweck, nicht ständig bei Updates (sinnlose) Schübe an Speicherbedarf zu bekommen. Es bietet sich an, einen sauberen Rechner aufzusetzen und auf dem die gesamte Software zum Vergleich zu installieren. Solange an dem Rechner nicht gearbeitet wird, wäre er nicht virengefährdet. Alternativ zum Speichern lediglich der Hashes könnte man auf dem Archivserver auch einen Speicherbereich festlegen, der (zeitsparend) von den Virenscans ausgenommen wird und dort die Whitelist-Dateien ablegen. Diese Whitelist für Standardsoftware könnte natürlich auch vom Anbieter gepflegt werden, was den Aufwand der Kunden erheblich reduzierte. Sollte dann doch mal eine neue Office-Version mit Viren ausgeliefert werden, bekäme zumindest der Anbieter das mit und könnte über ein Update Alarm schlagen (also das Whitelisting der betroffenen Hashes verhindern).
Dieselbe Datei von mehreren Clients würde man natürlich nur einmal speichern. Das betrifft insbesondere die Daten, die auf Fileservern liegen und eventuell als temporäre Dateien auf den Clients erzeugt werden. Man könnte auf dem Archivserver gelegentlich einen Prozess niedriger Priorität starten, der nach Duplikaten sucht. Angesichts der Menge an Dateien erscheint es sinnvoll, nicht nur über die Hashes, sondern auch über die Dateigröße zu indizieren.
Der gesamte Speicherbedarf (und damit auch Scanbedarf) ergibt sich damit aus:
|
den gesamten lokalen und auf den Fileservern gespeicherten Daten |
|
|
plus |
die gelöschten Dateien |
|
plus |
die alten Versionen veränderter Dateien (aber eventuell nur die veränderten Teile) |
|
plus |
die auf mindestens einem Rechner installierte Software |
|
minus |
alle Dateien, deren Datum der Löschung oder der letzten Änderung aus dem gewählten Beobachtungszeitraum herausfällt |
|
minus |
alle Dateien von der Whitelist |
|
minus |
soweit bisher mitgezählt – alle Duplikate |
Je nach Nutzerverhalten landet man am Ende vermutlich bei 10-50% der Kapazität der Fileserver.
Was nicht passieren darf, ist, dass der Kopiervorgang einen Dateizugriff auslöst, der wiederum einen neuen Kopiervorgang zur Folge hätte. Dies kann wohl nur passieren, wenn die Netzwerksoftware aktualisiert wird – aber auch das muss möglich sein. Da wäre es hilfreich, sich nicht auf andere Software zu verlassen, sondern diese in den Virenscanner zu integrieren. Mit seinen eigenen Updates sollte er keine Probleme bekommen. Ein weiterer Ansatz zur Reduktion dieses Problems ist, mehrere Protokolle zu unterstützen, so dass man bei Kollisionen ausweichen kann. Dafür muss natürlich sichergestellt sein, dass nie bei beiden gleichzeitig solche Situationen eintreten.
Ein erhebliches Problem ist der Umgang mit Situationen, in denen die Netzwerkanbindung ausgefallen ist. Im LAN sollte so etwas natürlich nicht passieren, aber wenn der Archivserver mal den Abgang probt, steht das gesamte Netz. Das kann nicht Sinn der Sache sein. Aus praktischen Gründen hat man kaum eine andere Wahl als in diesem Fall das Kopieren asynchron durchzuführen. Damit schafft man zwar ein Sicherheitsloch, weil der Scanner geknackt werden könnte, bevor das Kopieren ausgeführt wurde, aber immerhin hat der Schädling keine Möglichkeit, diese Netzwerkprobleme zu provozieren, so dass dieses Risiko tragbar erscheint. Diese Problematik betrifft natürlich insbesondere den Bootvorgang, bei dem naturgemäß (anfangs) keine Netzwerkverbindung zur Verfügung steht.
Man sollte auf die Möglichkeit redundanter Systeme von Archivservern achten.
Es ist zu prüfen, ob gegen dieses System ein DoS-Angriff möglich ist. Dafür müssten Angreifer die Clients lediglich riesige Datenmengen erzeugen lassen und/oder sehr große Dateien immer wieder sporadisch ändern. So etwas würde man aber schnell erkennen und den jeweiligen Rechner unschädlich machen können.
Abgesehen von einigen Details zur Lösung der genannten Probleme ist die Aufgabenstellung insgesamt nicht sonderlich komplex. An das GUI eines Virenscanners reicht sie sicher nicht heran. Die konkreten Kosten kann ich nicht abschätzen, aber das Projekt erscheint in dem Sinne risikolos, als das technische Ziel auf jeden Fall erreicht werden kann.
Auf Serverseite könnte man (modifizierte) Open-Source-Software einsetzen. Die stünde dann zwar auch den anderen zur Verfügung, aber die müssten erst noch ihre Wächter anpassen. Da das ganze Konzept keine wirklich große technische Herausforderung darstellt, täte man sich mit den höheren Kosten einer Servereigenentwicklung keinen Gefallen. Insbesondere kann es den Nachfolgern vergleichsweise egal sein, ob ihr Produkt leicht imitierbar ist, da sie in erster Linie gegen das Erstprodukt antreten. Da wäre es natürlich hinderlich, wenn der Imitator wesentlich geringere Kosten hätte, weil er sich den Aufwand einer Eigenentwicklung spart. Außerdem wäre sein Produkt in kürzerer Zeit entwickelt.
Ein Fileserver mit mehreren On-Demand-Scannern leistet ganz Ähnliches. Die Scanner auf dem Server sind sicher (bis auf Sicherheitslücken im Scanner, wenn die Dateien Exploits enthalten). Dieser Ansatz ist insofern umfassender, als die Scanner auf dem Fileserver nur Infektionen von Dateien finden können, die auf deren Netzwerklaufwerke oder in beispielsweise Benutzerprofile geschrieben werden. Es gibt Schädlinge, die sich über Netzlaufwerke verbreiten, aber da man so die Entdeckungswahrscheinlichkeit maximiert, ist das nicht unbedingt clever. Nicht alle Schädlinge werden sich so verhalten. Außerdem ist nicht unbedingt (je nach Rechtelage der Datei) klar, von welchem Benutzer, geschweige denn PC aus die Infektion vorgenommen wurde.
Rein praktisch hat ein Fileserver auch nicht die Ressourcen, um ständig On-demand-Scanner laufen zu lassen – da ja jedesmal alle Dateien geprüft werden müssen. Außerdem erfolgt dort keine Versionierung, die aber unverzichtbar ist, wenn nicht ein Schädling auf triviale Weise seine Spuren verwischen können soll.
Die Gewissheit, über Infektionen so schnell wie möglich informiert zu werden, ist Unternehmen sicher einiges wert. Man könnte rechtlich so weit gehen, zu sagen, dass diese relativ einfache Maßnahme unter Haftungsaspekten verlangt werden kann. Entsprechend dem überschaubaren Aufwand könnte man diese Software günstig anbieten, und ein, zwei ausgemusterte Fileserver haben die meisten übrig bzw. stellen niemanden vor eine große Herausforderung. Damit ist die Ausgangslage für eine große Verbreitung im Segment der Unternehmen ab einer kritischen Größe (ab der IT professionell wird) sehr gut.
Einwenden kann man die geringe Wahrscheinlichkeit so eines Vorfalls, die möglicherweise aus Erfahrungswerten abgeschätzt werden kann. Andererseits steht der geringen Wahrscheinlichkeit ein geringer technischer Aufwand gegenüber, so dass man mit dem Aufpreis so weit runtergehen kann, bis die Kunden ihn akzeptieren, sollte das wirklich zum Problem werden.
Den Geschwindigkeitsvorteil gegenüber herkömmlichen Scannern und die Möglichkeit, auch unbekannte Schädlinge zu entdecken, dürften aber als erheblicher Mehrwert anerkannt werden.
Der wesentliche (potentielle) Nachteil ist die Performancebremse auf den Clients, wobei diese vor einem abschließenden Urteil in der Praxis untersucht werden sollte, da auch das Gegenteil denkbar ist.
Aus eigenem Antrieb werden sich wohl nur größere Unternehmen so etwas zulegen. Aber da die Installation dieses Archivservers nicht kompliziert sein muss und das Problem jedermann einleuchtet (auch dem Laien), sind kleinere Unternehmen nicht generell als Zielgruppe auszuklammern.
Die Vermarktung könnte über den Hinweis laufen, dass dieser Nutzen nur auf wesentlich aufwändigere Weise (ständige Checks von einem sauberen Bootmedium aus) erreicht werden könnte, also de facto bisher nicht zur Verfügung steht.
Schwierig wird die Vermarktung sicher durch den Aspekt, dass die meisten Kunden ihre aktuellen Virenscanner bereits für einige Zeit im voraus bezahlt haben und auch deshalb nur ungern wechseln werden. Ideal wäre die Möglichkeit, verbreitete Wettbewerbsprodukte so zu manipulieren, dass sie mit diesem System arbeiten können. Ob das geht und den Aufwand lohnt, vermag ich nicht zu beurteilen. Der Ansatz wäre wohl, einen zweiten Hook für die Dateisystemzugriffe zu installieren - nach dem anderen Scanner. Aber nicht ohne Grund heißt es, dass man nur einen Wächter gleichzeitig laufen lassen kann.
Wenn man den Server als OSS implementierte, hätte das zur Folge, dass man für diese Technik quasi einen Standard setzt, und das wiederum hätte ein höheres Vertrauen der Zielgruppe in den Bestand dieser Technik zur Folge. Den technischen Standard vorzugeben, hat einen langfristigen Imagegewinn zur Folge.
Da nicht absehbar ist, dass Virenscanner irgendwann mal selber gegen Kompromittierung immun werden, ist ein prinzipielles Veralten des Produkts ebenfalls nicht absehbar.
Da wie geschildert der technische Aufwand überschaubar ist, werden die Wettbewerber so etwas schnell nachbauen, wenn sie den Ansatz für wirtschaftlich vielversprechend halten.
Der große Vorteil des ersten ist einerseits der Imagegewinn, andererseits die Möglichkeit, begriffsprägend tätig zu werden, also sowohl für den Markennamen als auch den Gattungsbegriff. So besteht die Chance, dass der Markt den Pionier noch lange mit dieser Innovation verbindet und so ein langfristiger Imagegewinn entsteht.
Die einzige erkennbare Alternative ist das häufige Scannen von einem sicheren Medium aus, etwa einer CD.
Die große Chance liegt darin, als erster ein Produkt anzubieten, dass alle haben wollen. Diese Monopolphase bietet sich für eine Werbekampagne auch für die normalen Produkte an. "Weltneuheit" liest sich immer gut, auch wenn es einen (als Privatanwender) nicht betrifft.
Naheliegende oder bereits vorgebrachte Einwände:
Auf die eine oder andere Weise verfügt der Archivserver über die Hashes aller Dateien, die auf einem Rechner sein sollten (vielleicht mit Ausnahme derer, die nur geschrieben, aber noch nicht gelesen wurden und derjenigen von der Whitelist). Eine "sichere" Prüfung des Rechners wäre also extrem viel schneller als mit einem klassischen Scanner auf CD, weil man auf der Boot-CD gar keinen Virenscanner mehr bräuchte, sondern nur noch ein Programm, das alle Pfade und Hashes an den Archivserver übermittelt. Taucht dabei eine Datei auf, die der Archivserver gar nicht kennt, dann muss der Wächter deaktiviert oder geknackt worden sein (wenn er nicht absichtlich für manche Dateien deaktiviert wurde). Allerdings könnten unbekannte Dateien dann zwecks sofortiger Prüfung auf den Server kopiert werden (oder lokal geprüft werden, wenn die CD einen Virenscanner enthält). Man könnte sogar – ganz unabhängig vom Vorhandensein eines Archivservers – Hashes für Standardsoftware auf solchen CDs hinterlegen, um so unnötige Prüfungen zu vermeiden.
Man könnte eine Boot-CD entwickeln, die die Anwender einfach im Rechner lassen. Wenn sie zum Feierabend ihren Rechner herunterfahren, schalten sie ihn nicht aus (bzw. können das gar nicht mehr), sondern starten ihn neu. Das System von der CD kontaktiert den Archivserver und fragt ihn, ob es starten oder von der Festplatte booten soll. Abends würde es selber starten und nach erfolgreichem Abschluss den Rechner ausschalten. So schafft man mehr Sicherheit ohne großen Aufwand für den Anwender. Natürlich könnte man auf diesem Weg auch die Korrektheit der Virenscannerinstallation prüfen (Registryeinträge usw.). Dem steht nur entgegen, dass die Administratoren wohl nur ungern die Bootreihenfolge auf ein Wechselmedium ändern. Die Umschaltung könnte auch über einen Bootmanager erfolgen, wobei der keine absolute Sicherheit vor Manipulationen böte.
Wenn ein Schädling das System derart unterwandert, dass der die Kopiervorgänge unterbindet oder manipuliert, dann könnte er durch diesen Abgleich gefunden werden (auf dem System, nicht in einer konkreten Datei, weil durchaus Dateien mit bekanntem Hash infiziert sein können (was das Ausgangsszenario der ganzen Idee ist) und vom Schädling veränderte Dateien ihn nicht enthalten müssen), obwohl keiner der Virenscanner ihn erkennt. Der Verlauf der Ereignisse sähe dann so aus:
Ein Schädling gelangt auf einen Client.
Aus irgendeinem Grund wird er nicht erkannt.
Die infizierte Datei wird korrekt auf den Archivserver kopiert, aber auch dort erst mal nicht erkannt.
Der Schädling deaktiviert oder manipuliert den Wächter, damit die Folgeaktion keinen Alarm auslöst.
Der Schädling nimmt Manipulationen am System vor, etwa, um sicherzustellen, dass er beim Booten/Login gestartet wird.
Wenn ein Virenscanner solche Aktivitäten bemerkt, könnte er misstrauisch werden, auch wenn er keinen Schadcode erkennt. Deshalb erscheint es aus Sicht der Malware sinnvoll, den Wächter zu deaktivieren.
Der Schädling "spielt Wächter" und simuliert die üblichen Aktivitäten, um keine aufmerksamkeit zu erregen.
Im Normalfall würde der Schädling irgendwann auf dem Archivserver entdeckt.
Der Abgleich per anderem Bootmedium deckt die Manipulation auf.
komplett überarbeitet
ergänzt: Absatz Marktchancen / Vorteile der Innovation und ihr Gewicht, Aufwand-Nutzen-Verhältnis
ergänzt: Absatz Erweiterungen