Spotlight on Security: Der Fluch des False-Positive

26. Februar 2020

Security News

Von David Harley

Wann ist ein False Positive (FP) wirklich ein False Positive? Wie viel Sorgfalt sollten Security-Anbieter aufwenden, um sie zu vermeiden oder schlimmstenfalls zu beheben. Warum sind Sie so wichtig?

Nun, beginnen wir mit einer Definition - eigentlich mit zwei Definitionen. Es gibt zwei große Erkennungsprobleme, für die alle von AV-Comparatives getesteten Security-Produkte anfällig sind (auch wenn einige Marketroids bei der Werbung für ihre eigenen Produkte anderer Meinung sind): False-Negatives und False-Positives Ergebnisse.

Eine False-Negative liegt vor, wenn ein Security-Produkt etwas Bösartiges - wie das Vorhandensein von Malware - erkennen soll, aber daran scheitert ein bösartiges Objekt oder eine bösartige Aktivität zu erkennen. Dies ist ein Beispiel dafür, was in der statistischen Testtheorie als Fehler vom Typ 2 bekannt ist. Formal könnte man sagen, dass die Nullhypothese "Es liegt keine bösartige Aktivität vor" fälschlicherweise bestätigt wird. Weniger formell würde man sagen: "Meine Security-Software hat kein bösartiges Muster entdeckt".
Eine False-Positive (oder Fehler vom Typ 1) tritt auf, wenn dieselbe Nullhypothese fälschlicherweise abgelehnt wird. "Meine Security-Software behauptet, dass es sich bei dieser Datei um Malware handelt, aber das ist sie definitiv nicht!"

Ein False-Negative bzw. eine fehlende Erkennung ist natürlich von Bedeutung. Wie sehr hängt von mehreren Faktoren ab, z.B. davon, wie weit die echte, aber unentdeckte Malware verbreitet ist (es muss nicht unbedingt Malware sein, aber bleiben wir bei dem, was ich am besten weiß!) und welche Auswirkungen sie auf ein betroffenes System hat. In der Security-Branche wird diese Auswirkungsmetrik oft als Kritikalität bezeichnet, die als das Ausmaß definiert werden kann, in dem Malware (oder auch eine FP) die Nutzererfahrung beeinträchtigen könnte.

Security und Kompromittierung

Lassen Sie mich Ihnen dazu- wenn Sie nicht in der Security-Branche tätig sind, kennen Sie es vielleicht nicht - das CIA-Tripod- (oder Triad-) Modell erklären:

Vertraulichkeit
Integrität
Verfügbarkeit

Alle drei Komponenten sind für die Sicherheitsimplementierung wichtig (klar), aber man kann realistischerweise nicht erwarten, dass alle drei Komponenten zu 100 Prozent erfolgreich sind. Betrachten wir Marcus Ranum's "Ultimately Secure DEEP PACKET INSPECTION AND APPLICATION SECURITY SYSTEM". Ranum will damit sagen, dass es man ein Gerät völlig sicher machen kann, indem man sein Stromkabel und das Kabel, das es mit dem Internet verbindet, durchtrennt, aber das reduziert seine Funktionalität auf null Prozent. Für eine Einzelperson oder In der realen Welt eines Unternehmens ist die Verfügbarkeit wohl die wichtigste Komponente des CIA-Triad, aber die Erreichung der Verfügbarkeit macht die vollständige Vertraulichkeit und Integrität weniger erreichbar. Wenn Sie jedoch nicht über jede Datei oder jedes Objekt verfügen, auf das Sie ein Anrecht haben, haben Sie weder perfekte Sicherheit noch ein tragfähiges Geschäftsmodell. Aber Perfektion ist nicht wirklich eine Option. Und FPs sind im Grunde ein unbeabsichtigter Angriff auf die Verfügbarkeit.

"Wolf" rufen!

