Ein Intrusion-Warning-System für dynamische Koalitionsumgebungen Martin Lies, Marko Jahnke, Michael Bussmann, Sven Henkel /F Abt. Kommunikation Neuenahrer Str. 20 D-53343 Wachtberg Jens Tölle Universität Bonn Institut für Informatik IV Römerstrasse 164 D-53117 Bonn 1
Übersicht Einführung Architektur Datenaustausch zwischen Partnern Handhabung von Ereignismeldungen Anomalieerkennung Erste Ergebnisse 2
Einführung: Grundlagen eines IDS Ebenen der Informationsabsicherung (Defense-in-Depth) Prävention (z.b. Zugriffskontrolle, Verschlüsselung, Firewalling) Detektion (z.b. Beobachtung des Netzverkehrs, Logfile-Analyse) Reaktion (z.b. Rekonfiguration von System/Netzwerk, computerforensische Maßnahmen, Recovery) Intrusion Detection (ID) Auffinden von Anzeichen für potentiell schadhafte Vorfälle in Computersystemen bzw. Netzwerken Einschätzung des Zustandes des zu überwachenden Systems bezüglich Sicherheit 3
Dynamische Koalitionsumgebungen Coalition Environments (CE) Zusammenarbeitende, gleichbereichtigte Partner Gemeinsame und konträre Ansichten & Interessen Beispiele Allianzen von Wirtschaftsunternehmen Kooperierende Strafverfolgungsbehörden Militärische Netzwerke (NATO, SFOR, KFOR etc.) Unbestritten: Kooperation bei IT-Sicherheit ist vorteilhaft und notwendig 4
Allgemeines Modell: IDS Ziel- System A-Box (Analyzer) C-Box (Response) Daten E-Box (Sensor) D-Box (Storage) 5
Einsatzszenario dynamische Koalitionsumgebung Domain A? Domain B Local IDS Local IDS Sensor Sensor Sensor Sensor Domain C Data Flow Warning Flow 6
Architektur: Kooperative IDS Ziel- System Daten E-Box A-Box C-Box C-Box A-Box E-Box Ziel- System Daten D-Box D-Box Domain A Domain B Nachteile: Modifikation aller beteiligten IDS n (n-1) zusätzliche Kommunikationsverbindungen Aufwand für separate Regeln über Informationsweitergabe sehr hoch (Erstellung, Wartung, Umsetzung) 7
Architektur: Meta-IDS Domain A Ziel- System Daten E-Box (Sensor) A-Box (Analyzer) D-Box (Storage) C-Box (Response) A-Box (Analyzer) C-Box (Response) Ziel- System A-Box (Analyzer) C-Box (Response) Daten E-Box (Sensor) D-Box (Storage) E-Box (Sensor) D-Box (Storage) Domain B 8
Meta-IDS in einer dynamischen Koalitionsumgebung Domain A Meta IDS Domain B Local IDS Local IDS Sensor Sensor Sensor Sensor Domain C Data Flow Warning Flow 9
Besondere Herausforderungen für Meta-IDS in CE Primäre Aufgaben: Tendenzerkennung Frühwarnung Entscheidungshilfe Interoperabilität Kommunikationsprotokolle Datenmodell Dynamik bei den Koalitionsmitgliedern Fluktuation Information Sharing Policies (IShPs) Trust Levels Hohes und wechselndes Datenaufkommen U.u. >10 Domains und >1000 E-Boxen 10
Datenaustausch über IDS-Gateways Entscheidung für Quasistandards bei Kommunikationsprotokollen & Datenmodell - Empfehlungen der IETF IDWG (IDMEF, IDXP/BEEP) - Alternativen Entwicklung von effizienten und flexiblen Verfahren zur Informationsbereinigung entsprechend der Information Sharing Policies - Anonymisierung/Pseudonymisierung - Domänenspezifische Laufzeitkonfigurierbarkeit 11
Modell und Format einer Ereignismeldung Analyzer Create Time Source Target Classification <IDMEF-Message version="1.0"> <Alert ident="abc123456789"> <Analyzer analyzerid="hq-dmz-analyzer01"> <Node category="dns"> <location>headquarters DMZ Network</location> <name>analyzer01.example.com</name> </Node> </Analyzer> <CreateTime ntpstamp="0xbc723b45.0xef449129"> Analyzer 2000-03-09T10:01:25.93464-05:00 </CreateTime> <Source ident="a1b2c3d4"> <Node ident="a1b2c3d4-001" category="dns"> <name>badguy.example.net</name> <Address ident="a1b2c3d4-002" category="ipv4-net-mask"> <address>192.0.2.50</address> <netmask>255.255.255.255</netmask> </Address> </Node> </Source> <Target ident="d1c2b3a4"> <Node ident="d1c2b3a4-001" category="dns"> <Address category="ipv4-addr-hex"> <address>0xde796f70</address> </Address> </Node> </Target> <Classification origin="bugtraqid"> <name>124</name> <url>http://www.securityfocus.com</url> </Classification> </Alert> </IDMEF-Message> Create Time Source Target Classification 12
Informationsbereinigung (1): Szenario Domain A Meta IDS (E M, E T ) Domain B Event Filter Local IDS Local IDS Event Message Anonymized Event Message Sensor Sensor Sensor Sensor Domain C 13
Informationsbereinigung (2): Verfahren 1-zu-1-Umsetzung eintreffender Meldungen Other system parameters no e = e Output e XML formatted message e Matching e matches E M? yes e = E T (e) Matching Template E M Transformation Template E T 14
Informationsbereinigung (3): Implementierung Entwicklung eines speziellen XML/XSLT-Prozessors Erweiterung der Matching-Templates Reguläre Ausdrücke Arithmetischboolesche Ausdrücke Integration der Transformationsvorschrift in Matching-Template <IDMEF-Message...... <address> $192\.22 \.([0-9]{1,3}$v1$ \.([0-9]{1,3}$v2$ <condition> ($v2<255) </condition> Matching-Template <transform> <xsl::copy> 191.72.<xsl::value-of select="$v1"/>.<xsl::value-of select="$v2"/> </xsl:copy> </transform> Transformations-Template </address>... </IDMEF-Message> 15
Redundanzfilter (1): Szenario Domain A Meta IDS (E M 0, EM 1, ET ) Redundancy B Domain Filter Local IDS Local IDS Sensor Sensor Sensor Sensor Domain C 16
Redundanzfilter (2) Erweiterung der 1-zu-1-Transformation Zusammenfassen von n ähnlichen Meldungen (n-zu-1) Berücksichtigen von zeitlichen Zusammenhängen Absolutes vs. Relatives Matching Ausgabe eines Aggregations-Ereignisses e 17
Redundanzfilter (3): Verfahren XML formatted messages e Transformation Template E T B 0 := 0 B 1 := 0 t B := 0 Read next e t B 0 and t t B > t B? no yes e = E T (B 0,B 1,s(E M 0 )) t B := 0 Output e B 0 empty? no yes Absolute Matching Matching Template E M ß e matches E M 0? no yes Store e in Bucket B 0 t B := t Output e Relative Matching Matching Template E M 1 yes e matches E M 1? no Store e in Bucket B 1 Output e 18
Redundanzfilter (4): Implementierung Erweiterung des XML/XSLT- Prozessors Bei absolutem Matching: Erzeugung von Template für relative Matchings Erzeugung und Update einer Summary-Message <IDMEF-Message...... <address>... Absolutes Matching-Template <maxmatch deltat="20000" maxmatch="40"> <xsl:copy>... <address>... <summary do="create">... </summary> <summary do="update">... </summary> </xsl:copy> </relmatch> <transform>... </IDMEF-Message> Relatives Matching Summary-Erzeugung Summary-Update Relatives Matching-Template 19
Kombinationsdetektor (1): Szenario Domain Nation A Meta IDS ( {E M i }, ET ) Combin. Domain Detector Nation B Local IDS Local IDS Sensor Sensor Sensor Sensor Domain Nation C Data Flow Warning Flow 20
Kombinationsdetektor (2): Verfahren Beispiel einer zu suchenden Kombination: Mehr als 100 TCP-Pakete von Adresse A zu Adresse B auf Port 22, die potentielle NoOp-Instruktionen beinhalten und ein Paket, von B nach A von Port 22 mit dem Textinhalt uid=0(root), das unmittelbar nach den Paketen des ersten Typs auftritt. Erkennen vordefinierter Kombinationen miteinander korrelierter Ereignisse (n-zu-m) Verallgemeinerter Fall der Redundanzfilter Spezifiziert über einer Menge von relativen Matching-Templates 21
Anomalieerkennung (1): Szenario Message Dispatcher Responder Meta IDS Analyzer Storage Domain A Domain B Local IDS Local IDS Sensor Sensor Sensor Sensor Domain C 22
Anomalieerkennung (2): Verfahren Source-Target Graph Normaler Zustand Anomalie! Graph Clustering Mit freundlicher Genehmigung der Universität Bonn, Institut für Informatik, Abt. IV 23
Anomalieerkennung (3) Mit freundlicher Genehmigung der Universität Bonn, Institut für Informatik, Abt. IV 24
Effizienzprüfung (1): Informationsbereinigung Durchsatzmessungen: - Konfiguration Meldungsgenerator Gateway Konsole - Hardware für Gateway: 1GHz PIII/256MB Meta-IDS Console Counter Sanitizer Policy Rules Message Dispatcher Meta-IDS Gateway Event Message Generator 25
Effizienzprüfung (2): Redundanzfilter Durchsatzmessungen: - Reihenfolge hochgradig relevant für Leistungsfähigkeit - Kombination mit Informationsbereiniger Meta-IDS Console Counter Redundancy Filter Sanitizer Filter Rules Policy Rules Message Dispatcher Meta-IDS Gateway Event Message Generator 26
Zusammenfassung Besondere Herausforderungen für IDS in CE-Szenarien Für dynamische CEs geeignet: Meta-IDS-Architekturen Informationsbereinigung bei Ereignismeldungen Wesentliche Voraussetzung für Anwendbarkeit Anomalieerkennung im Ereignismeldungs-Datenmodell Unabhängigkeit von Heterogenität der lokalen Netze Redundanzfilterung von Ereignismeldungen Gesteigerte Handhabbarkeit durch Datenreduktion Detektor für Kombinationen von Elementarereignissen Flexible Realisierung durch XML/XSLT-Techniken 27
Ausblick Aufbau eines Multi-Domänen Testbetts (Kooperation /F, Uni Bonn, FH Koblenz) Erweiterung des Anomaliedetektors - Berücksichtigung weiterer Bestandteile von Ereignismeldungen (Prioritäten, Meldungsklassen) - Grenzen des Verfahrens bei stärkerer Veränderung der Eingabedaten (Anonymisierung, etc.) 28
Kontakt Martin Lies lies@fgan.de Marko Jahnke jahnke@fgan.de Jens Tölle toelle@cs.uni-bonn.de /F Abteilung Kommunikation Neuenahrer Str. 20 53343 Wachtberg Universität Bonn Institut für Informatik IV Römerstrasse 164 53117 Bonn 29