Zum Begriff Schlangenöl: Ich bin da nicht so fanatisch wie z.B. fefe.
Nehmen wir mal die aktuelle Bedeutung, so wie sie halt auf
AV-Software auch angewandt wird.
AVs schützen vor Dingen, die den jeweiligen Herstellern bekannt sind, bzw. durch eine Heuristik erfaßt werden. So weit, so gut. Problem ist nur, daß in der Tat allein schon durch das Parsen von Dateien aller Couleur jede Menge Angriffsfläche frisch entsteht. Guck dir die mehr oder weniger regelmäßigen Schwachstellen in Sachen Archivformate an. Und wenn es dann an die Bearbeitung der gemeldeten Schwachstellen kommt, dann merkt man, daß es auch bei
AV-Herstellern kein höheres Problembewußtsein für Schwachstellen gibt als anderswo.
Die Kritik ist also durchaus berechtigt. Im Gegensatz zu den ganzen anderen im obigen Artikel verlinkten Programmen haben die meisten AVs aber durchaus auch eine Schutzwirkung. Daher finde ich den Begriff Schlangenöl - bei aller berechtigter Kritik! - unpassend.
Problematisch sehe bei
AV-Software, dass sie unter Umständen bei einigen Usern ein (falsches) Gefühl der Sicherheit erzeugt, und im Ernstfall dann doch nicht hilft.
Das bringt das Hauptproblem schön auf den Punkt. Bzw. es ist Glückssache ob sie hilft. Sprich, sie hilft in - meinetwegen - 98% der Fälle, aber was passiert falls du über die verbleibenden 2% stolperst. In absoluten Zahlen sind die verbleibenden 2% dann ja noch immer extrem viele nicht erkannte Schädlinge.
Leider ist es nicht im Interesse der
AV-Hersteller Anwender zu schulen. Das wäre aus meiner Sicht die wirksamste Methode schlechthin. Aber als ehemaliger Admin weiß ich auch, daß die meisten Anwender auch keinen Bock haben geschult zu werden.
Bei Sicherheits-Komplett-Paketen, die dann auch TLS-Verbindungen aufbrechen, werde ich aber wirklich skeptisch.
Sei gleich ablehnend. Derlei
MitM-Quark gehört auf den Müllhaufen der Geschichte. Das geht überhaupt nicht.
Zum Glück hatte ich selber noch nicht so große Probleme und die zwei/drei mal, war das Problem zwei Stunden bis paar Tage Später weg, nachdem ich den Fals-Positive hochgeladen hatte.
Glückspilz!
Wobei, viele der
AV-Programmhersteller nutzen doch keine eigene Signaturen und verwenden die von wo anders,
aber ich hätte dann eigentlich auch erwartet, dass es dort dann auch einfacher wird, wenn sich nur Einer oder eine Gruppe um die Befüllung/Bereinigung/Reparatur kümmern, anstatt jder Hersteller selbst.
Okay, kurzer Exkurs. Signaturen im klassischen Sinne kommen noch immer zum Einsatz. Aber allein durch die schiere Menge täglich frischer Malware, die sich nur in wenigen Bytes unterscheidet, müssen diese baldmöglichst in Heuristiken überführt werden. Das macht man, sobald sich ein Cluster aus verschiedenen Dateien herauskristallisiert. Die Bezeichnung "Signaturen" ist also eigentlich technisch irreführend, aber dennoch gebräuchlich.
Erkennung ergibt sich grob gesagt aus: Engine (Code) + "Signaturen" (Daten).
Meistens sind diese "Signaturen" nur zu jeweils einer Engine kompatibel. Aus Endanwendersicht gibt es also jene
AV-Hersteller mit eigener Engine und jene ohne eigene Engine. Letztere bauen - auch wenn das jetzt etwas überspitzt und verkürzt ist - im Prinzip nur eine Benutzeroberfläche um eine existierende
AV-Engine. Und ja, es kann sein daß ein solcher Hersteller seine eigenen "Signaturen" anbietet oder zusätzlich zu denen des Herstellers der
AV-Engine eigene erstellt und anbietet (dazu gibt's dann Werkzeuge seitens des Herstellers der Engine). Bei VT kann man häufig an der gleichen Namensgebung erkennen ob sich mehrere
AV-Produkte eine Engine teilen.
Dann gibt es noch den Spezialfall mehrerer Engines. Meistens sind das dann Hersteller aus der zweiten Kategorie, denn die Engine-Hersteller befinden sich ja in einer natürlichen Konkurrenz zueinander. Meist wird die schnellste Engine vorgeschaltet. Zusätzliche Engines dienen dann der Verifikation. Denn allgemein galt bei uns immer:
sobald wir etwas erkennen, geht's nicht mehr um Geschwindigkeit, sondern um Gründlichkeit. Bei mehreren Engines bekäme also die Engine 2 die Datei nochmal vorgelegt und so können dann bspw. Fehlalarme (False Positives) ausgeschlossen werden.
Aber ich kann keine wirklichen Details nennen, da ich da nicht genug Einblick habe (Multi-Engine). Ich würde annehmen, daß der Produkt-Hersteller die eingesetzten Engines selbst bewertet und so quasi den Erkennungen eine Vertrauenswürdigkeit zuordnet und dementsprechend einen Gesamt-Score ermittelt. Also bspw. weiß der dann daß Engine 1 die schnellste ist, also wird die davorgeschnallt. Außerdem ist Engine 1 gut bei - sagen wir mal - Droppern. Hingegen bei PUA ergibt sich eine Diskrepanz zu den Bewertungskriterien von Engine-Hersteller und Produkt-Hersteller. Also werden PUA-Erkennungen von Engine 1 nochmal Engine 2 vorgelegt und dann ggf. "durchgelassen".
Hatte ein Programm auf dem Server kompiliert, via RDP her geholt und wollte es lokal testen ... erst gefühlt ewig warten und dann der Sperrbildschrirm.
Das erhöht natürlich unheimlich die Akzeptanz solche Lösungen
Heuristik heißt bei Virenscanner: Wir suchen nach 'ner Ähnlichkeit.
Nee, das bedeutet wir such(t)en nach Indikatoren und ab einer bestimmten Schwelle schlagen wir Alarm, falls zu viele Indikatoren bedenkliche Werte zeigen.
Naja, und reicht die Menge der Indikatoren, dann böse
Für mich ist das eine Ähnlichkeit, vielleicht auf 'ner anderen Ebene, als bei Meier und Maier, aber es gibt halt eine bestimmte Menge an (algorithmischen) Übereinstimmungen.
Wahrscheinlich meinen wir das gleiche. Nur bei Ähnlichkeiten frage ich mich immer: ähnlich wozu. Und genau diese Cluster bilden sich ja erst raus, je mehr erkannte Dateien man "sieht".