FPs sind auch deshalb ein Problem, weil ein Produkt, das häufig saubere Dateien als bösartig kennzeichnet, dazu führen kann, dass die Nutzer den Erkennungen des Produkts nicht mehr trauen (was nicht überraschend ist): In dieser Situation ist es nicht ungewöhnlich, dass eine legitime Erkennung ignoriert wird und der Benutzer echte Malware auf die Whitelist setzt, so dass diese mit möglicherweise verheerenden Folgen ausgeführt werden kann.

Gefährlichkeit, Malware und FPs

In den Tagen der Viren - verzeihen Sie mir ein kurzes Schwelgen in Nostalgie - tat die meiste virale Malware eigentlich nichts anderes, als einen kleinen Bereich des Arbeitsspeichers und/oder des Speichers zu belegen. Den meisten Virenschreibern ging es mehr um den Ruhm, einen erfolgreichen (vorzugsweise weit verbreiteten) Virus geschrieben zu haben, als darum, Schaden anzurichten oder Geld zu erpressen, und einige (vor allem Mike Ellison alias Stormbringer) waren sogar entschuldigend und hilfsbereit, wenn ihre Kreationen spürbare Schäden verursachten. Selbst in den letzten Jahren gab es (seltene) Beispiele von Ransomware-Autoren, die ein gewisses Maß an Reue (oder kalte Füße) zeigten. Abgesehen davon gibt es natürlich unzählige Beispiele für Viren und neuere Malware, deren Auswirkungen beträchtlich sind (vom Morris-Wurm über Michelangelo und CIH bis hin zu Ransomware und Wipern, die sich als Ransomware tarnen, aber rein destruktiv sind). Diese Auswirkungen werden von der Security-Branche wie nach ihrer Gefährlichkeitdefiniert, die man informell als das Ausmaß des verursachten Schadens definieren könnte. Glücklicherweise kann es vorkommen, dass selbst Malware, die eigentlich zerstörerisch wirken soll, ihre Ziele nicht erreicht, weil die Umgebung, in der sie sich befindet, es nicht zulässt, dass sie ausgelöst wird, oder weil die Nutzlast dort einfach nicht wie erwartet funktioniert.

Man könnte meinen, dass ein False Positive überhaupt keine Rolle spielen sollte, da selbst echte Malware nicht unbedingt signifikante Auswirkungen hat. Leider ist das nicht der Fall. Tatsächlich treffen viele der Szenarien, in denen Malware erheblichen Schaden anrichten kann, auch auf FPs zu: nicht wegen des falsch diagnostizierten Objekts selbst, sondern wegen der Maßnahmen, die die Security-Software ergreift, um zu verhindern , dass sie keinen Schaden anrichtet. In solchen Szenarien ist das Heilmittel meist schlimmer als das Symptom. Wenn man an die Folgen von Malware denkt, kommt einem in der Regel zuerst der Schaden bzw. die Gefährlichkeit in den Sinn, aber es gibt auch noch andere Faktoren, die eine Rolle spielen:

Wie verbreitet das FP und das falsch diagnostizierte Objekt ist (Prävalenz)
Wie einfach ist es, einen Schaden zu beheben (Wiederherstellbarkeit)
Die Art der Benutzerumgebung, in der sich der Vorfall ereignet. (Art des bestehenden Schutzes, Richtlinienfragen usw.)

Ausgehend von diesen weit gefassten Kategorien könnten FP-Probleme eine breite Palette von Themen umfassen.

Manche Fehlalarme führen dazu, dass ein einzelnes System nicht mehr gebootet werden kann oder dass es zwar gebootet werden kann, aber keine Verbindung zu einem lokalen Netzwerk oder zum Internet herstellen kann. Schwerwiegende Vorfälle dieser Art sind selten (aber wenn sie auftreten, wird viel darüber berichtet). Dennoch kann kein verantwortungsbewusster Anbieter garantieren, dass es seinen Kunden nicht irgendwann einmal passiert. Es ist schon vorgekommen, dass Security-Produkte den ordnungsgemäßen Start von Windows verhindert haben, weil Systemdateien wie svchost.exe fälschlicherweise als schädlich eingestuft wurden. (Manchmal sind sind solche Dateien natürlich wirklich durch Malware mit ähnlichen Auswirkungen kompromittiert, aber das ist ein anderes Thema). Manchmal beschränken sich diese Vorfälle auf esoterische Kombinationen von Betriebssystemversion und Region, aber ein weit verbreiteter Vorfall, der von einem großen Anbieter ausgeht, ist nicht nur unangenehm (oder schlimmer) für den Kunden, sondern schadet auch dem Ruf des Anbieters und damit der Marktfähigkeit seiner Produktpalette erheblich.

