Unsere Antivirus-Formel.

Jedes System basiert auf einem einzigartigen Algorithmus; ohne diesen Algorithmus gibt es kein System. Es ist egal, welcher Art von Algorithmus das System folgt – linear, hierarchisch, festgelegt, stochastisch oder wie auch immer. Wichtig ist, dass das System bestimmten Regeln folgen muss, um die besten Ergebnisse erzielen zu können.

Wir werden oft nach den Algorithmen unserer Produkte gefragt – vor allem danach, wie uns diese helfen, zukünftige Bedrohungen besser zu erkennen als die Mitbewerber.

Nun, natürlich kann ich die Details unserer magischen Formel nicht preisgeben, allerdings werde ich in diesem Technik-Beitrag (wahrscheinlich der technischste Beitrag auf diesem Blog) die Tür zu unserer Technologieküche ein bisschen öffnen – um Ihnen einen Blick darauf zu ermöglichen, was dort drin vor sich geht. Und wenn Sie dann noch mehr Informationen haben möchten, können Sie mir gerne in den Kommentaren unten Ihre Fragen schicken.

Wir nutzen eine deduktive Methode, um unbekannte Schadprogramme zu entdecken – von generellen Merkmalen zu speziellen. Alle Schadprogramme führen, sagen wir mal, die Aktionen X, Y und Z aus. Eine bestimmte Datei führt aber ebenfalls X, Y und Z aus; also würde diese Datei schädlich aussehen. Allerdings ist das Ganze in der Praxis nicht so simpel.

Es ist unmöglich, zu sagen, dass eine bestimmte Aktion eindeutig die Schädlichkeit eines Objekts anzeigt. Immerhin wurde jedes Kommando einmal entwickelt, um nützliche Dinge zu tun.

Zunächst einmal kann man nicht sagen, dass eine bestimmte Aktion eindeutig die Schädlichkeit eines Objekts anzeigt. Ein klassisches Beispiel dafür ist der Zugriff auf den Master Boot Record (MBR): Sie können nicht sagen, dass alles, das dieses Kommando nutzt, schädlich ist, denn es gibt auch viele Programme, die das ganz friedlich tun. Das gleiche gilt für alle anderen Aktionen; immerhin wurde jedes Kommando ursprünglich entwickelt, um nützliche Dinge zu tun.

Mit anderen Worten, reicht es nicht, einfach die Spreu vom Weizen zu trennen. Allerdings kann man den Umfang und die Zusammensetzung sowohl des Weizens, als auch der Spreu herausfinden. Und genau das wird auch getan: Herausfinden, was in der eigenen Kornkammer vorgeht, aber auch, was in den benachbarten Kornkammern passiert. Dann werden die Ergebnisse analysiert, eine fundierte Entscheidung in der Weizen/Spreu-Sache getroffen – wer ist „Freund“, wer ist „Feind“ – und entsprechend gehandelt.

Dafür verwenden wir eine Technologie, die ganz Bescheiden SR heißt. Nicht zu verwechseln mit alter Zahncreme, denn in unserem Fall steht das SR für Security Rating. Dabei handelt es sich im Grunde um ein ein verzweigtes, selbstlernendes System von Gewichtungen, die dabei helfen, bei der Evaluierung und Emulation eines Objekts dessen wahre Natur herauszufinden.

Kasperskys magische Formel: ein selbstlernendes Gewichtungssystem, mit dem die wahre Natur eines Objektes herausgefunden werden kann.Tweet

SR analysiert die Zusammensetzung und Dichte der von einem Objekt erzeugten Ereignisse und zudem seine nach außen sichtbaren Attribute (Name, Größe, Speicherort, Komprimierung, usw.). Basierend auf komplexen Regeln erhält jedes Attribut eine Gefahrenbewertung (0-100 Prozent). Die erste Reihe von Regeln (es gibt mittlerweile über 500) war das Ergebnis einer manuellen Studie von über 80.000 einzigartigen Schadprogrammen verschiedener Familien. Heute werden Regeln meist automatisch erstellt, so dass die menschlichen Experten die selbstlernenden Algorithmen feineinstellen können.

