Agentenbasierte Lösung

Der Einsatz autonomer Agenten erlaubt es uns, auf eine hierarchische Struktur zu verzichten. Die Dezentralisierung ermöglicht eine ausgeglichene Auslastung der Netzwerkkapazitäten; es existiert kein zentraler Administrationsserver mehr, der zu Stoßzeiten zu einem Flaschenhals werden könnte. Durch die Eliminierung zentraler Systeme verschwinden außerdem die bei den Angreifern besonders beliebte Ziele, die bildlich gesehen, Achillesfersen der Infrastrukturen darstellen.

Jeder Rechner wird durch einen oder durch mehrere Agenten geschützt. Die Konfigurationen von Agenten könnten sich durchaus voneinander unterscheiden. So können Agenten, z.B. abhängig von den ihnen zur Verfügung stehenden Ressourcen, mit einer ungleichen Anzahl von Regeln arbeiten. Agenten unterstützen ein gemeinsames Protokoll, welches ihnen Nachrichten- und Datenaustausch ermöglicht.

Die Abbildung 4 veranschaulicht den Aufbau einer solchen Struktur.

 

Abbildung 4: Verwendung unterschiedlicher Regelwerke.

Die Hosts eins und zwei arbeiten mit vergleichsweise kleinen Regelwerken. Agent drei ist dagegen leistungsfähig genug, um von einem erweiterten Signatursatz und Heuristik Gebrauch zu machen. Auf den ersten Blick scheinen die ersten beiden Hosts, einen geringeren Schutz als der dritte Rechner zu besitzen. Global gesehen ist dies jedoch nicht der Fall, denn Host3 verfügt über die notwendigen Voraussetzungen, um alle ihm bekannten Angriffe zu erkennen. Sobald dieser einen solchen Angriff feststellt, übermittelt er eine entsprechende Warnung an die beiden Client-Rechner mit dem Hinweis auf die Signatur des von ihm erkannten Angriffs. Die beiden Rechner müssen jetzt lediglich die entsprechende Signatur in ihre Signatursätze aufnehmen, um von diesem Angriff ebenfalls geschützt zu sein. Die beschriebenen Prozesse werden in der Abbildung 5 veranschaulicht.

 

Abbildung 5: Bekanntgabe der Angriffssignatur.

 

Eine solche Vorgehensweise ermöglicht einen besonders sparsamen Umgang mit den Ressourcen der zu schützenden Rechner. Dies ist beispielsweise in den mobilen Systemen von einer besonderen Bedeutung, denn deren Rechenleistung dieser Systeme ist durch die Akkukapazität und Wärmeabfuhr beschränkt. Die Aufnahme einer neuen Signatur in den Datensatz kann mit einer Schutzimpfung verglichen werden. Die wenigsten Menschen kommen auf die Idee, sich im Hochsommer einer Grippeimpfung zu unterziehen, denn sie ist in der Regel vollkommen überflüssig und würde lediglich das Immunsystem belasten. Auf der anderen Seite würde sich jeder vernünftige Mensch eine Schutzimpfung gegen Malaria gönnen, wenn er im Sommer die tropischen Wälder als Urlaubsziel aufsuchen würde. Es macht Sinn, die Signatur eines neuen Angriffes erst dann in den Signatursatz aufzunehmen, wenn dieser wahrscheinlich wird. Wenn die Gefahr des Angriffes nicht mehr gegeben ist und die Agenten eine bestimmte Sorte von Angriffen nicht zu erwarten haben, können die entsprechenden Signaturen als nicht mehr aktuell eingestuft und wieder aus dem Speicher entfernt werden.

Die dezentralisierte Struktur eines Multiagentensystems hat auch weitere positive Eigenschaften. Wir haben bei der Auseinandersetzung mit einem auf dem Client/Server-Ansatz basierenden System gesehen, dass der zentrale Server zum Flaschenhals der Infrastruktur werden kann. Dies ist z.B. dann der Fall, wenn zu viele Clients mit den aktuellen Signaturen versorgt werden müssen und der Server nicht über die dafür notwendigen Kapazitäten verfügt. Die dezentralisierte Struktur eines Multiagentensystems kann dazu verwendet werden, die Kapazitätenengpässe zu vermeiden.

Wir kehren zu dem von uns behandelten Gedankenmodell zurück, bei dem Host3 einen Angriff feststellen konnte und jetzt versucht, die ihm bekannten Hosts über diese Gefahr zu benachrichtigen. Seine Ressourcen reichen jedoch lediglich aus, die Signatur des Angriffs dem Host2 zu übermitteln. Nichtsdestotrotz kann Host1 die von ihm benötigte Signatur in seine Datenbank aufnehmen, indem er diese vom Host2 bezieht. Abbildung 6 veranschaulicht den beschriebenen Vorgang. Host2 wäre außerdem in der Lage, einen Teil der Serveraufgaben zu übernehmen und die ihm bekannten Hosts über die Existenz einer Bedrohung und das Vorhandensein einer Signatur des Angriffs benachrichtigen. Dieser Prozess könnte so lange fortgesetzt werden, bis alle Rechner im bedrohten Netzwerksegment über einen aktualisierten Signatursatz verfügen.

Abbildung 6: Bei der Nichtverfuegbarkeit von Host3 kann Host1 die Signatur des Angriffs vom Host2 beziehen.

Es ist leicht zu sehen, dass der beschriebene Aufbau leicht von einem Angreifer ausgenutzt werden kann, indem er einige Falschmeldungen generiert und diese verschickt. Agenten würden diese an die anderen Hosts weiterleiten, was dazu führt, dass das gesamte Multiagentensystem sich nach einer kurzen Zeit im "Stresszustand" befindet. Sämtliche Systeme arbeiten in diesem Fall mit dem vollen Signatursatz und gehen somit recht verschwenderisch mit ihren Ressourcen um. Das beschriebene Problem kann gelöst werden, wenn Agenten in er Lage sind, ihr Vertrauen zu einem System zu ändern. So können beispielsweise einige falsche Meldungen eines Systems dazu führen, dass dessen Warnungen in Zukunft ignoriert werden. Um das "Hochschaukeln" der Warnstufe des gesamten Systems zu vermeiden, kann die Tatsache ausgenutzt werden, dass Malware sich in der Regel nicht wahllos verbreitet. Die Wahrscheinlichkeit, dass die Malware versucht, zuerst die Nachbarn eines Systems anzugreifen und nicht einen Rechner am anderen Ende der Welt ist relativ hoch. Die Warnmeldungen sollen deswegen mit einem Zähler ausgestattet werden: bei jeder Weiterleitung der Meldung (einem Hop) wird der Zähler decrementiert. Sobald der Zählerstand null beträgt, wird die Meldung vom System nicht mehr weitergeleitet.

 

 

Abbildung 7: Jede Warnmeldung wird mit einem Zaehler versehen, der bei jedem Hop decrementiert wird. Beim Zaehlerstand 0 wird die Nachricht verworfen.