Dann gibt es FPs, die den Zugang zum Internet erlauben, aber den Zugriff auf Dienste wie E-Mail oder Webdienste verhindern. Eines meiner Lieblings-FPs aller Zeiten war der E-Mail-Filter, der alle E-Mails blockierte, die einen bestimmten Buchstaben des Alphabets enthielten. Hassen Sie es nicht auch, wenn das Alphabet Sie zu spammen beginnt? ("Die heutige Dienstverweigerung ist präsentiert von dem Buchstaben P und der Zahl 7.”

Gesperrter Zugang zu solchen Seiten (für den Einzelnen oder Unternehmen) ist oft mit der korrekten oder falschen Diagnose von Malware verbunden, die von bestimmten URLs angeboten wird. Leider ist das Auftreten sowohl von Typ 1 und Fehler des Typs 2 sind symptomatisch für ernsthafte und anhaltende Probleme mit der Art und Weise, wie Kriminelle Malware über Websites verbreiten.

Frage: Wann ist eine bösartige URL keine bösartige URL?

Antwort: Sehr oft, wenn die Gruppe, die die bösartigen URLs verwaltet, Maßnahmen ergreift, um die Wahrscheinlichkeit zu verringern, dass diese URLs von Security-Forschern entdeckt und als bösartig eingestuft werden. Offensichtliche Beispiele für solche Gegenmaßnahmen sind, wenn eine Website es vermeidet, Malware an IP-Blöcke zu senden, von denen bekannt ist, dass sie mit Strafverfolgungs- oder Sicherheitsunternehmen in Verbindung stehen, oder an IP-Adressen im selben Block, die immer wieder auf die bösartige Website zurückkehren.

Generische Erkennung

Es gibt viele andere Techniken, die dazu dienen, die Erkennung von bösartigem Code zu erschweren, und die vielleicht besser bekannt sind. In den meisten Fällen sprangen frühe Viren von System zu System, ohne den Kerncode zu verändern, der sie funktionstüchtig machte, so dass sie relativ einfach zu erkennen waren. Heutige Malware ist ganz anders: Ausgefeilte Programmiertechniken machen es leicht, den Code immer wieder zu verändern, zum Beispiel indem sie ihn bei jeder Iteration anders verschleiern. Was tun die Sicherheitsunternehmen, um solche Gegenmaßnahmen zu verhindern?

Tatsächlich hat die Anti-Malware-Branche schon vor Jahrzehnten damit begonnen, sich von dem simplen "signaturbasierten" Modell "Erkenne einen Virus (oder was auch immer), analysiere einen Virus, setze einen Virus auf die schwarze Liste" zu entfernen. Schließlich verfügen selbst die größten Labors nicht über die Ressourcen, um alle täglich eingehenden Samples individuell und mit visueller Kontrolle durch einen Menschen zu bearbeiten. (Daher liegt der Schwerpunkt heute auf dem Einsatz maschineller Intelligenz bei der Verarbeitung von Samples.) Jedes Mal, wenn die Hersteller eine Erkennung hinzufügen, versuchen sie, einen Code zu generieren, der eine große Anzahl ähnlicher Muster abfängt, und nicht nur eine kurzlebige Iteration von bösartigem Code. Leider kann dieser verallgemeinerte oder generische Ansatz so weit gehen, dass eine ganze Klasse von Objekten blockiert wird, von denen viele völlig unbedenklichen Code enthalten. Dafür gab es im Laufe der Jahre viele Beispiele, aber ein interessantes Beispiel, auf das AV-Comparatives gestoßen ist, lautet wie folgt:

Aufspüren versus Blockieren: ein Beispiel

Nehmen wir ein Word-Dokument, das ein Makro enthält, das eine legitime und signierte Anwendung startet. Word-Dokumente sind natürlich seit dem ersten weit verbreiteten Makrovirus in den 1990er Jahren ein Streitpunkt. Schon damals waren Makros ein legitimes und potenziell außerordentlich nützliches Werkzeug, insbesondere für Geschäftsanwender. Zu Beginn der Entwicklung von Makroviren schoss jedoch mindestens ein Anbieter über das Ziel hinaus, indem er alle Dateien "säuberte", indem er die Ausführung von Makros deaktivierte (und dann verkündete, dass er das Problem der Makroviren "behoben" habe). Heutige Makros sind viel schwieriger zu kompromittieren als in den berauschenden Tagen des WM/Concept-Virus: Microsoft und andere Akteure in der Security-Branche haben große Anstrengungen unternommen, um sie zu rehabilitieren. Und natürlich gibt es viele Geschäftsszenarien, in denen der Start einer App nicht nur legitim, sondern sogar unerlässlich ist. Dennoch hat AV-Comparatives eine Reihe von Produkten gefunden, die verdächtige Dateien als verdächtig kennzeichnen und/oder die Ausführung von unschuldigen Dateien per Makro blockieren.

Delegieren der Entscheidung

Ist dies ein False-Positive? Nun, nicht, wenn ein einigermaßen gut informierter Systembesitzer sich - ausdrücklich oder einfach durch Akzeptieren einer Voreinstellung - für eine der folgenden Positionen entschieden hat:

Die Verantwortung für die Entscheidung zu übernehmen, ob ein vom Produkt als verdächtig markiertes Objekt oder ein Prozess tatsächlich bösartig ist.
Die Annahme, dass die Wahrscheinlichkeit, durch ein falsch positives Ergebnis einen größeren Schaden zu erleiden, so gering ist, dass es gerechtfertigt ist, einige False-Positives hinzunehmen.

Aber nur wenige Computerbesitzer - oder sogar Systemadministratoren - sind Experten in der Kunst des Malware-Managements und begnügen sich oft damit, die Standardeinstellungen eines Security-Anbieters zu akzeptieren, in der Hoffnung, dass diese Vorgaben ihnen den heiligen Gral der Anti-Malware-Technologie bieten: 100% Schutz vor 100% Malware und eine vollständige Abwesenheit von False-Positives. Leider wird im Marketing für Security-Produkte häufig der Irrglaube verbreitet, dass 100% Erkennung und 0% FPs kompatible Zielesind. Das Angebot von Standardeinstellungen, die zumindest einen Teil der Verantwortung für das "Erkennen" von Malware auf den Kunden abwälzen, ist einer der Versuche der Anti-Malware-Industrie, einen akzeptablen Kompromiss zu erzielen.

Das Gute, das Schlechte und das Unbestimmte

Hier ist ein weiteres Beispiel von AV-Comparatives, bei dem es sich wohl um einen False-Positive handelt. Vielleicht haben Sie nie über den Prozess der Softwareinstallation nachgedacht, sondern ihn einfach als einen Prozess akzeptiert, der abläuft, wenn Sie eine Anwendung zum ersten Mal erwerben, und sehr wahrscheinlich nur die angebotenen Standardeinstellungen akzeptiert.

Als ich ein junger (OK, junggebliebener) aufstrebender Programmierer war, erforderten viele Programme - manchmal sogar recht umfangreiche - keinen nennenswerten Installationsprozess. Sobald das Programm auf Ihrem System war, mussten Sie es nur noch ausführen und vielleicht ein paar Entscheidungen über Standardeinstellungen treffen.

Da die Betriebssysteme jedoch immer ausgefeilter und komplexer geworden sind, ist auch der Installationsprozess selbst für die einfachsten Anwendungen komplexer geworden, und es gibt eine ganze Klasse von Installationsprogrammen, die die Installation von anderer Programme vereinfacht. Solche Programme enthalten in der Regel Funktionen wie Komprimierung und Verschlüsselung, mit denen sich das Vorhandensein bösartiger Software-Routinen verschleiern lässt. Die Security-Industrie hat viele Jahre lang von der Möglichkeit profitiert, bestimmte Installationsprogramme, Packer und Crypter (Verschlüsselungssoftware) zu identifizieren, die ausschließlich mit Malware in Verbindung gebracht wurden. Wenn das Paket jedoch manchmal (wenn auch nur selten) von legitimer Software verwendet wird und diese legitime Software als bösartig diagnostiziert wird, haben wir ein Problem. Welche Maßnahmen ein Produkt auch immer ergreift, wenn es ein solches Paket entdeckt, es liegt bereits nahe an der Grenze zwischen allgemeiner Erkennung und False-Positives.

AV-Comparatives berichtet jedoch über etwas, das noch problematischer ist. Die Tester haben Installationsroutinen mit der NSIS-Skriptsprache erstellt oder kompiliert, die aus offiziellen Open-Source-Projekten stammen, und dabei festgestellt, dass mehrere Produkte saubere Installationsprogramme als bösartig erkennen. Man kann wohl davon ausgehen, dass nicht alle Benutzer von Security-Software wissen, dass ihr Produkt diese allgemeine Erkennung nach Klassen und nicht nach spezifischem bösartigem Code beinhaltet. Und unschuldigen Code als bösartig zu diagnostizieren, ist eine durchaus brauchbare Definition eines False-Positive.

Jenseits der Kritikalität

Die kritischste Auswirkung auf ein System umfasst in der Regel mehr als eine der Kategorien, in die FP fallen können: z.B. die Behinderung des Zugangs zu Anwendungen, zu Daten wie Unternehmensdatenbanken, zu Netzen und zu Geschäftsprozessen, die sich auf die Fähigkeit des Einzelnen, des Finanzinstituts oder des Einzelhändlers auswirken, eine Transaktion durchzuführen. Die genauen Einzelheiten hängen jedoch von vielen Faktoren ab. Und die Kritikalität ist nicht der einzige Faktor, der zur Definition der Schwere eines FPs herangezogen wird: Die Prävalenz ist ein weiterer Faktor, der allerdings schwer zu messen ist. Wenn Sie zu Hause das Internet nutzen und alles über Ihren Laptop oder sogar Ihr Smartphone oder Tablet erledigen, kann die Unfähigkeit, dieses Gerät zu nutzen, verheerender sein als der Funktionsverlust eines oder mehrerer PCs in einem Unternehmensnetzwerk. Vorausgesetzt, dass Vermögenswerte wie Softwarelizenzen und Geschäftsdaten leicht ersetzt oder wiederhergestellt werden können - wie es sein sollte , in einer gut verwalteten IT-Infrastruktur.

Verantwortung übernehmen

Wie die Wiederherstellbarkeit spielt auch die Umgebung eine wichtige Rolle: Einige Umgebungen sind viel toleranter gegenüber False-Positives als andere, und - zumindest im Prinzip - sind die Kunden besser in der Lage zu entscheiden, wo sie auf diesem Kontinuum stehen als die Anbieter. Aber es ist ein kompliziertes Thema, das viele Unternehmen und die meisten Einzelpersonen nur schwer verstehen können, so wünschenswert es auch wäre, dass Menschen und Organisationen im Allgemeinen ein besseres Verständnis für das Malware-Problem hätten.

Schlussfolgerung

Heutzutage ist die Rolle der Security-Tester, die den Kunden helfen, ein besseres Verständnis für das Thema zu erlangen, wichtiger denn je, und gut durchgeführte False Positive Tests sind ein wichtiger Bestandteil der von ihnen angebotenen Dienstleistungen. Aber auch ihre Fähigkeit, den Anbietern die Notwendigkeit aufzuzeigen, die Bedürfnisse ihrer Kunden besser zu verstehen.

Geringe Prävalenz, geringes Interesse

Einer kleiner Entwickler erstellt eine App, die von Security-Produkten als bösartig oder zumindest verdächtig eingestuft wird. Der Entwickler weiß in der Regel nichts davon, bis sich seine Kunden darüber beschweren und/oder sie eine Fehldiagnose auf VirusTotal oder einer ähnlichen Quelle sehen. Wir wissen, dass ein weit verbreiteter und weithin veröffentlichter Fehlalarm dem Ruf des Security-Anbieters schadet, aber in diesem Fall sind der Ruf und die Marktfähigkeit des App-Anbieters bedroht, und der Security-Anbieter sieht dies möglicherweise als weniger wichtig an. Wenn der Entwickler versucht, den/die Security-Anbieter zu kontaktieren, um das FP zu beheben, wird berichtet, dass die Anbieter möglicherweise so reagieren:

Da die fehlerhaft gekennzeichnete Datei nicht weit verbreitet ist, wird das Problem nicht angegangen, da der Aufwand für die notwendigen Änderungen am Security-Produkt in keinem Verhältnis zur Größe des Problems steht. Es stimmt, dass die Lösung eines solchen Problems erhebliche Umstrukturierungen nach sich ziehen kann. Die Industrie ist sehr darauf angewiesen, die Erkennungen so allgemein wie möglich zu gestalten, um die automatische Erkennung zu maximieren, so dass die Änderung und das Testen einer komplexen Erkennung zur Beseitigung eines False-Positives alles andere als trivial sein kann. Die Korrektur muss sorgfältig implementiert werden, nicht nur, damit sie mit dem nächsten Build wirksam bleibt, sondern auch, damit sie keine Erkennungsprobleme verursacht, wenn andere Dateien gescannt werden. Die betroffene Datei einfach auf die Whitelist zu setzen, ist eine unbefriedigende Alternative, da bei jeder Neuerstellung der Anwendung die Möglichkeit einer weiteren FP besteht. Außerdem besteht die Möglichkeit einer Sicherheitsverletzung durch eine kompromittierte Version der Anwendung.

Sollte die geringe Verbreitung einer FP einen Anbieter wirklich von jeglicher Verantwortung für die Genauigkeit seiner Erkennung entbinden? Wir erwarten vielleicht nicht, dass ein Security-Produkt jede Bedrohung auf Anhieb erkennt, aber wir erwarten, dass solche Produkte aktualisiert werden, um Bedrohungen zu erkennen, sobald sie bekannt werden. Auch wenn man erwarten könnte, dass die Anbieter Informationen über neue Bedrohungen für sich behalten, um sich einen Wettbewerbsvorteil zu verschaffen, so tauschen seriöse Anbieter doch Informationen über solche Bedrohungen aus und stellen das Wohl der Allgemeinheit über ihre eigenen Wettbewerbsinteressen. Es gibt auch keinen offiziellen Schwellenwert, unterhalb dessen es niemanden interessiert, wenn Informationen nicht weitergegeben werden. Ist es unzumutbar, von den Anbietern zu erwarten, dass sie auf die FP gleichermaßen reagieren, unabhängig davon, wie weit sie verbreitet sind?
Sie vermarkten ein Security-Produkt für Unternehmen, so dass es für sie keine Rolle spielt, wenn Nischenprodukte wie (unschuldige) Spiele falsch diagnostiziert werden, da von solchen Apps nicht erwartet wird, dass sie rechtmäßig in einer Unternehmensumgebung eingesetzt werden. Abgesehen davon, dass diese Erwartung fast schon absichtlich naiv klingt, ist es doch nicht die Aufgabe eines Security-Entwicklers, bekannte Schäden am Ruf eines anderen Entwicklers zu ignorieren, selbst wenn dieser Entwickler nicht zu seinen Kunden gehört oder ein wichtiger Akteur auf seinem eigenen Markt ist? Dies ist ein Problem, wenn ein einzelner Anbieter FPs einsetzt, aber es gibt noch ein weiteres Problem, wenn andere Anbieter diesem Beispiel folgen und nicht auf VirusTotal auftauchen wollen, weil sie Malware nicht erkennen, die von mindestens einem konkurrierenden Anbieter erkannt wird.

Darin spiegelt sich ein seit langem bekanntes Problem wider: Einige Anbieter haben tatsächlich Erkennungen "gestohlen", ohne sie zu überprüfen, was zu einem "Schneeballeffekt" führt, bei dem eine potenzielle Fehldiagnose aufgrund der Anzahl der Anbieter, die das so genannte bösartige Objekt falsch diagnostizieren, immer häufiger als korrekt angesehen wird. Kaspersky hat dieses Problem vor zehn Jahren durch die experimentelle Erstellung harmloser ausführbarer Dateien aufgezeigt, von denen einige absichtlich als bösartig eingestuft wurden, und die Dateien in VirusTotal hochgeladen. Kaspersky berichtete daraufhin, dass innerhalb von 10 Tagen 14 andere Anbieter dieselben Dateien als bösartig eingestuft hatten, offensichtlich ohne die Dateien selbst zu überprüfen. Obwohl ich mit der Art und Weise, wie das Experiment durchgeführt wurde, nicht ganz einverstanden war, haben mich die Auswirkungen so sehr beunruhigt, dass ich gemeinsam mit dem Kaspersky-Forscher Magnus Kalkuhl einen Blog-Artikel verfasst habe, der sich eher mit dem Problem der "kaskadierenden" FPs als mit den Einzelheiten der Demonstration befasst.

Es stellt sich auch die Frage, wie viele Menschen sich überhaupt darüber im Klaren sind, dass ein Security-Anbieter unterschiedliche Erkennungskriterien anwendet, je nachdem, ob ein Produkt für den Unternehmens- oder für den Privatmarkt, für den Firmenserver oder für den Heim-Desktop bestimmt ist. Wahrscheinlich nicht die Mehrheit. Dennoch ist dies ein Thema von einiger Bedeutung, wenn Computeranwender VirusTotal zum Vergleich von Produkten unangemessen nutzen. Außerdem wird berichtet, dass es in einigen Fällen keine Möglichkeit gibt, den Hersteller zu kontaktieren, um FPs zu beheben, oder zumindest ist die Kontaktstelle schwer zu finden. Insbesondere scheint es so zu sein, dass bestimmte auf Unternehmen ausgerichtete Anbieter den Kontakt/Support nur für ihre zahlenden Kunden zulassen.

Es ist wichtig, dass die Anbieter False-Positives ebenso ernst nehmen wie False-Negatives. Es reicht nicht aus, FPs mit Begründungen wie "es spielt keine Rolle, wenn es nicht weit verbreitet ist", "dies ist nicht die Art von Programm, die unser Kundenstamm berücksichtigen muss, weil es keine Unternehmensanwendung ist" oder "es hat keine kritischen Auswirkungen in der realen Welt" zu ignorieren. Jede fehlerhafte Erkennung von sauberen Dateien ist ein FP, und die Auswirkungen eines FP können weitaus größer sein, als zum Zeitpunkt der ersten Meldung vermutet wird. Wie und wie gut ein Unternehmen mit einem echten FP umgeht, ist ein brauchbarer Indikator für seine Ethik und seine Professionalität. Es ist daher nicht überraschend und völlig vernünftig, dass solide Prüforganisationen Methoden entwickelt haben, mit denen sie dies messen können.

Autor Bio

Obwohl David Harley sich heutzutage eher als Musiker denn als Security-Experte sieht, hat er mehr als drei Jahrzehnte im Bereich der Cybersicherheit gearbeitet, u.a. in den Bereichen System- und Netzwerkadministration/-management in der medizinischen Forschung und im öffentlichen Gesundheitswesen, Produkttests und -bewertung sowie über ein Jahrzehnt lang in enger Zusammenarbeit mit einem großen Security-Anbieter. Daher kann er auch heute noch nicht widerstehen, seine Meinung zu Security-Fragen zu äußern, wenn er dazu aufgefordert wird. Die meisten seiner öffentlich zugänglichen Schriften über Security sind verlinkt oder gespeichert: hier.