Um das Testen und die Wartung einfacher verwaltbar zu machen, sind die Regeln in Gruppen eingeteilt (zum Beispiel „Internet“, „Passwörter“, „Registry“ usw.), und wenn ein Objekt gegen eine oder mehrere verstößt, werden die dementsprechenden Beschränkungen darauf ausgesprochen.

Hier einige Beispiele der einfachsten Regeln:

Die Regel „Laden eines Treibers über die Low-Level-API ntdll.dll“

API function: NtLoadDriver
Argument 1: *
Argument 2: *
Argument 3…N: *
Einschätzung: Einzelne Operation – 40%, 2-3 Operationen – 50%, >3 Operationen – 60%
Gefährlich: Nein

Die Regel „Analyse des Kernel-Maschinencodes (taking hooks)“

API function: CreateFile
Argument 1: Contains ’ntoskrnl.exe‘ entry
Argument 2: *
Argument 3…N: *
Einschätzung: Einzelne Operation – 100%, 2-3 Operationen – 100%, >3 Operationen – 100%
Gefährlich: Ja

Die Gesamtwertung eines Objekts ist die Summe aller individuellen Bewertungen, nachdem die komplette Regeldatenbank geprüft wurde. Es handelt sich also um ein typisches künstliches neuronales Netz, das Signale von zahlreichen Sensoren sammelt, deren qualitative und quantitative Charakteristiken analysiert, die Verbindungen erforscht und ein Urteil fällt.

So ging es mit SR im Jahr 2007 los (Patent US7530106). Seit damals haben wir das System immer wieder verbessert. Aber das haben Sie sich wahrscheinlich schon gedacht!

Das erste Problem damals war, dass eine analysierte Datei eine riesige Zahl von unbedeutenden Ereignissen erzeugen kann, die dazu führen können, dass die Datei fälschlicherweise als gefährlich eingestuft wird. Wenn zum Beispiel ein Delphi-Programm gestartet wird, erzeugt dies bis zu 500 solcher Ereignisse. Diese sind bei allen mit dieser Programmiersprache geschriebenen Programmen gleich und sie geben absolut keine Informationen darüber, was das Programm im Schilde führen könnte. Dieses „Grundrauschen“ verbraucht nicht nur Computerressourcen, es macht auch die Analyse schwerer.

Ein Programm kann eine riesige Menge unbedeutender Ereignisse erzeugen. Also haben wir eine Möglichkeit gefunden, diese zu filtern.

Also haben wir einen Filter erstellt, der dieses Grundrauschen ausfiltert. Und anders als bei den üblichen Regeln, reicht hier ein Boolesches Attribut. Dadurch wird die Regel viel einfacher und die Arbeit geht schneller. Die Regeln enthalten dann nur den Namen der API-Funktion und die Masken für deren Argumente.

Zum Beispiel:

SysAllocString (*,-NULL-,-NULL-)

Wenn hier das erste Argument der Funktion eine Bedeutung hat, während der Rest keine Bedeutung hat, wird das Ereignis als unbedeutend eingestuft.

Für die automatische Generierung der Filterregeln für unwichtige Ereignisse nutzen wir drei Methoden:

Die erste ist die Drosophilae-Methode. Wir erstellen mit dem Entwicklungs-Tool X ein einfaches Programm, das „Hello World“ schreibt und nutzen dabei so weit möglich dessen beliebteste DLLs. Wir lassen das kompilierte Programm durch den Emulator laufen und die ganzen erzeugten drosophilen Ereignisse geben wir in das „unwichtig“-Feld ein.

Die zweite ist die verpackte Drosophilae-Methode. Diese läuft genau wie die erste Methode ab, allerdings interessieren uns hier die Verhaltensereignisse der Packer/Schutzhüllen. Dafür erstellen wir eine Attrappe, die in Assembler geschrieben und mit allen möglichen Packern und Schutzhüllen versehen ist, lassen sie durch den Emulator laufen und… nun, den Rest können Sie sich denken: Wir filtern erneut die unbedeutenden Ereignisse.

Wie helfen Drosophilae den Kaspersky-Experten, zukünftige Gefahren zu bekämpfen?Tweet

Die dritte Methode ist die statistische. Wir analysieren eine große Menge legitimer und schädlicher Dateien, und markieren die API-Aufrufe, die oft im Verhalten beider Dateitypen zu finden sind. Diese Methode ergänzt die ersten beiden und hilft, wenn es keine Möglichkeit gibt, eine Drosophila zu erzeugen. Ein Beispiel für die Anwendung dieser Methode ist das Markieren der unbedeutenden Ereignisse, die von der GUI und den Speicherzuordnungsfunktionen generiert werden.

Doch das (die automatische Generierung von Filterregeln für unwichtige Ereignisse) war nur eine der einfachsten Herausforderungen. Alles andere war dann schwerer…

Die erste Version von SR arbeitete auf einem einzigen geschützten Computer, der im Grunde isoliert war. Wir hatten kein globales Bild; und wir verstanden nicht, welche Regeln wir auslösten  oder wie oft und wie exakt  und konnten deren Wertung auch nicht verändern. Es gab also genügend ungenutzte Möglichkeiten, das Ganze effektiver zu machen…

Die erste Version von SR arbeitete isoliert. Die späteren Versionen wurden dann mit Cloud-Technologien aufgemotzt.

…Nun kommt das Cloud-basierte KSN (Kaspersky Security Network) ins Spiel, das wir später bei voller Fahrt entwickelt haben, und zu dem mittlerweile das Astraea-Expertensystem hinzukam (für die Analyse riesiger Massen von Signalen geschützter Computer sowie die Erarbeitung sinnvoller Schlussfolgerungen zur weltweiten Bedrohungssituation und zu Epidemien).

Im Jahr 2009 veröffentlichten wir dann die nächste SR-Version – SR2 (US8640245), die mit dem KSN und Astraea zusammengeführt wurde. Das brachte uns Big Data mit guten, detaillierten Möglichkeiten – in der Sicherheitsbranche das Geheimrezept für Erfolg!

Im Wesentlichen haben wir uns die Möglichkeit geschaffen, (i) veraltete (ineffektive) Regeln abzuschaffen, (ii) Regeln zeitweise abzuschalten oder zu testen und (iii) Einstufungen von Regeln durch spezielle Koeffizienten in Echtzeit zu korrigieren. Drüber hinaus war die Größe der Koeffizientendatenbank lächerlich klein – im Kilobyte-Bereich – und deren Aktualisierung beeinflusste im Jahr 2009 die Internetverbindung des geschützten Computers so gut wie gar nicht.

Astraea erweiterte ebenfalls den statistischen Rahmen für die Berechnung der Bewertungen – bei den Berechnungen wurden nicht nur Signale verschiedener Emulatoren genutzt, sondern auch Signale vieler weiterer Sensoren, die mit dem KSN verbunden sind. So konnte die Lösung ein von der Cloud (dem KSN) bereits gefälltes Urteil erhalten und sich somit den Emulationsprozess sparen. Und es gibt noch einen weiteren erfreulichen Bonuspunkt: Wir können zuverlässig unbekannte „Spezies“ aus dem Datenstrom pflücken, über die wir noch nicht viele Informationen haben, die sich aber verdächtig verhalten, und diese dann manuell analysieren.

Wirklich wichtig dabei ist, dass Astraea die Regeln automatisch korrigiert; ein menschlicher Experte wird nur für die regelmäßige Prüfung der Effektivität des genutzten mathematischen Modells und für dessen Verbesserung benötigt (Patentanmeldung US20140096184).

Smart-Tech kann es selbst machen. Beispiel: #Kaspersky Lab bekämpft zukünftige Gefahren ohne menschliche HilfeTweet

Als wir unsere Finger auf den globalen Daten hatten, kamen uns sofort neue Ideen zur Lösung alter Probleme: Ganz oben auf der Liste war dabei das Problem der Fehlalarme.

Wir haben beim laufenden Kampf gegen Fehlalarme, so genannten False Positives, schon seit seiner Einführung mit SR herumexperimentiert. Aber im Jahr 2011 kam das Ganze erst so richtig ins Rollen: Wir haben gleichzeitig mehrere neue Funktionen zur Minimierung von Fehlalarmen ausgeliefert.

Legitime Software führt viele Operationen mit friedlichen Absichten aus. Installationsprogramme löschen zum Beispiel Dateien im System32-Ordner. Die automatische Regulierung der Einstufung dieser Operation führt also zu ihrer grundlosen Degradierung und wir verpassen dadurch echte Schädlinge. Man braucht also einen Kompromiss, denn man kann schlecht auf zwei Hochzeiten gleichzeitig tanzen. Also beschlossen wir, den Berechnungsmechanismus der Einstufungen in drei Teile aufzuteilen:

Erstens: die oben beschriebene Berechnung – je gefährlicher ein Verhalten ist und je öfter es vorkommt, desto höher die Einstufung.

Zweitens: eine Art Whitelist-Regeln, die Aktionen der normalen Regeln je nach konkreter Situation oder Datei zurücknehmen oder korrigieren.

Drittens: Entdeckungsregeln für legitime Programme, die die Bedrohungseinstufung absenken, wenn typisches Verhalten entdeckt wird. Diese Regeln können auch eine Art Sicherheits-Einstufung festlegen.

Beispiel:

Die Regel „Erstellung des Registry-Keys für Autorun“

API function: Registry: establishing the meaning of the parameter (RegSetValueEx)
Argument 1: Contains entry
‚RegistryMachineSoftwareClasses*shellexContextMenuHandlersNotepad++‘
Argument 2: *
Argument 3…N: *
Einschätzung: Einzelne Operation – 1%, 2-3 Operationen – 1%, >3 Operationen – 1%
Gefährlich: Nein

Hier können wir eindeutig sehen, dass auf den Registry-Key zugegriffen wird; allerdings handelt es sich hier nur um Notepad++, das seine DLL liefert. Das Argument der Regel verhindert einen Fehlalarm, während die eigentliche Regel bestehen bleibt; bei anderen Versuchen, den Registry-Key zu ändern, wird sie wie gewünscht arbeiten.

Gegen Ende 2011 führten wir noch eine weitere nützliche Funktion ein (wir pfuschen ja nicht herum).

Wie schon angesprochen, arbeiten die Regeln in SR unabhängig voneinander; dadurch konnten wir komplexe Wechselwirkungen wie Datei laden – Datei auf die Festplatte speichern – Autorun-Key hinzufügen nicht studieren. Wenn es uns aber gelänge, solche Wechselwirkungen zu verfolgen, wäre es möglich, Einstufungen zu geben, die mehr als nur die Summe der Einstufungen getrennter Ereignisse sind. Oder weniger :). Also haben wir beschlossen, in SR2 die Verknüpfung von Ereignissen für die präzisere Erkennung unbekannter Schadprogramme einzuführen.

Das machten wir auf zwei Arten.

Um zukünftige Bedrohungen besser bekämpfen zu können, ist es wichtig, nicht nur Ereignisse, sondern auch deren Wechselwirkungen zu analysieren.

Zum ersten haben wir Bit-Masken erstellt, die Regelgruppen oder einzelne Regeln mit ODER und UND definieren. Die Hauptbeschreibung ist der Bit-Index der Verhaltensklassifikationen. Ursprünglich war das für die Gruppierung von Schadprogrammen, basierend auf deren spezifischem Verhalten, gedacht, doch ein ähnlicher Ansatz kann auch zur Verfeinerung der Einschätzung von Bewertungen genutzt werden. Mit der Hilfe von Masken können wir Funktionen wie (RULE76 or RULE151) und (RULE270 or RULE540) implementieren. Das Gute an solchen Masken ist ihre Kompaktheit und ihr schnelles Arbeitstempo; die Limitierung ist, dass sie wenig flexibel sind.

Zum zweiten haben wir spezielle Skripte entwickelt, die nach den SR-Berechnungen globale Analysen ausführen (Patent US8607349). Die Skripte können unabhängig voneinander gestartet werden, oder wenn eine Regel ausgelöst wird. Jedes Skript hat Zugriff auf die Datenbank der akkumulierten Statistiken früherer ausgelöster Regeln und Regelgruppen. Als Konsequenz daraus bekamen wir die Möglichkeit, (i) komplexe Logiken wie Konditionen, Zyklen und die Aktivierung von Sub-Programmen zu nutzen; (ii) neuronale Netze komplett zu nutzen und (iii) Skripte nicht nur für präzisere SR-Einstufungen zu verwenden, sondern auch, um neues Wissen zu erlangen, das in folgenden Skripten angewendet werden kann.

So entscheidet das erste Skript zum Beispiel auf der Basis der Analyse von einem Dutzend Regeln, dass das „Programm versucht, die Passwörter anderer Programme zu erhalten“. Ein zweites Skript entscheidet, dass das „Programm etwas über das Internet überträgt“. Während ein drittes Skript entscheidet, dass „wenn das Programm ein Interesse an Passwörtern zeigt und etwas über das Internet überträgt, das Programm eine +100%-Einstufung bekommt“.

Davon abgesehen, können Skripte mit jeder Regel genutzt werden, und die finale Regel wird zu einem Auslöser für eine Art Algorithmus.

Ein Beispiel so eines Skripts:

VarS : string;begin
if copy(ExtractFilePath(APIArg[1]), 2, 100)=‘:‘ then begin
AddSR(20);
s := LowerCase(ExtractFileExt(APIArg[1]));if S = ‚.exe‘ then AddSR(40);
if S = ‚.com‘ then AddSR(50);
if S = ‚.pif‘ then AddSR(60);
if S = ‚.zip‘ then AddSR(-20);
end;
end.

In diesem Beispiel bewertet das Skript die Operation einer Dateierstellung. Wir prüfen, ob die Datei im Wurzelverzeichnis des Laufwerks erstellt wurde und vergeben dafür 20% an SR. Und je nach Dateierweiterung vergeben wir eine zusätzliche Wertung mit „+“ oder „-„.

Das Beispiel zeigt den Hauptvorteil von Skripten: die Möglichkeit, komplexe, differenzierte Beurteilung der Argumente von Funktionen zu geben, mit Zuordnung auf individuelle SR-Bewertungen, basierend auf den Ergebnissen unterschiedlicher Prüfungen. Darüber hinaus können manche Prüfungen die Bewertung verbessern, andere diese dagegen verschlechtern. Damit können komplexe Prüfungen und komplexe Analysen durchgeführt werden, die weitere Fehlalarme unterdrücken.

Und nun ein kleiner Blick in die Zukunft…

Wir haben bereits mit der Veröffentlichung unserer Version 2015 der Heimanwenderprodukte begonnen. Wir haben lange darüber nachgedacht… und schließlich beschlossen, das lokale SR aufzugeben und stattdessen die Kalkulation der Bewertungen komplett in die Cloud zu verlagern.

Dieser Ansatz bringt uns viele Vorteile: Die Qualität der Analyse leidet nicht darunter, während auf dem geschützten Computer weniger Ressourcen benötigt werden, da die ganze Berechnung in der Cloud erfolgt. Und die Verzögerung bei der Auslieferung des Urteils über eine Datei beträgt… nun, praktisch Null – Bruchteile von Millisekunden, die nur durch spezielle Software gemessen werden können; unsere Anwender werden es nicht bemerken!

Das war es also. Ein kurzer Blick auf unsere Coca-Cola-ähnliche „Geheimformel“ in etwas über 2.000 Wörtern :). Aber das ist natürlich nur die Spitze des Eisbergs: eine detailliertere Beschreibung der Technologien würde Tage dauern. Aber wie gesagt: Wenn Sie mehr Details hören möchten, sagen Sie mir in den Kommentaren unten Bescheid!

Jaa! Der technischste Beitrag von @e_kaspersky über zukünftige Bedrohungen. Lohnt sich, zu lesen.Tweet

Kommentare lesen 1
Kommentare 1 Hinterlassen Sie eine Nachricht.

    Maximilian Hentschel

    Hört sich interessant, wobei ich aber nicht alles verstehe. Aber bitte mehr davon 🙂 IT-Sicherheit ist sehr interessant für mich und Kaspersky ist das führende Produkt für IT-Sicherheit.

Hinterlassen Sie eine Nachricht.