Studie ¼ber die Nutzung von Log - Institut f¼r Internet-Sicherheit

Studie über die Nutzung von Log- und Monitoringdaten im Rahmen der IT-Frühwarnung und für einen sicheren IT-Betrieb

Logdatenstudie

Vervielfältigung und Verbreitung:Bitte beachten Sie, dass das Werk einschließlich aller Teile urheberrechtlich geschützt ist.

Für Rückfragen stehen Ihnen die Mitarbeiter des BSI gern zur Verfügung:

Bundesamt für Sicherheit in der InformationstechnikReferat 122 InternetsicherheitPostfach 20 03 6353133 BonnTel. +49 (0) 3018 9582-0E-Mail: [email protected]: http://www.bsi.bund.de

Folgende Organisationen haben an der Erstellung des vorliegenden Textes mitgewirkt:– Bundesamt für Sicherheit in der Informationstechnik, Bonn, http://www.bsi.bund.de

– Computacenter AG & Co. OHG, Kerpen, http://www.computacenter.com

Abbildung 2 Logo der Computacenter

2 Bundesamt für Sicherheit in der Informationstechnik

Abbildung 1 Logo des BSI

mailto:[email protected]

http://www.computacenter.com/

http://www.bsi.bund.de/

http://www.bsi.bund.de/

Logdatenstudie

Inhaltsübersicht1 Management Summary......................................................................................................9

2 Einleitung.........................................................................................................................11

3 Übersicht über Protokolle und Formate zur Übertragung und Speicherung von Log- und Monitoringdaten..............................................................................................................13

4 Standardisierungsbestrebungen.......................................................................................96

5 Übersicht über aktuelle Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten 112

6 Praktische Empfehlungen für konkrete Anwendungsszenarien....................................208

7 Empfehlungen für zusätzliche Sicherheitsmaßnahmen.................................................242

8 Anhang...........................................................................................................................278

Bundesamt für Sicherheit in der Informationstechnik 3

Logdatenstudie

Weitere Angaben zum Text

Typ des DokumentsStudie

SchlagwörterInternet-Sicherheit, IT-Frühwarnung mittels Log und Monitoringdaten, Protokoll Übersicht, Standartisierungs- Übersicht, Verfügbare Produkte, Praktische Empfehlungen, Zusätzliche Sicherheitsempfehlungen


Logdatenstudie

Inhaltsverzeichnis1 Management Summary......................................................................................................................9

2 Einleitung........................................................................................................................................11

3 Übersicht über Protokolle und Formate zur Übertragung und Speicherung von Log- und Monitoringdaten.............................................................................................................................................13

3.1 Protokolle zur Übertragung von Log- und Monitoringdaten................................................................133.1.1 Allgemeine Überlegungen zum Protokollieren sicherheitsrelevanter Informationen....................................133.1.2 Syslog.............................................................................................................................................................153.1.3 Syslog-ng........................................................................................................................................................183.1.4 SNMP.............................................................................................................................................................213.1.5 NetFlow..........................................................................................................................................................233.1.6 IPFIX..............................................................................................................................................................263.1.7 Security Device Event Exchange (SDEE)......................................................................................................273.1.8 WMI für Windows Eventlog..........................................................................................................................273.1.9 Check Point Log Export API..........................................................................................................................293.1.10 SSL-verschlüsselte Übertragung..................................................................................................................303.1.11 Tabellarischer Überblick und Zusammenfassung........................................................................................32

3.2 Formate zur Speicherung von Log- und Monitoringdaten...................................................................323.2.1 Allgemeine Überlegungen zu Formaten.........................................................................................................333.2.2 Microsoft-Betriebssysteme und -Anwendungen............................................................................................35

3.2.2.1 Windows NT bis Server 2003 Event Log..............................................................................................353.2.2.2 Windows Eventlog ab Windows Vista..................................................................................................37

3.2.3 Unix-artige Betriebssysteme..........................................................................................................................373.2.4 Für SNMP-Traps verwendetes Format...........................................................................................................393.2.5 IPFIX-Format.................................................................................................................................................393.2.6 Cisco NetFlow-Format...................................................................................................................................423.2.7 Format bei Cisco IOS-basierenden Geräten...................................................................................................433.2.8 Firewall-Geräte...............................................................................................................................................45

3.2.8.1 Check Point VPN-1 Logformat.............................................................................................................453.2.8.2 Cisco PIX-Format..................................................................................................................................473.2.8.3 Juniper Netscreen Security Manager.....................................................................................................48

3.2.9 Intrusion-Detection- und -Prevention-Systeme..............................................................................................503.2.9.1 Cisco IPS-Format (SDEE).....................................................................................................................503.2.9.2 McAfee IntruShield IPS (Datenbank)...................................................................................................533.2.9.3 3Com Tipping Point IPS........................................................................................................................53

3.2.10 Webserver und -Anwendungen....................................................................................................................553.2.10.1 Internet Information Server Format.....................................................................................................563.2.10.2 Apache Format (Common Log Format)..............................................................................................573.2.10.3 Tomcat Servlet Container Format.......................................................................................................58

3.2.11 Proxy-Systeme..............................................................................................................................................593.2.11.1 Microsoft ISA Server Format..............................................................................................................603.2.11.2 Squid-Format.......................................................................................................................................623.2.11.3 NetCache-Format.................................................................................................................................633.2.11.4 Bluecoat SG Format............................................................................................................................683.2.11.5 SecureComputing Webwasher Format................................................................................................69

3.2.12 Mailserver.....................................................................................................................................................713.2.12.1 Exchange Server Message Tracking Format.......................................................................................713.2.12.2 Sendmail-Format.................................................................................................................................723.2.12.3 Exim-Format........................................................................................................................................733.2.12.4 Postfix-Format.....................................................................................................................................753.2.12.5 Qmail-Format......................................................................................................................................763.2.12.6 SpamAssassin-Format.........................................................................................................................77


Logdatenstudie

3.2.13 Virenschutz-Anwendungen..........................................................................................................................783.2.13.1 McAfee Virusscan Enterprise Format.................................................................................................783.2.13.2 Symantec Antivirus Corporate Edition Format...................................................................................803.2.13.3 ClamAV-Format..................................................................................................................................83

3.2.14 Netzwerk- und Schwachstellen-Scanner......................................................................................................843.2.14.1 NMAP-Format.....................................................................................................................................843.2.14.2 Nessus-Format.....................................................................................................................................853.2.14.3 QualysGuard-Format...........................................................................................................................863.2.14.4 McAfee Foundstone Format................................................................................................................87

3.2.15 Weitere wichtige Dienste und Daemons......................................................................................................873.2.15.1 ISC Bind Format..................................................................................................................................883.2.15.2 Samba-Format......................................................................................................................................903.2.15.3 Asterisk-Format...................................................................................................................................91

3.2.16 Tabellarische Übersicht und Zusammenfassung..........................................................................................93

4 Standardisierungsbestrebungen.......................................................................................................964.1 „Security Issues in Network Event Logging“ (Syslog)........................................................................96

4.2 „IP Flow Information Export“ (IPFIX)..............................................................................................100

4.3 IETF-Arbeitsgruppe „Remote Network Monitoring“ (rmonmib)......................................................104

4.4 Zusammenfassung und Fazit..............................................................................................................110

5 Übersicht über aktuelle Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten.....................................................................................................................................................112

5.1 Ausgangslage.....................................................................................................................................1125.1.1 Ziele der IT-Frühwarnung............................................................................................................................1125.1.2 Auswahl relevanter Log- und Monitoringdaten und zu beobachtender Größen..........................................1145.1.3 Grundlegende technische Rahmenbedingungen eines Projektes zur Umsetzung der IT-Frühwarnung......1165.1.4 Gängige Begriffsdefinitionen.......................................................................................................................117

5.1.4.1 Security Operations Center (SOC)......................................................................................................1175.1.4.2 Security Information Management (SIM)...........................................................................................1175.1.4.3 Security Event Management, auch Security Event Monitoring (SEM)..............................................1175.1.4.4 Computer-Forensik..............................................................................................................................118

5.2 Darstellung und Diskussion der Verarbeitungskette von Log- und Monitoringdaten zum Zweck der IT-Frühwarnung......................................................................................................................................118

5.2.1 Notwendige Zentralisierung von Log- und Monitoringdaten......................................................................1185.2.2 Unterstützung von Formaten und Protokollen.............................................................................................1195.2.3 Normalisierung und Aggregation.................................................................................................................1205.2.4 Filterung und Auswahl von Informationen: Fokus auf IT-Sicherheit, Zweckbindung, Aussondern von „Datenmüll“.................................................................................................................................................................1215.2.5 Schnittstellen: Import, Export und die Unterstützung bestehender Prozesswerkzeuge...............................1235.2.6 Lesender Zugriff auf die Log- und Monitoringdaten...................................................................................1235.2.7 Modellierung und Priorisierung; Reduktion von False-Positives................................................................1255.2.8 Korrelation unabhängiger Ereignisse...........................................................................................................1265.2.9 Grundlegende Sizing-Aspekte technischer IT-Frühwarnsysteme................................................................1275.2.10 Output und Alarmierung............................................................................................................................1285.2.11 Ergebnisdarstellung, Analysefunktionen und Berichterstellung................................................................1295.2.12 Sicherheit von IT-Frühwarnsystemen: Integrität, Authentizität, Verfügbarkeit und Vertraulichkeit von Log- und Monitoringdaten....................................................................................................................................130

5.3 Vorstellung aktuell erhältlicher Produkte zur Speicherung und Verarbeitung von Log- und Monitoringdaten..................................................................................................................................................131

5.3.1 Nagios...........................................................................................................................................................1315.3.2 HP „OpenView for Operations“...................................................................................................................1365.3.3 Microsoft System Center Operations Manager mit Audit Collection Service.............................................1415.3.4 Check Point „Eventia“..................................................................................................................................145


Logdatenstudie

5.3.5 Quest „Intrust“..............................................................................................................................................1515.3.6 Attachmate „NetIQ Security Manager“.......................................................................................................1555.3.7 Flowerfire „Sawmill“...................................................................................................................................1605.3.8 Intersect Alliance „SNARE Server“.............................................................................................................1635.3.9 Cisco Security MARS..................................................................................................................................1675.3.10 Open Source Security Information Management „OSSIM“......................................................................1715.3.11 IBM „Tivoli Security Operations Manager“..............................................................................................1785.3.12 Symantec „Security Information Manager“...............................................................................................1835.3.13 CA eTrust „Network Forensics“ und „Security Command Center“..........................................................1885.3.14 RSA „enVision“.........................................................................................................................................1925.3.15 Novell „Sentinel“.......................................................................................................................................1975.3.16 ArcSight „Enterprise Security Manager“...................................................................................................202

5.4 Fazit und Zusammenfassung..............................................................................................................207

6 Praktische Empfehlungen für konkrete Anwendungsszenarien....................................................2086.1 Fiktiver IT-Verbund „Recplast GmbH“.............................................................................................208

6.1.1 Erfassung der Anforderungen, Ausgangslage, „Pflichtenheft“....................................................................2106.1.1.1 Primäre Ziele.......................................................................................................................................2106.1.1.2 Teilziele und Zwischenschritte............................................................................................................211

6.1.2 Auswahl und Absicherung der Logdaten.....................................................................................................2136.1.3 Analysemöglichkeiten des IT-Verbunds mit Bordmitteln...........................................................................216

6.1.3.1 Reine Windows-Infrastruktur..............................................................................................................2176.1.3.2 Gemischte Infrastruktur.......................................................................................................................219

6.1.4 Analysemöglichkeiten, die über den Einsatz von Bordmitteln hinausgehen...............................................2226.1.4.1 Analysemöglichkeiten mit Windows, die über Bordmittel hinausgehen............................................2236.1.4.2 Gemischte Umgebung, über den Einsatz von Bordmitteln hinausgehend..........................................227

6.1.5 Diskussion des Erreichten............................................................................................................................229

6.2 P-A-P-Gateway..................................................................................................................................2306.2.1 Anforderungen und Pflichtenheft.................................................................................................................232

6.2.1.1 Primäre Ziele.......................................................................................................................................2326.2.1.2 Zwischenschritte und Teilziele............................................................................................................232

6.2.2 Auswahl der Logdaten..................................................................................................................................2336.2.3 Analysemöglichkeiten für das P-A-P-Gateway...........................................................................................236

6.2.3.1 Die Einführung eines zentralen Loghosts............................................................................................2366.2.3.2 Nachgelagerte Analyse........................................................................................................................2376.2.3.3 Echtzeit-Auswertung und IT-Frühwarnsystem....................................................................................238

6.2.4 Diskussion des Erreichten............................................................................................................................240

7 Empfehlungen für zusätzliche Sicherheitsmaßnahmen.................................................................2427.1 Einführung: Risikoanalyse auf der Basis von IT-Grundschutz..........................................................242

7.1.1 Anforderungen und Pflichtenheft.................................................................................................................2427.1.2 Beschreibung zum schematischen Vorgehen...............................................................................................243

7.2 Risikoanalyse zum IT-Verbund der Recplast GmbH.........................................................................2447.2.1 Die Gefährdungsübersicht............................................................................................................................2447.2.2 Ermittlung zusätzlicher Gefährdungen.........................................................................................................2497.2.3 Gefährdungsbewertung................................................................................................................................2517.2.4 Behandlung von Risiken..............................................................................................................................270

7.3 Risikoanalyse zum P-A-P-Sicherheits-Gateway................................................................................2747.3.1 Die Gefährdungsübersicht............................................................................................................................2747.3.2 Ermittlung zusätzlicher Gefährdungen.........................................................................................................2757.3.3 Gefährdungsbewertung................................................................................................................................2757.3.4 Behandlung von Risiken..............................................................................................................................276

7.4 Zusammenfassung.............................................................................................................................276


Logdatenstudie

8 Anhang..........................................................................................................................................2788.1 Abbildungsverzeichnis.......................................................................................................................278

8.2 Tabellenverzeichnis...........................................................................................................................278

8.3 Stichwort- und Abkürzungsverzeichnis.............................................................................................280


Logdatenstudie

1 Management SummaryDie vorliegende Studie gibt einen Überblick über den aktuellen Stand der Technik im Hinblick auf die Verarbeitung und Speicherung von Log- und Monitoringinformationen.

Im ersten Teil werden die Formate beschrieben, in denen wichtige Systeme und Anwendungen Logdaten speichern. Außerdem werden die verbreitetsten Protokolle zur Übertragung von Log- und Monitoringinformationen über das Netz vorgestellt. Anschließend wird eine Übersicht über momentan auf dem Markt verfügbare Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten gegeben.

Der zweite Teil der Studie gibt praktische Hinweise, wie Log- und Monitoringdaten in zwei konkreten Anwendungsszenarien genutzt werden können, nämlich im IT-Verbund eines kleinen Unternehmens sowie im Kontext eines Sicherheitsgateways, das zu einem größeren IT-Verbund gehört. Zum Abschluss wird durch eine ergänzende Sicherheitsanalyse nach dem BSI-Standard 100-3 untersucht, welche Sicherheitsmaßnahmen zusätzlich für sogenannte Loghosts in Betracht gezogen werden sollten, für die bereits die Standardsicherheitsmaßnahmen nach Grundschutz umgesetzt wurden.


Logdatenstudie


Logdatenstudie

2 EinleitungLog- und Monitoringdaten werden in jedem IT-Verbund von den verschiedensten IT-Systemen und Anwendungen in großer Menge und Vielfalt generiert. Vielfach enthalten die erzeugten Meldungen Informationen, die auf mögliche Sicherheitsprobleme oder bereits eingetretene Sicherheitsvorfälle schließen lassen. Die Idee, diese Informationsquellen zur Verbesserung der IT-Sicherheit zu erschließen, liegt daher nahe.

Ziel der vorliegenden Studie ist es, den Stand der Technik im Hinblick auf die Verarbeitung und Speicherung von Log- und Monitoringinformationen zu dokumentieren und die Grundlage dafür zu legen, dass diese Informationen in IT-Frühwarnsystemen effizient genutzt werden können.

Unter Logdaten werden in diesem Zusammenhang in erster Linie Daten verstanden, die ein System oder eine Anwendung ereignisbezogen generiert, und die entweder auf dem System selbst oder auf einem gesonderten System gespeichert werden. Wohlbekannte Beispiele für Ereignisse, zu denen Logdaten erzeugt werden, sind die An- oder Abmeldung von Benutzern, gescheiterte Anmeldeversuche und Statusmeldungen von Diensten, wie sie beispielsweise unter Unix-Betriebssystemen in der syslog-Datei oder unter Windows im Ereignisprotokoll festgehalten werden. Weitere Beispiele sind Anfragen an Web- oder Proxyserver, sowie Informations- oder Warnmeldungen von Intrusion Detection Systemen, die diese Anwendungen meist in eigenen Logdateien oder -datenbanken speichern.

Logdaten spielen oft eine zentrale Rolle bei der Untersuchung von IT-Sicherheitsvorfällen (Computerforensik). Solche Untersuchungen finden oft längere Zeit nach dem eigentlichen Vorfall statt und dienen dazu, den Verlauf des Geschehens zu rekonstruieren sowie den entstandenen Schaden oder in manchen Fällen das Ausmaß des Sicherheitsvorfalls überhaupt zu ermitteln. Dieser Aspekt der Nutzung von Logdaten wurde in der vorliegenden Studie jedoch nicht vertieft.

Logdaten eignen sich jedoch auch zur Verwendung im Rahmen von Frühwarnsystemen, wenn sie laufend überwacht oder zumindest regelmäßig in relativ kurzen Abständen ausgewertet werden. Im Rahmen dieser Studie wird vor allem dieser Aspekt betrachtet.

Synonym für den Begriff Logdaten wird oft der Begriff Protokolldaten verwendet. Im Rahmen dieser Studie soll jedoch dieser Begriff möglichst vermieden werden, um die Gefahr von Verwechslungen im Zusammenhang mit der Verwendung des Begriffs "Protokoll" im Sinne von "Übertragungsprotokoll" zu verringern.

Unter dem Begriff Monitoringdaten werden im Rahmen dieser Studie solche Daten betrachtet, die nicht ereignisbezogen erzeugt werden, sondern laufend aktualisiert den aktuellen "Betriebszustand" eines Systems oder einer Anwendung wiedergeben. Typische Beispiele sind die aktuelle Systemauslastung eines Rechners, der freie Plattenplatz auf einem Dateiserver oder die Anzahl momentan offener Anfragen auf einem Webserver. Solche Monitoringinformationen sind von ihrer Natur her flüchtige Informationen und werden meist nur in größeren Abständen oder anlassbezogen gespeichert, etwa wenn bestimmte Schwellwerte über- oder unterschritten werden. Im Rahmen der vorliegenden Studie war vor allem die Frage interessant, wie Monitoringinformationen dazu genutzt werden können, frühzeitig Störungen oder mögliche Angriffe zu erkennen.

Daten, die von speziell entwickelten Komponenten von IT-Frühwarnsystemen, Protokollanalysatoren oder von Anwendungen erzeugt werden, die den gesamten Verkehr in einem Netzsegment aufzeichnen und speichern (sogenannte "Sniffer"), werden Rahmen dieser Studie nicht oder allenfalls am Rande betrachtet.


Logdatenstudie

Im ersten Teil der Studie werden die Formate beschrieben, in denen wichtige Systeme und Anwendungen Logdaten speichern. Außerdem werden die verbreitetsten Protokolle zur Übertragung von Log- und Monitoringinformationen über das Netz vorgestellt. Der darauf folgende Abschnitt gibt einen kurzen Überblick über die Arbeit dreier IETF-Arbeitsgruppen, die einen Bezug zum Thema Log- und Monitoringdaten haben. Anschließend wird eine Übersicht über momentan auf dem Markt verfügbare Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten gegeben.

Der zweite Teil der Studie gibt praktische Hinweise, wie Log- und Monitoringdaten in zwei konkreten Anwendungsszenarien genutzt werden können, nämlich im IT-Verbund eines kleinen Unternehmens sowie im Kontext eines Sicherheitsgateways, das zu einem größeren IT-Verbund gehört. Zum Abschluss wird durch eine ergänzende Sicherheitsanalyse nach dem BSI-Standard 100-3 untersucht, welche Sicherheitsmaßnahmen zusätzlich für sogenannte Loghosts in Betracht gezogen werden sollten, für die bereits die Standardsicherheitsmaßnahmen nach Grundschutz umgesetzt wurden.

Angesichts der großen Anzahl „relevanter“ Datenquellen – von Betriebssystemen über Serverprogramme bis zu Netzwerkkomponenten - und verschiedener Formate – praktisch jede betrachtete Datenquelle verwendet ein eigenes Format – ist zwangsläufig die Auswahl der tatsächlich betrachteten Datenquellen bzw. -formate unvollständig und die Beschreibungstiefe begrenzt. Dies gilt ebenfalls für die Auswahl der betrachteten Produkte, bei denen das Spektrum von spezialisierten Produkten, die für ein sehr beschränktes Einsatzgebiet vorgesehen sind, bis hin zu umfassenden Lösungen reicht, die eine Vielzahl von Datenquellen unterstützen und vom Benutzer durch eigene Module erweitert werden können.

Die vorliegende Studie wird daher mit Sicherheit nicht alle Fragen beantworten können, die sich in der Praxis ergeben. Sie kann aber einen Überblick bieten und durch die an vielen Stellen enthaltenen Hinweise auf externe Quellen die Grundlage für vertiefende Recherchen darstellen.


Logdatenstudie

3 Übersicht über Protokolle und Formate zur Übertragung und Speicherung von Log- und Monitoringdaten

3.1 Protokolle zur Übertragung von Log- und Monitoringdaten

3.1.1 Allgemeine Überlegungen zum Protokollieren sicherheitsrelevanter Informationen

Sollen in die Log- und Monitoringdaten enthaltenen Informationen in einem IT-Verbund systematisch ausgewertet werden, so wird eine zentralisierte Speicherung und Auswertung bereits bei einer relativ geringen Anzahl beteiligter Systeme unumgehbar. Dieses Vorhaben impliziert einige Anforderungen an das zugrunde liegende System zur Übermittlung der protokollierten Informationen, insbesondere die verwendeten Netzwerkprotokolle. Andere Aspekte bedingen dagegen eher Anforderungen an die Speicherung und Formatierung der Logdaten. Dieser Bereich wird im Kapitel 3.2. näher betrachtet.

Übertragung über das Netzwerk, Übertragung in EchtzeitEine direkte Folgerung ist, dass die protokollierten Informationen über das Netzwerk übertragen werden müssen. Nur so können die Daten an zentraler Stelle und vor allem automatisiert gesammelt und gespeichert werden.

Sollen die Informationen in einem IT-Frühwarnsystem verwendet werden, so muss die Auswertung darüber hinaus möglichst zeitnah erfolgen. Zeitnah bedeutet in diesem Zusammenhang idealerweise in Echtzeit bzw. "Beinahe-Echtzeit", also innerhalb weniger Sekunden. Das Netzwerkprotokoll muss deshalb einen fortwährenden Strom von neuen Logdaten übermitteln können.

Im Gegensatz dazu steht im zweiten Anwendungsszenario, der Auswertung der Informationen im Kontext der Computerforensik, die effiziente und sichere Speicherung großer Datenmengen im Vordergrund.

Bandbreiten-Management und Cache-VerhaltenAngesichts der Anforderung, Log- und Monitoringdaten in Echtzeit zu übertragen und zu sammeln, und vor allem angesichts der Tatsache, dass in großen Netzwerken mit umfangreichem Datenverkehr entsprechend auch sehr große Mengen an Log- und Monitoringdaten anfallen, ergibt sich als nächstes die Forderung, dass die für die Übertragung der Daten notwendige Netzwerkbandbreite beschränkt bleibt. Einerseits darf es nicht passieren, dass die Übertragung von im Grunde ja nachgelagerten Informationen wie den Logdaten den Fluss der eigentlichen Nutzdaten einschränkt. Andererseits muss auch sichergestellt werden, dass nicht durch temporäre Bandbreitenengpässe Log- und Monitoringdaten verloren gehen. In vielen Fällen wird es deshalb vorteilhaft sein, Log- und Monitoringdaten nicht über das eigentliche Datennetzwerk (in-band), sondern über ein davon getrenntes Managementnetzwerk zu übertragen.


Logdatenstudie

In jedem Fall müssen jedoch temporäre Engpässe der Netzwerk-Bandbreite konzeptionell berücksichtigt werden, da ihr Auftreten a priori kaum ausgeschlossen werden kann. Für die Übertragung von Logdaten ergibt sich somit die Forderung, die während solcher Engpässe zu übertragenden Daten zwischenzuspeichern (Caching), um sie zu einem späteren Zeitpunkt – mit Verspätung – an zentraler Stelle abzuliefern: Zumindest für Logdaten ist eine verspätete Auslieferung einem Datenverlust vorzuziehen.

Vertraulichkeit für sensitive InformationenNicht alle Logdaten enthalten sensitive Informationen. Oft ist allerdings nicht festzustellen, dass eine spezielle Datenquelle niemals sensible Logmeldungen verschicken wird. Vielmehr ist typisch, dass eine Mischung aus interessanten, weil sicherheitsrelevanten, und unwichtigen Meldungen generiert wird. Einige Datenquellen generieren Log-Informationen, die datenschutzrelevant sind, da sie Benutzernamen enthalten und somit eine Zuordnung zu konkreten Personen ermöglichen.

Daher ist es wichtig, auch während der Übertragung von Logdaten für die Vertraulichkeit sorgen zu können. Zumindest sollte die Möglichkeit bestehen, bei Bedarf einen gesicherten Übertragungsweg zur Verfügung zu stellen, beispielsweise durch eine Verschlüsselung der Daten.

Fälschungssicherheit und Beweiskraft: Sicherstellung von Integrität und AuthentizitätDer Aspekt der Übertragung der Logdaten über das Netzwerk zu einer zentralen Stelle in Echtzeit wurde bereits erwähnt. Diese Vorgehensweise hat noch einen weiteren Vorteil: Informationen über einen erfolgreichen Angriff werden sofort vom kompromittierten System weg übertragen, so dass die Daten nicht mehr nachträglich durch den Angreifer gelöscht, verfälscht oder mit unwichtigen Daten überschrieben werden können.

Sowohl für die Verwendung von Log- und Monitoringdaten im Kontext IT-Frühwarnung, aber vor allem im Bereich Forensik ist es wichtig, dass weder Beweise für Sicherheitsvorfälle, noch die Beweiskraft der gesammelten Informationen an sich verloren gehen dürfen.

Eine weitere Anforderung ist, dass sich die sammelnde Seite gegenüber dem Daten liefernden System authentifizieren sollte, um eine Versendung der Daten an nicht-autorisierte Stellen oder Man-in-the-Middle-Angriffe zu unterbinden.

Daraus ergibt sich die Anforderung, dass die beteiligten Anwendungen und die verwendeten Protokolle Mechanismen zur Verfügung stellen sollten, um die Integrität und Authentizität der übertragenen und gespeicherten Informationen zu schützen.

Vollständigkeit der LogdatenEin weiterer Aspekt der Beweiskraft und der Verlässlichkeit von Logdaten ist die Vollständigkeit der zu sammelnden Informationen. Ist nicht sichergestellt, dass die gesammelten Informationen vollständig sind, so wird ihre Beweiskraft in der Regel nicht besonders hoch sein.

Auch aus technischen Gesichtspunkten ergibt sich die Anforderung nach Vollständigkeit und Lückenlosigkeit: Ein IT-Frühwarnsystem hat den Anspruch, ein vollständiges Lagebild zu liefern. Teilinformationen verschiedener Datenquellen müssen an zentraler Stelle zusammengeführt und durch eine Korrelation zu einem vollständigen Bild zusammengesetzt werden.


Logdatenstudie

Somit ergibt sich die Anforderung an das Logdaten übertragende Netzwerk-Protokoll, die Vollständigkeit zu gewährleisten. Auf UDP basierende Protokolle sind hierzu nicht in der Lage, da bei ihnen nicht gewährleistet ist, dass alle Datenpakete am Ziel ankommen.

Bestimmbarkeit des Ursprungs und WeiterleitungsmöglichkeitenIn heterogenen Netzwerk-Umgebungen ist es nicht selten unmöglich, die Logdaten direkt vom datenerzeugenden System zum zentralen Log-Sammler zu bringen, teilweise ist dies noch nicht mal erwünscht:

– Vorhandene Meta- oder Umbrella-Systeme sammeln unter Umständen bereits Logdaten. Sich an diese Systeme anzuklinken, kann in vielerlei Hinsicht praktisch sein, beispielsweise in einem Umfeld mit Tausenden von Windows-Clients.

– System-verantwortliche Abteilungen haben in der Regel für ihre Systeme bereits dezentrale Logdaten-Sammler im Einsatz, die insbesondere für eine langfristige Speicherung der Logdaten im Original-Format aufgebaut und ausgelegt sind. Eine Weiterleitung der Logdaten von einem System zum nächsten über mehrere Hops ist in solchen Szenarien durchaus denkbar.

In solchen Fällen müssen sowohl das zur Übertragung benutzte Protokoll als auch das verwendete Datenformat gewährleisten, dass die ursprüngliche Datenquelle ermittelbar bleibt und nicht durch die Weitervermittlungsstufen verschleiert wird.

Verarbeitete und Original-DatenZu guter Letzt besteht oft die Anforderung, Logdaten in Originalform aufzubewahren. Dies kann einerseits wiederum unter dem Stichwort "Beweiskraft" erforderlich sein, aber auch, damit der volle Informationsgehalt nicht verloren geht, beispielsweise wenn bei einer Weiterverarbeitung Teile der Informationen weggelassen werden.

Es wäre somit wünschenswert, dass der Logdaten übertragende Mechanismus in der Lage ist, sowohl "Orginaldaten", als auch bereits aufbereitete oder weiterverarbeitete Daten zu transportieren.

3.1.2 Syslog

Einsatz und HistorieSyslog ist ein bereits in frühen Tagen der BSD-Betriebssysteme entwickeltes Protokoll zur Übertragung und Speicherung der System- und Applikations-Logmeldungen. Es nimmt aufgrund seiner hohen Bekanntheit und Verbreitung einen wichtigen Stellenwert innerhalb der Protokolle zur Logdaten-Übertragung ein. Folgende Liste stellt eine Auswahl unterschiedlicher Logmeldungstypen dar:

– Meldungen des Betriebssystem-Kernels

– Meldungen von User-Space-Anwendungen

– Meldungen des Mail-Systems

– Meldungen von Systemdiensten („Daemons“)

– Sicherheitsmeldungen (auth, auth-priv)


Logdatenstudie

Ursprünglich war Syslog ein Verfahren zur Speicherung rein lokaler Meldungen innerhalb des Unix-Betriebssystems. Später wurde es nicht nur auf praktisch alle Unix- und Linux-Derivate portiert (z. B. Linux, Solaris, HP-UX etc.), sondern auch für die Übertragung über Netzwerke erweitert. Auch zahlreiche Hersteller von Netzwerkkomponenten unterstützen Syslog zur Übertragung ihrer Systemmeldungen.

Da man sich nie auf ein eindeutiges Meldungsformat einigen konnte und sich infolgedessen unterschiedliche Implementierungen und daraus resultierende Inkompatibilitäten ergaben, entstand im Jahre 2001 ein RFC (3164), welches aber keinen Standard festlegte, sondern lediglich informellen Charakter hatte.

Syslog ist ein unidirektionales Protokoll mit Datenfluss von einem sendenden Gerät („Device“) zu einer nahezu beliebigen Anzahl an Kollektoren („Collector“) oder Relaisstationen („Relay“). Relaisstationen nehmen Syslog-Meldungen entgegen, können ggf. fehlende Informationen hinzufügen und die Meldung an einen oder mehrere Kollektoren/Relaisstationen weiterleiten.

Durch seine hohe Verbreitung genießt Syslog trotz fehlender Standardisierung den Status eines De-facto-Standards. Es liefert ausschließlich ereignisbezogene Daten, beispielsweise über fehlgeschlagene Anmeldeversuche oder die Beendigung von Diensten und Betriebssystemen.

ProtokollaufbauSyslog ist aufgrund seiner fehlenden Standardisierung in unterschiedlichen Ausprägungen vorzufinden. Nachfolgend wird deshalb in erster Linie auf die in RFC 3164 beschriebene Variante eingegangen.

Ein Syslog-Paket setzt sich aus den drei Bestandteilen PRI („Priority“), Header und MSG („Message“) zusammen und darf eine Länge von 1024 Bytes nicht überschreiten. Die Priorität enthält die beiden Werte Kritikalität („Severity“) und Nachrichtenherkunft („Facility“).

Die folgenden acht Kritikalitätsstufen stehen zur Verfügung:

Severity Zugeordnete Zahl

Bedeutung

emergency 0 System oder Dienst unbrauchbaralert 1 Alarm, Eingriff dringend notwendigcritical 2 Kritischer System- oder Dienstzustand erreichterror 3 System- oder Dienstfehlerwarning 4 System- oder Dienstwarnungnotice 5 Grenzwerte wurden erreichtinformational 6 Unkritische Meldungdebug 7 Meldung für Fehlersuche

Tabelle 1: Kritikalitätsstufen von Syslog

Nachfolgend ist eine Auswahl möglicher Nachrichtenherkünfte/Facilities aufgelistet. Eine vollständige Liste ist in RFC 3164 aufgeführt.


Logdatenstudie

Facility Zugeordnete Zahl

Beschreibung

kern 0 Meldung des Betriebssystem-Kernelsdaemon 3 Meldung vom Systemdienstauth 4 Meldung zu Authentifizierung und Sicherheitcron 9 Meldung des Cron-Diensteslocal 16-23 Acht frei definierbare Facility-Typen local0 – local7

Tabelle 2: Herkunft von Syslog-Meldungen

Der Paketteil PRI für die Priorität setzt sich nach folgender Formel zusammen und kann dadurch eine Länge von drei bis fünf Oktetten haben:

PRI = 8 x Facility + Severity

Im darauf folgenden sogenannten Header sind ein Zeitstempel und der Name oder die IP-Adresse des sendenden Systems enthalten. Die Angabe von Fully Qualified Domain Names (FQDN) ist nicht möglich, was in größeren Umgebungen mit unterschiedlichen Domänen zu Problemen führen kann.

Durch ein Leerzeichen getrennt folgt im Anschluss die eigentliche Nachricht (MSG). Ihr erster Teil enthält die Angabe der meldenden Betriebssystem- oder Software-Komponente (TAG), während der Meldungstext (Content) in der Regel durch einen Doppelpunkt („:“) oder eine eckige Klammer („[“) separiert wird. Für Beispiele sei auf das spätere Kapitel zu den Formaten von Log- und Monitoringdaten verwiesen (siehe Abschnitt 3.2.3).

Als Transportprotokoll kommt das verbindungslose UDP zum Einsatz. Der hierfür reservierte Port ist 514. Im RFC 3195 wurde eine Erweiterung des Protokolls um zwei TCP-basierende Transportmechanismen vorgeschlagen. Die Kommunikation findet hier auf Port 601/TCP statt und bietet somit eine verlässliche Auslieferung. Außerdem sind Sicherungsmechanismen über das Blocks Extensible Exchange Protocol (BEEP, siehe RFC 3080) vorgesehen. Die Verschlüsselung erfolgt auf Basis des Protokolls TLS (Transport Layer Security, siehe Abschnitt 3.1.10), während die Authentifizierung über den Simple Authentication and Security Layer (SASL) nach RFC 2222 bereitgestellt wird. Eine Umsetzung dieser Erweiterungen in der Breite fand bis dato jedoch nicht statt.

Mögliche Probleme im Zusammenhang mit SyslogSyslog verwendet in der Regel das verbindungslose UDP-Protokoll, welches eine verlässliche Zustellung der Daten nicht garantieren kann. Auch sind die in RFC 3195 vorgeschlagenen Mechanismen zur Absicherung und verlässlichen Zustellung kaum implementiert. Obwohl die übertragenen Informationen durchaus von hoher Priorität und Kritikalität sind, kann durch die Syslog-Architektur nicht verhindert werden, dass diese mitgelesen, zurückgehalten oder verändert werden.

Die Integrität, Authentizität und Vertraulichkeit der übertragenen Informationen können bei vielen Syslog-Implementierungen nur durch nachgeschaltete Sicherheitsmechanismen sichergestellt werden.


Logdatenstudie

3.1.3 Syslog-ng

Einsatz und HistorieDas Protokoll Syslog-ng stellt eine Erweiterung zum standardmäßig verwendeten Syslog dar. Im Jahre 1998 von der Firma BalaBit IT-Security aus Ungarn entwickelt hat es sich aufgrund seiner Flexibilität und Skalierbarkeit zu einem weit verbreiteten Dienst und Protokoll zum Transport von Logmeldungen entwickelt. Syslog-ng darf auch von Unternehmen frei eingesetzt werden, da Syslog-ng unter der GNU General Public License steht. Ziel der Entwickler ist es, flexible, skalierbare und sichere Erweiterungen zu den eingeschränkten Funktionalitäten von Syslog anzubieten.

Bereits seit 1999 wird es in der freien Debian-Distribution und seit der Version 9.3 auch in SuSE Linux standardmäßig anstelle von Syslog eingesetzt.

Grundsätzlich dient Syslog-ng dem gleichen Einsatzzweck wie Syslog, bietet aber gerade für den Einsatz in größeren IT-Verbünden und für eine zentralisierte Verwaltung der Logdaten dringend notwendige Erweiterungen an. So ist es möglich, in der Quellengabe den FQDN anzugeben, was gerade in größeren IT-Verbünden mit mehreren Domains vorteilhaft ist, um Meldungen eindeutig zuordnen zu können. Des weiteren unterstützt Syslog-ng das verbindungsorientierte Transportprotokoll TCP.

Die Entwickler haben angekündigt, dass sie in zukünftigen Versionen von Syslog-ng das Blocks Extensible Exchange Protocol (BEEP, siehe RFC 3080) verwenden wollen, um die Übertragung abzusichern.

ProtokollaufbauSyslog-ng wird auf einer flexiblen Grundarchitektur basierend konfiguriert. In der Konfigurationsdatei befinden sich deshalb die folgenden Objekttypen:

Quelle (Source):

Die sog. Quelle der Meldung legt die Input-Schnittstelle des Syslog-ng-DMailseaemons fest. Es sind insgesamt acht unterschiedliche Quellen spezifiziert:


Logdatenstudie

Quelle Beschreibunginternal Für Meldungen von Syslog-ng selbstunix-stream Für verbindungsorientierte Unix-Socket Streamssun-streams Für Meldungen früherer Betriebssystemversio

nen von Sun Microsystemsunix-dgram Ähnlich wie unix-streams, mit Datagramsfile Für das Lesen aus eine(r) Datei(n)pipe Für Lesen aus Named Pipesudp Für über ein Netzwerk eintreffende UDP-Mel

dungen. Weitere Parameter sind möglichtcp Für über ein Netzwerk eintreffende TCP-Mel

dungen. Weitere Parameter sind möglich

Tabelle 3: Quellen von Syslog-ng-Meldungen

Ziel (Target):

Das Ziel einer Meldung gibt an, wohin ausgehende Nachrichten vom Syslog-ng-Daemon geschrieben werden. Es bestehen die gleichen Möglichkeiten wie beim Objekttyp Quelle, nur „internal“ und „sun-stream“ können nicht als Ziel festgelegt werden. Zusätzlich können aber folgende Ziele definiert werden:

Ziel Beschreibungusertty Zur Ausgabe von Meldungen in einem interakti

ven Konsolenfensterprogram Zur Übergabe von Meldungen an eine Applikati

on mithilfe des Standard-Eingabekanals STDIN

Tabelle 4: Ziele von Syslog-ng-Meldungen

Filter:

Zur Auswahl empfangener Meldungen werden Filter definiert und mit Namen versehen. Mehrere vordefinierte Filter können referenziert und über logische Verknüpfungen „and“, „or“ und „not“ miteinander verknüpft werden.

Es existieren folgende Filterfunktionen:


Logdatenstudie

Filterfunktion Beschreibunglevel Filtert nach der Kritikalität der Meldungfacility Filtert nach dem Facility-Werthost Filtert unter Verwendung regulärer Ausdrücke

nach Hostnamennetmask Filtert nach IP-Adressen meldender Systemeprogram Filtert nach Meldungen einer Applikationfilter Referenziert einen vordefinierten Filter inner

halb eines Filters

Tabelle 5: Filter in Syslog-ng

Die Objekttypen Quelle, Filter und Ziel werden zu sog. „Log-Statements“ zusammengefasst. Die Reihe aller konfigurierten Statements stellt in der Regel eine für jede Logmeldung sequentiell abzuarbeitende Anweisungsliste für den Syslog-ng-Daemon dar; nur bei zutreffender Quelle und zutreffendem Filter wird die Meldung dem zugehörigen Ziel übergeben. Beispiel: Ein Log-Statement umfasst UDP als Quelle, ein Subnetz als Filter und einen Syslog-Server mit TCP als Target. Dies bewirkt, dass alle Meldungen, die von den im Subnetz liegenden IP-Adressen über UDP empfangen werden, per TCP an den Syslog-Server verschickt werden.

Zusätzlich stehen die folgenden globalen Optionen zur Verfügung:

Option Beschreibungcatchall Sämtliche eingehenden Meldungen werden emp

fangen und weiterverarbeitet (Filterung)final Meldungen, die einer Quellbedingung entspre

chen, werden danach nicht mehr durch die anderen Log-Statements geschleust

fallback Alle Meldungen, die keiner Quellbedingung entsprechen, werden dem mit „fallback“ versehenen Log-Statement zugewiesen

flow-control Verhindert die Überflutung von Zielen mit Meldungen durch strikte Einhaltung der Größe des Ausgangspuffers

Tabelle 6: Optionen in Syslog-ng

Mögliche Probleme im Zusammenhang mit Syslog-ngSyslog-ng unterstützt das verbindungsorientierte TCP-Protokoll. Hierdurch wird eine gesicherte Zustellung der Logmeldungen ermöglicht. Die Entwickler haben bereits angekündigt, die in RFC 3195 vorgeschlagenen Mechanismen zur Absicherung und verlässlichen Zustellung in eine zukünftige Version aufzunehmen. Zum aktuellen Zeitpunkt kann aber noch nicht verhindert werden, dass Informationen mitgelesen, zurückgehalten oder verändert werden. Die Integrität, Authentizität und Vertraulichkeit der Daten können bei Syslog-ng nur durch nachgeschaltete Sicherheitsmechanismen sichergestellt werden.


Logdatenstudie

3.1.4 SNMP

Einsatz und HistorieDas Simple Network Management Protocol (SNMP) ist ein erstmals in RFC 1157 definiertes Protokoll zur Überwachung und Konfiguration von Systemen und Netzwerken.

Es wird umfassend als De-facto-Standard für vielerlei Netzwerkkomponenten und Server-Systeme eingesetzt, insbesondere auch für Komponenten der IT-Sicherheit wie Firewalls.

Die SNMP-Kommunikation findet immer zwischen einer oder mehreren Management-Stationen einerseits und einem Agenten andererseits statt, welcher direkt auf dem zu überwachenden oder zu steuernden Gerät installiert ist. In der Regel liefern die Hersteller von Betriebssystemen und Applikationen einen entsprechenden SNMP-Agenten mit dem Produkt aus. Die Anzahl an Agenten in einem SNMP-Verbund wird im Wesentlichen von der Anzahl der im Netzwerk eingebundenen Geräte bestimmt.

Es existieren über alle Versionen von SNMP hinweg zwei Kommunikationsvarianten mit jeweils unterschiedlichem Verbindungsablauf. Die Kommunikation zwischen der Management-Station und dem Agenten baut aber immer auf dem verbindungslosen Transportprotokoll User Datagramm Protocol (UDP) auf:

1. Bei der von der Managementstation initiierten, bidirektional geführten Kommunikation erfolgt eine Anfrage der Station zu den zu ermittelnden Attributen des Agenten auf Port 161/UDP.

2. Bei der zweiten, unidirektionalen Kommunikation sendet der Agent im Vorfeld definierte Attributwerte ereignisbezogen an den Port 162/UDP des Managers. Solche Datenpakete werden im Englischen als „SNMP-Traps“ bezeichnet.

Diese beiden Varianten bieten unter anderem den Vorteil, dass ein Kommunikationsteilnehmer als Management-Station agieren und zugleich auch einen Agenten haben kann, um seinerseits selbst gesteuert oder überwacht zu werden.

Protokoll-AufbauAbzufragende Attribute eines Systems sind bezüglich ihrer Form durch ihre eindeutige Beschreibung in sogenannten „Object Identifiern“ festgelegt. Object Identifier wiederum sind zu Gruppen zusammengefasst. Als Beispiele für solche Gruppen können system, interfaces, at (Address Translation) oder auch Attribute bestimmter Protokolle wie ip, tcp, udp genannt werden. Für standardisierte Object Identifier sind Möglichkeiten des schreibenden und des lesenden Zugriffs gegeben. Object Identifier und ihre Gruppen sind innerhalb der Management Information Base (MIB) zusammengefasst. Diese definiert somit die Menge der abfragbaren Attribute eines Zielsystems. Eine Auflistung aller Object Identifier kann in den RFCs zu den MIBs nachgelesen werden.

Es existieren zwei definierte Standards für MIBs. Im Jahre 1988 wurde MIB-I durch RFC 1066 und in korrigierter Version in RFC 1156 verabschiedet. Als sich zeigte, dass wichtige Attribute in der MIB-I nicht enthalten und die enthaltenen Attribute zum Teil ungeschickt formuliert waren, verabschiedete man den Standard MIB-II. Dieser Standard wurde im Jahre 1990 durch RFC 1158 bzw. in aktueller Form in RFC 1213 verabschiedet. Erweiterungen der MIB-II sind in den RFCs 2011-2013 formuliert und enthalten im Grunde die Unterstützung für eine erweiterte Definitionssprache zur Festlegung der Daten- und Nachrichtentypen (SMIv2).


Logdatenstudie

SNMP nutzt einen Verzeichnisbaum, der ähnlich dem des Domain Name Systems aufgebaut ist, um spezifische Attribute abfragen zu können. Die Benennung der Zweige und Blätter dieses Verzeichnisbaums ist zum einen in einem für Menschen lesbaren Format organisiert, zum anderen wird innerhalb des Protokolls eine numerische Verzeichnisstruktur genutzt. Die Position eines Object Identifiers kann somit in einer Kette von Zahlen dargestellt werden, beispielsweise für die Gruppe ip als 1.3.6.1.2.1.4. Die entsprechende Textform ist iso.org.dod.internet.mgmt.mib.ip.

Die Anwendung aller drei Komponenten SNMP, MIB und SMI ist zwingend notwendig für ein funktionierendes Netzwerk-Management-System.

SNMP Version 1 (SNMPv1)In dem in RFC 1157 verabschiedeten, frei verfügbaren und durch die Standards von MIB und SMI ergänzten Standard wurden sicherheitstechnische Fragen seinerzeit vollkommen außer Acht gelassen. Die Autorisierung des Zugriffs erfolgt mithilfe eines Community Strings, der in Klartext und zudem noch in jedem übertragenen Paket enthalten ist. Da die Übertragung der Daten über das verbindungslose Protokoll UDP stattfindet, ist die Zustellung einer SNMP-Nachricht durch das Protokoll nicht gesichert. Es wird versucht, diese Unzulänglichkeit durch erneutes Versenden einer Anfrage der Management-Station nach Verstreichen einer bestimmten Zeitspanne (Timeout) abzufangen. Die Zustellung von Traps wird hierüber aber nicht abgedeckt.

Die Vertraulichkeit, Integrität und Authentizität der übertragenen Daten ist mit SNMPv1 nicht gewährleistet. Es besteht die Möglichkeit, Daten oder den Community String mitzulesen und diesen beispielsweise zur Veränderung der Routing-Tabelle eines Netzwerkgerätes zu missbrauchen. Wird UDP als Transportprotokoll verwendet, können gerade im unidirektionalen Modus Informationen (Traps) verloren gehen, ohne dass dies einer der beiden Kommunikationspartner bemerkt.

Aufgrund dieser offensichtlichen Schwächen ist aus Sicherheitssicht vom Einsatz von SNMPv1 abzuraten.

SNMP Version 2 (SNMPv2)SNMPv2 wurde über eine Vielzahl von RFCs (1901-1908) definiert. Erweiterungen zu SNMPv1 bestehen in einem neuen Pakettyp zur Abfrage von größeren Datenmengen (get-bulk-request) und einem Mechanismus zur Weiterleitung von Informationen von Manager zu Manager (inform-request). In SNMPv2 kam es zu einer Erweiterung der unterstützten Protokolle für Apple Talk, IPX und des ISO-Protokolls CLTS, jedoch fand keine Erweiterung auf ein verbindungsorientiertes Protokoll, konkret TCP, statt. Eine Ergänzung und Korrektur der MIB ist fester Bestandteil (MIB-II) von SNMPv2. Im RFC 1910 wurde der Einsatz eines Sicherheitsmodells für SNMPv2 vorgeschlagen. Dieser kam jedoch nicht einheitlich zur Anwendung.

Der Einsatz der Unterversion SNMPv2c brachte keine wesentliche Erweiterung der Sicherheit. Nun wurden benutzerbasierte Community Strings mit entsprechenden Lese-/ Schreibrechten unterstützt, und einzelne Hersteller von Software für SNMPv2 implementierten nicht-standardisierte Sicherheitsmechanismen.

Die Gewährleistung der Vertraulichkeit, Integrität und Authentizität der Daten ist in SNMPv2 aufgrund der fehlenden Standardisierung somit insgesamt nicht gewährleistet. Darüber hinaus sind Sicherheitsbedürfnisse in SNMPv2 nicht flächendeckend gelöst, nur gesicherte Insellösungen sind realisierbar. Trotz dieser Einschränkungen ist SNMPv2 in der Praxis derzeit am häufigsten vorzufinden.


Logdatenstudie

SNMPv3In der Version 3 des SNMP-Protokolls wurden grundlegende Erweiterungen und ein neues, mehrschichtiges Rahmenwerk eingeführt. Dieser Standard wurde in RFC 3411 definiert. Weitreichende Veränderungen fanden in der Benennung und der Verarbeitung der Prozesse statt. Dennoch sind SNMPv3-fähige Systeme zu den älteren Versionen 1 und 2 abwärtskompatibel. In RFC 3430 findet sich ein Vorschlag zur Umsetzung auf Basis weiterer Protokolle, auch eine Beispielimplementierung über das verbindungsorientierte TCP.

Erstmals kommt in Version 3 ein dediziertes Sicherheitssystem mit einem oder mehreren Sicherheitsmodellen zum Einsatz, nämlich das in RFC 3414 definierte User-Based Security Model (USM). Dieses ist seinerseits in drei untergeordnete Sicherheitsmodelle unterteilt:

– Das Authentifizierungsmodul garantiert durch die Verwendung von zwei optionalen Authentifizierungsprotokollen (HMAC-MD5-96 und HMAC-SHA-96) die Authentizität der versendeten Nachrichten. Indem der Hash-Based-Message-Authentication-Code (HMAC) und die Einweg-Hash-Funktion (Message Digest, MD5, oder Secure-Hash-Algorithm, SHA-1) verwendet werden, können über den Schlüsselaustausch der Versender der Nachricht und über den Hash-Algorithmus die Integrität der Nachricht sichergestellt werden.

– Das Aktualitätsmodul schützt durch einen in jeder Nachricht enthaltenen Zeitstempel vor einer Verfälschung des Inhalts und damit auch vor dem Abfangen und erneutem Einspielen eines Datenstroms.

– Das Vertraulichkeitsmodul verschlüsselt die versendeten Daten und schützt damit vor dem Mitlesen der gesendeten Daten. Hier kommt der Blockchiffrierungsalgorithmus Data Encryption Standard (DES) zum Einsatz, der inzwischen nicht mehr als sicher anzusehen ist. Der Rückkopplungsmodus Cipher Block Chaining (CBC) sorgt dafür, dass identische Datenblöcke nicht denselben verschlüsselten Datenblock ergeben.

Aus Sicherheitssicht ist es empfehlenswert, für das Sammeln von Monitoringdaten SNMP in der Version 3 einzusetzen und auf ältere Versionen zu verzichten.

Version Verbindungsart Vertraulichkeit Integrität Verschlüsselung

SNMPv1 Verbindungslos (UDP) NEIN NEIN NEIN

SNMPv2 Verbindungslos (UDP) NEIN NEIN NEIN

SNMPv3

Offen,noch verbindungslos (UDP)

JA JA JA

Tabelle 7: Übersicht über die SNMP-Versionen


Logdatenstudie

3.1.5 NetFlow

Einsatz und HistorieNetFlow ist ein vom Hersteller Cisco bereits 1996 zum Patent angemeldetes, proprietäres Protokoll zur Analyse von Monitoringdaten. Im Jahre 2004 hat Cisco das RFC 3954 eingereicht, in dem ausdrücklich betont wird, dass NetFlow nicht zu einem Standard weiterentwickelt werden soll. Mithilfe von NetFlow lassen sich auf unidirektionaler Basis statistische Daten über Kommunikationsbeziehungen oder auch das relative Auftreten von Netzwerkprotokollen über den Zeitverlauf gewinnen (beispielsweise „Top Talker“, „Top Protocols“, „Top Applications“ etc.). Diese Informationen können zu Accounting-Zwecken (z. B. „Welcher Teilnehmer hat wie viel Datenlast erzeugt?“), aber auch für Auswertungen im Kontext der Netzwerksicherheit herangezogen werden. Die Verbreitung von NetFlow ist durch die Marktmacht des Herstellers Cisco sehr groß. In vielen Unternehmen wird es in erster Linie für die Verkehrsanalyse und das Accounting eingesetzt.

Folgende Informationen werden typischerweise mit NetFlow gesammelt:

– Quell- und Zieladresse

– Quell- und Zielport

– Protokolltyp in OSI-Schicht 3

– Type-of-Service Byte

– Logisches Input Interface

Durch eine Konfiguration von NetFlow können weitere Informationen zur Auswertung exportiert werden.

Andere Hersteller von Netzwerkkomponenten haben eigene Protokolle zur statistischen Auswertung von Kommunikationsdaten definiert, welche technisch äquivalent zu NetFlow sind. So verwendet beispielsweise Juniper das Protokoll cFlow und Huawei das Protokoll Netstream. Ein Konsortium der Unternehmen InMon Corp., Foundry Networks und HP entwickelte das mit NetFlow inkompatible Protokoll sFlow (RFC 3176).

Die statistische Auswertung von Monitoringdaten, wie sie NetFlow liefert, kann in Korrelation mit ereignisbezogenen Logmeldungen Anhaltspunkte für ein anomales oder „sicherheitsbedenkliches“ Verhalten liefern und einen Mehrwert für IT-Frühwarnsysteme beisteuern.

Protokoll-AufbauCisco definiert einen Flow als unidirektionalen Datenfluss zwischen einer Quelle und einem Ziel. Ein entsprechend konfigurierter Switch oder Router hält in seinem Arbeitsspeicher einen Cache zur Zwischenspeicherung der identifizierten Flows. NetFlow stellt über Timer und Schwellwerte sicher, dass nicht zu viele Daten in den Cache geschrieben werden. Die konfigurierbaren Optionen zur Überwachung sind vielfältig und hängen unter anderem von der NetFlow-Version und der eingesetzten IOS-Version ab. Die gesammelten Daten werden mithilfe eines NetFlow-Exports in festen Intervallen vom erzeugenden Gerät zum NetFlow-Kollektor übertragen. Aus Performance-Gründen wird hierfür das verbindungslose Transportprotokoll UDP genutzt. Der Packet Header der Version 9 unterteilt sich in die folgenden Felder:


Logdatenstudie

Feld BeschreibungVersion NetFlow-Version des PaketsCount Anzahl an Flowset Records in dem übertragenen

PaketSystem Uptime Zeit seit dem letzten Start der KomponenteUnix Time Zeit in UTCSequence Number Inkrementelle Nummer des PaketsSource ID Identifikationsnummer zur Unterscheidung von

Komponenten

Tabelle 8: NetFlow Paket-Header

Hinzu kommt das Export-Format, welches in Abschnitt 3.2.6 beschrieben wird.

Der Anteil des NetFlow-Datenaufkommens am insgesamt zu verarbeitenden Datenaufkommen wird von Cisco typischerweise mit 1,5 % beziffert. Auf Kollektorseite können die Daten mit diversen Werkzeugen ausgewertet werden. Neben den vom Hersteller Cisco angebotenen Tools (u. a. Security MARS und Network Analysis Module, NAM) können auch kommerzielle Produkte anderer Hersteller (z. B. IBM Aurora, IsarNet, Arbor Networks etc.) sowie diverse frei verfügbare Software-Werkzeuge (z. B. MRTG) hierfür verwendet werden.

Die aktuelle Version von NetFlow ist Version 9, die am häufigsten eingesetzte ist die Version 5.

Version 5 bietet im Vergleich zur originalen Version 1 Erweiterungen für das Border Gateway Protocol (BGP), erweiterte Systeminformationen und Flow-Sequenznummern. Version 7 brachte die Unterstützung für den nativen und den Hybrid-Modus der Catalyst-Switch-Familie. In Version 8 kam das NetFlow-ExportFormat für die Unterstützung aggregierter Exports bei Cisco Routern hinzu. In der aktuellen Version 9 von NetFlow wurde das Export-Format umgebaut und unterstützt nun Vorlagen. Dies soll zukünftige Erweiterungen vereinfachen, die eingesetzt werden können, ohne das Format erneut umbauen zu müssen.

Die zwischen den oben genannten Releases liegenden Versionen 2-4, 6 und 8 kamen nicht bis zur Einsatzreife.

Seit geraumer Zeit bietet Cisco eine neue NetFlow-Variante an. Diese trägt den Namen Cisco IOS Flexible NetFlow und bietet unter anderem erweiterte Möglichkeiten für die Analyse von Netzwerk-Anomalien und Sicherheitsvorfällen.

Mögliche Probleme im Zusammenhang mit NetFlowNetFlow verwendet als Transportprotokoll das verbindungslose Protokoll UDP, welches bei Netzwerkproblemen zum Verlust von Daten während der Übertragung führen kann. Über die im Packet Header übertragene Sequence Number kann jedoch zumindest der Verlust von Informationen festgestellt werden. Problematisch ist außerdem die Übertragung der Daten in Klartext. Es kann also nicht ausgeschlossen werden, dass die übertragenen Informationen abgehört und verändert werden .


Logdatenstudie

3.1.6 IPFIX

Einsatz und HistorieIPFIX wird von der IETF als freier Standard eines Protokolls zur Verkehrsanalyse entwickelt. Das erste Entwurfsdokument zu IPFIX veröffentlichte das IETF im Februar 2002. Ziel der Arbeitsgruppe ist die Entwicklung eines offenen und damit frei implementierbaren, skalierbaren und sicheren Protokolls zur Übertragung von Monitoringdaten. IPFIX kann als Pendant zu Ciscos proprietärem NetFlow angesehen werden.

IPFIX soll die folgenden Zwecke erfüllen:

– Usage Based Accounting; Abrechnung von IP-Services, basierend auf Benutzern, genutzten Services etc.

– Traffic Profiling als Grundlage für Trendanalysen, Netzwerkplanung etc.

– Traffic Engineering als Grundlage für die Optimierung der Performanz und Auslastung des Netzwerkes wie in RFC 2702 beschrieben

– Attack/Intrusion Detection; beispielsweise das Erkennen von anomalem Datenverkehr oder Denial-of-Service-Attacken

– Quality of Service Monitoring; passives Überprüfen von Qualitätskriterien der IP-Flows

Zu diese Zwecken kann auch Cisco NetFlow verwendet werden. Eine weitere Fähigkeit von IPFIX ist aber die Übertragung der Daten über öffentliche Netze (Inter-Domain). IPFIX ist ein reines Push-Protokoll, was bedeutet, dass der Sensor in bestimmten Intervallen selbständig Daten an den Kollektor sendet.

Die statistische Auswertung von Monitoringdaten, wie sie IPFIX, liefert, kann in Korrelation mit ereignisbezogenen Logmeldungen Anhaltspunkte für anomales oder „sicherheitsbedenkliches“ Verhalten liefern und einen Mehrwert für IT-Frühwarnsysteme beisteuern.

Protokoll-AufbauZur Entwicklung und Identifizierung von Datenfeldern bietet IPFIX sog. Field Specifier, die Herstellern frei implementierbar zur Verfügung stehen. Zur Definition der in den Field Specifiern enthaltenen Datentypen werden sogenannte Information Element Identifier verwendet.

IPFIX baut auf einer verteilten Architektur auf. Die Schnittstelle zum Auslesen der Daten wird als Observation Point bezeichnet, die auf diesem laufenden Prozesse für den Abruf und Versand der Daten als Metering Process und Export Process. Die gesammelten Daten sendet der Export Process an einen oder mehrere Collecting Processes, welche meist auf einem entfernten System laufen. IPFIX bevorzugt als Transportprotokoll das Stream Control Transmission Protocol (SCTP) (RFC 2960), welches die folgenden Eigenschaften aufweist:

– Es ist ein verbindungsorientiertes Protokoll für IP-Netzwerke.

– Es beinhaltet Mechanismen zur Verhinderung von Kollisionen in IP-Netzwerken (Congestion-Avoidance).

– Es umfasst einen Schutz gegen Überflutungsversuche (Flooding) und

– einen Schutz gegen Attacken, bei denen eine falsche Identität vorgetäuscht wird (Masquerading).


Logdatenstudie

IPFIX kann auch auf Basis von TCP und UDP eingesetzt werden. Zur Absicherung der Kommunikation wird IPsec oder Transport Layer Security (TLS) empfohlen. Da Templates verwendet werden, ist IPFIX für Erweiterungen offen. Außerdem kann eine Gruppe von Field Specifiern einfach integriert werden, siehe auch Kapitel 3.2.5.

Mögliche Probleme im Zusammenhang mit IPFIXIPFIX verwendet zur Übertragung das verbindungsorientierte Protokoll SCTP, das die Vollständigkeit der Daten sicherstellt. Die Daten werden allerdings in Klartext übertragen, so dass das Abhören und Verändern von Informationen nicht unterbunden werden können. Wird ein Protokoll zur sicheren Übertragung von Daten auf der Vermittlungsschicht (beispielsweise IPsec oder TLS) verwendet, können die Datenströme gegen Mitlesen abgesichert werden.

3.1.7 Security Device Event Exchange (SDEE)

Einsatz und HistorieDas von Cisco Systems 2003 spezifizierte Protokoll zur Übertragung von Logmeldung von Intrusion-Detection-Systemen (siehe auch Abschnitt 3.2.9.1) hat bis heute außer bei Produkten des Herstellers Cisco keine Verbreitung gefunden. Seine Spezifikation ist aber offen erhältlich.

SDEE stellt eine konkrete Umsetzung der bekannten und erprobten SSL/TLS-Technologie für die Logdaten-Übertragung dar.

Protokoll-AufbauSDEE ist ein SOAP-basierendes Protokoll, welches jedoch noch ein Transportprotokoll benötigt. Bisher ist nur die Umsetzung auf der Basis von HTTP realisiert. SDEE erbt somit alle Eigenschaften HTTP-basierter Datenübertragung, insbesondere die verlässliche Zustellung durch TCP und die Möglichkeit, die Integrität und Vertraulichkeit der übertragenen Daten über SSL/TLS zu schützen (siehe Kapitel 3.1.10) und die beteiligten Kommunikationspartner zu authentifizieren. Für die Nutzung von SSL/TLS ist aber die entsprechende Unterstützung auf Server- wie Client-Seite notwendig.

Mögliche Probleme im Zusammenhang mit SDEEProblematisch ist vor allem der Einsatz von nicht SSL/TLS-basierter Kommunikation, also Klartext-HTTP, wenn Client und Server die Verschlüsselung nicht unterstützen. Ansonsten werden die potenziellen Probleme von TLS geerbt. Da sowohl auf Client- als auch auf Server-Seite jedoch gute eine Kontrolle der eingesetzten Software-Versionen stattfinden kann, ist die Verwendung veralteter, nicht mehr sicherer Algorithmen relativ leicht zu vermeiden.


Logdatenstudie

3.1.8 WMI für Windows Eventlog

Einsatz und HistorieDie Windows Eventlog-Architektur sieht bis einschließlich Windows 2003 von Haus aus keine zentrale Logdatensammlung und in diesem Zusammenhang auch keine spezielle Übertragung dieser Daten über das Netzwerk vor.

Microsoft hat mit der Windows Management Instrumentation (WMI) aber einen Mechanismus implementiert, bei dem mithilfe des Programms Windows Event Viewer („Windows-Ereignisanzeige“ in deutschen Windows-Versionen) Netzwerkabfragen über das Eventlog entfernter Windows-Rechner gestellt werden können. WMI steht seit Windows 2000 zur Verfügung und ermöglicht Systemadministratoren unter anderem. die eher bedarfsgetriebene Einsicht in lokal und nicht lokal vorgehaltene Logdaten. Erweiterungen für Windows ME und NT 4.0 sind verfügbar und implementieren WMI auch auf diesen älteren Betriebssystem-Versionen.

Des Weiteren ist mittlerweile eine Audit Collection System (ACS) genannte Windows-Erweiterung verfügbar, die auf einem Agenten-Kollektor-System aufbauend eine Zentralisierung der Windows Security Event Logs von über das Netzwerk erreichbaren Rechnern umsetzt. Sie ist Teil des neuen System Center Operations Managers (SCOM) 2007. Zentral wird hier eine SQL-Datenbank vorausgesetzt, weitere Komponenten sind der Agent auf den Einzelsystemen und die zentrale Kollektor-Komponente auf dem Datenbank-Server. ACS ist seit etwa Anfang 2007 als Teil der Beta-Version des SCOM erhältlich.

Protokoll-AufbauMicrosoft legt gegenüber Partnern und Kunden gewisse Schnittstellen (API) der Log-Architektur offen, dokumentiert jedoch nicht offen den Aufbau der darunter liegenden Protokolle oder Formate.

Die WMI-Kommunikation des Event Viewers basiert auf der RPC-Komponente (Remote Procedure Call) von Windows, die obligatorisch auf jedem Windows-System betrieben wird. Lokale Aufrufe funktionieren mit Named Pipes und werden nicht über Netzwerkschnittstellen geleitet. Für entfernte Verbindungen wird RPC-typisch ein dynamischer TCP-Port über den RPC-Portmapper-Dienst auf TCP/135 ausgehandelt. Die darauf folgende Kommunikation erfolgt optional verschlüsselt über 128-Bit RC4 (vor Windows Vista) bzw. AES (seit Windows Vista). Ob und wie verschlüsselt wird, ist eine Frage der Applikationsversionen auf beiden Enden der Kommunikation. Sie kann durch den Administrator nicht gezielt eingestellt werden.

Mögliche Probleme im Zusammenhang mit WMIRPC-basierte Protokolle sind an Firewalls aufgrund der dynamisch zugewiesenen Kommunikationsports schwierig zu filtern bzw. freizugeben. Die Firewall muss hierfür in der Lage sein, den Verbindungsaufbau über den RPC-Portmapper mitzulesen, was ein Verständnis für die spezielle RPC-Variante voraussetzt.

Der Einsatz von Verschlüsselungsalgorithmen sichert die Vertraulichkeit und Integrität der übertragenen Daten.

Problematisch ist in erster Linie die nicht offensichtliche Konfiguration der Kommunikationsverschlüsselung: Ob und wie verschlüsselt wird, hängt von den beteiligten Kommunikationskomponenten ab und kann im täglichen Betrieb nicht gezielt vom Administrator eingestellt werden. Man


Logdatenstudie

ist hier abhängig von einer sicheren Default-Konfiguration seitens des Herstellers. Eine unvollständige Dokumentation erschwert den Zugang zu WMI für Windows Eventlog zusätzlich.

WMI und der Event Viewer sind ferner nicht dazu geeignet, Windows Eventlogs zu zentralisieren. Sie beheben dieses Manko der Windows-Architektur nur unvollständig. Für eine aus Sicherheitssicht wünschenswerte konsequente Zentralisierung von Logdaten muss auf das neue SCOM von Microsoft oder auf Produkte dritter Hersteller zurückgegriffen werden.

3.1.9 Check Point Log Export API

Das offene Rahmenwerk zur Integration von Drittprodukten in die Firewall- und VPN-Produktpalette des Herstellers Check Point beinhaltet eine Schnittstelle zur sicheren Übertragung von Logdaten. Die Log Export API (LEA) genannte Schnittstelle ist integraler Bestandteil der Open Platform for Security (OPSEC), eines Rahmenwerkes zur Verbesserung der Interoperabilität zwischen den Produkten des Herstellers Check Point und denen anderer Hersteller.

Einsatz und HistorieDie Logdaten des Basisproduktes Firewall-1/VPN-1 liefern ereignisbezogene Meldungen, und zwar eine Sammlung der Logdaten der einzelnen Firewall-Installationen auf dem zentralen, Smart Center genannten Verwaltungssystem. Über die Logmeldungen sind folgende Informationen erfassbar:

– Meldungen der Firewall (Block/Accept)

– Authentifizierungsmeldungen (VPN)

– Meldungen des IDS/IPS (Smart Defense)

– Meldungen des Systems selbst

Jede Logmeldung bezieht sich auf einen entsprechenden Eintrag im SmartView Tracker der Firewall, der Applikation zur Ansicht und Analyse generierter Logs. Jeder Eintrag besteht aus einer festen Anzahl an Datenfeldern, siehe Kapitel Fehler: Referenz nicht gefunden.

Das OPSEC-Rahmenwerk bietet proprietäre Programmierschnittstellen (API), die offengelegt sind. Ein Hersteller von Sicherheitsprodukten, der sein Produkt mit denen von Check Point verbinden möchte, kann sich über die Webseite von OPSEC registrieren und gegebenenfalls zertifizieren lassen. OPSEC kann durch die Marktverbreitung von Check Point Firewalls als De-facto-Industriestandard angesehen werden, ein RFC-Status oder Ähnliches besteht jedoch nicht.

Protokoll-AufbauDer Hersteller Check Point empfiehlt beim Aufbau der Lösung für größere Installationen eine verteilte Architektur. Die Logmeldungen werden von den separat installierten Firewall-Modulen (Enforcement Points) generiert, welche diese an ein entferntes SmartCenter-Management zur Konsolidierung senden. Dieses wiederum schickt die Meldungen an den sogenannten LEA-Client, sobald sich dieser erfolgreich mit dem SmartCenter-Management verbindet (Push-Mechanismus). Welche Ereignisse von der jeweiligen Firewall protokolliert werden, ist in der Richtlinie (Security Policy) pro Firewall-Regel einzustellen.

OPSEC LEA benutzt für die Übertragung optional das Protokoll Secure Socket Layer (SSL), welches im Abschnitt 3.1.10 näher beschrieben ist. Die Authentifizierung erfolgt über die Mechanis


Logdatenstudie

men SSLCA und FWN1 in Verbindung mit der sogenannten „Secure Internal Communication“ (SIC) des Herstellers.

Vorbereitend für den Aufbau einer LEA-Verbindung muss die Datei „$FWDIR/conf/fwopsec.conf“ am SmartCenter-Management dahingehend konfiguriert werden, ob eine reine Authentifizierung mit Klartextübertragung oder die vollständige Anwendung von SSL erreicht werden soll. Als Kommunikationsport ist per Default TCP/18184 vorgesehen.

Es existiert die folgende Auswahl an Kommunikationsvarianten:

– auth-opsec für die reine Authentifizierung über OPSEC-Mechanismen

– auth-ssl für eine Passwort-Authentifizierung und SSL-Verschlüsselung

– auth-sslca für eine zertifikatsbasierte Authentifizierung und SSL-Verschlüsselung

Mögliche Probleme im Zusammenhang mit OPSEC LEABeim Transport von Logdaten einer Check Point Firewall sind zumindest authentifizierte Verbindungen unverzichtbar. Dennoch ist das noch sicherere SSL zur sicheren Übertragung und Authentifizierung zu bevorzugen, da es auch die Daten an sich bei der Übertragung verschlüsselt. SSL garantiert in Verbindung mit dem darunter liegenden Transportprotokoll TCP die Integrität, Authentizität und Vertraulichkeit der übertragenen Daten.

3.1.10 SSL-verschlüsselte Übertragung

Secure Sockets Layer (SSL) ist weithin bekannt als Protokoll zur verschlüsselten Übertragung von Webverkehrsdaten, z. B. im Online-Banking. Der Name wird dabei fälschlicherweise oft äquivalent mit HTTPS verwendet, obwohl HTTPS nur die Umsetzung von SSL im Bereich HTTP ist und zur Verschlüsselung von Webtraffic während des Datentransports dient. Mit SSL lassen sich aber auch ganz andere Datenformate und Inhalte verschlüsselt übertragen und findet das Protokoll beispielsweise auch im Bereich der E-Mail-Kommunikation (SMTP über SSL, verschlüsseltes POP3) Verwendung. In diesem Kapitel wird beschrieben, welche zunehmend starke Rolle SSL bei der Übertragung von Logdaten spielt.

Einsatz und HistorieUrsprünglich wurde SSL durch die Firma Netscape 1993 eingeführt, um im Internet eine Ende-zu-Ende-Verschlüsselung, die Vertraulichkeit der übertragenen Daten und eine Authentifizierung der Server-Seite zu ermöglichen. Zwar ist SSL der gängigste Begriff, korrekterweise muss in den aktuellen Versionen jedoch bereits von einer Transport Layer Security (TLS) gesprochen werden. Mittlerweile sind SSL und sein Nachfolger TLS durch entsprechende RFCs Allgemeingut geworden und es existiert eine IETF-Arbeitsgruppe, die sich der Weiterentwicklung des Protokolls gewidmet hat. Die TLS-Versionen 1.0 und 1.1 entsprechen der standardisierten Weiterentwicklung von SSL oberhalb von Version 3.0. Im Folgenden werden beide Protokolle der Einfachheit halber nur mit SSL bezeichnet.

Die Gründe dafür zunehmenden Einsatz von SSL liegen auf der Hand:

– SSL läuft über TCP und erbt damit gegenüber UDP-basierter Kommunikation (wie beispielsweise bei Syslog) den Vorteil der Zuverlässigkeit der Verbindung. TCP-basierte Protokolle sind im Zweifelsfall auch besser an Firewalls zu filtern.


Logdatenstudie

– Über die Verschlüsselung wird die Vertraulichkeit der übertragenen Daten gewährleistet.

– Die Möglichkeit, zur Programmierung auf aktuell gehaltene und frei verfügbare Open-Source-Bibliotheken zurückzugreifen, reduziert den Entwicklungsaufwand für Hersteller.

– Die Authentisierung kann bei SSL sowohl für den Client als auch für den Server über Zertifikate erfolgen. Im Zusammenhang mit der Übertragung von Logdaten kann durch den Einsatz von SSL daher Authentizität von Logdaten sichergestellt werden.

Die verschlüsselte Übertragung über SSL erbt die Vorzüge einer ausgereiften und erprobten Webtechnologie und findet sich in immer mehr Produkten eingebaut wieder. Allerdings sind auch gegen eine SSL-gesicherte Übertragung Angriffe möglich, beispielsweise wenn die zur Authentisierung verwendeten Zertifikate nicht richtig geprüft werden.

Wie in Kapitel 3.1.2 skizziert ist im Rahmen der Weiterentwicklung des in Sicherheitshinsicht ungenügenden Syslog eine Verwendung von SSL/TLS als unterliegender Sicherheitsarchitektur bereits in Planung.

Protokoll-AufbauSSL ist im OSI-Modell oberhalb von TCP als Transportprotokoll und unterhalb des eigentlich gewünschten Anwendungsprotokolls (z. B. HTTP) angesiedelt. Ähnlich wie IPsec besteht es aus zwei Teilgruppen von Unterprotokollen, dem symmetrisch verschlüsselnden SSL Record Protocol zur eigentlichen Datenübertragung und dem mit asymmetrischen Kryptographie-Algorithmen arbeitenden SSL Handshake Protocol zum initialen Verbindungsaufbau, zur optionalen Authentifizierung der beiden Kommunikationspartner und zum Aushandeln des im Datenkanal verwendeten symmetrischen Schlüssels.

Im Webbereich findet typischerweise eine serverseitige Authentifizierung statt, diese ist jedoch genau wie die clientseitige Authentifizierung nur optional. Sie wird beidseitig auf der Basis von X509-Zertifikaten umgesetzt. Während des Kommunikationsaufbaus erfolgt die Server-Authentifizierung zeitlich vor der clientseitigen Authentifizierung.

Es sind des weiteren Zeitstempel-Mechanismen zur Abwehr von Replay-Attacken implementiert.

Die Protokoll-Suite SSL ist flexibel bezüglich der Verwendung verschiedenster Hash- und Verschlüsselungsfunktionen sowie des darüber liegenden Anwendungsprotokolls. Die konkrete Einigung auf identische Funktionen und ihre Versionen auf Client- wie Server-Seite ist Teil des Kommunikationsaufbaus.

Mögliche Probleme im Zusammenhang mit SSL/TLSAngriffe gegen SSL-gesicherte Verbindungen sind insbesondere dann möglich, wenn die vorhandenen Sicherheitsmechanismen nicht korrekt umgesetzt werden. Beispielsweise ermöglicht eine nicht richtig implementierte Zertifikatsprüfung Man-in-the-middle-Attacken, und die Verwendung von Verschlüsselungsalgorithmen mit zu kurzen Schlüssellängen oder schwacher Hashfunktionen erleichtert Angriffe gegen die Vertraulichkeit.

Durch die bei SSL notwendigen Verschlüsselungsoperationen kann es zu Performanceproblemen kommen, wenn beispielsweise auf einem Logdaten-Kollektor viele gleichzeitige Verbindungen behandelt werden müssen. In bestimmten Einsatzszenarien kann deswegen der Einsatz spezieller Hardware zur Beschleunigung der Kryptooperationen notwendig werden.


Logdatenstudie

Insgesamt bietet der Einsatz von SSL bei der Übertragung von Log- und Monitoringdaten aber einen deutlichen Sicherheitsgewinn, wenn man in Betracht zieht, dass die beschriebenen Protokolle meist keine integrierten Sicherungsmechanismen besitzen.

3.1.11 Tabellarischer Überblick und Zusammenfassung

Name UDP/TCP, Port Verschlüsselung Proprietär EinsatzgebieteSyslog UDP 514 Nein Offen Unix, NetzwerkSNMP UDP 161+162 Ab Version 3 Offen ÜberallNetFlow UDP 2055 Nein Proprietär,

offengelegtNetzwerk

IPFIX UDP+TCP 4739 Nein Offen NetzwerkWindows WMI RPC, viele Ports Nein Proprietär,

freie APIWindows

OPSEC LEA TCP 18184 Optional Proprietär, freie API

Check Point VPN-1

SSL TCP, meist 443 Ja Offen Überall

Tabelle 9: Protokollübersicht: Protokolle und ihre Funktionen

Zusammenfassend kann man festhalten, dass es zwar sichere Protokolle zur Übertragung von Log- und Monitoringdaten gibt, gerade aber die eigens für diesen Zweck entwickelten Protokolle Sicherheitsaspekte unberücksichtigt lassen bzw. nur in veralteten unsicheren Varianten zur Verfügung stehen.

Eine konsequente Weiter- bzw. Neuentwicklung dieser Protokolle, vor allem. des stark verbreiteten syslog-Protokolls, wäre deshalb wünschenswert. Im Abschnitt Standardisierungsbestrebungen wird beschrieben, wie der Stand der diesbezüglichen Standardisierungsbestrebungen aktuell ist.

3.2 Formate zur Speicherung von Log- und Monitoringdaten

Bei den bereits zahlreichen Methoden, Logdaten über das Netzwerk zu versenden und verfügbar zu machen, gibt es vor allem im Bereich der verwendeten Formate zur Speicherung von Log- und Monitoringdaten eine schier unüberschaubare Vielfalt. Dies ist einerseits bedingt durch die vielen verschiedenen Anwendungsbereiche, aus denen die gemeldeten Informationen stammen, aber sicher auch gefördert durch die proprietäre Ansätze von Herstellern und fehlende Abstimmung in diesem Feld. Andererseits fehlt die Abstimmung nicht zuletzt deswegen, weil die Logdaten zu sehr vielen verschiedenen Zwecken eingesetzt werden können. Der ursprüngliche Zweck der Protokollierung von Systemmeldungen war sicherlich in erster Linie die Fehlersuche. Die Verwendung von Logdaten im Zusammenhang mit der Aufklärung von Sicherheitsvorfällen oder gar in IT-Frühwarnsystemen stand dabei bisher zu keiner Zeit im Vordergrund.

Die Probleme werden spätestens dann offensichtlich, wenn man über die vereinzelt abgespeicherten Logdateien hinausdenkt und den Faden spinnt hin zu einer zentralen Sammlung und Korrelation der protokollierten Informationen. Ein notwendiger Schritt hierzu ist nämlich die Normalisierung der Informationen, um ihre maschinelle Weiterverarbeitung zu ermöglichen. Nicht-standardisierte For


Logdatenstudie

mate und vor allem für das menschliche Auge optimierte Darstellungsformen erschweren das sogenannte Parsing der Log- und Monitoringdaten immens.

3.2.1 Allgemeine Überlegungen zu Formaten

Bevor spezielle Logformate beschrieben werden, wird im folgenden Abschnitt zunächst diskutiert, welche Varianten in den verschiedenen Aspekten prinzipiell existieren.

Binär- oder Klartext, Lesbarkeit für Maschinen oder für MenschenDie am einfachsten zu beantwortende Frage für den Betrachter von Logdaten ist die nach dem Klartextformat bzw. Binärformat. Binärformate sind primär für die Verarbeitung durch Rechner entworfen, ihre Inhalte entziehen sich zunächst dem menschlichen Auge. Klartextformate wiederum liegen in verschiedenen Ausformungen der Lesbarkeit auch für den Menschen vor: zum einen besteht vor allem im Unix-Bereich das Ziel, vor allem dem Menschen, in der Regel den Systemadministratoren, Aufschluss über aktuelle Ereignisse auf dem lokalen System zu geben. Dementsprechend enthalten Logmeldungen hier sogar oft Formulierungen in Form von ganzen Sätzen. Andere Klartextformate gehen einen Mittelweg zwischen Maschinenlesbarkeit und der „Human Readability“, indem sie streng formatiert, aber im Klartext protokollieren – z. B. mit vorgegebenen kommaseparierten Feldern.

Klartextformate bringen den großen Nachteil mit sich, dass sie vergleichsweise große Datenmengen generieren. Oft wiederholen sich redundante Informationen in gleichartigen Meldungen. Klartextformate sind schlichtweg hinderlich, wenn ihnen die standardisierte Form fehlt, welche eine maschinengestützte Weiterverarbeitung ermöglicht. Sie stehen dann insbesondere der Verwendung im Rahmen eines IT-Frühwarnsystems als nicht zu unterschätzendes Hindernis im Weg.

Binärformate dienen in der Regel dem Ziel, die Loginformationen möglichst effizient zu speichern. Sie erlauben z. B. eine von der Systemlokalisation unabhängige Darstellung, die Vermeidung redundanter Textblöcke wie bei Klartextformaten und auch die leichte Anpassbarkeit einer lesbaren Darstellung mit geeigneten Lese-Programmen an die jeweilige Lokalisation, beispielsweise hinsichtlich der jeweils geforderten Datumsformate. Ein Nachteil binärer Formate ist die unbedingte Notwendigkeit eines Hilfsprogramms (z. B. des Windows Event Viewers), um die Meldungen für den Menschen lesbar zu machen , was wiederum mit Rechenaufwand verbunden ist: Die Anreicherung der im Prinzip ja skelettierten Informationen setzt ein Framework von Dekodierungstabellen voraus. Beispielsweise muss während der Darstellungsberechnung vom Rechner nachgesehen werden, was die Beschreibung zu Windows Event-ID 524 ist, um diese dann dem Ereignis im Event Viewer hinzuzufügen.

ZeichensätzeDie Verwendung von regional unterschiedlichen Zeichensätzen für die gespeicherten Loginformationen ist charakteristisch für Klartextformate. Beispielsweise werden in Deutschland Umlaute verwendet, die im amerikanisch-englischen Standard-Zeichensatz nicht enthalten sind und auch nicht dargestellt werden können.

Unterschiedliche Zeichensätze werden in Binärformaten bewusst umgangen, beispielsweise beim Windows Eventlog Format.


Logdatenstudie

Entsprechend sollte ein Klartextformat in der Lage sein, unterschiedliche oder universelle Zeichensätze zu unterstützen, auch wenn dies zu einem höheren Speicherplatzbedarf führt.

Mehrzeilige MeldungenEin immer wieder anzutreffendes Merkmal von Logformaten ist die Abweichung von einzeiligen Meldungen. Stattdessen verteilt sich die einzelne Meldung über mehrere Logzeilen und ihr Sinn ergibt sich erst durch die Berücksichtigung aller Zeilen. Weiteres Manko ist hier zudem oft, dass nicht kenntlich gemacht wird, wann eine einzelne Meldung anfängt und wann sie aufhört. Dies erschließt sich dann in der Regel nur durch den Kontext.

Für eine maschinelle Verarbeitung von Logdaten ist die einzeilige Form pro Ereignis klar vorzuziehen.

TrennzeichenEin in seinen Grundzügen oft anzutreffendes Klartextformat sind aneinandergereihte Werte, die durch ein Trennzeichen voneinander getrennt werden. Oft ist dies ein Komma, häufiger noch ist hier das Tabulatorzeichen anzutreffen. Diese Formate lassen sich insgesamt unter dem Begriff CSV-(Comma Separated Values) ähnliche Formate zusammenfassen. Hier wird pro Zeile eine Logmeldung geschrieben.

Der Nachteil dieser Formate besteht darin, dass meist nicht in jeder einzelnen Logmeldung alle möglichen Felder mit Werten versehen sind, und oft treten leere Felder auf. Die Identifikation der einzelnen Felder erfolgt durch ihre Position in der Reihe von Einzelfeldern.

Wünschenswert ist bei CSV-Formaten die Kenntlichmachung der Bedeutung der einzelnen Felder durch eine Zeile für die Überschrift (Header) pro Logdatei.

CSV-ähnliche Formate werden gerne dort verwendet, wo gleichartige Meldungen vorkommen oder die Menge an grundlegend verschiedenen Meldungen stark beschränkt ist. Bestes Beispiel hierfür sind Access-Logs von Web Proxies, die für jeden Seitenaufruf Standard-Informationen protokollieren. Ein Beispiel für eine Anwendung, bei der sich dieses Format weniger eignet, ist E-Mail: die möglichen Meldungen in diesem Bereich reichen von Meldungen auf SMTP-Ebene (Protokoll-Abläufe) über die Envelope-Analyse („Absender auf einer Blacklist“) bis hin zu Aussagen über den Inhalt der E-Mail („Virus gefunden“).

Mit Tags versehene FelderFür das letzte Beispiel der E-Mail eignet sich viel besser ein variables Format, das nur die in der jeweiligen Meldung wichtigen Informationen in einem dennoch standardisierten Format mitschreibt. Ein solches besteht aus einem einzeiligen Format, nur nicht-leere Werte werden in die Logmeldung aufgenommen. Dies führt zu einer variierenden Anzahl von Feldern bei unterschiedlichen Logmeldungen. Auch entspricht beispielsweise das vierte Feld nicht immer dem Wert der Quell-IP-Adresse. Um hier eine Zuordnung einer Bedeutung zu einem Wert überhaupt zu ermöglichen, wird dem jeweiligen Wert die Bedeutung in Form eines Tags beigefügt, z. B. „Quell-IP-Adresse=10.0.0.1“. Dieses Format wird im Englischen allgemein als „named-value pair“-Format bezeichnet.

Zeitstempel und DatumsangabenZeitstempel und Datumsangaben sind ein relativ problematischer Aspekt von Logformaten. Dies ist durch die starke regionale Abhängigkeit der Zeit- und Datumsdarstellung bedingt: im angelsächsi


Logdatenstudie

schen Raum wird das Datum beispielsweise oft in der Form MM/DD/YY angegeben (MM: Monat aus dem Bereich 1-12, DD: Tag aus dem Bereich 1-31, YY: die letzten zwei Stellen der Jahresangabe). Uhrzeiten weden selbst in der EDV oft noch in der a.m./p.m.-Notierung angegeben. Weitere Probleme können dadurch entstehen, dass nicht klar ist, ob eine Zeitangabe sich auf die Ortszeit des Systems, oder auf die „Standardzeit“ UTC (Coordinated Universal Time) bezieht. Fehlinterpretationen sind hier deshalb an der Tagesordnung. Die Weiterverarbeitung entsprechender Logmeldungen kann nicht ohne die initiale Konfiguration des Parsers durch den Menschen auskommen.

Vor allem im Unix-Bereich mangeln Zeitstempel zudem daran, dass ihnen konsequent die Jahreszahl-Angabe fehlt. Dies ist im Kontext der IT-Frühwarnung weniger problematisch als bei der Forensik, bei der auch weiter zurückliegende Ereignisse betrachtet werden.

3.2.2 Microsoft-Betriebssysteme und -Anwendungen

Bis vor kurzem waren Microsoft-Produkte noch durch ein einheitliches binäres Event-Format über die wichtigsten Betriebssystem-Bereiche hinweg gekennzeichnet. Diese bis Windows Server 2003 durchgehaltene Architektur wurde für Windows Vista durch eine neue Eventlog-Architektur ersetzt, die den neuen Microsoft-Standard darstellt.

3.2.2.1 Windows NT bis Server 2003 Event Log

Windows-Betriebssysteme, die auf Windows NT aufbauen, haben bis einschließlich Windows Server 2003 ein binäres Ereignis-Format, das sich in der bei Microsoft unter dem Begriff „Event Logging“ laufenden Log-Architektur einordnet, im Gegensatz zum weiterentwickelten „Windows Eventlog“, wie die Bezeichnung ab Windows Vista lautet.

Microsoft begründet die Verwendung eines binären Ereignis-Formats mit folgenden Argumenten:

– Platzverbrauch: Maschinenlesbare Formate sind im Gegensatz zu im Klartext lesbaren Formaten effizienter speicherbar. Beispielsweise wird die Ereignisbeschreibung nicht in jedem Ereignis gespeichert, sondern der Beschreibungstext wird nur referenziert und nach Bedarf bei der Überführung in eine lesbare Form mit anderen Event-Daten zusammengeführt (z. B. Rendering des Events im Event Viewer).

– Fälschungssicherheit: Im Klartext lesbare Formate sind durch Menschen leicht fälschbar.

– Weiterverarbeitung: Maschinenlesbare Formate eignen sich ggf. für eine maschinelle Verarbeitung besser als durch Menschen lesbare Klartextformate.

– Unabhängigkeit von lokalen Einstellungen: Format-Vorgaben z. B. für Datum und Uhrzeit variieren regional, die Größen sind binär, aber eindeutig darstellbar.

Die Umsetzung eines maschinenlesbaren Formats im Event Logging hatte in der Vergangenheit allerdings auch einige Nachteile. Hierzu gehörten:

– Beschränkung der Ereignissammlung auf lokale Maschinen, fehlende Möglichkeit zur zentralen Sammlung von Ereignissen

– Rechnerübergreifende Ereignisabfragen sind nur über das RPC-Protokoll möglich.

– Die eingebaute Größenbeschränkung des Eventlogs macht die Auslagerung jeder umfangreicheren Debug-Information in eine eigens anzulegende Datei notwendig.


Logdatenstudie

– Es besteht die Notwendigkeit eines entsprechenden Werkzeugs, um die Ereignisse lesen zu können.

Die Ereignisse werden bei Windows-Betriebssystemen in den folgenden drei Teil-Logdateien abgespeichert:

– Systemlog (englisch „system log“) SysEvent.evt

– Anwendungslog (englisch „application log“) AppEvent.evt

– Sicherheitslog (englisch „security log“) SecEvent.evt

Bei Domänen-Controllern (ab Windows 2000) gibt es zusätzlich noch diefolgenden Logdateien:

– DNS-Dienst

– Verzeichnisdienst

– Verzeichnisreplikationsdienst

Diese Dateien liegen im Verzeichnis %WINDIR%\system32\config. Sie sind während der Laufzeit des Betriebssystems vor direktem Zugriff geschützt.

Weitere, vor allem Platz beanspruchende Debug-Loginformationen werden in der Regel nicht in den größenbeschränkten Ereignisdateien abgespeichert, werden in einem jeweils dem Zweck angemessenen Klartextformat im Ordner %WINDIR%\Debug\ abgelegt. Dadurch soll verhindert werden, dass wichtige Ereignisse überschrieben werden und verloren gehen.

Microsoft hat im Laufe der Jahre und über die Windows-Versionen hinweg Schnittstellen geschaffen, so dass mittlerweile auch andere Applikationen in die Windows-Ereignisdateien schreiben können, insbesondere auch in das Sicherheitslog.

Konfigurierbar ist unter Windows die Genauigkeit, mit der die Sicherheitsüberwachung durchgeführt wird (Auditierung). Diese wird innerhalb einer Windows-Domäne zentral erstellt und per Richtlinie auf alle Windows-Rechner verteilt.

Die Ereignis-Protokollierung wird durch den Windows-Ereignisprotokoll-Dienst automatisch verwaltet und überwacht.

Das Format der Ereignisse ist in der Darstellung durch das Programm Ereignisanzeige (Event Viewer) in folgende Felder unterteilt:


Logdatenstudie

Feld (Deutsch) Feld (Englisch) BeschreibungDatum Date Datumsangabe für das EreignisUhrzeit Time Uhrzeit des EreignissesTyp Type Log-Level bzw. Priorität des EreignissesBenutzer User Zum Zeitpunkt des Ereignisses angemeldetes BenutzerkontoComputer Computer Computer, auf dem das Ereignis stattgefunden hatQuelle Source Dienst, Programm oder Komponente, das das Ereignis ge

meldet hatKategorie Category Ereignis-Klassifizierung, die meist im Sicherheitslog vorge

nommen wirdEreigniskennung Event ID Eindeutige Zahl zur Identifikation des EreignissesBeschreibung Description Möglichkeit der näheren Beschreibung des Events

Tabelle 10: Felder einer Meldung im Windows Event Log bis Windows Server 2003

Windows kennt folgende Ereignistypen (Log-Level):

– Information: Das Ereignis beschreibt die erfolgreiche Durchführung einer Aufgabe oder eines Vorgangs, z. B. erfolgreicher Start des Dienstes

– Warnung/Warning: Anzeige eines möglichen (zukünftigen) Problems, z. B. volllaufende Festplatte

– Fehler/Error: Anzeige eines nennenswerten Problems, das Funktionseinschränkungen zur Folge haben kann, z. B. fehlgeschlagener Start eines Dienstes

– Erfolgsüberwachung / Success Audit: Erfolgreiche Durchführung eines sicherheitsüberwachten Vorgangs, z. B. erfolgreiche Benutzer-Anmeldung am System

– Fehlerüberwachung / Failure Audit: Fehlgeschlagene Durchführung eines sicherheitsüberwachten Vorgangs, z. B. fehlgeschlagene Benutzer-Anmeldung am System

3.2.2.2 Windows Eventlog ab Windows Vista

Microsoft hat für die künftigen Windows-Versionen in Windows Vista eine Neuordnung des Windows-Ereignissystems vorgenommen, welches nun unter dem Begriff „Windows Eventlog“ läuft. In Windows Vista ist die Version Windows Event Logging 6.0 integriert.

Die Speicherung der Events ist nach wie vor binär, es gibt aber eine Reihe von Weiterentwicklungen gegenüber dem alten System:

– Die Darstellung und der Export von Ereignissen ist nun auch im XML-Format möglich.

– Es gibt eine Reihe neuer Typen von Logdateien, die nicht mehr Themen- sondern Zweck-bezogen gesammelt werden: Debug-Logs, administrative Logs, Analyselogs, Set-Up-Logs usw.

– Die vorher in einem eigenen Ordner im Klartext-Format gespeicherten Debug-Logdateien sind nun in eine innerhalb des Betriebssystems zentralisierte Aufbewahrung und Ansicht integriert worden.


Logdatenstudie

Die Ereignisanzeige ist nun wesentlich leistungsfähiger und erlaubt das Erstellen und Speichern von Filtern und Ansichten zur Analyse von Ereignissen.

Microsoft hat für die neue Version des Windows Eventlog Schnittstellen bereitgestellt, so dass andere Applikationen Ereignisse an das Logging-System versenden , auf gespeicherte Events zurückgreifen, sich über neue Events benachrichtigen lassen oder binäre Events in ein geeignetes Format überführen können. Diese Schnittstellen sind im Internet veröffentlicht und können über folgende Adresse erreicht werden :

http://msdn2.microsoft.com/en-us/library/aa385780.aspx

Auf Beispiele für Ereignisse wird hier aufgrund des Binärformats der Darstellung verzichtet. Windows-Formate können maschinell nur schlecht weiterverarbeitet werden, da eine Offenlegung des Binärformats nicht verfügbar ist.

3.2.3 Unix-artige Betriebssysteme

Das Betriebssystem-Logging auf Linux und anderen Unix-Derivaten basiert traditionell auf syslog. Jedes Derivat liefert von Haus aus sein eigenes syslogd-Programm mit. Neben der bereits im Abschnitt 3.1.2 beschriebenen Möglichkeit, die Ereignisse über das Netzwerk und das Syslog-Protokoll zu versenden, gibt es vor allem das per Default aktivierte lokale Logging im lokalen Dateisystem. Diese Variante wird im Folgenden näher erläutert.

Der jeweilige Syslog-Daemon ist als zentrale Komponente zur Verwaltung der Fehler- und sonstigen Log-Meldungen der verschiedenen Systemkomponenten konzipiert. Dazu senden die einzelnen Prozesse und Daemons ihre Meldungen über „Unix Domain Sockets“an den syslogd. Dieser kann die empfangenen Meldungen an verschiedene Ziele weiterreichen:

– an lokale Logdateien (moderne syslogd-Varianten unterstützen auch Named Pipes),

– an die Systemkonsole (meist werden diese Meldungen auf dem Bildschirm ausgegeben),

– an angemeldete Benutzer über deren Shell sowie

– an einen anderen Rechner über das Netzwerk

In der zentralen Konfigurationsdatei syslog.conf wird das Verhalten des Daemons eingestellt. Sie ist derivatabhängig beispielsweise im /etc-Verzeichnis oder auch einem Unterverzeichnis hiervon zu finden.

Folgende typische Konfigurationszeile soll die Konfiguration des Syslog-Daemons beispielhaft illustrieren. Sie stammt aus einer Solaris-Variante von Syslog:*.err;kern.notice /dev/sysmsgZuerst werden die Syslog-Facilities mit Error-Level in einer Punkt-getrennten Notation aufgeführt. Der Stern dient als Platzhalter für beliebige Facilities. Mehrere Facility-Error-Level-Kombinationen lassen sich durch Strichpunkte separiert hintereinander auflisten. Die Angabe eines Error-Levels trifft auf alle Meldungen mit diesem Error-Level oder höher zu. Tabulatorsepariert wird zum Ende der Konfigurationszeile das Ziel der zutreffenden Meldungen angegeben. Pro Zeile kann nur ein Ziel festgelegt werden.

Als Ziele kommen neben lokalen Dateien, für die der absolute Pfad angegeben werden muss, kommagetrennte Aufzählungen lokaler Benutzer oder Netzwerkrechner infrage:*.err;kern.notice;auth.notice /dev/sysmsg


http://msdn2.microsoft.com/en-us/library/aa385780.aspx

Logdatenstudie

*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages*.alert;kern.err;daemon.err operator*.alert root*.emerg *mail.debug @loghostDie Weiterleitung an einen Netzwerkrechner wird mit @ eingeleitet, direkt gefolgt vom Host-Namen des Zielrechners. Im obigen Beispiel werden also Nachrichten aus der Facility mail.debug an den Rechner loghost weitergeleitet.

Bei den Zielen bedeutet ein Stern „alle angemeldeten Benutzer“.

Der Sylog-Daemon wird in allen Runlevels mit root-Rechten gestartet.

Typische System-Logdateien verschiedener Derivate sind in folgender Tabelle aufgeführt:

Unix-/Linux-Derivat Logdatei für SystemmeldungenSolaris /var/adm/messagesAIX Muss konfiguriert werdenRedhat ES /var/log/messagesNovell ES /var/log/messagesFree-BSD Muss konfiguriert werden

Tabelle 11: Speicherorte für Meldungen in Unix-/Linux-Derivaten

Moderne syslogd-Versionen bieten die genauere Auswahl von Error-Levels an, z. B. „alle Error-Level außer INFO“ oder „alle Error-Level bis ALERT“. Auf zunehmend vielen Systemen wird der klassische Syslog-Daemon durch das leistungsfähigere und besser konfigurierbare syslog-ng abgelöst.

Die automatische Rotation und Komprimierung lokaler Logdateien ist Aufgabe separater Programme wie logrotate. Es empfiehlt sich, eine regelmäßige Rotation (z. B. täglich um Mitternacht) mit einer Komprimierung der alten Logdatei zu verknüpfen. Die Dauer der Aufbewahrung alter Logdateien muss normalerweise angepasst werden: Standardmäßig sind hier oft zu geringe Zeiten von einer Woche eingestellt.

Das Format der per Syslog gesammelten Logmeldungen folgt der in Kapitel 3.1.2 beschriebenen Spezifikation. Formate aus dem Unix-Umfeld können maschinell schlecht weiterverarbeitet werden, da sie wie bereits erwähnt weitgehend aus „Freitext“ bestehen. Als Beispiel für Kernel-Meldungen können folgende Zeilen dienen:

Feb 11 19:51:22 localhost kernel: [17180115.628000] scsi1 : SCSI emulation for USB Mass Storage devicesFeb 11 19:51:27 localhost kernel: [17180120.632000] Vendor: Apple Model: iPod Rev: 1.62Feb 11 19:51:27 localhost kernel: [17180120.632000] Type: Direct-Access ANSI SCSI revision: 00Feb 11 19:51:27 localhost kernel: [17180120.636000] SCSI device sda: 1982464 2048-byte hdwr sectors (4060 MB)Feb 11 19:51:27 localhost kernel: [17180120.636000] sda: Write Protect is offFeb 11 19:51:27 localhost kernel: [17180120.636000] SCSI device sda: 1982464 2048-byte hdwr sectors (4060 MB)


Logdatenstudie

Feb 11 19:51:27 localhost kernel: [17180120.640000] sda: Write Protect is offFeb 11 19:51:27 localhost kernel: [17180120.640000] sda: sda1 sda2

3.2.4 Für SNMP-Traps verwendetes Format

Das Simple Network Management Protocol (SNMP) liest die Informationen für Object Identifier aus Speicherbereichen aus, es handelt sich somit um binäre Daten. Diese werden dann vom empfangenden System nach Bedarf in andere Formate umgewandelt.

SNMP nutzt zur Definition der abrufbaren Object Identifier die Abstract Syntax Notification One (ASN.1), eine formelle Beschreibungssprache zur Definition sowohl der Object Identifier als auch ihrer Werte.

Wie in Abschnitt 3.1.4 bereits beschrieben werden alle verfügbaren Object Identifier zu einer oder zu mehreren MIBs zusammengefasst, welche ihrerseits in der Definitionssprache SMI beschrieben werden.

Da es sich bei den MIBs um Binärdaten handelt, muss an dieser Stelle auf ein Beispiel verzichtet werden.

3.2.5 IPFIX-Format

Die per IPFIX-Protokoll übertragenen Daten werden aus dem Rechner-Cache für die abzufragenden Statistiken ausgelesen und in das IPFIX-Transportprotokoll gekapselt. Die Daten liegen dort im Binärformat vor.

Eine IPFIX-Nachricht beginnt mit einem Message Header gefolgt von mindestens einem sog. Record Set. Jedes der enthaltenen Record Sets entspricht einem von drei möglichen Set-Typen:

– Data Set

– Template Set

– Options Template Set

Die im Message Header übertragenen Datenfelder sind diese:

Feldname BeschreibungVersion Number Version des übertragenen Flow Record Format Length Gesamtlänge der Nachricht vom Message Header bis zu den ent

haltenen SetsExport Time Zeit in Sekunden (UTC) bei der Generierung der NachrichtSequence Number Inkrementelle Sequenznummer Modulo 2^32 aller IPFIX Data Re

cords innerhalb des SCTP-Streams der aktuellen Observation Domain

Observation Domain ID Eindeutige 32-Bit-Identifikationsnummer der Observation Domain des Export-Prozesses.

Tabelle 12: Felder im Message Header von IPFIX


Logdatenstudie

Da IPFIX herstellerspezifisch erweiterbar ist, wird eine Unterscheidung zwischen IETF-spezifizierten und Enterprise-spezifizierten Informationselementen notwendig. Diese in jedem Record Set übertragene Information enthält folgende Datenfelder:

Feldname Beschreibung Enterprise Bit Field Specifier Bit

0 für Typ IETF1 für Typ Enterprise

Information Element Identifier Identifikationsnummer des Informationselements (nur bei Feldern des Enterprise-Typs)

Field Length Länge des entsprechenden Informationselements in OktettenEnterprise Number IANA Enterprise Number, der das Informationselement zugehört

Tabelle 13: Felder im Record Set von IPFIX

Ein Record Set ist eine generische Bezeichnung für einen oder mehrere Datensätze (Records) mit jeweils derselben Struktur. Am Anfang eines Sets steht der Set Header. Optional wird am Ende des Sets ein sog. Padding-Feld zum Auffüllen der Nachricht bis zur maximalen Größe angehängt.

Der Set Header besteht aus den folgenden Feldern:

Feldname BeschreibungSet ID Set-Typ

2: Template Set3: Option Template Sethöher bis 255: Data Sets

Length Definiert die Länge des gesamten Record Sets in Oktetten zur Bestimmung der Position des nächsten Sets

Tabelle 14: Felder im Header eines Record Sets von IPFIX

Für die nach dem Set Header folgenden Records sind folgende Record-Formate definiert:

Template RecordTemplate Records enthalten eine definierte Anzahl an Data Records, was dem Collector-Prozess das Sammeln von Informationen ohne genaue Kenntnis der Interpretation der einzelnen Field Specifiers erlaubt.

Der Aufbau eines Template Records ist wiederum in einen Template Record Header und mehrere Field Specifier untergliedert. Der Template Record Header enthält die folgenden Informationen:

Feldname BeschreibungTemplate ID (> 255) Identifikation des Templates.

Werte bis 255 sind reserviert.Werte bis 65535 sind frei für die Definition von Sets.

Field Count Anzahl an Fields innerhalb des Records

Tabelle 15: Felder im Header eines Template-Records von IPFIX


Logdatenstudie

Options Template RecordOptions Template Records geben der exportierenden Komponente die Möglichkeit, zusätzliche Informationen weiterzureichen, was alleine über Flow Records nicht möglich wäre. Ein Options Template Record ist wiederum nach dem Muster Header und Field Specifier definiert:

Feldname BeschreibungTemplate ID (>255) Identifikation des Templates.

Werte bis 255 sind reserviert.Werte bis 65535 sind frei für die Definition von Sets.

Field Count Anzahl an Fields innerhalb des Records einschließlich ScopesScope Field Count Anzahl an Scope Fields innerhalb des Records

Tabelle 16: Felder im Header eines Options Template Records in IPFIX

Data RecordsData Records sind in Data Sets zusammengefasst. Templates für die korrekte Verarbeitung von Data Records müssen zuvor oder innerhalb der gleichen Nachricht an den Collector gesendet worden sein, damit dieser die Data Records korrekt interpretiert.

IPFIX ist ein flexibles und für Erweiterungen offenes Format. Damit erhöht sich zwangsläufig seine Komplexität.

Weitere Informationen finden sich in den Memos der IPFIX-Arbeitsgruppe der IETF:

http://www.ietf.org/html.charters/ipfix-charter.html

Wegen des Binärformats der Data Records muss an dieser Stelle auf ein Log-Beispiel verzichtet werden.

3.2.6 Cisco NetFlow-Format

NetFow-Daten werden aus den Statistik-Caches des Cisco IOS-Betriebssystems ausgelesen und für die Netzwerkübertragung vorbereitet. Ein Datenformat im eigentlichen Sinne existiert nicht. Aus diesem Grund wird hier nur auf den Paketaufbau eines NetFlow-Exports eingegangen. Die geläufigste Version ist die 5, welche im Folgenden beschrieben wird.

NetFlow exportiert Flow-Informationen über UDP-Pakete. Ein NetFlow-Export besteht aus einem sog. Message Header und einer limitierten Anzahl an sog. Flow Records. Die Informationen im Message Header werden zur Identifikation der Version und damit der Allokation eines ausreichend großen Empfangspuffers wie auch zur korrekten Interpretation des Paketinhaltes herangezogen.

Der Aufbau des Message Headers stellt sich wie folgt dar:



Logdatenstudie

Feldposition in Bytes

Feldname Beschreibung

0-3 Version and Count Versionsnummer des NetFlow-Exports und Anzahl der im Paket enthaltenen Flow Records

4-7 SysUptime Zeitspanne seit dem letzten Neustart des Systems8-11 unix_secs Angabe der UTC-Zeit bis auf die Sekunde12-15 unix_nsecs Angabe der Nanosekunden innerhalb der UTC-Zeit16-19 flow_sequence Sequenznummer der Flow Records20-23 reserved Nicht belegt

Tabelle 17: Felder im Header von NetFlow

Die möglichen Byte-Definitionen des Flow Record Formats in Version 5 lauten wie folgt:

Feldposition in Bytes


0-3 srcaddr Quell-IP-Adresse4-7 dstaddr Ziel-IP-Adresse8-11 nexthop IP-Adresse des Next Hop Routers12-15 input and output SNMP-Index des Input und Output Interface16-19 dPkts Pakete innerhalb des Flows20-23 dOctets Gesamtzahl an Layer-3 Bytes in den Flow-Paketen24-27 First Die Zeit seit dem letzten Neustart des Systems bei Be

ginn des Flows28-31 Last Die Zeit seit dem letzten Neustart des Systems am Ende

des Flows32-35 srcport and dstport TCP-/UDP-Quell- und -Zielport36-39 pad1, tcp_flags, prot,

and tosZahl nicht belegter Bytes, TCP Flags, IP-Protokolltyp (z. B. UDP=17) und Type-of-Service

40-43 src_as and dst_as AS der Quelle und des Ziels44-47 src_mask, dst_mask,

and pad2Adressmasken der Quelle und des Zieles

Tabelle 18: Felder eines NetFlow-Records

Welche Informationen durch NetFlow ausgelesen werden, ist frei konfigurierbar.

Weiterführende Informationen zur Version 5 von NetFlow können unter folgendem Link eingesehen werden:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a00800ca62d.html

Die Version 9 des Protokolls findet sich unter:




Logdatenstudie

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_feature_guide09186a00801b0696.html

Wegen des Binärformats der NetFlow-Records muss an dieser Stelle auf ein Log-Beispiel verzichtet werden.

3.2.7 Format bei Cisco IOS-basierenden Geräten

In den Routern und Switches des Herstellers Cisco kommt das Netzwerk-Betriebssystem „Internetworking Operating System“ (IOS) mit teilweise unterschiedlichen Funktionsumfängen zum Einsatz.

Logmeldungen des IOS können an den internen Puffer des Gerätes, an die Konsole oder auch per Syslog-Protokoll an einen entfernten Logsammler geschickt werden.

Das Format einer vom IOS ausgegebenen Meldung folgt (ggf. nach dem Syslog-Header) diesem Aufbau:<facility>-<severity>-<MNEMONIC>:<description>Folgendes Beispiel beginnt mit der optional zu aktivierenden Zeitstempelangabe.6/17/2001,18:31:15:SYS-5-MOD_INSERT:Module 5 has been insertedDer Facility Code für die Einheit, welche die Meldung generiert, besteht aus zwei oder mehr Buchstaben. Eine Facility kann eine Hardware-Komponente, ein Protokoll oder auch ein Modul der System-Software sein. Nur beispielhaft seien hier einige Facility Codes aufgeführt:

Code FacilityACL Access Control ListsDVLAN Dynamic VLANETHC Ethernet ChannelKERNEL Kernel Messages

Tabelle 19: Quellangaben in einer Cisco IOS-Meldung

Für die Anwendung von Severities gilt der folgende Grundsatz: Je niedriger der Wert der Severity, desto wichtiger ist die Meldung. In IOS-Meldungen existieren acht Severity-Stufen:

Severity-Stufe Bedeutung0 Das System ist nicht benutzbar.1 Dringender Eingriff erforderlich.2 Kritischer Zustand des Systems3 Es sind Fehler aufgetreten.4 Es sind Warnungen aufgetreten.6 Normaler Zustand mit wichtiger Meldung6 Informelle Meldung7 Meldung im Debugging-Modus

Tabelle 20: Kritikalitätsstufen in einer Cisco-IOS-Meldung




Logdatenstudie

„Descriptions“ folgen der Vorgabe, für den Menschen leicht lesbar zu sein. Sie sind nicht standardisiert und auf Maschinenebene insofern schwierig zu interpretieren.

Die Weiterleitung von Systemmeldungen ist standardmäßig nicht aktiviert und muss erst eingestellt werden. In der Default-Konfiguration werden Meldungen erst ab einem Severity Level von 4 (Warning) erstellt.

Die initiale Konfiguration mit einem Severity Level von 4 ist in der Regel ausreichend, insbesondere für die IT-Frühwarnung. Für Meldungen über An- und Abmeldungen am Gerät muss der Default-Level aber umgesetzt werden.

Link zum Dokument „System Message Guide Cisco Catalyst Family“:

http://www.cisco.com/en/US/products/hw/switches/ps663/products_system_message_guide_chapter09186a00800eb797.html#1015031

3.2.8 Firewall-Geräte

Firewall-Geräte zeichnen sich durch ein einfach zu standardisierendes Format aus, da es wenig unterschiedliche Meldungsarten gibt (i. W. „Paket durchgelassen“ und „Paket verworfen“) und diese Meldungen untereinander gleichartig aufgebaut sind.

Formate aus diesem Umfeld können maschinell sehr gut weiterverarbeitet werden.

3.2.8.1 Check Point VPN-1 Logformat

Die israelisch-amerikanische Firma Check Point bietet mit ihren Lösungen VPN-1 und Provider-1 zwei Verwaltungseinheiten zur Administration der Firewalls an. Während sich die Lösung VPN-1 an Unternehmen richtet, die keine mandantenfähige Lösung benötigen, ist Provider-1 mandantenfähig ausgelegt. Die Speicherung der Log-Einträge erfolgt in einem Binär-Format.

Die binären Logs können entweder über das Rahmenwerk Log Export API (LEA) (siehe Abschnitt 3.1.9), über die Benutzeroberfläche oder über die Kommandozeile des SmartCenters in Klartext exportiert werden.

Die Meldungen der Check Point Firewall haben den nachfolgen Aufbau und sind über Semikolon separiert:




Logdatenstudie

Feld-Position Feldname Beschreibung1 num Fortlaufende Nummer der Logmeldung2 date Datum3 time Zeit4 orig Meldende Firewall und -Komponente5 type Art der Meldung6 action Durchgeführte Aktion7 alert Alarmmeldung8 i/f name Name des aktionsdurchführenden Interfaces9 i/f dir Richtung, in das Interface durchquert wurde10 product Check Point-Produkt11 log_sys_message Systemmeldungstext, falls verfügbar12 rule Nummer der auslösenden Regel13 rule_uid Eindeutige ID der auslösenden Regel (nur neue

re Versionen)14 rule_name Name der auslösenden Regel15 service_id Bezeichner für den abgefragten Dienst16 src Quelle17 dst Ziel18 proto TCP/UDP/ICMP19 service Ziel-Port20 s_port Quell-Port21 session_id ID der Sitzung22 dns_query Per DNS abgefragter FQDN23 dns_type Per DNS abgefragter Typ (A, PTR etc.)24 message_info Nähere Informationen zur Meldung

Tabelle 21: Felder einer Check Point VPN-1-Meldung

Folgende zwei Beispiele zeigen typische Logmeldungen:1;16Jul2007;9:20:16;gateway;log;accept;;eth1.10;inbound;VPN-1 & FireWall-1;;15;{A417FC35-51A6-4C87-9D18-719B4CA3D3CF};OpenVPN-out;syslog;ASG;<Name>;udp;syslog;32784;;;;7;16Jul2007;9:20:29;gateway;log;accept;;eth1.3;outbound;VPN-1 & FireWall-1;;0;;;ntp-udp;gateway;<Name>;udp;ntp-udp;ntp-udp;;;;Implied rule Das vom Hersteller Check Point verwendete Format ist proprietär und nicht öffentlich dokumentiert.


Logdatenstudie

Im Auslieferungszustand des System werden interne Ereignisse und die bereits mitgelieferten Regeln („Implied Rules“) in die Logdateien geschrieben. Die Speicherung von nachträglich eingepflegten Regeln hängt vom Administrator der Firewall und damit von den Anforderungen des Unternehmens an den Umfang und die Art des Loggings ab.

3.2.8.2 Cisco PIX-Format

PIX ist die von Cisco angebotene Firewall-Gerätefamilie. Über die verschiedenen Versionen der PIX und ihres Nachfolge-Produkts, der ASA (Adaptive Security Appliance) haben sich die konkreten Logmeldungen zwar geändert, das hier beschriebene zugrunde liegende Format ist jedoch konstant geblieben, es ist also versionsunabhängig.

Als Optionen stehen die Ausgabe auf der Konsole, die Weiterleitung an einen Syslog-Server oder die Versendung von SNMP-Traps als Optionen zur Verfügung. Meldungen der PIX werden in Klartext formuliert.

Cisco empfiehlt für die Kompatibilität zu IOS-Meldungen und die bessere Auswertung innerhalb von Cisco Works-Applikationen die Konfiguration zur Ausgabe im sog. EMBLEM-Format. Für diese Syslog entsprechende Formatoption ist nur UDP als Übertragungsprotokoll verfügbar. Dabei wird den Meldungen ein Zeitstempel und eine Syslog-kompatible Severity hinzugefügt.

Meldungen von PIX-Firewalls folgen, ggf. nach dem Syslog Header, diesem Aufbau:%PIX-<Level>-<Message-Number>: <Message-Text>Folgendes Beispiel zeigt typische PIX-Systemmeldungen:%PIX-6-110001: No route to 10.10.100.3 from 192.168.0.10%PIX-6-106015: Deny TCP (no connection) from 10.132.0.52/1036 to10.2.1.3/23 flags PSH ACK on interface DMZ2PIX-Meldungen beginnen immer mit einem Prozentzeichen, gefolgt von der konstant als „PIX“ bezeichneten Facility. Der Severity-Level der generierten Meldung liegt wie beim IOS zwischen den Werten 0 und 7. Es folgt eine eindeutige sechsstellige Identifikationsnummer („Message-Number“) für die Meldung. Anschließend folgt der eigentliche Meldungstext.

Die Severity-Levels entsprechen den IOS-Levels und dem Syslog-Standard:

Level Beschreibung0 Das System ist nicht benutzbar1 Dringender Eingriff erforderlich2 Kritischer Zustand des Systems3 Es sind Fehler aufgetreten4 Es sind Warnungen aufgetreten5 Normaler Zustand mit wichtiger Meldung6 Informelle Meldung7 Meldung im Debugging-Modus

Tabelle 22: Kritikalitätsstufen einer Cisco PIX-Meldung


Logdatenstudie

Der Severity-Level 0 wird von der PIX nicht verwendet und nur aus Kompatibilitätsgründen mitgeführt.

Die Standardkonfiguration der PIX erzeugt Logmeldungen ab Severity Level 3. Interessante Informationen wie beispielsweise erfolgreiche/fehlgeschlagene Logins sind aber in niedrigeren Severity- Levels definiert. Hierfür ist die Logkonfiguration auf einen Severity-Level von 6 notwendig.

Weiterführende Informationen zu verwendeten Variablen und den verfügbaren Meldungstexten können unter folgendem Link eingesehen werden:

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_system_message_guide_chapter09186a008051a0cc.html#wp1030015

3.2.8.3 Juniper Netscreen Security Manager

Der Hersteller Juniper bietet als Firewall die Netscreen-Geräte sowie die mit mehr Funktionen versehene ISG-Geräteserie an.

Für die zentrale Administration dieser Lösungen wird der Netscreen Security Manager (NSM) eingesetzt. Dabei handelt es sich um ein Werkzeug sowohl für die Gerätekonfiguration als auch für die Auswertung sicherheitsrelevanter Ereignisse. Es ist konzipiert für die Zentralisierung der Logmeldungen aller per NSM verwalteten Einzelgeräte.

Der NSM bietet zwei Varianten für die Weiterleitung von Logmeldungen an: Zum einen können Meldungen über SNMP-Traps versendet werden. Wegen des damit verbundenen erhöhten Ressourceneinsatzes bietet Juniper auch den besser für die Übertragung großer Logmengen geeigneten Export per Syslog an, welcher im Folgenden näher beschrieben wird.

Der NSM schreibt die Logdaten nach einem Standard-Syslog-Header in den MESSAGE-Teil. In den aktuellen Versionen des „ScreenOS“-Betriebssystems 5.x wird unterschieden zwischen sogenannten „Traffic Log Messages“, also Meldungen über die Firewall passierende Datenpakete, und Systemmeldungen, welche unformatiert und „human-readable“ geschrieben werden. Traffic Log Messages verwenden ein „named value pair“-Format, wie folgende Beispiele zeigen:Feb 5 19:39:42 10.1.1.1 ns25: Netscreen device_id=00351653456 system-notification-00257(traffic): start_time="2003-02-05 19:39:04" duration=0 policy_id=320001 service=1434 proto=17 src zone=Untrust dst zone=Trust action=Deny sent=0 rcvd=40

Feb 5 19:39:42 10.1.1.1 ns25: Netscreen device_id=00351653456 system-notification-00257(traffic): start_time="2003-02-05 19:34:44" duration=1 policy_id=0 service=http proto=6 src zone-Trust dst zone=Untrust action=Permit sent=11903 rcvd-31454 src=10.5.5.1 dst=xxx.xxx.10.2 src_port=1254 dst_port=80 translated

Feb 7 14:37:30 10.1.1.1 ns25: NetScreen device_id=00351653456 system-warning-00515: duration=0 start_time="2003-02-07 14:37:04" netscreen: Admin User "netscreen" logged in for Web(https) management (port 443) from 12.146.232.2:3473. (2003-02-07 14:34:32)




Logdatenstudie

Feb 7 14:41:33 10.1.1.1 ns25: NetScreen device_id=00351653456 system-information-00767: duration=1 start_time="2003-02-07 14:40:04" netscreen: The system configuration was saved by admin -netscreen-. (2003-02-07 14:38:30) Folgende Datenfelder können innerhalb einer Meldung enthalten sein (teilweise sind diese jedoch nicht dokumentiert):

Feld Beschreibungday_idrecord_idtimeReceived Zeitstempel des NSMtimeGenerated Zeitstempel des generierenden SystemsdomaindomainVersiondeviceName Name des generierenden SystemsdeviceIpAdress IP-Adresse des generierenden Systemscategory Kategoriesubcategory Unterkategoriesrc zone Zone innerhalb NSM Src intface Eingehendes Interface des generierenden SystemsSrc addr Quelladresse des PaketesSrc port Quellport des PaketesNat src addrNat src portDst zoneDst intface Ausgehendes Interface des generierenden SystemsDst addr Zieladresse des PaketesDst port Zielport des PaketesNat dst addrNat dst portprotocol Protokollname/-nummerRule domainRule domainVersionPolicyname Rule baseRule numberaction Durchgeführte Aktion (Deny/Pass)


Logdatenstudie

Feld Beschreibungseverity SchweregradIs alertdetails Zusätzlicher MeldungstextUser strApplication strUri str Angefragte URLelapsed Dauer einer erlaubten VerbindungBytes in Byte-Zähler eingegangener PaketeBytes out Byte-Zähler ausgehender PaketeBytes totalPacket in Paketzähler eingegangener PaketePacket out Paketzähler ausgehender Paketepacket total Anzahl übertragener Pakete RepeatCount hasPaketDataVarData Enum

Tabelle 23: Felder einer NSM-Meldung

3.2.9 Intrusion-Detection- und -Prevention-Systeme

Netzwerkbasierte Intrusion-Detection-Systeme (IDS) bzw. Intrusion-Prevention-Systeme (IPS), die im Fokus dieses Abschnitts liegen, analysieren den Netzwerkverkehr auf mehreren Schichten, anders beispielsweise als die oft auf die Transport-Ebene fokussierten Firewalls. Die Angriffserkennung erfolgt anhand verschiedener Technologien, angefangen von Mustererkennung bis hin zur verhaltensbasierten Analyse. Diese Vielfalt spiegelt sich auch in den IDS-/IPS-Logformaten wieder.

Formate aus diesem Umfeld können maschinell gut weiterverarbeitet werden.

3.2.9.1 Cisco IPS-Format (SDEE)

Cisco unterteilt seine IPS-Gerätefamilie in Einschubmodule für Router und Switches sowie in Geräte, welche an beliebigen Punkten im Netzwerk platziert werden können.

Die Geräte der 4200er-Serie benutzen den von den ICSA Labs verwalteten Protokoll- und Formatstandard „Security Device Event Exchange“ (SDEE), welcher frei implementierbar ist. Entwickelt wurde der Standard in einem Konsortium der ICSA Labs in Zusammenarbeit mit den Herstellern Cisco, Fortinet, Infosec Technologies, IBM ISS, SecureWorks, SourceFire, Symantec und Tripwire. SDEE wurde konzipiert, um Alarm-, Richtlinien- und Auditierungsereignisse von netzwerk- und hostbasierten IDS/IPS standardisiert weiterzureichen.


Logdatenstudie

Die von IDS-/IPS-Sensoren generierten Daten werden in XML beschrieben und mittels des SOAP-Protokolls der Version 1.2 weitergereicht.

Innerhalb der von Cisco verwendeten SDEE-Version können die folgenden Datenfelder enthalten sein:

Feld BeschreibungBase CountVictim Addr ZieladresseVictim Port ZielportDevice Action Aktion, die der Sensor durchgeführt hatInterface Group Das Segment des Sensors VLAN VLAN IDSignature Version Version des SignatursetsSub Sig ID ID der Unterkategorie der SignaturFrom AttackerFrom VictimSignature Name der gezogenen SignaturevAlertSig ID ID der gezogenen SignaturHost ID ID des SensorsInterface ID des eingehenden InterfacesApp Name Name der ApplikationTime Zeitstempel bei der GenerierungSeverity SchweregradEvent ID Cisco-interne IDTrigger Packet Mitschnitt des auslösenden PaketsAlert Details MeldungstextSig Name Name der gezogenen SignaturAttacker Addr Quelladresse des AngreifersAttacker Port Quellport des AngreifersProtocol ProtokolltypAggregated Anzahl aggregierter Meldungen

Tabelle 24: Felder einer Cisco IPS-Meldung

Link zur Homepage der ICSA Labs und SDEE:

http://www.icsalabs.com/icsa/topic.php?tid=b2b4$52d6a7ef-1ea5803f$4c69-ff36f9b5

Folgendes Beispiel zeigt eine SDEE-formatierte Meldung:


http://www.icsalabs.com/icsa/topic.php?tid=b2b4$52d6a7ef-1ea5803f$4c69-ff36f9b5

Logdatenstudie

evIdsAlert: eventId=1177526035273721484 vendor=Cisco severity=low originator: hostId: ciscoids1 appName: sensorApp appInstanceId: 370 time: 19. Juli 2007 16:25:21 UTC offset=60 timeZone=GMT+01:00 signature: description=ICMP Network Sweep w/Echo id=2100 version=S2 subsigId: 0 marsCategory: Probe/HostSweep/Non-stealth interfaceGroup: vs0 vlan: 0 participants: attacker: addr: 10.49.216.143 locality=OUT target: addr: 10.49.216.10 locality=OUT os: idSource=unknown type=unknown relevance=relevant target: addr: 10.49.216.64 locality=OUT os: idSource=learned type=windows-nt-2k-xp relevance=relevant target: addr: 10.49.216.20 locality=OUT os: idSource=unknown type=unknown relevance=relevant target: addr: 10.49.216.26 locality=OUT os: idSource=unknown type=unknown relevance=relevant target: addr: 10.49.216.39 locality=OUT os: idSource=unknown type=unknown relevance=relevant target: addr: 10.49.216.216 locality=OUT os: idSource=unknown type=unknown relevance=relevant riskRatingValue: 60 targetValueRating=medium attackRelevanceRating=relevant threatRatingValue: 60 interface: ge0_0 protocol: icmp


Logdatenstudie

3.2.9.2 McAfee IntruShield IPS (Datenbank)

Die IntruShield-Gerätefamilie ist die netzwerkbasierte IPS-Lösung des Herstellers McAfee.

Diese Lösung umfasst eine MySQL-Datenbank auf der zentralen Management-Komponente, in der insbesondere die einlaufenden Logmeldungen der verwalteten Geräte abgelegt werden. Die Absicherung der Verbindungen zwischen den Sensoren und dem Management erfolgt über das SSL-Protokoll.

MySQL-Datenbanken sind frei verfügbar, nicht jedoch das verwendete Datenbankschema. Logmeldungen werden in den dafür vorgesehenen Tabellen der Datenbank gespeichert. Die jeweils gewünschten Datenfelder einer Meldung lassen sich in beliebiger Reihenfolge über ODBC-Schnittstellen abfragen.

Auf die Angabe eines Logbeispiels sowie einer Beschreibung der einzelnen Werte der Meldungen in Form einer Tabelle muss hier verzichtet werden, da das Schema nicht offengelegt ist.

3.2.9.3 3Com Tipping Point IPS

Der Hersteller 3Com bietet IPS-Geräte namens Tipping Point im Segment der netzwerkbasierten IPS (NIPS) an. Diese IPS-Lösung beinhaltet eine Management-Komponente namens SMS (Security Management System) für die zentrale Verwaltung von NIPS-Sensoren.

Logdaten speichert das SMS in einer mitgelieferten MySQL-Datenbank, eine Oracle-Datenbank kann bei Bedarf optional angebunden werden. Das Datenbankschema ist frei verfügbar. Der Hersteller bietet zudem eine Webschnittstelle (Web-API) für die Interaktion mit IT-Frühwarnsystemen. Die Übermittlung von Logmeldungen über Syslog ist ebenfalls konfigurierbar.

Über die Webschnittstelle können prinzipiell alle Daten aus dem SMS abgefragt werden. Dies umfasst folgende informelle Gruppen:

– Informationen über die angebundenen Einzelsysteme

– Informationen über erstellte Richtlinien

– Informationen über installierte Signatur-Aktualisierungen

– Logmeldungen der Einzelsysteme

Für eine erfolgreiche Datenübertragung muss initial das Schema bekannt sein. Es kann über die folgende URL geladen werden:http[s]://<sms_server>/dbAccess/tptDBServlet?method=SchemaDie Abfrage einer Meldung erfolgt mithilfe der folgenden beispielhaften URL:http[s]://<sms_server>/dbAccess/tptDBServlet?method=GetData&table=ALERTS&begin_time=1&end_time=1162252800000[&format=<format>]Abfragen setzen sich aus folgenden Datenfeldern zusammen:

Feld Beschreibunghttp[s]:// Protokoll<sms_server> IP-Adresse oder FQDN des SMS-Servers


Logdatenstudie

Feld Beschreibung/dbAccess/tptDBServlet Teil der Zugriffs-URLmethod=GetData Zugriffsmethodetable Abgefragte Tabelle, z. B. ALERTSbegin_time Startpunkt des abgefragten Zeitbereichsend_time Endpunkt des abgefragten Zeitbereichsformat=<format> Ausgabeformat (CSV, XML oder SQL-kompatibel)

Tabelle 25: Felder einer Abfrage von SMS-Meldungen über ein Web-API

Des Weiteren sind folgende Spalten in der Logmeldungstabelle enthalten:

Feld BeschreibungSEQUENCE_NUM Indizierungsnummer der TabelleDEVICE_ID Identifikator des meldenden SensorsALERT_TYPE_ID Identifikator der MeldungPOLICY_ID Identifikationsnummer der zugehörigen Richtlinie (POLICY)SIGNATURE_ID Identifikationsnummer der zugehörigen Signatur (SIGNATURE)BEGIN_TIME Startzeit des EventsEND_TIME Zeit der Sendung der Meldung zum ManagementHIT_COUNT Anzahl der erkannten einzelnen Attacken, bevor die Meldung ge

neriert wurde (Aggregation)SRC_IP_ADDR Quelladresse des verursachenden SystemsSRC_PORT Quellport des verursachenden SystemsDST_IP_ADDR Zieladresse des angegriffenen SystemsDST_PORT Zielport des angegriffenen SystemsSEGMENT_INDEX Physikalisches Segment des meldenden SensorsSLOT_INDEX Physikalischer Einschub des SensorsSEVERITY Der Schweregrad der in der Signatur definierten AttackeMESSAGE_PARMS Liste von Meldungsparametern (Text)

Tabelle 26: Felder einer Tipping Point-Meldungstabelle

Tipping Point verwendet über den Syslog-Header hinaus Trennzeichen im Message-Teil: Es können Kommas (,), Semikolons (;) oder auch Schrägstriche (/) verwendet werden. Die nachfolgende Tabelle zeigt die Felder einer Syslog-Meldung:

Feld-Nr. Beschreibung1 Logtyp: Bsp. ALT=Alert2 Version des Meldungsformats


Logdatenstudie

Feld-Nr. Beschreibung3 ISO-8601-Zeitstempel bei der Generierung4 Hostname/IP-Adresse des Sensors5 Sequenz-ID6 Reserviert7 Durchgeführte Aktion (Block/Permit)8 Schweregrad9 Policy UUID10 Policy Name11 Name der Signatur12 Protokollname13 Quelladresse und -port (kommasepariert)14 Zieladresse und -port (kommasepariert)15 ISO-8601-Zeitstempel der Aggregation16 Anzahl der Meldungen der Aggregation17 Traffic-Threshold-Meldungsparameter18 Netzwerkmitschnitt der Verfügbarkeit19 Slot und Segment der Meldung auf dem Sensor

Tabelle 27: Felder einer SMS-Meldung über Syslog

Folgendes Beispiel illustriert das Format von Tipping Point über Syslog. Der eigentliche Separator <TAB> wurde der Lesbarkeit halber durch ein Komma ersetzt:Oct 12 00:52:44 192.168.9.62 7, 1, e2c8b1c1-5979-11db-7682-,00000001-0001-0001-0001-000000000141,0141: ICMP: Destination Unreachable (Port Unreachable),141,icmp,172.20.100.2,0,172.20.100.8,0,9,3,1,FranceLab100E,100732157,1160608921435Oct 12 00:52:44 192.168.9.62 7,1,349905d5-5949-11db-17b4-3ab2f398c55e,00000001-0001-0001-0001-000000001793,1793: SMTP: Windows Executable_Attachment,1793,tcp,216.136.107.233,41422,216.136.56.28,25,1,3,1,FranceLab100E,67380477,1160608923651Oct 12 00:52:44 192.168.9.62 7,1,349905d9-5949-11db-17b4-3ab2f398c55e,00000001-0001-0001-0001-000000002177,2177: SMB: Null Session SetUp,2177,tcp,10.1.1.108,1052,10.1.1.102,139,1,3,1,FranceLab100E,84091723,1160608926618Oct 12 00:52:44 192.168.9.62 7,1,3498b7c3-5949-11db-17b4-3ab2f398c55e,00000001-0001-0001-0001-000000001400,1400: SMB: Windows Logon_Failure,1400,tcp,10.1.1.102,139,10.1.1.108,1052,1,3,1,FranceLab100E,67511115,1160608926668


Logdatenstudie

3.2.10 Webserver und -Anwendungen

Webserver-Logdaten sind oft von Interesse, um das Benutzerverhalten auf den bereitgestellten Webseiten zu analysieren (Nutzerstatistiken). Die wichtigsten Logdateien aus Sicht eines IT-Frühwarnsystems sind das typische Error-Log und das Access-Log. Letzteres besteht aus stark standardisierten Meldungen.


3.2.10.1 Internet Information Server Format

Der Microsoft Webserver Internet Information Server (IIS) ist einer der wenigen Windows-Dienste, der ein eigenes klartext- und dateibasiertes Logging unterstützt. Dies hat den Vorzug, dass das in diesem Bereich sehr wichtige „Data Mining“ für Webserver-Nutzungsstatistiken über Dritthersteller abgewickelt werden kann. Aufgrund der in diesem Bereich anfallenden enormen Datenmengen wäre eine Integration in die größenbeschränkte Standard-Eventlog-Dateien von Windows zudem nicht sinnvoll.

Der IIS bietet vier verschiedene Log-Formate an:

– W3C Extended

– Microsoft IIS

– NCSA Common

– Speicherung in einer ODBC-Datenbank (Microsoft SQL)

Die Standard-Einstellung sieht das W3C-Format vor, welches sehr flexibel gehandhabt werden kann, da dem Format einzelne Felder hinzugefügt oder weggenommen werden können. Das IIS-Format wird in erster Linie aus Gründen der Abwärtskompatibilität unterstützt.

Folgende Tabelle führt die Felder des W3C-Formats auf:

Feld-Name Bedeutungdate Datum der Anfragetime Uhrzeit der Anfrage im UTC-Formatc-ip IP-Adresse des anfragenden Clientscs-username Name eines authentifizierten Benutzers, sonst „-“s-ip Server-Names-port Server-Portcs-method Angefragte Aktion, z. B. ein HTTP GETcs-uri-stem Ziel der Aktion, z. B. index.htmlcs-uri-query Abfrage des Clients, URI nur bei dynamischen Webseitensc-status HTTP-Status-Codecs(User Agent) Für die Abfrage des verwendeten Internet-Browserssc-substatus Substatus-Fehler-Code


Logdatenstudie

Tabelle 28: Felder einer IIS-Meldung

Ein Beispiel für das W3C-Extended Format sieht folgendermaßen aus (Zeilenumbrüche kommen nicht vor): #Software: Microsoft Internet Information Services 6.0#Version: 1.0#Date: 2006-05-02 17:42:15#Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem

cs-uri-query sc-status cs(User-Agent)2006-05-02 17:42:15 172.16.1.1 - 172.31.2.2 80 GET /images/picture.jpg– 200 Mozilla/4.0+(compatible;MSIE+5.5;+Windows+2000+Server)Das W3C-Format beinhaltet Kopfzeilen mit Versionsinformationen sowie eine Übersichtszeile mit den geschriebenen Feldern.

3.2.10.2 Apache Format (Common Log Format)

Seit Kurzem existiert ein eigenes Teilprojekt innerhalb der Apache-Foundation, das sich speziell mit modulübergreifendem Logging zum Zweck des Debuggings und der Auditierung beschäftigt.

Folgende Beschreibung bezieht sich auf die aktuelle Version 2.2 des Apache HTTP-Webservers.

Standardmäßig ist das Logging ins lokale Dateisystem aktiviert. Das jeweilige Format lässt sich ebenfalls detailliert konfigurieren, z. B. über die folgende Zeile innerhalb der Datei httpd.conf, allgemein durch Einträge im Kontext der jeweiligen Server- oder Virtual Host-Konfiguration:LogFormat „%h %l %u %t \"%r\" %>s %b“ commonDiese Default-Konfiguration entspricht dem wichtigen „Common Log Format“.

Die Anweisung „LogFormat“ bewirkt allgemein die Definition eines Logformats und definiert ggf. einen Apache-internen Namen für das Format. Hier lautet der Name „common“. Die Variablen des Common Log Format haben folgende Bedeutungen:

Variable Bedeutungh Entfernter Clientl Entfernter Logname, soweit dieser per ident-Aufruf ermittelbar istu Entfernter Benutzername, falls eine Authentifizierung stattgefunden hatt Zeitstempel der Anfrager Erste Zeile der Anfrage, z. B. „GET /index.html HTTP/1.1“>s HTTP-Status-Code der letzten Anfrageb Größe der Antwort ohne den HTTP-Header

Tabelle 29: Variablen im Apache Common Log Format

Sämtliche Variablen und ihre Konfigurationsmöglichkeiten sind auf folgender Seite des Apache-Projekts dokumentiert:

http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats


http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats

Logdatenstudie

Über die folgende Anweisung kann das Access-Log zum Logging in die Syslog-Facility veranlasst werden:CustomLog syslog:apache commonDie AnweisungErrorLog syslog:apache commonbewirkt dasselbe für das Error-Log und zwar jeweils im zuvor als „common“ bezeichneten Log-Format. „apache“ entspricht der Syslog-Facility.

Im Error-Logging existieren folgende Log-Level:

– emerg

– alert

– crit

– error

– warn (Default)

– notice

– info

– debug

Durch folgendes Kommando wird der Log-Level konfiguriert, oberhalb dessen Meldungen versendet werden:LogLevel <level>Aus Sicherheitsperspektive empfiehlt es sich, zumindest den Level „warn“ auszuwählen.

Beispiele für Logmeldungen im oben als „common“ definierten Format:192.168.2.20 - - [28/Jul/2006:10:27:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395127.0.0.1 - - [28/Jul/2006:10:22:04 -0300] "GET / HTTP/1.0" 200 2216

3.2.10.3 Tomcat Servlet Container Format

Für den Servlet Container Tomcat steht eine Vielzahl von Log-Frameworks zur Verfügung. Da es kein zentrales Logging für die Anwendungen gibt, die innerhalb des Tomcat betrieben werden, ist es die Aufgabe jeder Anwendung selbst, Informationen zu erzeugen. Das mächtigste und am weitesten verbreitete ist das Framework log4j. Bei log4j können Änderungen im Logging-Verhalten und in der Darstellung der Logmeldungen durchgeführt werden, ohne den eigentlichen Applikationscode ändern zu müssen. Außerdem kann noch die Laufzeit der Log-Level einer Anwendung geändert werden. Die Darstellung der Logmeldungen lässt sich mithilfe des sog. „Pattern Layout“ über die Konfigurationsdatei definieren:

Variable Bedeutung%d Zeitstempel im internationalen ISO-8601-Format%-5p Severity-Level (z. B. 'INFO')


Logdatenstudie

Variable Bedeutung'-' bedeutet linksbündig'5' bedeutet verlängert auf 5 Zeichen (damit z. B. 'INFO'- und 'DEBUG'-Ausgaben bündig untereinander stehen)

%t Thread-Name%c Name der Kategorien%m Übergebener Meldetext%n Zeilenwechsel

Tabelle 30: Variablen im Pattern Layout von Tomcat

Unterstützt werden unter anderem die gängigen Log-Level wie DEBUG, INFO, WARN, ERROR und FATAL. Es ist aber auch möglich, weitere Einstufungen vorzunehmen.

Weitere Konfigurationsoptionen finden sich unter folgender URL:

http://logging.apache.org/log4j/docs/api/org/apache/log4j/PatternLayout.html

Es besteht ferner die Möglichkeit, alle Log-Einträge an einen Syslog-Server zu senden.

Jede Instanz des Servlet Containers erhält über die eigene Konfigurationsdatei seine eigene Konfiguration, die Parameter können damit auf die jeweilige Applikation angepasst werden. Es empfiehlt sich, mittels der log4j-Konfiguration eine maximale Größe und die Anzahl der aufzubewahrenden Historiendateien, des Logs festzulegen.

Da der Tomcat Servlet Container kein zentrales, standardisiertes Logging anbietet, gibt es kein allgemeingültiges Logformat, welches die Webanwendungen nutzen könnten. Für jede Anwendung, die in einer Instanz bzw. einem Container betrieben wird, muss das Log entsprechend erstellt, ausgewertet und beurteilt werden. Hier sollte aber schon bei der Konzeption und Entwicklung einer neuen Individualanwendung auf ein Logformat geachtet werden, welches entsprechende Informationen beinhaltet und sie in einer entsprechenden Form darstellt.

Das folgende Logging-Beispiel zeigt, dass hier de facto keinerlei Standardisierung vorliegt:346 [main] ERROR SortAlgo.DUMP - Tried to dump an uninitialized array.

at org.log4j.examples.SortAlgo.dump(SortAlgo.java:58) at org.log4j.examples.Sort.main(Sort.java:64)Weitere Informationen zum Tomcat Servlet Container finden sich unter:

http://tomcat.apache.org/

Die Dokumentation von Log4j ist unter folgender URL zu finden:

http://logging.apache.org/log4j/docs/index.html




http://logging.apache.org/log4j/docs/api/org/apache/log4j/PatternLayout.html

Logdatenstudie

3.2.11 Proxy-Systeme

Web-Proxy-Systeme können die Client-Zugriffe auf Webserver aufzeichnen. Die hierfür verwendeten Formate sind teilweise dem Webserver-Bereich entnommen bzw. ähneln sich sehr stark. Sich stark ähnelnde Einzelmeldungen ermöglichen wiederum ein kompaktes Logformat. Über die Produkte hinweg finden sich einige gut unterstützte Formate immer wieder (W3C Extended, NSCA). Zu beobachten ist auch die Unterstützung mehrerer Formate durch ein Produkt bzw. eine Anpassbarkeit des Formats an die Anforderungen (beispielsweise die des Datenschutzes).


3.2.11.1 Microsoft ISA Server Format

Das Produkt ISA (Internet Security and Acceleration) Server (im Folgenden in Version 2004 beschrieben) wird von Microsoft als zentrales Sicherheits-Gateway vermarktet, mit Funktionen im Bereich Web-Proxy, Reverse-Proxy, Firewall, VPN- und SSL-Gateway sowie SMTP-MTA. Eine sinnvolle Auswahl von Loginformationen ist abhängig vom konkreten Einsatzzweck der ISA Server-Installation, die häufig nur einen Teil aller angebotenen Funktionen umfasst.

Für die verschiedenen Dienste des ISA Servers werden getrennte Logdateien angelegt. Bereitstehende Optionen für das Logformat sind für alle Dienste bis auf den SMTP-Dienst folgende:

– Speicherung in einer Datei (Speicherort der Datei kann auch eine Netzwerkfreigabe sein)

• im W3C-Format oder

• im ISA Server-Format

– Speicherung in einer Microsoft SQL-Datenbank, ggf. über das Netzwerk

– Speicherung in einer lokalen MSDE (Microsoft Desktop Engine)

Der SMTP-Dienst kann nur im Datei-Format protokollieren.

Innerhalb dieser Formate können die zu protokollierenden Felder fast immer festgelegt werden, indem sie aus einer Auswahlliste von Möglichkeiten zusammengestellt werden. Nur im ISA Server-Format werden grundsätzlich alle Felder mitgeschrieben, leere Felder werden hier mit einem Strich befüllt. Das Trennzeichen ist hier ein Komma, im Gegensatz zum Tabulator beim W3C-Format.

Für die Nutzung der MSDE-Protokollierung muss bereits bei der Installation des ISA Servers die Option „Erweiterte Protokollierung“ ausgewählt worden sein.

Die Verwendung der SQL-Server-Datenbank-Option bedingt den sog. „Firewall-Lockdown-Modus“ für das Schreiben in die entfernte Datenbank: fällt die Netzwerkverbindung zum SQL-Server aus, so begibt sich der ISA Server in einen abgeschotteten Modus, in dem der Netzwerkverkehr nicht mehr weitergeleitet wird. Ähnliches, nämlich die Deaktivierung des Firewall-Dienstes, wird vorgenommen, wenn der Logging-Dienst aufgrund fehlenden Speicherplatzes im Dateisystem oder der Datenbank gestoppt werden muss.

Bei der W3C- und SQL-Protokollierung werden die Uhrzeit und das Datum im UTC-Format geschrieben, beim ISA Server- und MSDE-Format in lokaler Zeit.

Für jede Zugriffsregel in der ISA Server-Richtlinie ist definierbar, ob beim Treffen der Regelbedingungen eine entsprechende Logmeldung geschrieben wird oder nicht. Per Default ist diese Einstellung aktiviert.


Logdatenstudie

Die maximale Größe einer aktuell beschriebenen Logdatei beträgt 2 GB, bevor spätestens zehn Minuten nach Überschreiten dieses Limits vom ISA-System automatisch eine neue Datei angelegt wird. Zudem wird täglich eine neue Logdatei erstellt (automatische Rotation). Es kann eingestellt werden, über wie viele Tage Logdaten aufbewahrt werden und ob sie nach der Rotation komprimiert werden sollen. Verteilte Installationen, sog. Enterprise-Installationen, des ISA Servers speichern ihre Logdaten zentral.

In der Default-Konfiguration ohne die Installationsoption „Erweiterte Protokollierung“ ist das Protokollieren in eine Datei anhand des W3C-Formats voreingestellt. Das wichtigste Log ist aufgrund des verbreiteten Einsatzes des ISA Servers ausschließlich als Web-Proxy das Web-Proxy-Log.

Die folgende Tabelle gibt die Standard-Einstellung für das erweiterte W3C-Format des Web-Proxy-Logs wider:

Feld-Nr Feldname Bedeutung1 c-ip IP-Adresse des anfragenden Clients2 cs-username Benutzername des anfragenden Benutzers3 c-agent „User-Agent“ des anfragenden Clients (Browser)4 sc-authenticated Angabe, ob sich der Benutzer authentifiziert hat5 date Datum des ISA Servers, an dem sich die Anfrage ereignet

hat6 time Zeit des ISA Servers, zu der sich die Anfrage ereignet hat7 s-svcname Name des Dienstes, w3proxy für den Web-Proxy8 s-computername Windows-Computer-Name des ISA Servers9 cs-referred Reserviert10 r-host Angefragter Server-Name11 r-ip Angefragte Server-IP-Adresse12 r-port Angefragter Server-Port13 time-taken Auf der Server-Seite benötigte Zeit für das Bearbeiten der

Anfrage14 cs-bytes Vom Client zum Server übertragene Bytes15 sc-bytes Vom Server zum Client übertragene Bytes16 cs-protocol Verwendetes Protokoll (i. d. R. http, https, ftp)17 cs-transport Verwendetes Transportprotokoll, dieses ist immer TCP18 s-operation Verwendete Anfrage-Methode, z. B. POST bei http19 cs-uri Angefragte URL20 cs-mime-type MIME-Typ in der Anfrage, soweit vom Server unterstützt21 s-object-source Quelle, aus der die angefragten Objekte stammen22 sc-status Status der Anfrage23 s-cache-info Cache-Status der Anfrage


Logdatenstudie

Feld-Nr Feldname Bedeutung24 rule Regel-Aktion für die Anfrage25 FilterInfo Feld für URL-Filter-Aktionen oder -Informationen26 cs-Network Netzwerk auf Client-Seite27 sc-Network Netzwerk auf Server-Seite28 error-info Zusätzliche Informationen über die Anfrage-Verarbeitung

Tabelle 31: Felder des erweiterten W3C-Formats im ISA Server

Weitere Informationen zum Logging im ISA Server 2004 allgemein:

http://www.microsoft.com/technet/isa/2004/help/FW_LogOver.mspx

Format-Link für die Web-Proxy-Komponente

http://www.microsoft.com/technet/isa/2004/help/FW_C_WebLogFields.mspx

Für die neueste Version, ISA Server 2006, sind die Formate hier beschrieben:

http://www.microsoft.com/technet/isa/2006/Logging_Reference.mspx

Das folgende Beispiel zeigt abschließend die Webaccess-Logzeilen des ISA Servers im Extended W3C-Format. Aus Gründen der Übersichtlichkeit sind nur die Header-Zeilen und eine Logzeile dargestellt. Der Tabulator ist aus Gründen der Lesbarkeit durch einen Strichpunkt ersetzt worden:#Software: Microsoft Internet Security and Acceleration Server 2004#Version: 2.0#Date: 2006-10-27 00:00:00#Fields: computer;date;time;IP protocol;source;destination;original client IP;source network;destination network;action;status;rule;application protocol;bytes sent;bytes sent intermediate;bytes received;bytes received intermediate;connection time;connection time intermediate;source name;destination name;username;agent;session ID;connection ID;interface;IP header;protocol payload

ACME-PROXY;2006-10-27;00:00:00;UDP;192.168.100.115:61683;255.255.255.255:14000;192.168.100.115;Internal;Local Host;Denied;0xc004000d;-;Unidentified IP Traffic;0;0;0;0;-;-;-;;-;-;-;0;0;-;-;-

3.2.11.2 Squid-Format

Der Open-Source-Proxy-Server Squid in seinen Versionen 2.x unterstützt verschiedene Logdateien für verschiedene Funktionen. Ort und Name der Logdateien sind konfigurierbar über die zentrale Konfigurationsdatei squid.conf. Hierfür notwendige Kommandos sind online dokumentiert unter

http://www.visolve.com/squid/squid24s1/logfiles.php.

Folgende Logdateien sind bei Squid üblich:

– Cache Access Log: Client-Zugriffe auf den Squid, das eigentliche Access-Log


http://www.visolve.com/squid/squid24s1/logfiles.php

http://www.visolve.com/squid/squid24s1/logfiles.php

http://www.microsoft.com/technet/isa/2006/Logging_Reference.mspx

http://www.microsoft.com/technet/isa/2004/help/FW_C_WebLogFields.mspx

http://www.microsoft.com/technet/isa/2004/help/FW_LogOver.mspx

Logdatenstudie

– Cache Log: Verhalten des Cache

– Cache Store Log: Aktivitäten des Storage Managers

– Cache Swap Log: Verwaltungslog für den Cache

– Useragent Log: separate Logdatei für das Useragent-Feld (optional)

– Referrer Log: separate Logdatei für das Referrer-Feld (optional)

Das Standard-Format des aus Sicherheitssicht relevanten Access-Log ist das Squid Native Log Format. Dieses wird von vielen anderen kommerziellen und nicht-kommerziellen Anwendungen ebenfalls unterstützt. Es sieht seit Version 1.1 folgende Felder vor:

Feldname Bedeutungtime Zeitstempel der Anfrage

elapsed Zeitdauer zur Beantwortung der Anfrage durch den Squid

remotehost IP-Adresse des anfragenden Clients

code/status Squid-kodiertes Ergebnis der Anfrage (der Client sieht einen HTTP-Response-Code)

bytes Größe der beantworteten Anfrage in Bytes

method HTTP-Methode des Clients

URL Angefragte URL

rfc931 Per ident festgestellter Client-Name

peerstatus/peerhost Squid-Code für die in einer Proxy-Hierarchie eingeschlagene Route zur Ermittlung der Antwort

type Content-Typ der Squid-Antwort

Tabelle 32: Felder im Squid Native Log Format

Die Felder des Squid Native Log Format sind jeweils durch ein Leerzeichen voneinander getrennt.

Die Log-Levels des Squid lassen sich für die einzelnen Logdateien über das Kommando debug_options auf Stufen von 1-9 setzen. Die Empfehlung lautet, mitdebug_options ALL, 1

den Level aller Logdateien auf eins zu setzen, um übergroße Mengen an Logdaten zu vermeiden.

An das lokale Syslog-System werden per Default nur Error-Logs, die mindestens den Level „fatal“ besitzen, gesendet. Es gibt keine gut dokumentierte Standardlösung, die Meldungen aus dem Access-Log eines Squid-Servers auch oder ausschließlich an das lokale Syslog-System zu schicken.


Logdatenstudie

3.2.11.3 NetCache-Format

Die Produktlinie der NetCache-Appliances wurde 2006 von Network Appliance an die Firma Bluecoat verkauft, die bereits eigene Produkte in Umfeld der Web-Proxies offeriert.

Das Logging von NetCache orientiert sich stark am Squid-Logging. Wie dort interessieren auch hier in erster Linie die typischen Access-Log-Einträge. Standardmäßig wird in eine lokale Datei protokolliert, optional kann auch die Übertragung per Syslog-Protokoll an einen zuständigen Server eingestellt werden. Das Format ist jeweils dasselbe, abgesehen vom Syslog-Header. Trennzeichen ist ein Tabulator-Zeichen.

Standardmäßig werden die Logdateien zeitlich rotiert. Es gibt auch die Option, die Dateien größenabhängig rotieren zu lassen. Die alten Logdateien werden automatisch komprimiert, nur die jeweils letzten zehn Dateien werden aufbewahrt, wenn sie nicht rechtzeitig per Dateitransfer automatisch oder manuell zur Archivierung auf einen entfernten Rechner transferiert werden.

Das Logformat ist in den neueren Versionen des Appliance-Betriebssystem 5.3 und 6.0 identisch. Folgende Tabelle entstammt der bei Network Appliance verfügbaren Online-Dokumentation. Das „Custom“-Format ist anpassbar, die Felder können hier beliebig an- und abgewählt werden. Die anderen Formate sind vorgegeben und können nicht verändert werden.

Feldname Beschreibung Default Common Netscapeextended

Squid-ähnlich

Custom

bytes Gesamtzahl der von NetCache an den Client ausgelieferten Bytes

X - - X X

cached Status-Anzeige, ob das Objekt in den Cache geladen wurde (1) oder nicht (0)

- - - - X

c-dns FQDN des Clients - - - - Xc-ip IP-Adresse des Clients X X X X Xcs-method HTTP-Request-Methode

des ClientsX - - X X

cs(Referer) Informationen im Request-Header-Feld der Client-Anfrage

- - - - X

cs-uri Abgefragte URL X - - X Xcs-uri-query Abfrage-Teil der URL

(nach dem Fragezeichen)- - - - X

cs-uri-stem Erster Teil der URL (vor dem Fragezeichen)

- - - - X

cs-username Benutzername; alt. zum x-username-Feld

- - - - X

date GMT-Zeit der Beendigung der Anfrage

- - - - X


Logdatenstudie


Squid-ähnlich

Custom

r-dns FQDN des Ursprungs-Servers

- - - - X

r-ip IP-Adresse des Ursprungs-Servers

- - - - X

rs(Content-Type)

Informationen im Request-Header-Feld der Antwort des Ursprungs-Servers

X - - X X

rs-status Antwort-Status-Code des Ursprungs-Servers

- - X - X

s-ip IP-Adresse, auf der die NetCache den Request empfangen hat

- - - - X

sc-comment HTTP-Antwort, die die NetCache an den Client versendet hat

- - - - X

sc-status HTTP-Antwort-Code, den die NetCache an den Client versendet hat

- X X - X

time GMT-Zeit der Beendigung der Client-Verbindung im Format HH:MM:ss

- - - - X

time-taken Benötigte Zeit für eine Transaktion im Format ss.mm

- - - - X

x-age Verstrichene Zeit seit der letzten Verifizierung des gespeicherten Inhalts mit dem Ursprungs-Server

- - - - X

x-authmethod

(Versuchte) Methode zur Authentifizierung des Clients

- - - - X

x-client-port TCP-Port der Verbindung auf Client-Seite

- - - - X

x-compress-action

Vorgenommene Kompressionsmethode für eine Transaktion

- - - - X

x-sc-contentencoding

Zum Client hin durchgeführte Inhaltskodierung

- - - - X

x-connect-time

Benötigte Gesamtzeit für die Verbindung zum Ur

- - - - X


Logdatenstudie


Squid-ähnlich

Custom

sprungs-Serverx-cs-bodylength

Länge der Client-Anfrage inklusive Header

- - X - X

x-cs-headerlength

Länge des vom Client empfangenen Headers

- - X - X

x-dnslookup-time

Benötigte Gesamtzeit für die DNS-Abfrage

- - - - X

x-domain Teil der Authentifizierungsinformation

- - - - X

x-elapsed-milliseconds

Zeit für eine Transaktion in Millisekunden

- - - X X

x-elapsed-seconds

Zeit für eine Transaktion in Sekunden (abgerundet)

- - X - X

x-hiercode NetCache Hierarchie-Code/IP-Adresse des Cache-Partners

X - - X X

x-hiername Name der angewandten Hierarchie-Weiterleitungsregel

- - - - X

x-localtime Lokale Zeit der NetCache im Format DD/MMM/YYYY:HH:mm:ss GGGG, wobei GGGG die Abweichung von der GMT-Zeit ist

- X X - X

x-last-modified

Angabe der Last-modified-Time im Header

- - - - X

x-last-verify Zeit der letzten Verifizierung des Objekts

- - - - X

x-note Verschiedene NetCache-Fehler-Codes

X - - - X

x-protocol Während der Verbindung verwendetes Protokoll

- - - - X

x-max-age Maximales Alter des Objekts

- - - - X

x-remote-id (Nicht umgesetzt; wird als „-“ protokolliert)

- X X X X

x-request-line

Komplette Zeile der Request-Methode

- X X - X


Logdatenstudie


Squid-ähnlich

Custom

x-rs-contentlength

Länge des vom Ursprungs-Server empfangenen Objekts in Bytes

- - X - X

x-rs-headerlength

Länge des vom Ursprungs-Server empfangenen Headers in Bytes

- - X - X

x-sc-contentlength

Länge des an den Client ausgelieferten Objekts in Bytes

- X X - X

x-sc-headerlength

Länge des an den Client ausgelieferten Headers in Bytes

- - X - X

x-smartfilter-categories

Smartfilter-Kategorisierungs-Code einer URL

- - - - X

x-smartfilter-result

Smartfilter-Ergebnis-Code (erlaubt 0, geblockt 1)

- - - - X

x-sr-bodylength

Länge des Body, welchen die NetCache vom Ursprungs-Server ausgeliefert hat, in Bytes

- - X - X

x-sr-headerlength

Länge des Headers, welchen die NetCache an den Ursprungs-Server ausgeliefert hat, in Bytes

- - X - X

x-timestamp Zahl der seit 1. Januar 1970 verstrichenen Sekunden in ss.mm zum Zeitpunkt der Beendigung der Client-Verbindung

X - - X X

x-transaction Transaktions- oder Antwort-Code

X - - X X

x-transaction-num

Numerische Darstellung des Transaktions-Codes

- - - - X

x-username Benutzername für authentifizierte Anfragen

X X X - X

x-wwfilter-categories

Kategorie-Code des WebWasher Dynablocators

- - - - X

x-wwfilter-result

Ergebnis-Code des WebWasher Dynablocators

- - - - X


Logdatenstudie


Squid-ähnlich

Custom

x-uri-path Relative URL-Pfad-Angabe ohne URI-Teil

- - - - X

Tabelle 33: Felder einer NetCache-Meldung

Beispiele (Zeilen umgebrochen):10.34.26.6 - - [12/Aug/2000:17:35:11 00000] "GET http://www.netapp.com/images/sub_careers_1a.gif HTTP/1.0" 200 1017 10.34.26.6 - - [12/Aug/2000:17:35:11 00000] "GET http://www.netapp.com/images/sub_careers_1b.gif HTTP/1.0" 200 1424 Dies kann im Detail online nachvollzogen werden:

http://now.netapp.com/NOW/knowledge/docs/NetCache_Appliance/6.0.5/html/netcache/admin/logs6.htm

http://now.netapp.com/NOW/knowledge/docs/NetCache_Appliance/6.0.5/html/netcache/errormsg/webacce3.htm

3.2.11.4 Bluecoat SG Format

Ähnlich wie die NetCache Appliances hat auch die SG Web-Proxy-Serie der Firma Bluecoat ein sehr gut anpassbares Logging, welches sich an bestehenden Standards orientiert. Hier wird allerdings ausschließlich die Web-Access-Protokollierung betrachtet. Die folgende Datstellung bezieht sich auf die Version 3.x des SGOS, des Betriebssystems der SG-Appliances.

Die Konfiguration des Logverhaltens der SG-Appliances sieht in einem ersten Schritt vor, bei Bedarf über die Standards hinausgehende Formate zu konfigurieren und im System zu hinterlegen. Diese Formate werden für jede der Logdateien separat konfiguriert. Z. B. kann das Web Access Logging im Squid-Format durchgeführt werden und das Logging des Instant Messagings in einem eigenen angepassten Format.

Optional wird die Verschlüsselung von Logdateien mit dem öffentlichen Schlüssel eines Zertifikats angeboten, so dass eine Entschlüsselung nur autorisierten Benutzern im Besitz des passenden privaten Schlüssels möglich ist.

Die Rotation und Komprimierung der Access Logs können ebenfalls eingestellt werden. Es fehlt allerdings die Option, Access-Log-Informationen per Syslog zu übertragen. Die Dateien lassen sich stattdessen in einem konfigurierbaren Zeitintervall auf einen anderen Server transferieren, in der Regel per FTP. Nur die systemeigenen Ereignisse oberhalb eines Log-Levels können per Syslog versendet werden.

Folgende Log-Formate werden per Default angeboten:

Name Beschreibungim Editierbares Instant-Messaging-Formatmain Editierbares ELFF-Format (ELFF: W3C-Extended-kompatibel)






Logdatenstudie

Name Beschreibungnsca Das nicht editierbare NSCA-Formatsmartreporter Nicht editierbares, zum Smartfilter Reporter kompatibles Formatsquid Entspricht den Squid-Logs in den Versionen 1.1 und 2.x, nicht editierbarstreaming Ein ELFF-Format, editierbarsurfcontrol Nicht editierbares, zum Surfcontrol Reporter kompatibles Formatsurfcontrol5 Nicht editierbares, zum Surfcontrol Reporter kompatibles Formatwebsense Nicht editierbares, zum Websense Reporter kompatibles Format

Tabelle 34: Logformate in Bluecoat SG

Weitere Formate lassen sich nach Bedarf definieren. Hierbei steht eine umfangreiche Liste von Format-Feldern zur Verfügung, welche in der öffentlich verfügbaren Bluecoat-Produktdokumentation enthalten ist, z. B. für Version 3.x:

http://download.bluecoat.com/manuals/SGOS3/ProxySG_CMG_Guide_3.2.4.pdf , App. B

Das main-Format entspricht in dieser Notation beispielsweise folgender Schreibweise:date time time-taken c-ip sc-status s-action sc-bytes cs-bytes cs-method cs-uri-scheme cs-host cs-uri-patch cs-uri-query cs-username s-hierarchy s-supplier-name cs(Content-Type) cs(User-Agent) sc-filter-result sc-filter-category x-virus-id s-ip s-sitenameWebsense, Surfcontrol und Smartfilter sind in die Appliance integrierbare URL-Filter-Produkte, die jeweils eine eigene Software für das Berichtswesen mit sich bringen. Die entsprechenden SG-Logformat-Vorlagen garantieren die Kompatibilität mit diesem Berichtswesen.

Folgendes Beispiel illustriert das main-Logformat inklusive Kopfzeilen. Als Separator wird jeweils ein Leerzeichen verwendet:#Software: SGOS 4.2.3.26#Version: 1.0#Start-Date: 2007-06-14 03:24:29#Date: 2007-05-15 14:34:45#Fields: date time time-taken c-ip sc-status s-action sc-bytes cs-bytes cs-method cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uri-query cs-username cs-auth-group s-hierarchy s-supplier-name rs(Content-Type) cs(Referer) cs(User-Agent) sc-filter-result cs-categories x-virus-id s-ip#Remark: 4000000000 "proxy"2007-06-14 13:08:46 14 172.22.1.141 407 TCP_DENIED 2746 361 GET http www.beispielseite.de 80 / - - - NONE - - - "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" DENIED "News/Media" - 10.33.36.12007-06-14 13:08:46 40 172.22.1.141 407 TCP_DENIED 3088 488 GET http www.beispielseite.de 80 / - - - NONE - - - "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" DENIED "News/Media" - 10.33.36.1


http://download.bluecoat.com/manuals/SGOS3/ProxySG_CMG_Guide_3.2.4.pdf

Logdatenstudie

2007-06-14 13:08:47 225 172.22.1.141 304 TCP_MISS 253 505 GET http www.beispielseite.de 80 /gp/road/Classic/shared/css/gp.css - user1 - DIRECT www.beispielseite.de text/css http://www.beispielseite.de/ "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" OBSERVED "News/Media" - 10.33.36.12007-06-14 13:08:47 324 172.22.1.141 304 TCP_MISS 269 509 GET http www.beispielseite.de 80 /gp/road/Classic/shared/js/functions.js - user1 - DIRECT www.beispielseite.de application/x-javascript http://www.beispielseite.de/ "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" OBSERVED "News/Media" - 10.33.36.1

3.2.11.5 SecureComputing Webwasher Format

Das als Software erhältliche, mittlerweile aber vorrangig als Appliance vertriebene Produkt Webwasher integriert diverse Sicherheitsfunktionen eines Internet-Gateways, die sich auch in den Logging-Funktionen wiederfinden. Die folgende Darstellung orientiert sich an der aktuellen Version 6.0 der Webwasher-Software, welche hinsichtlich ihrer Logging-Funktionen leistungsfähiger ist im Vergleich zu älteren Versionen.

Zur Auswahl stehen folgende Logdateien:

Name der Logdatei FunktionHTTP Access Log Für alle WebzugriffeHTTP Access Deny Log Nur für alle verweigerten WebzugriffeSecurity Log Für alle Aktionen der diversen SicherheitsfunktionenUpdate Log Für automatisierte AktualisierungsvorgängeSMTP Inbound Log Informationen über eingehende E-Mail-AktivitätenSMTP Outbound Log Informationen über ausgehende E-Mail-AktivitätenSMTP Filter Log E-Mail betreffende Sicherheitsfunktionen wie AntispamSMTP Debug Log Nach Bedarf zu aktivierendes Debug-Logging für E-MailError LogExceptions LogAudit Log Für administrative VorgängeFound Viruses Log Für gefundene VirenFeedback LogCustom Log Separate, anpassbare Logdatei

Tabelle 35: Logdateien in Webwasher

Jede dieser Logdateien kann angepasst werden hinsichtlich folgender Optionen:

– Verschlüsselung (automatische Verschlüsselung; Entschlüsselung nur über Vier-Augen-Prinzip möglich)

– Rotation (größen- und zeitabhängig)


Logdatenstudie

– Löschung (der jeweils ältesten Dateien)

– Übertragung der Daten an zentrale Sammler-Server

– Formatfelder

Die Logdateien lassen sich per HTTP, HTTPS und FTP in konfigurierbaren Stundenintervallen automatisiert auf einen zentralen Server transferieren. Eine Syslog-Option steht nicht zur Verfügung.

Für die Formatfelder steht eine umfangreiche Liste möglicher Felder bereit. Felder hieraus können zu einem passenden Logformat zusammengestellt werden. Standard-Einstellungen für zwei Logdateien sind im Folgenden beschrieben, wobei als Trennzeichen Kommas, Strichpunkte, Tabulator-Zeichen und andere verwendet werden können und auch Anführungszeichen und Klammern nach Bedarf eingebaut werden dürfen.

HTTP Access Log:src_ip_anonymous - "auth_user_anonymous" time_stamp "req_line" status_code bytes_to_client "referer" "user_agent" "attribute" block_res "media_type" "profile" elapsed_time "virus_name"Audit Log:time_stamp interface auth_user src_ip "event" "policy" setting "setting_old_value" "setting_new_value" ui_locationFür eine detaillierte Betrachtung der Konfigurationsmöglichkeiten steht neben der Produktdokumentation auch die Hilfefunktion der Administrationsoberfläche zur Verfügung.

3.2.12 Mailserver

Mailserver (genauer Mail Transport Agents, MTA) inklusive der häufig integrierten Komponenten zum Viren- und Spamschutz können ihre Logmeldungen nur schlecht standardisieren, da sehr unterschiedliche Meldungsarten generiert werden müssen.

Formate aus diesem Umfeld können maschinell nur schlecht weiterverarbeitet werden.

3.2.12.1 Exchange Server Message Tracking Format

Das Logging des Microsoft Exchange Servers ist in verschiedene Module unterteilt. Zum einen findet eine Protokollierung in das lokale Windows-Ereignisprotokoll statt, dessen Format bereits beschrieben wurde (siehe Abschnitt 3.2.2.1). Ähnlich wie der Microsoft IIS Webserver unterstützt der Exchange Server aber auch ein eigenes Logging. Dieses besteht aus folgenden Komponenten:

– Message Tracking: Hier werden alle Arten von Nachrichtenübermittlungen protokolliert, so dass der Verbleib einzelner Nachrichten abklärbar ist. Es ist per Default nicht aktiviert, stellt aus Sicherheitssicht jedoch einen Mehrwert dar, so dass sich seine Aktivierung empfiehlt.

– Protokoll-Logging: Dieses auf SMTP-Server-Komponenten aktivierbare Logging protokolliert die SMTP-Befehle, die bei der Nachrichtenübertragung verwendet werden. Hier ist per Default das bereits bekannte W3C-Format eingestellt, so dass hier auf eine Format-Beschreibung verzichtet wird.

– Diagnostisches Logging: Dieses ist nach Bedarf zu aktivieren, um vorliegende Probleme einzugrenzen.


Logdatenstudie

Das Message Tracking Format wird im Folgenden als einziges genauer beleuchtet. Es ist für den Exchange Server in der Version 2007 wie folgt aufgebaut:

Feld-Nummer


1 Date Datum des Ereignisses2 Time Zeit des Ereignisses3 Client-IP IP-Adresse des Clients4 Client-Hostname Hostname des Clients5 Partner-Name Name des Nachrichten-empfangenden Services6 Server-Hostname Hostname des protokollierenden Servers7 Server-IP IP-Adresse des protokollierenden Servers8 Recipient-address Nachrichten-Empfänger (X.400- oder SMTP-Adresse)9 Event-ID Zahl, die der protokollierten Aktion entspricht10 MSGID Nachrichten-ID11 Priority Priorität: -1 gering, 0 normal, 1 hoch12 Recipient-Report-

StatusEmpfangsstatus der Berichte: 0 = zugestellt, 1 = nicht zugestellt

13 Total-Bytes Größe der Nachricht in Bytes14 Number-Recipients Gesamtzahl an Empfängern15 Origination-Time Innerhalb von Exchange gespeicherte Zustellzeit16 Encryption Verschlüsselungsstatus einer Nachricht: 0 = unverschlüsselt,

1 = signiert, 2 = komplett verschlüsselt17 Service-Version Version des Exchange-Server-Dienstes18 Linked-MSGID Nachrichten-ID auf der Gegenseite19 Message-Subject Die ersten 256 Bytes des Nachrichten-Betreffs20 Sender-Address Absende-Adresse in SMTP-, X.400- oder DN-Form

Tabelle 36: Felder des Message Tracking Format in Exchange Server

Das Message Tracking Format wird von Microsoft unter folgendem Link detailliert beschrieben:

http://support.microsoft.com/kb/246965

3.2.12.2 Sendmail-Format

Das Sendmail-Logging hat sich im Laufe der Weiterentwicklung von Sendmail analog mitentwickelt. Im Folgenden wird das Logging für Versionen oberhalb von Version 8.12 beschrieben.

Sendmail versendet seine Logzeilen per Default an das lokale Syslog-System. Der Aufruf erfolgt im Programm-Code durch die Funktion openlog:openlog(SM_LOG_STR, LOG_PID, LOG_MAIL);


http://support.microsoft.com/kb/246965

Logdatenstudie

Diese Zeile bewirkt das Herstellen einer Verbindung mit dem lokalen Syslog-System, unter der über die Variable SM_LOG_STR definierbaren Kennung für den Sendmail-Daemon selbst, unter Angabe der PID des Sendmail-Prozesses (LOG_PID) sowie der Facility, die unter LOG_MAIL definierbar ist. Standardmäßig ist dies die Facility „mail“.

Sendmail besitzt einen eigenen konfigurierbaren Log-Level, der auf den Syslog-Level abzubilden ist. Sendmail kennt Log-Level von 0 bis 98; je höher die Zahl, desto mehr Informationen werden protokolliert. Ein Log-Level von 15 ist aus Sicherheitssicht sinnvoll, da hier auch die empfangenen SMTP-Kommandos mitgeschrieben werden. Der Default-Wert ist 9. In der mc-Konfiguration für Sendmail wird dies folgendermaßen konfiguriert:define(`confLOG_LEVEL', 15)Die bei Sendmail-Level 15 im Syslog abgebildete Priorität ist „info“.

Das Format der Sendmail-Meldungen im Syslog ist nach dem Standard-Syslog-Kopf mit Datum, Uhrzeit und Hostname folgendermaßen aufgebaut:<syslog-header> sendmail[<pid>]:<qid>: <tag>=<value>, [...]Dabei ist qid die Sendmail-ID der betroffenen E-Mail, tag das Schlüsselwort und value der Wert des jeweiligen Tags.

Dies entspricht einer named-value-Notation im Message-Teil der Syslog-Nachricht. Eine Auswahl wichtiger Schlüsselwörter ist in der folgenden Tabelle erläutert:

Schlüsselwort Bedeutungbodytype Body-Type der Nachrichtdaemon Daemon des Absendersdelay Gesamtzeit zur Bearbeitung der Nachrichtfrom Envelope/Senderangabelen Länge eines zu langen Headersmailer Verwendeter Delivery Agentmsgid Message-ID im E-Mail-Headernrcpts Anzahl der Empfängerpri Anfängliche Prioritätproto Verwendetes Übertragungsprotokollreject Grund für den Rejectrelay Host, der die Nachricht versendet oder entgegengenommen hatsize Größe der Nachrichtstat Status der Zustellungto Empfänger

Tabelle 37: Schlüsselwörter im Sendmail-Format


Logdatenstudie

3.2.12.3 Exim-Format

Exim bietet ein einfach zu konfigurierendes und flexibles Logging an. Es gibt drei Log-Streams, nämlich

– mainlog für normale Betriebsmeldungen,

– rejectlog für aufgrund von Richtlinien zurückgewiesene E-Mails und

– paniclog für schwerwiegende Fehler in Exim.

Es besteht zudem die Möglichkeit, in lokale Dateien und/oder in das lokale Syslog-System zu protokollieren. Die Konfiguration des Loggings erfolgt in der zentralen Konfigurationsdatei über die VariableLOG_FILE_PATH=syslog : /var/log/exim.logIn diesem Beispiel ist sie auf Syslog und den angegebenen Pfad gesetzt. Die Syslog-Facility ist per Default LOG_MAIL, der Prozessname exim. Der mainlog-Stream wird auf die Syslog-Priorität „info“ gesetzt, rejectlog auf „notice“ sowie paniclog auf „alert“.

Mögliche Komplikationen entstehen durch doppelte Meldungen, welche in den verschiedenen Log-Streams vorkommen und durch lange Zeilen, die von Exim auf mehrere Syslog-Meldungen aufgebrochen werden. Ersteres kann durch die Option SYSLOG_DUPLICATION vermieden werden, letzteres bedarf einer Kompilierung von Exim mit Nicht-Standard-Werten.

Das Format der Logmeldungen ist auch für lokale Logdateien im Syslog-Format gehalten: dem Standard-Syslog-Header folgen eine Message-ID und ein kurzes Symbol für die E-Mail-Flussrichtung. Danach folgt eine Kombination von Schlüsselwörtern mit Werten, um knapp den Inhalt der Meldung darstellen zu können. Beispiel (aufgebrochen auf zwei Zeilen):2002-10-31 09:00:10 16ZCW1-0005MB-00 => [email protected] R=dnslookup T=remote_smtp H=holistic.fict.example [192.168.234.234]Das Zweizeichen-Symbol „=>“ steht in diesem Beispiel für „ausgehende E-Mail“. Weitere Optionen sind hierfür:

– <= : Eintreffende Nachricht

– => : Normale Versendung der Nachricht

– -> : weitere Adresse innerhalb derselben Zustellung

– *> : Zustellung unterdrückt durch die Option -N

– ** : Zustellung fehlgeschlagen, Nachricht wurde zurückgeschickt („bounced“)

– ==: Zustellung verschoben wegen eines temporären Problems

Die in der Meldung in der Folge auftretenden möglichen Schlüsselwörter sind folgende:

Schlüsselwort BedeutungA Name des AuthentifiziertenC SMTP-Bestätigung bei Zustellung


Logdatenstudie

Schlüsselwort BedeutungCV Status der ZertifikatsüberprüfungDN Distinguished Name des ZertifikatsDT Nur bei =>: Zeit für die ZustellungF Absender-Adresse (nur bei Zustellung)H Hostname und IP-AdresseI Lokal verwendetes Netzwerk-Interfaceid Message-ID der eintreffenden NachrichtP <=: verwendetes Protokoll

=>, **: Return-PfadQT =>: Wartezeit in der Queue

„Completed“-Meldungen: GesamtwartezeitR <=: Referenz für einen lokalen „Bounce“

=>, **, ==: Name des RoutersS NachrichtengrößeST „Shadow“-TransportnameT <=: Nachrichten-Betreff

=>, **, ==: TransportnameU Lokaler Benutzer, bzw. ident-BenutzerX TLS-Verwendung

Tabelle 38: Schlüsselwörter im Exim-Format

3.2.12.4 Postfix-Format

Das Postfix-Log-Format ist stark an Sendmail angelehnt, im Wesentlichen nicht konfigurierbar und auch nicht gut dokumentiert. Per Default werden die Daten in das lokale Syslog-System mit dem Log-Level „debug“ und der Facility „LOG_MAIL“ geschrieben. Der Hauptunterschied im Format liegt in der Tatsache begründet, dass Postfix im Gegensatz zum monolithischen Sendmail aus interagierenden Unterprozessen/Modulen besteht, die jeweils für sich nur einen Teil der Aufgaben eines Mail Transport Agents erledigen. Dieser Umstand spiegelt sich im Logging wider und wird durch die Kennzeichnung des jeweiligen Prozesses als „postfix/<modul>“ kenntlich gemacht.

Beispiel:<syslog-header> postfix/<modulname> [pid]: qid: <tag>=<value>, [...]Folgende Module treten hierbei auf:


Logdatenstudie

Modul Beschreibung

bounce Daemon für Nachrichten „bouncing“ und „deferring“cleanup Nachrichten-Speicherung und -Standardisierunglocal Lokale Mail-Zustellungmaster Master-Prozess zur Steuerung der anderen Prozessepickup Lokaler Mail-Pickupqmgr Queue Managershowq Programm zur Anzeige der Mail Queuesmtp SMTP Clientsmtpd SMTP Servertrivial-rewrite Adress-Umschreibung und Namensauflösung

Tabelle 39: Module im Postfix-Format

Mögliche Werte für Schüsselwörter/Tags sind folgende:

Schlüsselwort Modul; Beschreibunguid pickup; UID des Absendersfrom pickup; Absender-Benutzernamemessage-id cleanup; Global eindeutiger Identifier der Nachrichtfrom qmgr; Absende-Mailadressesize qmgr; Größe der Nachricht in Bytesrelay smtp; Relay der versendeten Nachrichtdelay smtp; Verzögerung bei der Nachrichtenzustellung in Sekundenstatus smtp; Status der Nachrichtto smtp; Empfänger-Adresse der Nachrichtto local; Empfänger der Nachrichtrelay local; Relay der versendeten Nachrichtdelay local; Verzögerung bei der Nachrichtenzustellung in Sekundenstatus local; Status der Nachrichtclient smtpd; Relay, von dem die Nachricht empfangen wurde

Tabelle 40: Schlüsselwörter im Postfix-Format

Ein Debug-Logging kann bei Postfix für einzustellende Kommunikationspartner des Mailservers über die Option „debug_peer_list” betrieben werden, indem dann noch der „debug_peer_level” hochgesetzt wird.

Folgende Logbeispiele illustrieren das oben Dargestellte:Mar 3 01:06:14 nibbles4u postfix/smtp[16435]: connect to mail.nibbles4u.com[70.30.166.248]: Connection timed out (port 25)


Logdatenstudie

Mar 3 01:06:14 nibbles4u postfix/smtp[16435]: 0B432816D8: to=<admin@nibbles4u.com>, relay=none, delay=79995, status=deferred (connect to mail.nibbles4u.com[70.30.166.248]: Connection timed out)Mar 3 01:06:40 nibbles4u postfix/smtp[16432]: connect to alt1.gmail-smtp-in.l.google.com[64.233.167.114]: Connection timed out (port 25)

3.2.12.5 Qmail-Format

Qmail ist ein aus Unterkomponenten bestehender Mail Transport Agent. Logmeldungen können über das Unterprogramm „Splogger“ in das Syslog-System geschrieben werden. Auch ist es üblich, in lokale Logdateien zu protokollieren. Das Format ist abgesehen vom Syslog-Header unabhängig von der Speicherart, da die Meldungen von den einzelnen Qmail-Modulen erzeugt und nur unterschiedlich weitergereicht werden. Das Logging selbst ist über die Module betrachtet sehr uneinheitlich:

– Beispielsweise meldet sich die Qmail-send-Komponente nicht mit eigenem Namen, sondern loggt einfach den Inhalt der Meldung. Meist, aber nicht immer, wird hierbei eine eindeutige Nachrichten-Nummer referenziert, die eine Identifikation der E-Mail über die einzelnen Prozessschritte hinweg erlaubt.

– Der Prozess Qmail-smtpd vermeldet seinerseits von weiteren Unterprogrammen Logmeldungen. Diese heißen z. B. tcpserver, rblsmtpd oder jgreylist (letztere sind Komponenten zur Spam-Identifizierung). Diese Unterprogramme melden sich eingangs mit ihrem Namen, teilweise unter Angabe einer Prozess-ID, teilweise ist diese noch nicht vergeben, weil es sich um einen sehr früh agierenden Server-Prozess handelt, z. B. ein Greylisting.

Die Interpretation von Qmail-Logdaten ist dementsprechend schwierig, wenn es sich um maschinelle Weiterverarbeitung handelt. Das Format ist als für den Menschen lesbares Format konzipiert.

Beispiele:

Qmail-send[TIMESTAMP] new msg 12345Nach dem formell differierenden Zeitstempel folgt die eigentliche Meldung. Die Zahl entspricht der eindeutigen Nachrichten-Nummer. Hier ein weiteres Qmail-send-Beispiel:[TIMESTAMP] info msg 12345: bytes 3189 from <[email protected]> qp 27763 uid 46Die eindeutige Nachrichten-Nummer wird hier referenziert. Nach der Kernmeldung folgen nach dem optionalen Doppelpunkt nähere Informationen.

Qmail-smtpd[TIMESTAMP] tcpserver: pid 22333 from 1.2.3.4[TIMESTAMP] jgreylist[22333]: 1.2.3.4 OK knownDiese zwei Meldungen stammen aus den Unterprogrammen, tcpserver und jgreylist. Letzteres kann im Gegensatz zum ersteren eine Prozess-ID referenzieren („22333“), die in der ersten Meldung aufgegriffen wird, aber an ganz anderer Stelle steht.


Logdatenstudie

Zusammenfassend kann man sagen, dass das Qmail-Format kaum einzugrenzen ist, was eine maschinelle Verarbeitung sehr erschwert.

3.2.12.6 SpamAssassin-Format

SpamAssassin ist ein Open-Source-Modul, das im Rahmen des Apache-Projekts gepflegt wird. Es wird in Mailserver wie Sendmail, Postfix oder Procmail eingebunden, um durchlaufende E-Mails auf Spam zu überprüfen. Diese werden dabei verschiedenen Tests unterzogen, und die jeweiligen Test-Teilergebnisse werden aufsummiert. Überschreitet die Summe einen konfigurierbaren Grenzwert, so gilt eine E-Mail als Spam klassifiziert. Für die Einbindung als Modul wird SpamAssassin entweder nach Bedarf aufgerufen oder auch als Daemon betrieben.

Die Spam-Konfiguration von SpamAssassin erfolgt beim Start mithilfe mehrerer, auf das System verteilter Konfigurationsdateien, die globale wie benutzerspezifische Einstellungen enthalten können. Für das Logging ist aber der Aufruf des SpamAssassin-Programms selbst entscheidend. Für die Daemon-Variante muss die Option-s <FACILITY>verwendet werden, damit das Default-Logging in das Syslog-System erfolgt.

Seit der Version 3.x verwendet SpamAssassin ein gut zu verarbeitendes Format innerhalb von Syslog. Folgendes Beispiel zeigt den durch eine Spam-E-Mail erzeugten Eintrag eines Servers, der SpamAssassin über das amavis-Modul eingebunden hat:Aug 15 06:47:37 dogma spamd[22796]: result: Y 21 - BAYES_99,BODY_ENHANCEMENT2,DCC_CHECK,DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO,HTML_70_80,HTML_BACKHAIR_2,HTML_FONT_BIG,HTML_FONT_SIZE_LARGE,HTML_MESSAGE,HTML_OBFUSCATE_05_10,MIME_HTML_ONLY,MISSING_SUBJECT,MSGID_FROM_MTA_ID,RCVD_IN_NJABL_DUL,RCVD_IN_RFC_IPWHOIS,RCVD_IN_SBL,RCVD_IN_SORBS_DUL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL scantime=3.1,size=1098,mid=<[email protected]>,bayes=1,autolearn=spamFolgendes Format wird nach dem Standard-Syslog-Header angewandt:

– Nach „result“ folgt ein „Y“ für Spam bzw. ein „.“ für Nicht-Spam.

– Danach folgt das gerundete Ergebnis für die gewertete E-Mail.

– Das folgende Feld ohne konkreten Inhalt wird mit „-“ befüllt.

– Danach folgt eine Auflistung der vorgenommenen Test-Methoden.

– Zuletzt wird eine Komma separierte Reihe von „named-value-pairs“ aufgeführt. Es dürfen hier jederzeit neue, zuvor unbekannte Paare aufgenommen werden, solange sie kommasepariert sind. Die Reihenfolge dieser Paare ist beliebig.

Dieses Format-Schema ist unter folgendem Link dokumentiert:

http://wiki.apache.org/spamassassin/SpamdSyslogFormat


http://wiki.apache.org/spamassassin/SpamdSyslogFormat

Logdatenstudie

3.2.13 Virenschutz-Anwendungen

Viele kommerzielle Virenschutz-Produkte beinhalten heutzutage eine zentrale Verwaltung zur Steuerung der auf viele Clients verteilten Installation. Beispiele für solche Verwaltungsprodukte sind der McAfee ePolicy Orchestrator, der Trendmicro Control Manager und der F-Secure Policy Manager. Diese rufen die Logdaten der entsprechenden Einzelprodukte wie McAfee Virusscan oder Trendmicro Officescan über die Agenten-Software ab und transferieren diese auf den zentralen Server. Hier werden die Logdaten zumeist in einer Datenbank gespeichert, um ein auf dieser basierendes Berichtswesen zu ermöglichen. Abfragen gegen diese Datenbanken können über SQL-Abfragen via ODBC oder JDBC durchgeführt werden. Ob dies über das Netzwerk prinzipiell möglich ist, hängt von der verwendeten Datenbank und ihrer Konfiguration ab. Abfragen entsprechen dann Standard-SQL-Statements.

Weitere Produkt-Beispiele inkl. Datenbank sind die Virenscanner von Trendmicro für Lotus Domino und Microsoft Exchange oder am Internet-Gateway die Interscan Messaging Security Suite.

Im Folgenden werden Beispiele für klassische Logdateien aufgelistet, wie sie v. a. auf stark dezentralen Client-Systemen anzutreffen sind. Formate aus diesem Umfeld können maschinell meist gut weiterverarbeitet werden.

3.2.13.1 McAfee Virusscan Enterprise Format

Das Virenschutz-Produkt Virusscan Enterprise der Firma McAfee verwendet ein lokales Logging sowie die Möglichkeit, sich in ein zentrales Logging und Reporting für McAfee-Produkte mithilfe des Produkts ePolicy Orchestrator (ePO) zu integrieren. An dieser Stelle wird im Wesentlichen das lokale Logformat beschrieben und die ePolicy-Integration skizziert. Diese Ausführungen gelten für die Version 8.0i.

Für die verschiedenen Subfunktionen des Virusscan-Produkts können verschiedene Logdateien eingestellt werden:(%VSEFEDLOGDIR%=<Drive>\Documents and Settings\All Users\Application Data\Network Associates\Virusscan)

Logdatei Lokation Format-EinstellungenACCESSPROTECTIONLOG %VSEFEDLOGDIR%\Access

ProtectionLog.txt– Max. 1 MB– Unicode UTF-8

BUFFEROVERFLOWPROTECTIONLOG

%VSEFEDLOGDIR%\BufferOverflowProtectionLog.txt

– Max. 1 MB– Unicode UTF-8

ONACCESSSCANLOG %VSEFEDLOGDIR%\OnAccessScanLog.txt

– Max. 1 MB– Unicode UTF-8– Optional:

• Session Settings• Session Summary• Failure to scan encrypted

file• User Name

ONDEMANDSCANLOG %VSEFEDLOGDIR%\OnDe – Max. 1 MB


Logdatenstudie

Logdatei Lokation Format-EinstellungenmandScanLog.txt – Unicode UTF-8

– Optional:• Session Settings• Session Summary• Failure to scan encrypted

file• User Name

EMAILONDEMANDLOG %VSEFEDLOGDIR%\EmailOnDemandLog.txt

– Max. 1 MB– Unicode UTF-8– Optional:

• Session Settings• Session Summary• Failure to scan encrypted

file• User Name

UPDATELOG %VSEFEDLOGDIR%\UpdateLog.txt

– Unicode UTF-8

Tabelle 41: Logdateien in McAfee Virusscan

Innerhalb der Logdateien verwendet McAfee ein nicht näher spezifiziertes Format. Es beinhaltet tabulatorgetrennte Felder, Zeilen beginnen jeweils mit Datum und Uhrzeit in zwei getrennten Feldern, worauf dann die eigentliche Meldung in einem lesbaren Klartext-Format folgt. Dieser Teil kann in sich wieder aus Tabulator-getrennten Feldern bestehen. Ereignisse können über mehrere Zeilen hinweg beschrieben werden. Das Format ist insgesamt auf Lesbarkeit für das menschliche Auge optimiert.

Beispiele für Logmeldungen der Client-Firewall-Komponente:11/9/2004 10:11:17 AM Blocked by port blocking rule nmap.exe Prevent mass mailing worms from sending mail 170.27.184.17311/9/2004 10:20:17 AM Blocked by port blocking rule nmap.exe Prevent mass mailing worms from sending mail 170.27.148.1211/9/2004 10:21:17 AM Blocked by port blocking rule nmap.exe Prevent mass mailing worms from sending mail 170.27.148.1211/11/2004 4:23:02 PM Blocked by port blocking rule nmap.exe Prevent mass mailing worms from sending mail 170.27.48.8911/16/2004 9:11:43 AM Blocked by port blocking rule sshd.exe Prevent IRC communication 127.0.0.1Bei einer Integration der Virusscan-Software in eine zentral per ePolicy Orchestrator (ePO) gesteuerte, unternehmensweit verteilte Virusscan-Installation sieht das McAfee-Konzept die Installation eines Software-Agenten auf jedem Virusscan-Rechner vor. Dieser Agentendienst ist u. a. für die Übertragung der Logdaten an den zentralen ePO-Server verantwortlich, wo diese gesammelt und in eine relationale Datenbank vom Typ Microsoft Desktop Engine (MSDE) geschrieben werden. Für die so gespeicherten Ereignisse können beispielsweise automatisierte Berichte erstellt und Alarmierungen durchgeführt werden.


Logdatenstudie

3.2.13.2 Symantec Antivirus Corporate Edition Format

Die Corporate Edition von Symantec Antivirus hat eine Verwaltungsinfrastruktur aus sogenannten Parent Servern, die insbesondere für das Zusammenführen der Logdaten der verwalteten Antivirus-Clients verantwortlich sind. Das Protokoll-Format ist ein kommasepariertes Klartextformat mit einer versionsabhängigen Anzahl von Feldern, deren Bedeutung fest definiert ist.

Die einzelnen Felder haben in der Regel einen eingeschränkten Wertebereich, der aber wiederum versionsabhängig ist. Die folgende Tabelle betrifft die Version 10.x:

Nr. Feldname Bedeutung1 LI_TIME Zeitstempel in Hexcode2 LI_EVENT Ereignisnummer (1-70)3 LI_CAT Kategoriennummer (1-4)4 LI_LOGGER Kodierung der protokollierenden Komponente5 LI_COMPUTER Name des Rechners mit dem Virenschutz6 LI_USER Benutzername7 LI_VIRUS Virusname8 LI_FILE Fundort des Virus im Verzeichnis9 LI_ACTION1 Eingestellte Primär-Aktion bei einem Virenfund10 LI_ACTION2 Eingestellte Sekundär-Aktion bei einem Virenfund11 LI_ACTION0 Unternommene Aktion bei einem Virenfund12 LI_VIRUSTYPE Kodierte Typenbezeichnung des Virus13 LI_FLAGS Unbekannt14 LI_DESCRIPTION Beschreibung für den Windows Eventlog15 LI_SCANID ID des Scans16 LI_NEW_EXT Unbekannt17 LI_GROUPID ID der Antivirus-Gruppe18 LI_EVENT_DATA Statistische Ergebnisse eines Scans19 LI_VBIN_ID ID einer ggf. in Quarantäne aufgenommenen Datei 20 LI_VIRUS_ID ID des gefundenen Virus21 LI_QUARFWD_STATUS Ergebnis eines Quarantänisierungsversuchs22 LI_ACCESS Hex-Kodierung des Betriebsstatus, meist leer23 LI_SND_STATUS Unbekannt24 LI_COMPRESSED Zeigt an, ob der Inhalt Teil eines Archivs war25 LI_DEPTH Zeigt an, in welcher Verschachtelungstiefe der Virus

war26 LI_STILL_INFECTED Zeigt an, wie viele Dateien eines Archivs immer noch


Logdatenstudie

Nr. Feldname Bedeutunginfiziert sind

27 LI_DEFINFO Version der verwendeten Virendatenbank28 LI_DEFSEQNUMBER Sog. Definition Sequence Number der Virendaten

bank29 LI_CLEANINFO Zeigt an, ob die infizierte Datei bereinigt werden kann30 LI_DELETEINFO Zeigt an, ob die infizierte Datei gelöscht werden darf31 LI_BACKUP_ID ID einer ggf. gesicherten Datei32 LI_PARENT Name des Parent Servers33 LI_GUID Windows GUID des infizierten Rechners34 LI_CLIENTGROUP Antivirus-Gruppe des infizierten Rechners35 LI_ADDRESS IP-Adresse des infizierten Rechners36 LI_DOMAINNAME Server-Gruppe (nur bei Parent Servern)37 LI_NTDOMAIN Windows-Domäne bzw. Arbeitsgruppe38 LI_MACADDR MAC-Adresse des infizierten Rechners39 LI_VERSION Software-Version des Symantec AV-Clients40 LI_REMOTE_MACHINE Name des angreifenden Rechners (nur ab Version 9)41 LI_REMOTE_MACHINE_IP IP-Adresse des angreifenden Rechners (nur ab Versi

on 9)42 LI_ACTION1_STATUS Status der angefragten Primär-Aktion (nur ab Version

9)43 LI_ACTION2_STATUS Status der angefragten Sekundär-Aktion (nur ab Ver

sion 9)44 LI_LICENSE_FEATURE_NAME Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)45 LI_LICENSE_FEATURE_VER Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)46 LI_LICENSE_SERIAL_NUM Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)47 LI_LICENSE_FULLFILMENT_ID Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)48 LI_LICENSE_START_DT Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)49 LI_LICENSE_EXPIRATION_DT Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)50 LI_LICENSE_LIFECYCLE Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)


Logdatenstudie

Nr. Feldname Bedeutung51 LI_LICENSE_SEATS_TOTAL Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)52 LI_LICENSE_SEATS Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)53 LI_ERR_CODE Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)54 LI_LICENSE_SEATS_DELTA Für die Lizenzkontrolle mit „Business Pack“-Produk

ten (nur ab Version 9)

Tabelle 42: Felder einer Meldung von Symantec Antivirus

Eine Beschreibung auch der möglichen Feldwerte kann unter

http://www.symantec.com/enterprise/support/overview.jsp?pid=51852

mit dem Suchbegriff „interpreting the log files“ abgerufen werden.

Beispiele für dieses Logformat:240801012128,5,1,720997,RBLWAP,SYSTEM,Trojan.Zlob,C:\WINDOWS\system32\ld100.tmp,5,4,4,256,570441764,"",0,,0,,0,4254,0,0,0,0,0,0,20060830.022,58100,2,4,0,acme-AVSRV,{579642AA-5A5E-46E1-8613-2289349D1F27},,(IP)-192.168.100.237,acmeav,acme,,8.1.825

240801012128,5,1,720997,RBLWAP,SYSTEM,Trojan.Nebuler,C:\WINDOWS\system32\winvdj32.dll,5,4,4,256,570441764,"",0,,0,,0,18150,0,0,0,0,0,0,20060830.022,58100,2,4,0,acme-AVSRV,{579642AA-5A5E-46E1-8613-2289349D1F27},,(IP)-192.168.100.237,acmeav,acme,,8.1.825

240801012128,5,1,720997,RBLWAP,SYSTEM,Trojan Horse,C:\WINDOWS\TEMP\winD51.tmp,5,4,4,256,570441764,"",0,,0,,0,25464,0,0,0,0,0,0,20060830.022,58100,2,4,0,acme-AVSRV,{579642AA-5A5E-46E1-8613-2289349D1F27},,(IP)-192.168.100.237,acmeav,acme,,8.1.825

3.2.13.3 ClamAV-Format

ClamAV ist ein Open-Source-Virenscanner. Auch die für die Erkennung neuer Viren entscheidende Aktualität der Virenmuster wird durch die Open-Source-Gemeinde sichergestellt.

ClamAV kann als lokaler Virenscanner für Dateien aufgerufen werden, aber auch über das Modul clamav-milter in Mail-Server wie Sendmail oder Exim eingebunden werden, damit er die durchlaufenden E-Mails scannt.

Das Logging von ClamAV ist per Default deaktiviert (siehe

http://docsrv.caldera.com:8457/cgi-bin/man?mansearchword=clamav.conf&mansection=5 ).

Im Folgenden wird ein Logging für die Syslog-Schnittstelle beschrieben. Hierfür ist in die Datei clamav.conf die ZeileLogSyslog


http://docsrv.caldera.com:8457/cgi-bin/man?mansearchword=clamav.conf&mansection=5

http://www.symantec.com/enterprise/support/overview.jsp?pid=51852

Logdatenstudie

aufzunehmen. Damit auch Scans sauberer Dateien gemeldet werden, muss die OptionLogCleanaktiviert werden. Die OptionLogTimewürde das Mitschreiben der Zeit bewirken, was im Fall von Syslog aber unnötig ist, da diese Funktion bereits vom Syslog-Daemon übernommen wird.

Es empfiehlt sich, die per Syslog-Integration entstehenden Logdateien den üblichen Überwachungen (Speicherplatz) und Aktionen (Rotation, Komprimierung, Archivierung) zu unterziehen.

Per Default loggt ClamAV mit der Facility LOG_LOCAL6. Im Fall eines Einsatzes als E-Mail-Virenscanner kann auch die LOG_MAIL-Facility angebracht sein. Der Schalter für die Facility lautetLogFacility <FACILITY>.ClamAV verwendet kein festes Logformat. Die Meldungen sind im engeren Sinn „human-readable“ wie folgendes Beispiel zeigt:Jan 31 23:38:27 addr3ss clamd[4605]: Log file size limited to 5242880 bytes. Jan 31 23:38:27 addr3ss clamd[4605]: Running as user clamav (UID 52, GID 52) Jan 31 23:38:27 addr3ss clamd[4605]: Reading databases from /var/lib/clamav Jan 31 23:38:29 addr3ss clamd[4605]: Protecting against 30065 viruses. Jan 31 23:38:29 addr3ss clamd[4605]: Bound to address 127.0.0.1 on port 3310 Jan 31 23:38:29 addr3ss clamd[4605]: Setting connection queue length to 23 Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Archived file size limit set to 15728640 bytes. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Recursion level limit set to 9. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Files limit set to 1000. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Compression ratio limit set to 300. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Limited memory usage. Jan 31 23:38:29 addr3ss clamd[4605]: Archive support enabled. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: RAR support disabled. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Blocking encrypted archives. Jan 31 23:38:29 addr3ss clamd[4605]: Archive: Blocking archives that exceed


Logdatenstudie

limits. Jan 31 23:38:29 addr3ss clamd[4605]: Portable Executable support enabled. Jan 31 23:38:29 addr3ss clamd[4605]: Detection of broken executables enabled. Jan 31 23:38:29 addr3ss clamd[4605]: Mail files support enabled. Jan 31 23:38:29 addr3ss clamd[4605]: OLE2 support enabled. Jan 31 23:38:29 addr3ss clamd[4605]: HTML support enabled. Jan 31 23:38:29 addr3ss clamd[4605]: Self checking every 600 seconds.

3.2.14 Netzwerk- und Schwachstellen-Scanner

Netzwerk- und Schwachstellen-Scanner geben ihre Ergebnisse über eine Art von Logdatei aus. Deren Logformate sind oft XML-basiert, um die sehr variablen Ergebnisse der Scans gut darstellen zu können.


3.2.14.1 NMAP-Format

Das Open-Source-Tool für Portscans und die Identifikation von Betriebssystemen (engl. „OS Fingerprinting“) von Hosts bietet eine Reihe von Konfigurationsoptionen an, die ermittelten Daten auszugeben bzw. zu speichern:

● Zusammenfassende Ausgabe (Standard)

● XML-Ausgabe (für die automatische Weiterverarbeitung)

● Einfache Textliste (pro gefundenem Host wird eine Zeile mit den ermittelten Informationen ausgegeben)

Für die automatische Weiterverarbeitung ist das XML-Format von Vorteil, da über Skript- wie auch Programmiersprachen diverse XML-Parser zur Verfügung stehen. Diese wird im Folgenden beschrieben.

NMAP bietet für seine XML-Struktur eine Dokumenttyp-Definition (DTD) an, in der alle Inhalte und Attribute beschrieben sind. Die aktuelle Version der DTD ist zu finden unter

http://insecure.org/nmap/data/nmap.dtd.

Eine danach erzeugte XML-Ergebnisdatei ist in zwei Abschnitte aufgeteilt. Zu Beginn wird die Konfiguration des Portscans mit Parametern der Unterprogramme nmaprun, scaninfo, verbose und debugging dargestellt. Daraufhin folgt für jeden überprüften Host ein eigenständiger Abschnitt mit allen Informationen, die über diesen gesammelt werden konnten. Dieser Abschnitt beinhaltet unter anderem folgende Informationen:

– Status (up/down)

– IP-Adresse

– MAC-Adresse

– Hostname


http://insecure.org/nmap/data/nmap.dtd

http://insecure.org/nmap/data/nmap.dtd

Logdatenstudie

– Liste der offenen Ports

– Liste der Services, die über die offenen Ports angeboten werden

– Informationen für die Erkennung des Betriebssystems

Eine detaillierte Beschreibung aller Elemente kann in der DTD von nmap nachgelesen werden. Auf die Angabe eines Logbeispiels wird wegen des umfangreichen XML-Formats des Logs verzichtet.

3.2.14.2 Nessus-Format

Der Schwachstellen-Scanner Nessus ist ein weit verbreitetes Werkzeug zur Untersuchung eines Netzwerkes auf bekannte Schwachstellen. Ähnlich wie nmap führt Nessus ein sog. „Host Discovery“ sowie Portscans durch, um Netzwerkgeräte und ihre Dienste zu identifizieren. Im Gegensatz zu nmap können mit Nessus auch Schwachstellentests auf die identifizierten Zielsystemen ausgeführt werden. Die Ergebnisse der Tests werden in Form von XML-Daten auf der Nessus-Server-Komponente gespeichert. Nessus bietet die Möglichkeit, die Ergebnisse in unterschiedlicher Art und Weise als Bericht darzustellen:

– HTML-Bericht

– XML-Bericht

– Text-Bericht

Für die automatische Weiterverarbeitung ist das XML-Format vorteilhaft. Pro Host werden alle über das Zielsystem gefundenen Informationen dargestellt. Die Struktur des XML-Reports von Nessus sieht folgende Datenfelder vor:

– Allgemeine Informationen über den durchgeführten Schwachstellen-Scan

• Ziel des Scans

• Start-/Ende-Zeit des Scans

– Detaillierte Informationen über die Zielsysteme

• IP-Adresse

• Hostname

• Liste der offenen Ports

• Liste der Services, die über die offenen Ports angeboten werden

• Falls vorhanden, eine Auflistung der Schwachstellen der auf den offenen Ports lauschenden Software

• Falls vorhanden, eine Auflistung lokaler Schwachstellen, wenn für den Scan auch ein lokaler Benutzer-Account zur Verfügung stand

• Informationen über die Erkennung des Betriebssystems

Weitergehende Informationen können im Internet gefunden werden unter

http://www.nessus.org/documentation/.

Auf die Angabe eines Logbeispiels wird wegen des XML-Formats verzichtet.


http://www.nessus.org/documentation/

http://www.nessus.org/documentation/

Logdatenstudie

3.2.14.3 QualysGuard-Format

QualysGuard ist ein ausgelagert in Qualys-Rechenzentren betriebener Service der Firma Qualys für das Management von Schwachstellen. Über eine Webanwendung können Qualys-Kunden Schwachstellen-Scans konfigurieren und durchführen. Diese erfolgen entweder über Internet-Scanner auf Kundensystemen mit öffentlichen IP-Adressen oder über entfernte Scanner, die im lokalen Netz des Kunden installiert und ferngesteuert werden. Sämtliche Ergebnisse dieser Schwachstellenanalysen werden verschlüsselt in einer Datenbank gespeichert und sind über Schnittstellen wieder abrufbar.

In folgenden Formaten können die Scan-Ergebnisse über das Benutzer-Interface zur Verfügung gestellt werden:

– HTML

– PDF

– MHT

– XML

Darüber hinaus gibt es einige Funktionen, die über das QualysGuard-API bereitstehen. Für die automatische Weiterverarbeitung gesammelter Informationen können mithilfe solcher API-Aufrufe XML-Reports erzeugt werden. Qualys liefert für alle XML-Dokumentvorlagen eine Dokumenttyp-Definition (DTD), in der Inhalte und Attribute beschrieben sind. Eine aktuelle Version der API-Dokumentation inklusive aller DTDs ist zu finden unter

http://www.qualys.com/docs/QualysGuard_API_User_Guide.pdf.

In einem Scanreport werden alle ermittelten Informationen über das bzw. die Zielsysteme aufgeschlüsselt nach System-IP-Adresse dargestellt. Die Struktur des XML-Reports von QualysGuard für Schwachstellen-Scans sieht folgende Informationen vor:

– Allgemeine Informationen über den durchgeführten Schwachstellen-Scan

• Anfordernder Benutzer

• Start-Zeit und Dauer

• Titel

• Zielsysteme

• Ausführender Scanner

• Anzahl der erreichbaren Zielsysteme

• Anzahl der Zielsysteme, die maximal erreichbar hätten sein können

• Scan-Optionen

• Status des Scans (Finished/Canceled/Paused/Interrupted)

– Detail-Informationen über jedes Zielsystem

• IP-Adresse/DNS-Name/NetBIOS-Name

• Liste von Informationen über das System

› Informationen, die über das System gesammelt werden konnten


http://www.qualys.com/docs/QualysGuard_API_User_Guide.pdf

http://www.qualys.com/docs/QualysGuard_API_User_Guide.pdf

Logdatenstudie

› Potenzielle Schwachstellen, die aus bestimmten Gründen nicht endgültig verifiziert werden konnten

› Schwachstellen (lokale und remote), die verifiziert werden konnten und definitiv vorhanden sind

■

• Zu jeder Schwachstelle werden Informationen angeboten, wie diese beseitigt werden kann (Konfigurationsänderungen/Patch etc.)

Auf die Angabe eines Logbeispiels wird wegen des XML-Formats verzichtet.

3.2.14.4 McAfee Foundstone Format

McAfee Foundstone Enterprise ist ein datenbankgestütztes Schwachstellen-Management-System. Zum Einsatz kommen zwei Komponenten, die zentrale Verwaltungseinheit mit Datenbank und die darüber administrierbaren Scanner. Alle Scan-Ergebnisse werden im Klartext in einer Microsoft SQL-Datenbank gespeichert. Für eine Weiterverarbeitung der ermittelten Daten steht eine Reihe von Ausgabemöglichkeiten zur Verfügung:

– XML

– CSV

– HTML

– PDF

– Direkter Zugriff auf die Datenbank

Für die Weiterverarbeitung der ermittelten Scan-Ergebnisse wird direkt über SQL-Abfragen auf die Datenbank zugegriffen. Für diese Abfragen sollte ein dedizierter Benutzer angelegt werden, der lediglich lesende Rechte auf der Datenbank besitzt.

Des Weiteren werden die für den Betrieb des Systems erzeugten System- und Aktivitäts-Logmeldungen zentral abgelegt.

Auf die Angabe eines Logbeispiels muss wegen des Datenbankformats des Logs verzichtet werden.

3.2.15 Weitere wichtige Dienste und Daemons

Im diesem Abschnitt werden die Logformate weiterer wichtiger Programme dargestellt.

3.2.15.1 ISC Bind Format

Die DNS-Server Implementierung des Internet Software Consortiums (ISC) mit Namen Bind ist die im Internet am weitesten verbreitete Variante. So laufen die 13 Root-Server des DNS im Internet auf Bind-Basis. Bind wird in der Regel auf Linux bzw. Unix betrieben, auch wenn eine Portierung für Windows existiert. Im Folgenden wird das Logging und seine Konfiguration für die Version 9 unter Unix-artigen Betriebssystemen dargestellt.


Logdatenstudie

Wie unter diesen Systemen üblich wird das Logging in das lokale Syslog-Subsystem präferiert. Um dies zu erreichen, müssen entsprechende Statements in die zentrale Bind-Konfigurationsdatei named.conf aufgenommen werden.

Entscheidend sind im Wesentlichen drei Statements:

1. Das „logging“-Statement: Hierunter werden die Details zu Ziel und Inhalt des Loggings zusammengefasst.

2. Das „channel“-Statement: Hierunter wird das Ziel des Loggings definiert.

3. Das „category“-Statement: In verschiedenen solcher Statements werden Inhalte (Kategorien) einem jeweiligen Channel (Ziel) zugeordnet.

Durch die „category“-Statements ist auszuwählen, welche Inhalte von Interesse sind. Kategorien, die keinem speziellen Channel zugewiesen werden, werden der Default-Kategorie zugewiesen und so behandelt wie die Default-Kategorie. Existiert keine Anweisung für die Behandlung der Default-Kategorie, so werden diese Ereignisse folgendem „Standard-Default“ zugeordnet:category default { default syslog; default debug; };Die hinter dem Bind-Logging stehenden Überlegungen legen es dem Administrator nahe, sich über Inhalte und Ziele des Loggings Gedanken zu machen, da das Standard-Logging nicht sinnvoll ist bzw. zu viele Informationen liefert. Folgende Konfiguration liefert aus einer Sicherheitsperspektive beispielsweise wertvolle Informationen:logging {

channel Ziel-Logdatei {syslog;severity debug;print-time no;print-severity no;print-category no;

};category default {Ziel-Logdatei; };category client {Ziel-Logdatei; };category config {Ziel-Logdatei; };category database {Ziel-Logdatei; };category dnssec {Ziel-Logdatei; };category queries {Ziel-Logdatei; };category resolver {Ziel-Logdatei; };category security {Ziel-Logdatei; };category update {Ziel-Logdatei; };category update-security {Ziel-Logdatei; };category xfer-in {Ziel-Logdatei; };category xfer-out {Ziel-Logdatei; };


Logdatenstudie

};Folgende Kategorien werden von Bind bereitgestellt:

Kategorie Bedeutungdefault Alle Kategorien, die nicht explizit angewiesen werden, fallen unter diese

Kategorie.client Bearbeitung von Client-Requestsconfig Verarbeitung der Bind-Konfigurationdatabase Die Bind-interne Datenbank für Zonen und Cache betreffende Ereignissednssec Verarbeitung der DNSSEC und TSIG-Protokollequeries Abfragen der Bind-Datenbankresolver DNS-Abfragen, die vom Server aus initiiert werden, z. B. rekursive

Lookupssecurity Genehmigung und Verweigerung von Requestsupdate Dynamische Aktualisierungen der Bind-Datenbankupdate-security Genehmigung und Verweigerung von Aktualisierungs-Requestsxfer-in vom Server empfangene Zonentransfersxfer-out vom Server versendete Zonentransfer

Tabelle 43: Kategorien in ISC Bind

Eine vollständige Liste aller Kategorien findet sich auf der öffentlichen Bind-Dokumentationsseite unter

http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#id2553006.

Das Bind-Format der Logmeldungen ist nach Syslog spezifiziert. Im eigentlichen Meldungsteil folgt es keinem festen Format mehr. Es ist in erster Linie lesbar für das menschliche Auge und nicht maschinenlesbar. Das Bind-Format kann maschinell nicht gut weiterverarbeitet werden. Hier zwei Beispiele:Aug 29 15:33:13 ns3 named[464]: client 217.148.39.3#1036: query (cache) denied Aug 29 15:33:13 ns3 named[464]: client 217.148.39.4#32769: query (cache) denied

3.2.15.2 Samba-Format

Samba ist eine unter der GNU General Public Licence stehende Software, die eine Reihe von Diensten über das SMB/CIFS Protokoll bereitstellt, sowie in Windows-Netzwerken die Rolle eines Domänencontrollers übernehmen kann.

Die folgenden Ausführungen beziehen sich auf die Version Samba 3.0. Speicherort und Namen der im Klartext abgelegten Logdateien können frei konfiguriert werden. Hierzu stehen verschiedene Konfigurationsparameter zur Verfügung. Alle Parameter werden im entsprechenden Abschnitt der zentralen Konfigurationsdatei smb.conf getätigt und sind ausführlich beschrieben unter


http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#id2553006

http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#id2553006

Logdatenstudie

http://de.samba.org/samba/docs/man/manpages-3/smb.conf.5.html.

Sämtliche Einstellungen bezüglich des Logverhaltens von Samba werden im globalen Abschnitt der Konfigurationsdatei vorgenommen. Grundsätzlich werden bei Samba zwei Logdateien, jeweils eines für die beiden Dienste des Samba Pakets, geschrieben:

– NMBD (NMBD ist der NetBIOS-Name Server und bietet via NetBIOS über TCP/IP entsprechende Namensdienste an.)

– SMBD (SMBD beinhaltet Datei-Server und Router für RPC-basierte Dienste)

Standardmäßig werden alle Log-Einträge in den Logdateien log.smbd und log.nmbd im Verzeichnis $SAMBA_BASE/var erfasst. $SAMBA_BASE ist hierbei das Samba-Installationsverzeichnis. Mithilfe des Parameters „log file“ können Anpassungen bezüglich des Speicherpfads, aber auch der Dateinamen vorgenommen werden:

Über folgenden Konfigurationsparameter wird der Pfad der Logdateien angepasst und für jeden angeschlossenen Client ein separates Log erzeugt:log file = /var/log/samba/log.%mMithilfe der Konfigurationsvariable können Logdateien anforderungsgemäß generiert werden. Mit der folgenden Konfiguration werden beispielsweise Logdateien für den jeweiligen Dienst (Laufwerksfreigabe) angelegt:log file = /var/log/samba/log.%SDurch die Verwendung der Parameter „log level“ und „max log size“ können Log-Level und maximale Dateigröße der Logdateien festgelegt werden. Der Wert für den Log-Level reicht hier von 0 bis 10, wobei 10 dem maximalen Debuglevel entspricht. Der Log-Level entspricht dem Parameterwert der Option -d , welche beim Daemon-Start auf der Kommandozeile übergeben wird. Diese hat den Standard-Wert 0, falls keine Angaben gemacht werden. Jeder Wert größer als 3 sollte für den reinen Betrieb vermieden werden, da in diesen Levels Details ausgeben, die nur für die Samba-Programmierung relevant sind:log level = 2Weitere wichtige Einstellungen für das Logverhalten von Samba sind diese:

Parameter Typ/Wert Funktion Defaultlog file String Name und Speicherpfad der Logdatei Definiert im Makefile

des Samba-Quell-Code

log level 0-10 Setzt den Log-Level:0 – kein Logging 3 – ausführliches Logging für den Betrieb

1

max log size Größe in KB

Maximale Größe der Logdatei. Nach Erreichen der Größe wird die Datei in .bak geändert und eine neue Logdatei begonnen.

5000

debug timestamp Boolean Schalten der Zeitstempeloption: An (yes) - bzw. Aus (no)

yes

debug hires Boolean Erweitert den Logzeitstempel um Mikrose no


http://de.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

http://de.samba.org/samba/docs/man/manpages-3/smb.conf.5.html

Logdatenstudie

Parameter Typ/Wert Funktion Defaulttimestamp kunden: An (yes) - bzw. Aus (no)debug pid Boolean Erweitert den Log-Eintrag um die Prozess-

IDno

syslog 0-10 Alle Nachrichten unterhalb des angegebenen Wertes werden an den Syslog-Dienst geschickt.

1

syslog only Boolean Wird dieser Wert auf „yes“ gesetzt, wird ausschließlich Syslog für das Logging eingesetzt, lokale Logdateien werden nicht mehr beschrieben.

no

Tabelle 44: Parameter für die Steuerung von Logs in Samba

Ein Samba-Log-Eintrag besteht ab Log-Level 1 aus mindestens zwei Zeilen pro Aktion. Das Logformat von Samba beinhaltet hierbei folgende Felder:

– Zeitstempel der Anfrage

– Protokollierender Dienst (smbd/nmbd)

– Durchgeführte Aktion

– Client-Name

– Client-IP

– Angefragte Freigabe

– Anfragender Benutzer (Name/UID/GID)

– Prozess-ID

Die nicht unerheblichen Schwierigkeiten bei der automatisierten Weiterverarbeitung der Samba-Logs werden unter anderem durch die mehrzeiligen Log-Einträge pro Meldung verursacht: In den Standardlogs enthält nicht jede Logzeile einen Zeitstempel. Dieses Problem kann mithilfe der Anbindung an Syslog verringert werden, indem hier jede Zeile mit einem Zeitstempel versehen wird.

3.2.15.3 Asterisk-Format

Asterisk ist eine unter der GNU General Public Licence stehende Software, die umfangreiche Funktionen im Bereich Telefonie zur Verfügung stellt, beispielsweise Funktionen einer klassischen Telefonanlageoder eines Voice over IP Gateway.

Die folgenden Ausführungen beziehen sich auf die Version Asterisk 1.2. Das Logging innerhalb von Asterisk kann sehr fein konfiguriert werden. So können die Logdateien auf jedem System unterschiedliche Namen haben. Ebenfalls kann unterschieden werden, ob Asterisk in eigene Logdateien speichert oder über Syslog die Meldungen an einen zentralen Server weiterleitet. Es kann auch eingestellt werden, welche Nachrichten eines Log-Levels in welcher Datei erfasst werden sollen. Konfiguriert wird das Logverhalten von Asterisk in der Datei logger.conf, und die Logdateien werden (unter Linux) per Default im Verzeichnis /var/log/asterisk abgelegt. Die Konfigurationsdatei logger.conf ist in zwei Abschnitte unterteilt.


Logdatenstudie

– [general] – Ausgabe und Formatierung der einzelnen Log-Einträge, z. B. das verwendete Zeitstempelformat, können hierüber verändert werden.

– [logfiles] – Hier können die diversen Logdateien mit zugehörigen Log-Levels konfiguriert werden.

Folgende unterschiedliche Meldungsarten gibt es innerhalb des Asterisk-Dienstes:

Meldungsart Erklärungdebug Ausgabe detaillierter Nachrichten und Events, die während des Betriebs auftreten.

Z. B. wird hier unter anderem auch die Eingabe der DTMF-Töne mitprotokolliert.verbose Ausgabe der Aktionen, die das System aktuell durchführt. Dies wird bevorzugt

für Debug-Aktionen mit der CLI-Konsole eingesetzt, kann aber auch in eine Datei gespeichert werden. Für den Verbose-Modus gibt es wiederum eine Untergliederung von 1-10, wobei 10 die detaillierteste Ausgabe erzeugt.

notice Notices sind Hinweismeldungen, die ausgegeben werden, sobald sich im System etwas verändert.

warning Warnmeldungen werden ausgegeben, wenn Asterisk eine Aktion ausführen will und diese nicht erfolgreich war.

error Fehlermeldungen, meist hervorgerufen durch „Out-of-Memory-Fehler“

Tabelle 45: Meldungsarten in Asterisk-Format

Mithilfe dieser Optionen ist es möglich, dass z. B. alle „warning“- und „error“-Meldungen in die Datei „messages“ geschrieben und andererseits alle „debug“-Meldungen in der Datei „debug“ erfasst werden. Auf die gleiche Art und Weise kann definiert werden, welche Meldungen mittels Syslog an einen zentralen Syslog-Host geschickt werden sollen.

Das Logging von Asterisk sieht ohne erhöhten Debug-Modus folgende Informationen vor:– Zeitstempel der Meldung

– Art der Meldung (z. B. WARNING, ERROR, DEBUG)

– Welches Modul verursachte die Meldung?

– Meldungstext

Die Felder der Log-Einträge sind jeweils durch ein Leerzeichen voneinander getrennt. Durch Erhöhung des Verbose-Levels können detailliertere Informationen wie z. B. die Felder des Absenders, des Ziels oder der SIP-Verbindung ausgelesen werden.

Das Asterisk-Format kann maschinell nicht gut weiterverarbeitet werden. Folgendes Beispiel illustriert die Formlosigkeit der Asterisk-Meldungen nach dem Syslog-Header:Jun 23 12:06:16 asterisk1 kevs-zapstuff: Asterisk Event Logger Started /var/log/asterisk/event_log Jun 23 12:06:16 asterisk1 kevs-zapstuff: Asterisk Dynamic Loader loading preload modules: Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Manager registered action Ping Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Manager registered action MailboxStatus Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Manager registered action MailboxCount


Logdatenstudie

Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Manager registered action ListCommands Jun 23 12:06:16 asterisk1 kevs-zapstuff: Asterisk Management interface listening on port 5038 Jun 23 12:06:16 asterisk1 kevs-zapstuff: == RTP Allocating from port range 10000 -> 20000 Jun 23 12:06:16 asterisk1 kevs-zapstuff: Asterisk PBX Core Initializing Jun 23 12:06:16 asterisk1 kevs-zapstuff: Registering builtin applications: Jun 23 12:06:16 asterisk1 kevs-zapstuff: [AbsoluteTimeout] Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Registered application 'AbsoluteTimeout' Jun 23 12:06:16 asterisk1 kevs-zapstuff: [Answer] Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Registered application 'Answer' Jun 23 12:06:16 asterisk1 kevs-zapstuff: [BackGround] Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Registered application 'BackGround' Jun 23 12:06:16 asterisk1 kevs-zapstuff: [Busy] Jun 23 12:06:16 asterisk1 kevs-zapstuff: == Registered application 'Busy'

Jun 23 12:06:16 asterisk1 kevs-zapstuff: [Congestion]

3.2.16 Tabellarische Übersicht und Zusammenfassung

Format-Name Binär? Beschreibung Protokoll Single/Multiple LineSyslog Klartext human-readable Syslog single-lineSNMP Klartext binär (ASN.1) SNMP multiple-lineCisco IOS Klartext human-readable Syslog single-lineCisco PIX Klartext human-readable Syslog single-lineNetFlow binär formlos NetFlow paketweiseIPFIX binär formlos IPFIX paketweiseCisco IPS Klartext human-readable Syslog single-lineJuniper Netscreen Security Manager

Klartext Datenbank ODBC -

McAfeeIntruShield

Klartext Datenbank ODBC -

3ComTipping Point

Klartext CSV Syslog single-line

Unix/Linux Klartext human-readable Syslog single-lineMS Windows NT-2003 Server

binär binär WMI multiple-line

MS Windows Vista

binär binär WMI multiple-line


Logdatenstudie

Format-Name Binär? Beschreibung Protokoll Single/Multiple LineMS IIS Klartext CSV Lokale Datei single-lineMS Exchange Klartext CSV Lokale Datei single-lineMS ISA Klartext CSV Lokale Datei single-lineSquid Klartext CSV Lokale Datei

Syslogsingle-line

NetCache Klartext CSV Lokale DateiSyslog

single-line

Bluecoat SG Klartext CSV Lokale Datei single-lineSecureComputingWebwasher

Klartext CSV Lokale DateiSyslog

single-line

ISC Bind Klartext human-readable Syslog single-lineApache Klartext CSV Lokale Datei

Syslogsingle-line

Sendmail Klartext human-readable Syslog single-lineExim Klartext human-readable Syslog single-linePostfix Klartext human-readable Syslog single-lineQmail Klartext human-readable Syslog single-lineSpam Assassin Klartext named-value pairs Syslog single-lineMcAfeeVirusscan

Klartext CSV Lokale Datei single-line

Symantec AV Klartext CSV Lokale Datei single-lineClamAV Klartext human-readable Syslog single-lineSamba Klartext Lokale Datei

Syslogsingle-line

Asterisk Klartext Lokale DateiSyslog

single-line

Tomcat Servlet Container

Klartext formlos Lokale DateiSyslog

multiple-line

NMAP Klartext XML Lokale Datei multiple-lineNessus Klartext XML Lokale Datei multiple-lineQualysGuard Klartext XML Web-API multiple-lineMcAfeeFounstone

Klartext Datenbank Web-API -

Tabelle 46: Übersicht über die beschriebenen Formate


Logdatenstudie

So wünschenswert eine Standardisierung im Bereich der Log- und Monitoring-Datenformate einerseits ist, so utopisch erscheint diese Vorstellung andererseits momentan. Inhalte und Zweck sind in den verschiedenen Bereichen sehr unterschiedlich, was die große Vielfalt an Formaten erklärt.

Betrachtet man die große Gruppe der syslog-basierenden Formate, so ist die nach wie vor vorherrschende Konzentration auf eine für den Menschen lesbare Darstellung augenfällig. Besonders negativ fallen hier die Email-Dienste auf, die allerdings auch sehr unterschiedliche Meldungsarten schreiben.

Nur wenige Bereiche, beispielsweise Proxies und Webserver, können weitgehend standardisierte und gut maschinenlesbare Formen vorweisen. Der Bereich der Firewalls ist zwar nicht standardisiert, jedoch sind die Meldungen in der Regel sehr gut weiterzuverarbeiten.

Hersteller-spezifische und proprietäre Ansätze sind offenbar ebenfalls nicht geeignet, eine gute Weiterverarbeitung der Daten zu garantieren. Oft spielen hier Aspekte wie Geheimhaltung, Verschleierung und Schutz geistigen Eigentums eine Rolle. Der Weiterverwendbarkeit der Daten im Rahmen von IT-Frühwarnsystemen ist dies nicht gerade förderlich.

Zumindest für Netzwerk-basierte Dienste und Anwendungen wäre ein Kompromiss zwischen Maschinen- und Menschen-lesbarkeit wünschenswert. Aktuelle Tendenzen gehen in die Richtung von Notierungsweisen, die auf named-value-Pairs basieren.


Logdatenstudie

4 StandardisierungsbestrebungenDie Internet Engineering Task Force (IETF) ist eine Organisation, die sich mit der technischen Weiterentwicklung des Internets befasst, um seine Funktionsweise zu verbessern und standardisierte Vorgehensweisen und Protokolle zu definieren. Verschiedene Arbeitsgruppen (Working Groups, WG) sind mit Teilaspekten der Internet-Technologie und ihrer Weiterentwicklung und Standardisierung befasst. Die Mitglieder dieser WGs rekrutieren sich aus verschiedensten Umfeldern, unter anderem auch aus Universitäten und Unternehmen.

4.1 „Security Issues in Network Event Logging“ (Syslog)

Der bereits in frühen Tagen der Entwicklung des Betriebssystems BSD entwickelte Syslog-Dienst zur Übertragung von Logmeldungen des Betriebssystemkerns und installierter Applikationen ist in vielen Unix-artigen Betriebssystemen implementiert. Dennoch hat sich über alle Betriebssystemvarianten kein einheitlicher Standard durchsetzen können. Im Jahre 2001 wurde das RFC 3164 veröffentlicht, um diesen Missstand zu beheben. Das genannte RFC hat aber nur informellen Charakter und konnte nie als Standard verabschiedet werden. In RFC 3164 wurden zudem Schwächen in der Sicherheit des Protokolls aufgezeigt.

Aus diesem Grund führte die IETF die Arbeitsgruppe Syslog zur Weiterentwicklung von Syslog als offenem und sicherem Protokollstandard fort. Das Ziel der Arbeitsgruppe ist es, die Schwächen in der Sicherheit und der Integrität von Syslog zu lösen. Weiterhin sollen das Protokoll, die Transportmechanismen und auch die Kompatibilität zu bereits existierenden Implementierungen und deren leichte Migration standardisiert werden. Aus Gründen der Performanz und des geringen Datenaufkommens hat sich das Transportprotokoll UDP etabliert. Allerdings ist die gesicherte Zustellung damit nicht gewährleistet. Deshalb wurde außerdem ein verbindungsorientiertes Transportprotokoll definiert und an der Erweiterungsfähigkeit des Protokolls gearbeitet.

Darüber hinaus hat die Arbeitsgruppe auf der Homepage des IETF veröffentlicht, dass sie je ein Dokument zu folgenden Themen erstellen möchte:

– Für ein standardisiertes Syslog, welches Daten strukturiert darstellt

– Für die standardisierte Übertragung von Meldungen über UDP

– Zur standardisierten, sicheren Übertragung von Meldungen

– Zur Standardisierung der Entitäten innerhalb der MIB von Syslog

– Zur signierten und authentifizierten Übertragung zum Zweck der Integrität und Authentizität von Meldungen

HistorieBereits im Oktober 2000 gab die Arbeitsgruppe Syslog einen Entwurf zur Vereinheitlichung des Syslog-Protokolls heraus. Dieses ging in der Version 12 im August 2001 in den RFC 3164 über.

Ebenfalls im Oktober 2000 folgte die Veröffentlichung eines weiteren Entwurfs zur zuverlässigen und sicheren Übertragung von Syslog-Meldungen. Dies wurde mit dem RFC 3195 im November 2001 in der Version 12 verabschiedet.


Logdatenstudie

Im Januar 2001 gab die Arbeitsgruppe einen Entwurf zur authentifizierten Übertragung von Meldungen heraus.

Ein erster Entwurf zur gesicherten und signierten Übertragung von Meldungen wurde im Januar 2001 veröffentlicht. Dieser Entwurf liegt in der Version 21 vom März 2007 vor und wird immer noch aktiv weiterentwickelt.

Im November 2001 kam ein Entwurf zur Schaffung einer einheitlichen MIB heraus. Dieser wird immer noch aktiv bearbeitet und liegt in der neuesten Fassung in der Version 15 vom März 2007 vor.

Im August 2003 kam ein Entwurf für die Unterstützung von internationalen Zeichensätzen hinzu.

Die Veröffentlichung eines ersten Entwurfs für das erweiterte Protokoll Syslog erfolgte im Dezember 2003. Der Entwurf hat seine letzte Fassung in der Version 20 im Mai 2007 erfahren und bisher wurde keine finale Version veröffentlicht.

Im März 2004 folgte der erste Entwurf für die Spezifikation des Transportmechanismus UDP in Syslog. Die letzte Version 9 kam im März 2007 heraus. Bisher ist dieses Teilprojekt noch nicht abgeschlossen.

Die Veröffentlichung des ersten Entwurfs zur Verwendung der Transport Layer Security (TLS) bei der Übertragung von Syslog zur Absicherung gegen Angriffe auf das Protokoll erfolgte im März 2006. Die aktuelle Version 9 vom April 2007 liegt vor, es ist aber noch keine finale Veröffentlichung in Sicht.

Drafts und Requests for Comments (RFC) Die Homepage der Arbeitsgruppe Syslog ist unter folgender URL zu finden:

http://www.ietf.org/html.charters/syslog-charter.html

Die nachfolgenden Entwürfe (Drafts) und RFC können auf der Homepage der IETF unter folgendem Link eingesehen werden:

http://tools.ietf.org/wg/syslog/


http://tools.ietf.org/wg/syslog/

http://www.ietf.org/html.charters/syslog-charter.html

Logdatenstudie

Draft/RFC Aktuelle Version Datum der ersten Version

Datum der letzten Version

draft-ietf-syslog-international 00 Nicht verfügbar 01.08.2003draft-ietf-syslog-auth 00 Nicht verfügbar 02.01.2001Draft-ietf-syslog-syslog (RFC 3164)

12 10.06.2000 27.08.2001

draft-ietf-syslog-reliable (RFC 3195)

12 18.10.2000 01.11.2001

draft-ietf-syslog-transport-udp 09 09.03.2004 19.03.2007draft-ietf-syslog-transport-tls 09 27.03.2006 23.04.2007draft-ietf-syslog-protocol 20 03.12.2003 02.05.2007draft-ietf-syslog-sign 21 02.01.2001 20.03.2007draft-ietf-syslog-device-mib 15 26.11.2001 05.03.2007

Tabelle 47: Übersicht über Drafts/RFCs der Arbeitsgruppe Syslog

Zusammenfassung wichtiger RFCs

RFC 3164 – The BSD syslog Protocol

Der RFC 3164 datiert vom August 2001 und spezifiziert die bis heute gültigen Vorgaben für das Syslog-Protokoll zur Übertragung von Logmeldungen über das Netzwerk. Autor des RFC ist C. Lonvick von Cisco Systems. Nach einer einleitenden Beschreibung zur generellen Charakterisierung von Syslog als flexiblem und einfachem Dienst mit wenig Spezifika geht der Autor dazu über, die System- oder Applikationsereignisse sowie die hieraus resultierenden Meldungen zu umreißen. Die Verarbeitung der empfangenen Meldungen auf Seiten des Syslog-Servers werden nicht in diesem RFC be- oder vorgeschrieben.

Genaue technische Angaben zum Syslog-Protokoll gemäß des RFCs finden sich auch im vorhergehenden Abschnitt (Übersicht über Protokolle).

Der RFC legt UDP als Transportschicht-Protokoll für Syslog fest, Port 514 wird empfohlen, ist aber nicht unbedingt erforderlich.

Außerdem werden die möglichen Rollen in der Syslog-Kommunikation festgeschrieben. Hierzu gehören „Device“ (das die Logmeldung generierende Gerät), „Relay“ (das die Logmeldungen weiterleitende Gerät) und „Collector“ (das die Logmeldungen sammelnde Gerät, typischerweise auch als Syslog-Server bezeichnet). Ferner werden die Regeln, denen Syslog-Architekturen unterliegen, verdeutlicht.

Im folgenden Kapitel werden die Anforderungen und Empfehlungen an Syslog-Paketformate spezifiziert, damit sie als RFC-konform gelten können. Dies umfasst Spezifikationen für den PRI-Teil, welcher wiederum Priorität und Facility beinhaltet, sowie den Header-Teil, der die Zeitangabe und den Hostnamen des sendenden Systems beinhaltet.

Der MSG-Teil des Pakets ist praktisch völlig frei verwendbar.


http://draft-ietf-syslog-device-mib/

http://draft-ietf-syslog-sign/

http://draft-ietf-syslog-protocol/

http://draft-ietf-syslog-transport-tls/

http://draft-ietf-syslog-transport-udp/

http://draft-ietf-syslog-reliable/

http://draft-ietf-syslog-syslog/

http://draft-ietf-syslog-auth/

http://draft-ietf-syslog-international/

Logdatenstudie

Das RFC behandelt die Pflichten und Aufgaben der verschiedenen Rollen, welche Überprüfungen und Korrekturen bzgl. der Paketkonformität durchführen müssen.

Spezifikationen sehen unter anderem vor, dass die Jahreszahl nicht Teil des Zeitfeldes sein darf und dass es unüblich, aber nicht verboten ist, statt des Hostnamens den FQDN anzugeben. Inkompatibilitäten sind dabei jedoch ggf. in Kauf zu nehmen. Ferner gibt es die Option, Prozessinformationen wie die PID aufzunehmen.

Ein umfangreiches Kapitel des RFC widmet sich der Sicherheit und der Zuverlässigkeit von Syslog. Hier wird die maximale Paketlänge von 1024 Bytes als obligatorisch festgehalten. Auf andere Probleme und Gefahren kann nur hingewiesen werden, ohne dass eine Lösung zur Verfügung steht:

– Fehlende Authentifizierungsmöglichkeiten, unsicherer Ursprung

– Fälschungsmöglichkeiten

– Probleme mit einer falschen Reihenfolge oder wiederholtem Eintreffen der Pakete, v. a. in komplexeren Architekturen oder durch Angriffe

– Unzuverlässigkeit der Zustellung durch UDP

– Fehlende Integrität und fehlende Vertraulichkeit

– Keine Priorisierungsmöglichkeit von zu priorisierenden Meldungen bei der Übertragung

– Schleifen in komplexen Architekturen, die insbesondere durch Fehlkonfigurationen entstehen

– Lastprobleme und Möglichkeiten für Denial-of-Service-Attacken

Im Ausblick wird auf weitere wichtige Verbesserungsmöglichkeiten hingewiesen, z. B. auf die Verwendung internationaler Zeichensätze.

RFC 3195 – Verlässliche Zustellung für Syslog

In diesem RFC, das im November 2001 (Autoren D. New, M. Rose von Dover Beach Consulting) publiziert wurde, geht es um die Umsetzung von Syslog über TCP als verlässlichem Transport-Protokoll. Es baut auf dem RFC 3164 auf.

Basis der im RFC vorgeschlagenen Erweiterungen ist das sog. BEEP-Protokoll (Blocks Extensible Exchange Protocol, spezifiziert in RFC 3090). Zwei Profile, also Realisierungen einer BEEP-Implementierung, werden aufgeführt: das einfache RAW-Profil für optimale Abwärtskompatibilität und das leistungsfähigere COOKED-Profil mit Möglichkeiten zur Authentifizierung und Verschlüsselung.

Im Folgenden wird der beispielhafte Aufbau einer RAW-basierten Kommunikation zwischen einem Device und einem Collector dargestellt. Dabei bietet das BEEP-Protokoll Möglichkeiten, Einzelmeldungen über BEEP zu aggregieren, um den entstehenden Overhead zu kompensieren. Außerdem können so durch eine Fortführung der Verbindung sukzessive Logmeldungen versandt werden, ohne dass eine neue BEEP-Sitzung gestartet werden muss. Das RAW-Profil basiert auf dem MIME-Typ „application/octet-stream“.

Das COOKED-Profil mit dem MIME-Typ „application/beep+xml“ist seinerseits aus drei Elementen aufgebaut, die im RFC detailliert spezifiziert werden:

– Über das „IAM“-Element wird eine Authentifizierung der Kommunikationspartner ermöglicht. Es muss vom Gerät, das die Verbindung aufbaut, initiiert werden.


Logdatenstudie

– Das „ENTRY“-Element stellt eine verarbeitete Version des Syslog-Eintrags bereit, in der die Einzelfelder des Eintrags aufgeschlüsselt sind in die obligatorischen Bestandteile FACILITY, SEVERITY, TIMESTAMP, HOSTNAME und TAG sowie optionale Teile wie „deviceFQDN“.

– Im „PATH“-Element wird eine verschachtelte Liste von Relays, über die die Nachricht versendet wurde, zusammen mit einer Dokumentation der jeweils implementierten Sicherheitsmechanismen während dieser Weiterleitungsschritte erzeugt.

Kommunikationsbeispiele werden im RFC für alle drei Elemente aufgelistet und ebenso wie ihre Spezifikationen beschrieben .

Die über PATH-Elemente erreichbaren Sicherheitsstufen umfassen folgende Funktionen:

– Verschlüsselungsmöglichkeiten unterschiedlicher Stärken

– Authentifizierung über SASL oder TLS

– Zeitstempel gegen Replay-Angriffe

– Integritätsschutz

– Verlässlichkeit der Zustellung

In PATH sind einige Konsistenz- und Plausibilitätschecks als obligatorisch spezifiziert.

Das RFC erwähnt des Weiteren Priorisierungsmöglichkeiten über mehrere gleichzeitige Verbindungen, so dass höher priorisierte Meldungen auch über eine hochpriorisierte Verbindung geführt werden können, und empfiehlt konkrete Umsetzungen der BEEP-Implementierung, um die in RFC 3164 aufgelisteten Gefahren abzufangen.

Abschließend listet das RFC die nötigen technischen Spezifikationen und Fehler-Codes der BEEP-Erweiterung für Syslog auf.

Die neue Syslog-Version ist unter dem Namen „syslog-conn“ bei IANA registriert und läuft über den reservierten Port TCP/601.

4.2 „IP Flow Information Export“ (IPFIX)

Innerhalb einer Arbeitsgruppe der IETF wird das Protokoll IPFIX entwickelt. Zukünftig soll es als Internet-Standard veröffentlicht werden. Neben einer Reihe freiwilliger Mitarbeiter, die den Entwicklungsprozess unterstützen, sind einige offizielle Mitarbeiter benannt.

Das Ziel der Arbeitsgruppe besteht in der Entwicklung eines offenen und damit frei implementierbaren, skalierbaren und sicheren Protokolls zur Übertragung von Monitorinaten. Das Protokoll weist eine ähnliche Struktur und Aufbau wie das von Cisco entwickelte Protokoll Netflow auf. Nach anfänglicher Definition des Datenmodells von IPFIX und einer anschließenden Testphase zu den Möglichkeiten der Implementierung wurden die folgenden Anwendungen des Protokolls definiert:

– Usage Based Accounting; dies beinhaltet die Abrechnung von IP-Services basierend auf Benutzern, genutzten Services etc.

– Traffic Profiling; als Grundlage für Trend-Analysen, Netzwerkplanung etc.

– Traffic Engineering; als Grundlage für die Optimierung der Performanz und Auslastung des Netzwerkes wie in RFC 2702 beschrieben.


Logdatenstudie

– Attack/Intrusion Detection; beispielsweise das Erkennen von anomalem Datenverkehr oder Denial-of-Service-Attacken

– Quality of Service Monitoring; passives Überprüfen von Qualitätskriterien von IP-Flows

Die dargestellten Anwendungen sind nicht limitiert und können von Integratoren des Protokolls beliebig erweitert werden.

HistorieDie Arbeitsgruppe wurde im Jahre 2001 gegründet und ist immer noch aktiv.

Im November 2001 veröffentlichte die Arbeitsgruppe einen ersten Entwurf mit den Voraussetzungen für einen offenen Protokollstandard zur Übertragung von Monitorinaten. Dieser ging nach insgesamt 17 Überarbeitungen schließlich im Juni 2004 in ein RFC ein (RFC 3917).

Im Februar 2002 konnte der erste Entwurf (Draft) des Datenmodells von IPFIX veröffentlicht werden.

Im Februar 2002 wurde außerdem ein erster Entwurf für die Architektur von IPFIX herausgegeben. Auch dieser wurde einem stetigen Entwicklungsprozess unterzogen und befindet sich nach zwölf Überarbeitungen seit September 2006 in der Vorbereitungsphase zur Veröffentlichung im RFC-Status.

Der erste Entwurf zum Protokollaufbau von IPFIX erschien im Juni 2003 und ist in der Version 24 seit November 2006 ebenfalls in der Vorbereitungsphase zur Veröffentlichung als RFC.

Weiterhin wurde im Juni 2003 der erste Entwurf des Informationsmodells von IPFIX der Öffentlichkeit vorgestellt. Der Entwurf befindet sich seit Juni 2006 auch in der Vorbereitungsphase zur Veröffentlichung eines RFC.

Im Juni 2003 erschien ein weiterer Entwurf über die Verwendung des Protokolls innerhalb von Applikationen. Dieser befindet sich noch in Bearbeitung und liegt in der Version 11 vom Februar 2007 vor.

Im September 2006 wurden zwei weitere Entwürfe veröffentlicht. Der Entwurf zur Verringerung von Redundanzen befindet sich noch in der Entwicklung und hat mit Stand vom März 2007 die Version 3 erreicht. Der andere Entwurf zur Implementierung eines Mechanismus für bidirektionale Datenströme hat aktuell die Version 4 vom April 2007.

Nach stetigen Anpassungen der veröffentlichten Dokumente kam 2006 eine Testphase, zu der auch alle interessierten Integratoren des Protokolls eingeladen waren. Die Erkenntnisse finden sich in einem im Oktober 2006 veröffentlichten Entwurf.

Im September 2006 wurde mit der Entwicklung eines Leitfadens für Integratoren von IPFIX begonnen. Dieser befindet sich in der Version 3 vom April 2007 in der Entwicklung und wird aktiv bearbeitet.

Als zum momentanen Zeitpunkt jüngstes Dokument wurde im Februar 2007 ein Entwurf für die Schaffung einer einheitlichen Management Information Base (MIB) für IPFIX veröffentlicht.

Insgesamt kann man festhalten, dass die Arbeitsgruppe bereits weit fortgeschritten ist in ihren Bestrebungen zur Schaffung des Standards IPFIX. Die Dokumente sind weitgehend auf den Weg gebracht. Die vorläufige Verabschiedung des Standards IPFIX und der Zeitrahmen hierzu ist auch von der Veröffentlichung der RFCs durch die Internet Engineering Steering Group (IESG) abhängig. Diese ist der IETF übergeordnet und besitzt die Hoheit für die Veröffentlichung von RFCs .


Logdatenstudie

Drafts und Requests for Comments (RFC)Die Homepage der Arbeitsgruppe IPFIX ist unter folgender URL zu finden:


Die nachfolgenden Entwürfe (Drafts) und RFC können auf der Homepage der IETF unter folgendem Link eingesehen werden:

http://tools.ietf.org/wg/ipfix/

Draft/RFC Aktuelle Version Datum der ersten Version


draft-ietf-ipfix-data 00 Nicht verfügbar 26.02.2002draft-ietf-ipfix-arch 02 Nicht verfügbar 27.03.2003draft-ietf-ipfix-reqs (RFC 3917)

16 05.11.2001 06.10.2004(RFC 3917)

draft-ietf-ipfix-protocol 24 19.06.2003 09.11.2006draft-ietf-ipfix-info 15 18.06.2003 26.02.2007draft-ietf-ipfix-architecture 12 26.02.2002 10.09.2006draft-ietf-ipfix-reducing-redundancy

03 06.09.2006 01.03.2007

draft-ietf-ipfix-biflow 04 05.11.2001 11.02.2007draft-ietf-ipfix-as 11 20.06.2003 07.02.2007draft-ietf-ipfix-testing 00 Nicht Verfügbar 18.10.2006draft-ietf-ipfix-mib 00 Nicht verfügbar 26.02.2007draft-ietf-ipfix-implementation-guidelines

03 05.09.2006 26.04.2007

Tabelle 48: Übersicht über Drafts/RFCs der Arbeitsgruppe IPFIX


RFC 3917 – Die Spezifikation von IPFIX

In diesem RFC vom Oktober 2004 (Autoren Quittek, NEC et. al.) wird IPFIX spezifiziert. Es werden die Anforderungen definiert, um IP-Flow-Informationen aus den typischen Geräten wie z. B. Routern exportieren zu können.

Ausgehend von einer Klärung wichtiger Begriffe (IP Traffic Flow, Observation Point, Metering Process, Flow Record, Exporting Process, Collecting Process) werden typische Anwendungen für IPFIX beschrieben, aus deren Anforderungen sich die konkreten Spezifikationen ableiten lassen. Hierzu gehören folgende:

– Erfassung der Nutzung von IP-Diensten für die Abrechnung im Provider-Umfeld

– Profilerstellung von realem Datenverkehr

– Datenverkehrs-Konzeptionierung und -Betrieb


http://draft-ietf-ipfix-implementation-guidelines/

http://draft-ietf-ipfix-implementation-guidelines/

http://draft-ietf-ipfix-mib/

http://draft-ietf-ipfix-testing/

http://draft-ietf-ipfix-as/

http://draft-ietf-ipfix-biflow/

http://draft-ietf-ipfix-reducing-redundancy/

http://draft-ietf-ipfix-reducing-redundancy/

http://draft-ietf-ipfix-architecture/

http://draft-ietf-ipfix-info/

http://draft-ietf-ipfix-protocol/

http://draft-ietf-ipfix-reqs/

http://draft-ietf-ipfix-arch/

http://draft-ietf-ipfix-data/

http://tools.ietf.org/wg/ipfix/


Logdatenstudie

– Angriffserkennung – insbesondere von Denial-of-Service-Attacken und von Angriffspfaden

– Überwachung des Quality of Service

Anforderungen an den Metering Process zur Identifizierung von Flows sind die Fähigkeit nicht verschlüsselte Header-Felder auslesen zu können, um das verwendete Interface, Quell- und Ziel-Adresse, den Protokolltyp und den Port sowie ggf. MPLS-Label und DiffServ Code Point festzustellen.

Notwendigerweise besitzt der im RFC definierte Metering Process folgende Eigenschaften:

– Er muss verlässlich arbeiten bzw. seine Auswahl diesbezüglich jedenfalls bemerkt werden.

– Er muss für jeden Flow zwei Zeitstempel setzen und sich per NTP eine gültige Zeit holen können.

– Er muss das Auslaufen („Expiration“) eines Flows erkennen können.

Weitere optionale Anforderungen werden im RFC aufgelistet.

Im Folgenden spezifiziert der RFC die Anforderungen an den Datenexport zunächst über das sog. Informationsmodell („Information Model“), welches die nötigen Inhalte des Daten-Exports festlegt. Anschließend wird das Datenmodell („Data Model“), das die Formatierung der Informationen bestimmt, sowie den Datentransfer, welcher die Anforderungen an den Transport zusammenfasst, beschrieben. Das Informationsmodell ist sehr umfangreich und nochmal unterschieden bzgl. obligatorischer und optionaler Inhalte. Das Datenmodell ist nur sehr generisch spezifiziert. Der Datentransfer berücksichtigt Datenstaus („Congestions“) und wiederum nur generisch die Zuverlässigkeit der Datenzustellung. Eine genauere Analyse dieses Aspekts findet erst in RFC 3955 statt.

Die Sicherheitsanforderungen an den Datenexport umfassen die Vertraulichkeit, Integrität und Authentizität der übertragenen Daten, resultierend aus einer im RFC zusammengefassten Bedrohungsanalyse.

Benachrichtigungen innerhalb von IPFIX müssen einen Push-Modus für den Daten-Export unterstützen. Pull, regelmäßige Benachrichtigungen und Benachrichtigungen bei speziellen Ereignissen können optional eingerichtet werden. Ebenso optional ist eine Anonymisierung von Feldern der IPFIX-Inhalte.

Es folgen einige allgemeine Spezifikationsanforderungen an IPFIX wie Skalierbarkeit und Offenheit für künftige Erweiterungen, gefolgt von generischen Beispiel-Implementierungen .

Abschließend wird im RFC die bereits erwähnte Bedrohungsanalyse aufgeführt. Dabei gehen die Autoren von der Annahme aus, dass IPFIX-Daten auch über das öffentliche Internet übertragen werden und entsprechend mächtige Angreifer einzukalkulieren sind.

RFC 3955 – Evaluierung von IPFIX-Protokollkandidaten

In diesem RFC vom Oktober 2004 (Autor S. Leinen, SWITCH) wird die Evaluierung verschiedener Protokoll-Kandidaten für den Punkt des Datenexports bei IPFIX beschrieben. Der RFC baut auf RFC 3917 auf.

Als Testkandidaten wurden folgende Protokolle aufgenommen:

– CRANE

– Diameter

– LFAP


Logdatenstudie

– Netflow v9

– Streaming IPDR

Jedes der Protokolle wird im RFC bezüglich seiner Netzwerk-Eigenschaften und seiner Datenkodierung kurz charakterisiert.

Es folgt eine grobe Einteilung der Protokolle in Gruppen hinsichtlich folgender Kriterien:

3. Design-Ziel der Protokolle

• Ausgelegt auf hohe Performance bei der Flow-Messung: NetFlow, LFAP

• Vielseitigkeit im Carrier-Umfeld: IPDR, CRANE

• AAA: Diameter

4. Daten-Darstellung

– Extern definierte Kodierung: CRANE, IPDR, NetFlow

– Teilweise selbst festgelegte Kodierung: Diameter, LFAP

5. Protokoll-Fluss zwischen Exporting und Collecting Process

– Hauptsächlich unidirektional: IPDR, NetFlow

– Bidirektional: CRANE, LFAP

– Unidirektional nach initialer Aushandlung: Diameter

Ausführlich folgt im RFC eine Abbildung der in RFC 3917 definierten Protokoll-Anforderungen auf die Protokollkandidaten. Die geführte Diskussion führt zu folgendem Schluss:

Keiner der Kandidaten erfüllt alle Anforderungen, jeder hat Stärken und Schwächen. NetFlow wird als einfaches und leistungsfähiges Protokoll mit großer Verbreitung gelobt.

Es wird deshalb die Arbeit mit einem weiter zu entwickelnden NetFlow nahe gelegt. Dieses muss im Bereich der Sicherheit, der Zuverlässigkeit und des Abfangens von Datenstau zum Teil noch stark verbessert werden, um wichtige, bisher nicht erfüllte Anforderungen zu erfüllen.

4.3 IETF-Arbeitsgruppe „Remote Network Monitoring“ (rmonmib)

Die Internet Engineering Task Force (IETF) hatte eine Arbeitsgruppe unter dem Titel „Remote Network Monitoring“ (rmonmib) gebildet. Ihre Verantwortung lag in der Definition eines kontrollierten Objektsatzes zur ferngesteuerten Überwachung von Netzwerken. Seit November 2006 hat diese Gruppe ihre Arbeiten abgeschlossen und sich in der Folge aufgelöst.

Die Arbeitsgruppe „Remote Network Monitoring“ war in zwei Teilgruppen unterteilt. Diese bearbeiteten jeweils eine der folgenden Fragestellungen:

– SNMP- und MIB-Thematiken

– Transport der notwendigen Daten

Die Arbeit der Gruppe ordnet sich in bereits bestehende Standards insbesondere zu SNMP und MIB ein und hat diese weiterentwickelt. Allgemeine Zielstellung war es hierbei, einen minimalen Satz


Logdatenstudie

von Objekten zu definieren, mit dem entfernte Netzwerke auf verschiedenen Netzwerkschichten überwacht werden können, um sie in den Aspekten

– Fehler-Feststellung,

– Konfigurations-Management sowie

– Performance-Überwachung und -Management

kontrollieren zu können.

Weitere Ziele waren zuletzt unter anderem diese:

– Ermittlung der am stärksten benutzten, physikalischen Ports an Switches und anderen Geräten mit mehreren Interfaces

– Messung der Transport-Performance von Netzwerken durch Überwachung von Netzwerkpaketen und des Protokollverhaltens.

– Weiterentwicklung bestehender RFC-Standards, z. B. SMON MIB (RFC 2613), RMON-2 MIB (RFC 2021)

– Verbesserung der Dokumentation des bestehenden RMON-Rahmens

HistorieDie Anfänge der rmonmib-Arbeitsgruppe reichen bis in die 90er-Jahre zurück. Erste RFCs, auf denen aufgebaut werden konnte, datieren von 1994. Zuletzt bestanden die Aufgaben insbesondere in der Erweiterung und Aktualisierung dieser vorliegenden Ergebnisse.

Eines der letzten Ziele der Arbeitsgruppe lag im Bereich der Ermittlung der Performance von Netzwerk-Applikationen, konkret auf der Benutzerebene. Während vereinzelte Messwerte bezüglich der aktuellen Netzwerk-Performance oder zur Verfügung stehender Rechner-Ressourcen mit bestehenden Standards bereits ermittelt werden können, fehlten bis dato Möglichkeiten, die für den Benutzer maßgebliche Reaktionszeit bei Interaktion mit der Anwendung zu ermitteln. Hierfür hat die Arbeitsgruppe Erweiterungen der RMON-2 MIB definiert, die es erlauben, solche Performance-Messwerte per SNMP abzufragen – unabhängig davon, wie diese Messwerte konkret ermittelt werden (siehe RFC 4502). Ein weiterer RFC mit diesbezüglichen Ergebnissen ist RFC 3729, welcher die für den Benutzer wichtigen Größen der Anwendungsverfügbarkeit und der Schnelligkeit der Datenauslieferung behandelt.

Eingeordnet in den bereits bestehenden Rahmen von RMON-Spezifikationen wurde zudem ein gemeinsamer Rahmen und ein Satz von MIB-Objekten festgelegt und zur Verfügung gestellt, der in der Lage ist, das Ansprechverhalten und die Verfügbarkeit von Netzwerkendgeräten zu ermitteln und die gemessenen Werte an eine zentrale Stelle zu übermitteln. Zu den verwendeten Begrifflichkeiten gehört auch der Begriff Quality of Service (QoS) für solche Anwendungen. Die diesbezüglichen Ergebnisse mündeten in die RFCs 4710-4712.

Drafts und Requests for Comments (RFC)Die Homepage der rmonmib-Arbeitsgruppe wird nicht mehr gepflegt, der letzte Stand findet sich unter http://www.ietf.org/html.charters/OLD/rmonmib-charter.html.

Die folgende Liste der RFCs ist auch im Internet unter http://tools.ietf.org/wg/rmonmib/ veröffentlicht.


http://tools.ietf.org/wg/rmonmib/

http://www.ietf.org/html.charters/OLD/rmonmib-charter.html

Logdatenstudie

Draft/RFC Aktuelle Version

Datum der ersten Version


Draft-ietf-rmonmib-apm-mib(RFC 3729)

12 9.5.2000 1.3.2004

Draft-ietf-rmonmib-appverbs(RFC 3395)

4 24.7.2000 26.9.2002

Draft-ietf-rmonmib-dsmon-mib(RFC 3287)

9 9.3.2000 3.7.2002

Draft-ietf-rmonmib-framework(RFC 3577)

5 26.6.2002 7.8.2003

Draft-ietf-rmonmib-hc-alarm-mib(RFC 3434)

2 21.1.2002 18.12.2002

Draft-ietf-rmonmib-hcrmon(RFC 3273)

10 26.6.1997 10.7.2002

Draft-ietf-rmonmib-iftopn-mib(RFC 3144)

5 9.3.2000 1.8.2001

Draft-ietf-rmonmib-pi-ipv6(RFC 3919)

4 14.10.2003 6.10.2004

Draft-ietf-rmonmib-raqmon-framework (RFC 4710)

16 15.1.2003 18.10.2006

Draft-ietf-rmonmib-raqmon-mib(RFC 4711)

12 14.1.2003 9.10.2003

Draft-ietf-rmonmib-raqmon-pdu(RFC 4712)

14 15.1.2003 18.10.2006

Draft-ietf-rmonmib-rmon-oid-assignments (RFC 3737)

1 24.9.2003 5.4.2004

draft-ietf-rmonmib-rmon2-v2(RFC 4502)

5 29.8.2003 19.5.2006

Draft-ietf-rmonmib-rmon-full(RFC 2819)

1 2.7.1999 1.6.2000

Draft-ietf-rmonmib-rmonmib-v2(RFC 2021, obsoleted by RFC 4502)

2 5.6.1995 15.1.1997

Draft-ietf-rmonmib-rmonmib(RFC 1757, obsoleted by RFC 4502)

2 20.6.1994 9.2.1995

Draft-ietf-rmonmib-rmonprot-mac(RFC 2896)

1 16.11.1998 31.8.2000

Draft-ietf-rmonmib-rmonprot-ref(RFC 2895, going to be obsoleted by RFC 3395)

0 16.11.1998 31.8.2000

Draft-ietf-rmonmib-rmonprot 2 17.11.1995 15.1.1997


Logdatenstudie

Draft/RFC Aktuelle Version

Datum der ersten Version


(RFC 2074, obsoleted by RFC 2895, going to be obsoleted by RFC 3395)Draft-ietf-rmonmib-smon(RFC 2613)

6 22.7.1997 21.6.1999

Draft-ietf-rmonmib-sspm-mib(RFC 4149)

12 29.11.2001 5.8.2005

Draft-ietf-rmonmib-tpm-mib(RFC 4150)

14 17.5.2000 5.8.2005

Draft-ietf-rmonmib-trmib(RFC 1513)

- 20.9.1993 20.9.1993

Tabelle 49: Übersicht über Drafts/RFCs der Arbeitsgruppe RMONMIB

Nicht in der Tabelle aufgeführt sind sechs ausgelaufene Drafts.


RFC 3577 – Einleitung zur RMON-Familie der MIB-Module

Dieser RFC vom August 2003 (Autoren S. Waldbusser, AT&T et. al.) gibt einen Überblick über die aktuellen Arbeiten der IETF-Arbeitsgruppe, konkret den erreichten Stand bei den RMON-MIBs.

Nach einer Einleitung folgt im RFC eine Definition von RMON und eine Auflistung der Umsetzungsziele für RMON:

– Die RMON-Probe muss in der Lage sein, lokal ohne Verbindung zur Management-Station zu arbeiten.

– Über das RMON-Konstrukt soll ein aktueller oder gar proaktiver Informationsstand über die überwachten Geräte erreicht werden.

– Fehler sollen entdeckt und gemeldet werden.

– Es sollen Informationen über das überwachte Gerät hinaus ermittelt oder erschlossen werden können, beispielsweise im Netzwerksegment des Geräts.

– Mehrere Management-Stationen sind architektonisch zu berücksichtigen.

Der RFC gibt in der Folge einen Überblick über die von der Arbeitsgruppe zur Verfügung gestellten Dokumente, die MIBs spezifizieren. Möglichkeiten, diese MIBs zu klassifizieren, bestehen

1. in der Schicht, an der die MIB ihre Informationen sammelt, z. B. Data Link Layer sowie

2. in der Schicht, auf der eine Aggregation der gesammelten Informationen stattfindet, z. B. durch Ordnung nach der IP-Adresse, also auf dem Network Layer.

Das RFC nimmt eine Klassifizierung der MIBs anhand dieser Kriterien vor.

Folgende MIBs werden im Folgenden kurz beschrieben:

– RMON-1 (RFC 2819)

– Token-Ring-Erweiterungen der RMON-MIB (RFC 1513)


Logdatenstudie

– RMON-2MIB (RFC 2021)

– RMON-MIB-Protokollbezeichner („Protocol Identifiers“, RFC 2896)

– Switch-Erweiterungen der RMON-MIB (SMON MIB, RFC 2613)

– Erweiterungen der RMON-MIB für die Interface-Parameter-Überwachung (IFTOPN, RFC 3144)

– Erweiterungen der RMON-MIB für „Differentiated Services“ (DSMON MIB, RFC 2474)

– RMON für „High Capacity Networks“ (HCRMON MIB, RFC 3272)

– Die MIB für die Messung der Applikations-Performance (APM MIB, RFC 3729)

– Erweiterungen der Protokollbezeichner-Referenz für RMON-MIB (RFC 2896)

– Die MIB für die Messung der Transport-Performance (TPM MIB, RFC 4150)

– Künstliche Quellen für die MIB zur Performance-Messung (SSPM MIB, RFC 4149)

– Erweiterungen der RMON-MIB für „High Capacity Alarms“ (RFC 3434)

– MIB zur Echtzeit-Überwachung des Quality of Service von Applikationen (RAQMON, RFC 4711)

Der RFC beschreibt sodann das gemeinsam verwendete Rahmenwerk der RMON-Dokumente, welches aus diesen Komponenten besteht:

– Media Independent Table: die interessantesten, medienunabhängigen Statistiken sind hier gesammelt und werden vererbt an die medienspezifischen Umsetzungen. Diese Tabelle ist in RFC 3434 definiert.

– Protocol Directory: In RFC 2021 finden sich die Definitionen der innerhalb von RMON behandelbaren Protokoll-Enkapsulierungen. Mithilfe dieser können über RMON-Protokolle höheren Levels identifiziert werden.

– AppDirectory: In RFC 3729 werden die Begriffe zur Beschreibung von Applikationen festgelegt, die übergreifend weiterverwendet werden können.

– DataSource: die Definition der möglichen sog. „DataSources“

– Capabilities: In den diversen MIBs wird die Leistungsfähigkeit von Probes festgelegt und beschrieben, anhand derer ein Abruf dieser Fähigkeiten erst möglich wird.

– Control Tables: Sie dienen der Konfiguration der oft komplexen Datensammel-Prozesse. In RFC 2819 werden diese noch genauer spezifiziert.

Der RFC schließt mit einer Erklärung zum Zusammenspiel der SSPM MIB mit der APM und der TPM MIB. Im Wesentlichen ist das SSPM MIB für die Generierung von Test-Traffic verantwortlich, der von den beiden anderen MIBs zur Messung herangezogen werden kann, wenn kein nicht-künstlicher Traffic vorhanden ist oder dieser nicht ausreicht.

RFC 3729 – Die MIB zur Applikations-Performance-Messung

In diesem RFC aus dem März 2004 (Autor S. Waldbusser) wird die MIB zur Applikations-Performance-Messung APM MIB spezifiziert.

Wesentliche Größen aus Sicht eines Anwenders sind

– die Verfügbarkeit und


Logdatenstudie

– das Ansprechverhalten

der Netzwerk-Anwendung. Andere Aspekte wie die Verfügbarkeit des vermittelnden Netzwerkes erschließen sich nicht und sind insofern nicht direkt relevant. Mithilfe der APM MIB sollen diese Größen für eine Anwender-initiierte Transaktion gemessen werden können.

Eine Applikation wird als aus sog. Verben bestehend definiert. Solche Verben sind funktionale Bestandteile der Applikation, z. B. der POP3-Abruf von E-Mails als Teil einer POP3-Anwendung. Eine Transaktion beginnt mit dem Aufruf eines solchen Verbs und endet mit dem Ende der Antwort der Applikation auf die Service-Anfrage des Anwenders.

Der RFC spezifiziert drei generische Arten von Transaktionen und ihre jeweilige Messgröße für das Ansprechverhalten:

– Auf Transaktionen ausgerichtet: Entscheidend ist hier die das Antwortverhalten der Transaktion für den Benutzer (end-user response time)

– Auf Durchsatz ausgerichtet: Solche Transaktionen werden nach zur Verfügung stehender Bandbreite in Kilobit pro Sekunde gemessen.

– Auf konstanten Datenstrom ausgerichtet: Diese Transaktionen werden am Verhältnis von Zeit, in der der Anwendung nicht genügend Durchsatz zur Verfügung steht, zur Gesamtzeit der Transaktion bemessen, angegeben in ppm (Parts per Million).

Der RFC befasst sich anhand einiger Beispiele mit der Frage der Zusammenfassung von Messergebnissen in Berichten. Aufgrund der unterschiedlichen Natur der verschiedenen Transaktionen können solche nicht immer sinnvoll zusammengefasst werden. Der RFC spezifiziert die sinnvollen Aggregierungsmöglichkeiten (welche jeweils Berichten entsprechen) und verdeutlicht sie anhand von Beispielen.

Anhand eines Beispiels wird wiederum veranschaulicht, wie Tabellen auch aus anderen RMON-MIBs mit APM-Tabellen verknüpft werden und eine neue erweiterte, aber nach wie vor gemeinsame Beschreibung durch die MIBs erfolgt. Konkret wird die Listung ausgemessener Anwendungen (WWW, WWW Get, SAP/R3) und ihrer Werte in verschiedenen Tabellen (protocolDirectory, apmHttpFilterTable, apmAppDirapmReportTable) dargestellt.

Der RFC spezifiziert die Messmethodik als offen bzw. indifferent gegenüber der konkreten Umsetzung, solange eine mit dem RFC gemeinsame Semantik gewährleistet ist.

Es werden zwei Architekturen zur Umsetzung solcher Messungen skizziert:

– „Application Directory Caching“: Zur Identifikation der auszumessenden Applikation wird eine Kopie des Applikationsverzeichnisses auf jeden APM-Agenten vorgenommen.

– „Push Model“: Für die Messung von Applikationen auf Client-Rechnern (Desktops, Laptops) wird diese Herangehensweise empfohlen, um mit wechselnden IP-Adressen oder unregelmäßiger Nicht-Erreichbarkeit des Clients umgehen zu können. Die Agenten auf den Clients initiieren hierbei die Übertragung der Inhalte an den Manager.

Vor der detaillierten Spezifikation der APM MIB wird im RFC die gewählte Struktur vorgestellt und erklärt. Sie umfasst folgende Punkte:

– APM Application Directory Group: enthält Konfigurationsobjekte für die enthaltenen Applikationen; apmAppDirTable

– APM User Defined Applications Group: enthält Objekte, die in der protocolDirTable nicht enthalten sind; apmHttpFilterTable, apmUserDefinedAppTable


Logdatenstudie

– APM Report Group: enthält sich wiederholende Berichte; apmReportControlTable, apmReportTable

– APM Transaction Group: zeigt aktuelle und vor kurzem durchgeführte Transaktionen und ihr Ansprechverhalten; apmTransactionTable

– APM Exception Group: generiert Benachrichtigungen für Transaktionen, die Schwellwerte überschreiten; apmExceptionTable,

– APM Notification Group: enthält zwei Benachrichtigungen für die Exception Group

Nach der APM-MIB-Spezifikation werden die Sicherheitsimplikationen dieser MIB aufgelistet: Neben einigen Objekten, die mit Schreib-/Lese-/Änderungsrechten agieren, gelten die für SNMP allgemein geltenden Sicherheitsbedenken, vor allem für SNMP-Versionen vor SNMPv3. Alle gesammelten und übertragenen Daten können u. U. ausgelesen werden, und es befinden sich für einen Angreifer interessante Informationen darunter.

RFC 4502 – RMON-MIB Version 2

In diesem RFC aus dem Mai 2006 (Autor S. Waldbusser) wird die RMON-MIB in der Version 2 (RMON2-MIB) spezifiziert.

Die Struktur des MIB wird im RFC mit folgenden Gruppen angegeben:

– protocol directory

– protocol distribution

– address mapping

– network layer host

– network layer matrix

– application layer host

– application layer matrix

– user history

– probe configuration

Der RFC sieht für Implementierungen vor, dass diese Gruppen nur vollständig umgesetzt werden dürfen und dass auch die IF-MIB implementiert sein muss.

Es wird in der Folge darauf eingegangen, wie RMON2-MIB verwendet wird, wenn mehrere Management-Stationen zum Einsatz kommen und konkurrierenden Zugriff auf die in der Regel beschränkten Ressourcen auf Agenten-Ebene fordern.

Hierfür kommt das Konzept des „OwnerString“ zum Einsatz, der für jede aufgerufene Funktion einen Eigner vermerkt. Manuell oder auch automatisch kann nun basierend auf der im OwnerString hinterlegten Information entschieden werden, wie weiter zu verfahren ist. Der String soll nach RFC-Spezifikation bei langlebigen, z. B. Default-Funktionen, mit dem String „monitor“ beginnen. Der RFC gibt Empfehlungen bezüglich der Verwendung dieses Strings und zum Verhalten gegenüber auf diese Weise markierten Funktionen.

Es wird des Weiteren empfohlen, wie Agenten mit diesem MIB zu implementieren sind, wenn mehrere Management-Stationen konfigurierenden Zugriff fordern und es zu nicht realisierbaren bzw. miteinander in Konflikt stehenden Konfigurationsversuchen kommt.


Logdatenstudie

Nachdem einige Konventionen für den RFC und Nachbardokumente festgelegt wurden, spezifiziert der RFC die RMON2-MIB.

Das RFC schließt mit Überlegungen zur Sicherheit. Neben einigen Objekten, die mit Schreib-/ Lese-/Änderungsrechten agieren, gelten die für SNMP allgemein geltenden Sicherheitsbedenken, vor allem für SNMP-Versionen vor SNMPv3. Alle gesammelten und übertragenen Daten können u. U. ausgelesen werden. Dabei ist der Anreiz für Angreifer groß, denn es befinden sich interessante Informationen in diesen Logdaten – wird RMON (RFC 2819) verwendet, u. U. sogar Passwörter und Benutzernamen.

4.4 Zusammenfassung und Fazit

Die Standardisierungsbestrebungen der drei hier beschriebenen Arbeitsgruppen der IETF sind im Detail unterschiedlich zu bewerten. Vor allem die Arbeit der rmon-Gruppe, die ja auch als abgeschlossen angesehen wird, ist im wesentlichen komplett, insbesondere unter Berücksichtigung der vorliegenden aktuellen SNMP-Version, die zur Übertragung von Monitorinaten einen ausreichend hohen Sicherheitsstandard gewährleistet.

Den beiden anderen Gruppen gemeinsam ist jedoch, dass für die Weiterentwicklung der jeweiligen Übertragungsprotokolle die Vertraulichkeit der Daten offenbar keine vorrangige Rolle spielt und somit einem wesentlichen Sicherheitsaspekt gegenüber funktionalen Überlegungen, beispielsweise der Schnelligkeit der Datenübermittlung, nur eine untergeordnete Rolle zuteil wird:

– Für syslog ist eine standardisierte auf TCP basierende Form in Verbindung mit TLS-verschlüsselter Übertragung dringend erforderlich.

– Die letzten Überlegungen der IPFIX-Gruppe zur Auswahl eines Transportprotokolls lassen eine wünschenswert hohe Gewichtung des Wertes Vertraulichkeit vermissen.

Eine Unterlassung dieser Entwicklungen kann im schlimmsten Fall zu einer weiteren Zersplitterung führen, indem Hersteller mit proprietären Ansätzen versuchen, die bestehenden Sicherheitsdefizite abzufangen.

Interessant wäre in diesem Zusammenhang eine genauere Untersuchung der Eignung von SSL/TLS für die Übertragung von Log- und Monitorinaten.


Logdatenstudie

5 Übersicht über aktuelle Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten

Der folgende Abschnitt soll eine Übersicht über am Markt verfügbare Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten geben, die als Komponenten in einem IT-Frühwarnsystem eingesetzt werden könnten. Dabei werden sowohl kommerzielle als auch Open-Source-Produkte beschrieben.

Einleitend wird hierzu zunächst der Umfang dieses weitläufigen Themas näher eingegrenzt (Abschnitt 5.1). Anschließend (Abschnitt 5.2) werden wesentliche Begriffe und Eigenschaften produktunabhängig dargestellt, die im Bezug auf IT-Frühwarnsysteme wichtig sind. Dabei folgt die Beschreibung einer typischen Verarbeitungskette für Log-und Monitoringdaten. Anhand dieser Kette kann eine grobe Unterteilung der Lösungen in die Bereiche „Produkte mit allgemeiner Ausrichtung und für die IT-Frühwarnung zweckdienlichen Funktionen“ sowie „Spezialisierte Produkte für die IT-Frühwarnung“ vorgenommen werden. Zu diesem Zweck werden diese Produktkategorien zunächst genauer definiert, damit im Folgeabschnitt eine Zuordnung der dort detailliert vorgestellten Produkte zu diesen Kategorien vorgenommen werden kann. Abgesehen von dieser Kategorisierung wird jedes der Produkte auf Basis der Ergebnisse eines standardisierten Fragenkatalogs beschrieben.

5.1 Ausgangslage

IT-Frühwarnung ist ein Begriff, dessen Bedeutung sich im Wesentlichen zumindest grob selbst erschließt. Folglich bezeichnet er die rechtzeitige Warnung vor sicherheitsbedrohlichen Vorfällen oder Vorgängen in IT-Verbünden, noch bevor sich eine mögliche Auswirkung einstellt. Rechtzeitige Maßnahmen bestehen aus qualifizierten und zutreffenden Warnmeldungen in Verbindung mit Empfehlungen zu geeigneten Gegenmaßnahmen.

Im diesem und dem folgenden Kapitel wird die Ausgangslage beleuchtet. Außerdem werden zentrale Begriffe der IT-Frühwarnung genauer spezifiziert. Dabei wird mit der Darstellung das Ziel verfolgt, konkrete Produkte für diesen Bereich messbar zu machen und ihre wesentlichen Eigenschaften herauszustellen.

5.1.1 Ziele der IT-Frühwarnung

IT-Frühwarnsysteme haben zum Ziel, den IT-Sicherheitsverantwortlichen aufgrund belastbarer Erkenntnisse über drohende oder bereits eingetretene IT-Vorfälle, die noch möglichst begrenzt sind, einen Überblick über Ereignisse und Bedrohungen zu geben und diesen laufend fortzuschreiben. Sind die Erkenntnisse über Bedrohungen hinreichend konkret, so sollen die Informationen aus dem IT-Frühwarnsystem dazu beitragen, mit genügend Reaktionszeit zu erwartende Schäden zu vermeiden oder zu verringern. Zu diesem Zweck muss ein IT-Frühwarnsystem relevante Indizien und Anomalien erkennen und eine Bewertung auf der Basis der richtigen Klassifikation von Ereignissen ermöglichen.

Die Auswertung von Log- und Monitoringinformationen, wie sie im Rahmen des IT-Betriebs erzeugt werden, kann wesentliche Informationen liefern, um dieses Ziel zu erreichen.


Logdatenstudie

Aus der vorangehenden Definition des Begriffs eines IT-Frühwarnsystems ergeben sich die folgenden unmittelbaren Anforderungen, die im Weiteren beleuchtet werden:

– Fortlaufende Echtzeit-Analyse auflaufender Daten

– Gewinnung einer Übersicht über die aktuelle Bedrohungslage

– Vorzeitige bzw. frühzeitige Erkennung relevanter Ereignisse, insbesondere Bedrohungen

– Bewertungs- und Priorisierungsmöglichkeiten für ermittelte Ereignisse, möglichst automatisch umzusetzen

– Vermeidung von Fehlalarmen (False Positives)

Weitere Ziele wie etwa die Umsetzung einer effizienten Warnung vor aktuellen Bedrohungen oder die Auswertung anderer Quellen wie beispielsweise Meldungen über Sicherheitslücken in Programmen oder Sicherheitsvorfälle an anderen Stellen sind nicht Teil der vorliegenden Studie. Im folgenden wird daher oft der Begriff des „technischen IT-Frühwarnsystems“ verwendet, um deutlich zu machen, dass die Überwachung technischer Parameter und von Systemen automatisch generierter Meldungen nur ein Teil eines umfassenden IT-Frühwarnsystems ist.

Um das Ziel der IT-Frühwarnung zu erreichen, muss der Zustand des IT-Verbundes fortlaufend überwacht werden. Die folgenden Einzelaufgaben können dabei Bestandteile der Ermittlung des Lagebildes sein:

– Ermittlung zentraler Kenngrößen wie des normalen Netzwerkverkehrsaufkommens und der Verfügbarkeit von Systemen und Diensten

– Ermittlung des statistischen Verhaltens von Benutzern, z. B. Anmeldungen über die Tageszeit

– Feststellung von Abweichungen von der Norm

– Erkennung einzelner wichtiger Vorgänge innerhalb einer großen Menge an Vorgängen

– Möglichkeiten zur Modellierung des IT-Verbundes, um Eigenschaften wie Schwachstellen, Verfügbarkeits-Level, Wichtigkeit des Einzelsystems etc. zu hinterlegen

Daneben stehen andere Ziele der Auswertung von Log- und Monitoringdaten, die aber im Kontext der IT-Frühwarnung eher zweitrangig sind:

– Sammlung von Beweisen für die Nachbearbeitung von Sicherheitsvorfällen

– Einhaltung gesetzlicher Vorgaben, z. B. Forderungen zur Speicherdauer von Logdaten

– Nachweis eines geführten Risiko-Managements, insbesondere in der IT.

Die letztgenannten Aspekte sind in der folgenden Darstellung konsequent ausgeklammert. Nicht selten widersprechen sich diese Teilziele auch mit denen der IT-Frühwarnung. Beispielsweise führt die Forderung nach langfristiger Speicherung von Original-Logdaten dazu, dass große Datenmengen gespeichert werden, die sich aber nur schwer mit relationalen Datenbanken bewältigen lassen, die wiederum für eine Echtzeit-Analyse nützlich sein können. Dieses technische Dilemma kann oft nicht vollständig befriedigend gelöst werden.

Ein IT-Frühwarnsystem selbst steht ferner nicht außerhalb der Forderungen nach der Integrität, Verfügbarkeit und Vertraulichkeit von Daten:

– Gespeicherte und verarbeitete Daten müssen gesichert und ihre Integrität darf nicht gefährdet sein, finden doch auf ihrer Basis unter Umständen Analysen statt, deren Ergebnis die Basis für


Logdatenstudie

schwerwiegende Entscheidungen sein kann. Die Vollständigkeit der gesammelten Information ist unerlässlich für das Erkennen aller Angriffe und Vorfälle.

– Das Frühwarnsystem selbst muss verfügbar gehalten werden. Je besser es seine Rolle erfüllt, desto wichtiger wird seine Verfügbarkeit gerade in Krisensituationen, die wiederum zu erhöhten Anforderungen beispielsweise bezüglich der Performance (erhöhtes Datenaufkommen) führen kann.

– Da die Daten, die im Rahmen der Überwachung eines IT-Verbundes gespeichert werden, in vielen Fällen sehr weitgehende Informationen über die Struktur und den Betrieb des IT-Verbundes enthalten, kommt der Vertraulichkeit dieser Informationen eine große Bedeutung zu.

5.1.2 Auswahl relevanter Log- und Monitoringdaten und zu beobachtender Größen

Ein technisches IT-Frühwarnsystem ist angewiesen auf die Aussagekraft der ihm zur Verfügung gestellten Log- und Monitoringdaten. Im besten Fall kann es aus diesen sämtliche Aussagen extrahieren, sie qualifizieren und übersichtlich aufbereiten, so dass der Sicherheitsverantwortliche darauf adäquat reagieren kann. Ein technisches Frühwarnsystem wird aber nicht in der Lage sein, fehlende Informationen zu vervollständigen.

Andererseits bedeutet die Verarbeitung großer Datenmengen eine technische Herausforderung an die Performance des IT-Frühwarnsystems. Spitzenlasten müssen bei der Konzeptionierung eines solchen Systems zusätzlich berücksichtigt werden. Deshalb ist die Frage nach einer möglichst präzisen Auswahl der zu überwachenden Log- und Monitoringdaten unerlässlich für die Verfügbarkeit des Systems: Man kann nicht einfach sämtliche Daten unmittelbar zur Auswertung übergeben. Die Beschränkung auf wirklich gehaltvolle und relevante Log- und Monitoringdaten wird deshalb zu einem unerlässlichen Schritt in der Planung der IT-Frühwarnung.

Im Folgenden werden Log- und Monitoringdaten grundlegend bezüglich ihrer Natur unterteilt.

Ereignisbezogene DatenEreignisbezogene Daten werden vom loggenden System bzw. Anwendung definitionsgemäß genau dann erzeugt, wenn ein Ereignis beschrieben werden soll. Andere Bezeichnungen sind Logdaten, Logmeldung oder einfach nur Meldung. Beispiele hierfür sind

– die Anmeldung eines Benutzers am System,

– das Passieren der Firewall durch eine Netzwerk-Verbindung gemäß Firewall-Regelwerk,

– der Zugriff auf eine auf einem Webserver gelagerte Seite oder

– die Verletzung von Zugriffsrechten innerhalb einer Anwendung.

Ereignisbezogene Logdaten haben für die IT-Frühwarnung in der Regel einen relativ hohen Wert, da sie oft unmittelbar sicherheitsrelevante Vorfälle betreffen. Problematisch sind in diesem Zusammenhang jedoch folgende Aspekte:

– „Man sieht den Wald vor lauter Bäumen nicht“: Nicht alle Logmeldungen haben einen Sicherheitsbezug. Viele Meldungen werden routinemäßig erstellt und lenken von den wirklich wichtigen Meldungen ab. Die schiere Menge der anfallenden Daten führt selbst in kleinen IT-Verbünden zur Notwendigkeit einer maschinengestützten Auswertung.


Logdatenstudie

– Uneinheitliche Formate bei Log- und Monitoringdaten: In den vorhergehenden Abschnitten wurde dargelegt, dass Log- und Monitoringdaten in sehr vielen unterschiedlichen und oft nicht genau spezifizierten Formaten anfallen. Dieser Umstand steht einer umfassenden maschinellen Auswertung (Parsing) oft im Wege.

Monitoringdaten, statistische DatenAnders als Logdaten werden Monitoringdaten fortlaufend erhoben. Ihre Abfrage beispielsweise über SNMP entsteht aus dem Wunsch heraus, die Verfügbarkeit von Systemen zu überwachen, System- und Netzwerkressourcen zu messen und diese Größen übersichtlich darzustellen, um auf Engpässe reagieren zu können. Sie sind nicht ereignisbezogen und stellen keine Ursache-Wirkungskette her, sondern ermitteln nur punktuelle Aussagen.

Problematisch sind in diesem Zusammenhang folgende Aspekte:

– Mangels Ursachenermittlung wird eine Interaktion zwischen Systemkomponenten nicht sichtbar. Beispielsweise führt der Ausfall des Netzwerks automatisch auch zum Ausfall des dort angeschlossenen Servers und aller dort vorgehaltenen Dienste.

– Systeme zur Sammlung, Auswertung und Darstellung von Monitoringdaten beschränken sich in der Regel auf den Aspekt der Verfügbarkeit von Systemen. Da die Grundwerte Integrität und Vertraulichkeit sowie jegliche Ursachen ausgeblendet werden, gibt es keinen einfachen Weg heraus aus dieser eingeschränkten Perspektive.

Diese Aspekte werden durch das folgende Beispiel illustriert: Der Schutz des Grundwertes der Verfügbarkeit wird einerseits von lokalen Problemen gefährdet (beispielsweise volllaufende Festplattenpartitionen), andererseits aber auch von Bedrohungen wie gezielten Hacker-Angriffen oder einem neuen, im Internet grassierenden Wurm. Aus Sicht der klassischen Monitoring-Systeme führen alle Vorfälle zu identischen Auswirkungen, nämlich zur Nichterreichbarkeit eines Servers. Nur letztere Information wird von den klassischen Monitoring-Systemen registriert und gemeldet.

Flow-Daten/FlussdatenFlow-Daten, wie sie beispielsweise über Cisco NetFlow oder mit IPFIX ermittelt werden können, geben Auskunft über die im Netzwerk verwendeten Protokolle und – mit gewissen Einschränkungen – auch über die dahinter liegenden Anwendungen. Wie andere Monitoringdaten sind auch Flow-Daten nicht ereignisbasiert, sondern werden fortwährend erhoben. In diesem Dokument werden Flow-Daten daher nicht gesondert betrachtet, sondern als Teil von Monitoringdaten, mit denen sie wesentliche Eigenschaften teilen.

In den konkreten Umsetzungen von Flow-Implementationen ist eine Teilauswertung von Rohdaten bereits vorgesehen, indem beispielsweise ein Router per NetFlow bereits eine Top-Ten-Liste von IP-Adressen („Top-Talker“) vermeldet, ohne die Rohdaten vollständig aufzubewahren oder weiterzuversenden.

Flow-Daten weisen im Zusammenhang mit der IT-Frühwarnung folgende problematische Eigenschaften auf:

– Es fallen typischerweise sehr große Datenmengen an. Der Umfang kann den von Log- und Monitoringdaten noch deutlich übertreffen.


Logdatenstudie

– Ähnlich wie bei Monitoringdaten fällt die Herstellung einer Ursachenkette zwischen dem Urheber und der Auswirkung einer Störung schwer. Flow-Daten sind für die Frühwarnung in erster Linie unterstützend zu sehen und entfalten alleine nicht genügend Aussagekraft.

Wie Monitoringdaten sind auch Flow-Daten in erster Linie dazu geeignet, einen „normalen Betriebszustand“ greifbar und messbar zu machen und Abweichungen davon zu erkennen.

Sniffer-DatenSog. Netzwerk-Sniffer sind konzipiert für die Analyse von Netzwerkverkehr, indem sie die Daten innerhalb eines Netzwerksegments vollständig aufzeichnen und für eine Analyse zur Verfügung stellen. Sie stellen ein wertvolles Werkzeug zur Fehlersuche dar.

Ihre Daten sprengen jedoch alle realisierbaren Kapazitäten bei technischen IT-Frühwarnsystemen. Deshalb werden sie im Folgenden nicht weiter betrachtet.

Wichtige GrößenAus der geschilderten Natur von Log- und Monitoringdaten wird insgesamt ersichtlich, dass eine starke Vorauswahl der Daten nicht nur hilfreich, sondern unerlässlich ist. Folgende Kennlinien und -größen sind für die IT-Frühwarnung jedenfalls interessant und sollten über die gesammelten Logmeldungen und Monitoringdaten greifbar und messbar werden:

– An- und Abmeldungen von Benutzern an Systemen und Applikationen

– Zugriffsrechte-Verletzungen bzw. solche Versuche

– Meldungen über aktuelle Netzwerkverbindungen, gegebenenfalls mit Quell- und Ziel-IP-Adresse, inkl. Adressübersetzungszuordnungen

– Meldungen spezialisierter Sicherheitssysteme wie Intrusion Detection oder Virenschutz

– Meldungen wichtiger Applikationen wie E-Mail oder eines zentralen Benutzerverzeichnisses

– Aktuelle Verfügbarkeit wichtiger Kernsysteme und Applikationen

– Aktuelle Schwachstellen der über das Netzwerk erreichbaren Systeme

– Nach Zeitpunkten (Tageszeit, Wochentag) aufgeschlüsseltes , statistisches Normalverhalten des Netzwerks sowie von Systemen und Benutzern

5.1.3 Grundlegende technische Rahmenbedingungen eines Projektes zur Umsetzung der IT-Frühwarnung

Für die Einführung eines zentralen IT-Frühwarnsystems, sei es lokal oder auf größerer Ebene angesetzt, gibt es eine Reihe meist technischer Anforderungen, die als notwendig voraus zu setzen sind, damit die Ziele überhaupt in greifbarer Nähe bleiben. Diese sind im Folgenden aufgelistet, jedoch ohne Anspruch auf Vollständigkeit:

– Zeitstempel: Für eine zeitliche Korrelation und damit verspätet eintreffende Meldungen nachträglich korrekt eingeordnet werden können, ist die Verfügbarkeit einer einheitlichen und genauen Referenzzeitquelle, z. B. in Form eines NTP-Servers unerlässlich. Die technischen Systeme müssen zudem in der Lage sein, mit unterschiedlichen Zeitstempel-Formaten und Zeitzonen umzugehen.


Logdatenstudie

– Für die zentral zu sammelnden Log- und Monitoringdaten muss genügend Netzwerkbandbreite zur Verfügung stehen. Für die Übertragung ist die Einrichtung bzw. Nutzung eines eigenen Out-of-Band-Netzwerks empfehlenswert.

– Die Namensauflösung wird typischerweise auch vom IT-Frühwarnsystem stark verwendet, z. B. um die Ziele eines Portscans zu ermitteln. Sie muss leistungsfähig genug sein, um alle wichtigen Rechner (vor allem interne, aber auch externe) rückwärts auflösen zu können und zwar von der Position des IT-Frühwarnsystems aus.

– Um eine zentrale Speicherung von Logdaten und ihre Fälschungssicherheit zu erreichen, wird ein Anschluss der Daten generierenden Geräte an das zentrale Frühwarnsystem notwendig. Der Transfer der Daten sollte möglichst in Echtzeit erfolgen, um eine zeitnahe Auswertung und eine Korrelation mit den Meldungen anderer Geräte zu ermöglichen. Die Verschiedenheit der Geräte und die bereits beschriebene, oft unzureichende Sicherheit der Übertragungswege stellen eine Herausforderung dar, die oft nur durch zusätzliche Maßnahmen wie VPN oder ein Out-of-Band-Management zu erreichen ist.

– Um Anforderungen des Datenschutzes erfüllen zu können, muss der Aspekt der Speicherung personenbeziehbarer Daten mit allen zu beteiligenden Gremien abgestimmt werden. Oft werden Anonymisierungs- oder Pseudonymisierungsfunktionen notwendig sein, um eine technische Umsetzung zu ermöglichen, ohne dass wichtige technische Informationen verloren gehen.

5.1.4 Gängige Begriffsdefinitionen

Zur Einordnung der in dieser Studie vorgenommenen Untersuchung wird im Folgenden ein Vergleich zwischen in der Industrie üblichen Begriffen und dem hier vorrangig betrachteten Begriff der IT-Frühwarnung durchgeführt.

5.1.4.1 Security Operations Center (SOC)

Ein SOC ist das auf IT-Sicherheit spezialisierte Pendant zu einem Network oder System Operations Center. Eine solche spezialisierte Einrichtung lohnt sich erst bei großen IT-Verbünden, wo sie sich an bestehende Betriebsprozesse (z. B. nach IT Infrastructure Library, ITIL) anschließen muss. Ein SOC benötigt eigene Werkzeuge für die Überwachung und Recherche.

5.1.4.2 Security Information Management (SIM)

Unter einem SIM versteht man die Implementierung eines in der Regel auf Werkzeuge gestützten Prozesses zur Zentralisierung, Speicherung und Aufbewahrung von Logdaten, teilweise auch von Monitoringdaten. Wichtige Aspekte sind beim SIM die Erfüllung gesetzlicher Vorgaben zur Speicherung von Logdaten, die Sicherstellung von IT-Beweismaterial und die Unterstützung eines Risiko-Managements in der IT. Systeme, die primär als SIM-Systeme konzipiert sind, fokussieren sich meist auf die Speicherung von großen und sehr schnell wachsenden Datenmengen. Ihre fortlaufende Verarbeitung zum Zwecke der Frühwarnung ist nicht das primäre Ziel des SIM. Insofern sind reine SIM-Systeme nicht besonders gut geeignet für die IT-Frühwarnung.


Logdatenstudie

5.1.4.3 Security Event Management, auch Security Event Monitoring (SEM)

SEM-Systeme sind meist als Echtzeitsysteme und -werkzeuge für Security Operations Centers konzipiert. Sie verarbeiten Log- aber auch Monitoringdaten fortwährend und in Echtzeit und unterstützen eine Vielzahl von Schnittstellen zu Geräten und Prozesswerkzeugen, die Logdaten generieren. Sie entsprechen in ihrer Eigenschaft als Werkzeug am ehesten der Umsetzung eines IT-Frühwarnsystems. Wie im Folgenden noch aufgezeigt wird, werden Verfügbarkeitsfragen von diesen Systemen aber oft nicht zufriedenstellend abgebildet.

5.1.4.4 Computer-Forensik

Im schon seit langem bekannten Bereich der Computer-Forensik geht es um die nachgelagerte Analyse eines IT-Vorfalls, um die Sicherung von Beweisen und die Ermittlung von Sachverhalten in juristischen Fragestellungen wie Schuld und Urheberschaft. Forensik und Frühwarnung ergänzen sich in vielerlei Hinsicht, ohne große Überschneidungen zu haben - vor allem nicht in technischer Hinsicht. Gemeinsames Ziel ist jedoch die Ermittlung möglichst verlässlicher Erkenntnisse.

5.2 Darstellung und Diskussion der Verarbeitungskette von Log- und Monitoringdaten zum Zweck der IT-Frühwarnung

Im folgenden Abschnitt werden einige für ein leistungsfähiges technisches IT-Frühwarnsystem erforderliche Funktionalitäten erläutert. Weiterhin werden wichtige und gängige Begriffe aus dem Bereich der IT-Frühwarnsysteme eingeführt.

Neben Kapiteln zu Beweggründen, die typische Lösungsfunktionen notwendig machen, sollen technische Aspekte, die bei Planung und Auswahl von IT-Frühwarnsystemen eine Rolle spielen, vermittelt werden.

5.2.1 Notwendige Zentralisierung von Log- und Monitoringdaten

In IT-Verbünden finden sich verschiedenste Klassen von Hard- und Software-Kompontenten, die interessante Log- und Monitoringdaten liefern, beispielsweise folgende:

– Aktive Netzwerkkomponenten (Router, Switches etc.)

– Betriebssysteme (Windows, Linux, Unix etc.)

– Applikationen und Dienste (Web-, File-, Name-, Mail-, Anmelde-Server etc.)

– Sicherheitskomponenten im Netzwerk (Firewalls, Proxy-Systeme, Schwachstellen-Scanner, IDS/IPS, Virusgateways, Überwachungssysteme zur Sicherstellung der Verfügbarkeit etc.)

– Sicherheitskomponenten auf Hosts (Firewalls, Viren-Scanner, Host-IDS etc.)

– Physikalische Zutrittssysteme

Diese erzeugen während des täglichen Betriebs fortlaufend große Mengen dieser Daten. Die vorzufindenden Datenmengen lassen sich durch ihre schiere Größe nicht mehr manuell analysieren.

Oft lassen sich viele Angriffe auf den IT-Verbund andererseits erst durch eine Verknüpfung von Informationen unterschiedlicher Datenquellen aufdecken. Die Verknüpfung der Informationen aus un


Logdatenstudie

terschiedlichen Datenquellen kann jedoch nur an einer zentralen Stelle, wo die Informationen zusammenlaufen, vorgenommen werden.

Durch solche eine Informationsverdichtung besteht die Hoffnung, auch auf fortgeschrittene, subtile Angriffstechniken und Angriffe aus dem Kreis interner IT-Benutzer reagieren zu können.

Einen zweiten wichtigen Beweggrund für den Aufbau zentraler IT-Frühwarnsystemen stellen die aktuell wachsenden Anforderungen an Unternehmen dar, ein Risiko- und Konformitätsmanagement (engl. Compliance Management) einzuführen. Für Aktiengesellschaften, die an US-amerikanischen Börsen notiert sind, oder Unternehmen im Kreditkartenumfeld wird dies oft zwingend erforderlich (Sarbanes-Oxley-Act SOX; Payment Card Industry PCI) sein.

Hierbei ist ein notwendiger Schritt, die zentrale Perspektive von IT-Management und IT-Sicherheitsbeauftragten durch eine zentrale technische Schnittstelle zu fördern und zu unterstützen: Der aktuelle Status der IT-Sicherheit muss zentral kontrolliert werden können.

Zusammenfassend können folgende Gründe für den Aufbau eines zentralen IT-Frühwarnsystems festhalten werden:

– Unzureichende Erkenntnis-Möglichkeiten bei Betrachtung nur einzelner Datenquellen

– Ziel der Abwehr fortgeschrittener Angriffstechniken, die über mehrere Systeme laufen

– Möglichkeit der Entdeckung von Tätern innerhalb des IT-Verbunds

– Risiko-Management in der IT, Zertifizierungen und Konformitätsnachweis zu Compliance-Standards (BSI, ISO, PCI)

Damit ein IT-Frühwarnsystem leistungsfähig in der Entdeckung von sicherheitsrelevanten Ereignissen betrieben werden kann, ist die zentrale Zusammenführung von Log- und Monitoringdaten also zwingend erforderlich.

5.2.2 Unterstützung von Formaten und Protokollen

Um die vielfältigen Datenquellen heterogener Netzwerke in ein technisches IT-Frühwarnsystem einbinden zu können, muss dieses eine möglichst hohe Anzahl an Formaten und Protokollen zur Übertragung unterstützen. Die Vielfaltvor allem der bestehenden Formate wird anhand der Beispiele im ersten Abschnitt dieser Studie sehr deutlich.

Es existiert kein einheitliches Format für die Speicherung von Log- und Monitoringdaten. Für bestimmte Anwendungsbereiche haben sich zwar Formate als De-facto-Standards etabliert, allerdings werden diese nicht komplett durchgängig genutzt. So hat nahezu jedes Unix-artige Betriebssystem Syslog integriert, jedoch sind seine Format-Spezifikationen nicht genau genug. Viele Anwendungen verwenden im Bereich von Unix/Linux spezielle Formate für das Schreiben von Logdaten (z. B. Squid, Sendmail etc.). Zudem verändern die Entwickler von Datenquellen von Zeit zu Zeit das Logformat (z. B. Windows 2003 zu Vista).

Für die Anbieter von Produkten zur Auswertung von Log- und Monitoringdaten stellt die Anpassung an neue oder weiterentwickelte Logformate durch entsprechende Parser einen immensen Aufwand dar.

Ein wenig einfacher stellt sich die Situation bei der Unterstützung der jeweiligen Protokolle zur Übertragung von Log- und Monitoringdaten dar. Die benötigten Protokoll-Spezifikationen sind meist offen gelegt und die Protokolle verändern sich nicht so häufig wie die Datenformate. Zusätz


Logdatenstudie

lich ist bei Protokollen aber der Schutz der Vertraulichkeit und Integrität der übertragenen Informationen zu berücksichtigen. Je nach Schutzbedarf kann der Einsatz eines verbindungsorientierten, authentifizierten und verschlüsselten Protokolls erforderlich werden, welches aber nicht immer zur Verfügung steht.

Bei Protokollen ist die Schnittstellen-Thematik für IT-Frühwarnprodukte somit wesentlicher einfacher. Sie bieten zudem teilweise an, durch eigene, sichere Übertragungsprotokolle bestehende Schwächen abzufangen.

5.2.3 Normalisierung und Aggregation

Innerhalb der heterogenen Landschaft der Logdaten liefernden Geräte besteht wie festgestellt kein einheitlicher Standard für Format und Übertragungsprotokoll. Für die Datenverarbeitung und insbesondere für Aussagenverknüpfung über unterschiedliche und unabhängig betriebene Geräte eines IT-Verbundes ist es ein entscheidender Schritt, die gesammelten Meldungen in ein einheitliches Format zu überführen.

Definition „Normalisierung“Unter einer Normalisierung versteht man den Prozess der Überführung gesammelter Logmeldungen in ein innerhalb des IT-Frühwarnsystems standardisiertes Datenformat, um die einheitliche Speicherung und übergreifende Weiterverarbeitung der Meldungen verschiedener Geräte vorzubereiten.

Der Einsatz einer Normalisierung ist aus folgenden Gründen naheliegend:

– Selbst Hersteller einer Geräteklasse belegen Datenfeld-Werte mit derselben Bedeutung unterschiedlich. So kann eine durch eine Firewall verbotene Kommunikationsverbindung bei dem einen Hersteller als „Block“ und dem anderen als „Deny“ dargestellt werden.

– Andere Datenfelder sind bei Meldungen unterschiedlicher Geräteklassen (beispielsweise Firewall, Antivirus, IPS etc.) immer wieder vorzufinden und müssen bei der Korrelation eines Frühwarnsystems standardisiert verarbeitet werden. Dies sind üblicherweise Felder wie Zeitstempel, Quell- und Ziel-IP-Adressen, FQDN's, etc.

Zum momentanen Zeitpunkt hat sich kein einheitlicher Standard für die Normalisierung in IT-Frühwarnsystemen herausgebildet, Normalisierung an sich ist eine proprietäre Angelegenheit.

Die technische Schwierigkeit bei der Normalisierung ist die Zuordnung der vom Applikationshersteller geschriebenen Informationen in die jeweiligen Datenfelder des normalisierten Formats. Die Hersteller von IT-Frühwarnsystemen müssen für diesen Vorgang jede Meldung des Geräts und ihren Aufbau im Detail kennen, um diese Zuordnung zutreffend vornehmen zu können. Bei diesem im Englischen als Parsing bezeichneten Vorgang werden die Datenfelder meist mit Hilfe von Regulären Ausdrücken einer Syntaxanalyse unterzogen. Da die Hersteller logliefernder Geräte bei der Einführung neuer Produkt-Versionen mitunter auch das Logging verändern, müssen die IT-Frühwarnsystem-Anbieter den Markt permanent beobachten, ihre Parser entsprechend aktuell halten und immer wieder anpassen. Ein finaler Stand wird erst durch die Einstellung des unterstützten Produkts erlangt.

Aus Gründen der Lastverteilung sollte das Performance-aufwändige Parsing in verteilten Architekturen auf den in Datenquellen-Nähe installierten Logsammlern (engl. Event Collector) stattfinden. Zentrale Komponenten des IT-Frühwarnsystem werden dadurch entlastet.


Logdatenstudie

Um die Meldungen für die anschließende Korrelation vorzubereiten, ist es nicht unbedingt erforderlich, alle Informationen einer Logmeldung zu normalisieren. Entsprechend unterteilt sich das Lager der Hersteller von IT-Frühwarnsystemen in diesem Punkt in zwei Gruppen mit unterschiedlicher Herangehensweise:

Die eine Gruppe verwendet eine „Basisnormalisierung“. Bei dieser werden für die Korrelation elementaren und einfach zu parsenden Informationen normalisiert, während unwichtige oder schwierig zu normalisierende Informationen einer Meldung nicht ins Normal-Format übernommen werden. Erstere sind meist Informationen über

– Quell-IP-Adressen

– Ports und

– durchgeführte Aktionen (Block, Accept etc.).

Beispiel einer Basisnormalisierung ist das Parsing des Standard-syslog-Headers ohne den Message-Teil.

Eine solche Basisnormalisierung beschränkt sich definitionsgemäß auf relativ wenige normalisierte Datenfelder, was zu einer eingeschränkten Korrelationsfähigkeit führt. Sollen nicht normalisierte Informationen verarbeitet werden, so muss die Korrelationsregel den präzisen „Wortlaut“ treffen. Dies führt zu einer höheren Anzahl zu pflegender Korrelationsregeln und einer erhöhten Wahrscheinlichkeit von nicht auslösenden Regeln („False Negatives“).

Der zweite Ansatz, die Übernahme möglichst aller Informationen in die Datenfelder der normalisierten Meldung, ist einer Basisnormalisierung deshalb prinzipiell vorzuziehen. Korrelationsregeln lassen sich hier herstellerunabhängig definieren und pflegen, da der genaue Wortlaut einer Meldung nicht länger entscheidend ist. Die Regeln werden zudem einfacher, weil generischer, und damit verständlicher. Eine einzelne Regel, beispielsweise für die Entdeckung eines Portscans, trifft sowohl bei entsprechenden Meldungen einer VPN-1- wie einer PIX-Firewall zu.

Definition „Aggregation“ Unter Aggregation wird die Zusammenfassung von als hinreichend ähnlich erachteten Logmeldungen mit redundantem Informationsgehalt zu einem aggregierten, d. h. zusammengefassten Datensatz verstanden.

Nicht bei allen Frühwarnsystemen sind die übereinstimmenden Datenfelder konfigurierbar. Es existieren vielmehr Umsetzungen von Aggregation, bei denen abgesehen vom Zeitstempel alle Datenfelder eines Datensatzes exakt den gleichen Inhalt aufweisen müssen. Unabhängig davon müssen Übereinstimmungen innerhalb eines relativ kurzen, idealerweise konfigurierbaren Zeitfensters (einige Sekunden bis maximal Minuten) gefunden werden.

5.2.4 Filterung und Auswahl von Informationen: Fokus auf IT-Sicherheit, Zweckbindung, Aussondern von „Datenmüll“

Neben Normalisierung und Aggregation verfügen IT-Frühwarnsysteme in der Regel. über eine weitere charakteristische Funktion: Datenfilter.

Durch Filterung können für den geplanten Einsatzzweck irrelevante Daten möglichst frühzeitig, z. B. am Logsammler, ausgesondert und somit vom weiteren Verarbeitungsprozess ausgeschlossen werden. Dies schont System-Resourcen.


Logdatenstudie

Die Komponente des Logsammlers empfängt oder ruft die originalen Logmeldungen vom erzeugenden System ab und zwar in originaler Form. Da die Log-Level vieler Daten erzeugender Systeme meist nicht besonders granular konfiguriert werden können, müssen IT-Frühwarnsysteme in der Lage sein, in erster Instanz erstmal alle Meldungen anzunehmen.

Jeder zu verarbeitende Logdatensatz erzeugt sodann Kosten – in Form von Rechenleistung und Speicherkapazität in der Datenbank. Weitere Kosten entstehen durch Bandbreitenbelegung in den übertragenden Netzwerken. Es ist insofern nahe liegend, die Ausfilterung nicht benötigter Informationen möglichst nahe am Ort der Entstehung der Logmeldungen, also direkt nachdem die Daten vom Frühwarnsystem entgegengenommen worden sind, durchzuführen.

Um zu vermeiden, dass auch relevante Informationen ausgesondert werden, sollte bereits im Vorfeld der Zweck des IT-Frühwarnsystems festgelegt worden werden. Oft erst anhand der davon abzuleitenden Ziele kann die konkrete Relevanz einzelner auftretender Meldungen beurteilt werden. Typischerweise ergeben sich durch Ziele wie Compliance und Forensik abseits der unmittelbaren IT-Frühwarnung Anforderungen zur Speicherung und Vorhaltung von Logmeldungen, die in der Frühwarnung nicht benötigt werden. Änderungen der vorgenommenen Ausrichtung sollten durch eine einfache Anpassung der im System konfigurierten Filter ermöglicht werden.

Eine geschickte Implementierung der Filterfunktion erlaubt darüber hinaus, wiederholt verwendbare Filter einem breiteren Benutzerkreis zur Verfügung zu stellen. Filter sollten dementsprechend gespeichert und mit aussagekräftigen Namen versehen werden können.

Die Eigenschaften von Filtern zielen zum Mustervergleich auf die möglichen Eigenheiten von normalisierten oder Original-Meldungen ab:

– Vorkommnisse bestimmter Wörter, Zahlen oder IP-Adressen

– Vorkommen innerhalb eines Zeitfensters

– Datenquelle und -eigenschaften

– weitere

PerformanceSchon bei mittelgroßen IT-Verbünden ist regelmäßig eine Größenordnung von 1.000 zu verarbeitenden Ereignissen pro Sekunde (Events per Second) und mehr keine Seltenheit.

Wie bereits verdeutlicht machen diese Datenmengen an zahlreichen Stellen Kapazitäten nötig:

– auf zentraler Seite des IT-Frühwarnsystems für die Verarbeitung der Daten (Schreib- und Lese-Zugriffe auf die Datenbank, Korrelation der Meldungen, Benutzerinteraktion etc.)

– gegebenenfalls dezentral an der Stelle der Logsammler bei Tätigkeiten wie Einlesen der ungefilterten Daten, Datennormalisierung und -aggregation.

Auf die Balance zwischen der Optimierung der Leistung und der Gefahr des Verlustes relevanter Daten durch Filterung und Aggregation ist zu achten. Je umfassender die beiden Techniken zum Einsatz kommen, desto höher ist die Gefahr, wichtige Datensätze oder -felder für das IT-Frühwarnsystem zu verlieren.

Zwar werden die Teilsysteme auf eine zu erwartende mittlere Auslastung ausgelegt werden, Spitzenlasten treten im Tagesverlauf aber regelmäßig auf, so dass genügend Reserve-Kapazitäten eingeplant werden müssen.


Logdatenstudie

Die Hardware-Parameter, über die die relevanten Performance-Werte beeinflusst werden können, sind:

– Prozessor-Zahl und -Leistung

– Arbeitsspeicher

– Festplatten-Geschwindigkeit und RAID-Level bzw. SAN-Konfiguration

Eine zusätzliche Belastung der IT-Frühwarnungs-Server durch zusätzliche Aufgaben ist aus offensichtlichen Gründen zu vermeiden.

5.2.5 Schnittstellen: Import, Export und die Unterstützung bestehender Prozesswerkzeuge

Um die Akzeptanz eines technischen IT-Frühwarnsystems zu steigern, sollte es in bereits bestehende Prozesse (z. B. Change-Management oder Incident Management) und ihre technische Umsetzung über entsprechende Tools (z. B. Ticket-System) eingebunden werden, statt neue, zusätzliche Prozesse und Abläufe zu schaffen.

Schnittstellen zu CMDB und Asset-DatanbankDes weiteren muss dem System mit der Implementierung ein Bild des überwachten IT-Verbundes (Netzwerk, PC, Server) mitgegeben werden, was allgemein unter dem Begriff „Modellierung“ zusammengefasst ist: Je genauer die vorliegenden Informationen Systeme und ihre Wertigkeiten und Schwachstellen eingepflegt sind, desto präziser können Korrelationsergebnisse in ihrer Relevanz eingestuft, d. h. priorisiert werden.

Um die benötigten Informationen nicht mühsam manuell einpflegen zu müssen, unterstützen Systeme zur Auswertung von Log- und Monitoringdaten in der Regel Schnittstellen zum Import solcher Systeminformationen. Die in Unternehmen häufig bereits existierenden Datenbanken zur Dokumentation von Systemdaten wie Hostname, IP-Adresse, Betriebssystem oder System-Ansprechpartnern können in diesem Zusammenhang genutzt werden, so dass sich der Arbeitsaufwand minimiert. In Unternehmen, die nach dem Standard ITIL arbeiten, können die Informationen einer Configuration Management Database (CMDB) entnommen werden.

Typischerweise erfolgt der Import solcher Systemdaten über eines der folgenden Formate:

– XML

– Formate mit Delimiter (z. B. CSV)

Schnittstellen zu Ticket-SystemenEntdeckt das IT-Frühwarnsystem einen sicherheitsrelevanten Vorfall, so folgen in der Regel Analysen und Recherchen zur Verifizierung und Ermittlung etwaiger Auswirkungen. In der Regel ist dazu nicht nur generell menschlicher Eingriff notwendig, sondern die Fachkenntnis ganz bestimmter Analysten und System-Administratoren sukzessive hinzuzuziehen. Findet eine solche verteilte Bearbeitung eines Vorfalls statt, wird die Verfolgung des Bearbeitungsstatus in einem Incident-Management-Prozess, zumeist über ein Ticket-System, nowendig.

Einige Anbieter von Systemen zur Auswertung von Log- und Monitoringdaten haben ein solches Ticket-System in ihre Lösungen integriert. IT-Frühwarnsysteme sollten aber zusätzlich über


Logdatenstudie

Schnittstellen zu den marktüblichen Ticketing-System-Produkten verfügen. Solche basieren beispielsweise auf SNMP oder produktspezifischen, offen gelegten Schnittstellen.

Einige Produkte erlauben sogar die bidirektionale Kommunikation mit dem externen Ticket-System.

5.2.6 Lesender Zugriff auf die Log- und Monitoringdaten

Um die fortlaufende Flut einlaufender Meldungen zu verarbeiten, müssen Systeme zur Auswertung von Log- und Monitoringdaten zunächst viele kleine Datensätze abspeichern, ohne dass dabei ein Rückstau entsteht. Diese Situation wird durch gleichzeitige lesende Zugriffe, die zur Analyse der gespeicherten Daten stattfinden, verschärft. Um dieser Herausforderung zu begegnen, kommen folgende zwei, sehr unterschiedliche Ansätze zum Einsatz:

Speicherung in einer relationalen DatenbankDie Speicherung der gesammelten Daten in einer relationalen Datenbank wird in der Regel durch Komponenten realisiert, die die Log- und Monitoringdaten normalisieren. Die Methode bietet zunächst die Möglichkeit der vollständigen oder teilweisen Indizierung der Tabellen-Datenfelder. Eine Suche nach Datenfeld-Inhalten kann damit wesentlich schneller durchgeführt werden als ohne eine Indizierung. Dieses Vorgehen ist überlegen, wenn die Analyse gesammelter Ereignisse im Vordergrund steht und dazu verschiedenste Informationen aus der Datenbank regelmäßig wieder ausgelesen werden müssen.

Beispiel: Das Frühwarnsystem meldet einen Portscan auf den autoritativen DNS-Server einer Organisation. Um zu ermitteln, ob es sich dabei um eine vorbereitende Maßnahme für weitere Angriffe gehandelt haben könnte, lässt sich der Analyst alle zeitlich späteren Ereignisse anzeigen, in denen die IP-Adresse des Server Ziel von Kommunikationsanfragen war. Dazu führt das Datenbanksystem in der Spalte mit den Ziel-IP-Adressen eine Suche nach allen Vorkommnissen der Adresse im fraglichen Zeitraum durch.

Wächst der gesammelte Datenbestand über die Zeit stetig an, so verlangsamt sich der Zugriff auf die Datenbank, wenn der Index unbeschränkt wächst. Dies geschieht, wenn der Suchbegriffsraum nicht beschränkt ist oder unpraktisch groß wird. In der Konsequenz kann dann nur die Datenbasis eines begrenzten Zeitraums aktiv im System gehalten werden. Insbesondere aus diesem Grund können meist auch nicht sämtliche Datenfelder indiziert werden, man beschränkt sich auf die wesentlichen.

Speicherung im Dateisystem des BetriebssystemsDer zweite, grundlegend verschiedene Ansatz besteht darin, die gesammelte Datenbasis in zu indizierenden Dateien im Dateisystem des Server-Betriebssystems abzuspeichern. Moderne Dateisysteme können hinreichend große Dateien und Ordnerstrukturen verwalten. Die Hersteller solcher Systeme indizieren die jeweiligen Meldungen bei der Speicherung und legen die Dateien im Dateisystem z. B. in einer zeitlich geordneten Struktur ab.

Ohne die hier typischerweise fehlende Normalisierung der Logdaten und ohne die Überführung der einzelnen Datenfelder in eine für Datenbanken charakteristische Tabellenform kann eine Suche über die Daten aber nicht unbegrenzt effizient durchgeführt: Beispielsweise kann nicht unterschieden werden, ob eine IP-Adresse Quelle oder Ziel eines Angriffs war. Die Index-Datenbank wächst


Logdatenstudie

zudem meist stetig an mit der Menge der gespeicherten Daten, so dass hier durch die Größe des Index schnell eine Obergrenze erreicht wird.

Das Verfahren hat Vorteile, wenn die performante Speicherung der Log-Meldungen im Vordergrund steht und die gesammelten Daten nicht in Quasi-Echtzeit analysiert werden müssen.

Kombinationen dieser AnsätzeUm die Vorteile beider Varianten nutzen zu können, existieren auch Kombinationen aus den beiden genannten Ansätzen. Einige Anbieter von IT-Frühwarnsystemen speichern nur die normalisierbaren Datensätze in einer relationalen Datenbank. Zusätzlich nutzen sie auch die großen Kapazitäten der Dateisysteme, um die originalen Logdaten dort vollständig und unverändert abzulegen und diese nur nachgelagert ohne Anspruch an eine besondere Performance auszuwerten (z. B. für einen nächtlichen Berichtslauf).

5.2.7 Modellierung und Priorisierung; Reduktion von False-Positives

ModellierungDie Modellierung des IT-Verbunds und der in ihm enthaltenen IT-Systeme ist ein wichtiges Hilfsmittel zur Unterscheidung wichtiger von unwichtigen Ereignissen.

Denkbare Modellierungsparameter können zunächst Werte über die Vertraulichkeit, die Kritikalität und die Verfügbarkeit des jeweiligen Systems sein. Die IT-Verantwortlichen müssen die Einstufung der Systeme im Netzverbund prinzipiell manuell vornehmen. Idealerweise ist im Vorfeld der Implementierung eines Systems zur Auswertung von Log- und Monitoringdaten eine Schutzbedarfs- oder Risikoanalyse durchgeführt worden, und ihre Ergebnisse können übernommen werden. Die Definition der von Systemen bereitgestellten Dienste oder Betriebssystem-Informationen kann dann dazu beitragen, die Modellierung zu verfeinern.

Beispielsweise sind Angriffe auf wichtige Systeme in der Entwicklungs- oder der Finanzabteilung mit höherer Priorität zu behandeln, wenn die dort gespeicherten Daten hohen Vertraulichkeitswert genießen und einem Unternehmenskonkurrenten nicht in die Hand fallen dürfen. Angaben über offene Ports auf diesen Systemen geben Aufschluss über denkbare Angriffsvektoren.

Die Berücksichtigung aktueller Ergebnisse eines Schwachstellen-Scans liefert schließlich eine präzise Bestimmung, ob ein konkret durchgeführter Angriff erfolgreich sein wird oder missachtet werden kann, beispielsweise weil rechtzeitig aktuelle Patches eingespielt worden sind.

Ein weiterer Modellierungsaspekt besteht darin, Routing-Pfade des IT-Netzes oder Firewall-Konfigurationen zu importieren und dadurch Aussagen über die Erreichbarkeit einzelner Systeme zu gewinnen.

Ziel einer Modellierung ist es, regelmäßig eine Aktualisierung des konfigurierten IT-Verbund-Modells vorzunehmen. Der damit verbundene, wiederkehrende Aufwand ist durch eine hohe Automatisierung zu minimieren.

PriorisierungAuf einer leistungsfähigen Modellierung aufbauend arbeiten die Systeme aus einer Flut an Log- und Monitoringdaten die Ereignisse größter Wichtigkeit, sprich der höchsten Priorität, heraus. Die Er


Logdatenstudie

eignisse mit der höchsten Priorität werden dem Analysten sofort ersichtlich gemacht durch eine entsprechende Einstufung des Ereignisses, beispielsweise durch farbliche Hervorhebung oder die Vergabe hoher Prioritätszahlen. Zur Durchführung der Priorisierung existieren heutzutage im wesentlichen zwei Ansätze.

Der erste, einfache Ansatz besteht in der Vergabe der Priorität innerhalb einer Korrelationsregel. Sobald eine Regel auslöst wird, wird die in der Regel konfigurierte Priorität dem Ereignis eins-zu-eins zugewiesen. Diese Herangehensweise birgt folgende Beschränkungen:

– Werte wie die Verfügbarkeitsanforderung an das betroffene System, seine Kritikalität und die Vertraulichkeit der dort gespeicherten Informationen werden bei der Priorisierung nicht berücksichtigt.

– Die in den Regeln definierten Prioritäten müssen in der Regel manuell an die Erfordernisse angepasst werden.

Die zweite Herangehensweise berücksichtigt Modellierungsinformationen direkt. Die Priorität wird mit einer Formel berechnet, welche die vorliegenden Modellierungsdaten des angegriffenen Systems berücksichtigt. Aktuelle Informationen über Schwachstellen können das Gewicht des Ereignisses stark erhöhen oder erniedrigen.

Durch die Berücksichtigung dieser Parameter ergeben sich für ein und denselben Angriff unter Umständen völlig unterschiedliche Prioritäten: So kann ein Ereignis, das die Anwendung eines Exploits auf ein verwundbares Zielsystem mit hohem Schutzbedarf vermeldet, mit höchster Priorität versehen werden. Die Anwendung desselben Exploits auf ein gepatchtes System führt hingegen zu einer Herabstufung des Vorfalls.

False-PositivesEin zentraler Aspekt beim Betrieb eines technischen IT-Frühwarnsystems ist die Reduktion von Fehlalarmen (engl. False-Positives).

Ein wichtiger Aspekt, um Fehlalarme zu vermeiden, ist die präzise Planung der aktiven Korrelationsregeln. Das Setzen realistischer Schwellwerte ist in diesem Zusammenhang ein notwendiger Prozess, in Frühwarn-Produkten mitgelieferte Standard-Regelwerke an die Gegebenheiten des IT-Verbundes anzupassen. Hierfür muss typischerweise zunächst ermittelt werden, wo das „Grundrauschen“ normalen Verhaltens zu finden ist, damit über das Grundrauschen hinausgehende Spitzen als sicherheitsrelevante Anomalien erkannt werden können.

In einem weiteren Schritt muss dem System über Ausnahmelisten (engl. White Lists) mitgeteilt werden, welche IT-Systeme fälschlicherweise als bösartig identifiziert worden sind. Solche sind üblicherweise Schwachstellen-Scanner oder Monitoring-Stationen, die sich zu einer hohen Anzahl von Systemen und Diensten auf unterschiedlichsten Ports verbinden und somit jeglichen Schwellwert überschreiten.

5.2.8 Korrelation unabhängiger Ereignisse

Die Korrelation von Log-Meldungen unabhängiger Logdatenquellen stellt eine Kernanforderung an IT-Frühwarnsysteme dar. In IT-Verbünden meist vorzufindende Sicherheitsmaßnahmen wie beispielsweise Firewalls, Intrusion-Detection-/-Prevention-Systeme und Antivirus-Gateways haben eine auf ihre jeweilige Funktion eingeschränkte Sicht. Sie können die Arbeitsabläufe und Prozesse des Unternehmens nicht erfassen und nicht beurteilen, ob diese sicher von statten gehen. Um diese


Logdatenstudie

Aufgabe angehen zu können, müssen komplexere Regeln auf ihre Einhaltung überprüft werden können.

Hierzu ein Sicherheitsrichtlinien-Beispiel: Ein Zugriff aus dem Internet auf den externen Webserver eines Unternehmens muss immer auf TCP-Port 80 über die Firewall des Perimeters erfolgen. Von innen ist zusätzlich Zugriff durch die Gruppe der Administratoren auf Port 20-22 (FTP, SSH) gestattet.

Beteiligte System zur Überwachung sind die Firewall, der Webserver, Authentifizierungs-Systeme und ggf. weitere.

Man kann zwischen folgenden drei Varianten von Korrelationen mit wachsendem Anspruch an die Umsetzbarkeit unterscheiden:

– Korrelation innerhalb der gleichen Geräteklasse (z. B. Firewalls): Hierbei lassen sich Auswertungen auf Auslastung und abnormes Verhalten innerhalb der Geräteklasse erstellen und einfache Analysen betreiben, z. B. Trendreports oder Top Talker.

– Korrelation über Geräteklassen mit ähnlichen Datenfeldern (z. B. Firewalls und Router): Zusätzlich lassen sich erweiterte Analysen zu den Stationen eines Angriffs durchführen.

– Korrelation über verschiedene Geräteklassen: Erst diese ermöglicht einen umfassenden Einblick auf Transport- und Applikationsebene. Ein Beispiel: Der Viren-Scanner eines Arbeitsplatzes meldet einen Wurm und dessen Quarantäne. Im weiteren Verlauf meldet ein Netzwerk-Gerät einen Anstieg von Netzwerkverkehr auf einem dedizierten Port, ausgehend vom Viren-befallenen System. Ohne Korrelation besteht die Gefahr, dass diese beiden Einzelmeldungen als irrelevant eingestuft werden, bzw. in der Datenmenge untergehen.

Die Korrelationsregeln lassen sich auch miteinander verknüpfen. So kann ein Angreifer, der bereits früher aufgefallen ist, bei erneuter Entdeckung höher priorisiert werden.

Eine Korrelationsregel besteht typischerweise aus den folgenden Komponenten:

– Mehrere Geräteklassen und deren normalisierte Datenfelder

– Logische Verknüpfungen (UND, ODER, NICHT etc.)

– Attribute (Zähler, Schwellwerte, z. B. Auftreten > 50)

– Aktionen (Alarmierung, Auslösen von Aktionen etc.)

Ein nicht zu vernachlässigender Aspekt bei der Erstellung von Korrelationsregeln ist die Tatsache, dass diese zur nahezu Echtzeitverarbeitung im Arbeitsspeicher der Management-Komponente vorgehalten werden müssen. Je größer die innerhalb der Regeln zu überwachenden Zeiträume und der Komplexität und Anzahl der Regeln, desto höher der Ressourcenverbrauch auf der Management-Komponente.

5.2.9 Grundlegende Sizing-Aspekte technischer IT-Frühwarnsysteme

Die Planung der Infrastruktur ist ein essentieller Bestandteil bei der Einführung eines Systems zur zentralen Auswertung von Log- und Monitoringdaten. Solche Systeme haben einen nicht unerheblichen Ressourcenbedarf, der entsprechende Kosten bei der Beschaffung von Hardware nach sich zieht. Ziel der Planung des Umfangs des Systems ist eine ausreichende Performance mit Reserven für Lastspitzen und Skalierbarkeit, ohne dass dadurch unnötige Kosten bei der Implementierung erzeugt werden.


Logdatenstudie

Um diese Aufgabe erfolgreich lösen zu können, sind die folgenden Fragen zu beantworten:

1. Wie groß ist das durchschnittliche zu verarbeitende und zu speichernde Datenvolumen innerhalb eines Tages (24 Stunden)?

2. Wie hoch ist die durchschnittliche und die höchste Anzahl an Logmeldungen pro Sekunde (EPS)?

3. Wie hoch ist die durchschnittliche Log-Rate in Kilobyte pro Sekunde für alle Datenquellen (kbps)?

4. Welche Art von Datenquellen und in welcher Anzahl sind Datenquellen in das System einzubinden?

5. Wie groß ist die größte Logdatei und das größte Logvolumen der einzelnen Datenquellen innerhalb eines Tages?

6. Wie lange müssen die einlaufenden Meldungen im System verfügbar sein?

Diese Fragen dienen der Abschätzung der Leistung der Management-Komponente und der darunter liegenden Datenbank. Die Administratoren der Log erzeugenden Systeme sind in der frühen Planungsphase abzufragen. Eventuell sind Messungen durchzuführen, um die tatsächlichen Raten zu ermitteln.

Die durchschnittliche Prozessorlast wie auch die Speicherauslastung an Management-Komponente und Datenbank sollte 50 % nicht überschreiten, um noch genügend Reserven für Lastspitzen und Erweiterungen des IT-Frühwarnsystems anbieten zu können.

Zu beachten sind weiterhin die Gegebenheiten der genutzten Netzwerkinfrastruktur und deren Bandbreiten. Die Komponenten des Systems, die Logs sammeln, führen häufig eine Datenkomprimierung bei der Übertragung zum zentralen Management durch. Dies kann gerade in schmalbandig angebunden Außenstellen einen Logsammler notwendig machen, der die Logs vor der Übertragung zum Management konsolidiert.

5.2.10 Output und Alarmierung

Ein technisches IT-Frühwarnsystem sollte bestehende Arbeitsabläufe und Datenflüsse nicht nur beachten und abbilden können, sondern sich auch in diese integrieren. Deshalb sollte ein IT-Frühwarnsystem eine Anzahl an häufig genutzten Schnittstellen für die Alarmierung und weitere Verfolgung von Vorfällen bereithalten.

Die Alarmierung von wichtigen Ereignissen hat über eine möglichst hohe Anzahl an Benachrichtigungsmechanismen zu erfolgen. Meist sind Prozesse für die Nachverfolgung von sicherheitsrelevanten Ereignissen in Behörden und Unternehmen bereits implementiert. Dies können neben einfachen Adressatengruppen in Mailsystemen auch fortgeschrittene Prozessabläufe und deren Bearbeitungssysteme sein. Ideal ist die Unterstützung der folgenden Benachrichtigungsmechanismen:

– Ein technisches IT-Frühwarnsystem sollte Ereignisse mit hoher Priorität als Alarmierung abgesetzt auf der Management-Konsole des Systems ausgeben.

– E-Mails: Das Versenden von E-Mails ist ein Mechanismus auf dem kleinsten Nenner. Da Mailsysteme ein Standard in der Unternehmenskommunikation sind, hat sich die Versendung von Ereignismeldungen hierüber bewährt. Die sofortige Bearbeitung des gemeldeten Vorfalles lässt sich aber nicht sicherstellen.


Logdatenstudie

– SMS oder Pager-Nachrichten: Das Versenden von Nachrichten an ein Mobiltelefon oder einen Pager eines Bereitschaftshabenden ist ebenfalls nicht gesichert (Funkloch). Zudem haben derartige Systeme keine weite Verbreitung in der Unternehmenslandschaft.

– SNMP-Traps: Die Versendung von SNMP-Traps ist eine Option zur Anbindung eines technischen IT-Frühwarnsystems an Ticket- und Case-Systeme. Sind derartige Systeme bereits implementiert, ist dies eine adäquate Option zur Weiterleitung von Vorfällen.

– Skripte: Die Ausführung von Skripten bietet Flexibilität bei der weiteren Verarbeitung von Vorfällen. Die tatsächliche Ausführung ist außerhalb des Systems sicher zustellen.

– Offene Programmierschnittstelle (API). Die Bereitstellung einer offenen und gut dokumentierten Programmierschnittstelle bietet Flexibilität bei der Anbindung an externe Verarbeitungssysteme.

Die ideale Überwachung der Meldungen eines technischen IT-Frühwarnsystems und deren Verarbeitung erfordert eine Infrastruktur zur verteilten Bearbeitung. Häufig sind verschiedene Abteilungen bei der weiteren Analyse und Behebung von Vorfällen beteiligt. Die Bearbeitung über mehrere Stationen – auch im Wechsel – ist nicht selten. Diese Überwachung kann allerdings nur durch einen definierten und implementierten Incident-Handling-Prozess gewährleistet werden.

Ein technisches IT-Frühwarnsystem sollte ferner bereits implementierte Systeme zur Bearbeitung von Trouble-Tickets unterstützen und adäquate Schnittstellen bereithalten. Der Vorteil des kombinierten Einsatzes mit Trouble-Ticket-Systemen liegt in Betriebsart solcher Systeme. Meist sind diese in ein Help Desk integriert, welches erweiterte Servicezeiten bis hin zu einer lückenlosen Besetzung (24x7 Stunden) bietet.

Ergänzend bieten manche Systeme zur Verarbeitung von Log- und Monitoringdaten selbst ein Trouble-Ticket-System zur Bearbeitung von Vorfällen. Somit kann bei Bedarf ein Incident-Handling-Prozess für das IT-Frühwarnsystem aufgebaut werden. Andererseits bietet ein System zur Auswertung von Log- und Monitoringdaten in Kombination mit einem externen Trouble-Ticket-System und einem bidirektionalen Datenfluss die Möglichkeit, Tickets an externe Systeme zu leiten. Gleichzeitig kann der aktuelle Stand an die Benutzer des IT-Frühwarnsystems gespiegelt und eine Interaktion aufgebaut werden.

5.2.11 Ergebnisdarstellung, Analysefunktionen und Berichterstellung

Ein wesentlicher Aspekt bei der Arbeit mit einem System zur Auswertung von Log- und Monitoringdaten ist die aussagekräftige Darstellung der jeweiligen Ergebnisse in einer leistungsfähigen Benutzeroberfläche und die Unterstützung bei der Erstellung von Berichten. Auch wenn aktuelle Systeme das Auffinden von Ereignissen in der Flut an Meldungen einzelner Datenquellen automatisieren – die Analyse und letztlich die Aussage über die Wahrscheinlichkeit eines realen Angriffs ist vom Benutzer zu tätigen. Um diese Aufgabe zu meistern, müssen gut ausgebildete Analysten durch sinnvolle Analysefunktionen unterstützt werden.

Analyse in der BenutzeroberflächeIn der Benutzeroberfläche sollten die am höchsten priorisierten Ereignisse sofort für den Analysten einsehbar sein. Diese können durch eine veränderte Farbgebung, durch Anzeige in einem separaten Fenster oder Einblenden eines Pop-up-Fensters kenntlich gemacht werden. Der Benutzer ist durch geeignete Werkzeuge bei der Analyse zu unterstützen.


Logdatenstudie

– Die einzelnen Prioritätsstufen sollten durch Setzen von Filtern oder Sortierung der Ereignisse unterscheidbar werden.

– Bei korrelierten Ereignissen sollten die einzelnen Meldungen, welche zum Auslösen der Regel führten, dem Benutzer angezeigt werden.

– Der logische Ablauf eines Angriffspfades sollte dem Benutzer visuell dargestellt werden. Die visuelle Anzeige gibt den Verlauf meist leichter verständlich wieder.

– Während der Anzeige eines Ereignisses sollte idealerweise ein Kontextmenü bei der Analyse unterstützen. Dieses sollte sukzessive Fragestellungen ermöglichen (z. B. alle Ereignisse von Angreifer/Opfer, alle Angriffe auf Port X etc.)

BerichterstellungSysteme zur Auswertung von Log- und Monitoringdaten vereinen unterschiedlichste Datenquellen und verarbeiten die Meldungen dieser Quellen. Dies zieht meist eine Abteilungen übergreifende Positionierung der Frühwarnung im Organigramm des Unternehmens nach sich. Das Management eines Unternehmens nutzt die Fähigkeiten des Systems zudem oftmals, um die Konformität mit Compliance-Standards nachzuweisen.

Die Anforderungen an die Art der Berichte variieren:

– Manager benötigen Berichte über den aktuellen Status der Konformität zu Compliance-Standards (soweit diese vom System unterstützt werden).

– Aktuelle Trendstatistiken sollten in den erstellten Berichten enthalten sein und sollten den aktuellen Stand der Sicherheit im Zeitverlauf darstellen. Außerdem sollten sie einen Überblick über die Anzahl der Ereignisse im vergangenen Monat und andere Sicherheitsfakten bieten.

– Die Berichte sollten sollten die wichtigsten Bedrohungen in einer Rangfolge (Top-n) darstellen. Zum Beispiel: Top 10 der Angreifer, der angegriffenen Ports, der Opfer etc. Diese Ranglisten dienen der Einsicht in die aktuelle Gefährdungslage.

– Da die Systeme durchaus an forensischen Untersuchungen von Vorfällen beteiligt sind, sollten auch sehr detaillierte Berichte mit allen verfügbaren Informationen eines Vorfalls möglich sein. Diese dienen zum Teil der Beweisführung und sollten deshalb so aufgebaut sein, dass sie von Gerichten verwertbar sind.

Berechtigungen auf die jeweiligen Berichtsfunktionen müssen granular an Gruppen und Benutzer vergebenen werden können. Nicht jede Information sollte einsehbar sein. Die Zuweisung von bestimmten Datenquellen oder Berichtsfunktionen muss für am System partizipierende Abteilungen konfigurierbar sein.

Um diese Anforderungen zu erfüllen, sollte die Berichtsfunktion möglichst flexibel sein. Die Erstellung eigener Berichte mit dem Firmenlogo des Unternehmens ist oft gewünscht. Idealerweise wird die Veränderung und Erstellung von Berichten über eine Assistenzfunktion unterstützt. Ein System zur Auswertung von Log- und Monitoringdaten sollte zudem eine umfassende Auswahl an nützlichen Berichtsvorlagen bereits im Auslieferungszustand mitbringen.


Logdatenstudie

5.2.12 Sicherheit von IT-Frühwarnsystemen: Integrität, Authentizität, Verfügbarkeit und Vertraulichkeit von Log- und Monitoringdaten

Systeme zur Auswertung von Log- und Monitoringdaten, insbesondere Systeme mit Fokus auf der Entdeckung von sicherheitsrelevanten Vorfällen, stellen selbst eine Komponente mit hohem Schutzbedarf dar, was sich in der zentralen Zusammenführung sicherheitsrelevanter Logdaten innerhalb eines einzelnen Systems begründet. Forderungen an Integrität, Authentizität, Verfügbarkeit und Vertraulichkeit der Lösung und ihrer Daten sind bei der Auswahl, Planung und Betrieb des Systems entsprechend zu berücksichtigen.

Erlangt ein nicht autorisierter Benutzer Zugang zum System, können sensitive Informationen verloren gehen oder zu nicht berechtigten Zwecken verwendet werden. Ein technisches IT-Frühwarnsystem sollte durch geeignete Gegenmaßnahmen gegen gängige Angriffsszenarien geschützt sein. Dies umfasst sowohl den Basisschutz des Systems durch eine vorgelagerte Firewall, eventuell ergänzt um ein Intrusion-Prevention-System, welches auch Angriffe auf Applikationsebene erkennen und verhindern kann. Diese Maßnahme ermöglicht die Beschränkung auf die absolut notwendigen Kommunikationsbeziehungen. Auch halten Lösungen im Bereich der Systeme zur Auswertung von Log- und Monitoringdaten oftmals erweiterte Authentifizierungsmethoden bereit. Die Integration in Verzeichnisdienste mit AAA-Servern und die Verwendung von Zertifikaten und Tokens ist ebenfalls häufig mit diesen Systemen möglich.

Die in technischen IT-Frühwarnsystemen gespeicherten Daten sind vor Verlust zu schützen. Eine der Funktionalitäten ist neben der Echtzeitanalyse der Datenbasis auch die Auswertung dieser über unter Umständen lange Zeiträume. Je nach Zweck des Systems (SEM, SIM) sind die Daten als zentrale Datenbasis des Unternehmens anzusehen und unterliegen somit gesetzlichen Aufbewahrungsfristen. Das System muss also geeignete Funktionen beinhalten, um die Daten über einen ausreichend langen Zeitraum speichern zu können und diese darüber hinaus vor Verlust zu schützen. Entsprechende Fallback- und Backup-Mechanismen sind vom System zur Verfügung zu stellen. In Systemen zur Auswertung von Log- und Monitoringdaten kommen häufig relationale Datenbanken zum Einsatz, die bereits Schutzmechanismen gegen Datenverluste integriert haben. Diese sind mit entsprechenden Backup-Möglichkeiten zur externen Aufbewahrung der Daten zu vervollständigen.

Weiterhin besteht das Problem des Mitlesens von sensitiven Daten während der Übertragung vom erzeugenden System zur ersten Instanz des sammelnden Systems und der Übertragung innerhalb des Systems selbst. Je nach Architektur des Systems (software- oder appliancebasiert) kann die Komponente, welche die Logs sammelt, unterschiedlich nah am erzeugenden System platziert werden. Eintechnisches IT-Frühwarnsystem muss ausreichende Verschlüsselungsmechanismen bei der systeminternen Kommunikation zur Sicherstellung der Integrität und Authentizität der über das Netzwerk übertragenen Logdaten bereitstellen. Dies wird idealerweise durch die Verwendung von Verschlüsselungsalgorithmen in Zusammenspiel mit Hash-Algorithmen gewährleistet. In manchen logerzeugenden Systemen kann bereits eine Verschlüsselung zur ersten Instanz des sammelnden Systems und damit durchgängig für die gesamte Übertragung aufgebaut werden. Kann die Verschlüsselung nicht umgesetzt werden (z. B. bei Syslog), ist das Risiko des Mitlesens von sensitiven Daten durch Platzierung der Logs sammelnden Komponente des technischen IT-Frühwarnsystems möglichst nahe am Quellsystem zu minimieren.

Auch die Nachvollziehbarkeit der Handlungen der Benutzer des Systems sollte über eine entsprechende Protokollierung (Audit-Log) gewährleistet sein. Kein Benutzer des technischen IT-Frühwarnsystems darf die protokollierten administrativen Handlungen im Nachgang verändern oder löschen können. Dies gilt auch für Benutzer mit administrativen Rechten.


Logdatenstudie

5.3 Vorstellung aktuell erhältlicher Produkte zur Speicherung und Verarbeitung von Log- und Monitoringdaten

Im folgenden Abschnitt wird eine Anzahl aktuell erhältlicher Produkte zur Speicherung und Auswertung von Log- und Monitoringdaten vorgestellt. Eine Vorauswahl der zu untersuchenden Produkte erfolgte auf der Basis einer Marktsichtung im Herbst 2006, wobei konkrete Vorschläge interessierter Referate mit einbezogen wurden. Die endgültige Auswahl erfolgte in Zusammenarbeit mit dem Auftragnehmer der Studie.

Auf Grund der relativ weit gefassten Anforderungen und der Veränderungen auf dem Markt für solche Systeme ist die Übersicht nahezu zwangsläufig unvollständig.

5.3.1 Nagios

Nagios ist ein flexibles und verbreitetes Open-Source-Werkzeug zum Überwachen IP-basierender Systeme aller Art, Dienste, Applikationen und (mit einigen Zusatzaufwänden) auch Netzwerk-Infrastrukturen. Es wurde von Ethan Galstad entwickelt und löste das ältere Netsaint ab.

Durch seine GPL-Lizensierung ist der Einsatz von Nagios mit keinen Lizenzkosten verbunden, der Konfigurationsaufwand zur Anpassung von Nagios lohnt sich erfahrungsgemäß aber erst ab mittelgroßen Netzwerken oder sehr komplexen Systemabhängigkeiten. Die derzeit größten Nagios-Installationen umfassen ca. 5.000 Hosts bzw. 40.000 überwachte Dienste. Nähere Informationen hierzu finden sich auf den Webseiten des Projekts unter http://www.nagios.org.

Durch seine Erweiterbarkeit über Module und Schnittstellen ist es schwer, die Leistungsfähigkeit von Nagios präzise einzugrenzen. Sie hängt stark vom konkreten Aufbau ab und der Frage, welche Module verwendet werden. Über folgende Leistungsmerkmale kann sie dennoch grob charakterisiert werden:

– Überwachung von Dienst- und Systemverfügbarkeiten

– Definition von Systemabhängigkeiten und Status-Propagierung

– Überwachung von Schwellwerten

– Bereitstellung eines Plugin-Interfaces, das neben einer umfangreichen Bibliothek verfügbarer Erweiterungen auch die Integration von speziellen, selbst entwickelten Überwachungsmethoden erlaubt.

– Bereitstellung eines granularen und universellen Benachrichtigungs- und Eskalationskonzepts

– Möglichkeit zur Definition von sog. "Event Handlern" für durch Ereignisse ausgelöste Reaktionen

– Ergebnis-Ausgabe über Webschnittstellen

– Automatische Logdateien-Rotation und -Archivierung

– Optional: agentenbasiertes verteiltes Sammeln und Erfassen von abgeschotteten Inseln, z. B. per NRPE und NSCA

Da die mitgelieferte Statusanzeige von Nagios bereits nicht mehr in der Lage ist, per Submaps ein mittleres Netz (100+ Systeme) übersichtlich darzustellen, sei NagVis als notwendiges Visualisie


Logdatenstudie

rungs-Add-on erwähnt. Zu erwähnende Nachbarprodukte im Open-Source-Bereich sind Big Brother (veraltet), Open-NMS und Zabbix (neu).

Aktuelle Version 2.9 (stable), 3.05b (Beta)Unterstützte Plattformen/Hardware-Serien ● Kompilierbare Sources für jedes Unix-

Derivat, z. B. Linux, BSD, Solaris, AIX, HP-UX

● Vorkompilierte RPMs für Red Hat und Fedora

Tabelle 50: Version und Plattformen von Nagios

Zusammenführung von Log- und MonitoringdatenDie Nagios-Architektur stellt sich wie folgt dar: Nagios besteht aus einem C-kompilierten Daemon, der über eine Reihe von Konfigurationsdateien sowie einige weitere Komponenten gesteuert wird und für die Steuerung der Überwachung verantwortlich ist. Für „Inhaltliches“ sind die Erweiterungen zuständig, wovon ein noch überschaubares Paket im initialen Lieferumfang enthalten ist, ein Vielfaches davon aber in der Open-Source-Welt zu finden ist. Statusinformationen gibt Nagios über eine Logdatei und über seine umfangreiche Web-Benutzeroberfläche aus.

Primär stellt Nagios ein Monitoring von Netzwerkservices wie SMTP, POP3, HTTP, Datenbanken, Ping etc. bereit – sowohl hinsichtlich simpler Verfügbarkeit als auch für Detailabfragen. Für Syslog und IPFIX benötigt man aber eigens entwickelte „Application-Stacks“ (siehe unten), um diese Daten verarbeiten und darstellen zu können. Ihre Normalisierung und Speicherung im Originalformat ist bei Nagios jedoch nicht vorgesehen.

Für viele Basisabfragen obiger Art kann beim Nagios-Einsatz auf Agenten verzichtet werden, für tiefer gehende Abfragen – insbesondere im Windows-Umfeld – müssen jedoch entsprechende Agenten auf den zu überwachenden Systemen installiert werden.

Die Verarbeitung von Logdaten ist für die Anforderungen eines IT-Frühwarnsystems nur rudimentär über die nativen Erweiterungen „check_log“ und „passive checks“ abgebildet. Die Zusammenführung von Logdaten oder vorverarbeiteten Monitoringdaten kann ereignisbezogen, d. h. passiv, über den NSCA (Nagios Service Check Acceptor) und aktiv über den NRPE (Nagios Remote Plugin Executor) erfolgen. Die Übertragung der Ereignisdaten per NSCA und NRPE erfolgt stets verschlüsselt, die der Monitoringdaten („active checks“) nur bei Verwendung des Moduls „check_ssh“.

Für die zwei generischen Ereignisquellen SNMP und Syslog sind „Application Stack“-Erweiterungen erforderlich:

– SNMP: NetSNMP, SNMPTT und Nagtrap (Benutzer-Interface)

– Syslog: Syslog-NG, sqlsyslog Daemon, php-syslog-ng (Benutzer-Interface)

Auf Basis dieser beiden Datenquellentypen ist eine Echtzeit-Darstellung von Ereignissen innerhalb der verfügbaren Rechner-Ressourcen des Nagios Servers möglich, sie wird jedoch problematisch im Fall von Systemengpässen. Die Möglichkeit, innerhalb der angezeigten Meldungen Filter zu setzen, ist nur rudimentär implementiert, aber durch manuelle Konfigurationsarbeit verbesserbar.

Gleichartige Monitoring-Meldungen können durch optionale Vorschriften zu einer einzelnen Meldung verdichtet, d. h. aggregiert werden. Im Nagios ist dies auch unter Detection and Handling of State Flapping beschrieben. Dies muss wiederum über spezielle Erweiterungen realisiert werden.


Logdatenstudie

Die Speicherung von Ereignissen über einen Zeitraum von mindestens 30 Tagen stellt bei geeigneter Hardware-Auswahl insofern kein Problem dar, dass durch starke Vorfilterung und Aggregation letztendlich nur relativ wenige Meldungen zentral gespeichert werden müssen. Nagios verwendet als zentralen Datenspeicher eine MySQL-Datenbank.

Mit Ausnahme von NetFlow- und IPFIX-basierten Datenquellentypen gibt es kaum eine Datenquelle, die Nagios mit seiner umfangreichen Plugin-Bibliothek, bestehend aus eigenen und beigetragenen Bestandteilen, nicht auf direktem Weg anbinden kann. Solche speziellen Plugins und Anleitungen für ihren Einsatz sind über Suchmaschinen leicht auffindbar. Jedoch verfolgen diese zumeist den Verfügbarkeits-, Servicelevel- und zunehmend den Performance-Aspekt ihrer Datenquellen und nur sehr selten die Sicherheitsaspekte Integrität und Vertraulichkeit. Eigene Plugins können in allen gängigen Programmiersprachen, vorzugsweise C, Perl, Shellscript oder PHP, geschrieben und in Nagios eingebunden werden.

Für die Sicherstellung der Systemverfügbarkeit werden Ereignisse in Nagios generell durch Ressourcen schonende passive Abfragen („passive checks“) in Nagios eingelesen. Es ist davon auszugehen, dass bei einem vernünftig dimensionierten Server Engpässe selten auftreten, wenn Ereignisse die Hauptdatenquelle bleiben. Die zu übertragenden Daten werden optional verschlüsselt übertragen, abhängig auch von ihrer Natur: „echo-replies“ können in diesem Sinne nicht vertraulich übertragen werden.

Ereignis-Entdeckung und ihre UnterstützungDie Modellierung eines IT-Verbundes in Nagios verfolgt naheliegenderweise den Verfügbarkeits- und Servicelevel-Aspekt, und nicht den Aspekt der Informationssicherheit im engeren Sinne. Das gleiche gilt für die möglichen Korrelationsfunktionen.

Für die Nagios-Kernfunktionen des Monitorings von IT-Komponenten müssen diese im Nagios hinterlegt und mit ihren zu überwachenden Eigenschaften versehen werden. Ein Modellierung in diesem Rahmen ist also obligatorisch. Weitergehende Eigenschaften oder über das Netzwerk vermittelte Zusammenhänge sind nur manuell einstellbar. Es fehlen insbesondere Gewichtungsmöglichkeiten aus Sicht der Informationssicherheit und Verbindungen zu Schwachstellen-Scannern.

Eine Korrelation im Sinne einer Ursachen-Analyse (Untersuchung von aufeinander folgenden Geschehnissen) bedeutet in Nagios aufwändige manuelle Konfigurationsarbeit, da jene granular-spezifisch und statisch durch Einzel-Service- und Host-Abhängigkeiten abgebildet werden muss und nicht generisch hinterlegt werden kann. Sie erfolgt in Echtzeit. Da eine Normalisierungsebene für die zugrunde liegenden Daten fehlt, wird ein erheblicher Aufwand unvermeidlich. Die Hauptfunktion von Nagios Basis-Korrelationen liegt in der Feststellung einer Schwellwert-Überschreitung.

Ein Standard-Regelwerk im Sinne von nutzbaren Sicherheits-Korrelationsregeln existiert nicht. Andere Basis-Korrelationen, oder besser Überwachungsvorschriften, müssen an die jeweiligen Anforderungen angepasst werden. Eine Mustererkennung ist nicht realisierbar, weder auf spezifischer noch generischer Ebene.

Denselben rudimentären Korrelationsmechanismen unterliegen auch die Agenten NSCA und NRPE, wobei eine Vorfilterung von Log- und Monitoringdaten auf Agentenebene zumindest verhindert, dass unerwünschte bzw. unnötige Meldungen auf zentraler Seite ankommen und es dort somit zu einer Belastung der zentralen Komponenten kommt.

Als Korrelationsergebnisse können außer der Generierung einer Ereignismeldung selbst folgende Aktionen ausgeführt werden:


Logdatenstudie

– SMS

– Pager

– E-Mail

– SNMP-Traps

– Ausführen eines frei konfigurierbaren Skripts

– Text2Speech durch Integration von Asterisk

– Seit Nagios v3: Übergabe an ein Ticketing-System

Eine Abbildung von Benachrichtigungsgruppen ist möglich. Es werden in der Monitor-Anzeige keinerlei Ereignisse dargestellt, sondern nur die Status der von Ereignissen beeinflussten Services und Hosts, welche folgende Zustände einnehmen können:

– Ack

– Error

– Unknown

– Critical

– Ok

– Up

– Down

– Sack

– Warning

In den täglich rotierenden eigenen Nagios-Logdateien und -Berichten sind zusätzlich die Ergebnisse aus Plugins (auch die der passive checks, welche indirekt die eingesammelten Logdaten enthalten) historisch festgehalten und zwar nach folgendem Konsolidierungsschema:

– „stalking[service] disabled“ → Status, d. h. nur Inhalte nach einer Status-Änderung werden festgehalten; dies führt zu einer Datenmengen-Reduzierung

– „stalking[service] enabled“ → PlugIn-Output-Inhalt; umfangreiche Datenmengen laufen auf

Für stärker automatisierte Korrelationen kann die Erweiterung SEC (Simple Event Correlator) sorgen. Es erweitert Nagios um Fähigkeiten, die in folgender Präsentation dargestellt sind:

http://www.cs.umb.edu/~rouilj/sec_nagios/WIP_nagios_sec.pdf

Ein algorithmisiertes Priorisierungsschema bietet Nagios allerdings nicht an.

Hochverfügbarkeit ist bei Nagios nicht vorgesehen. Für die Verfügbarkeit seiner Funktionen und Komponenten muss das System deshalb besonders sorgfältig auf die an Nagios gestellten Anforderungen abgestimmt werden, um eine Überlastung zu vermeiden. Vor allem der Einsatz vieler Plugins führt zu vermehrtem Datenaufkommen.

Benutzerinteraktion und VorfallsbearbeitungStatusinformationen gibt Nagios über eine Logdatei und über seine umfangreiche Web-Benutzeroberfläche aus. Die Konfiguration erfolgt mittels eines Texteditors. Nagios kann auch über ergänzen


http://www.cs.umb.edu/~rouilj/sec_nagios/WIP_nagios_sec.pdf

Logdatenstudie

de Open-Source-Web-Oberflächen wie NagiosQL, Groundworks Monarch und ca. 40 weitere kleinere Interfaces konfiguriert werden. Recherche-Möglichkeiten sind kaum vorhanden, da eine Echtzeit-Darstellung priorisierter Ereignisse im Wesentlichen fehlt. Somit fehlt auch ein Ausgangspunkt für Recherchen. Die Visualisierung dient der Darstellung von Systemverfügbarkeiten. Insgesamt liefert Nagios über seine Web-Interfaces diese Informationen:

– Aktueller Systemstatus in der „Map“

– Alarmierungen

– Darstellung der Problemhistorie

– Berichtgenerierung

Berichte umfassen vor allem Verfügbarkeitsaussagen. Sie können automatisch generiert und in HTML und CSV dargestellt werden. Eigene Berichtsvorlagen können nicht erstellt werden. Allerdings bietet Nagios die Möglichkeit, eigene SQL-Abfragen über die auf MySQL basierende NDO-Erweiterung („NDOUtils“) zu erstellen.

In Nagios selbst gibt es ein gruppen- und ein rollenbasiertes Rechtekonzept, in dem bis auf Einzel-Host- und Service-Ebene heruntergebrochene Daten Benutzergruppen zugeordnet werden können. Des Weiteren können verschiedene Zugriffs-Levels, beispielsweise für die Zusammenfassung, Details, die Berichterstellung, das Setzen von Downtimes usw., vergeben werden. Die Konfiguration von Nagios selbst ist zusätzlich auf Datei-Ebene geschützt.

Für die Benutzerauthentifizierung bietet Nagios standardmäßig nur eine lokale Authentifizierung nach dem Schema „Benutzername/Passwort“. Eine erweiterte Authentifizierung und eine Beschränkung auf IP-Adressen ist nur über eine entsprechende Konfiguration der Webserver-Komponente möglich.

Sicherstellung der Verfügbarkeit des SystemsEine Selbstüberwachung ist bei Nagios sehr gut abgebildet. Sie wird innerhalb des Gesamt-Monitorings dargestellt. Darüber hinaus bietet Nagios vorgefertigte MRTG-Konfigurationen zur Darstellung von eigener Statistiken mithilfe von MRTG. Es existiert ein erweitertes Setup für das Monitoring eines redundanten Nagios Servers und für Nagios HA.

Die Produktpflege der Zielkomponenten liegt vollkommen in den Händen des Administrators, insbesondere für die eingebauten Datenbankkomponenten. Es gibt keinerlei eingebaute Automatismen für diese Tätigkeiten.

5.3.2 HP „OpenView for Operations“

Die Firma Hewlett Packard bietet zwei Versionen des Produktes „HP OpenView Operations“ aus der Produktsuite „HP OpenView“ an. Die Produkte „HP OpenView Operations for Windows“ und „HP OpenView Operations for UNIX“ unterscheiden sich im Wesentlichen darin, dass sie entweder unter dem Betriebssystem Microsoft Windows, Sun Solaris oder HP-UX laufen. Im Fokus der folgenden Betrachtung steht das Produkt auf UNIX-Basis. Das Produkt für Windows-Systeme wird voraussichtlich im Laufe des Jahres 2007 eine wesentliche Produktänderung im Hinblick auf sicherheitsrelevante Aspekten erfahren. Stand heute ist das Windows- basierende Produkt nicht in der Lage, Daten verschlüsselt über HTTPS zu übertragen.


Logdatenstudie

„HP OpenView Operations for UNIX“ (im Folgenden OVOU genannt) fokussiert sich auf die Erhebung von Performance-Kennzahlen und die Überwachung der Verfügbarkeit von:

– Aktiven Netzwerkkomponenten bis Layer 2

– Betriebssystemen unterschiedlichster Derivate (agentenbasiert)

– Applikationen verschiedenster Hersteller

– ASCII-basierten Logdateien und SNMP-Geräten

Die Lösung lässt sich aufgrund der hochgradigen Integration von unterschiedlichen Funktionen nicht eindeutig in eine Sparte einordnen. Der vorgestellte Produktumfang erfüllt sowohl die Funktionen eines Monitoring-Systems als auch Funktionen aus dem Bereich der IT-Frühwarnung nahezu in Echtzeit.

OVOU wird nach der Anzahl von überwachten Systemen lizenziert. Dabei ist es entscheidend, auf welcher Hardware diese Systeme laufen. Bei virtuellen Servern wird einmalig die darunter liegende Hardware lizenziert. Bei physischen Systemen wird je nach CPU-Typ nach der Anzahl der CPUs oder nach Hardware-Hersteller und Produkt lizenziert. Die Lizenz für die zentrale Komponente umfasst unter anderem den Service Navigator, eine einfache Korrelationsmaschine und die Möglichkeit, 1.000 aktive SNMP-basierte Komponenten zu überwachen. Die benötigte Oracle-Datenbank ist nicht Bestandteil der Lizenz.

Zu der HP OpenView-Produktsuite gehören weiterhin Lösungen, die weitgehend miteinander integriert sind. Hierzu gehören folgende:

– Softwareverteilung, Inventarisierung, Asset- und Lizenz-Management

– Netzwerk-Konfigurationsmanagement

– ITIL-basierte Produkte (Incident-, Change-, Problem-, Change-, ... -Management)

– End-to-End-Management

– Lasttestverfahren

– Storage-Management

– Reporting

Aktuelle Version HP OpenView Operations UNIX Version 8.xUnterstützte Plattformen/Hardware-Serien HP-UX (PA-RISC, Itanium), Solaris (SPARC)

Tabelle 51:Version und Plattformen von HP OVOU

Zusammenführung von Log- und MonitoringdatenOVOU besteht aus dem zentralen System, den Agenten auf den zu überwachenden Systemen, einer Oracle-Datenbank und den Konsolen für den Zugriff auf das zentrale System. OVOU kann in einem Cluster aufgebaut werden. Die folgende Abbildung zeigt die Architektur von HP OVOU:


Logdatenstudie

Abbildung 5.1: Architektur von HP OVOU

Bei einem Ereignis informiert der Agent per „Event“ das zentrale System und übermittelt dabei Informationen, welches Ereignis zu dem Event geführt hat. Wenn eine Festplattenpartition vollläuft beinhaltet das Event typischerweise die Partition, den Füllgrad, den Schwellwert, der überschritten wurde und eine Handlungsanweisung. Führt ein Log-Eintrag aufgrund einer Mustererkennung (Pattern) zu einer Benachrichtigung, so beinhaltet diese typischerweise den einzeiligen Log-Eintrag, die Ereigniszeit, den Systemnamen und einen Meldungstext, der automatisch aus Teilen dieser Informationen zusammengesetzt wurde. Diese so genannten Events werden dann zum zentralen System geschickt und können dort miteinander korreliert werden.

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler AgentLogkorrelator Event Correlation DesignerManagement-Komponente „HP OpenView Operations for UNIX“ und „HP OpenView

Performance Insight“Logspeicher Oracle-DatenbankEreignis Event

Tabelle 52: Begriffsbestimmung bei HP OVOU

Sowohl die Events, die aus dieser Korrelation entstehen, als auch die originalen Events können in der zentralen Oracle-Datenbank beliebig lange gespeichert werden. Die einzige Beschränkung besteht dabei in der Größenbeschränkung der Oracle-Datenbank selbst.

Die ASCII-Logdateien und die binären Logdateien bleiben unberührt im Original bestehen. Bei binären Logdateien muss dafür gesorgt werden, dass ein Übersetzungsprogramm existiert, dass die Datei in eine ASCII-Datei durch HP OpenView gesteuert übersetzt.


Logdatenstudie

Alle Events können sowohl durch den Agenten als auch in der zentralen Komponente aufgrund unterschiedlicher Kriterien gefiltert und aggregiert werden.

Bei nicht unterstützten Datenquellen muss dafür gesorgt werden, dass ein Event erzeugt wird, welches die notwendigen Informationen trägt. Bei nicht unterstützen Betriebssystemen ist dabei die Kreativität des Beraters gefragt.

Die Events tragen mehrere Informationen, die in Attributen sortiert sind. Eine Normalisierung der Events ist im Design der Events hinterlegt. Das heißt, dass der Systemname, das Datum und die Uhrzeit, der Meldungstext und weitere Attribute entsprechend gefüllt werden müssen. Die Verantwortung dafür liegt bei individuellen Anpassungen in der Hand des Beraters, bei vorgefertigten Lösungen in der Hand des Herstellers. Eine Basisnormalisierung für übergreifende Korrelation über mehrere Datenquellen findet nicht statt. Prinzipiell ist es möglich, eine solche Normalisierung durchzuführen, sie liegt aber in der Verantwortung des Beraters.

Die Events werden über eine HTTPS-Verbindung übertragen, dies ist über einen einzigen Port möglich. Die Events werden in der zentralen Oracle-Datenbank unverschlüsselt abgelegt. Von außen können die Daten damit abgefragt und eingesehen werden. Eine Anonymisierung oder Pseudonymisierung ist in OVOU nicht vorgesehen und könnte nur mit einem erheblichen Aufwand realisiert werden.

Ereignis-Entdeckung und ihre UnterstützungNetzwerke können über den „HP OpenView Network Node Manager“ abgebildet werden. Diese Modellierung fließt allerdings nicht in die Korrelation ein. Dies ist prinzipiell möglich, erfordert allerdings eine manuelle Leistung für den Asset-Import. OVOU kann mithilfe des Produktes „Event Correlation Designer“ einzelne Events oder Eventgruppen filtern, zusammenfassen, eskalieren, hervorheben und auch verwerfen. Damit ist OVOU in der Lage, wesentliche Ereignisse aus Millionen von Events herauszugreifen. Das Produkt kann außerdem Windows-basiert Eventlog-Informationen und ASCII-basierte Logdateien auslesen, die daraus resultierenden Events unterschiedlicher Herkunft zentral korrelieren und als Event in einer Oracle- Datenbank ablegen. Logdateien in einem anderen Format als ASCII werden zeitgesteuert in eine ASCII-Datei übersetzt und ausgewertet.

Der „Event Correlation Designer“ ist nicht Bestandteil der Lizenz und muss zusätzlich erworben werden. Ohne dieses Zusatzprodukt gibt es nur die eingeschränkte Möglichkeit, ähnliche Events miteinander zu korrelieren.

Die Kriterien, an denen OVOU erkennt, was mit den Ereignissen passieren soll, lassen sich flexibel festlegen. Events können anhand ihrer Attribute miteinander oder mit extern abgelegten Kennzeichen verglichen werden. Die Attribute können dabei mit einer Mustererkennung oder eins zu eins gegenübergestellt werden. Events können dabei auf weitere Ereignisse warten, bevor eine Aktion ausgelöst wird.

Die Korrelation erfolgt in der Regel auf dem zentralen Server ereignis- und nicht zeitgesteuert. Allerdings kann bei einer Flut an Meldungen die Abarbeitung einige Zeit dauern, da die Events dann in einer Queue gehalten werden, bevor sie weiterverarbeitet werden. Die Events werden dann aufgrund ihrer Herkunft, ihres Alters und ihres Inhalts verwertet. Dabei ist es auch möglich, die Inhalte gegen einen Schwellwert zu prüfen. Diese Prüfung erfolgt jedoch für gewöhnlich auf dem Agenten und nicht im zentralen Server und bedeutet hier einen erheblichen Aufwand. Wenn eine Korrelation erfolgreich war, kann ein weiteres Event erzeugt werden oder eine Aktion auf dem zentralen Server angestoßen werden. Die Standardaktionen beschränken sich auf die Weiterleitung von Events.


Logdatenstudie

Im Standardregelwerk wird lediglich festgelegt, wie die Events hochgezählt werden (A plus A) und das gegenseitige Löschen von Events (A löscht B) vorgenommen wird.

Vordefinierte Regelwerke zur Mustererkennung von Angriffen durch Würmer oder ähnliche Angriffe gibt es nicht. Eine Berücksichtigung der Vorgeschichte des Angreifers oder eines Opfers steht im Auslieferungszustand ebenfalls nicht zur Verfügung. Die Möglichkeit dazu bietet jedoch der „Event Correlation Designer“. Hierzu muss das Regelwerk allerdings selbst erstellt bzw. programmiert werden.

Eine Priorisierung von Vorfällen ist über die Kritikalität (Normal, Minor, Warning, Major, Critical) vorgesehen. Diese werden über die mitgelieferten Regeln vergeben und können manuell gepflegt oder bei selbst definierten Regeln vergeben werden. Sollte die zentrale Komponente nicht verfügbar sein, so werden die Events lokal in einer Queue gehalten, bis die zentrale Komponente wieder erreichbar ist. Über die Filterung nicht benötigter Ereignisse und Aggregation bereits auf dem Logsammler lässt sich die Performanz des Systems optimieren.

Benutzerinteraktion und VorfallsbearbeitungDie Benutzer greifen über eine Web-Schnittstelle oder ein Java-GUI auf den zentralen Server zu. HP OUVU kann aber auch über X-Server oder Kommandozeile vom Server aus selbst administriert werden.

Der Benutzer kann sein GUI flexibel umgestalten und Events, die einem bestimmten Muster folgen filtern. Zum Beispiel können alle Events mit einer geringeren Priorität als „Kritisch“ in der Anzeige unterdrückt werden.

Eine Recherche-Möglichkeit ist über Filter in der Konsole möglich. Die Filter beinhalten zum Beispiel das Alter und die Kritikalität des Events. Weitere Filter können manuell definiert werden.

Im zentralen System selbst kann eine Alarmierung über die folgenden Benachrichtigungsmechanismen erfolgen:

– E-Mail

– Pager/SMS

– SNMP-Trap

– Skriptausführung eines beliebigen Programms

– Ticket-System

Die Visualisierung der Alarme erfolgt über eine listenbasierte und/oder serviceorientierte Oberfläche. Eine graphische Darstellung der historischen Abfolge von Meldungen eines Ereignisses ist nicht Bestandteil von OVOU.

Reports können über OVOU selbst, das OpenView Performance Insight oder den OpenView Reporter generiert werden. Alle Tools haben eines gemeinsam: Die Standard-Reports befassen sich mit den Themen Performance und Verfügbarkeit von Applikationen, Netzwerken, Hardware und Betriebssystemen. Zumindest „HP OpenView Performance Insight“ umfasst Werkzeuge, um weitere Reports flexibel zu generieren. Dabei werden die Daten in einer eigenen Datenbank vorgehalten. Die dafür notwendigen Werkzeuge bedienen sich weitgehend den Datenbank Programmiersprachen.

Reports werden in der Grundversion von Performance Insight nicht mitgeliefert. Sie werden über sogenannte Report Packs kostenpflichtig erworben. Der Fokus und die Anzahl der Reports richtet


Logdatenstudie

sich nach dem erworbenen Report Pack. Prinzipiell können eigene Reports selbst erstellt werden, dafür stellt das Produkt einen umfangreichen Werkzeugkasten zur Verfügung.

Die Ausgabe der Reports umfasst die folgenden Formate:

– HTML

– CSV

– PDF

– SREP (eigens Format)

Die Reports können zeitgesteuert erstellt werden.

Die Benutzer können nur über Benutzername/Passwort authentifiziert werden, andere Mechanismen fehlen.

Die Benutzerdaten sind auf dem zentralen System hinterlegt. Die zugewiesenen Rechte und Rollen sind über das OVOU granular konfigurierbar. Dabei können auch Zugriffsrechte für unterschiedliche Mandaten und Benutzergruppen vergeben werden.

Unterschiedliche Sichten und Zugriffsrechte können über ein Rollenkonzept festgelegt werden. Eine revisionssichere Benutzerkontrolle ist nicht Bestandteil des Produktes.

Sicherstellung der Verfügbarkeit des SystemsDas zentrale System ist hochverfügbar auslegbar, indem zwei Systeme zu einem Cluster zusammengefasst werden. Die Daten liegen dann für gewöhnlich im SAN. Die Cluster-Software kann die Aufgabe übernehmen, die Systemkomponenten zu überwachen und bei einem Systemfehler auf auf das andere System umzuschalten. Die Aufgabe der Überwachung kann auch von dem HP OpenView Agenten übernommen werden, der unabhängig vom zentralen System auf dem gleichen System läuft. Dieser Agent kann autark reagieren, das heißt ohne eine Interaktion mit der zentralen Komponente. Die Agenten auf den zu überwachenden Systemen werden über einen Heartbeat Check kontrolliert. Somit ist gewährleistet, dass die Infrastruktur für die Überwachung jederzeit einen bekannten Status hat.

Die Agenten werden von der zentralen Komponente aus konfiguriert, dabei werden neue Patches und neue Regeln flächendeckend verteilt. Daten werden in der zentralen Oracle-Datenbank gehalten, die eigenverantwortlich zu sichern ist.

5.3.3 Microsoft System Center Operations Manager mit Audit Collection Service

Die Firma Microsoft bietet für Unternehmenskunden einige Produkte zur Verwaltung von IT-Verbünden an. Diese Produkte sind seit neuestem zur Produktsparte System Center zusammengefasst. Ihre charakteristischen Merkmale liegen naturgemäß in der engen Integration in die Microsoft-Plattform sowie in der Interoperabilität der modularen, aufeinander abgestimmten Komponenten. Der Operation Manager 2007 ist ein Kernelement der Systems Center Familie.

System Center Operation Manager (SCOM) 2007 ist für die Überwachung von Arbeitsstationen, Serversystemen und IT-Diensten positioniert. Eine Teilkomponente ist der so genannte „Audit Collection Service“ (ACS), der die im Sicherheitslog des NT-Ereignislogs erfassten Ereignisse an ein zentrales Kollektor-Komponente sendet, wo die Ereignisse bewertet und archiviert werden. Dieser


Logdatenstudie

Abschnitt beschreibt im Schwerpunkt die Frühwarnfunktionen von SCOM in Verbindung mit dem ACS.

Die System Center Produktsparte richtet sich an der IT Infrastructure Library (ITIL) bzw. an der Microsoft-Interpretation der ITIL-Empfehlungen für den IT-Betrieb aus, dem sog. Microsoft Operations Framework (MOF). Als weitere Mitglieder der System Center Produkt Familie sind der SC Configuration Manager, der SC Data Protection Manager, der SC Virtual Machine Manager, der SC Capacity Planer und der SC Service Manager zu nennen.

System Center adressiert Unternehmenskunden aller Größen. Es werden verschiedene Lizenzierungsmodelle und Leistungsumfänge angeboten, um die unterschiedlichen Anforderungen abzudecken. Für den Mittelstand gibt es speziell die Lösung System Center Essentials, welche innerhalb einer Konsole das Monitoring von IT-Diensten, Softwareverteilung und -inventarisierung sowie Patchmanagement vereint.

Der System Center Operations Manager lizensiert sich grundsätzlich wie folgt: eine Serverlizenz wird für den Management Server benötigt, zudem eine Verwaltungslizenz für jedes überwachte System. Die Komponente Audit Collection System ist als Bestandteil von SCOM in der SCOM Lizenz enthalten.

Für seine eigenen Softwarekomponenten stellt der Hersteller Microsoft die hierzu erforderlichen Regelwerke (so genannte „Management Packs“) ohne zusätzliche Lizenzkosten zur Verfügung. Für Fremdanwendungen oder Hardwarekomponenten können Regelwerke von Drittanbietern bezogen oder Eigenentwicklungen genutzt werden. Auf diese Weise bietet SCOM eine zentrale Administrationskonsole für den IT-Verbund.

Der Operations Manager wurde ursprünglich von der Firma NetIQ entwickelt und an Microsoft im Jahre 2000 lizenziert und später komplett verkauft. Seitdem entwickelt Microsoft dieses Produkt und speziell die Regelwerke als Teil ihrer System-Management Produktsparte weiter. In den „Common Engineering Criteria“ 2004 hat sich Microsoft verpflichtet, zu jedem der eigenen Produkte zeitgleich mit der Veröffentlichung ein von der jeweiligen Produktgruppe entwickeltes Regelwerk zu veröffentlichen. Aktuell finden sich ca. sechzig Regelwerke auf dem Downloadportal.

Aktuelle Version 2007Unterstützte Plattformen/Hardware-Serien Windows Server

Tabelle 53: Version und Plattformen von Microsoft MOM

Zusammenführung von Log- und MonitoringdatenDer Audit Collection Service besitzt folgende Produkt-Architektur:


Logdatenstudie

Folgende produktspezifische Begriffe werden verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler – Agent und „Audit Collection Service“ (ACS) Forwarder

– SCOM-Agent / -DienstLogkorrelator – ACS Collector / Management Server (MS)

– SCOM-ServerManagement-Komponente Management Server (MS)Logspeicher Microsoft SQL-DatenbankEreignis Event

Tabelle 54: Begriffsbestimmung bei Microsoft SCOM 2007

Über ACS-Agenten werden dezentral anfallende Meldungen aus dem Sicherheits-Windows-Eventlog der überwachten Systeme aufgegriffen und verschlüsselt an den korrespondierenden Collector-Service auf dem Management Server weitergeleitet. Auf zentraler Seite werden die Meldungen für eine spätere Analyse in einer Microsoft SQL-Datenbank komprimiert abgelegt. Ein separater SCOM-Dienst wird genutzt, wenn mehr als nur die Meldungen des Sicherheitslogs verarbeitet wer


Abbildung 5.2: Architektur von Microsoft System Center Operations Manager 2007 - ACS

Logdatenstudie

den sollen, beispielsweise Anwendungslogs oder Logdaten von separaten Nicht-Windows-Systemen.

Für die Windows-Ereignismeldungen arbeitet der ACS-Agent über die entsprechende API und ist nicht auf das Auslesen der binären Ereignisprotokollierung von Windows angewiesen. Ereignisse werden in Echtzeit mit einer Komprimierung von etwa 3:1 übertragen.

Aufgaben des ACS-Collectors liegen in der Aggregation gleichartiger Ereignisse und der Filterung unerwünschter Meldungen über entsprechende Regelwerke. Der Audit Collection Service des SCOM und seine Komponenten ermöglicht also die getrennte Sammlung und Speicherung der Windows Audit-Logdaten. Er stellt den speziell abgesicherten Zugriff dieser für forensische Zwecke meist separat und langfristig zu speichernden Informationen bereit.

Da nur aggregierte Meldungen und diese zusätzlich komprimiert gespeichert werden, ist der Platzbedarf an zentraler Seite gering. Eine Vorhaltung der Daten über einen Zeitraum von mehr als 90 Tagen ist realisierbar.

Der SCOM-Server mit Datenbank und seine SCOM-Service- bzw. -Agenten-Komponente sind für alle Ereignisse zuständig. Dafür sind Schnittstellen, über die Log- und Monitoringdaten bereitgestellt und ausgelesen werden können, sog. Provider, teilweise bereits in Windows-Betriebssystemen vorhanden und sie werden noch durch neue Provider ergänzt, die der SCOM-Agent bei Installation mitliefert. Es ist dann möglich, neben den Standard-Schnittstellen wie z.B.Windows Eventlog beispielsweise auch SNMP- oder syslog-Meldungen entfernter Datenquellen einzusammeln und hierüber Nicht-Windows-Systeme bzw. Nicht-Microsoft-Anwendungen / Komponenten in die SCOM-Gesamtarchitektur zu integrieren.

Im Gegensatz zum ACS-Agenten schickt der SCOM-Agent seine Meldungen per Default in Fünf-Minuten-Intervallen an seinen Server. Dringende Meldungen werden priorisiert übertragen. Originaldaten werden in der Regel nicht weitergeleitet oder verarbeitet.

Management Packs von Microsoft oder dritten Herstellern ermöglichen dann für jede an SCOM angeschlossene Anwendung und für jedes System eine einfache Verarbeitung der eingesammelten Meldungen.

Im SCOM werden gesammelte Log- und Monitoringmeldungen nur basis-normalisiert. Die in der Datenbank gespeicherten Meldungen können auf dieser Basis jedoch in einer späteren Berichtserstellung analysiert werden. Ziel der Basis-Normalisierung ist aufgrund des abweichenden Produktfokus nicht die Datenquellentypen übergreifende Korrelation von Ereignissen, wie sie typischerweise in Frühwarnsystemen zu finden ist.

Die gesammelten Informationen werden ab dem Agenten-Level verschlüsselt übertragen. Vertraulichkeit und Integrität sind somit gewährleistet. Der Zugriff auf die Datenbank ist über die intrinsischen Mechanismen abgesichert, die Daten werden aber nicht verschlüsselt abgelegt. Für die Sicherstellung der Verfügbarkeit sind die Agenten in der Lage lokal zwischenzuspeichern. Es sind keine Datenschutz-Mechanismen implementiert.

Ereignis-Entdeckung und ihre UnterstützungDie Frage, wie aus Millionen von Ereignismeldungen die wesentlichen herausgegriffen werden sollen, wird bei Microsoft SCOM und ACS folgendermaßen angegangen:

Die im SCOM vornehmbaren Modellierungen können an einer Sercive-orientierten Sichtweise aufgebaut werden (beispielsweise Webservice mit dahinterliegender Datenbank) oder auch an der physikalischen Struktur. Microsoft bietet zwar keine Management Packs, um Ergebnisse von Schwach


Logdatenstudie

stellen-Scannern zu integrieren und somit in die Modellierung zu integrieren, es sind aber Spezifikationen offengelegt, wie diese z.B. durch eine eigenentwickelte Lösung integriert werden können. Die modellierbaren Eigenschaften der Assets sind eher System- als Netzwerk-nah, beispielsweise kann die auf den überwachten Systemen installierte Software im SCOM hinterlegt werden.

Eine Korrelation in dem Sinne, wie sie im Rahmen der Grundlagenbetrachtungen definiert wurde, findet im ACS-Teil des Systems nicht statt, da hier ja nur eine Datenquelle betrachtet wird, sondern es werden für eintreffende Meldungen Schwellwertüberschreitungen überprüft und Mustervergleiche durchgeführt. Entsprechende Standard-Regelwerke werden mit dem Produkt mitgeliefert, sie sind anpass- und erweiterbar. Der SCOM bietet darüberhinaus die Möglichkeit auch Datenquellen übergreifend zu korrelieren. Die Vergangenheit eines Angriffs oder eines Angreifers kann nicht in die Priorisierung einfließen, da diese Größen nicht erfasst werden.

Für die Priorisierung einer Ereignismeldung wird direkt in der Korrelationsregel hinterlegt, welche Einstufung das Ereignis bei Überschreiten der Schwellwerte erhält. Weitere Priorisierungsfaktoren fließen nicht ein.

Zur Sicherstellung der Systemverfügbarkeit über die Zwischenspeicherung auf Agentenebene hinaus kann die SCOM-Lösung zusätzlich auf Management Server und Datenbank Ebene redundant ausgelegt werden.

Benutzerinteraktion und VorfallsbearbeitungFür die Administration der SCOM-Lösung stehen zwei verschiedene Benutzerkonsolen bereit. Über die Standard-MMC-Konsole mit entsprechendem Plugin steht dem Windows-Administrator eine vertraute Oberfläche für den vollwertigen Zugriff bereit. Parallel wird eine Webkonsole geboten. Beide Konsolen sind auch in Deutsch erhältlich.

Kontextabhängig können Hilfen, Aktionen und erweiterte Ansichten angesteuert werden. Eine integrierte Wissensdatenbank unterstützt bei der Fehlerbehebung, indem fehlerbezogene Hintergrundinformationen und Lösungsvorschläge angeboten werden. Die Wissensdatenbank ist um firmeninternes Wissen erweiterbar.

Als Output lässt sich folgende Reihe an Aktionen durchführen:

– Email-Benachrichtigung

– SNMP-Trap

– Alarmfenster in der Konsole

– Versenden einer SMS

– Nachrichtenerstellung für ein Ticket-System (Office Communicator, Powershell)

– Ausführen von Kommandos und Skripts (z.B. VB- J-Script, Powershell)

Der SCOM stellt eine grafische Übersicht über die aktuelle ermittelten System- und IT-Dienstzustände bereit, die dem Administrator über eine Visualisierung die Arbeit vereinfacht.

Das im SCOM implementierte Berichtswesen baut auf den SQL Reporting Services der zentral eingesetzten SQL-Datenbank auf. Somit ist eine Auswertung der oft langfristig gespeicherten Daten nahtlos umsetzbar. Über mitgelieferte Berichtsvorlagen, eigene Berichte und die Bearbeitungsmöglichkeit aller Vorlagen können zeitgesteuerte Auswertungen gefahren werden. Die Vorlagenbearbeitung kann über den sogenannten Report Builder aus der Konsole heraus erfolgen.


Logdatenstudie

Output-Formate für Berichte sind diese:

– PDF

– HTML

– TXT

– XML

– TIFF

– XLS

Die Zahl und die Inhalte der bereitstehenden Berichte sind stark abhängig von den eingesetzten Management Packs, welche meist ihre eigenen Vorlagen mitbringen. Microsoft liefert von Haus aus bereits umfangreiche Berichtvorlagen mit.

Die Sicherheit im Benutzerzugriff ist auf folgender Ebene realisiert: Für die Authentifizierung ist die SCOM-Lösung in die Microsoft-Mechanismen integriert, d.h. es wird Kerberos und NTLM unterstützt. Für die Datenbank betreffende Zugriffe wird eine separate Authentifizierung an der SQL-Datenbank durchgeführt.

Es können verschiedene Zugriffsrechte-Gruppen eingerichtet werden. Diese sind auch in der Lage, funktionelle Gruppen, z.B. Exchange-Administratoren, abzubilden. Über das ins Active Directory integrierte Berechtigungskonzept lassen sich Kombinationen aus "Rolle" und "Profil"definiert werden, wodurch ein granulares Rechtekonzept realisiert wird. Es findet keine Überwachung von Benutzeranmeldungen, aber von -aktionen statt.

Sicherstellung der Verfügbarkeit des SystemsDie Verfügbarkeit der Systemkomponenten vom SCOM, insbesondere der Agenten, wird überwacht als natürlicher Teil der Lösung. Ausfälle von Agenten oder zugrunde liegenden Systemen werden per Default registriert.

Aktuellhaltung und Verteilung von Systemkomponenten geschehen über die zentrale SCOM Konsole, sind aber auch durch bestehende Lösungen wie den Configuration Manager 2007 realisierbar.

5.3.4 Check Point „Eventia“

Die israelisch-amerikanische Firma Check Point bietet die Produktsuite Eventia, bestehend aus den Komponenten Analyzer und Reporter, an. Der Fokus des Produkts liegt auf der Echtzeit-Auswertung von Logdaten zum Zwecke der IT-Frühwarnung sowie in der Erstellung von bedarfsgesteuerten Berichten auf der Basis der gesammelten Informationen.

Diese Lösung richtet sich an Unternehmenskunden, angefangen beim Mittelstand über Großunternehmen bis hin zu Service Providern.

Der Eventia Analyzer kann dem Bereich der spezialisierten IT-Frühwarnsysteme zugeordnet werden, da hier ein produktübergreifender Ansatz zur Auswertung von Log- und Monitoringdaten verfolgt wird. Eventia Reporter ergänzt die vom Analyzer zur Verfügung gestellten Funktionen.

Daneben bietet Check Point noch den SmartView Monitor an, der für die Statusüberwachung der Check Point-Firewall-Produkte gedacht ist, sowie den SmartView Tracker, welcher die einlaufenden Logdaten der Firewalls darstellt und beispielsweise für die Fehlersuche konzipiert ist.


Logdatenstudie

Die Eventia Software wird im Wesentlichen nach der Zahl der Geräte, die Logdaten generieren, lizenziert. Zusätzlich ist ein Software-Pflege-Vertrag abzuschließen.

Der Eventia Analyzer ist seit Frühjahr 2005 am Markt verfügbar, der Reporter bereits seit Herbst 2004.

Aktuelle Version R65Unterstützte Plattformen Windows Server 2003

Windows 2000 Advanced Server (SP1, SP2, SP3, SP4)Windows 2000 Server (SP1, SP2, SP3, SP4)RedHat Enterprise Linux 3.0Check Point SecurePlatform

Tabelle 55: Version und Plattformen von Check Point Eventia

Zusammenführung von Log- und MonitoringdatenEventia Analyzer und Reporter besitzen die in der folgenden Zeichnung dargestellte Produkt-Architektur:


Logdatenstudie

Seitens Check Point Eventia werden die folgenden produktspezifischen Begriffe verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Log-ServerLogkorrelator Correlations UnitManagement-Komponente Analyzer-ServerLogspeicher MySQL-DatenbankEreignis Incident

Tabelle 56: Begriffsbestimmung bei Check Point Eventia

Der Eventia Analyzer ist spezialisiert auf die Verarbeitung von typischen Log- sowie Monitoringdaten, sofern sie per SNMP verfügbar gemacht werden.

Bedingt durch die Architektur werden Log- und Monitoringdaten auf der Komponente „Log-Server“ gesammelt und verbleiben dort. Es findet in diesem Sinne keine vollständige Zentralisierung der Originaldaten statt. Stattdessen werden im Arbeitsspeicher der Korrelationseinheiten („Correlation Unit“) aus einzelnen Logmeldungen korrelierte Ereignisse erzeugt. Nur diese werden an den zentralen Analyzer weitergeleitet und in der Datenbank abgespeichert.


Abbildung 5.3: Architektur von Check Point Eventia

Logdatenstudie

Damit findet eine Speicherung der vollständigen Originaldaten nur auf der dezentralen Ebene der Logsammler statt, zentral werden primär korrelierte Ereignisse gespeichert. Letztere enthalten aber zumindest diejenigen Original-Logmeldungen, die zur Auslösung der Ereignismeldung geführt haben.

Die Übertragung der Log- und Monitoringdaten ab dem Log-Server ist verschlüsselt, so dass die Integrität und Authentizität der übertragenen Daten gewährleistet ist.

Durch die Vor-Korrelation der Log- und Monitoringdaten auf der Correlation Unit wird verhindert, dass unerwünschte bzw. unnötige Meldungen auf zentraler Seite ankommen und diese dort zu einer Belastung der zentralen Komponenten führen.

Gleichartige Log-Meldungen können in diesem Zuge durch einer der möglichen Korrelationen zu einer einzelnen Meldung verdichtet, d. h. aggregiert werden.

Die Speicherung von Ereignissen über einen Zeitraum von mindestens 30 Tagen stellt bei geeigneter Hardware-Auswahl insofern kein Problem dar, da durch die starke Vorfilterung und Korrelation letztendlich relativ wenige Meldungen zentral gespeichert werden müssen.

Der Schwerpunkt bei den einlesbaren Datenquellen liegt bei Eventia natürlich auf den hauseigenen Produkten. Von den in der Übersicht der Formate aufgelisteten Datenquellen-Typen werden folgende nicht unterstützt:

– Exim

– Postfix

– Qmail

– Alle Schwachstellen-Scanner

– F-Secure

– Microsoft IIS

– Microsoft ISA

– Bluecoat SG

– NetCache

– SC Webwasher

– ISC Bind

– SpamAssassin

– ClamAV

– Samba

– Asterisk

– Tomcat

Über die Liste hinausgehend werden außer Check Point-Produkten noch vier Fremd-Produkte unterstützt.

Eine generische Unterstützung für Syslog- und SNMP-basierte Datenquellen ist gegeben. Die vollständige Liste der unterstützten Datenquellen ist unter der folgenden URL zu finden:

http://www.checkpoint.com/products/home_promo/popups/eventia_2005.html


http://www.checkpoint.com/products/home_promo/popups/eventia_2005.html

Logdatenstudie

Eine Möglichkeit, offiziell nicht unterstützte Datenquellen durch das Schreiben eines eigenen Parsers hinzuzufügen, besteht bisher nicht. Die Offenlegung einer entsprechenden Schnittstelle ist in Planung.

Der Eventia Analyzer nimmt während der Korrelation von einzelnen Logmeldungen zu einer neuen Ereignis-Meldung auch eine Normalisierung vor: die Felder der neu zu generierenden Ereignismeldung werden im Check Point-Standard-Format, das bereits aus dem Firewall-Bereich bekannt ist, befüllt. Die notwendigen Daten werden dabei vom Parser in die entsprechenden Felder geschrieben. Dabei werden unter anderem auch die originalen Meldungsdaten in ein hierfür vorgesehenes Feld geschrieben, so dass die zugrunde liegenden Original-Informationen einsehbar sind. Die Original-Logdaten werden aber nicht normalisiert.

Die Sicherheit der Log- und Monitoringdaten gewährleistet Eventia durch die bereits erwähnte verschlüsselte Übertragung und die Speicherung in einer gehärteten MySQL-Datenbank. Innerhalb der Datenbank liegen die Informationen aber unverschlüsselt und nicht signiert vor. Es gibt bisher keine Mechanismen – beispielsweise durch das Verschleiern von Feldern mit Benutzernamen – den Datenschutz zu gewährleisten.

Ereignis-Entdeckung und ihre UnterstützungDie Frage, wie aus Millionen Ereignismeldungen die wesentlichen herausgegriffen werden sollen, geht Check Point bei Eventia folgendermaßen an:

Der Bereich der Modellierung ist in Eventia nur rudimentär ausgebaut. Typischerweise liest Eventia die Objektdatenbank des Firewall-Managements ein und übernimmt diese. Dort hinterlegte Netze und IP-Adressen werden in Eventia somit weiterverwendet.

Das Programm bietet aber keine Möglichkeit, darüber hinausgehende Informationen über die basismodellierten Größen zu hinterlegen. Folglich können besondere Rechner oder Netze – beispielsweise „gesprächige“ Netzwerk-Management-Server oder Schwachstellen-Scanner – nicht mit ihrer Rolle hinterlegt werden und geschäftskritische Server oder Applikationen nicht als besonders wichtig gekennzeichnet werden.

Außerdem können die Ergebnisse von Schwachstellen-Scannern in Eventia nicht importiert werden – weder für eine Anlage von neuen Assets, noch für eine Verwertung der gefundenen Verwundbarkeitsinformationen.

Die Korrelation der auf den Korrelationseinheiten fortlaufend ankommenden Meldungen wird fortwährend und quasi in Echtzeit im Arbeitsspeicher der Server durchgeführt.

Für die Korrelation der Meldungen liefert Check Point mit dem Produkt eine Reihe von Standardregeln aus. Diese können über automatische Aktualisierungsvorgänge auf den neuesten Stand gebracht und erweitert werden. Darüber hinaus können auch eigene Regeln definiert bzw. bestehende Regeln angepasst werden.

In den Korrelationsregeln selbst besteht die Möglichkeit, Eigenschaften von Logmeldungen abzufragen, Schwellwertüberschreitungen zu überprüfen und zwei oder mehr Meldungen miteinander zu verknüpfen. Ferner können die Abfragen über die üblichen logischen Bedingungen inkl. Negation miteinander verbunden werden. Die Korrelation erfolgt über alle berichtenden Datenquellen hinweg.

Für die Erkennung von Angriffen kann auf eine generische und auf eine konkrete Mustererkennung zurückgegriffen werden. Eine eventuell vorliegende Vorgeschichte eines Angreifers oder eines Angriffs kann nicht berücksichtigt werden.


Logdatenstudie

Als Korrelationsergebnisse können außer der Generierung einer Ereignismeldung selbst folgende Aktionen ausgeführt werden:

– Versenden einer E-Mail

– Ausführen eines frei konfigurierbaren Skripts

– Blocken des Angreifers mithilfe einer Check Point-Firewall

Für die Priorisierung von Ereignissen sind in Eventia fünf Stufen vorgesehen. Dabei wird die Priorisierung als direktes Ergebnis einer Korrelationsregel definiert, weitere Informationen als die in der Regel abgefragten Bedingungen können mangels Modellierung nicht berücksichtigt werden. Die Priorisierung ist in Eventia somit nur ein halbautomatischer Vorgang.

Die Verfügbarkeit der Ereignis-Entdeckung durch Eventia ist in erster Linie durch die starke Vorfilterung der eintreffenden Log-Meldungen sichergestellt. Nur ein geringer Bruchteil der Informationen muss zentral verarbeitet und gespeichert werden. Spitzenlasten werden vom Eventia Analyzer in erster Linie durch eine relativ geringe Durchschnittsauslastung der Systeme bewältigt, aber nicht durch das temporäre Zwischenspeichern von Meldungen auf dezentralen Komponenten, um zentrale Einheiten zu entlasten – dieses Konzept ist nicht berücksichtigt.

Benutzerinteraktion und VorfallsbearbeitungFür die tägliche Arbeit mit dem Eventia-System steht in erster Linie ein eigenes proprietäres Benutzerprogramm zur Verfügung. Dieses bietet dem mit Check Point-Produkten arbeitenden Administrator ein gewohntes Umfeld. Andere Benutzeroberflächen kommen nur bei der Installation oder Produktpflege-Vorgängen ins Spiel (Kommandozeile oder Weboberfläche).

Für die Recherchen innerhalb der Echtzeit-Darstellung von Ereignissen und aufgrund von gemeldeten Frühwarnungen stehen kontextbasierte Hilfen und Informationen zur Verfügung. Die Möglichkeit, innerhalb der angezeigten Meldungen Filter zu setzen, steht ebenfalls zur Verfügung.

Außer den bereits genannten Aktionen als Ergebnis einer Korrelation stehen wenige weitere Standard-Möglichkeiten der Aktion/Reaktion zur Verfügung. Es existieren keine Schnittstellen zu Ticketing-Systemen, es können keine SNMP-Traps verschickt werden.

Mehr als 25 Berichtsvorlagen werden bei Eventia von Haus aus mitgeliefert. Hieraus erstellte Berichte umfassen vor allem technische Aussagen. Sie können automatisch generiert und in HTML und MHT dargestellt werden. Außerdem können eigene Berichtsvorlagen erstellt und bestehende angepasst werden.

Für die Benutzerauthentifizierung stehen folgende Authentifizierungsmechanismen zur Verfügung:

– Benutzername/Passwort

– Zertifikatsbasierte Authentifizierung

– SecurID

– RADIUS

– TACACS

Die Authentifizierung wird ergänzt um die notwendige Freischaltung von IP-Adressen, denen der Zugriff auf das Eventia-System gestattet sein soll.


Logdatenstudie

Benutzerrechte werden innerhalb des Produkts definiert und auf Gruppen-Ebene zugewiesen. Zugriffe durch Benutzer werden mitprotokolliert. Zugriffsrechte können allerdings nicht datenbezogen erteilt oder entzogen werden. Es existiert mithin kein durchgängiges rollenbasiertes Rechtekonzept, das insbesondere den Datenschutz gewährleisten könnte.

Sicherstellung der Verfügbarkeit des SystemsFür die Verfügbarkeit des Eventia-Systems selbst steht ein eingebauter Monitor zur Verfügung, der die Erreichbarkeit der diversen Komponenten überwacht und aufzeigen kann.

Eine Produktpflege im Betrieb erfolgt nur teilweise automatisiert. Wesentliche Teile der Aktualisierung der Software müssen manuell durchgeführt werden.

5.3.5 Quest „Intrust“

Das Unternehmen Quest Software, Inc. bietet Produkte zur Verbesserung der Performance von Anwendungen, Datenbanken und Windows-Infrastrukturen.

Das weltweit agierende Unternehmen mit rund 3.000 Mitarbeitern bietet innerhalb seines Produkt-Portfolios Lösungen zur Sammlung, Analyse und langfristigen Speicherung von Log-Daten an.

Quest InTrust und Reporter sind speziell im Hinblick auf die IT-Sicherheit entwickelt worden. Ein weiteres Quest-Produkt ist Foglight, hiermit können Applikationen zur Sicherstellung der Verfügbarkeit überwacht werden.

InTrust adressiert die Aufzeichnung von Systemereignissen angeschlossener Systeme und gewährleistet dadurch die Nachverfolgbarkeit von Veränderungen.

Reporter wiederum sammelt Konfigurationsinformationen und gleicht diese mit konfigurierbaren Sollwerten ab. Im Folgenden werden nur die Funktionen von InTrust näher betrachtet.

InTrust richtet sich in erster Linie an mittlere und große IT-Netzwerke im Unternehmensumfeld. Der Fokus richtet sich vor allem auf Windows- und Unix-Umgebungen, weniger auf Netzwerk- oder Sicherheitsgeräte. In seinem Bereich eingesetzt, analysiert InTrust fortwährend die eingehenden Log- und Monitoringdaten, alarmiert bei auftretenden Vorfällen und archiviert die Daten für langfristige Zwecke, insbesondere zur Einhaltung von Compliance-Vorschriften.

Mit der Produktfamilie InTrust wird in eigenständigen Event-Logdateien eine detaillierte Protokollierung der Aktivitäten des überwachten Microsoft Active Directory erstellt. InTrust ist als Log Consolidator entwickelt worden, das heißt, die Event-Log_Dateien der angeschlossenen Server-Plattformen werden automatisiert gesammelt und kostengünstig abgespeichert. Die Dateisystem-basierte Lösung von InTrust ist ausgelegt für die langfristige Archivierung großer Datenmengen. Des Weiteren besteht die Möglichkeit, auf Basis dieser Daten entsprechende Berichte über die aktuelle Lage der IT-Sicherheit zu erstellen: InTrust besitzt umfangreiche Berichtsfunktionen, um gesuchte Informationen aus den gesammelten Daten zu extrahieren.

Aktuelle Version 9.5Unterstützte Plattformen Windows Server

Tabelle 57: Version und Plattformen von Quest Intrust


Logdatenstudie

Zusammenführung von Log- und MonitoringdatenQuest Intrust besitzt folgende Produktarchitektur:

Seitens des Herstellers Quest werden die folgenden produktspezifischen Begriffe verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Intrust Agenten / Plugins für Windows, Windows-Applika

tionen, Exchange, Unix, Linux und weitereLogkorrelator Intrust AgentenManagement-Komponente Intrust KonsolenLogspeicher Microsoft SQL-DatenbankenEreignis Event

Tabelle 58: Begriffsbestimmung bei Quest Intrust

Die Log- und Monitoringdaten werden auf einem zentralen Server, dem Repository-Server, gesammelt und gespeichert.

Die Daten relativ weniger Datenquellentypen werden verarbeitet. Es gibt Schnittstellen für generisches Syslog und SNMP. Außer den Standard-Betriebssystemen werden die Logdaten folgender Applikationen eingelesen:

– Microsoft IIS

– Microsoft ISA

– Microsoft Exchange Server

– Microsoft SQL


Abbildung 5.4: Architektur von Quest Intrust

Logdatenstudie

– Oracle 9 und aktueller

– Dokumenten-Änderungen bei Excel- und Word-Dokumenten

– Cisco Routers

– Cisco PIX

– Check Point VPN-1

– TXT logs

Es wird kein Parser für nicht bekannte Datenquellen bereitgestellt. Als generische Schnittstelle gibt es einen WMI-Skript-Parser, mit dem neue Datenformate dem System bekannt gemacht werden können.

Die Original-Log- und -Monitoringdaten werden mitübertragen und im zentralen Repository langfristig abgespeichert. Eine typische Speicherdauer ist sechs Monate.

Für die kurzfristige oder in Echtzeit erfolgende, fortlaufende Auswertung der Daten werden diese in eine zweite, separate Datenbank eingelesen. Diese wird als Audit-Datenbank bezeichnet.

Eine Aggregation gleichartiger Logmeldungen wird von den Agenten nicht durchgeführt.

Es findet keine Normalisierung der Log- und Monitoringdaten statt, weder zentral noch auf Agenten-Ebene. Aufgrund der relativ geringen Anzahl an unterstützten Datenquellentypen wäre die Schaffung einer solchen Meta-Ebene zu aufwändig.

Die Agenten können dazu verwendet werden, die einzulesenden Daten bezüglich ihrer Relevanz vorzufiltern. Des Weiteren sind sie verantwortlich für eine verschlüsselte und komprimierte Übertragung in die zentralen Datenbanken.

Sie besitzen des Weiteren eine Caching-Vorrichtung, um Logdaten zwischenzuspeichern, falls diese temporär nicht an die zentralen Datenbanken übertragen werden können.

Es gibt keinen Mechanismus, um innerhalb der gesammelten Datenmenge den Datenschutz speziell adressieren zu können.

Ereignis-Entdeckung und ihre UnterstützungUm wesentliche Ereignisse aus Millionen Logs herausgreifen, besitzt Quest Intrust folgende Basisfunktionen.

Zur Modellierung des Netzwerks können grundlegende Eigenschaften von Rechnern hinterlegt werden, nämlich Windows Active Directory Domain und IP-Adressinformationen. Dies geschieht im Wesentlichen manuell.

Darüber hinaus gibt es zum Zweck der Modellierung keine Schnittstellen zu Drittsystemen wie Schwachstellen-Scannern, wodurch Assets weder automatisch angelegt werden können, noch Schwachstellen-Informationen oder Aussagen über die Relevanz der berücksichtigten Systeme hinterlegt werden können.

Für die Korrelation von Ereignismeldungen werden entsprechende Konfigurationen auf die Agenten gebunden und dort umgesetzt. Somit erfolgt keine Datenquellen übergreifende Korrelation an zentraler Stelle. Die Umsetzung erfolgt aber fortlaufend in Echtzeit.

Die Korrelationsfunktionen überprüfen Schwellwert-Überschreitungen und das zu häufige Auftreten von einzelnen Ereignismeldungen.


Logdatenstudie

Intrust ist darüber hinausgehend nicht in der Lage, generische Korrelationen durchzuführen. Vielmehr werden die Logmeldungen analysiert, indem die einzelnen Meldungen interpretiert und einer Überprüfung unterzogen werden, ob diese Meldungen zu oft auftreten bzw. gar nicht auftreten dürften. Dies entspricht von der Herangehensweise einem Mustervergleich.

Mit dem Erwerb weiterer sog. Plug-ins erweitert man das Verständnis für das Logging weiterer Komponenten, wie z. B. Microsoft Exchange.

Intrust erkennt somit keine generischen Muster, sondern ausschließlich applikationsspezifische Muster. Ein entsprechend arbeitendes Grund-Regelwerk wird mitgeliefert.

Aufgrund einer fehlenden Modellierung können durch Korrelationsregeln Aspekte wie Vorgeschichte von Angreifer oder Opfer nicht berücksichtigt werden.

Priorisierungen werden als Teil einer Korrelationsregel hinterlegt und sind nicht Ergebnis eines Algorithmus.

Um die System-Performance zu gewährleisten, ist eine Lastverteilung der Aufgaben vorgesehen. Die Korrelationen finden dezentral auf den Agenten statt. Eine in den Agenten implementierte Caching-Funktion sichert die Übertragung der Logdaten auch bei temporärem Netzwerkausfall oder Nichterreichbarkeit der Datenbanken.

Benutzerinteraktion und VorfallsbearbeitungIntrust bietet zwei getrennte Benutzeroberflächen: ein MMC-Snapin stellt die eigentliche Administrationsoberfläche der Intrust-Lösung bereit, eine Weboberfläche stellt die auflaufenden Alarme dar. Es gibt keine integrierten Recherche-Möglichkeiten, um auf aktuelle Vorfälle reagieren zu können, eine kontextabhängige Benutzerhilfe existiert ebenfalls nicht.

Für Alarmierungen und allgemeine Meldungen stehen folgende Mechanismen zur Verfügung:

– E-Mail

– Alarm in der Konsole

– SNMP-Traps

– XML-Ausgabe

– Ausführen eines Skripts

– Erzeugung eines in der Datenbank gespeicherten Ereignisses

Angriffe werden in keiner der Benutzeroberflächen visualisiert.

Für das Berichtswesen stehen applikations- und Compliance-spezifische Vorlagen zur Verfügung. Daraus resultierende Berichte können automatisiert generiert werden. Für diese Berichte stehen folgende Formate zur Verfügung:

– PDF

– TXT

– HTML

– XML

– XLS

– Webarchiv


Logdatenstudie

– TIFF

– CSV

Administratoren von Quest Intrust authentifizieren sich über Windows Active Directory am System. Benutzerrechte lassen sich auf der Ebene der Berichte setzen sowie für den Zugriff auf archivierte Daten. Damit ist ein rollenbasiertes Konzept für den Datenschutz umsetzbar. Es findet kein Auditierung der Benutzeraktionen statt.

Sicherstellung der Verfügbarkeit des SystemsIntrust sieht eine fortlaufende Überwachung der eigenen Systemkomponenten über mitgelieferte Korrelationsregeln vor.

Das Repository als reines Dateisystem kann über normale Backup-Mechanismen versorgt werden. Die Audit-Datenbank wird über mitgelieferte Skripte regelmäßig von alten Logmeldungen bereinigt, weitere Tätigkeiten müssen zurzeit noch manuell durchgeführt werden.

5.3.6 Attachmate „NetIQ Security Manager“

Die amerikanische Firma Attachmate und ihr kürzlich erworbener Geschäftsbereich NetIQ bieten das Produkt „Security Manager“ an. Dieses ist Teil der von NetIQ angebotenen Produktreihe für betriebsunterstützende System-Management-Lösungen und ein zentrales IT-Sicherheitsmanagement.

Das Produkt richtet sich an Unternehmenskunden, angefangen beim Mittelstand über Großunternehmen bis hin zu Service Providern.

Der Security Manager kann dem Bereich der IT-Frühwarnung zugeordnet werden, da er einen produktübergreifenden, sicherheitsorientierten Ansatz für die Auswertung der Log- und Monitoringdaten umfasst und die Daten in Echtzeit verarbeitet.

Ergänzende Produkte von NetIQ sind der sog. „Secure Configuration Manager“, der die Gültigkeit umgesetzter Systemkonfigurationen gegen bestehende Sicherheitsrichtlinien überprüft, sowie der sog. „AppManager“, welcher eine nicht primär sicherheitsrelevante Systemüberwachung ermöglicht.

Der Security Manager wird nach der Zahl der Geräte, deren Log- und Monitoringdaten ausgewertet werden, lizensiert. Es ist zusätzlich ein Softwarepflege-Vertrag abzuschließen.

Das Produkt hat eine Entwicklung von etwa zehn Jahren hinter sich, inklusive früher Anfänge als Insellösung im Bankenumfeld.

Aktuelle Version 6.0Unterstützte Plattformen/Hardware-Serien Windows Server 2003

Tabelle 59: Version und Plattformen von Attachmate NetIQ

Zusammenführung von Log- und MonitoringdatenDer NetIQ Security Manager besitzt folgende Architektur:


Logdatenstudie

Folgende produktspezifische Begriffe werden von NetIQ verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Agent für Windows, Unix und iSeriesLogkorrelator Central ComputerManagement-Komponente Central ComputerLogspeicher Microsoft SQL-DatenbankEreignis Incident

Tabelle 60: Begriffsbestimmung bei Attachmate NetIQ

Der Security Manager ist auf die Korrelation und Speicherung von Log- und Monitoringdaten aus Unternehmensnetzwerken spezialisiert.

Die Daten werden hierzu am Central Computer gesammelt und korreliert. Es stehen verschiedene Speichersysteme zur Verfügung, die vom Central Computer je nach Verwendungszweck benutzt werden:

– Für die Echtzeit-Korrelation steht ein Microsoft SQL-Datenbank-Server bereit.

– Für die Langzeitarchivierung von Daten stehen ein oder mehrere sog. „Log Archive Server“ zur Verfügung.

– Auf diese wird auch für das Berichtswesen zurückgegriffen, wenn Daten zur Berichtserstellung ausgewertet werden müssen.


Abbildung 5.5: Architektur von Attachmate NetIQ

Central Computer (one or more)

Windows / ADAntivirus / HIDS

(with agents)

Windows / ADAntivirus / HIDS

(with agents)

Firewalls, Routers, Switches (agentless)

Firewalls, Routers, Switches (agentless)

Unix / Linux(with agents)

Unix / Linux(with agents)

iSeries(with agent)iSeries

(with agent)

Windows Agent(proxy)

Windows Agent(proxy)

Windows / AD(agentless)

Windows / AD(agentless)

ReportingServer(OLAP)

OLAPCube

ReportingServer(OLAP)

OLAPCubeOLAPCube

Network IDS / IPS(agentless)

Log Archive Server

(one or more)

Log Archive Server

(one or more)

Unix / Linux(agentless)

Unix / Linux(agentless)

Unix / Linux Agent(proxy)

Unix / Linux Agent(proxy) Real Time DB

Server (MS SQL)

Logdatenstudie

Die Log- und Monitoringdaten können je nach Art der Daten über einen von zwei Wegen an die zentrale Instanz gelangen. Zum einen kann der notwendige Agent direkt auf dem Datenquellensystem installiert werden, zum anderen kann ein der Agent auch im sog. Proxy-Modus auf einem dedizierten System betrieben werden, wo er als Logsammler über Netzwerkprotokolle Daten abruft bzw. empfängt, so dass die eigentlichen Datenquellensysteme in dieser Variante agentenfrei bleiben.

Durch den jeweiligen Agenten werden die Daten normalisiert und zusammen mit den Originaldaten zur zentralen Instanz übertragen, wo sie vollständig archiviert werden können.

Zusätzlich zur Normalisierung nimmt der Agent ggf. auch eine Filterung und eine Aggregation der Daten vor.

Bei entsprechender Auslegung der Datenbank können die Daten für eine zeitnahe Auswertung einige Tage bis hin zu einigen Wochen in der Datenbank vorgehalten werden, langfristig werden sie dort aber gelöscht und nur noch im Archiv gespeichert.

Der Schwerpunkt bei den einlesbaren Datenquellen liegt beim Security Manager bei den Betriebssystemen und Applikationen. Von den in der Übersicht der Formate aufgelisteten Datenquellen-Typen werden folgende nicht unterstützt:

– Tipping Point IPS

– McAfee IntruShield

– Squid

– Netcache

– Bluecoat SG

– SecureComputing WW

– ISC Bind

– Apache

– alle E-Mail-Server

– SpamAssassin

– F-Secure

– Samba

– Asterisk

– Tomcat

– Alle Schwachstellen-Scanner

Über die Liste hinausgehend unterstützt der Security Manager noch etwa zehn weitere Produkte.

Generische Unterstützung für Syslog- und SNMP-basierte Datenquellen ist ebenfalls gegeben. Die vollständige Liste der unterstützten Datenquellen ist unter folgender URL im Internet zu finden:

http://www.netiq.com/products/sm/default.asp?id=SystemsSupported

Für nicht unterstützte Datenquellen besteht die Möglichkeit, einen Normalisierungs-Parser zu schreiben. Der Parser wird hier als „Meta-Data Map“ bezeichnet und in XML geschrieben. Beispiele, wie dies zu geschehen hat, sind anhand der unterstützten Datenquellen vorhanden und instruktiv.


http://www.netiq.com/products/sm/default.asp?id=SystemsSupported

Logdatenstudie

Die Normalisierung der Daten führt beim Security Manager zu einem standardisierten Format, dem IDMEF (Intrusion Detection Message Exchange Format).

Die Daten werden ab dem Agenten verschlüsselt transferiert, wobei ein „Cylink Mek“-Algorithmus mit einer Schlüssellänge von 56 bit verwendet wird. Anschließend werden sie signiert auf den zentralen Instanzen hinterlegt. Dies geschieht datenbezogen auf dem Central Computer und partitionsbezogen auf den Log Archive Servern. Optional kann die Datenverbindung zwischen Agent und Central Computer auch authentifiziert werden.

Die Vertraulichkeit von benutzerbezogenen Daten wird umgesetzt über ein Zugriffsrechte-System, das die Sichtbarkeit von datenschutzrelevanten Inhalten auf autorisierte Benutzerkreise einschränkt. Sensible Daten können in Berichten aber auch vollständig ausgeblendet werden.

Ereignis-Entdeckung und ihre UnterstützungDie Fragestellung, wie wesentliche Ereignisse aus Millionen von Logs herauszugreifen sind, wird beim NetIQ Security Manager folgendermaßen angegangen:

Möglichkeiten zur Modellierung bietet das Produkt nicht an. Lediglich durch entsprechende Filter kann der betrachtete Kreis von Logdaten eingeschränkt werden. Es existieren keine Schnittstellen zu Konfigurationsdatenbanken. Netzwerke und Assets können im System nicht hinterlegt werden.

Ebenso können die Ergebnisse von Schwachstellen-Scannern nicht in den Security Manager importiert werden – weder für eine Anlage von neuen Assets, noch für eine Verwertung der gefundenen Schwachstelleninformationen.

Besondere Rechner oder Netze, beispielsweise gesprächige Netzwerk-Management-Server oder Schwachstellen-Scanner, können mit ihrer Rolle nicht hinterlegt werden, geschäftskritische Server oder Applikationen können nicht als besonders wichtig gekennzeichnet werden.

Die Korrelation der auf dem Central Computer fortlaufend ankommenden Meldungen wird fortwährend und quasi in Echtzeit im Arbeitsspeicher des Servers durchgeführt.

Für Korrelationsfunktionen ist in NetIQ zunächst ein editierbarer Satz von Standardregeln enthalten. Neue Regeln können ebenfalls hinzugefügt werden. In den Korrelationsregeln selbst besteht die Möglichkeit, Eigenschaften der normalisierten Logmeldungen abzufragen, Schwellwertüberschreitungen zu überprüfen und zwei oder mehr Meldungen miteinander zu verknüpfen. Die Abfragen können über die üblichen logischen Bedingungen inkl. Negation und konditionalen Abfragen miteinander verbunden werden. Die Korrelation erfolgt über alle berichtenden Datenquellen hinweg.

Als Ergebnis einer Korrelation kann zurzeit nur ein Alarm ausgelöst werden.

Über Korrelationen, wie sie der Security Manager anbietet, können generische Muster, beispielsweise eine Wurmausbreitung, erkannt werden. Spezifische Muster werden nicht abgefragt. Diese Möglichkeit bieten nur die zuliefernden Datenquellen wie Virenschutzsysteme oder IDS/IPS.

Es existieren nur rudimentäre Priorisierungsmöglichkeiten. Ziel der Arbeit in diesem Produkt ist es, möglichst exakt zutreffende Korrelationen ohne False Positives zu erzeugen. Dabei muss auf präzisierende Informationen aus Schwachstellen-Scannern oder Relevanzbewertungen von Assets verzichtet werden. Im Wesentlichen stehen hierfür Filterabfragen zur Verfügung.

Es gibt keinen Priorisierungsalgorithmus, die Konfiguration der Priorisierung erfolgt manuell.

Die Verfügbarkeit der Ereignis-Entdeckung durch den Security Manager ist durch eine Filterung der eintreffenden Logmeldungen und die verteilte Architektur sichergestellt. Die Normalisierung


Logdatenstudie

findet auf den Agenten statt, so dass sich der Central Computer auf die Korrelationen konzentrieren kann. Auch das Berichtswesen ist ausgelagert. Das Produkt kann ferner hochverfügbar ausgelegt werden. Die Agenten sind in der Lage, Logdaten vorübergehend zwischenzuspeichern, falls die Verbindung zum Central Computer ausfallen sollte.

Benutzerinteraktion und VorfallsbearbeitungFür die tägliche Arbeit mit dem Security Manager steht neben einer Weboberfläche ein proprietäres Benutzerprogramm zur Verfügung, das sog. Control Center. Des Weiteren gibt es eine sog. Development-Konsole. Die zu erledigenden Aufgaben verteilen sich wie folgt auf die einzelnen Oberflächen:

– Weboberfläche: Berichtswesen

– Monitor Console: Echtzeit-Status-Überwachung

– Control Center: zentrale Auswertungen der Log- und Monitoringdaten

– Development-Konsole: Bearbeitung und Erstellung von Korrelationsregeln

Kontextmenüs und kontextabhängige Hilfestellungen erleichtern dem Benutzer die Arbeit im System.

Für die Visualisierung stehen Kuchendiagramme und ähnliche grafische Darstellungsmöglichkeiten bereit. Angriffe werden nicht grafisch visualisiert.

Ergebnisse der Datenauswertung und Recherchen können in benachbarte Systeme für die Fallbearbeitung und das Ticketing überführt werden. Die Alarmierungsfunktionen werden dahingehend konfiguriert.

Das Berichtswesen stellt Vorlagen für das Management (ohne Erweiterungsmodule ca. fünf Vorlagen) und das technische Personal (ohne Erweiterungsmodule ca. 30 Vorlagen) bereit. Diese sind applikationsspezifisch geordnet. Ein weiterer Schwerpunkt sind hier forensische Analysen mithilfe von Berichtsabfragen. Eigene Berichte können erstellt, und bestehende können angepasst werden.

Berichte können automatisch erstellt und als

– HTML-,

– PDF-,

– XML-,

– TXT-,

– XLS- und

– CSV-Datei

ausgeliefert werden.

Für die Benutzerauthentifizierung steht die Windows-Authentifizierung auf der Basis von globalen Gruppen zur Verfügung.

Es gibt keine Accounting-Funktion, die alle durchgeführten Benutzeraktionen aufzeichnen würde. Es sind verschiedene Autorisierungs-Levels einstellbar, durch die der getrennte Zugriff auf Datenbestände umgesetzt werden kann.


Logdatenstudie

Sicherstellung der Verfügbarkeit des SystemsDer Security Manager stellt über die Monitor Console eine Statusüberwachung der eigenen Komponenten bereit. Hierüber kann auch die Performance der Komponenten kontrolliert werden. Des Weiteren können alle Komponenten des Security Managers zentral aktualisiert werden.

Die Datenbank wird automatisch vom System verwaltet, insbesondere auch die veralteten Daten werden automatisch gelöscht.

5.3.7 Flowerfire „Sawmill“

Der aus Großbritannien stammende Hersteller Flowerfire bietet mit seinem Produkt Sawmill eine weitere Lösung zur Verarbeitung von Log- und Monitoringdaten an. Der Fokus des Produktes liegt auf der zentralen Speicherung und nachträglichen Auswertung von Meldungen unterschiedlichster Datenquellen. Über ein standardisierte Berichtsfunktionen können die Meldungen analysiert und ausgegeben werden.

Bei Sawmill handelt sich allerdings weniger um ein IT-Frühwarnsystem mit einer Datenverarbeitung, die quasi in Echtzeit erfolgt, als vielmehr um ein Werkzeug zur Auswertung der Daten im Nachgang der Datenspeicherung. Damit kann es der Kategorie des Security Information Managements mit spezialisiertem Funktionsumfang zugeordnet werden.

Im Fokus des Herstellers liegen einzelne Benutzer, mittelständische Betriebe und Großunternehmen.

Neben der Lösung Sawmill hat bietet der Hersteller keine weiteren Produkte an.

Sawmill wird nach der Anzahl der einzubindenden Datenquellen lizenziert. Angefangen von einer Lizenz für eine Datenquelle erstreckt sich die Lizensierung bis hin zu 10.000 oder mehr Datenquellen.

Die folgende Tabelle bietet einen Überblick über die aktuelle Version von Sawmill sowie die vom Programm unterstützten Plattformen:

Aktuelle Version 7.2.9Unterstützte Plattformen/Hardware-Serien Windows 95 - 2003

MacOSs X 10.2 – 10.4Red Hat 7 – 9Red Hat Enterprise Server 1 – 4Sun Solaris 8 – 10FreeBSDOpenBSD 3.8

Tabelle 61: Version und Plattformen von Flowerfire Sawmill

Zusammenführung von Log- und MonitoringdatenBei der Lösung sind alle Meldungen am Sawmill Server zu zentralisieren, um die Auswertung vornehmen zu können.

Eine verteilte Architektur, wie sie von vielen Herstellern in diesem Bereich konzipiert ist, besteht bei Sawmill nicht. Die Management-Komponente wird auf einem Server installiert und besteht im Wesentlichen aus einem Webserver, einer Datenbank (MySQL) und dem Modul zur Auswertung


Logdatenstudie

der einlaufenden Meldungen. Die Verbindung zum Webserver erfolgt über das Protokoll HTTP im Klartext. Verbietet die Sicherheitsrichtlinie des Unternehmens die Kommunikation in Klartext oder ist bereits ein Webserver auf einem adäquaten Server vorhanden, kann Sawmill auch als CGI-Programm installiert werden. In diesem Fall kann die Verbindung zu Sawmill auch per HTTPS verschlüsselt stattfinden.

In Sawmill werden die folgenden produktspezifischen Begriffe verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler ProfileLogkorrelator FilterManagement-Komponente Sawmill-ServerLogspeicher MySQL-DatabaseEreignis Report

Tabelle 62: Begriffsbestimmung bei Flowerfire Sawmill

Sawmill verarbeitet sowohl Log- als auch Monitoringdaten zahlreicher Datenquellen und Formate. Dabei werden alle originalen Daten an Sawmill übertragen und in Profilen innerhalb der zentralen Datenbank gespeichert. Sie stehen dann für die Auswertung der einzelnen Datenquellen zur Verfügung.

Die Vorfilterung von nicht benötigten Meldungen ist ebenfalls möglich. Allerdings geschieht dies aufgrund der zentralen Architektur erst auf der Management-Komponente. Sie bezieht sich auf alle Bereiche einer Meldung und kann über den Namen, Wildcards oder reguläre Ausdrücke vorgenommen werden.

Die Zusammenfassung gleichartiger Meldungen zu einer Meldung ist nicht Bestandteil der Lösung.

Ob Meldungen über Zeiträume von mehr als 30 Tagen gespeichert werden können, ist abhängig von dem zur Verfügung stehenden lokalen Speicherplatz.

Sawmill unterstützt eine hohe Anzahl von unterschiedlichen Datenquellen aus dem Bereich der Log- und Monitoringdaten. Von den in der Übersicht der Formate aufgelisteten Datenquellen-Typen werden folgende nicht unterstützt:

– IPFIX

– McAfee IntruShield

– Asterisk

– McAfee Virusscan

– QualysGuard

– McAfee Foundstone

Neben den beschriebenen Formaten unterstützt Sawmill ca. 700 weitere. Eine vollständige Liste aller Formate, die unterstützt werden ist unter folgendem Link ohne Registrierung zugänglich:

http://www.sawmill.co.uk/manual.html

Ein Rahmenwerk zur herstellerunabhängigen Einbindung weiterer Datenquellen ist kostenlos verfügbar und bereits im Auslieferungszustand enthalten.


http://www.sawmill.co.uk/manual.html

Logdatenstudie

Sawmill wertet alle Datenquellen ohne Normalisierung aus. Somit steht kein unabhängiges Format zur Korrelation von unterschiedlichen Datenquellen bereit.

Die Sicherheit bei der Übertragung hängt von der Datenquelle ab und ist durch die zentrale Architektur limitiert. Alle Meldungen werden weder signiert noch verschlüsselt in der zentralen Datenbank abgelegt. Eine Anonymisierung oder Pseudonymisierung von Meldungen ist nicht Bestandteil der Lösung.

Ereignis-Entdeckung und ihre UnterstützungInnerhalb der Lösung ist es nicht möglich, die Netzwerk- und Systemumgebung abzubilden. Für die Entdeckung relevanter Ereignisse ist einzig das Geschick des Analysten gefragt. Jede Datenquelle wird einzeln ausgewertet und die verschiedenen Meldungen aufgeschlüsselt. Eine Verarbeitung der Daten, die quasi in Echtzeit durchgeführt wird, ist praktisch nicht verfügbar. Die Berichte von Sawmill lassen sich periodisch mit einem Mindestintervall von einer Minute erstellen.

Für jede Datenquelle sind in den Profilen die in den Meldungen enthaltenen Datenfelder aufgeschlüsselt. Da keine von Datenquellen unabhängige Korrelation stattfindet, ist auch kein Regelwerk hierfür vorhanden.

Auch die Priorisierung verschiedener Meldungen wird von Sawmill nicht automatisch durchgeführt. Hier sind die Kenntnisse des Analysten und dessen Fähigkeiten gefragt.

Benutzerinteraktion und VorfallsbearbeitungDer Zugriff auf den Webserver der Management-Komponente erfolgt mittels eines beliebigen Browsers.

Sawmill verarbeitet die einlaufenden Meldungen und teilt diese in Bestandteile auf. In erster Instanz wird der Benutzer eine statistische Ansicht der einzelnen Datenfelder und -klassen gezeigt. Diese Klassen kann der Benutzer weiter aufschlüsseln und sich letztlich einzelne Meldungen im originalen Format ansehen. Eine tiefer gehende Analyse ist indes nicht Bestandteil des Funktionsumfangs von Sawmill.

Eine Alarmierung von Benutzern ist in Sawmill nicht vorhanden. Als Ausgabeformat steht nur der Versand von E-Mails zur Verfügung:

Die Visualisierung von Angriffsverläufen kann nicht vorgenommen werden. Über das ergänzende Produkt GeoIP besteht aber die Möglichkeit, die Logmeldungen von Webservern und damit die zugreifenden IP-Adressen auf einer Weltkarte anzeigen zu lassen.

Sawmill präsentiert die vorhandenen Datenmengen in Form von Diagrammen und prozentualen Statistiken an. Die Ansicht der Berichte ist abhängig von der Datenquelle. Die folgenden Ausgabeformate stehen für Berichte zur Verfügung:

– CSV

– PDF

Alle Berichte können zeitgesteuert nach Monaten, Tagen, Stunden und Minuten von der Lösung selbst erstellt und bei Bedarf per E-Mail verschickt werden.

Die Authentifizierung der Benutzer erfolgt ausschließlich per Benutzername und Passwort. Wenn das Produkt als CGI-Programm auf einem bestehenden Webserver installiert wurde, können dessen Authentifizierungsmechanismen und damit auch die externe Verwaltung von Passwörtern genutzt


Logdatenstudie

werden. Die Verwendung von Benutzergruppen ist nicht Bestandteil der Lösung. Für Benutzer können granular Zugriffsrechte und damit auch Ansichten konfiguriert werden. Somit ist es möglich, die Administrationsoberfläche an die Bedürfnisse von Benutzern anzupassen. Eine revisionssichere Speicherung der Benutzeraktionen ist nicht vorhanden. Ebenso fehlt ein Rollenkonzept.

Sicherstellung der Verfügbarkeit des SystemsDie permanente Überwachung der eigenen Systemkomponenten bezieht sich auf die Überwachung der Tabellengröße der Datenbank und der CPU-Nutzung des Systems nach konfigurierten Parametern.

Ein Prozess zur Aktualisierung des Systems befindet sich im experimentellen Status. Die Aktualisierung erfolgt dabei über das Internet per HTTP. Die Verwaltung des Speicherplatzes der Datenbank und die Sicherung sind vorkonfiguriert, sie können aber an die Bedürfnisse des Kunden abgepasst werden.

5.3.8 Intersect Alliance „SNARE Server“

Die australische Firma Intersect Alliance bietet mit dem SNARE Server eine weitere Lösung zur Verarbeitung von Log- und Monitoringdaten an. Der Fokus dieses Produktes liegt auf der zentralen Zusammenführung und Auswertung der jeweiligen Datenquellen in konfigurierbaren Zeitabständen. Auch hier können die Datenquellen über standardisierte Berichtsfunktionen analysiert und ausgegeben werden.

Beim SNARE Server handelt es sich jedoch weniger um ein IT-Frühwarnsystem mit einer Datenverarbeitung, die quasi in Echtzeit durchgeführt wird, als vielmehr um ein Werkzeug zur Auswertung im Nachgang der Datenspeicherung. Damit kann dieses Tool in die Kategorie des Security Information Managements mit spezialisiertem Funktionsumfang eingeordnet werden.

Der Fokus der Lösung liegt zudem eher auf mittelständischen Betriebe und Großunternehmen.

Neben dem SNARE Server hat Intersect Alliance auch noch eine Reihe weiterer Agenten für die gängigsten Betriebssysteme im Programm. Diese dienen dem Transport der spezifischen Logmeldungen der jeweiligen Betriebssysteme. Diese SNARE Agents genannten Agenten sind frei verfügbar und unter der GNU General Public License veröffentlicht.

Die Agenten sind kostenfrei auf der Homepage des Herstellers erhältlich, während der SNARE Server kostenpflichtig ist. Zu lizensieren ist die Leistungsfähigkeit des Servers, welcher in drei Varianten vorliegt. Die Einstiegsvariante beinhaltet die Integration von 50 Datenquellen. Die anderen beiden Varianten unterscheiden sich durch erweiterte Funktionen bei der Kommunikation mit den Agenten.

Die folgende Tabelle bietet einen Überblick über die aktuelle Version und die von SNARE Server unterstützten Plattformen:

Aktuelle Version 3.5Unterstützte Plattformen/Hardware-Serien Auf Ubuntu Linux 5.10 basierende Software-Lö

sung zum Aufbau einer Appliance

Tabelle 63: Version und Plattformen von Intersect Alliance SNARE Server


Logdatenstudie

Zusammenführung von Log- und MonitoringdatenDie Lösung von Intersect Alliance ist so konzipiert, dass alle eintreffenden Meldungen an zentraler Stelle auf dem SNARE Server gespeichert werden.

Die Software zum Aufbau der Lösung kann auf der Homepage des Herstellers als ISO-Datei herunter geladen werden. Nachdem das Abbild der Datei auf eine CD gebrannt wurde, kann die Appliance installiert werden. Der Hersteller bezeichnet die Lösung als appliancebasiert, weil nach der Installation und einer initialen Konfiguration nicht mehr auf das Betriebssystem zugegriffen werden muss. Alle notwendigen administrativen Tätigkeiten sind über die Benutzerschnittstelle der Lösung vorzunehmen. SNARE Server besteht im Wesentlichen aus einem Webserver als Benutzeroberfläche, einer MySQL-Datenbank zur Speicherung der Meldungen und einer Server-Komponente für die Verarbeitung der Daten. Die Agenten sind direkt auf den Datenquellen zu installieren und senden die Meldungen an den SNARE Server. Die Verbindung zum Webserver erfolgt im Auslieferungszustand über das Protokoll HTTP im Klartext. Hierfür kann aber auch das verschlüsselte Protokoll HTTPS verwendet werden.

Die folgende Abbildung zeigt die Architektur von Intersect Alliance SNARE Server:

SNARE Server ist auf die Verarbeitung ereignisbezogener Daten von Betriebssystemen, Applikationen und Netzwerkgeräten spezialisiert. Die originalen Daten werden vor der Übertragung mit Informationen zur Verarbeitung innerhalb von SNARE angereichert, sie bleiben aber prinzipiell in der ursprünglichen Form erhalten.


Abbildung 5.6: Architektur von Intersect Alliance SNARE Server

Logdatenstudie

Alle einlaufenden Daten werden in der Datenbank gespeichert. Bei dieser Datenbank werden dann die SQL-Abfragen während der Analyse gestellt. Nach einem konfigurierbaren Zeitraum lagert das System die Meldungen in komprimierten Textdateien in das Dateisystem aus.

Eine der Aufgaben der SNARE Agents ist die Filterung von nicht relevanten Meldungen. Dies dient der Reduktion der zu verarbeitenden Datenmengen.

Die Zusammenfassung (Aggregation) von gleichartigen Meldungen zu einer zu übertragenen Meldung ist nicht Bestandteil der Agenten.

Die Speicherung der einlaufenden Meldungen über 30 Tage ist problemlos möglich. Letztlich ist die Speicherdauer abhängig von dem zur Verfügung stehenden Speicherplatz. Durch die Auslagerung in Textdateien mit einer Kompressionsrate von 10:1 können große Datenmengen auch wieder in das System migriert werden. Dadurch werden auch forensische Analysen über zurückliegende Zeiträume ermöglicht.

Von den in der Übersicht der Formate aufgelisteten Datenquellen-Typen werden folgende nicht unterstützt:

– SNMP-Log-Format

– NetFlow und IPFIX

– Juniper Netscreen Security Manager

– Cisco IPS und McAfee IntruShield

– Netcache

– BlueCoat

– Secure Computing Webwasher

– Tomcat Servlet Container

– Sendmail, Exim, Postfix, Qmail und SpamAssasin

– ISC Bind

– Asterisk

– McAfee Virusscan, Symantec Antivirus, ClamAV

– Nessus, McAfee Foundstone, QualysGuard

Zusätzlich zu den beschriebenen Formaten unterstützt SNARE Server die folgenden:

– Syslog; Solaris, AIX, IRIX, True64

– ACF2

– RACF Mainframe

– Cyberguard

– Netgear Firewall

– IPTables Firewall

– Gauntlet Firewall

– SNORT NIDS


Logdatenstudie

– IBM Socks Server

Eine Dokumentation, die einen Überblick über alle momentan verfügbaren Datenquellen bietet, ist unter folgendem Link erhältlich:

http://www.intersectalliance.com/snareserver/index.html

Ein Rahmenwerk zur Einbindung noch nicht unterstützter Datenquellen ist nur bedingt verfügbar. Wenn die Daten über Syslog verfügbar gemacht werden, ist diese Funktion über ein universelles Logformat anpassbar. Werden andere Mechanismen und Protokolle genutzt, muss die Entwicklung weiterer Datenquellen an den Hersteller adressiert werden.

Eine Normalisierung der spezifischen Datenfelder in die Notation des Herstellers findet nicht statt. Alle Analysen sind bezogenen auf die Datenfelder der originalen Meldungen.

Die Verschlüsselung der Meldungen bei der Übertragung von Agenten zur Management-Komponente ist nur zum Teil gewährleistet und hängt vom jeweiligen Agenten ab. Die Entwickler arbeiten an der Umsetzung der Verschlüsselung für alle Agenten. Auf der Management-Komponente werden die Daten bei der Speicherung nicht verschlüsselt oder signiert. Die Absicherung der Datenbestände soll über das gehärtete Betriebssystem gewährleistet werden. Die Anonymisierung oder Pseudonymisierung der Datenbasis ist nicht im Funktionsumfang enthalten.

Ereignis-Entdeckung und ihre UnterstützungUm wesentliche Ereignisse aus einer Flut an Meldungen herauszugreifen, teilt das System die Datenbasis hierarchisch nach Kategorien auf (sog. Objectives). Dabei wird jede Datenquelle separat betrachtet.

Die Abbildung des Netzwerkes und der sich darin befindlichen Systeme ist nicht möglich. Dies liegt schlichtweg im Fehlen einer Korrelation begründet. Auch die Einbindung der Daten von Schwachstellen-Scannern ist aufgrund fehlender Datenquellenunterstützung nicht Bestandteil von SNARE Server.

Die Verarbeitung und damit Aufteilung der Meldungen in die kategorisierten Bestandteile findet nahezu in Echtzeit statt. Allerdings muss hierfür ein Benutzer die Analysen anstoßen oder mittels der verfügbaren Zeitplanung in kurzen Abständen durchführen lassen.

Bereits im Auslieferungszustand sind im System eine Reihe von wichtigen Kategorien enthalten. Benutzer mit ausreichender Berechtigung können weitere Abfragen auf die zugrunde liegende Datenbank definieren und so spezielle Kundenbedürfnisse abbilden.

Die Erkennung spezieller Angriffe ist über die Einbindung von SNORT IDS möglich.

Welche Ereignisse in welcher Form behandelt werden sollen, ist im Vorfeld der Implementierung von SNARE Server zu definieren. Die Behandlung verschiedener Ereignisse kann nicht automatisiert priorisiert werden.

Auf den Logsammlern des Systems können nicht benötigte Daten gefiltert werden. Falls ein System ausfällt, haben die Logsammler einen Puffer zur Zwischenspeicherung von Meldungen. Zudem kann die Management-Komponente sowohl im Hot-Standby- als auch im Hochverfügbarkeit-Modus ausgelegt werden.


Logdatenstudie

Benutzerinteraktion und VorfallsbearbeitungAls Benutzerschnittstelle steht die Verbindung über einen Webbrowser entweder über HTTP oder HTTPS zur Verfügung. Die Komponenten des Systems können weitgehend über die Webschnittstelle administriert und überwacht werden. Bei Bedarf kann auf die Konsole des Betriebssystems zugegriffen werden.

In den einzelnen Kategorien kann die Granularität mittels eines Mausklicks erhöht werden, um einzelne Systeme oder Ereignisse näher zu analysieren. Auch lassen sich über den Webbrowser weitere Abfragen auf die Datenbasis der Datenbank generieren.

Die Ergebnisse der Abfragen können automatisch per E-Mail an Mailboxen und Benutzer versandt werden. Weiterhin kann auch ein Eintrag an einen entfernten Syslog-Server gesendet werden.

Aus jeder Abfrage können die jeweiligen Berichte in den nachfolgenden Formaten generiert werden:

– Text

– HTML

– CSV

Als Authentifizierungsmechanismen für den SNARE Server stehen die Abfrage von Benutzername und Passwort oder die externe Authentifizierung über LDAP bereit. Die Agenten besitzen eine eigene Webschnittstelle, welche die Authentifizierung nur mittels Benutzername und Passwort anbietet. Ein Rollenkonzept ist nicht umgesetzt. Die Zugriffsrechte für jede Funktion der Lösung können auf Gruppenebene oder auch für Benutzer vergeben werden. Alle Benutzeraktionen werden revisionssicher in eine Logdatei auf dem Server geschrieben.

Sicherstellung der Verfügbarkeit des SystemsDas System überwacht alle kritischen Bereiche selbsttätig. Hierzu gehören Prozesse, die Auslastung des Platten- und Arbeitsspeichers sowie die Überwachung der Datenbanktabellen. Alle Informationen lassen sich von der Benutzeroberfläche einsehen und Schwellwerte festlegen.

Das System kann über Updates, die von der Webseite des Herstellers heruntergeladen werden können, und anschließend durch Hochladen der Aktualisierung über die Webschnittstelle aktualisiert werden. Die Datenmigration wird über die Benutzeroberfläche gelöst. Ebenso verhält es sich mit den Einstellungen für die Archivierung von Datenbeständen.

5.3.9 Cisco Security MARS

Die Firma Cisco Systems Inc. bietet in der Produktreihe Cisco Security Monitoring, Analysis and Response System (MARS) ein Produkt zur Auswertung von Log- und Monitoringdaten an.

Der Kundenfokus der appliancebasierten Lösung beginnt im unteren Mittelstand und reicht über Großkunden in verteilten Umgebungen bis hin zu Service Providern.

Der Fokus des Produktes liegt auf der Analyse und Auswertung von Informationen zur Netzwerk- und Sicherheitsinfrastruktur und kann deshalb dem Bereich der spezialisierten IT-Frühwarnsysteme zugeordnet werden. Daneben kann mit dem Produkt ein Netzwerk-Monitoring durchgeführt werden, da es die Möglichkeit bietet, NetFlow-Daten auszuwerten.


Logdatenstudie

Des Weiteren bietet Cisco eine Reihe ergänzender Produkte an. Durch Integration von MARS in das System-Management, den Cisco Security Manager (CSM), kann das Produkt in Verbindung mit Sicherheitslösungen wie Firewalls, ACL auf Routern und IDS stattfinden. Dies ermöglicht auch die Unterstützung von Gegenmaßnahmen (STM = Security Threat Mitigation).

Die Lizensierung der Lösung basiert auf den Hardware-Kosten für die Appliance und einem Wartungsvertrag.

Aktuelle Version 5.2.7Unterstützte Plattformen/Hardware-Serien Appliancebasiert:

Tabelle 64: Version und Plattformen von Cisco MARS

Zusammenführung von Log- und MonitoringdatenCisco MARS besitzt die in der folgenden Skizze dargestellte Architektur in einer verteilten Installation:

Cisco MARS speichert bei der Implementierung einer Appliance im Netzwerk sowohl die Rohdaten als auch normalisierte Daten zentral ab (Oracle-DB). Eine externe Datenbank des Herstellers Oracle kann bei Bedarf angebunden werden. Bei einer hierarchischen Architektur mehrerer Appliances verbleiben die Rohdaten standardmäßig auf der Appliance, die diese entgegengenommen hat. Nur die normalisierten Ereignisse werden zentral gespeichert. Die Rohdaten können bei bei Bedarf (Analyse) auf die zentrale Appliance transportiert werden.


Abbildung 5.7: Architektur von Cisco MARS

Logdatenstudie

Cisco MARS verwendet die folgenden produktspezifischen Begriffe:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Local Controller (verteilte Installation)Logkorrelator Kein spezifischer BegriffManagement-Komponente Global Controller (verteilte Installation)Logspeicher Kein spezifischer BegriffEreignis Incident

Tabelle 65: Begriffsbestimmung bei Cisco MARS

Cisco Mars ist spezialisiert auf die Verarbeitung von Log- und Monitoringdaten. Neben NetFlow-Daten werden ereignisbezogenen Daten bei der Korrelation herangezogen.

Durch den Aufbau einer verteilten Architektur können nicht relevante Daten auf der ersten Instanz gefiltert und somit im System nicht weiter verarbeitet werden. Diese Funktionalität ist manuell zu konfigurieren. Dadurch wird sichergestellt, dass ausschließlich relevante Daten betrachtet werden.

Weiterhin unterstützt Cisco MARS die Verdichtung gleicher Meldungen zu einem normalisiertem Ereignis durch Aggregation.

Die Lösung speichert die Rohdaten lokal in der lokalen Datenbank sowohl über einen Zeitraum von 30 Tagen als auch 90 Tage lang vollständig. Letztlich sind diese Aufbewahrungsfristen abhängig von der Auswahl der zu implementierenden Appliance, da diese unterschiedliche Speicherkapazitäten aufweisen.

Der Schwerpunkt bei der Unterstützung von Datenquellen liegt bei Cisco MARS auf den eigenen Produkten, welche auch alle integriert sind. Von den in der Übersicht der Formate aufgelisteten Datenquellen-Typen werden folgende nicht unterstützt:

– IPFIX

– Tipping Point IPS

– Microsoft ISA Server

– SQUID Proxy

– Bluecoat SG


– Clam AV

– SAMBA Log

– Asterisk

– Tomcat

– NMAP

– Nessus

Zusätzlich zu den in dieser Studie beschriebenen Formaten unterstützt Cisco MARS 9 weitere Produkte und deren Formate.


Logdatenstudie

Die vollständige Liste der unterstützten Produkte und deren Formate kann unter folgendem Link eingesehen werden:

http://www.cisco.com/en/US/products/ps6241/products_device_support_table09186a0080467232.html

Zur Integration von noch nicht unterstützten Datenquellen bietet Cisco den Custom Parser an. Mit diesem Parser können viele verschiedene Datenquellen eingebunden und normalisiert werden.

Die Log-Einträge der eintreffenden Daten normalisiert das System vollständig. Aufgrund dessen erfolgt die Korrelation über alle Felder und Datenquellen unabhängig voneinander.

Die Übertragung von Daten in einer hierarchischen Architektur findet verschlüsselt statt. Auf der Appliance selbst liegen die Daten unverschlüsselt in der Datenbank vor. Die Absicherung der Daten hinsichtlich der Schutzziele Vertraulichkeit und Integrität obliegt somit der Datenbank und dem gehärteten Betriebssystem. Eine Verschleierung der personenbezogenen Daten durch Anonymisierung ist nicht Bestandteil der Lösung.

Ereignis-Entdeckung und ihre UnterstützungDie Aufgabe, in einer sehr großen Anzahl an Meldungen die relevanten durch Korrelation und Priorisierung zu finden, geht die MARS Appliance folgendermaßen an:

Im Bereich der Modellierung bietet die Appliance Basisfunktionalitäten. So erarbeitet sich das System die Netzwerkumgebung mithilfe zu integrierender NetFlow-Daten der aktiven Netzkomponenten selbst. Die Netzwerkumgebung kann dann nicht nur grafisch dargestellt werden, sondern auch die Anzeige von Ereignissen innerhalb dieser Grafik ist möglich. Über Schwachstellen- Scanner können Systeme innerhalb dieser Netzwerke inventarisiert werden. Neben den IP-Adressen fließen die Betriebssystemversion, offene Ports und Verwundbarkeiten in die Modellierung mit ein. Weiterhin unterstützt das System die Definition von Ausnahmen mittels einer Ausnahmeliste (White List).

Der Fokus der Lösung liegt in der Quasi-Echtzeit-Verarbeitung der gemeldeten Ereignisse, um Angriffe und abnormales Verhalten schnellstmöglich entdecken zu können.

Hierzu findet eine Korrelation über alle integrierten Datenquellen hinweg statt. Die Korrelationsregeln enthalten die folgenden Elemente:

– Verknüpfung einer Anzahl von Datenquellen durch logische Operatoren.

– Definition von Schwellwerten für die Auslösung der Regel

– Berücksichtigung der Daten des Schwachstellen-Scanners

– Überprüfung, ob Angreifer bereits früher auffällig geworden ist.

– Berücksichtigung von Ausnahmelisten

– Aktionsoptionen

Ein Regelwerk für die Entdeckung unterschiedlicher Bedrohungen liefert der Hersteller bereits in die Lösung integriert mit. Dieses Regelwerk ist durch den Kunden veränderbar. Eigene Regeln können ebenfalls hinzugefügt werden.

Für die weitere Bearbeitung der Korrelationsergebnisse stehen neben der Anzeige in der Benutzeroberfläche die folgenden Aktionen zur Verfügung:

● Senden eines SNMP-Traps




Logdatenstudie

● Senden einer Syslog-Meldung

● E-Mail auch mit Ereignisinformationen als XML-Datei im Anhang

● SMS

● Proprietäres Ticket-Format (Distributed Threat Mitigation)

Die Erkennungsmöglichkeiten der Lösung beziehen sich sowohl auf die Entdeckung von generischen Mustern als auch auf das Aufspüren von konkreten Bedrohungsszenarien.

Die Priorisierung von erkannten Ereignissen erfolgt direkt in der Regel des Systems. Sie geht damit nicht auf den Schutzbedarf des jeweiligen inventarisierten Systems ein. Die Änderung der Priorisierung kann manuell innerhalb der Regel erfolgen.

Die Sicherstellung der Performanz der Lösung erfolgt in erster Linie durch Implementierung mit ausreichend Reserven für Lastspitzen und Erweiterungen. In verteilten Architekturen werden bei einem Ausfall eines Knotens die Meldungen lokal in einem Cache gespeichert. Weiterhin können nicht benötigte Informationen vor der Korrelation gefiltert werden.

Benutzerinteraktion und VorfallsbearbeitungFür die Administration und Analyse des Systems steht eine per SSL gesicherte Benutzeroberfläche per Webbrowser zur Verfügung. Das Login über eine Konsole ist zwar möglich, wird im normalen Betrieb aber nicht benötigt.

Der Benutzer hat die Möglichkeit, bei der Analyse eine hohe Anzahl an Abfragen und Filtern zu konfigurieren und so weiterführende Informationen zu erhalten. Ein Kontextmenü mit Vorschlägen für die Analyse ist indes nicht integriert.

Als Schnittstellen zur Alarmierung sind die im vorigen Abschnitt als Aktionsoptionen bezeichneten Benachrichtigungsmechanismen vorgesehen, Schnittstellen zu Ticketing-Systemen bestehen nicht.

Das System bringt im Auslieferungszustand bereits150 Standard-Reports mit. Diese enthalten sowohl Reports für Analysten, für das Management und auch für Audit- und Revisionszwecke (Compliance).

Es stehen die folgenden Formate für die Erstellung von Reports zur Verfügung:

– PDF

– HTML

– XML

– CSV

Alle Reports sind frei vom Benutzer anpassbar. Die zeitlich gesteuerte Ausführung des Reportings ist im Funktionsumfang enthalten.

Aktuell wird eine lokale Benutzerdatenbank mit einer Authentifizierung über Benutzername/Passwort verwendet. Eine Integration in ein unternehmensweites Authentifizierungsschema über RADIUS/TACACS+ ist geplant.

Die Lösung verwendet ein gruppenbasiertes Berechtigungskonzept. Dieses umfasst unterschiedliche Ansichten und Zugriffsrechte innerhalb der Benutzeroberfläche. Die Einschränkung der Zugriffsrechte auf bestimmte Datenquellen ist indes nicht konfigurierbar.


Logdatenstudie

Des Weiteren wird ein ausführliches Audit-Log vom System geführt, welches alle Aktivitäten der Benutzer protokolliert. Eine Manipulation dieses Protokolls durch die Benutzer ist nicht möglich.

Sicherstellung der Verfügbarkeit des SystemsDie MARS Appliance verwaltet sich weitgehend selbst. Hierzu gehören sowohl die Aktualisierung des Systems nach der Aktivierung und die Pflege der Datenbank als auch die Datensicherung. Die Überwachung der korrekten Funktion des Systems ist darin ebenfalls enthalten. Dem Administrator werden bei einer Überschreitung der definierten Schwellwerte entsprechende Benachrichtigungen zugestellt.

5.3.10 Open Source Security Information Management „OSSIM“

Unter den Anbietern von Systemen zur Auswertung von Log- und Monitoringdaten befindet sich auch das Open-Source-Projekt Open Source Security Information Management (OSSIM). Erklärtes Ziel des Projektes ist die Entwicklung eines Rahmenwerkes, um die Daten unterschiedlicher Open-Source-Werkzeuge in eine Benutzeroberfläche zu integrieren, um sicherheitsrelevante Ereignisse zu ermitteln.

Der Kundenfokus dieses Programms erstreckt sich von begeisterten Heimanwendern über mittelständische Unternehmen bis hin zu großen Unternehmen.

OSSIM ist eindeutig in die Kategorie der spezialisierten IT-Frühwarnsysteme mit einer Auswertung der eintreffenden Meldungen in Quasi-Echtzeit einzuordnen. Es wertet sowohl Monitoring- als auch ereignisbezogene Daten aus. Die Datenbasis wird verwendet, um eine Normalisierung, Korrelation und Priorisierung der Daten durchzuführen und auf diese Weise sicherheitsrelevante Ereignisse zu entdecken. Ein Risiko-Management ist ebenfalls Bestandteil der Lösung.

OSSIM wird unter der BSD License entwickelt und ist aus diesem Grund frei verfügbar. Auf der Homepage des Projekts haben sich erste Firmen eingeschrieben, die eine professionelle Unterstützung kostenpflichtig anbieten.

Das Projekt wurde am 18.07.2003 auf der Homepage von SourceForge registriert, was dem Gründungszeitpunkt zumindest nahe kommen dürfte.

Aktuelle Version 0.9.9.rc4Unterstützte Plattformen/Hardware-Serien Diverse Linux-Derivate:

- Debian- Fedora - Gentoo Daneben auch:MacOS X

Tabelle 66: Version und Plattformen von OSSIM

Zusammenführung von Log- und MonitoringdatenInnerhalb der Lösung werden einlaufende Log- und Monitoringdaten in einer zentralen Datenbank zusammengeführt. In hierarchischen Architekturen größerer Installationen kann dieses Konzept aufgeweicht werden, um die Bandbreite einer zentralen Speicherung aller Daten zu minimieren.


Logdatenstudie

Nachfolgend ist der Aufbau einer hierarchischen Architektur dargestellt:

Das System arbeitet mit dezentralen Logsammlern, die sowohl die im System integrierten Open-Source-Werkzeuge als auch Erweiterungen für die Konnektivität mit kommerziellen Datenquellen vorhalten. Diese leiten die Rohdaten an die Management-Komponente weiter. Auf der Management-Komponente werden die Daten verarbeitet und in die Datenbank geschrieben. Für die Korrelation und Priorisierung der Datenbasis findet eine bidirektionale Kommunikation zwischen der Datenbank und der Management-Komponente statt.

Die folgende Skizze zeigt die einzelnen Komponenten des Systems:


Abbildung 5.8: Architektur von OSSIM

Logdatenstudie

OSSIM verwendet die folgenden produktspezifischen Begriffe:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Sensor mit Agent und DetectorsLogkorrelator Correlator als Teil der Management-Komponen

teManagement-Komponente ServerLogspeicher ossim-mysqlEreignis Event

Tabelle 67: Begriffsbestimmung bei OSSIM

OSSIM operiert mit insgesamt drei MySQL-Datenbanken. In der Event Database werden die Rohdaten aller Datenquellen gespeichert. Die Knowledge Database enthält alle konfigurationsspezifischen Daten wie die Abbildung des Netzwerkes und die definierte Sicherheitsrichtlinie. Die dritte Datenbank ist die Profile Database, in der für jedes erkannte System ein spezifisches Benutzerprofil vorgehalten wird.

Auf den Logsammlern können eine Priority Policy und Correlation Directives installiert werden. Diese definieren die zu sammelnde Datenmenge und welche Meldungen gesammelt werden sollen. Zudem erfüllen sie die Voraussetzungen für eine Filterung von nicht relevanten Meldungen.

Die Zusammenfassung von gleichartigen zu einer aggregierten Meldung ist zum momentanen Zeitpunkt nicht Bestandteil der Lösung. Die Implementierung dieser Funktion steht aber auf der Road Map der Entwickler.


Abbildung 5.9: Logischer Aufbau von OSSIM

Logdatenstudie

Die Speicherung der Daten über einen Zeitraum von 30 Tagen ist abhängig vom verfügbaren Speicherplatz möglich. Da es sich eine rein softwarebasierende Lösung handelt, ist die Speicherung der Daten über beliebige Zeiträume letztlich von der korrekten Planung und Umsetzung des Speicherbedarfs abhängig.

Als feste Bestandteile der Lösung haben die Entwickler die folgenden Open-Source-Werkzeuge in OSSIM integriert:

– Snort IDS

– Nessus Vulnerability Scanner

– Ntop Network Monitor

– Nagios Availability Monitor

– Osiris und Snare Host IDS

– Spade und HW Aberrant Behaviour Anomaly Detector

– RRD

– NMAP Port Scanner

– ARPwatch, POf, Pads und Fprobe passive Monitoring

– Acid/Base Forensic Analysis Console

– OSVDB Vulnerability Database

Zusätzlich zu diesen integrierten Datenquellen haben es sich die Entwickler das Ziel gesetzt, eine möglichst umfassende Liste an offenen und kommerziellen Datenquellen zu integrieren. Auf der Homepage der Projektgruppe wird zur Anzeige dieser Datenquellen die Liste des Herstellers ArcSight herangezogen. Da die bereits integrierten Datenquellen recht kurz ist, wird an dieser Stelle auf den Vergleich mit den in dieser Studie beschriebenen Datenquellen verzichtet:

– Checkpoint Firewall-1 (SAM, LEA)

– Cisco Pix

– ISS Siteprotector

– Juniper NSM

– Fortinet Fortigate Syslog

– Microsoft Windows Eventlog

– Microsoft IIS Webserver

– Unix/Linux Syslog

– Cisco Router IOS

– Cisco Catalyst Switch

– Apache Webserver

Die aktuelle Liste der unterstützten Datenquellen kann unter folgendem Link eingesehen werden:

http://www.ossim.net/dokuwiki/doku.php?id=roadmap:plugins


Logdatenstudie

Für die Erweiterung der Normalisierung bereits integrierter Datenquellen und zur Einbindung weiterer Datenquellen wird von OSSIM ein Rahmenwerk zur Verfügung gestellt. Dieses basiert auf der Programmiersprache Python und nutzt reguläre Ausdrücke, um die Datenfelder zuzuweisen.

Die einlaufenden Meldungen werden auf der Management-Komponente einer Normalisierung unterzogen. Diese ist abhängig von der Art der Datenquelle und wird zur unabhängigen Korrelation von Datenquellen herangezogen.

Während der Übertragung zwischen den Logsammlern und der Management-Komponente findet eine Verschlüsselung statt. Diese basiert zum Zeitpunkt der Erstellung der Studie auf OpenVPN. Die Integration von weiteren Verschlüsselungsmechanismen ist ebenfalls geplant. Innerhalb der Datenbank werden die Meldungen nicht verschlüsselt oder signiert. Die Anonymisierung oder Pseudonymisierung der Datenbestände während der Verarbeitung ist nicht Bestandteil des Funktionsumfangs von OSSIM.

Ereignis-Entdeckung und ihre UnterstützungFür die möglichst präzise Modellierung der Netzwerk- und Systemumgebung besteht in OSSIM die Möglichkeit, Netze abzubilden. Des Weiteren können die Systeme der Netzwerkumgebung integriert werden. Die einzelnen Systeme können über den Schwachstellen-Scanner oder auch die passiven Werkzeuge generiert und gleichzeitig mit Informationen angereichert werden. Modellierungsinformationen, die in OSSIM hinterlegt werden können, sind das Betriebssystem, Dienste, die IP- und MAC-Adresse, Statistiken zur Bandbreitennutzung, die Gewichtung des Systems und auch die Verwundbarkeiten eines Systems.

Alle Meldungen werden permanent an die Management-Komponente gesendet und dort quasi in Echtzeit verarbeitet. Für die Korrelation stehen unterschiedliche Mechanismen zur Verfügung. Diese beinhalten:

– Verknüpfung mehrerer Ereignisse

– Abfragen auf den Inhalt von Datenfeldern

– Definition von Schwellwerten und Alarmierung bei einer Überschreitung

– Durchführung von Aktionen

Eigene Regeln können mit der Administrationsoberfläche nicht erstellt werden. Ein Regelwerk ist bereits vom Projektteam im Auslieferungszustand definiert. Dieses ist jedoch als rudimentär anzusehen. Ebenso verhält es sich mit den Aktionsoptionen: Es stehen in OSSIM nur die Benachrichtigung von Benutzern per Mail, die Anzeige in der Konsole und das Schreiben eines Logs als Optionen bereit.

Durch die Verknüpfung der einzelnen Arten von Monitoring- und Logdaten innerhalb der vordefinierten Regeln können Würmer sowohl generisch anhand ihres Verhaltens als auch spezifische Würmer entdeckt werden. Bei der Korrelation wird auch die Vorgeschichte des Angreifers beachtet. Allerdings werden Listen auffälliger Angreifer nur im Arbeitsspeicher geführt, so dass ihr Umfang beschränkt ist.

Die Priorisierung von Ereignissen findet unter Beachtung der Zuverlässigkeit (Reliability) des Ereignisses statt. Diese Zuverlässigkeit ist Bestandteil einer Regel und wird auch von den in den Systemdaten hinterlegten Informationen beeinflusst. Im Wesentlichen sind dies die erkannten Schwachstellen des Systems, die Gewichtung (Value) und die dem System zuordneten Verbindun


Logdatenstudie

gen. Die Priorität lässt sich nicht in den Regeln verändern und kann somit nur über die Gewichtung innerhalb der Systemdaten vorgenommen werden.

Die Sicherstellung der Performanz des System ist über die korrekte Planung der Implementierung zu lösen. Wichtig ist hierbei die Kenntnis der konkreten Datenmengen, um Überlastsituationen zu vermeiden. Die Logsammler fassen mehrere Meldungen zusammen, um auf diese Weise die Bandbreite bei der Übertragung der Meldungen zur Management-Komponente zu schonen. Eine Aggregation gleichartiger Meldungen zu einer einzigen Meldung ist in OSSIM nicht berücksichtigt. Die Filterung von Meldungen kann nicht zentral administriert werden und muss auf den jeweiligen Logsammlern durchgeführt werden.

Benutzerinteraktion und VorfallsbearbeitungDie Benutzerschnittstelle ist webbasierend und wird über HTTP angesprochen. Die Absicherung dieser Übertragung über HTTPS lässt sich wahrscheinlich durch Konfiguration des Webservers realisieren.

Der Benutzer wird bei der Recherche von Ereignissen im Wesentlichen durch die Anzeige von Berichten der beteiligten Datenquellen und durch das Setzen von Ereignisfiltern unterstützt. Ebenfalls können über die integrierte Schwachstellen-Datenbank weitere Informationen zu der Schwachstelle und deren Behebung angezeigt werden. Ein Kontextmenü, welches den Analysten unterstützt, ist nicht verfügbar.

Für die Alarmierung bei erkannten Ereignissen stehen die folgenden Schnittstellen zur Verfügung:

– Anzeige in der Konsole

– E-Mail

– Ausführen eine Programms

– Anlegen eines Tickets im integrierten Ticket-System

Die zur Verfügung gestellten Reports lassen sich im Wesentlichen auf vier Typen reduzieren:

– Host Report; Anzeige aller in OSSIM integrierten Systeme

– Alarm Report; Anzeige der wichtigsten Systeme (Angreifer, Opfer, genutzte Ports etc.)

– Security Reports; gleiche Anzeige wie bei den Alarm Reports, allerdings mit Bezug auf einzelne Ereignisse

– Incident Report; Anzeige des aktuellen Status der im Ticket-System enthaltenen Vorfälle

In der Konsole lassen sich die Berichtes nicht verändern, sie sind somit statisch und auf die angebotenen begrenzt. Auch lassen sich die Berichte nicht zeitlich gesteuert erstellen. Neben der Anzeige in der Konsole können die Berichte ausschließlich im PDF-Format ausgegeben werden.

Die Authentifizierung erfolgt ausschließlich über Benutzername und Passwort. Weitere Authentifizierungsmechanismen befinden sich in der Planung. Zugriffsrechte können für einzelne Benutzer für Netze, Regeln, Datenquellen und einzelne Programmfunktionen vergeben werden. Ein Rollenkonzept existiert nicht, was sich auch durch das Fehlen von Gruppen bemerkbar macht. Eine weitere Limitation besteht darin, dass nur ein Administrator am System konfiguriert werden kann. Die Aktionen jedes Benutzers werden revisionssicher in ein Log geschrieben.


Logdatenstudie

Sicherstellung der Verfügbarkeit des SystemsDas Monitoring der eigenen Systemkomponenten ist in die Benutzeroberfläche nicht integriert. Da es sich um ein offenes System handelt, kann das Monitoring über die Werkzeuge des Betriebssystems und der Datenbank gelöst werden. Hierzu sind in jedem Fall tiefer gehende Kenntnisse über Unix/Linux und die Datenbank notwendig.

Die Aktualisierung des Systems erfolgt manuell. Der Benutzer kann sich in eine Mailing-Liste einschreiben, über die Aktualisierungen bekannt gegeben werden. Die Speicherplatzverwaltung ist direkt über die Datenbank gelöst und muss mit den zur Verfügung gestellten Werkzeugen konfiguriert werden. Einzig das Backup der Datenbank ist direkt in die Benutzeroberfläche integriert.

5.3.11 IBM „Tivoli Security Operations Manager“

Die amerikanische Firma IBM bietet im Rahmen der Produktsuite Tivoli den Tivoli Security Operations Manager (TSOM) an. Der Fokus dieses Software-Produkts liegt in der Echtzeit-Auswertung von Log- und Monitoringdaten zum Zwecke der IT-Frühwarnung.

Diese Lösung richtet sich vor allem an große Unternehmen und Service Provider.

Der TSOM kann eindeutig dem Bereich der spezialisierten IT-Frühwarnsysteme zugeordnet werden, da er einen produktübergreifenden Ansatz für die Auswertung von Log- und Monitoringdaten sowie einen Echtzeitverarbeitungsansatz verfolgt.

Der TSOM ist Teil einer Produktsuite, die mit dem Tivoli Compliance Insight Manager (TCIM) seine Ergänzung im Bereich des Logdaten- und Compliance-Managements hat. Der TSOM stammt aus der Akquise der Firma Micromuse und ihres Produktes neuSECURE, welches wiederum Produkt der zuvor von Micromuse akquirierten Firma GuardedNet war. Das neuSECURE- bzw. TSOM-Produkt ist mittlerweile geeignet, um das alte IBM-Produkt Tivoli Risk Manager vollständig zu ersetzen.

Um das Produkt einsetzen zu können, wird eine Grundlizenz benötigt, des Weiteren fallen Lizenzen nach der Anzahl der Netzwerkknoten (Router, Switches etc.) und nach der Anzahl der Netzwerkgeräte (d. h. Firewalls, IDS etc. ) an. Außerdem wird ein aktueller Software-Wartungsvertrag benötigt.

Die Produkthistorie des nun als TSOM vertriebenen Produktes reicht bis ins Jahr 1999 zurück.

Die folgende Tabelle bietet einen Überblick über die aktuelle Version und die seitens TSOM unterstützten Plattformen:

Aktuelle Version 4.1Unterstützte Plattformen/Hardware-Serien Red Hat Enterprise Linux 3.0

AIX 5.3Solaris 9Windows Server 2003

Tabelle 68: Version und Plattformen von IBM TSOM

Zusammenführung von Log- und MonitoringdatenIBM TSOM besitzt die in der folgenden Zeichnung dargestellte Architektur:


Logdatenstudie

Folgende produktspezifische Begriffe werden in IBM TSOM verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler – Event Aggregation Module, EAM

– Universal Collection Module, UCM (ergänzender Agent)

Logkorrelator Central Management SystemManagement-Komponente Central Management SystemLogspeicher Datenbank: DB2, Oracle oder MySQLEreignis Event

Tabelle 69: Begriffsbestimmung bei IBM TSOM

Der TSOM ist auf die Verarbeitung von Log- und Monitoringdaten aus einer großen Bandbreite von Datenquellen eingerichtet.

Die Log- und Monitoringdaten werden über verschiedene Mechanismen und Protokolle von den Datenquellen zu den EAM-Modulen transferiert, wobei die Sicherheit des jeweiligen Übertragungsprotokolls (Syslog, CP LEA, SSL etc.) zum Tragen kommt. Für Datenquellen, bei denen dieses Vorgehen nicht angewandt werden kann, steht zum Import der Logdaten noch das optionale UCM zur Verfügung, welches auf das Datenquellensystem als Agent aufgebracht werden kann. Es können mehrere EAMs zum Einsatz kommen. In diesem Fall müssen die Log- und Monitoringdaten erst auf dem zentralen CMS zusammengeführt werden. Für ein zentrales Log-Management können die Da


Abbildung 5.10: Architektur von IBM TSOM

Logdatenstudie

ten aber vom jeweiligen EAM zusätzlich in das optionale TCIM-Produkt weitergeleitet werden (nicht in der Abbildung 5.10 enthalten), welches für eine Logdaten-Zentralisierung und Langzeitspeicherung besser geeignet ist als der TSOM.

Die gesammelten Ereignisdaten werden im TSOM auf der Ebene des CMS gespeichert, wofür eine DB2-Datenbank verwendet wird.

Eine Filterung der einlaufenden Ereignismeldungen kann sowohl auf der Ebene des EAM wie des CMS stattfinden, auch können gleichartige Ereignisse über zentrale Einstellungen aggregiert werden.

Die Langzeitspeicherung von Daten ist bei TSOM in erster Linie eine Frage der bereitgestellten Ressourcen im Datenbankbereich. Eine Speicherung von 30 bis 90 Tagen ist im Projekt aber durchaus typisch und wird regelmäßig so umgesetzt.


– Alle Mail-Server inkl. Microsoft Exchange

– ISC Bind

– Squid

– SecureComputing Webwasher

– NetCache

– Samba

– Asterisk

– Tomcat

– SpamAssassin

– ClamAV

– F-Secure

Über die Liste hinausgehend werden außer IBM-Produkten noch weit mehr als 50 Fremdprodukte unterstützt.

Eine generische Unterstützung für Syslog- und SNMP-basierte Datenquellen ist ebenfalls gegeben. Eine vollständige Liste der unterstützten Datenquellen ist im Internet nicht angegeben, sondern muss bei IBM angefragt werden.

Für die Integration weiterer Datenquellen-Typen steht die Möglichkeit, einen eigenen Parser zu schreiben, bereit. Zudem sind die mitgelieferten Parser offengelegt und editierbar/korrigierbar.

Die importierten Log- und Monitoringdaten werden durch den Parser normalisiert, bevor sie in die zentrale Datenbank geschrieben werden. Die erfolgende Normalisierung ist dabei sehr umfangreich und vollständig, sie findet auf dem EAM, nicht aber auf dem USM statt.

Ab dem EAM- bzw. USM-Level werden die Daten zudem SSL-verschlüsselt übertragen. Dies bedeutet die Bewahrung von Integrität und Sicherstellung der Authentizität der übertragenen Daten ab diesem Level. Ein datenquellennaher Einsatz von EAM bzw. USM ist somit eine Option für Umgebungen mit entsprechenden Anforderungen an die Behandlung von Log- und Monitoringdaten.


Logdatenstudie

Zur Wahrung des Datenschutzes können Ereignisfelder, die Benutzerdaten wie Benutzernamen o. ä. enthalten, über einen Hash-Algorithmus verschleiert werden.

Ereignis-Entdeckung und ihre UnterstützungUm aus aus Millionen von Logmeldungen wesentliche Ereignisse herauszugreifen, verwendet TSOM folgende Mittel:

Es ist möglich, im TSOM eine Modellierung des bestehenden Netzwerks vorzunehmen. Dies kann automatisiert und regelmäßig über Schnittstellen zu Drittsystemen wie Schwachstellen-Scannern, Konfigurations-Management-Datenbanken und anderen Tools (IBM Omnibus) vorgenommen werden, so dass ein aktueller und akkurater Datenbestand im TSOM abgebildet werden kann. Zu Assets und Netzwerken können neben den Basiseigenschaften zusätzlich Informationen wie offene Ports, Verwundbarkeiten sowie Software-Versionen der laufenden Dienste hinterlegt werden. Wichtig ist in diesem Zusammenhang die Gelegenheit, über eine Gruppenbildung auch Aussagen der Informationssicherheit über die Relevanz diverser Assets oder organisatorische Verantwortlichkeiten zu modellieren.

Das Prinzip sog. „Watchlists“ gestattet es, auffällig gewordene oder anders auffällige Rechner besonders zu beobachten bzw. zu bewerten. Dafür können Black- und White Lists eingesetzt werden.

Auf diesen Modellierungsmöglichkeiten baut bei TSOM die Korrelation von Ereignissen in Echtzeit auf. Es finden sich die üblichen Funktionen zur Korrelation von Einzelereignissen sowie zwei oder mehr Ereignissen. Schwellwertüberschreitungen, logische Verknüpfungen, Abfragen auf Inhalte von Ereignismeldungen sind möglich. In der Modellierung hinterlegte Informationen wie die Verwundbarkeit eines Systems gegen einen Angriff fließen dabei in die Korrelation ein. TSOM liefert einen Standardsatz an Korrelationsregeln mit, welcher editiert und angepasst werden kann.

Dies trifft weniger zu auf sog. statistische Korrelationen, bei denen die Entwicklung von Performance-Größen über die Zeit durch eine statistische Analyse der Log- und Monitoringdaten fortlaufend erfolgt. Diese vorkonfigurierten, mit Algorithmen hinterlegten Auswertungen erlauben die anomaliebasierte Erkennung von Angriffen und Angreifern.

Die Korrelationen erfolgen auf Basis der normalisierten Daten und somit gerätetypunabhängig und datenquellenübergreifend. Für die Erkennung von Angriffen kann auf eine generische Mustererkennung zurückgegriffen werden. Eine konkrete Mustererkennung ist nur indirekt über die Ergebnisse aus IDS-/IPS-Systemen möglich.

Als Aktionen nach dem Auslösen einer Korrelationsregel werden im TSOM neben der Erzeugung eines neuen sog. Meta-Ereignisses eine Reihe von Optionen angeboten:

– Anpassung einer Firewall-Konfiguration

– Ausführung eines Skripts

– Versenden einer E-Mail

– Pager-Nachricht

– SMS

– SNMP-Trap-Versendung

– Weitere


Logdatenstudie

Das Priorisierungs-Schema im TSOM berücksichtigt eine Reihe von Parametern. Grob beschrieben kann die Wichtigkeit von Rechnern, Netzwerken und Ereignistypen konfiguriert werden. Zusammen mit einer dem berichtenden Gerät zugeordneten Zuverlässigkeit seiner Aussagen wird für ein einzelnes Ereignis dann automatisch eine Wertigkeit/Priorität errechnet und diesem zugewiesen.

Die möglichen Werte der Einzelgrößen rangieren jeweils auf einer Prozent-Skala von 0-100 %. Manuelle Eingriffe in dieses Priorisierungsschema sind durch die initial notwendige Einstellung der genannten Parameter vorgesehen.

Die Sicherstellung der System-Performance für die Ereignis-Entdeckung, also die Sicherung genügender Systemressourcen, geschieht durch die gezielte Vorfilterung von uninteressanten Logmeldungen, die Bereitstellung möglichst hoher Hardware-Performance und die Trennung performance-fordernder Prozesse wie der regelbasierten Korrelation von im Hintergrund stattfindenden Prozessen wie der statistischen Korrelation. Die Logsammler-Komponenten sind in der Lage, Meldungen lokal temporär zwischenzuspeichern, bis eine ausgefallene Verbindung zum Central Management System wiederhergestellt ist.

Benutzerinteraktion und VorfallsbearbeitungFür die alltägliche Arbeit im TSOM-System wird ein Web-Interface bereitgestellt, welches auf der Basis von Java-Plugins arbeitet. Diese komplexe Konsole betont stark die visuelle Darstellung der Inhalte und ermöglicht über Kontextmenüs die genauere Recherche von identifizierten Vorfällen. Kontextabhängig wird dem Administrator auch ein Hilfemenü sowie eine Reihe von Recherche-Werkzeugen angeboten (ping, traceroute, nslookup etc.).

Die Konsole integriert die zuvor geschilderten Aspekte wie Steuerung der TSOM-Komponenten, Setzen von Filtern für Recherchen, Anzeige importierter Informationen über Assets etc. Hierzu öffnen sich nach Bedarf neue Browser-Fenster.

Ziel der Arbeit mit TSOM und insbesondere der Konsole ist die Integration in bestehende Vorfall-Bearbeitungsprozesse. Außer den bereits genannten Aktionen als Ergebnis einer Korrelation stehen hierfür folgende weitere Standard-Möglichkeiten der Aktion/Reaktion zur Verfügung:

– Generierung von Vorfall-Tickets in bestehenden Ticketing-Systemen wie Remedy

– Weitergabe von Ereignis-Informationen in diese Ticketing-Systeme für die effiziente Abarbeitung

– Automatisierung von Standard-Reaktionen durch die Ausführung generischer Skripte

TSOM stellt von Haus aus mehr als 70 technische und 40 Compliance-Berichtsvorlagen zur Verfügung. Diese können bearbeitet werden, neue Berichtsvorlagen können ebenfalls hinzugefügt werden. Die Berichte können automatisch erstellt werden und in den Formaten, XMP, HTML, PS und PDF ausgegeben werden. Sie können Benutzern per E-Mail oder als Datei auf einer Verzeichnis-Freigabe zur Verfügung gestellt werden.

Für die Benutzerauthentifizierung steht LDAP zur Verfügung.

Benutzerrechte werden innerhalb des Produkts definiert und auf Gruppen-Ebene zugewiesen. Es steht ein rollenbasiertes Zugriffskonzept zur Verfügung. Die Aktionen der Systembenutzer werden mitprotokolliert, so dass eine Nachvollziehbarkeit der durchgeführten Aktionen möglich ist. Der Zugriff auf Daten innerhalb des Systems kann über ein rollenbasiertes Konzept reglementiert werden.


Logdatenstudie

Sicherstellung der Verfügbarkeit des SystemsSeit der aktuellen Software-Version von TSOM wird die Administration der Systemkomponenten über die zentrale CSM-Konsole durchgeführt.

Eine Status-Überwachung der TSOM-eigenen Komponenten kann über Korrelationsregeln realisiert werden. Die Datenbank wird separat überwacht und muss nur minimal administriert werden, die Mehrzahl an Tätigkeiten wird automatisch ausgeführt.

Die Systemkomponenten EAM, USM und CSM müssen dezentral nach Bedarf aktualisiert werden.

5.3.12 Symantec „Security Information Manager“

Die amerikanische Firma Symantec bietet auf dem Markt der IT-Frühwarnsysteme das Produkt Symantec Security Information Manager (SSIM) an. Der Fokus dieses Produkts liegt auf der Echtzeit-Auswertung von Logdaten zum Zwecke der IT-Frühwarnung sowie in der Erstellung von bedarfsgesteuerten Berichten auf der Basis der gesammelten Informationen.

Die Lösung ist auf die Bedürfnisse von Behörden und Unternehmen ab dem Mittelstand bis hin zu Großkunden ausgelegt.

SSIM kann eindeutig dem Bereich der spezialisierten IT-Frühwarnsysteme zugeordnet werden. Der Fokus liegt dabei auf der Erkennung von Vorfällen der IT-Sicherheit durch Integration vielfältiger Datenquellen aus dem Bereich der Log- und Monitoringdaten.

Symantec bietet neben dem angesprochenen Produkt eine Palette an weiteren Produkten aus dem Bereich der IT-Sicherheit an. Durch die Verbindung mit dem Produkt BindView aus dem Bereich des Patch- und Schwachstellen-Managements kann SSIM sinnvoll ergänzt werden.

Das Produkt wird auf Basis der zu integrierenden Datenquellen und über einen abzuschließenden Wartungsvertrag lizensiert.

SSIM ist seit Oktober 2005 erhältlich und wird seitdem kontinuierlich weiterentwickelt.

Aktuelle Version 4.5 Unterstützte Plattformen/Hardware-Serien Appliance: Dell Serie 1900 und 2900

Software: Konsole: Windows 2000 oder Windows XP

Tabelle 70: Architektur von Symantec SIM

SSIM besitzt die in der folgenden Darstellung gezeigte Architektur:


Logdatenstudie

Die folgenden produktspezifischen Begriffe werden im SIM verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Unterteilung in Collector, Agent und SensorLogkorrelator Correlation ManagerManagement-Komponente Correlation ManagerLogspeicher Filesystem (Rohdaten) und DB2-Datenbank Ereignis Event

Tabelle 71: Begriffsbestimmung bei Symantec SIM

SSIM unterstützt den Datenimport der unterschiedlichsten Datenquellen aus dem Bereich der Log- und Monitoringdaten. Es existiert keine Spezialisierung auf bestimmte Datenformate.

Ausgehend von der Quelle der Log- und Monitoringdaten nimmt der Sensor, welcher ein Teil des Konnektors ist, die Daten entgegen. Ein Sensor ist dabei keine eigenständige Software, sondern der Parser des Konnektors. Je nach Installationsart kann ein Konnektor mit dem Sensor direkt auf dem erzeugenden Gerät oder auch auf einem sich innerhalb des Netzwerkes befindlichen Konnektor-Server installiert sein. Der Konnektor nimmt die vom Sensor aufgenommenen Daten entgegen und normalisiert diese zur weiteren Verarbeitung im System.

Auf der gleichen Maschine wie der Konnektor ist der Agent installiert. Der Agent ist hierbei für die Kommunikation mit der Appliance und damit auch für die Kommunikation mit dem Management zuständig. Des Weiteren werden durch den Agenten die Konfigurationen aus dem Verzeichnisdienst für den Agenten und die Kollektoren mit sämtlichen Sensoren abgeholt. Das Management speichert


Abbildung 5.11: Architektur von Symantec SIM

Logdatenstudie

sowohl die Rohdaten indexiert im Filesystem als auch die korrelierten Ereignisse innerhalb einer Datenbank (DB2).

Optional kann zur Performance-Optimierung eine hierarchische Architektur aufgebaut werden. Die Rohdaten verbleiben hierbei auf der Appliance der untersten Ebene, und nur die normalisierten Ereignisse werden an das zentrale Management gesendet. Optional besteht die Möglichkeit, auch hier die Rohdaten auf dem zentralen Management zu speichern.

Die Konfiguration der Filterung von nicht benötigten Daten und die Aggregation ist auf dem Agenten und damit dem Logsammler realisiert. Dies hilft dabei, die Performanz des Managements sicherzustellen.

Die Speicherung aller Daten über einen Zeitraum von 30 Tagen ist problemlos möglich. Ein Speicher-Zeitraum von 90 Tagen ist bei geeigneter Hardware-Auswahl ebenfalls gewährleistet. Gegebenenfalls lässt sich der Speicherplatz des Managements durch externe Speicherlösungen (DAS, NAS, SAN) erweitern.


– IPFIX

– NetCache

– Tomcat Servlet Container

– Microsoft Exchange

– Sendmail

– Exim

– PostFix

– Qmail

– SpamAssassin

– ISC Bind

– SAMBA

– Asterisk

– ClamAV

– NMAP


Zusätzlich zu den beschriebenen Formaten können ca. 90 weitere Datenquellen und deren Formate in die Lösung eingebunden werden.

Der Hersteller bietet eine kostenfreie Programmierschnittstelle (Parser) zur Erstellung von Sensoren für noch nicht unterstützte Datenquellen an. Die Erstellung von Sensoren wird durch einen Assistenten wirkungsvoll unterstützt.

Die Lösung führt eine vollständige Normalisierung der Rohdaten bereits auf dem Kollektor durch. Die Rohdaten bleiben dabei unverändert und werden parallel an den Manager geschickt. Die Korrelation erfolgt dabei über alle integrierten und normalisierten Datenquellen im Manager.


Logdatenstudie

Die Kommunikation zwischen dem Agenten und der Management-Appliance erfolgt verschlüsselt über ein verbindungsorientiertes Protokoll. Auf diese Weise ist die Vertraulichkeit, Integrität und Verfügbarkeit der Daten während des Transports gesichert. Auf der Management-Komponente liegen die Rohdaten in indexierten Archiven auf dem Filesystem und sind nicht verschlüsselt. Die normalisierten Daten und Konfigurationsdateien innerhalb der Datenbank sind ebenfalls nicht verschlüsselt. Die Appliance läuft auf einem gehärteten Red Hat Enterprise Linux Release 4.

Die Anonymisierung der einlaufenden Meldungen ist im Auslieferungszustand nicht enthalten. Über das erhältliche Rahmenwerk EventService SDK kann die Anonymisierung vom Hersteller für den Kunden umgesetzt werden.

Ereignis-Entdeckung und ihre UnterstützungDie Verarbeitung von großen Datenmengen und deren Reduzierung auf die relevanten Ereignisse ist innerhalb der Lösung wie folgt gelöst.

Die Modellierung innerhalb der Lösung kann manuell oder durch einen Import der Daten eines Schwachstellen-Scanner erfolgen. Die Abbildung der Netzwerkumgebung ist dabei nicht enthalten. Den angelegten oder importierten Systemen können Werte für die Attribute Vertraulichkeit, Integrität und Verfügbarkeit mitgegeben werden. Der Schwachstellen-Scanner steuert Informationen zu offenen Ports und Diensten, sowie erkannten Schwachstellen bei. Diese fließen neben den Werten der Sicherheit direkt in den Algorithmus zur Priorisierung während der Korrelation ein.

Die Klassifizierung besonderer Systeme wie Schwachstellen-Scanner ist in Symantec SIM integriert, so dass ihre irrtümliche Identifikation als Angreifer vermieden werden kann. Ferner können Ausnahmelisten (White Lists) befüllt werden, um fälschlicherweise als Angreifer deklarierte Systeme aus der Korrelation auszunehmen.

Die Korrelation der eintreffenden Daten erfolgt in SSIM quasi in Echtzeit, kann aber auch auf bereits bestehende Datenbestände und zurückliegende Zeiträume angewandt werden.

Der Hersteller liefert eine ganze Reihe vordefinierter Regeln zur Korrelation bereits mit dem Produkt zusammen aus. Die Anpassung bestehender und Definition eigener Regeln ist in die Lösung integriert. Die Erstellung eigener Regeln ist über einen Definitionsassistenten gelöst.

Die Verknüpfung mehrerer Meldungen über logische Operatoren inkl. Negation ist neben der Angabe von Schwellwerten und einer Auswahl an Aktionen für die Regelerstellung verfügbar. Die Einbindung unterschiedlicher Datenquellen und spezifischer Teilinformationen von Meldungen ist durchgängig realisiert.

Mithilfe dieser Regeloptionen ist es möglich, sowohl generische Mustererkennung als auch eine konkrete Mustererkennung durchzuführen.

Für die Ausgabe der Korrelationsergebnisse stehen die folgenden Aktionen zur Verfügung:

– Anzeige in der Administrationskonsole

– E-Mail

– Eingebautes Ticketing-System mit Schnittstelle zu HP OpenView, Remedy und Peregrine

– Versenden von SNMP-Traps

– Erzeugung einer weiteren Logmeldung im System

– Offene Programmierschnittstelle zur Entwicklung weiterer Benachrichtigungsarten


Logdatenstudie

Eine Besonderheit des Herstellers Symantec ist DeepSight, die Integration der Daten des Global Intelligence Networks (GIN), welches ein über den Globus verteiltes Security Operations Center mit mehreren Standorten bietet. Die dort anonymisiert auflaufenden Daten anderer Kunden des Herstellers liefern fundierte Daten über aktuelle Top-Angreifer und Angriffstechniken. Die Lösung integriert diese Daten und behandelt IP-Adressen mit Auffälligkeiten in GIN mit hoher Priorität.

Die Einstufung von Ereignissen erfolgt in 5 Stufen, wobei Stufe 5 die höchste Priorität klassifiziert. Die Priorisierung führt SSIM automatisch unter Hinzunahme der modellierten Werte und der Informationen eines optionalen Schwachstellen-Scanners durch. Die Berücksichtigung der Vorgeschichte eines Angreifers erfolgt über DeepSight. Dies ist ein Dienst, den Symantec seinen Kunden separat anbietet: Mittels gesammelter Informationen aus einem globalen Netzwerk von Überwachungsstationen werden fortlaufend aktuelle Sicherheitsinformationen gesammelt und den Kunden zur Verfügung gestellt. Deepsight-Informationen kann SSIM automatisiert berücksichtigen.

Die Verfügbarkeit der Lösung ist in erster Linie über redundante Management-Komponenten und die Übertragung von Meldungen vom Logsammler zum Management realisiert. Hierzu gehört auch die Gruppierung von Events zur Übertragung (Aggregation), die Kompression vor der Übertragung, das Speichern in einer Warteschlange(Caching), falls die Appliance nicht erreichbar ist, und ggf. auch der Failover zu einer zweiten Appliance.

Benutzerinteraktion und VorfallsbearbeitungFür die tägliche Arbeit mit SSIM steht eine proprietäre Benutzeroberfläche zur Verfügung, die auf den Arbeitsplatzrechnern der Analysten und Administratoren installiert werden muss. Weiterhin gibt es eine Weboberfläche und einen Konsolenzugang für die Installation und administrative Vorgänge.

Die SSIM Konsole beinhaltet die Visualisierung von Informationen über den Zustand von Agenten, Kollektoren und Sensoren. Hiermit ist es möglich, einen schnellen Überblick über die komplette Umgebung, den Zustand und Event-Raten zu erhalten. Vorfälle werden in der Incident-Sicht dargestellt. Diese Sicht bietet vordefinierte Filter, damit der Anwender sich auf die Vorfälle konzentrieren kann, die seiner Aufmerksamkeit bedürfen.

Die Lösung bietet ferner einen Report-Generator bei dem mittels Drag&Drop eigene Reports auf einfache Weise selbst erstellt werden können. Die Lösung bringt keine vordefinierten Reports im Auslieferungszustand mit. Es sind aber 200 vordefinierte Datenbankabfragen in zu erstellende Reports integrierbar. SSIM unterstützt folgende Ausgabeformate:

– PDF

– HTML

– XML

Die Reports können zeitgesteuert an die jeweiligen Empfänger per Mail versendet werden.

Der Zugriff auf Events und Vorfälle, Funktionen der Konsole und Sichten kann rollenbasiert definiert werden. Ein Benutzer kann durch die Zuordnung einer Rolle so eingeschränkt werden, dass er etwa nur Zugriff auf einige Berichte oder die Daten einer bestimmten Datenquelle erhält. Einstellungen von SSIM, die Benutzern, Rollen, Sensoren und Agenten betreffen, werden in einem LDAP-Verzeichnisdienst abgelegt.


Logdatenstudie

Zum momentanen Zeitpunkt (v4.5) können sich Benutzer ausschließlich direkt an der Appliance mittels Benutzername und Passwort authentifizieren. Die Erweiterung auf externe Authentifizierungsverfahren mittels Active Directory ist für die kommende Version des Produkts geplant.

Sicherstellung der Verfügbarkeit des SystemsSSIM hat innerhalb der Benutzeroberfläche eine Ansicht zur Überwachung der Komponenten des Systems integriert, über die auch eine Alarmierung bei Ausfällen und bei einer Überlastung stattfindet.

Die Parameter zur Pflege der indexierten Archivierung auf dem Filesystem des Managements sind innerhalb der grafischen Benutzeroberfläche angesiedelt. Diese beinhalten die Konfiguration des Speicherplatzes und die Aufbewahrungsdauer. Die Pflege der Datenbank ist über die Webschnittstelle des Managements realisiert. Sie wird weitgehend automatisch gepflegt und bietet eine konfigurierbare Ansicht der durchzuführenden Aufgaben. Zu konfigurieren sind die folgenden Aufgaben:

– Speicherplatzverwaltung

– Bereinigung der Datenbank

– Backup der Datenbestände

– Datenmigration

5.3.13 CA eTrust „Network Forensics“ und „Security Command Center“

Die amerikanische Firma CA (früher Computer Associates) bietet Produkte für das Management von IT-Infrastrukturen an. Teil davon sind auch IT-Sicherheitsprodukte, für den Bereich der IT-Frühwarnung kommen die Produkte eTrust Network Forensics und eTrust Security Command Center infrage. Im Folgenden wird die Leistungsfähigkeit eines kombinierten Einsatzes beider Produkte beschrieben, der seitens CA unter dem Oberbegriff eTrust Security Management angeboten wird.

Soweit nicht explizit etwas anderes vermerkt wird, gelten die folgenden Produktbeschreibungen für das Programm Network Forensics. Das Security Command Center ist als übergeordnetes Produkt und zentrale Integrationsinstanz ausgelegt und bietet Schnittstellen in die Betriebsprozesse. Zudem ist es als System für nachträgliche Auswertungen von Auditierungsdaten ausgelegt und besitzt entsprechend erweiterte Schnittstellen- und Berichtsfunktionen.

Die Lösung richtet sich an Unternehmenskunden, angefangen beim gehobenen Mittelstand, über Großunternehmen bis hin zu Service Providern.

Sie ist nicht ausschließlich auf die IT-Frühwarnung fokussiert, sondern bietet auch forensische Funktionen und Werkzeuge für ein Security Operations Center.

Quasi links und rechts dieser Lösung finden sich bei CA Produkte aus den Bereichen Identitäts- und Zugriffs-Management, Bedrohungs-Management und Mainframe-Absicherung. Außerhalb des unmittelbaren Sicherheitsfokus finden sich Lösungen zum Infrastruktur-, Anwendungsleistungs-, Speicher- und Datenbank-Management.

Die Lizensierung der beiden Produkte berücksichtigt zentrale Komponenten wie Server sowie Agenten und Analyse-Komponenten. Sie ist im Detail unterschiedlich für die beiden Produkte Network Forensics und Security Operations Center.

Die Lösungen von CA sind bereits seit ca. zehn Jahren am Markt erhältlich.


Logdatenstudie

Aktuelle Version Network Forensics: r8.5Security Command Center: r8

Unterstützte Plattformen/Hardware-Serien Optional als Appliance; sonst Windows, Linux, Unix

Tabelle 72: Version und Plattformen von CA eTrust

Zusammenführung von Log- und MonitoringdatenNetwork Forensics besitzt die in folgender Abbildung dargestellte Architektur:


Abbildung 5.12: Architektur von CA eTrust

Logdatenstudie

Folgende produktspezifische Begriffe werden von CA eTrust verwendet:

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler CollectorLogkorrelator AnalyzerManagement-Komponente Analysis PlatformLogspeicher Loader und Datenbank (Ingres, MS SQL oder Oracle)Ereignis Ereignis

Tabelle 73: Begriffsbestimmung bei CA eTrust

Die Lösung ist auf die Verarbeitung von ASCII-basierten Logdaten aller möglichen Datenquellen ausgerichtet.

Über eine dezentrale Software-Komponente, einen Agenten, werden die Logdaten eingesammelt und an den zentralen Network Forensics Server weitergeleitet. Die Log- und Monitoringdaten werden dabei über verschiedene Mechanismen und Protokolle von den Datenquellen zu den Agenten transferiert, wobei die Sicherheit des jeweiligen Übertragungsprotokolls (Syslog, CP LEA, SSL etc.) zum Tragen kommt. Ab dem Agenten werden die Daten proprietär verschlüsselt übertragen. Der Agent besteht bei Network Forensics aus einer Collector-Komponente zum Aufgreifen der ASCII-Daten und einer Loader-Komponente zum Übertragen der Logdaten an die zentrale Datenbank. Als relationale Datenbanken werden Ingres, Microsoft SQL sowie Oracle unterstützt.

Auf Agenten-Ebene kann eine Filterung der Daten durchgeführt werden. Die Daten können aggregiert werden, eine Normalisierung findet aber nicht statt. Sie werden vollständig in originalen Format oder alternativ gekürzt übertragen. Binäre Daten werden, sofern die Datenquelle unterstützt wird, in eine lesbare Form umgeschrieben, bevor sie an zentrale Stelle übertragen werden.

Die Langzeitspeicherung von Daten ist bei eTrust Network Forensics in erster Linie eine Frage der bereitgestellten Ressourcen im Datenbankbereich. Eine Speicherung von 30 Tagen ist im Projekt aber durchaus typisch und wird regelmäßig so umgesetzt.

Da die Daten nicht normalisiert werden, ist ein generischer Support für alle ASCII-basierten Logformate realisiert. Ein Parsing der Daten entfällt weitestgehend.

Durch die verschlüsselte Datenübertragung ab dem Agenten-Level können die Schutzziele der Integrität und Authentizität der Daten sichergestellt werden. Ein datenquellennaher Einsatz der Agenten ist somit eine Option für Umgebungen mit entsprechenden Anforderungen an die Behandlung von Log- und Monitoringdaten. Allerdings kommen seitens eTrust nicht öffentlich gemachte, proprietäre Algorithmen zum Einsatz.

Optional können die abgelegten Log- und Monitoringdaten signiert werden, sodass die Authentizität auch auf zentraler Seite dauerhaft gewährleistet ist.

Ereignis-Entdeckung und ihre UnterstützungUm aus aus Millionen von Logmeldungen die wesentlichen Ereignisse herauszugreifen, besitzt das eTrust Security Management nur Basisfunktionen:


Logdatenstudie

Grundsätzlich kann keine Modellierung des überwachten IT-Verbunds im eigentlichen Sinne durchgeführt werden. Es können keine Netzwerke angelegt werden, welche die tatsächlichen Begebenheiten widerspiegeln, das gleiche gilt für Assets oder Eigenschaften dieser. Es werden auch keine Schnittstellen zu Schwachstellen-Scannern angeboten.

Ohne Modellierung finden sich dennoch die üblichen Funktionen zur Korrelation von Einzelereignissen sowie zwei oder mehr Ereignissen. Schwellwertüberschreitungen, logische Verknüpfungen. Abfragen auf Inhalte von Ereignismeldungen sind möglich. Die Korrelationen finden in Network Forensics fortwährend in Echtzeit statt. Hierfür stellt das Produkt ein Standard-Regelwerk zur Verfügung, das editiert werden und um eigene Regeln erweitert werden kann.

Aufgrund einer nicht durchgeführten Normalisierung fußen die Regeln auf spezifischen Ereigniseigenschaften, z. B. auf speziellen Strings. Korrelationen können somit nicht datenquellenunabhängig durchgeführt werden.

Eine fortwährende statistische Datenanalyse findet nicht statt. Es können aber im Nachgang Abfragen an das System gestellt werden, die eine statistische Aufbereitung der gesammelten Daten durchführen.

Für die Erkennung von Angriffen kann auf eine generische Mustererkennung zurückgegriffen werden. Eine konkrete Mustererkennung ist jedoch nur indirekt über die Ergebnisse aus IDS-/IPS-Systemen möglich.

In die Korrelationen fließen keine Erkenntnisse über die Vorgeschichte von Angreifer oder Opfer ein. Entsprechende Mechanismen sind nicht verfügbar.

Als Ergebnis einer Korrelation kann das eTrust Security Management neben der Erzeugung eines neuen sog. Meta-Ereignisses eine Reihe von Aktionen durchführen:

● Versenden von E-Mails

● Pager-Nachricht

● SMS

● SNMP-Trap-Versendung

● Trouble-Ticket-Generierung

Eine Priorisierung wichtiger Ereignismeldungen kann nur auf der Basis von Filterungen durchgeführt werden. Sie muss damit insbesondere manuell vorgenommen werden.

eTrust Network Forensics setzt darüber hinaus vorrangig auf Visualisierungstechniken, um Abweichungen von normalem Verhalten aufzuzeigen.

Die Sicherstellung der System-Performance für die Ereignis-Entdeckung, also die Sicherung genügender Systemressourcen, erfolgt durch die gezielte Vorfilterung von uninteressanten Logmeldungen und indem eine möglichst hohe Hardware-Performance bereitgestellt wird.

Benutzerinteraktion und VorfallsbearbeitungFür die alltägliche Arbeit im eTrust Security Manager System stehen drei verschiedene Benutzeroberflächen zur Verfügung: ein Web-Interface, ein Windows-Interface sowie eine Java-Konsole. Hauptsächlich wird mit dem webbasierten Interface gearbeitet. Dieses bietet eine kontextbasierte Hilfefunktion, arbeitet aber nicht mit Kontext-Menüs. Die Benutzeroberfläche wird typischerweise


Logdatenstudie

an die Bedürfnisse des jeweiligen Benutzers angepasst, um ein rollenbasiertes Benutzerkonzept umzusetzen.

Die Lösung fokussiert sich sehr stark auf die Visualisierung der Ereignisse und Abläufe, welche in den Konsolen dargestellt werden.

Außer den bereits genannten Aktionen als Ergebnis einer Korrelation stehen hierfür folgende weitere Standard-Möglichkeiten der Aktion/Reaktion zur Verfügung:

– Alarmierung in der Konsole

– Versenden eines konfigurierbaren SNMP-Traps

– Generierung von Vorfall-Tickets in bestehenden Ticketing-Systemen wie Remedy

– Weitergabe von Ereignis-Informationen in diese Ticketing-Systeme zur effizienten Abarbeitung

– Erzeugen einer neuen Logmeldung

Die Lösung bietet von Haus aus eine gewisse Zahl an Berichtsvorlagen. Diese können bearbeitet werden, außerdem können neue Berichtsvorlagen hinzugefügt werden. Des Weiteren können die Berichte automatisch in den Formaten, XML, TXT, HTML und PDF erstellt werden.

Systembenutzer werden über Benutzername/Passwort authentifiziert. Zugriffsrechte werden auf der Basis von Benutzergruppen erteilt. Tätigkeiten – insbesondere die der Gruppe der Administratoren – werden mitprotokolliert.

Es gibt kein Rollenkonzept zur Trennung von Inhalten auf der Zugriffsebene zur Einhaltung des Datenschutzes.

Sicherstellung der Verfügbarkeit des SystemsFür die Selbstüberwachung des Network Forensics Systems ist der Einbau einer optionalen Komponente in das Security Command Center nötig. Die Überwachung findet dann von dort aus statt. Network Forensics überwacht sich nicht selbst.

5.3.14 RSA „enVision“

Die Firma RSA Security bietet mit ihrem Produkt enVision eine Lösung zur Auswertung von Log- und Monitoringdaten an. Der Fokus des Produktes liegt auf der zentralen Auswertung von Log- und Monitoringdaten zum Zwecke der IT-Frühwarnung in Echtzeit sowie der forensischen Analyse.

Die Lösung eignet sich für Unternehmensanwender, angefangen beim Mittelstand über Großkunden bis hin zu Service Providern mit eigenem Kundenstamm.

Dabei kann enVision als Lösung zur Logdatenauswertung mit Funktionen aus dem Bereich der IT-Frühwarnung durch Korrelation in Echtzeit eingestuft werden. Dies zeigt sich anhand der Fähigkeit des Systems, auch große Datenmengen zentralisiert zu speichern.

Neben enVision hat der Hersteller keine weiteren Produkte im Segment der IT-Frühwarnung im Portfolio.

Da es sich bei enVision um eine Appliance-Lösung handelt, ist die Anzahl der zu integrierenden Datenquellen über die Leistungsfähigkeit der erworbenen Appliance limitiert. Für bis zu 7.500 EPS und 1.250 überwachter Geräte kommt das Modell ES zum Einsatz. Darüber hinaus kann bei


Logdatenstudie

300.000 EPS und 30.000 Systemen das Modell LS (in unterschiedliche Ausbaustufen) eingesetzt werden. Daneben sind die obligatorischen Wartungsverträge abzuschließen.

Das Produkt enVision ist bereits seit 10 Jahren auf dem Markt verfügbar und unterliegt einer stetigen Entwicklung.

Aktuelle Version 3.5Unterstützte Plattformen/Hardware-Serien Reine appliancebasierte Lösung

Tabelle 74: Version und Plattformen von RSA enVision

Zusammenführung von Log- und MonitoringdatenDas Produkt enVision ist spezialisiert auf die zentrale Zusammenführung der Meldungen unterschiedlichster Datenquellen und deren Auswertung, die nahezu in Echtzeit erfolgt.

Die Produktarchitektur besteht aus einer Reihe von Appliances, angefangen von 500 Meldungen pro Sekunde (EPS) bis zu einer Leistung von 300.000 EPS durch Kaskadierung. Auf der Appliance läuft ein gehärtetes und im Hinblick auf dessen Performance optimiertes Windows 2003 Server als Betriebssystem. Das System arbeitet gänzlich ohne externe Logsammler. Die eingebundenen Datenquellen werden direkt in eine Appliance integriert. Hierzu verwendet das System entweder Push- oder Pull-Mechanismen, um die Meldungen zu empfangen oder abzuholen. Die Verarbeitung und auch die Speicherung der Meldungen erfolgt direkt auf der Appliance oder über ein angebundenes DAS oder SAN. Der Hersteller hat zur Speicherung eine eigene, patentierte Datenbank entwickelt, die sich Internet Protocol Database (IPDB) nennt.

Nachfolgend eine Architekturskizze einer verteilten Installation:


Abbildung 5.13: Architektur von RSA enVision

Logdatenstudie

Die Architekturskizze zeigt eine verteilte Architektur von insgesamt 6 Lokationen. Die zentrale Site ist dabei Site 1. An Site 2 sind die Sites 3 und 4 angebunden und werden von dort administriert. Site 6 ist an Site 5 gekoppelt und von dort aus administriert. Insgesamt arbeitet RSA enVision mit drei Datenbanken und drei Management-Konsolen gearbeitet.

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Local Collector (LC) oder Remote Collector

(RC); beides sind AppliancesLogkorrelator CorrelationManagement-Komponente Application ServerLogspeicher DatabaseEreignis Event

Tabelle 75: Begriffsbestimmung bei RSA enVision

Das System verarbeitet sowohl Log- als auch Monitoringdaten unterschiedlichster Geräteklassen. Hierzu gehören neben ereignisbezogenen Daten auch Monitoringdaten, beispielsweise von Switches und Routern.

Alle originalen Daten werden an eine Appliance übertragen und von dieser gespeichert. In verteilten Umgebungen ist die zentrale Speicherung bedingt durch teilweise hohe Raten an Meldungen nicht möglich. Bei diesem Anwendungsszenario werden die Rohdaten dezentral gespeichert und nur bei Bedarf an das zentrale Management gesendet.

Aufgrund des Einsatzes von Appliances unterstützt die Lösung keine Filterung von nicht benötigten Daten. Eine ähnliche Funktionalität lässt sich über den Aufbau einer dezentralen Architektur erreichen.

Die Möglichkeit, mehrere gleichartige Logmeldungen zu einer zusammenzufassen ist ebenfalls kein Bestandteil des Systems.

Die Speicherung von Meldungen über einen Zeitraum von mindestens 30 Tagen ist bei allen Appliances gegeben. Als übliche Speicherdauer gibt der Hersteller einen Zeitraum von 3 Monaten bis zu einem Jahr an. Letztlich ist die Dauer der Speicherung abhängig von der Größe der Datenbank und damit an die Bedürfnisse des Kunden anpassbar.


– IPFIX

– Squid Proxy


– ISC Bind

– Sendmail

– Exim

– Postfix

– Qmail

– ClamAV


Logdatenstudie

– SAMBA

– Asterisk

– Tomcat

– NMAP

– Nessus

– Qualys Guard


Zusätzlich zu den dargestellten Datenquellen und deren Formate unterstützt enVision ca. 70 weitere Datenquellen. Die Liste der Datenquellen befindet sich im nicht öffentlichen Bereich der Homepage des Hersteller. Deshalb kann hier nur der Link zur Homepage des Produktes angegeben werden:

http://www.rsa.com/node.aspx?id=3170#

RSA enVision bietet einen Universal Device Support (UDS), womit noch nicht unterstützte Datenquellen eingebunden werden können. Dies kann bei entsprechenden Kenntnissen durch den Kunden, offizielle Partner oder den RSA Prof. Service vorgenommen werden.

Eine Normalisierung der eintreffenden Meldungen wird indes nicht durchgeführt. Die Verarbeitung und insbesondere die Korrelation von Meldungen bezieht sich also immer auf produktspezifische Felder innerhalb der ursprünglichen Meldung.

Da die Lösung allein auf Appliances basiert, muss die Übertragung der Meldungen zur Appliance mittels der von der Datenquelle zur Verfügung gestellten Protokolle erfolgen. Oftmals sind in diese Übertragungsprotokolle jedoch keine Sicherungsmaßnahmen integriert. Die Übertragung zwischen den Appliances findet in diesem Fall in Klartext statt. Allerdings sind die übertragenen Daten verschlüsselt. Auch in der Datenbank des Systems liegen alle gespeicherten Daten verschlüsselt vor. Die Anonymisierung oder Pseudonymisierung von Daten ist nicht möglich.

Ereignis-Entdeckung und ihre UnterstützungÜber XML- oder über DHCP-Abfragen lassen sich die Systemdaten aus externen Systemen (DHCP, Asset-Management) in die Lösung importieren, um sie dort abzubilden. Gleiches gilt, wenn die Daten eines Schwachstellen-Managements für die Korrelation hinzugezogen werden. Innerhalb der einzelnen Assets ist der Wert „Importance“ zu setzen, da dieser für die Korrelation verwendet wird. EnVision bietet keine Funktionen zur Abbildung der Netzwerkumgebung innerhalb des Systems.

Um wichtige Ereignisse aus einer Flut an einzelnen Meldungen herauszuarbeiten, ist in enVision ein Algorithmus zur Korrelation integriert. Die Korrelation läuft permanent im Hintergrund und ermöglicht damit die Entdeckung von sicherheitsrelevanten Ereignissen, die nahezu in Echtzeit erfolgt.

Innerhalb einer Korrelationsregel können die folgenden Parameter Verwendung finden:

– Verknüpfung mehrerer Ereignisse durch logische Operatoren

– Abfragen auf die Datenklasse der Datenquelle oder den Inhalt eines Meldungsfeldes

– Schwellwerte

– Angabe von Zeiträumen, in denen die einzelnen Ereignisse stattgefunden haben


http://www.rsa.com/node.aspx?id=3170

Logdatenstudie

– Aktionen

Eine produktunabhängige Korrelation durch normalisierte Meldungen findet indes nicht statt. Einzig die angesprochene Verwendung von Produktkategorien (Firewall, IDS etc.) erleichtert die globalere Definition von Korrelationsregeln.

Die Lösung bringt bereits im Auslieferungszustand eine Reihe an Korrelationsregeln mit. Diese können an die Bedürfnisse des Kunden angepasst, außerdem können eigene Regeln hinzugefügt werden.

Die Erkennung von spezifischen Attacken ist über die Einbindung von IDS-/IPS-Systemen möglich. Ebenso können beispielsweise Würmer mithilfe von Regeln, die auf dem Verhalten dieser Würmer basieren, entdeckt werden.

Die Berücksichtigung der Vorgeschichte eines Angreifers oder des Zielsystems wird nicht automatisiert vorgenommen. Hier sind manuell neue Regeln zu definieren.

Für die optimierte Bearbeitung von Ereignissen nach Priorität ist in die Lösung ein Korrelationsalgorithmus integriert. Dieser verwendet für die Berechnung der Priorität auch die in den Assets definierte Gewichtung (Importance) und die Schwachstellen. Somit ist die Priorisierung nicht statisch, sondern kann vom Benutzer des Systems verändert werden. Dies ermöglicht die Abbildung der Kritikalität eines Systems. Das System priorisiert erkannte Ereignisse in fünf Stufen.

Um die Performance der Lösung sicherzustellen, besitzen die in einer verteilten Installation eingebundenen Appliances einen Puffer. Dieser beugt dem Verlust von Meldungen durch Spitzenlasten oder einem Ausfall einer nach gelagerten Appliance vor.

Benutzerinteraktion und VorfallsbearbeitungDie Administration und die Analyse von Vorfällen erfolgt über ein Web-Interface. Dieses stellt die zentrale Benutzeroberfläche dar.

EnVision unterstützt die Analyse von Ereignissen durch Setzen von Ereignisfiltern. Außerdem können die Informationen aus einem Schwachstellen-Management angezeigt werden. Ein Kontextmenü, welches den Analysten durch vordefinierte Vorschlagswerte unterstützt, ist nicht im Funktionsumfang enthalten. Um eine tiefer gehende Analyse von Ereignissen unter Ansicht der einzelnen Meldungen durchzuführen, wird ein weiteres Programm benötigt. Dieses Event Explorer genannte Programm ist von der eigentlichen Analyse getrennt.

Für die Benachrichtigung bei erkannten Ereignissen stehen neben der Anzeige dieser Events in der Konsole des Analysten zusätzlich die folgenden Mechanismen zur Verfügung:

– Syslog-Eintrag

– Instant-Messaging-Nachricht

– E-Mail

– SNMP-Trap

– Nachricht an ein Ticket-System

Die Lösung beinhaltet bereits im Auslieferungszustand eine Vielzahl unterschiedlicher Berichte. Diese sind sowohl auf die Bedürfnisse von Managern als auch von technischem Personal zugeschnitten. Es ist ferner möglich, bestehende Berichte an die Bedürfnisse des Kunden anzupassen und auch eigene Berichtvorlagen zu erstellen. Berichte können sowohl ereignis- als auch zeitgesteu


Logdatenstudie

ert generiert werden. Dabei stehen die folgenden Formate für die Generierung von Berichten zur Auswahl:

– PDF

– HTML

– CSV

– Textdatei

Das System hat ein Rollenkonzept zur Erfüllung unterschiedlicher Aufgaben im System durchgängig implementiert. Dieses beinhaltet auch die Definition von Gruppen und die Zuweisung von Rechten für diese. Die Berechtigungsstruktur bietet auch die Vergabe von Sichten für Benutzer und Gruppen, so dass diese nur die zugehörigen Datenquellen und Ereignisse einsehen können. Alle Benutzeraktionen werden im System revisionssicher gespeichert und können nicht verändert werden. Für die Authentifizierung von Benutzern am System ist momentan die Eingabe von Benutzername und Passwort integriert. An der Implementierung von externen Authentifizierungsmechanismen wird gearbeitet.

Sicherstellung der Verfügbarkeit des SystemsDie Aktualisierung des Systems erfolgt manuell. Der Hersteller kündigt Produktaktualisierungen an und unterstützt den Vorgang durch entsprechende Dokumente. Die Speicherplatzverwaltung der Datenbank ist weitgehend automatisiert und erfordert fast keine manuellen Eingriffe. Hierzu gehört auch die Sicherung der Datenbank nach definierten Aktionsplänen auf dem System. Die Backups sind durch geeignete Mechanismen vom System an andere Speicherorte zu transferieren. Die enVision Appliance enthält einen System Monitor mit Informationen über die Festplattenauslastung, Performance und Meldungen pro Sekunde (EPS = Events per Second). Diese können als Alarm innerhalb von Regeln verarbeitet werden und über die dargestellten Benachrichtigungsmechanismen gemeldet werden. Alternativ/parallel dazu kann die Appliance mittels eines Agenten einer Lösung aus dem Bereich des Monitorings überwacht werden.

5.3.15 Novell „Sentinel“

Die amerikanische Fa. Novell bietet auf dem Markt der Produkte zur Auswertung von Log- und Monitoringdaten die Lösung Sentinel an. Der Fokus des Produktes liegt auf der Echtzeit-Auswertung unterschiedlicher Datenquellen, der Berichterstellung von Ereignissen und der Sicherstellung der Compliance von Unternehmen zu verschiedenen Standards.

Die Lösung richtet sich an Behörden und Firmenkunden, die zum Teil dem Mittelstand zuzurechnen sind, sowie an Großkunden. Außerdem wird sie auch für Service Provider vom Hersteller empfohlen.

Novell Sentinel kann eindeutig dem Bereich der spezialisierten IT-Frühwarnsysteme zur Erkennung von sicherheitsrelevanten Ereignissen und der Unterstützung von Compliance-Themen zugeordnet werden. Dies zeigt sich durch die Einbindung unterschiedlichster Datenquellen aus dem Bereich der Log- und Monitoringdaten.

Die Lizensierung erfolgt grundsätzlich nach der Anzahl und dem Typ der überwachten Endpunkte (z. B. Server). Die Basisinstallation enthält bereits alle benötigten Laufzeitkomponenten sowie Lizenzen für 100 Novell-Endpunkte und 25 Microsoft Windows-Endpunkte. Optionale Erweiterungs


Logdatenstudie

module (Sentinel Advisor, eine komfortable Integration in Ticketing- und Help-Desk-Systeme, weitere Server-Komponenten) werden separat je Instanz lizenziert.

Das Produkt ist bereits seit 1999 erhältlich und wird von Novell kontinuierlich weiterentwickelt und im Funktionsumfang erweitert.

Aktuelle Version 6.0Unterstützte Plattformen/Hardware-Serien Reine Software-Lösung

Betriebssystem-Plattformen:SuSE Linux Enterprise ServerRed Hat Enterprise LinuxSun SolarisWindows 2000 Server SP4Windows 2003 Server Standard

Tabelle 76: Version und Plattformen von Novell Sentinel

Zusammenführung von Log- und MonitoringdatenNovell Sentinel besitzt die in der folgenden Skizze dargestellte Architektur:


Logdatenstudie

Novell Sentinel ist spezialisiert auf die Zusammenführung, Korrelation und Alarmierung unterschiedlichster Datenquellen von Log- und Monitoringdaten.

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler CollectorLogkorrelator CorrelationManagement-Komponente ManagerLogspeicher Event-DatabaseEreignis Incident

Tabelle 77: Begriffsbestimmung bei Novell Sentinel

Die Lösung überträgt in der Standardeinstellung nur normalisierte Meldungen an die Management-Komponente. Die Speicherung der ursprünglichen Meldungen kann konfiguriert werden. Die Speicherung der originalen Meldungen erfolgt dann in einem separaten Feld innerhalb der normalisierten Meldung.

Alle Meldungen werden zentral innerhalb einer relationalen Datenbank gespeichert. Sentinel unterstützt die folgenden Datenbanken:

– Oracle 9i

– Oracle 10g


Abbildung 5.14: Architektur von Novell Sentinel

Logdatenstudie

– Microsoft SQL Server 2005 Standard und Enterprise

– Microsoft SQL Server 2005 64-Bit Standard und Enterprise

Die Filterung von nicht relevanten Meldungen erfolgt bereits auf dem Logsammler. Diese Funktion kann konfiguriert und somit granular an die Bedürfnisse des Kunden angepasst werden.

Ebenfalls können auf dem Logsammler gleichartige Logmeldungen mit redundantem Informationsgehalt in diesem Zuge zu einer einzelnen Ereignismeldung zusammengefasst werden (Aggregation).

Innerhalb der Lösung werden die Daten typischerweise nach zwei bis drei Monaten archiviert, können aber für forensische Analysen wieder in das System integriert werden. Die Dauer der Aufbewahrung der Daten gibt der Hersteller bezogen auf den Zweck und speziell für Revisionszwecke mit einem Jahr an. Letztlich hängt die Aufbewahrungsdauer von den Kundenanforderungen und dem zur Verfügung stehenden Speicherplatz ab.

Aufgrund der produktunabhängigen Herangehensweise unterstützt die Lösung eine Reihe unterschiedlichster Datenquellen. Von den in Kapitel 3.2 beschriebenen Datenquellen werden die folgenden nicht unterstützt:

– IPFIX

– McAfee IntruShield IPS

– SQUID Proxy

– NetCache


– ISC Bind

– Sendmail

– Exim

– Postfix

– Qmail

– SpamAssasin

– ClamAV

– SAMBA

– Asterisk

– Tomcat

Neben den in dieser Studie beschriebenen Formaten unterstützt Sentinel momentan 46 weitere. Eine Auflistung aller aktuellen Datenquellen kann nach Anmeldung auf der Homepage des Herstellers unter folgendem Link eingesehen werden:

http://support.novell.com/products/sentinel/collectors.html

In Novell Sentinel steht ein Rahmenwerk zur Erweiterung der bestehenden Datenquellen um zusätzliche Datenfelder für die Normalisierung zur Verfügung. Dieses kann auch herangezogen werden, um noch nicht unterstützte Datenquellen einzubinden. Das Rahmenwerk ist bereits in der Basislizenz enthalten und muss nicht zusätzlich erstanden werden.


http://support.novell.com/products/sentinel/collectors.html

Logdatenstudie

Die Normalisierung findet mittels einer Basisnormalisierung auf dem Logsammler statt. Im Collector erfolgt ein Parsing der Original-Meldung. Dabei werden die entsprechenden Informationen extrahiert und den entsprechenden Attributen des Zielformates zugewiesen. Dabei sind ca. 30 Standard-Attribute durch Novell vorbelegt bzw. reserviert; ca. 200 Attribute verschiedener Datentypen können durch den Kunden frei belegt werden.

Die Meldungen vom Logsammler zur Management-Komponente sind verschlüsselt. Die Speicherung von Meldungen innerhalb der Datenbank erfolgt nicht verschlüsselt oder Signiert. Die Absicherung der Datenbestände ist somit Teil der Sicherheit des Datenbanksystems selbst. In Sentinel können spezielle Filter als "private" definiert werden, die nur die Gruppe der Datenschutzbeauftragten/des Betriebsrats/der Security Officer sehen dürfen, wenn ein dringender Tatverdacht vorliegt. Die Anonymisierung von Datenbeständen ist indes nicht Bestandteil des Systems.

Ereignis-Entdeckung und ihre UnterstützungEin wesentliches Ziel von Sentinel ist die Aufgabe, wichtige Ereignisse aus der Flut einzelner Meldungen herauszufiltern. Zur Erfüllung dieser Aufgabe bietet das System die folgenden Funktionalitäten:

Eine grafische Netzwerktopologie wird aus den in Meldungen enthaltenen Informationen automatisch aufgebaut. Die einzelnen Systeme innerhalb dieses Netzverbundes können über Asset-Datenbanken importiert oder auch durch die Berichte eingebundener Schwachstellen-Scanner generiert werden. Durch die Informationen der Schwachstellen-Scanner lassen sich weitere Parameter wie Betriebssystem, Schwachstellen etc. zuweisen. Die Abbildung des Schutzbedarfs eines Systems erfolgt manuell und dient dem System zur Durchführung der Korrelation.

Alle in das System einlaufenden Daten werden in nahe Echtzeit verarbeitet, gespeichert und für die Korrelation im Arbeitsspeicher der Management-Komponente vorgehalten. Hierbei lassen sich einfache Filtern, aber auch komplexe Sequenzen aus mehreren Bedingungen erstellen. Die Verknüpfung der einzelnen Bedingungen erfolgt flexibel mittels logischer Operatoren. Auch die Definition von Schwellwerten innerhalb einer Regel ist Bestandteil des Funktionsumfangs.

Zur Alarmierung stehen neben der Anzeige von Ereignissen in der Konsole die folgenden Aktionen zur Verfügung:

– Hinzufügen oder Entfernen von einer dynamischen Liste

– Anstoß eines Workflows, welcher in Sentinel definiert wurde

– E-Mail

– Aufrufen eines Programms

Die Korrelation der Daten findet durch die Normalisierung produktunabhängig statt und kann somit generisch für verschiedene Produkte innerhalb einer Produktklasse durchgeführt werden.

Der Hersteller liefert im Auslieferungszustand ein Standardregelwerk mit. Dieses kann durch den Kunden angepasst und erweitert werden. Die generische Erkennung von Wurmausbrüchen anhand einer Abweichung vom Normverhalten, aber auch die Erkennung spezifischer Attacken sind Teil dieses Regelwerkes.

Die Vorgeschichte eines Angreifers oder eines Zielsystems berücksichtigt Sentinel über dynamische Listen, in die zum Beispiel Angreifer, die Netzwerk-Scans durchgeführt haben, aufgenommen werden. Bei weiteren Angriffen ist der nachfolgende Angriff dann höher priorisiert.


Logdatenstudie

Die Priorisierung der korrelierten Meldungen erfolgt mithilfe eines Algorithmus und erfordert deshalb die Modellierung der Assets. Der Korrelationsalgorithmus verwendet die in den Assets hinterlegten Informationen Sensitivity und Asset Value sowie den in den Regeln hinterlegten Schweregrad. Zusätzlich kann ein Benutzer mit administrativen Rechten manuell die Priorität innerhalb der Korrelationsregeln verändern.

Durch die Anwendung von Filtern und auch die Aggregation auf den Logsammlern können effektive Maßnahmen zur Verbesserung der Performance der Lösung vorgenommen werden. Daneben besitzen die Logsammler einen lokalen Puffer, um Meldungen in Überlastsituationen oder bei einem Ausfall der Management-Komponente zwischenzuspeichern und nach Behebung der Verzögerung zu übertragen.

Benutzerinteraktion und VorfallsbearbeitungDie Administration des Systems und auch die Analyse von Ereignissen findet mittels einer Java-Konsole statt. Diese ist auf den Arbeitsstationen der Benutzer zu installieren. Einzig das Reporting kann über einen Browser per Web-Schnittstelle vorgenommen werden.

Zur Unterstützung der Analyse ist ein Kontextmenü Bestandteil der Lösung. Dieses kann durch einen Rechtsklick aktiviert werden. Des Weiteren können verschiedene Details eines Vorfalls ausgewählt werden, wie z. B. Ereignisse, die mit dem Vorfall in Verbindung stehen, oder Listen aller Bestände, die von dem Vorfall betroffen sind. Ferner werden Angriffsinformationen sowie Anfälligkeiten aus den Berichten eines Schwachstellen-Scanners angezeigt.

Für die Alarmierung von Benutzern bietet Sentinel neben der Anzeige von Ereignissen in der Konsole die folgenden Schnittstellen:

– Versand einer E-Mail

– Versand von SNMP-Traps

– Weiterleitung an ein externes Ticketing-System

– Aufrufen eines Programms

– Anstoßen eines Workflows

Da innerhalb von Sentinel granulare Workflows definiert werden können, ist zudem die korrekte Abarbeitung von Vorfällen sicher gestellt.

Im Auslieferungszustand des Systems sind bereits eine Reihe an Berichten sowohl für das Management als auch für technisches Personal enthalten. Diese sind zeitlich gesteuert zu erstellen und werden in der Webschnittstelle angezeigt und per Mail versandt. Sentinel unterstützt die folgen Formate für die Erstellung der Berichte:

– PDF

– HTML

– XML

– Textdatei

– Crystal Reports-Format


Logdatenstudie

Die Authentifizierung von Benutzern erfolgt ausschließlich mittels Benutzername und Passwort. Die Einbindung externer Authentifizierungsmechanismen ist zum Zeitpunkt der Erstellung dieser Studie nicht möglich.

Die Zugriffsrechte auf die Ressourcen des Systems lassen sich auf Gruppenebene und auch für einzelne Anwender einstellen. Die Rechte eines Benutzers oder einer Gruppe lassen sich granular für bestimmte Regeln, Datenquellen etc. konfigurieren. Hiermit ist es möglich, die angezeigten Daten und Funktionen des Systems auszublenden und auch eine Anonymisierung vorzunehmen. Ein Rollenkonzept für bestimmte Tätigkeiten innerhalb der Lösung ist vollständig umgesetzt.

Die revisionssichere Speicherung aller Benutzeraktionen im System innerhalb eines Logs ist vorhanden.

Sicherstellung der Verfügbarkeit des SystemsDas Monitoring der eigenen Komponenten erfolgt ebenfalls durch das Publizieren von Ereignissen. Diese sind durch ein Attribut als interne Events gekennzeichnet und können so bei Bedarf einfach selektiert werden.

Historische Daten werden durch ein automatisiertes Verfahren regelmäßig aus der Datenbank in Flat Files ausgelagert. Die Archivierung dieser Files sowie das Backup der Datenbank selbst erfolgt außerhalb von Sentinel innerhalb der Standard-Infrastruktur des Kunden. Die Konfiguration von Regeln und Filtern kann exportiert bzw. importiert werden. Das System ist nach Ankündigung und Bereitstellung eines Updates durch den Hersteller manuell zu aktualisieren.

5.3.16 ArcSight „Enterprise Security Manager“

Die amerikanische Fa. ArcSight Inc. bietet mit der Lösung ArcSight Enterprise Security Manager (ESM) eine Lösung zur Verarbeitung von Log- und Monitoringdaten an. ArcSight hat sich auf die Entwicklung und den Vertrieb von IT-Frühwarnsystemen spezialisiert und bedient keine anderen Lösungssparten. ArcSight wurde im Jahre 2002 in in Cupertino, USA gegründet. Die erste Version von ESM erschien im gleichen Jahr.

Die Lösung verarbeitet sowohl Log- als auch Monitoringdaten. Der Fokus des Produkts liegt auf der Entdeckung von sicherheitsrelevanten Vorfällen, die nahezu in Echtzeit erfolgt.

Zusätzlich zu ESM bietet der Hersteller auch eine appliancebasierte Lösung zur Zentralisierung von Logdaten (Logger) sowie ein Produkt zur Durchführung von Gegenmaßnahmen in Verbindung mit dem IT-Frühwarnsystem an.

ArcSight ESM wird für die eingesetzte Hardware (Prozessoren) und zusätzlich für die Art der zu integrierenden Datenquellen und deren Anzahl lizenziert. Für bestimmte Datenquellen können Lizenzkosten pro IP-Adresse entstehen.

Im Fokus des Produktes sind Mittelstandskunden, Großkunden sowie Service Provider. Dabei lässt sich die Lösung flexibel an die Größe eines IT-Verbunds anpassen.

ArcSight ESM liegt in der folgenden Version und für folgende Plattformen vor:

Aktuelle Version 4.0Unterstützte Plattformen softwarebasiertes IT-Frühwarnsystem

Betriebssysteme:


Logdatenstudie

Aktuelle Version 4.0Windows 2003Sun SolarisRedHat Linux

Tabelle 78: Version und Plattformen von ArcSight ESM

Zusammenführung von Log- und MonitoringdatenEine typische Installation hat den folgenden schematischen Aufbau:

Ausgehend von den Datenquellen werden die Daten auf dezentralen Logsammlern gesammelt und von dort an die Management-Komponente gesendet. Diese speichert die Daten in einer externen Datenbank (Oracle) und verarbeitet diese. Die Speicherung der Rohdaten ist standardmäßig in ESM nicht eingestellt, kann aber konfiguriert werden. Wird das Produkt Logger verwendet, werden die Rohdaten auf dieser Appliance gespeichert.


Abbildung 5.15: Architektur von ArcSight ESM

Logdatenstudie

Produktunabhängiger Begriff Produktspezifischer BegriffLogsammler Event CollectorLogkorrelator Teil des ESM ManagersManagement-Komponente ESM ManagerLogspeicher DatabaseEreignis Event

Tabelle 79: Begriffsbestimmung bei ArcSight ESM

Die Lösung verarbeitet ereignisbezogene Daten unterschiedlichster Hersteller und auch sessionbasierte Daten (NetFlow etc).

Die Übertragung der Rohdaten ist standardmäßig nicht konfiguriert. Allerdings lässt sich die Übertragung dieser Daten konfigurieren und ist somit prinzipiell möglich.

ArcSight ESM speichert die auf der Management-Komponente einlaufenden Daten in einer Datenbank des Herstellers Oracle. Die Installation der Datenbank auf der Management-Komponente ist bei kleineren Installationen möglich. Typischerweise erfolgt die Installation aber auf einer externen Datenbank, welche auch auf einem SAN installiert sein kann.

Die Filterung von nicht benötigten Daten wird bereits auf dem Logsammler durchgeführt. Dies ist konfigurierbar und ermöglicht das Filtern bereits vor der weiteren Übertragung zur Management-Komponente.

Auch die Aggregation von gleichen Datensätzen zu einer Meldung ist auf den Logsammlern implementiert und trägt somit zur Verbesserung der Performance des Systems bei.

Die Speicherdauer der Daten im System ist abhängig vom verfügbaren Speicherplatz (standardmäßig beträgt die Speicherdauer 30 Tage online). Der Hersteller gibt die von Kunden üblicherweise verlangte Speicherung mit 90 Tagen online, 6 Monaten auf dem System und 1-2 Jahren im Archiv an.

ArcSight ESM unterstützt eine Vielzahl an herstellerspezifischen und standardisierten Datenquellen. Von den in der Übersicht der Formate aufgelisteten Datenquellen-Typen werden folgende nicht unterstützt:

– IPFIX

– SPAM Assessin

– SAMBA

– Asterisk

– Tomcat

– Clam AV

Zusätzlich zu den beschriebenen Formaten unterstützt das Produkt ca. 150 weitere Datenquellen! Unter dem folgenden Link können diese eingesehen werden:

http://www.arcsight.com/product_supported.htm

Eine Programmierschnittstelle zur Erweiterung der bereits unterstützten Datenquellen um weitere, auch proprietäre Quellen ist kostenpflichtig verfügbar.


http://www.arcsight.com/product_supported.htm

Logdatenstudie

Innerhalb der Lösung werden alle Datenfelder der ursprünglichen Meldung normalisiert und sind somit für eine produktübergreifende Korrelation verfügbar. Für Datenquellen mit nachrangigem Informationsgehalt besteht die Möglichkeit, die Normalisierung auf relevante Datenfelder zu reduzieren.

Die Kommunikation zwischen den Logsammlern und der Management-Komponente ist verschlüsselt. Diese umfasst sowohl die Übertragung der Meldungen als auch die Steuerung der Logsammler selbst. Die Speicherung der Daten innerhalb der Datenbank beinhaltet keine Verschlüsselung. Der Schutz der Daten muss über die Absicherung des Datenbanksystems erfolgen. Zur Gewährleistung des Datenschutzes können die Daten anonymisiert verarbeitet werden.

Ereignis-Entdeckung und ihre UnterstützungUm wichtige Ereignisse aus der hohen Anzahl von einzelnen Meldungen zu extrahieren, ist es notwendig, die Netzwerkumgebung und darin befindliche Systeme mit Informationen anzureichern (Modellierung). Hierfür sind die einzelnen Netze in das System einzupflegen. Weiterhin müssen die Systeme im System abgebildet werden. Dies kann über den Import der Daten von Asset-Datenbanken, manuell oder auch über einen integrierten Schwachstellen-Scanner erfolgen. Diese Systemdaten sind um weitere Informationen anzureichern. Dies können die Deklaration des Systemzwecks (Monitoring-System, DB, Active Directory etc.), die Bestimmung der Kritikalität, der Schweregrad von Auswirkungen und weitere Informationen sein. Sollte ein System als Schwachstellen-Scanner oder als Monitoring-System deklariert sein, wird dieses automatisch aus bestimmten Regeln ausgenommen. Auf diese Weise erfolgt die Reduktion von möglichen falsch-positiven Alarmen.

Alle in das System einlaufenden Daten werden nahezu in Echtzeit verarbeitet. Die Korrelation erfolgt über eine beliebige Anzahl an Ereignissen durch die Definition von Regeln. Innerhalb dieser ist es möglich, den Inhalt von Meldungen abzufragen, mit Schwellwerten zu arbeiten und die Ereignisse durch logische Operatoren zu Verknüpfen. Durch die vollständige Normalisierung der Meldungen können Korrelationsregeln generisch und damit produktunabhängig aufgebaut werden.

Im Auslieferungszustand ist bereits eine ganze Reihe von Korrelationsregeln für unterschiedlichste Analysezwecke enthalten. Diese beinhalten neben der generischen Erkennung von Anomalien (Würmer etc.) auch die Erkennung von spezifischen Angriffsmustern.

Durch die Verwendung von Listen wird die Vorgeschichte von Angreifern und Zielsystemen bei der Korrelation beachtet. So werden beispielsweise Angreifer mit einer Angriffs vorbereitenden Vergangenheit bei erneutem Auftreten von Ereignissen priorisiert behandelt.

Die Einstufung der Priorisierung findet über einen Algorithmus statt und erfordert somit keinen manuellen Eingriff in spezifische Regeln. Hierzu werden die Informationen aus den modellierten Systemen herangezogen. Zusätzlich ist es möglich, die Priorisierung auch manuell für bestimmte Angriffsszenarien in den Regeln zu definieren.

Auf den Logsammlern ist das Puffern (engl. Caching) von Meldungen implementiert. Auch können nicht benötigte Meldungen dort bereits durch Filterung verworfen werden. Durch das Puffern gehen somit keine Informationen in Überlastsituationen oder bei einem vorübergehenden Ausfall der Management-Komponente verloren. Das Filtern von Meldungen trägt zur Verbesserung der Performance des Systems bei.


Logdatenstudie

Benutzerinteraktion und VorfallsbearbeitungArcSight bietet zwei Benutzerschnittstellen zur Analyse und Administration des Systems an. Einerseits enthält es eine zu installierende Benutzerschnittstelle zur umfassenden Administration und auch Analyse. Andererseits ist die Analyse von Ereignissen und eingeschränkte Administration auch mittels eines Browsers über eine Webschnittstelle erhältlich.

Die Benutzer werden durch ein Kontextmenü bei der Analyse von Ereignissen unterstützt. Dieses ermöglicht die einfache Konfiguration weitergehender Analysen. So können zum Beispiel Abfragen zu weiteren Ereignissen auf ein Zielsystem mit einem Klick realisiert werden. Auch lassen sich bei der Integration eines Schwachstellen-Scanners weiterführende Informationen zum konkreten Angriff einsehen.

Das System bietet neben der Anzeige von korrelierten Ereignissen in der Konsole die folgenden Aktionen auf erkannte Ereignisse:

– E-Mail

– Pager

– SNMP-Traps

– Schnittstelle zu Ticketing-Systemen (Remedy, HP OpenView)

– Skriptausführung

Die erkannten Angriffe und deren Angriffspfad können durch logische Diagramme visualisiert werden. Falls bei der Modellierung der Netzwerke auch die geografischen Daten (Längen-, Breitengrad) eingegeben wurden, können die Angriffsverläufe auch auf einer Weltkarte dargestellt werden.

ArcSight ESM liefert eine ganze Reihe von Reports im Auslieferungszustand mit. Diese sind unterteilt in Gruppen und erfüllen die Anforderungen des Managements (Zusammenfassung) wie auch von Analysten (detaillierte Informationen). Außerdem ist es möglich, eigene Reports zu erstellen. Die zeitlich gesteuerte Generierung von Reports ist ein Teil der Reporting-Funktionen. Das System unterstützt die folgenden Formate bei der Erstellung von Reports:

– HTML

– RTF

– CSV

– XML

– PDF

Die Lösung bietet neben der standardmäßigen Authentifizierung über Benutzername und Passwort weitere externe Authentifizierungsmechanismen:

– RADUIS (SecurID, Premier Access)

– Active Directory

– LDAP

– JAAS Plugin

Zugriffsrechte sind granular implementiert. Hierzu gehören die Einstellung sowohl auf Gruppenebene als auch für bestimmte Benutzer auf Datenklassen, Datenquellen und Funktionen. Die Einschränkung bezieht sich auch auf die Anzeige ausschließlich berechtigter Funktionen und Daten.


Logdatenstudie

Ein Rollenkonzept ist bereits vom Hersteller im Auslieferungszustand des Systems definiert. Die Benutzeraktionen aller Benutzer werden revisionssicher gespeichert und bei ausreichender Berechtigung angezeigt.

Sicherstellung der Verfügbarkeit des SystemsDie Verfügbarkeit des Systems wird über einen separaten Monitor überwacht und bei einem Ausfall oder einer Überschreitung der definierten Werte über die implementierten Benachrichtigungsmechanismen gemeldet.

Die Aktualisierung des Systems ist manuell durchzuführen. Der Hersteller unterstützt dies durch die Versendung von E-Mails bei Änderungen. Die Migration und das Backup von Konfigurationsdaten ist ebenfalls manuell durchzuführen und kann granular erfolgen. Die Migration der Datenbank ist über die Mechanismen des Datenbankherstellers Oracle vorzunehmen. Die Verwaltung des Speicherplatzes erfolgt in definierten Parametern (Quota) durch das System. Diese umfasst auch die Archivierung von Datenbeständen.

5.4 Fazit und ZusammenfassungDie in diesem Abschnitt vorgestellten Produkte sind komplex und nicht alle lassen sich unmittelbar miteinander vergleichen. Für eine Darstellung, die trotz dieser Schwierigkeit eine Vergleichbarkeit gewährleistet, wurde eine auf die Bereiche SEM / SIM ausgerichtete, standardisierte Beschreibungsweise gewählt.

Produkte aus dem spezialisierten Umfeld schneiden in dieser Darstellung zwangsläufig am besten ab: sie erfüllen die meisten Anforderungen. Produkte aus benachbarten Bereichen, z.B. aus der System-Überwachung, können in dieser Darstellung nur in einer Projektion auf die SEM- / SIM-Sichtweise beurteilt werden.

Dieses Vorgehen wird in folgenden Punkten zusätzlich relativiert:

– Nicht jedes SEM-/SIM-Einsatz-Szenario sieht gleich aus. Hier gibt es eine breite Vielfalt von Faktoren, die unterschiedlich gewichtet werden.

– SEM bzw. SIM entsprechen nicht vollständig einer IT-Frühwarnung. Sie decken nur Teilanforderungen dessen ab.

– In der Praxis ist aufgrund finanzieller und personeller Engpässe oft ein schrittweises Projektvorgehen mit Teilzielen erforderlich. Nicht jedes leistungsfähige SEM-Produkt erlaubt aber ein solches Vorgehen, all zu oft gilt leider die Devise „Alles oder nichts“.

Betrachtet man die Leistungsfähigkeit der besten SEM-Produkte hinsichtlich ihrer Eignung als IT-Frühwarnsystem, so ist allgemein festzustellen, dass der Wert der Verfügbarkeit ausgeblendet wird. Die Verfügbarkeit in IT-Verbünden wird heutzutage noch über separate Programme und Werkzeuge überprüft. Ein Zusammenwachsen dieser klassischen Monitoring-Bereiche mit dem Bereich der reinen Sicherheitsüberwachung ist nur als schleppend feststellbar. Aktuelle Markttreiber sind Compliance-Thematiken, die eher wegführen aus dem Bereich der Echtzeit-Überwachung und Funktionen zum Logdaten-Management und zur Langzeitspeicherung erforderlich machen. Sich hier abzeichnende technische Kompromisse weichen die vorhandenen Frühwarn-Funktionen auf statt sie weiter zu schärfen.


Logdatenstudie

6 Praktische Empfehlungen für konkrete Anwendungsszenarien

Der nachfolgende Teil der Studie beschäftigt sich in zwei konkreten Szenarien mit der Umsetzung einer Logdaten-Zentralisierung und -Auswertung. Das erste Szenario „Recplast GmbH“ stellt eine typische mittelständische Firma dar und beleuchtet gezielt die begrenzten finanziellen und personellen Ressourcen, die sich dort in der Regel wiederfinden. Das zweite Szenario „P-A-P-Gateway“ entspricht der Umsetzung einer BSI-Standard-Architektur für ein Internet-Gateway und konzentriert sich auf die technische Umsetzung einer Logauswertung mit dem Ziel, möglichst weitreichende Aspekte der IT-Frühwarnung umzusetzen.

6.1 Fiktiver IT-Verbund „Recplast GmbH“

Dieser Abschnitt beschäftigt sich mit der Frage, welche Möglichkeiten einer Firma wie der Recplast GmbH angesichts begrenzter finanzieller und personeller Ressourcen zur Verfügung stehen, um den bestehenden IT-Verbund zu erweitern, damit Logdaten zentralisiert gesammelt und ausgewertet können.

Das Recplast-Szenario entstammt einem BSI-Webkurs zum IT-Grundschutz. Die fiktive Firma Recplast wird hierin als Anwendungsbeispiel für die Einführung eines IT-Sicherheits-Managements beschrieben. Details zu diesem Kurs können online unter

http://www.bsi.bund.de/gshb/webkurs/index.htm

eingesehen werden.

In diesem Dokument wird davon ausgegangen, dass die im Webkurs ermittelten Maßnahmen für den Grundschutz mittlerweile umgesetzt wurden.

Im folgenden Abschnitt werden die wichtigsten Eckdaten des Recplast-Szenarios noch einmal kurz zusammengefasst.

Die Infrastruktur der Recplast GmbH ist im Wesentlichen an zwei Standorten verteilt: Am Hauptverwaltungsstandort in Bad Godesberg befinden sich 30 Arbeitsplatzrechner und fünf Server, am Produktionsstandort in Bonn-Beuel ein weiterer Server und zwölf Arbeitsplatzrechner. Die beiden Standorte sind über eine Standleitung im internen Netzwerk miteinander verbunden. Über eine Firewall und einen Router wird die DSL-Verbindung ins Internet abgesichert. Es existieren ferner drei Vertriebsbüros, die per VPN an das Internet-Gateway in Bad Godesberg angeschlossen sind. Die folgende Abbildung veranschaulicht die Struktur:


Logdatenstudie


http://www.bsi.bund.de/gshb/webkurs/index.htm

Logdatenstudie

Gegenüber der online dokumentierten Recplast-Version wird aus Gründen der Aktualität im Folgenden davon ausgegangen, dass die Client-Rechner mittlerweile von Windows 2000 Professional auf Windows XP migriert worden sind. Zudem werden die folgenden beiden Varianten eingeführt:

7. Die Windows-Server wurden auf das Betriebssystem Windows Server 2003 migriert. Dies führt zu einer sog. „reinen Windows-Infrastruktur“ mit folgenden Server-Anwendungen:

a. Server S1: Microsoft Domänen-Controller

b. Server S2: Microsoft Exchange-Server

c. Server S3: Datei- und Druck-Server auf Basis von Windows Server 2003

d. Server S4: Datenbank-Server für die Kunden- und Auftragsbearbeitung

e. Server S5: Datenbank-Server für die Finanzbuchhaltung


Abbildung 6.1: Netzplan der Recplast IT-Infrastruktur

Logdatenstudie

f. Server S6: Server für den Standort Bonn-Beuel

8. Die Server S2 bis S6 wurden durch Linux-Server ersetzt. Als Kommunikations-Server dient ein Kolab-Server, als Datenbank kommt MySQL zum Einsatz. Bei diesen Servern handelt es sich also um eine sog. „gemischte Infrastruktur“ mit folgenden Server-Anwendungen:

a. Server S1: Microsoft Domänen-Controller auf Basis von Windows Server 2003

b. Server S2: Kolab-Server auf Basis von Linux

c. Server S3: Datei- und Druck-Server auf Basis von Linux

d. Server S4: MySQL-Datenbank-Server auf Basis von Linux für die Kunden- und Auftragsbearbeitung

e. Server S5: MySQL-Datenbank-Server auf Basis von Linux für die Finanzbuchhaltung

f. Server S6: Server auf Basis von Linux für den Standort Bonn-Beuel

Im Netzwerk kommen in beiden Szenarien die folgenden identischen Komponenten zum Einsatz:

– DSL-Router zum Internet

– Firewall auf Basis von Windows Server 2003

– Zentraler Switch in Bad Godesberg

– Switch für die Personalabteilung

– Router nach Bonn-Beuel

– Router nach Bad Godesberg

– Switch in Bonn-Beuel

Die Telekommunikationsanlagen sind in beiden Szenarien vom IT-Verbund getrennt und werden in den folgenden Betrachtungen ausgeblendet.

Die Recplast GmbH verfügt nur über begrenzte finanzielle und personelle Ressourcen, insbesondere in der IT. Dies führt insbesondere im Hinblick auf die umsetzbare Sicherheit zu Kompromissen und nicht optimalen Lösungen. Die folgenden Empfehlungen zur Einrichtung eines Logdaten-Managements berücksichtigen diese Ausgangslage und klammern unrealistische Ansätze weitestgehend aus. Technisch optimale Lösungen müssen insofern verworfen werden, wenn ihre Einführung zu teuer wäre. Aufwände für die Einführung einer Lösung müssen sich in einer zu den Aufwänden in anderen Sicherheitsbereichen der Recplast analogen Größenordnung bewegen.

6.1.1 Erfassung der Anforderungen, Ausgangslage, „Pflichtenheft“

In diesem Abschnitt werden die mit der Einführung einer Logging-Infrastruktur verbundenen Ziele festgehalten. An diesen muss sich eine zukünftige Lösung messen lassen.

6.1.1.1 Primäre Ziele

– Störungen des IT-Betriebs sollen frühzeitig erkannt werden und entsprechend schneller behoben werden.


Logdatenstudie

– Aus den Logdaten sollen Hinweise auf bevorstehende Störungen gewonnen werden, so dass Störungen schon im Vorfeld vermieden werden können. Beispiel: Der freie Festplattenplatz eines Servers wird in Kürze nicht mehr ausreichen.

– Angriffe aus dem Internet und Vorfälle im internen Netz sollen entdeckt werden.

– Die Auswirkungen solcher Angriffe und Vorfälle sollen abgeschätzt werden können.

6.1.1.2 Teilziele und Zwischenschritte

Aus den zuvor genannten primären Zielen können einige konkretere technische Ziele abgeleitet werden, die entweder die direkte Umsetzung der primären Ziele bedeuten oder ihre Erreichung stark unterstützen und möglich machen:

1. Auf allen internen Systemen der Recplast GmbH wird dieselbe Zeit geführt. Dies wird beispielsweise durch die Einführung eines entsprechenden Client-Server-Systems, welches das Network Time Protocol (NTP) nutzt, möglich gemacht. Diese Maßnahme ist eine notwendige Voraussetzung für den System übergreifenden Vergleich von Logdaten.

2. Für ein Unternehmen wie die Recplast GmbH mit nur geringen personellen Ressourcen muss eine Logging-Infrastruktur die schnelle Sichtung der relevanten Logdaten ermöglichen. Deshalb wird ein zentrales Logging eingerichtet. Dabei werden alle relevanten Logdaten an zentraler Stelle gesammelt und bereitgehalten.

3. Um den Speicherumfang für die Logdaten möglichst gering zu halten und eine effiziente Auswertung der anfallenden Datenmengen nicht unnötig zu erschweren, muss festgelegt werden, welche Logmeldungen vom System protokolliert werden sollen. Dabei müssen konsequenterweise die umzusetzenden Gesichtspunkte der IT-Sicherheit zugrunde gelegt werden.

4. Hierauf aufbauend können dann die gesammelten Meldungen ausgewertet werden. Diese Auswertung wird im ersten Teilziel nicht in Echtzeit durchgeführt, um die Kosten gering zu halten. Eine maschinengestützte Auswertung ist allerdings aufgrund der anfallenden Datenmengen bereits bei einer Unternehmensgröße wie der der Recplast GmbH praktisch unverzichtbar. Eine Auswertung der Logmeldungen setzt wiederum die Zentralisierung dieser Daten voraus.

5. Es wird festgelegt, welche Logdaten wie lange abgespeichert werden und wie der Zugriff auf sie abzusichern ist.

6. Im Recplast-Szenario werden nur am Rande die Möglichkeiten der Umsetzung einer (leistungsfähigen) IT-Frühwarnung eruiert, denn die Einführung einer solchen Lösung würde den Rahmen des bei der Recplast GmbH Machbaren sprengen. Es wird aber dargestellt, welche Basis-Funktionen einer Frühwarnung bereits mit geringen Mitteln umsetzbar sind.

7. Im Hinblick auf die Log-Einstellungen der Systeme und Anwendungen ist zu untersuchen, inwieweit noch genügend Systemressourcen bereitstehen, um auch ein hinreichend ausführliches Logging zu gestatten. Das Logging darf nicht die Verfügbarkeit der Systeme gefährden, insbesondere nicht im Fall eines umfangreichen Logging-Aufkommens, das beispielsweise entsteht, wenn ein Netzwerkwurms auf den Datei-Server zugreifen möchte.

8. Unter dem letzten Gesichtspunkt ist zu diskutieren, ob der zentrale Log-Dienst auf bestehender Hardware untergebracht werden kann oder ob dafür neue Hardware beschafft werden muss.


Logdatenstudie

Dieses Pyramiden-Diagramm veranschaulicht, welche Schritte auf dem Weg zu einem funktionierenden IT-Frühwarnsystem üblicherweise durchlaufen werden:

1. Ausgehend von der Ausnutzung aller zur Verfügung stehenden Bordmittel wird ein System aufgebaut, das dem Ziel dient, die Logdaten zu zentralisieren.

2. Auf Basis der zentral vorliegenden Logdaten kann anschließend begonnen werden, fortwährende Analysen durchzuführen. Aus Kostengründen werden diese in einer typischen ersten Aufbaustufe nicht in Echtzeit durchgeführt. Erkenntnisse, die aus den Logdaten gewonnen werden, sind deshalb keine Früh- oder gar Vorwarnung, sie gewähren dennoch wichtige Einblicke in die bestehende Sicherheitsarchitektur und ihre Umsetzung im Betrieb. Diese Stufe einer IT-Frühwarnung spielt auch eine wichtige Rolle im Bereich der Informationssicherheit mit den Themen Compliance und kontrolliertes Sicherheitsmanagement.

3. Für eine effiziente Frühwarnung bedarf es der fortwährenden Logdaten-Analyse in Echtzeit. Hierfür sind nicht unerhebliche Hardware-Ressourcen und Software-Lizenzen anzuschaffen.


Abbildung 6.2: Schema zur Nutzung von Logdaten

Früh-warnung

nachgelagerteLog-Auswertung

Log-Zentralisierung

Bordmittel

Logdatenstudie

6.1.2 Auswahl und Absicherung der Logdaten

Unabhängig von der jeweiligen Variante des Recplast-Szenarios oder dem anzusetzenden finanziellen Rahmen ist zunächst die Auswahl der als relevant einzuschätzenden Logdaten. Die Aussagekraft einer Auswertung solcher Daten ist natürlich limitiert durch die in ihnen enthaltenen Informationen, weshalb vorab jedenfalls eine mit den Zielen abgestimmte Auswahl erfolgen muss.

Die Logdaten-Auswahl wird von folgenden Rahmenparametern beeinflusst:

● Die Sammlung unnötiger, redundanter oder zu ausführlicher Informationen sollte aus Kostengründen vermieden werden. Je weniger Speicherplatz benötigt wird, desto besser.

● Je geringer die zu durchsuchende Datenmenge ist, desto effizienter kann die Suche innerhalb der Datenmenge bzw. eine Analyse durchgeführt werden.

Logdaten, die keine Aussagekraft für die Störungserkennung, Fehlersuche und Frühwarnung besitzen und auch keine gesetzlich relevanten Vorgänge berühren und diese dokumentieren, sollten nicht abgespeichert werden bzw. gar nicht erst erhoben werden. Diese Maßnahme dient der Reduktion der Datenmenge auf ein wirklich benötigtes Maß. Man mache sich aber bewusst, dass gerade die Frage, was für eine Fehlersuche relevant sein oder werden könnte, eine große Grauzone von Daten schafft, die nur selten benötigt werden, im Fall des Falles aber unabdingbar sind.

Das Ziel besteht also darin, eine möglichst exakte Auswahl an Log- und Monitoringdaten in Anbetracht der formulierten Ziele zu treffen. Aus Sicht der Vertraulichkeit und der Integrität von Daten interessieren in erster Linie die Logmeldungen der Sicherheitsgeräte und diejenigen Anwendungs-Logdaten, die die regelkonforme Benutzung der jeweiligen Anwendung überwachen. Aus Sicht der Verfügbarkeit sind es hingegen regelmäßig abgefragte Informationen über den Betrieb der Systeme, wie die Erreichbarkeit der Systeme über das Netzwerk oder Fehlermeldungen aus den Betriebssystemen, die auf zu lösende Probleme hindeuten. Auf das Recplast-Szenario übertragen ergibt sich folgende Liste relevanter Logdaten:

– Firewall-Logdaten:

• Zugriffsversuche über die Firewall und ihr Regelwerk hinweg – sowohl bei verbotenen Kommunikationsbeziehungen als auch bei erlaubten

• Internet-Zugriffe, ggf. anonymisiert oder pseudonymisiert

• E-Mail-Logdaten über eingehende und vielleicht auch ausgehende E-Mails

– Internet-Router-Meldungen über konfigurierte Access-Listen

– VPN-Logmeldungen für die Verbindung zu externen Standorten und mobilen Clients

– Windows-An- und Abmeldungen wie sie auf dem Domänen-Controller protokolliert werden

– Interne DNS- und DHCP-Server-Meldungen auf dem Domänen-Controller

– Sicherheits-und System-Ereignismeldungen der Windows-Server-Betriebssysteme

– Syslog-Meldungen der Linux-basierten Systeme und Anwendungen

– Access-Switch-Meldungen über die Nutzung physikalischer Ports und MAC-Adressen angeschlossener Geräte

– Meldungen über verarbeitete E-Mails aus dem Exchange- bzw. Kolab-System, zumindest auf SMTP-Protokollebene


Logdatenstudie

– Logdaten der zentralen Datenbank-Anwendungen sowie der Datenbanken selbst. Es wird davon ausgegangen, dass für das Datenbank-Logging eigene Logdateien im Dateisystem des Betriebssystems genutzt werden.

– Logdaten des Datei- und Druck-Servers, insbesondere solche, die Zugriffsrechtsverletzungen aufzeigen (z. B. Audit-Log auf Windows-Systemen)

– Logdaten des verteilten Virenschutzsystems auf Clients und Servern, zentral bereits gesammelt auf dem Verwaltungssystem der Virenschutz-Software

Auf folgende Logmeldungen kann verzichtet werden:

– Windows-Ereignismeldungen der stationären Clients und der Laptops, in erster Linie aus folgenden Gründen:

• An- und Abmeldungen werden bereits auf dem Domänen-Controller zentral registriert.

• Im Allgemeinen gilt: Da im Recplast-Netzwerk praktisch ausschließlich Client-Server-Kommunikation stattfindet, sind die serverseitigen Logdaten in der Regel ausreichend. Die clientseitigen Logdaten würden redundante Informationen liefern.

• Da die Clients bei Recplast dezentral verwaltet werden müssen (IT Help Desk Support), genügt hier zunächst eine dezentrale, bedarfsgetriebene Auswertung der Logdaten für die Fehlersuche.

– Anwendungs-Logmeldungen der Windows-Ereignisanzeige, falls die jeweilige Applikation eine eigene Logdatei führt. Die im Windows-Log anfallenden Logmeldungen sind dann nicht aussagekräftig.

– Rekursive DNS-Lookups aus dem internen Netz für FQDNs aus dem öffentlichen Internet. Aufgrund der enormen Datenmenge sollte hierauf verzichtet werden.

Damit die als relevant eingestuften Logmeldungen von den Systemen überhaupt geschrieben werden, müssen auf den einzelnen Systemen unter Umständen Anpassungen gegenüber dem Standard-Logging vorgenommen werden. Hierzu zählen beispielsweise folgende Konfigurationseinstellungen:

– Windows-Server: Die Empfehlungen zur Größe und zum Verhalten bei maximaler Größe der Ereignisanzeige müssen umgesetzt werden. Das Audit-Logging auf dem Datei- und Druck-Server muss entsprechend den freien System-Ressourcen aktiviert werden.

– Exchange-Server: Das Exchange Message-Tracking, welches die SMTP-Transaktionen protokolliert, muss eingeschaltet werden.

– Firewall- und Netzwerk-Komponenten: Hier ist aus Sicherheitssicht ein ausführliches Logging wünschenswert. Beispielsweise ist es interessant, nicht nur von unterbundenen Aktionen (z. B. nicht erlaubter Verbindungsaufbau), sondern auch von erlaubten Aktionen zu erfahren (z. B. erlaubter Verbindungsaufbau).

– Im Allgemeinen gilt, dass das Logging so ausführlich wie nötig und so knapp wie möglich gehalten werden sollte.

Lücken in der Überwachung durch LogmeldungenIn der Logging- und Überwachungsinfrastruktur existieren die folgenden nicht abdeckbaren Lücken:


Logdatenstudie

– Virenschutz: Es wird davon ausgegangen, dass das Virenschutz-Produkt ein zentralisiertes eigenes Logging mitbringt. Es hängt also vom konkreten Produkt ab, ob dieses Logging bereits leistungsfähig genug ist, z. B. indem es ein eigenes Berichtswesen mitbringt.

– Webserver-Zugriffe: Da die Webserver bei einem Provider ausgelagert sind, sind die dort anfallenden Zugriffslogs und -statistiken nicht mehr Teil der vorliegenden Betrachtung. Außerdem bieten Provider i. d. R. entsprechende Dienste zur Analyse der Daten an.

– Client-Meldungen: Der Aufwand für die Client-Logdatenist aufgrund der Zahl der Systeme als hoch anzusehen. Dies wird verstärkt bei einem Einsatz von mobilen Clients, die nicht immer Konnektivität in das lokale Netzwerk haben und deren Logging zeitversetzt erfolgt. Auch ist die ständige Verfügbarkeit dieser Systeme weder ein Ziel noch realistisch, da Arbeitsplatzrechner abends und am Wochenende meist heruntergefahren werden.

– Überwachungsfunktionen, die sich per SNMP und andere Abfragen (TCP-Verbindungsanfragen, Ping etc.) realisiert lassen: Eine entsprechende Infrastruktur fehlt im Recplast-Szenario. Da der Schwerpunkt der Betrachtung auf dem Logging-System liegt und das klassische System- und Netzwerk-Monitoring heutzutage einen separaten Infrastruktur-Part darstellt, wird im Folgenden auf die eingehende Untersuchung verzichtet.

– Syslog ist bei einigen Systemen wie Netzwerk-Komponenten die einzige unterstützte Methode für eine Protokollierung und deshalb prinzipiell nicht verzichtbar. Daraus folgt, dass die Vertraulichkeit und Integrität der Logdaten während des Transports nicht gewährleistet sind, wenn keine durchgehende Verschlüsselung realisierbar ist (auf diesen Komponenten kann auch kein Agent, der die Logdaten verschlüsselt verschickt, installiert werden) oder – wie bei Recplast – weder eine Netzwerk-Segmentierung noch ein Out-of-Band-Management vorliegen.

Auslegung des Logging-SystemsEine Auslegung eines Logging-Systems ist auf zentraler Seite zunächst durch die beiden folgenden Faktoren bestimmt:

● Erwartete Logmenge: Wie viele Megabyte Daten fallen im Durchschnitt pro Tag an und wie lange sind sie abzuspeichern?

● Wie viele Logmeldungen werden in Spitzenzeiten pro Sekunde erzeugt (Ereignisse pro Sekunde)?

Im Recplast-Szenario ist nicht davon auszugehen, dass die Ereignisse pro Sekunde eine hohe Anforderung darstellen. Dieser Faktor ist vor allem durch die Zahl der loggenden Systeme und das auf diesen verarbeitete Logvolumen bestimmt. Das Recplast-Szenario ist hier nicht so genau spezifiziert, dass eine präzise Angabe möglich wäre, es ist aber mit deutlich weniger als 25 Ereignissen pro Sekunde zu rechnen:

Die Server und Applikationen werden im Normalbetrieb deutlich weniger als ein Ereignis pro Sekunde verursachen. Netzwerkkomponenten schreiben ähnlich wenige Ereignisse.

Für die 34 Benutzer der Recplast GmbH wird das folgende gemittelte Verhalten angesetzt:

● Ein durchschnittlicher Benutzer erhält und versendet 100 E-Mails am Tag inkl. Spam, dabei werden 5 Logmeldungen pro E-Mail erzeugt.

● Er greift auf 50 Webseiten am Tag zu, daraus resultieren 10 Logmeldungen pro Seite.


Logdatenstudie

● Er nimmt 25 An- und Abmeldungen am Tag über alle Systeme summiert vor, dabei entstehen 2 Logmeldungen pro An- bzw. Abmeldung.

● Ein Benutzer führt 50 Datei-Server-Zugriffe am Tag aus, daraus resultieren 2 Logmeldungen pro Datei-Zugriff.

In Summe werden dadurch ca. 1.150 Ereignisse pro Benutzer und Tag ausgelöst. Dabei entstehen insgesamt ca. 40.000 durch Benutzer verursachte Logmeldungen pro Tag. Im Durchschnitt über den Tag und die Woche gemittelt ist also höchstens mit einem Ereignis pro Sekunde zu rechnen.

Die durchschnittliche Größe einer Logmeldung kann allgemein mit 150 Bytes angesetzt werden. Daraus ergibt sich ein Speicherplatzbedarf von1 Ereignis/s x 24h/Tag x 3600s/h x 150 Bytes = 12,96 Millionen Bytes/TagDieser Speicherplatzbedarf besteht bei einer nicht-komprimierten Aufbewahrung der Daten. Wenn die Logdaten mit normalen Komprimierungsalgorithmen komprimiert werden, kann dieser um die Hälfte reduziert werden. Für das Recplast-Szenario werden somit sechs Megabyte an Logdaten pro Tag angesetzt.

Absicherungsvorgaben für die gesammelten LogdatenDie zentral zu sammelnden Logdaten müssen entsprechend ihrem hohen Vertraulichkeitswert vor unbefugtem Zugriff geschützt werden. Dabei sind auch Datenschutz-Aspekte zu berücksichtigen, denn viele der Daten (Internet-Zugriff, An- und Abmeldungen) enthalten personenbezogene Informationen.

Für das Recplast-Szenario wird gefordert, dass nur autorisiertes Personal Zugriffsrechte auf die Daten erhält und ein anderweitiger Zugriff unterbunden und überwacht werden muss. Diese Vorgabe kann durch entsprechende Rechte im Betriebssystem umgesetzt werden. Der Einsatz von Verschlüsselungswerkzeugen kann zusätzlich angeraten sein.

Es ist nicht davon auszugehen, dass die Recplast spezielle gesetzliche Vorschriften zur Speicherung und Aufbewahrung von Logdaten einhalten muss. Eine verbindliche Aussage kann für jedes Unternehmen aber nur durch entsprechende juristische Experten erteilt werden.

6.1.3 Analysemöglichkeiten des IT-Verbunds mit Bordmitteln

Die günstigste Variante, eine Lösung zur Logdaten-Analyse einzuführen, besteht in einer vollen Ausnutzung aller bereits zur Verfügung stehenden Mittel, der sog. „Bordmittel“. Einige Aspekte der oben genannten Ziele lassen sich ggf. bereits umsetzen, ohne dass große Budgets bewilligt werden müssten.

Dieser Abschnitt befasst sich deshalb mit der Fragestellung, welche Maßnahmen im IT-Verbund der Recplast auf der Basis der in den jeweiligen Varianten implementierten Betriebssysteme und Anwendungen realisiert werden können. Der Einsatz zusätzlicher Hardware oder kostenpflichtiger Software ist in dieser Fragestellung ausgeschlossen, ebenso die zeitaufwändige Programmierung von eigener Software oder Skripten. Der benötigte zeitliche Aufwand sollte sich in diesem Abschnitt im Bereich von maximal zwei Tagen bewegen.


Logdatenstudie

6.1.3.1 Reine Windows-Infrastruktur

Wie bereits beschrieben wird in dieser Variante von Windows als einzigem bei Recplast eingesetzten Betriebssystem ausgegangen. Die Applikationen besitzen ein eigenes Logging, ebenso die Netzwerk- und Sicherheitskomponenten.

In einem ersten Schritt werden die IT-Systeme auf eine einheitliche Zeitgebung konfiguriert. Dies erfolgt in den Betriebssystemen der Server bzw. direkt auf den Netzwerkkomponenten. Es empfiehlt sich die Umsetzung via NTP über einen vertrauenswürdigen externen Zeitgeber-Server. Entsprechende Freischaltungen auf der Firewall und in den Access-Listen des Routers müssen vorgenommen werden. Alternativ kann auch der Domänen-Controller als interner Zeitgeber fungieren. Möglicherweise übernimmt er diese Funktion bereits von Haus aus für die Windows-Server im IT-Verbund der Recplast GmbH.

Betrachtet man zunächst die Windows-Server – es wird davon ausgegangen, dass das Betriebssystem Windows Server 2003 verwendet wird – , so muss man feststellen, dass die Bordmittel in diesem Umfeld nicht sehr leistungsfähig sind (s. Kap. 3.2.2.1): Das Default-Logging muss in dieser Betriebssystemversion zwar nicht mehr angepasst werden, um den Anforderungen an die Sicherheit und Verfügbarkeit zu entsprechen, es gibt aber von Haus aus keine Möglichkeiten, die Logdaten an zentraler Stelle zu sammeln.

Gegebenenfalls kann die Größe des lokalen Windows-Ereignis-Logs hoch gesetzt und das Logging des DNS- und DHCP-Servers kann so konfiguriert werden, dass eine ausführlichere Protokollierung vorgenommen wird. Dabei stellt die Einstellung „Overwrite events as needed“ sicher, dass immer Plattenplatz für Logdaten bereitsteht, sie kann aber prinzipiell auch dazu führen, dass wichtige Ereignisse durch unwichtige Ereignisse überschrieben werden.

Ohne Hilfsmittel können Windows-Logdaten nicht von einem einzelnen System auf einen zentralen Loghost transferiert werden. Sie müssen auf dem Log generierenden System verbleiben. Einzelne Abfragen können remote über die Windows-Ereignisanzeige durchgeführt werden, dabei werden entsprechende Rechte vorausgesetzt. Eine kontinuierliche Übertragung der dezentral generierten Logdaten an zentraler Stelle ist in der Windows-Architektur jedoch nicht vorgesehen.

Nicht-Windows-Systeme wie Router, Firewalls, Switches und die Datenbank-Anwendungen finden in einer reinen Windows-Umgebung keine Anknüpfungspunkte wie beispielsweise einen Syslog-Server. Windows bietet zwar Schnittstellen zu Drittsystemen, in älteren Betriebssystemen als Windows Vista sind diese jedoch nicht geeignet, die Logdaten von separaten Geräten zu empfangen und zu speichern.

Für die Geräte, die Syslog unterstützen, fehlt in den Bordmitteln ein entsprechender Syslog-Server/Syslog-Daemon, so dass deren entferntes Logging deaktiviert bleiben muss und nur zu Zwecken der Fehlersuche – beispielsweise auf der Kommandozeile – aktiviert werden kann.

Die Logdaten der Applikationen oder auch der auf Windows installierten Firewall können über Windows-Verzeichnisfreigaben entweder auf einer zentralen Seite lesbar gemacht werden oder über eine Freigabe auf die zentrale Seite gleich dort geschrieben werden. Im letzteren Fall kann die Verfügbarkeit der Datenbank-Anwendungen oder der Firewall durch Ausfälle der Verbindung zum Log-Server gemindert werden: Abhängig von der konkreten Implementierung kann ein Ausfall der Log-Komponente auch die Applikation selbst in Mitleidenschaft ziehen und im Extremfall zum Absturz des Programms führen.


Logdatenstudie

Eine kostenfreie Erweiterung der Umgebung – beispielsweise um einen frei erhältlichen Syslog-Server für Microsoft Windows – wird erst in einem späteren Abschnitt diskutiert (siehe Abschnitt 6.1.4), da diese Maßnahme nicht allein mit Bordmitteln von Microsoft Windows umgesetzt werden kann.

Insgesamt kann die Variante „Windows mit Bordmitteln“ die Minimal-Anforderungen an ein Logging-System größtenteils nicht erfüllen. Nur die Realisierung einer übergreifenden Systemzeit ist ohne Weiteres umzusetzen. Es ist keine Zentralisierung von Logdaten ohne den Einsatz von weite


Abbildung 6.3: Recplast: Integration der Windows-Komponenten

Logdatenstudie

rer Software (oder auch Hardware) erreichbar. Die Logging-“Inseln“ Syslog-Geräte, Windows-Systeme und Applikationen werden insbesondere nicht in eine zentralisierte Lösung integriert.

KostenabschätzungProjektkosten:

Maßnahme Aufwand BemerkungSetzen der NTP-Zeit auf allen Systemen

1 AT

Betriebskosten:

Maßnahme Aufwand BemerkungÜberprüfung der Systemzeit

1,5 AT pro Jahr 15min pro Woche

6.1.3.2 Gemischte Infrastruktur

In der gemischten Infrastruktur gibt es neben einem einzelnen Windows-Domänen-Controller nur noch Linux-Server-Systeme. Diese bringen jeweils ein vollständiges Syslog-Subsystem mit, welches genutzt werden kann, um das Logging der verschiedenen Syslog-Geräte zu zentralisieren. Ohne den Einsatz von zusätzlicher Hardware müssen hierfür noch freie Systemressourcen auf einem der Linux-Server verfügbar sein. Denkbar sind hierfür in erster Linie die Server S3 und S6, da sie keinen unternehmenskritischen Dienst anbieten und die von ihnen angebotenen Dienste nicht besonders ressourcen-fordernd sind. Der Server S3wird allerdings als Dateiserver von sehr vielen Benutzern frequentiert, woraus Probleme mit der Zugriffsabsicherung resultieren können.

Die Einrichtung eines Syslog-Daemons ist abhängig von der eingesetzten Linux-Variante. Syslog-ng kann als leistungsfähiger angesehen werden und sollte gegenüber dem klassischen Syslog bevorzugt werden, sofern eine Auswahlmöglichkeit besteht.

Analog zu der Variante „Windows mit Bordmitteln“ wird auch in diesem Szenario eine einheitliche Systemzeit über NTP konfiguriert.

Die Systeme, welche ihre Logdaten per Syslog protokollieren, werden dahingehend konfiguriert, ihre Daten per Syslog an den neuen Loghost zu versenden. Falls die Auswahlmöglichkeit gegeben ist, sollten die Daten über TCP und nicht über UDP versandt werden. Verschiedene Syslog-Clients verwenden verschiedene Syslog-Facilities. Systeme, die ihrerseits mehr als eine Syslog-Facility benötigen (z. B. für das Betriebssystem- und Anwendungs-Logging), sollten entsprechend nochmals unterschiedliche Facilities einsetzen.

Bei Syslog-ng kann auf die Verwendung von Facilities zur Unterscheidung von Logdatenquellen verzichtet werden. Stattdessen können Syslog-Meldungen anhand von Quell-IP-Adresse und Strings unterschieden und in unterschiedliche Ziele/Logdateien geschrieben werden.

Die Konfiguration des Syslog-Daemons setzt folgende Vorgaben um:

– Die Ereignisse verschiedener Syslog-Facilities werden in separate Logdateien geschrieben.


Logdatenstudie

– Täglich um Mitternacht werden die Logdateien rotiert, d. h. die alte Logdatei wird umbenannt, beispielsweise in <IP-Adresse des Syslog-Clients>_<Datum in YYYYMMDD-Notation>.

– Die Logdateien einer Woche werden am darauf folgenden Wochenende am Sonntag in der Nacht oder optional eine Woche später komprimiert. Indem Logdaten für diesen Zeitraum unkomprimiert vorgehalten werden, soll es dem Betriebspersonal ermöglicht werden, innerhalb der Daten einfach nach Fehlermeldungen oder Vorfällen zu suchen. Nach diesem Zeitraum überwiegt erfahrungsgemäß der Nutzen einer Speicherplatz-Ersparnis, da die Daten nur noch selten abgefragt werden.

– Die komprimierten Logdaten werden nach einem bestimmten Zeitraum der Lagerung automatisch gelöscht. Bei der Recplast GmbH könnte könnte hierfür ein Zeitraum von drei oder sechs Monaten festgelegt werden. Außer technischen Vorgaben sind hier unter Umständen gesetzliche Anforderungen zu beachten.

Die Absicherung des Loghosts ist im Netzwerkverbund der Recplast nur schwer realisierbar, sie darf deshalb in ähnlichen Szenarien jedoch nicht außer Acht gelassen werden. Umso wichtiger wird die Absicherung der Logdaten auf dem Loghost selbst: Über Server-Härtungsmaßnahmen kann der unautorisierte Zugriff verhindert werden, der autorisierte Zugriff muss ergänzend überprüft und eingeschränkt werden. Wird der Loghost zusätzlich auf einem bereits anderweitig eingesetzten System installiert, so ist darauf zu achten, dass es nicht zu Autorisierungskonflikten kommt. Unter diesem Gesichtspunkt ist insbesondere der Datei-Server zu sehen, denn hier besitzt i. d. R. jeder Benutzer Zugriff auf bestimmte Freigaben.

Das in diesem Szenario verbliebene Windows-System ist ähnlich wie in der reinen Windows-Variante nicht ohne Weiteres in die Syslog-Infrastruktur integrierbar, denn die Bordmittel von Windows allein sind hierfür nicht ausreichend.

Die Applikationsseite ist einfach integrierbar, falls das Datenbank-System bzw. die Datenbank-Anwendung Syslog unterstützt. Ansonsten kann für diese Einzelfälle auf herkömmliche Methoden zurückgegriffen werden, um Daten im Netzwerk zu verschieben bzw. zugänglich zu machen. Dabei ermöglichen Netzwerkfreigaben über NFS oder Samba (diese garantieren allerdings kaum eine bessere Vertraulichkeit der Daten als Syslog) oder ein regelmäßiger Dateitransfer über SSH/SCP oder FTP die zentralisierte Vorhaltung dieser Logdaten.


Logdatenstudie


Logdatenstudie

Zusammenfassend kann man feststellen, dass in der Variante „Gemischte Umgebung mit Bordmitteln“ die Minimalziele größtenteils erreicht werden können. Eine einheitliche Systemzeit ist einfach zu erzielen. Ein zentraler Loghost kann vermutlich auf bereits vorhandener Hardware untergebracht werden, auch wenn dies natürlich nicht dem idealen Zustand entspricht. Bei entsprechenden Budgets sollte deshalb über den Einsatz von zusätzlicher Hardware nachgedacht werden. Der Großteil der Systeme kann über Syslog zentralisiert werden, nur die kleine verbliebene Windows-Insel ist nicht in diese Lösung integrierbar.Darüber hinausgehende Ziele wie die automatische Auswertung der gesammelten Logdaten sind mit Bordmitteln nicht zu erreichen.Abschließend muss darauf hingewiesen werden, dass der Einsatz von Syslog die Unzulänglichkeiten dieses veralteten Protokolls erbt: es gibt keine Zuverlässigkeit und keine Vertraulichkeit bei der


Abbildung 6.4: Recplast: Integration der Linux-Server

Logdatenstudie

Datenübertragung. Inhalte könnten während der Übertragung abgefangen und verändert werden. Deshalb sollten zusätzliche Absicherungsmaßnahmen getroffen werden.



1 AT

Konfiguration des syslog-ng Daemons

1,0 AT Inkl. Tests und Kontrolle

Konfiguration der syslog-Parameter auf den Einzelsystemen


Betriebskosten:



Kontrolle der Logging-Funktionen, manuelle Überwachung

2 AT pro Jahr 20min pro Woche

6.1.4 Analysemöglichkeiten, die über den Einsatz von Bordmitteln hinausgehen

Weitet man das Recplast-Szenario aus, indem man neben den in den Betriebssystemen integrierten Bordmitteln weitere Produkte hinzuzieht, so bedeutet dies nicht gleich den Einsatz kostenpflichtiger Software: Der besondere Kostenaspekt einer mittelständischen Firma wie Recplast wird auch in dieser Konstellation nicht außer Acht gelassen.

Im folgenden Abschnitt soll aufgezeigt werden, wie die weiteren Ziele einer Logging-Infrastruktur nach und nach erreicht werden können, indem zusätzliche Hard- und Software zum Einsatz gebracht werden.

Der erste Abschnitt widmet sich wieder der reinen Windows-Infrastruktur, die mit Bordmitteln allein das Ziel der Log-Zentralisierung nicht erreichen konnte. Dementsprechend wird es zunächst darum gehen, dieses Basisziel zu erreichen, bevor auf weitere Schritte eingegangen wird.

Der zweite Abschnitt über die gemischte Infrastruktur startet von einer mit Bordmitteln im Wesentlichen bereits erreichten Log-Zentralisierung. Diese auch auf die Windows-Insel zu erweitern, ist das erste Ziel dieser Betrachtung. Darüber hinausgehende Ziele werden aufgrund ihrer Ähnlichkeit nur in ihrem Unterschied zu den im reinen Windows-Umfeld gefundenen Lösungen dargestellt.


Logdatenstudie

6.1.4.1 Analysemöglichkeiten mit Windows, die über Bordmittel hinausgehen

Ausgehend von einer auf allen beteiligten Systemen gleichgezogenen Systemzeit besteht hier vor allem das Ziel, die Ereignis-Logdaten der Windows-Systeme über das Netzwerk auf einen zentralen Host zu transportieren. Wie bereits erwähnt ist dieses Ziel mit Windows-Bordmitteln nicht umzusetzen. Gleichwohl ist im Windows-Betriebssystem eine Schnittstelle vorgesehen, über die die gemeldeten Ereignisse im Klartext und in Echtzeit ausgelesen werden können. Grundsätzliche Idee wird es deshalb sein, durch die Installation eines entsprechenden Software-Agenten Windows-Ereignisse abzugreifen. Dieser Agent kann dann dafür sorgen, dass die Logmeldungen über das Netzwerk an einen Log-Server versendet werden.

Dieser Server wird außerdem idealerweise in der Lage sein, die per Syslog zu versendenden Logdaten der Netzwerkkomponenten zu empfangen, er muss also in diesem Sinne eine Syslog-Server-Komponente besitzen.

Aus dieser Überlegung heraus kann man den einfachen Schritt machen und auch die Windows-Seite auf den Syslog-Mechanismus umsetzen, und zwar durch den Einsatz eines entsprechenden Agenten.

Alternativ kommt ein Agent infrage, der die Daten nicht per Syslog und damit im Klartext versendet, sondern über ein verschlüsseltes Protokoll wie beispielsweise TLS/SSL. Auf der Server-Seite muss in diesem Fall eine kompatible Komponente arbeiten, und es gibt anders als bei Syslog kaum Lizenzkosten freie Implementierungen, die dies unterstützen. Es kommt hier also zu einer Abwägung zwischen den Faktoren Kosten und Sicherheit.

Die Einrichtung eines separaten Management-VLANs ist eine Erweiterungsmöglichkeit für das Recplast-Netzwerk, die zum einen eine vertrauliche Datenübertragung nicht nur, aber auch für Logdaten erlauben würde. Zum anderen ermöglicht sie den Verzicht auf ein kommerzielles Logauswertungsprodukt. Zwar können VLAN-Trennungen aus BSI-Sicht nicht vorbehaltlos empfohlen werden, doch wäre der erzielte Sicherheitsgewinn bereits ein Fortschritt. Eine komplette physikalische Trennung macht den Einsatz weiterer Hardware unvermeidbar, genügt aber auch höchsten Sicherheitsansprüchen. Wie diese im Logdaten-Umfeld genutzt werden kann, wird im folgenden Kapitel zum P-A-P-Gateway (siehe Abschnitt 6.2) beschrieben.

Da an dieser Stelle durch die Syslog-Komponenten ein konsistenter Sicherheits-Level ohnehin nicht erreichbar ist, wird im Folgenden davon ausgegangen, dass auch die Windows-Insel mithilfe eines entsprechenden Agenten über Syslog an die Logging-Infrastruktur angebunden wird.

An zentraler Stelle wird dadurch der Einsatz eines Syslog-Servers notwendig. Auch für Windows gibt es hierfür leistungsfähige und kostenfrei verfügbare Implementierungen. Die Anschaffung eigener Hardware wird in dieser Variante nicht zuletzt aufgrund der vertretbaren Kosten empfohlen. Lizenzrechtlich abzuklären ist der kostengünstige Einsatz von Windows XP statt Server 2003 als Betriebssystem des Loghosts.

Für die Insel der Datenbank-Anwendungen der Recplast GmbH ist erfahrungsgemäß davon auszugehen, dass kein Agent verfügbar ist, der die Logdaten aufgreift und über Syslog versendet. Man würde in diesem Fall zu dem bereits zuvor beschriebenen Mittel der Verzeichnis-Freigabe greifen, um auch die Applikations-Logdaten auf den Loghost zu transferieren.

Die Platzierung des Loghosts im Recplast-Netzwerkverbund wird unter den Gesichtspunkten der Erreichbarkeit von jedem der loggenden Systeme einerseits und der Absicherung des Loghosts gemäß der Klassifizierung der dort gelagerten Daten vorgenommen. Berücksichtigt man die aus interner Netzwerksicht kaum vorhandene Absicherung der für das Unternehmen wichtigen Systeme wie E-Mail-Server oder Applikations-Server, so erscheint eine gesonderte Absicherung des Loghosts


Logdatenstudie

unverhältnismäßig. Jedenfalls muss aber die Absicherung der datenschutzrelevanten Logdaten Berücksichtigung finden. Diese muss aber nicht über Maßnahmen im Netzwerk umgesetzt werden. Es genügt die effiziente Installation einer Zugriffsrechtestruktur auf der Betriebssystem-Ebene.


Logdatenstudie

Bewertet man die in diesem ersten Schritt erreichten Ziele, kann man feststellen, dass sich ohne große Aufwände auch in einem Windows-Verbund mit Netzwerkkomponenten und einigen zentralen Applikationen eine Zentralisierung der Logging-Infrastruktur umsetzten lässt. Es kann somit eine erste Basis für Fehlersuche und bedarfsgetriebene Auswertungen geschaffen werden. Für darüber hinausgehende Ziele stellen diese Maßnahmen folglich eine Ausgangsbasis dar.

Solche Ziele könnten für die Recplast GmbH darin bestehen, die gesammelten Logdaten automatisch und regelmäßig auszuwerten. Spätestens ab diesem Schritt wird eigene Hardware unverzichtbar, da diese Prozeduren bereits Performance intensiv sind. Eine fortlaufende Echtzeit-Auswertung eintreffender Ereignismeldungen für die IT-Frühwarnung ist zum heutigen Zeitpunkt als nicht realistisch einzuschätzen: Kosten und vor allem der Aufwand im Betrieb sind in Unternehmen von der


Abbildung 6.5: Recplast: Anbindung der Windowssysteme über Agenten

Logdatenstudie

Größe einer Recplast GmbH nicht zu stemmen. Außerdem sind keine Produkte verfügbar, welche die diesbezüglichen Anforderungen von mittelständischen Unternehmen berücksichtigen.

Im Folgenden wird deshalb der Einsatz eines Programms zur regelmäßigen nachgelagerten Analyse der gesammelten Logdaten diskutiert.

Bei der Produktauswahl ist entscheidend, dass die vorhandenen Gerätetypen wie Windows-Betriebssystem, Firewall, Netzwerkgeräte etc. eingelesen und verarbeitet werden können. Des Weiteren ist es wichtig, dass die zu erwartende Datenmenge verarbeitet werden kann. Der Einsatz von Datenbanken hat sich deshalb als notwendiges Mittel erwiesen. Die Kostenfrage ist gerade in diesem Punkt im Auge zu behalten. D. h., dass nicht direkt benötigte Funktionen auch nicht bezahlt werden sollten und ein Produkt auszuwählen ist, das die geforderten Funktionen genau abdeckt. Frühwarnfunktionen und ein Security Event Management sind in diesem Sinne nicht gefordert.

Im Kapitel 5.3 sind zwei Produkte beschrieben, von denen sich eines auch für den Einsatz unter Windows eignen würde. Solche Produkte nutzen in der Regel MySQL-Datenbanken. Wenn die Möglichkeit des Einsatzes dieser Lösungen in Erwägung gezogen wird, ist unter Umständen die Integration der Windows-Betriebssysteme erneut zu betrachten. Es ist zu untersuchen, ob der zuvor besprochene Agenten-Einsatz unterstützt wird oder das Produkt der Wahl einen eigenen Mechanismus liefert. Da der Anspruch aber nicht in einer Echtzeit-Auswertung der Logdaten liegt, kann über einen zeitversetzten Export der Logdaten aus dem Windows-Ereignislog nachgedacht werden. Unmittelbares Ziel muss hier die Automatisierung sein, um die Betriebsaufwände gering zu halten und die Akzeptanz im IT-Personal nicht zu untergraben.

Das Logging-System mit Berichtsfunktion, im Folgenden kurz Auswertungssystem genannt, ist analog zum klassischen Loghost vor unbefugtem Zugriff zu schützen. Ein Rechtesystem sollte den Zugriff auf datenschutzrelevante Daten kontrollieren. Leider sind die meist aus dem angelsächsischen Raum stammenden Produkte – bedingt durch die unterschiedliche Wahrnehmung und Auslegung des Datenschutzes in diesen Ländern – oft nicht mit entsprechenden Funktionen ausgestattet. Vor dem Kauf muss dieser Aspekt deshalb gesondert begutachtet werden.

Durch ein Auswertungssystem neu hinzukommen meist Webserver-basierte Zugriffe auf das System, beispielsweise um Berichte zu generieren und abzufragen. An dieser Stelle muss auf die starke Authentifizierung und den SSL-verschlüsselten Zugriff geachtet werden.

Auswertungssysteme mit obiger Spezifikation verzichten meist auf eine Normalisierung der Logdaten. Dadurch kann dann auch keine Korrelation über verschiedene Gerätetypen erfolgen. Verzichtet werden muss auch auf eine leistungsfähige Priorisierung wichtiger gegen unwichtige Ereignisse, insbesondere mangels Modellierung. Das Abfragesystem ist insofern vor allem als Hilfsmittel zu begreifen, um große Datenmengen in automatisierter Form zu verwalten und in Berichte umzusetzen. Letztere können als wichtiger Dokumentationsteil der IT dienen.

Abfragen werden gerätespezifisch in das System eingesteuert, Ergebnisse lassen sich pro Gerätetyp anzeigen. Folgende Abfrage- und Berichtsbeispiele sind unter diesen Gesichtspunkten denkbar:

– Firewall:

• Liste der aktivsten Angreifer

• Liste interner IP-Adressen mit auffälligem Verhalten

• Zugriffsversuche über unerwünschte Protokolle und Dienste, ggf. auch von internen Systemen, die durch Trojaner und Würmer hervorgerufen werden

• Zugriffe auf SSL-geschützte Webseiten, die für ein Tunneling verwendet werden


Logdatenstudie

• Statistiken über die Bandbreiten-Belegung

• Fehlerhafte Zugriffe auf die E-Mail-Server-Komponente

• Statistiken über das E-Mail-Aufkommen und Spam-Anteile

– Domänen-Controller inkl. DNS:

• Zugriffsversuche auf administrative Konten

• Aktivitäten von im Urlaub befindlichen Benutzern

• Verstöße gegen die Passwort-Richtlinie

• Gezielte Sperrung wichtiger Konten durch zu häufiges Verwenden von falschen Passwörtern bei der Anmeldung

• Fehlerhafte Abfragen von internen Systemen durch falsch konfigurierte Clients

• Verdächtige DNS-Lookups

– Netzwerkgeräte

• „Top-Talker“

• Top-Protokolle

• Geräte, die an häufig wechselnden Netzwerk-Ports auftauchen

– Datenbank-Applikationen

• Nicht konforme Abfragen

• Nicht autorisierte Anmelde- und Abfrageversuche

• Unbekannte Fehlermeldungen der Applikation

Der Betrieb der Auswertungslösung erfolgt mit der Maßgabe, möglichst wenig zusätzlichen Aufwand zu verursachen. Neue Berichte müssen zu abgestimmten Zeitpunkten generiert werden, damit nicht parallel andere Berichte erzeugt und das System überfordert wird.

Besondere Pflege benötigt ferner die Datenbank, die große Datenmengen speichern muss. Eine regelmäßige Bereinigung veralteter Datenbestände ist ein dringend notwendiger Administrationsvorgang, sofern dieser nicht bereits automatisch vom System durchgeführt wird.



1 AT

Installation des Loghost-Systems inkl. Syslog-Programm

1500 €1,0 AT

Konfiguration des syslog-ng Programms


Installation und Konfigu 1,0 AT Inkl. Tests und Kontrolle


Logdatenstudie

Maßnahme Aufwand Bemerkungration der Agenten auf den Windows-SystemenKonfiguration der syslog-Parameter auf den Einzelsystemen


Betriebskosten:





Wartung des Loghosts 2 AT pro Jahr


Logdatenstudie

6.1.4.2 Gemischte Umgebung, über den Einsatz von Bordmitteln hinausgehend

In der Variante „Gemischte Umgebung, über den Einsatz von Bordmitteln hinausgehend“ kann auf eine mit Bordmitteln funktionierende zentralisierte Lösung zurückgegriffen werden, die auf Syslog basiert. Auch eine einheitliche Systemzeit kann als gegeben vorausgesetzt werden.

Die Integration der bislang isolierten Windows-Insel, die im Wesentlichen aus dem Domänen-Controller besteht, kann über denselben Agenten bewerkstelligt werden, der im vorangegangenen Abschnitt beschrieben wurde. Der generische Ansatz, bei allen Geräten auf Syslog als einzigem offenen Standard zu setzen, wird somit auch für Windows realisierbar.

Ansonsten gelten für diese Variante dieselben Aussagen, die bereits im vorangehenden Kapitel beschrieben wurden.


Logdatenstudie

Zusammengefasst ist auch hier eine wirkliche Frühwarnung nicht realisierbar. Die nachgelagerte Analyse über ein entsprechendes Auswertesystem auf einem eigenen Server lässt sich ohne Einschränkungen auch mit Linux umsetzen. Auch die Kosten bewegen sich in demselben Rahmen, dies gilt jedoch nicht für die Kosten für die Betriebssystem-Lizenz und -wartung für den Loghost-Server, die im Linux-Szenario (teilweise) entfallen.



Abbildung 6.6: Recplast: Integration aller Systeme

Logdatenstudie


1 AT

Installation des Loghost-Systems inkl. Syslog-ng Daemon

1000 €1,0 AT

Konfiguration des syslog-ng-ng Daemons


Installation und Konfiguration des Agenten auf dem Windows-System


Konfiguration der syslog-Parameter auf den Einzelsystemen


Betriebskosten:Maßnahme Aufwand Bemerkung

Überprüfung der Systemzeit




Wartung des Loghosts 2 AT pro Jahr

6.1.5 Diskussion des Erreichten

Betrachtet man die im Recplast-Umfeld erreichbaren Ziele, so setzt zunächst Ernüchterung ein. Abgesehen von Basis-Funktionen ist eine Frühwarnung nicht erreichbar, schon gar nicht im engeren Sinn. Dies betrifft allerdings nicht nur diese Technologie: angesichts der Kosten und Aufwände sind auch andere neue und herausfordernde Technologien nur unzureichend in den IT-Verbund der Recplast zu integrieren und dauerhaft gut zu betreiben.

Vergleicht man die in vielen Aspekten durchaus vergleichbare Intrusion Detection bzw. Prevention Technologie mit dem jetzigen Stand der IT-Frühwarnung, so zeigt sich, dass dies nur eine Momentaufnahme sein könnte: Auch im IDS-/IPS-Umfeld waren die Anschaffungskosten und vor allem die Aufwände für die notwendigen Anpassungen und den Betrieb ursprünglich so hoch, dass an einen sinnvollen Einsatz im mittelständischen Umfeld nicht zu denken war. Mittlerweile sind jedoch Lösungen verfügbar, die einerseits mit minimalem Konfigurationsaufwand betrieben werden können und anderseits einen deutlichen Mehrwert für die Sicherheit darstellen, indem solche Geräte „inline“ betrieben werden.

Wie gezeigt wurde, ist aber auch eine Recplast in der Lage, bereits mit geringen Aufwänden wichtige Teilziele zu erreichen, nämlich


Logdatenstudie

● die Zentralisierung der Logdaten sowie

● ggf. eine zwar nachgelagerte, jedoch automatisch und regelmäßig durchgeführte Auswertung der gesammelten Daten.

Dies veranschaulicht das Pyramiden-Diagramm:

Bei geschickter Vorgehensweise und unter Ausnutzung der Bordmittel sind, wie gezeigt wurde, Kosten und Aufwand vertretbar.

6.2 P-A-P-GatewayIn der Studie „Konzeption von Sicherheitsgateways“ (erschienen im Bundesanzeiger Verlag, ISBN 3-89817-525-1) wird der Aufbau eines dreistufigen Sicherheits-Gateways nach dem Schema Paketfilter – Application Level Gateway – Paketfilter (P-A-P) zur Absicherung von Unternehmens-IT-Verbünden gegenüber dem öffentlichen Internet empfohlen. Im dortigen Kapitel 6.2.wird diskutiert, wie ein Loghost in das Sicherheits-Gateway integriert werden kann. Die dort getroffenen Aussagen werden im folgenden Abschnitt ergänzt um Aussagen zur Konfiguration des Loggings der im P-A-


Abbildung 6.7: Das bei Recplast erreichte Niveau im Pyramidendiagram

Früh-warnung


Log-Zentralisierung

Bordmittel

X

X

-

X

Logdatenstudie

P-Gateway installierten Geräte sowie des Loghosts selbst. Es wird des Weiteren beschrieben, wie das reine Logging über den Loghost zu einer Frühwarnung erweitert werden kann.

Die allgemeine architektonische Empfehlung, ein P-A-P-Gateway aufzubauen, wird in diesem Abschnitt bezüglich der einzusetzenden Produkte konkretisiert. Dabei handelt es sich dabei nicht um Produktempfehlungen seitens des BSI. Die aufgelisteten Produkte sollen lediglich dabei helfen, für die Logging-Infrastruktur spezifischere und damit auch umsetzbare Aussagen zu treffen.

Es wird angenommen, dass die folgenden Produkte im P-A-P-Gateway zum Einsatz kommen:

● HTTP Caching-Proxy: Squid. Das WWW wird nur passiv angefragt, es sind keine Webserver im Gateway-Verbund platziert.

● SMTP-Proxy mit Viren-Scanner: Postfix mit ClamAV

● DNS-Proxy: Bind. Es werden keine eigenen Zonen gehostet, sondern nur rekursive Lookups für das interne Netz durchgeführt.

Ferner wird davon ausgegangen, dass kein Webserver installiert ist.

Die Paketfilter sind so konfiguriert, dass

● keine direkten Verbindungen aus dem internen Netz ins Internet zugelassen werden, sondern Verbindungen ausschließlich indirekt über den zuständigen Proxy des Application Level Gateways geführt werden müssen;

● kein Verbindungsaufbau von Systemen, die sich in demilitarisierten Zonen (DMZ) befinden, in das interne Netz erfolgen kann, und dass

● kein Verbindungsaufbau aus dem Internet zu Systemen in DMZ oder gar im internen Netz durchgeführt werden kann.

Eine Netzwerk- und System-Überwachung (beispielsweise mithilfe von Nagios) wird als installiert und funktionierend vorausgesetzt. Seine Funktionsweise entspricht einer herkömmlichen Überwachung zur Sicherstellung der System- und Dienste-Verfügbarkeit.

Des Weiteren wird davon ausgegangen, dass ein NTP-Server über ein entsprechendes Funkuhr-Modul die aktuell gültige Zeit empfängt und an die Einzelsysteme des Gateways weitergibt. Es kann also davon ausgegangen werden, dass alle Systeme dieselbe Systemzeit besitzen.

Wie das Netzwerkdiagramm verdeutlicht, ist im P-A-P-Gateway ein separates Netzwerksegment für das Management und die Überwachung bereits vorhanden. Es ist über eigene Paketfilter PF7 – PF10 gegenüber dem Internet, dem Sicherheits-Gateway sowie dem internen Netz abgesichert. Die Platzierung des Loghost-Systems in diesem Bereich entspricht der Platzierung des Loghosts in einer eigenen DMZ in dem Sinne, dass im selben Netzsegment keine von außen adressierbaren Systeme wie der SMTP-Proxy zu finden sind und deren geringere Sicherheit vom Loghost quasi geerbt wird. Als Betriebssystem wird, soweit dies möglich ist, Linux vorausgesetzt. Die Netzwerkgeräte laufen mit dem jeweiligen proprietären Betriebssystemen der Hersteller, z. B. Cisco IOS.

Ein P-A-P-Sicherheits-Gateway wird typischerweise bei größeren Firmen als der Recplast GmbH eingesetzt. Der Analyse-Fokus des vorliegenden Kapitels liegt aber generell jenseits des bei der Recplast GmbH dominierenden, sehr engen Kostenrahmens. Vielmehr soll in diesem Kapitel technisch Machbares betrachtet werden und dies hinsichtlich seiner technischen Sinnhaftigkeit beleuchtet werden.


Logdatenstudie

6.2.1 Anforderungen und Pflichtenheft

In diesem Kapitel werden die Ziele der Einführung einer leistungsfähigen Logging-Infrastruktur festgehalten. An ihnen muss sich die vorzuschlagende Lösung messen lassen.

6.2.1.1 Primäre Ziele

Folgende primäre und allgemein formulierte Ziele sind festzuhalten:

– Angriffe aus dem Internet auf das vom Sicherheits-Gateway geschützte Netz und das Sicherheits-Gateway selbst sollen frühzeitig entdeckt werden können.

– Mögliche Auswirkungen eines Angriffs sollen abgeschätzt werden können.

– Im Falle eines erfolgreichen Angriffs aus dem Internet sollen die Logdaten dazu genutzt werden können, die betroffenen Systeme einzugrenzen und den Schaden zu begrenzen.

– Die Effizienz des IT-Betriebs soll gewährleistet bzw. gesteigert werden, indem Störungen frühzeitig erkannt und entsprechend schneller behoben werden. Sofern dies möglich ist, sollen Störungen sogar verhindert werden, indem aus den Monitoring- und Logdaten Hinweise auf mögliche Probleme (beispielsweise Netzwerkprobleme) abgeleitet werden.

– Die finanziellen Aspekte der Einrichtung einer leistungsfähigen Logging-Infrastruktur werden im P-A-P-Gateway-Szenario im Gegensatz zum Recplast-Szenario ausgeklammert. Das Augenmerk wird dabei auf technisch machbare und sinnvolle Lösungsansätze gelegt.

6.2.1.2 Zwischenschritte und Teilziele

Aus den zuvor genannten primären Zielen lassen sich einige konkretere technische Ziele ableiten, die entweder die direkte Umsetzung der primären Ziele bedeuten oder ihre Erreichung wenigstens stark fördern und möglich machen:

1. Es wird ein zentrales Logging eingerichtet, d. h. alle relevanten Logdaten werden an zentraler Stelle gesammelt und bereitgehalten.

2. Um den Speicherumfang für die Logdaten möglichst gering zu halten und eine effiziente Auswertung der anfallenden Datenmengen nicht unnötig zu erschweren, muss eine Auswahl der mitzuschreibenden Logmeldungen erfolgen.

3. Hierauf aufbauend können dann die gesammelten Meldungen ausgewertet werden. Eine maschinengestützte Auswertung ist aufgrund der anfallenden Datenmengen unverzichtbar. Diese setzt allerdings die Zentralisierung der Logdaten voraus.

4. Als Erweiterung der Zielsetzung gegenüber dem Recplast-Szenario ist bei der Datenauswertung im P-A-P-Gateway-Szenario auch eine Echtzeit-Auswertung der Daten ein wichtiges Ziel. Sie wird für den Anspruch benötigt, frühzeitig Angriffe und Störungen zu erkennen und ihre Auswirkungen präzise abzuschätzen zu können.

5. Es wird außerdem festgelegt, wie der Zugriff auf die Logdaten abzusichern ist.


Logdatenstudie


Logdatenstudie

Betrachtet man das P-A-P-Gateway im Pyramiden-Diagramm, so wird nochmals deutlich, worin die Unterschiede der Logging-Infrastruktur im Vergleich zum Recplast-Szenario bestehen:

Wo bei der Recplast GmbH aufgrund des relativ kleinen IT-Betriebs und des eingeschränkten Budgets nur die unteren beiden Stufen einfach zu realisieren sind und die dritte Stufe optional ist, startet man bei einem P-A-P-ähnlichen Gateway immer bereits auf der ersten Stufe. Die Frage nach den Bordmitteln würde hier sicherlich nicht weit genug reichen, insbesondere aufgrund der hohen Modularität der Architektur. Als Minimallösung muss ein zentraler Loghost eingerichtet werden. Die dritte Stufe der nachgelagerten Auswertung der zentral gesammelten Logdaten ähnelt sehr stark dem Recplast-Szenario und wird hier deshalb nicht nochmal näher betrachtet. Interessant ist hingegen die Fragestellung, wie realistisch eine Echtzeit-Auswertung im Sinne einer Frühwarnung ist. Diese wird den Schwerpunkt der Betrachtung in den folgenden Abschnitten bilden.

6.2.2 Auswahl der Logdaten

Ausgehend von der konkretisierten Form des P-A-P-Gateways mit den zuvor beschriebenen Produkten werden nun solche Logmeldungen und Log-Level ausgesucht, die wertvoll sind für eine Frühwarnung.


Abbildung 6.8: Das beim PAP-Gateway erreichte Niveau im Pyramidendiagramm

Früh-warnung


Log-Zentralisierung

Bordmittel -

X

X

X

P-A-P:

Logdatenstudie

Die Aussagekraft einer Auswertung solcher Daten ist natürlich limitiert durch die in ihnen enthaltenen Informationen, weshalb wie im Recplast-Szenario eine mit den Zielen abgestimmte Auswahl erfolgen muss.

Die Logdaten-Auswahl wird auch im P-A-P-Gateway von folgenden allgemeinen Rahmenparametern beeinflusst:

– Die Sammlung unnötiger, redundanter oder zu ausführlicher Informationen sollte aus Kostengründen vermieden werden. Je weniger Speicherplatz benötigt wird, desto besser.

– Je geringer die zu durchsuchende Datenmenge ist, desto effizienter kann die Suche innerhalb der Datenmenge bzw. eine Analyse durchgeführt werden.

Da im vorliegenden Szenario davon ausgegangen wird, dass die Verfügbarkeit über eine separate Netzwerk- und System-Überwachung sichergestellt ist, können die für diesen Bereich typischen Monitoring-Informationen aus der Logging-Infrastruktur teilweise ausgeklammert werden. Sie interessieren nur insofern, als sie Sicherheitsinformationen im engeren Sinne enthalten.

Für das P-A-P-Gateway ergibt sich folgende Liste von Geräten und Log-Informationen:

– Paketfilter: Zugriffsversuche gemäß Access-Listen, sowohl verbotene Kommunikationsbeziehungen als auch erlaubte

– HTTP-Proxy: Internet-Zugriffe, ggf. anonymisiert oder pseudonymisiert

– SMTP-Proxy: E-Mail-Logdaten über eingehende und ausgehende E-Mails auf SMTP-Protokoll-Ebene

– Viren-Scanner der Proxies: Diese Komponenten enthalten jeweils ihr eigenes Logging.

– NTP-Zeit-Server: Interessant sind hier die anfragenden NTP-Clients.

– DNS-Proxy: Anders als im Recplast-Szenario werden die DNS-Lookups einbezogen.

– Syslog-Meldungen der Linux-basierten Systeme und Anwendungen

– Access-Switch-Meldungen über die Nutzung physikalischer Ports und MAC-Adressen angeschlossener Geräte

Damit die als relevant eingestuften Logmeldungen von den Systemen überhaupt geschrieben werden, müssen auf den einzelnen Systemen unter Umständen Anpassungen gegenüber dem Standard-Logging vorgenommen werden. Dies sind beispielsweise folgende Konfigurationseinstellungen:

– Netzwerkgeräte mit Access-Listen: Hier ist aus Sicherheitssicht ein ausführliches Logging wünschenswert. Beispielsweise ist es interessant, nicht nur von unterbundenen Aktionen (z. B. nicht erlaubter Verbindungsaufbau), sondern auch von erlaubten Aktionen zu erfahren (z. B. erlaubter Verbindungsaufbau).

– Das Logging von Postfix und ClamAV läuft separat nebeneinander her. Durchlaufende E-Mails sind schwer einander zuzuordnen. Es kann zur Aufgabe einer Auswertung gemacht werden, diese Zuordnung nachträglich durchzuführen.

– Das Squid-Logging sollte ggf. so angepasst werden, dass die interne Client-IP-Adresse hinter einer Netzwerkmaske verborgen wird.

– Im Allgemeinen gilt, dass das Logging so ausführlich wie nötig und so knapp wie möglich erfolgen sollte.


Logdatenstudie

Syslog und seine Rolle im P-A-P-Gateway-VerbundSyslog ist bei einigen Systemen wie z. B. Netzwerkkomponenten die einzige unterstützte Methode der Protokollierung. Deshalb kann prinzipiell nicht darauf verzichtet werden. Daraus folgt jedoch, dass die Vertraulichkeit und Integrität der auf diese Weise übertragenen Logdaten während des Transports nicht gewährleistet sind, da keine durchgehende Verschlüsselung realisierbar ist. Diese Schwäche des Syslog-Protokolls ist einer der Hauptgründe dafür, die auf diese Weise übertragenen Daten über die Infrastruktur abzusichern. Dies ist beispielsweise möglich, indem die Daten in einem eigenen, speziell gesicherten Management-Netzsegment transportiert werden. Die Sicherheit dieses Netzbereichs garantiert dann insbesondere die Vertraulichkeit und Integrität der Logdaten.

Auslegung des Logging-SystemsEine Auslegung eines Logging-Systems ist auf zentraler Seite durch die beiden folgenden Faktoren bestimmt:

– Erwartete Logmenge: Wie viele Megabyte an Daten fallen im Durchschnitt pro Tag an und wie lange sind sie abzuspeichern?

– Wie viele Logmeldungen fallen in Spitzenzeiten pro Sekunde an (Ereignisse pro Sekunde)?

Die P-A-P-Architektur ist hinsichtlich ihrer Performance stark von der zugrunde liegenden Hardware abhängig. Diese wird in der Regel nach dem Bandbreitenbedarf ausgelegt. Hiervon sowie von der Zahl der Benutzer im Netzwerk hängt es in erster Linie ab, wie viele Logmeldungen pro Zeiteinheit generiert werden. Für eine konkrete Abschätzung wird im Folgenden von 1.000 Benutzern und einer 10 Mbit-Anbindung ins Internet ausgegangen. Von letzterer wird zudem angenommen, dass sie nicht ausgelastet ist und hier kein Flaschenhals entsteht.

Im Vergleich zum Recplast-Szenario resultiert aus diesen Rahmenbedingungen ein Zuwachs der Datenmenge um den Faktor 15. Mit Spielraum für Lastspitzen und unter Berücksichtigung des Wachstums der Umgebung wird im Folgenden davon ausgegangen, dass durchschnittlich ca. 25 Ereignisse pro Sekunde protokolliert werden:25 Ereignisse/s x 24h/Tag x 3600s/h x 150 Bytes = 324,00 Millionen Bytes/TagDeshalb wird im Folgenden eine Logdatenmenge von 150 MB (komprimiert) bzw. 325 MB (unkomprimiert) pro Tag angesetzt.

Absicherungsvorgaben für die gesammelten LogdatenDie zentral zu sammelnden Logdaten müssen entsprechend ihrem hohen Vertraulichkeitswert vor unbefugtem Zugriff geschützt werden. Für das P-A-P-Szenario wird gefordert, dass nur autorisiertes Personal Zugriffsrechte auf die Daten erhält und anderweitiger Zugriff unterbunden und überwacht werden muss. Dies kann durch entsprechende Rechte im Betriebssystem umgesetzt werden. Ergänzend sollten Access-Listen der Paketfilter erweitert werden.

Zwar kann der Squid auf Anonymisierung eingestellt werden, bei den E-Mail-Logdaten ist dies ohne Weiteres aber nicht realisierbar: hier können benutzerbezogene Daten nicht vollständig eliminiert werden.


Logdatenstudie

6.2.3 Analysemöglichkeiten für das P-A-P-Gateway

Im vorliegenden P-A-P-Gateway-Szenario sind keine Varianten wie im Recplast-Szenario zu berücksichtigen. Ziel der in diesem Abschnitt vorzustellenden Konzepte ist aber der stufenweise Aufbau einer Logging-Infrastruktur. Wie bereits erwähnt wird die Existenz eines Administrations- oder Management-Netzes vorausgesetzt, das von der Logging-Infrastruktur mitverwendet werden kann.

Als Startpunkt wird mit dem einfachen, die Logdaten nur sammelnden und speichernden Loghost begonnen.

Die darüber hinausgehende Stufe einer nachgelagerten Auswertung der gespeicherten Logdaten unterscheidet sich praktisch nicht von der im Recplast-Kapitel beschriebenen Variante eines Auswertungssystems. Die Leistungsfähigkeit und Architektur der Lösungen sind in großen Teilen identisch. Diese Stufe wird deshalb nur kurz gestreift.

Die letztendlich gewünschte Realisierungsstufe einer Logging-Infrastruktur ist eine solche, die wichtige Frühwarnfunktionen erfüllen kann. In einer abschließenden Diskussion wird aber noch eruiert, ob mit heutigen Produkten das Ziel einer vollständigen Frühwarnung für alle Sicherheitswerte Vertraulichkeit, Integrität und vor allem Verfügbarkeit überhaupt erreichbar ist.

6.2.3.1 Die Einführung eines zentralen Loghosts

Das P-A-P-Gateway ist durch seine Modularität, die Konzentration auf Unix/Linux als zentralem Betriebssystem und die hervorragende Interkonnektivität der Module relativ einfach um einen Loghost zu erweitern. Entsprechende Lösungen lassen sich jedoch auch in einer reinen Windows-Infrastruktur oder einem gemischten Szenario aufbauen. Jedoch wird in diesem Fall gegebenenfalls ein höherer Aufwand entstehen.

Das Übertragungsprotokoll der Wahl ist – dies ist kaum zu vermeiden – wiederum Syslog. Die Netzwerkgeräte machen den Einsatz dieses veralteten Protokolls praktisch notwendig. Der alternative Einsatz von SNMP ist nur in neuen Versionen des Protokolls als sicherer anzusehen. Diese Option wird aber seitens der Netzwerkausrüster nicht immer angeboten. Ausgehend von dieser Überlegung ist der Einsatz eines Loghosts auf der Basis von Linux und Syslog-ng ein logischer nächster Schritt.

Die Überlegung zur Platzierung eines solchen Loghosts ist im Wesentlichen unabhängig von der konkreten Ausformung des Loghost-Systems: Es ist egal, ob ein klassischer Syslogd oder Syslog-ng zum Einsatz kommt. Eine diesbezügliche, ausführliche Diskussion wird in der Studie „Konzeption von Sicherheitsgateways“ geführt. An dieser Stelle sei dennoch die Eigenheit von Syslog erwähnt, dass bei einer Weiterleitung von Syslog-Paketen über einen nicht entsprechend befähigten Syslog-Proxy der ursprüngliche Sender der Meldung durch die Daten des Proxies ersetzt wird und diese wichtige Information in der Meldung deshalb verloren zu gehen droht. Dieses Problem kann gelöst werden durch den Einsatz von Syslog-ng als Syslog-Proxy oder die generelle Vermeidung von Applikationsschicht-Komponenten auf dem Weg vom Syslog-Client zum Syslog-Server. Letzteres ist im P-A-P-Gateway umgesetzt, wenn man den Loghost im Management-Netz platziert.

Die Kommunikation aller oben aufgelisteten Gateway-Komponenten hin zum Loghost findet direkt statt: es sind außer routenden Instanzen keine in höheren Schichten arbeitenden Komponenten auf dem Weg – insbesondere keine Applikationsschicht-Geräte. Die Syslog-Pakete werden von den Geräten über ein dediziertes physikalisches Interface auf das Management-Netz gelegt, so dass die Pakete zu keinem Zeitpunkt unvertraute Netzbereiche passieren müssen.


Logdatenstudie

Syslog-Clients, die das gegenüber UDP wesentlich bessere TCP-Protokoll unterstützen, sollten auf der Server-Seite eine entsprechend konfigurierte Server-Komponente finden.

Die Paketfilter-Regelwerke bzw. -Access-Listen müssen um die neuen Kommunikationsbeziehungen erweitert werden. Für das Treffen dieser Regeln sollten aber selber keine Logmeldungen generiert werden, um Rekursionen zu vermeiden.

Eine solche Erweiterung des P-A-P-Gateways ist ihrerseits modular. Insbesondere kann der bisher beschriebene, auf Syslog-ng basierende Loghost durch einen Server oder eine Appliance ersetzt werden, ohne dass die umliegenden Geräte oder Regelwerke davon gravierend beeinflusst würden.

6.2.3.2 Nachgelagerte Analyse

Das Ziel einer nachgelagerten Analyse wurde bereits im Recplast-Szenario beschrieben (Abschnitt 6.1). Die Ausführung der Lösung dort unterscheidet sich nicht wesentlich vom Einsatz im P-A-P-Gateway.

Die zu verarbeitende Datenmenge ist in einer typischen P-A-P-Umgebung jedoch deutlich größer als im Recplast-Szenario. Dementsprechend ist die verwendete Hardware stärker auszulegen, die in Frage kommende Software ist aber dieselbe.


Abbildung 6.9: Beispiel Loghost in einem P-A-P-Gateway

Logdatenstudie

6.2.3.3 Echtzeit-Auswertung und IT-Frühwarnsystem

In diesem Abschnitt wird der Einsatz eines üblicherweise als Security Event Management (SEM) bezeichneten Systems beschrieben. Eine detaillierte Beschreibung solcher Produkte und ihrer Leistungsfähigkeit ist im Kapitel 133 nachzulesen.

Von den zuvor definierten Zielen ausgehend ist ein Schwerpunkt auf der Echtzeitanalyse der gesammelten Daten festzustellen. Denn nurdadurch wird es möglich, schnell und idealerweise sogar vorzeitig auf Angriffe und Störfälle zu reagieren. Aspekte des reinen Logdaten-Managements treten eher in den Hintergrund, u. a. auch die Frage nach der Speicherung der Daten im unveränderten Original-Format für die Einhaltung gesetzlicher Speicherfristen.

Um damit eine Echtzeitanalyse durchführen zu können, muss das SEM-Produkt vorrangig die folgenden Funktionen und Eigenschaften aufweisen:

– Syslog und SNMP müssen als Protokolle zum Empfang der Logmeldungen unterstützt werden.

– Die Lösung muss eine vollständige Normalisierung der Logdaten aller angeschlossenen Geräte anbieten. Auf dieser Basis wird eine leistungsfähige Datenkorrelation über verschiedene Produkte hinweg möglich.

– Die normalisierten Logdaten müssen in einer relationalen Datenbank abgespeichert werden, damit eine leistungsfähige nachträgliche Auswertung (in Form von Berichten) einerseits und andererseits auch eine nachgelagerte Korrelation der Daten durchgeführt werden können. Diese Datenbank muss die bei einer in diesem Umfeld typischen Speicherdauer von 30 Tagen erforderliche Speicherkapazität aufweisen (ca. 10 GB Datenbankgröße). Es darf dabei nicht zu Performance-Engpässen kommen.

– Es müssen Modellierungsfunktionen zumindest für das verwendete IP-Adress-Schema (Was ist intern, was extern?) vorhanden sein. Wünschenswert sind zudem Optionen, um Eigenschaften der berichtenden und der durch das Gateway geschützten Systeme zu hinterlegen, weil erst hierüber eine effiziente Priorisierung wichtiger Meldungen erreicht werden kann.

– Filterfunktionen müssen logisch gesehen so frühzeitig greifen, dass unerwünschte Logmeldungen nicht abgespeichert werden. Eine Filterung nach der Speicherung ist in diesem Sinne nicht effizient.

– Eine fortlaufende Korrelation der eintreffenden Meldungen muss im Arbeitsspeicher des SEM-Gerätes stattfinden, um angesichts der vielen eintreffenden Ereignisse schnell genug zu arbeiten.

– Als grundlegende Alarmierungsfunktion muss in die Lösung eine E-Mail-Benachrichtigungsfunktion integriert sein. Die Kopfzeile und der Textkörper der E-Mail-Nachricht müssen frei konfiguriert werden können.

– Die Konfiguration und Benutzerführung allgemein müssen leistungsfähig und hinreichend intuitiv sein, um dem Betriebspersonal die tägliche Arbeit ohne großen Schulungsaufwand zu ermöglichen.

Wie anschließend noch diskutiert wird, weist das P-A-P-Gateway zumindest zwei Eigenschaften auf, die den Einsatz einer einfachen, appliancebasierten Lösung ermöglichen:

1. Es müssen keine auf dem Betriebssystem Windows basierenden Systeme integriert werden. Wie mehrfach bereits diskutiert wurde, fällt dies aufgrund der von Haus aus nicht zu zentralisierenden Windows Logging-Architektur schwer. Auswege aus dieser Problematik führen zum Einsatz


Logdatenstudie

von Software-Agenten auf den Windows-Systemen, die in appliancebasierten Lösungen oft nicht angeboten werden.

2. Das Management-Netz, welches die Unzulänglichkeiten von Syslog abfängt, ist durch die Konzentration des Gateways an einem einzelnen Standort einfach realisierbar. Eine Verteilung über mehrere Standorte hinweg, z. B. für ein VPN, könnte den Einsatz von Agenten und dezentralen Loghosts notwendig machen.

Aufgrund der aufgeführten Anforderungen und des deutlich einfacheren Betriebs einer solchen Lösung wird der Einsatz einer Appliance empfohlen. Die explizit als fehlend aufgeführten Ausschlusskriterien begünstigen diese Empfehlung im Falle des P-A-P-Gateways.

Installation und Basiskonfiguration des SEM-SystemsDie Ersetzung des Linux-Loghosts durch eine Appliance ist aufgrund der Modularität des Gesamtkonzeptes denkbar einfach: die beiden Rechner können im Wesentlichen einfach gegeneinander ausgetauscht werden, siehe die Abbildung auf Seite 245.

Die anschließende Konfiguration der Appliance-Lösung geht über die mit dem Syslog-ng Loghost erreichbare (siehe Abschnitt 6.2.3.1) deutlich hinaus. Entsprechende Aufwände für eine initiale Konfiguration sind einzukalkulieren und bewegen sich insgesamt typischerweise im Bereich von zehn Personentagen, wenn die Anforderungen nicht über das hier Aufgezählte hinausgehen. Der Zeitraum für diese Phase erstreckt sich in der Regel über mindestens einen Monat, da das System im Laufe des initialen Betriebs sukzessive nachjustiert werden muss.

Folgende Aufgaben sind in dieser Phase zu bewerkstelligen:

– Anpassung der Paketfilter-Regeln

– Anpassung der Logging-Konfiguration der Einzelsysteme

– Abstimmung der benötigten Logmeldungs-Inhalte

– Dokumentation der Ziele

– Anschluss der Einzelsysteme und gezielte Überprüfung der Funktion

– Modellierung der überwachten Infrastruktur

– Erste manuelle Analyse von Logmeldungen und Aussortieren von unerwünschten Ereignissen

– Wiederholte Justierung mitgelieferter Korrelationsregeln, Erstellung eigener Korrelationsregeln

– Konfiguration von regelmäßig und automatisch zu erstellenden Berichten

– Wiederholte Kontrolle der Datenbank und der Korrelationsergebnisse

– Kontrolle der abgespeicherten Logdaten

• Kontrolle auf Vollständigkeit

• Regelmäßige automatische Bereinigung veralteter Daten nach einer bestimmten Zeit

– Übernahme des Systems in die Betriebsprozesse

Folgende organisatorische Aspekte sollten in der Planungsphase berücksichtigt werden:

– Oft sind mehrere Ansprechpartner und Projektstellen an der Planung und Durchführung zu beteiligen, beispielsweise die Teilsystem-Verantwortlichen für E-Mail, Proxies, Netzwerkkomponenten und das neue SEM-System. Außerdem darf der entstehende Verwaltungsaufwand nicht un


Logdatenstudie

terschätzt werden. Das Projekt sollte deshalb von vornherein eher größer als zu klein angelegt werden.

– Das Ziel des Projekts sollte darin bestehen, die Anforderungen aller beteiligten Stellen vorab zu erfassen und das Konzept daran zu testen.

6.2.4 Diskussion des Erreichten

Wie bereits erwähnt stellt natürlich auch das P-A-P-Gateway einen Spezialfall der Anwendung der SEM-Technologie dar. Seine Eigenheiten erlauben den Einsatz einer appliancebasierten Lösung, ohne Kompromisse hinsichtlich Leistungsfähigkeit und Lösungsumfang in Kauf nehmen zu müssen.

– Der Einsatz an einem lokalen Gateway erlaubt das „Ausbügeln“ von Schwächen des hier propagierten Syslog-Protokolls.

– Da keine Windows-Systeme integriert werden müssen, kann auf den Einsatz von Software-Agenten verzichtet werden, welche bei Appliance-Lösungen oft nicht mitgeliefert werden.

Wie würde die Architektur aussehen, wenn beide Prämissen aufgegeben werden müssten? Angenommen sei für diese Fragestellung eine verteilte VPN-Struktur mit mehreren Gateways ohne übergreifendes Management-Netzwerk und die Notwendigkeit, auch Windows-Server und -Applikationen zu integrieren.

Mit dem Ziel eine vertrauliche Übertragung der Logdaten zu erreichen, kann in diesem Fall das im Folgenden beschriebene, wesentlich komplexere Szenario angestrebt werden. Eine hierfür anzustrebende Lösung wäre analog anzupassen:

– Um die Logdaten jeder Lokation vor der Übertragung an die zentrale Stelle zwischenzuspeichern, würde man pro Lokation einen dezentralen Loghost platzieren. Dieser nimmt im Wesentlichen die Funktion des im P-A-P-Gateways eingangs beschriebenen Loghosts für jede Lokation ein.

– Sind auch jeweils Windows-Systeme vorhanden, so engt sich die Auswahl der Möglichkeiten drastisch ein: nur ein agentenbasiertes System mit Agenten für Windows ist dann in der Lage, die Daten sowohl dezentral zu sammeln als auch vertraulich zu übertragen. Pro Lokation wären sowohl Agenten auf den Windows-Systemen zu installieren als auch syslog-basierte Loghosts unterzubringen, die die gesammelten Meldungen verschlüsselt weiterleiten. Zu untersuchen ist, ob die VPN-Verschlüsselung genügt, oder auch gegenüber internen Benutzern die Vertraulichkeit der Logdaten gewahrt werden muss.

– Diese neuen dezentralen Komponenten des SEM-Systems würden die Meldungen insgesamt an ein zentrales SEM-System übertragen, wo übergreifende Speicherung und Korrelation stattfinden würden.

Nicht ohne Grund wurde in diesem Abschnitt von einem SEM-System gesprochen und nicht von einem Frühwarnsystem. Die im Rahmen dieser Studie verwendete Definition eines Frühwarnsystems schließt die Überwachung des wichtigen Wertes der Systemverfügbarkeit mit ein. Dieser Aspekt wird im Markt aber getrennt behandelt und über klassische Monitoring-Systeme wie Nagios ermöglicht. Eine integrierte Sichtweise für die Werte Vertraulichkeit, Integrität und Verfügbarkeit innerhalb eines einzelnen Produkts ist zumeist noch nicht umgesetzt, da die relativ neuen SEM-Technologien und die ausgereiften Überwachungssysteme in der Regel noch nicht vereint sind. Künftige


Logdatenstudie

Tendenzen hierzu sind aber bereits abzusehen, bzw. werden von einzelnen Herstellern bereits umgesetzt.

Für Recplast- wie auch für das P-A-P-Gateway-Szenario waren jeweils abgestufte Lösungsansätze notwendig. Dies ist bedingt durch den hohen Aufwand und die hohen Kosten der Einführung einer solchen Lösung. Ab wann lohnt sich der Aufbau einer vollwertigen Frühwarnungs- bzw. wenigstens SEM-Lösung?

Die Beantwortung der Frage ist über folgende Einflussfaktoren bestimmt:

– Existieren gesetzliche Vorschriften zur Vorhaltung und Speicherung von Logdaten, so ist die Einführung einer solchen Lösung unter Umständen auch schon für kleine Unternehmen nicht zu vermeiden. Als Beispiel seien hier Telekommunikations- und Internet-Dienste-Provider genannt.

– Die Menge der im einem Unternehmen anfallenden Logdaten macht eine Log-Management-Lösung eigentlich schon zu einem frühen Zeitpunkt notwendig. Typische IT-Budgets müssen für eine solche Lösung zurzeit aber fünf- bis sechsstellige Projektsummen berücksichtigen.

– Kleinere Lösungen wie Loghosts für die einfache Zentralisierung von Logdaten sind bereits mit deutlich geringen Aufwänden realisierbar. Mit etwas Geschick und dem Einsatz von Open-Source-Produkten fallen sogar oftmals nur Arbeitsaufwände an.


Logdatenstudie

7 Empfehlungen für zusätzliche Sicherheitsmaßnahmen

7.1 Einführung: Risikoanalyse auf der Basis von IT-Grundschutz

Dieser Anschnitt beschäftigt sich mit der Frage, welche ergänzenden Sicherheitsmaßnahmen bei der Speicherung und Verarbeitung von Logdaten ergriffen werden sollten.

Bei der Ermittlung des Schutzbedarfs werden die im Bereich IT-Grundschutz üblichen Schadensszenarien zugrunde gelegt:

– Verlust der Vertraulichkeit von Informationen

– Beeinträchtigung des informationellen Selbstbestimmungsrechts

– Beeinträchtigung der persönlichen Unversehrtheit

– Beeinträchtigung der Aufgabenerfüllung

– Negative Außenwirkung

– Finanzielle Außenwirkung

Ausgehend von der Möglichkeit, dass die Schutzziele im Hinblick auf Vertraulichkeit, Integrität oder Verfügbarkeit der Logdaten-Systeme oder der zugehörigen Informationen verloren gehen können, werden die realistischen Folgeschäden eines Verlustes dieser Grundwerte betrachtet. Da Logdaten-Systeme bei einem Angriff aktiv sowohl als Teil eines Frühwarnsystems als auch für forensische Zwecke zur Rekonstruktion des Angriffs eingesetzt werden, wird für die weitere Betrachtung die Schutzbedarfskategorie „hoch“ für die Vertraulichkeit und Integrität der Logdaten angenommen. Der Schutzbedarf hinsichtlich der Verfügbarkeit wurde in den Szenarien der Recplast GmbH und beim P-A-P-Sicherheits-Gateway als „normal“ festgelegt.

Schutzbedarfskategorie BeschreibungNormal Die Schadensauswirkungen sind begrenzt und

überschaubar.Hoch Die Schadensauswirkungen können beträchtlich

sein.Sehr hoch Die Schadensauswirkungen können ein existen

ziell bedrohliches, katastrophales Ausmaß erreichen.

Tabelle 80: BSI-Schutzbedarfskategorien (Quelle: BSI GSH)

7.1.1 Anforderungen und Pflichtenheft

Basierend auf dem BSI-Standard 100-3 und unter der Prämisse, dass Logdaten einen hohen Schutzbedarf bezüglich der Vertraulichkeit besitzen, wird in diesem Arbeitspaket eine Risikoanalyse auf der Basis des IT-Grundschutzes für die beiden Anwendungsszenarien des IT-Verbunds der Recplast GmbH und des P-A-P-Sicherheits-Gateways durchgeführt.


Logdatenstudie

Bei den nachfolgenden Ausführungen zur erweiterten Risikoanalyse wird vorausgesetzt, dass die Vorgehensweise nach IT-Grundschutz (IT-Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, Basis-Sicherheitscheck I) bekannt ist. Auf diese wird hier nicht weiter eingegangen. Im Abschnitt 7.2.4 werden vorrangig solche Sicherheitsmaßnahmen beschrieben, welche der Risikoreduktion dienen. Diese beschreiben neben den bestehenden Risiken konkrete Maßnahmen und Empfehlungen, welche bei der Einführung eines Logdaten-Management-Systems beachtet werden sollten.

7.1.2 Beschreibung zum schematischen Vorgehen

Die ergänzende Risikoanalyse in diesem Kapitel teilt sich in die Szenarien Recplast GmbH und P-A-P-Gateway auf. Im Falle der Recplast GmbH ergänzt die Risikoanalyse die Ausführungen aus den vorangegangenen Kapiteln 6.1 und 6.2. Die beschriebenen Risiken beziehen sich dabei auf den jeweiligen IT-Verbund, der in diesem Szenario vorgegeben wurde. Ausführungen zu den Bordmitteln der Systeme (Windows Server 2003, Linux etc.) sind hier jedoch nicht Bestandteil der Beschreibung. Vielmehr liegt der Fokus der Risikoanalyse auf der Log-Zentralisierung auf Basis der vorgeschlagenen Windows-Logdaten-Lösung.

Abbildung 7.1:Logfile-Pyramide

Im P-A-P-Szenario wird unabhängig vom Recplast-IT-Verbund die Einführung eines Logdaten-Management-Systems beschrieben (siehe Logdaten-Pyramide in Abb. 7.1). Dabei liegt der Schwerpunkt auf der Logzentralisierung, Auswertung und Echtzeitanalyse. Abweichend zum Recplast-Szenario kommt bei der Logzentralisierung eine Unix-/Linux-Variante zum Einsatz. Die Logauswertung im P-A-P-Szenario basiert inhaltlich auf den Ausführungen des Recplast-Szenarios. Dieses wird deshalb nicht noch einmal beschrieben. Im Folgenden wird nur auf die Änderungen näher eingegangen.


Frühwarnung, Echtzeit-Korrelation

Log-Auswertung, ohne Echtzeit

Log-Zentralisierung

Bordmittel

-

(X)

X

X-

(X)

X

X

P-A-P

Zusammenfassen in der Risikoanalyse

Zusammenfassen in der Risikoanalyse

Logdatenstudie

7.2 Risikoanalyse zum IT-Verbund der Recplast GmbH

7.2.1 Die Gefährdungsübersicht

Den Ausgangspunkt für die Risikoanalyse bei der Recplast GmbH bilden im ersten Schritt die Gefährdungen aus den Grundschutzkatalogen. Dabei fokussieren wir uns ausschließlich auf den Loghost, der restliche IT-Verbund wird in der Risikoanalyse berücksichtigt. Nachfolgend werden aus den relevanten Grundschutzbausteinen die Gefährdungen ausgewählt, welche aufgrund des hohen Schutzbedarfs der Daten bezüglich Vertraulichkeit und Integrität einer ergänzenden Risikoanalyse zugeführt werden müssen (rote Markierung). Der Grundwert Verfügbarkeit wurde für nachfolgende Bausteine als normal angenommen. Gefährdungen, die über die Standardmaßnahmen „normal“ ausreichend abgesichert sind (schwarze Markierung), werden nicht weiter betrachtet.


Logdatenstudie

B 3.101 Allgemeiner Server bezogen auf den LoghostG 1.1G 1.2

PersonalausfallAusfall des IT- Systems

G 2.7G 2.9G 2.25

Unerlaubte Ausübung von RechtenMangelhafte Anpassung an Veränderungen beim IT-EinsatzEinschränkung der Übertragungs- oder Bearbeitungsgeschwindigkeit durch Peer-to-Peer-Funktionalität

G 3.2G 3.3G 3.5G 3.6G 3.8G 3.9G 3.31

Fahrlässige Zerstörung des Geräts oder der Daten Nichtbeachtung von IT-Sicherheitsmaßnahmen Unbeabsichtigte Leitungsbeschädigung Gefährdung durch Reinigungs- oder Fremdpersonal Fehlerhafte Nutzung des IT-Systems Fehlerhafte Administration des IT-Systems Unstrukturierte Datenhaltung

G 4.1G 4.6G 4.7G 4.10G 4.13G 4.22G 4.39

Ausfall der Stromversorgung Spannungsschwankungen/Überspannung/Unterspannung Defekte Datenträger Komplexität der Zugangsmöglichkeiten zu vernetzten IT-Systemen Verlust gespeicherter Daten Software-Schwachstellen oder -Fehler Software-Konzeptionsfehler

G 5.1G 5.2G 5.7G 5.9G 5.15G 5.18G 5.19G 5.20G 5.21G 5.23G 5.26G 5.40G 5.71G 5.85

Manipulation/Zerstörung von IT-Geräten oder Zubehör Manipulation an Daten oder Software Abhören von LeitungenUnberechtigte IT-Nutzung "Neugierige" Mitarbeiter Systematisches Ausprobieren von PasswörternMissbrauch von Benutzerrechten Missbrauch von AdministratorrechtenTrojanische Pferde Computer-Viren Analyse des Nachrichtenflusses Abhören von Räumen mittels eines Rechners mit Mikrofon Vertraulichkeitsverlust schützenswerter InformationenIntegritätsverlust schützenswerter Informationen

Tabelle 81: Maßnahmenbewertung B 3.101 bezogen auf den Loghost


Logdatenstudie

B 3.108 Windows Server 2003 bezogen auf den LoghostG 1.2 Ausfall des IT-SystemsG 2.1G 2.4G 2.7G 2.8G 2.19G 2.22G 2.26G 2.67G 2.87G 2.92G 2.111G 2.114

G 2.115

G 2.116

Fehlende oder unzureichende Regelungen Unzureichende Kontrolle der IT-Sicherheitsmaßnahmen Unerlaubte Ausübung von RechtenUnkontrollierter Einsatz von Betriebsmitteln Unzureichendes Schlüsselmanagement bei der Verschlüsselung Fehlende Auswertung von ProtokolldatenFehlendes oder unzureichendes Test- und Freigabeverfahren Ungeeignete Verwaltung von Zugangs- und ZugriffsrechtenVerwendung unsicherer Protokolle in öffentlichen NetzenFehlerhafte Regelungen für den Browser-Zugriff auf Exchange Kompromittierung von Anmeldedaten bei einem Dienstleisterwechsel Uneinheitliche Windows Server 2003-Sicherheitseinstellungen bei SMB, RPC und LDAP Ungeeigneter Umgang mit den Standard-Sicherheitsgruppen von Windows Server 2003 Datenverlust beim Kopieren oder Verschieben von Daten unter Windows Server 2003

G 3.1

G 3.2G 3.9G 3.16G 3.38G 3.44G 3.48

G 3.49G 3.56G 3.57G 3.58G 3.81

Vertraulichkeits-/Integritätsverlust von Daten durch Fehlverhalten der IT-BenutzerFahrlässige Zerstörung des Geräts oder der Daten Fehlerhafte Administration des IT-Systems Fehlerhafte Administration von Zugangs- und ZugriffsrechtenKonfigurations- und BedienungsfehlerSorglosigkeit im Umgang mit InformationenFehlerhafte Konfiguration von Windows 2000-/XP-/Server 2003-basierten IT-Systemen Fehlerhafte Konfiguration des Active Directory Fehlerhafte Einbindung des IIS in die Systemumgebung Fehlerhafte Konfiguration des Betriebssystems für den IISFehlerhafte Konfiguration eines IISUnsachgemäßer Einsatz von Sicherheitsvorlagen für Windows Server 2003

G 4.10G 4.13G 4.22G 4.33G 4.34G 4.35G 4.36G 4.39G 4.54G 4.55

Komplexität der Zugangsmöglichkeiten zu vernetzten IT-Systemen Verlust gespeicherter Daten Software-Schwachstellen oder -Fehler Schlechte oder fehlende AuthentisierungAusfall eines KryptomodulsUnsichere kryptographische AlgorithmenFehler in der Verschlüsselung Software-KonzeptionsfehlerVerlust des Schutzes durch das verschlüsselnde Dateisystem EFS Datenverlust beim Zurücksetzen des Kennworts in Windows Server 2003/XP

G 5.2G 5.7G5.16

Manipulation an Daten oder SoftwareAbhören von LeitungenGefährdung bei Wartungs-/Administrationsarbeiten durch internes Personal


Logdatenstudie

G 5.17G 5.19G 5.20G 5.21G 5.23G 5.26G 5.48G 5.50G 5.52

G 5.71G 5.79G 5.81G 5.84G 5.85G 5.127G 5.132G 5.133

Gefährdung bei Wartungsarbeiten durch externes Personal Missbrauch von BenutzerrechtenMissbrauch von AdministratorrechtenTrojanische PferdeComputer-VirenAnalyse des NachrichtenflussesIP-SpoofingMissbrauch des ICMP-ProtokollsMissbrauch von Administratorrechten im Windows NT-/2000-/XP-/Server 2003- System Vertraulichkeitsverlust schützenswerter InformationenUnberechtigtes Erlangen von Administratorrechten unter Windows Server 2003Unautorisierte Benutzung eines KryptomodulsGefälschte ZertifikateIntegritätsverlust schützenswerter InformationenSpywareKompromittierung einer RPD-Benutzersitzung unter Windows Server 2003 Unautorisierte Benutzung webbasierter Administrationswerkzeuge



Logdatenstudie

B 5.2 Webserver bezogen auf den LoghostG 2.1G 2.4G 2.7G 2.9G 2.28G 2.32G 2.37G 2.96G 2.100

Fehlende oder unzureichende Regelungen Unzureichende Kontrolle der IT-Sicherheitsmaßnahmen Unerlaubte Ausübung von Rechten Mangelhafte Anpassung an Veränderungen beim IT-Einsatz Verstöße gegen das Urheberrecht Unzureichende Leitungskapazitäten Unkontrollierter Aufbau von Kommunikationsverbindungen Veraltete oder falsche Informationen in einem Webangebot Fehler bei der Beantragung und Verwaltung von Internet-Domänennamen

G 3.1

G 3.37G 3.38

Vertraulichkeits-/Integritätsverlust von Daten durch Fehlverhalten der IT-Benutzer Unproduktive Suchzeiten Konfigurations- und Bedienungsfehler

G 4.10G 4.22G 4.39

Komplexität der Zugangsmöglichkeiten zu vernetzten IT-Systemen Software-Schwachstellen oder FehlerSoftware-Konzeptionsfehler

G 5.2G 5.19G 5.20G 5.21G 5.23G 5.28G 5.43G 5.48G 5.78G 5.87G 5.88

Manipulation an Daten oder Software Missbrauch von BenutzerrechtenMissbrauch von AdministratorrechtenTrojanische PferdeComputer-VirenVerhinderung von Diensten Makroviren IP-SpoofingDNS-SpoofingWeb-Spoofing Missbrauch aktiver Inhalte



Logdatenstudie

B 5.7 Datenbanken bezogen auf den LoghostG 2.22G 2.26G 2.38

G 2.39G 2.40G 2.41G 2.57G 2.110

Fehlende Auswertung von Protokolldaten Fehlendes oder unzureichendes Test- und Freigabeverfahren Fehlende oder unzureichende Aktivierung von Datenbank-Sicherheitsmechanismen Mangelhafte Konzeption eines DBMS Mangelhafte Konzeption des Datenbankzugriffs Mangelhafte Organisation des Wechsels von Datenbankbenutzern Nicht ausreichende Speichermedien für den Notfall Mangelhafte Organisation bei einem Versionswechsel und bei der Migration von Datenbanken

G 3.6G 3.16G 3.23G 3.24G 3.80

Gefährdung durch Reinigungs- oder Fremdpersonal Fehlerhafte Administration von Zugangs- und Zugriffsrechten Fehlerhafte Administration eines DBMS Unbeabsichtigte DatenmanipulationFehler bei der Synchronisation von Datenbanken

G 4.26G 4.27G 4.28G 4.30

Ausfall einer Datenbank Unterlaufen von Zugriffskontrollen über ODBC Verlust von Daten einer Datenbank Verlust der Datenbankintegrität/-konsistenz

G 5.9G 5.10G 5.18G 5.64G 5.65G 5.131

Unberechtigte IT-Nutzung Missbrauch von Fernwartungszugängen Systematisches Ausprobieren von PasswörternManipulation an Daten oder Software bei Datenbanksystemen Verhinderung der Dienste eines Datenbanksystems SQL-Injection


7.2.2 Ermittlung zusätzlicher Gefährdungen

Als Ergänzung zu den Gefährdungen aus den Grundschutzkatalogen sind in diesem Abschnitt weitere Gefährdungen zu finden, die aufgrund der Kommunikation mit dem Logdaten-System auftreten können. Dabei werden folgende spezielle Fragestellungen im Hinblick auf die Logdaten-Management-Lösung beachtet:

– Was sollte bei der Konzeption eines Logdaten-Systems bei der Recplast GmbH beachtet werden?

– Welche organisatorischen Mängel müssen bei der Recplast GmbH im Hinblick auf ein Logdaten- System vermieden werden?

– Welche Sicherheitsprobleme können bei einem technischen Versagen entstehen?

– Durch welche Schwachstellen können die Datensätze und die Kommunikation mit einem Logdaten-System gestört werden?


Logdatenstudie

– Gibt es bestehende Publikationen in Foren, bei Herstellern, Newsgroups, die sicherheitsrelevante Punkte weitergehend beleuchten?

Die nachfolgend beschriebenen Gefährdungen zeigen weitere Bedrohungen für ein Logdaten-Management-System auf, welche die Vertraulichkeit und die Integrität des Systems beeinträchtigen können.

Logdaten-Management (LM)Vertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 1.LM Kompromittierung der Logdaten-Kommunikation, fehlendes Out-of-band-ManagementAlle am Logdaten-Management partizipierenden Datenquellen halten keine separate Schnittstelle zur Übertagung von Log- und Monitoringdaten vor. Die Daten müssen über gemeinsam genutzte Kommunikationskanäle gesendet werden. Im Hinblick auf den Schutzbedarf sensitiver Daten ist dies nicht vertretbar.

Tabelle 85: Zusätzliche Gefährdung: Kompromittierung der Logdaten-Kommunikation


hochhochnormal

G 2.LM Falsche Platzierung des Loghosts im NetzIm Netzwerk der Recplast GmbH besteht kein vom Rest des IT-Verbundes abgetrenntes, dediziertes Management-Netz. Da sensitive Daten aus vielen Datenquellen an zentraler Stelle zusammengeführt werden und aufgrund des hohen Informationsgehalts, reichen die im Netzwerk der Recplast implementierten Sicherheitsmaßnahmen nicht aus. Das Logdaten-Management ist deshalb durch weitere Sicherheitsmaßnahmen in besonderer Weise zu schützen.

Tabelle 86: Zusätzliche Gefährdung: Falsche Platzierung des Loghosts


Logdatenstudie


hochhochnormal

G 3.LM Fehlende Authentifizierung von logrelevanten SystemenBeim Aufbau der Kommunikationsverbindung zwischen dem Logdaten-Management und den zuliefernden Datenquellen ist besonderes Augenmerk auf die Authentisierung der Kommunikationsteilnehmer zu legen. Die Kenntnis der Herkunft von Log- und Monitoringdaten ist von zentraler Bedeutung für die korrekte Arbeitsweise eines Logdaten-Managements. Die im Netzwerk der Recplast GmbH vorgehaltenen Authentisierungsmechanismen reichen nicht aus, um diese Anforderung zu erfüllen.

Tabelle 87: Zusätzliche Gefährdung: Fehlende Authentifizierung


hochhochnormal

G 4.LM Mangelndes Wissen und Fähigkeiten im Betrieb eines Loghosts Die Komplexität des zu implementierenden Logdaten-Managements muss den personellen Fähigkeiten des Anwenders oder Administrators entsprechen. Um ein solches System betreiben und die auftretenden Ereignisse analysieren zu können, ist Spezialwissen zu Analysetechniken und Angriffsarten erforderlich. Dieses Wissen ist zurzeit bei der Recplast GmbH nicht vorhanden.

Tabelle 88: Zusätzliche Gefährdung: Mangelndes Wissung und Fähigkeiten im Betrieb eines Loghosts


hochhochnormal

G 5.LM Fehlende Zeitsynchronisation des Loghosts und der zu überwachenden SystemeFür die korrekte Arbeitsweise eines Logdaten-Managements muss die Zeit auf allen relevanten Systemen synchronisiert werden. Die Auswertung von Angriffsverläufen ist auf die korrekte Zuordnung des Zeitpunkts des Angriffs angewiesen. Die Recplast GmbH hält allerdings keinen Dienst zur Synchronisation des Datums und der Uhrzeit vor.

Tabelle 89: Zusätzliche Gefährdung: Fehlende Zeitsynchronisation


Logdatenstudie


hochhochnormal

G 6.LM Fehlende Trennung von Überwachungs- und Kontrollaufgaben vom IT-BetriebAufgrund der sensitiven und zum Teil benutzerbezogenen Daten sollte die Administration des Logdaten-Managements von den administrativen Vorgängen des Betriebssystems getrennt sein. Diese Vorgehensweise dient einerseits dem Schutz der Komponenten des Logdaten-Managements vor Fehlkonfigurationen. Andererseits können die sensitiven Daten nur von zugelassenem Personal verarbeitet werden (beispielsweise von Analysten und Sicherheitsbeauftragten). Die Trennung dieser Rollen ist bei der Recplast GmbH nicht gegeben.

Tabelle 90: Zusätzliche Gefährdung: Fehlende Aufgabentrennung im Logdatenmanagement

7.2.3 Gefährdungsbewertung

In der nachfolgenden Gefährdungsbewertung werden aus den Bausteinen Allgemeiner Server, Windows Server 2003, Webserver und Datenbank die Gefährdungen und deren IT-Sicherheitsmaßnahmen im Hinblick auf einen ausreichenden Schutz überprüft. Es handelt sich dabei um Standard-Sicherheitsmaßnahmen aus den IT-Grundschutz-Katalogen. Darüber hinaus werden die zusätzlichen Gefährdungen anhand der folgenden Kriterien bewertet:

– Sind die vorgeschlagenen Standard-Sicherheitsmaßnahmen vollständig, um auch vor Gefährdungen mit der Schadensauswirkungen „hoch“ angemessenen Schutz zu bieten?

– Sind die Mechanismen der Standard-Sicherheitsmaßnahmen ausreichend stark, um auch die Anforderung der Schadensauswirkungen „hoch“ zu gewährleisten?

– Sind die vorgesehen Sicherheitsmechanismen zuverlässig genug, damit sie nicht umgangen werden können?

Die Ergebnisse der Bewertung werden in den nachfolgenden Tabellen bewertet. Zielobjekte, bei denen durch die Maßnahmen der IT-Grundschutz-Kataloge den Risiken ausreichend Rechnung getragen wird, werden mit OK=J gekennzeichnet. In den Fällen, in denen diese Maßnahmen nicht ausreichen und ein Restrisiko besteht, wird der Vermerk OK=N angegeben. Diese Risiken werden anschließend im nächsten Abschnitt ausführlich behandelt.


Logdatenstudie

B 3.101 Allgemeiner Server bezogen auf den LoghostVertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 3.2 Fahrlässige Zerstörung von Geräten oder Daten OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.318/A, Sichere Installation eines ServersM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.240/Z, Einrichten einer Testumgebung für einen Server M5.9/B, Protokollierung am Server – die Protokoll-Informationen des Loghosts werden auch für die Auswertung mitbenutzt.

G 3.3 Nichtbeachtung von IT-Sicherheitsmaßnahmen OK=JM2.22/A, Hinterlegung des Passwortes – für den Loghost ist aufgrund der hohen Integrität und Vertraulichkeit der Daten eine Hinterlegung des Passwortes bei der Geschäftsleitung sinnvoll, um die Unabhängigkeit von der IT gewährleisten zu können. M2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkung für Accounts und/oder TerminalsM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.93/B, Regelmäßige IntegritätsprüfungM4.239/A, Sicherer Betrieb eines ServersM4.240/Z, Einrichten einer Testumgebung für einen ServerM5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am ServerM5.10/A, Restriktive Rechtevergabe – diese ist speziell bei Logfile-Lösungen zu beachten, damit das System nicht kompromittiert wird.

G 3.9 Fehlerhafte Administration des IT-Systems OK=JM2.315/A, Planung des Server-EinsatzesM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM2.318/A, Sichere Installation eines ServersM2.319/C, Migration eines ServersM2.24/A, Einführung eines PC-Checkheftes – diese Maßnahme gilt insbesondere dann, wenn sonst keine weitere Dokumentation (z. B. in einer Asset-DB oder CMDB) genutzt wird.M4.93/B, Regelmäßige IntegritätsprüfungM4.240/Z, Einrichten einer Testumgebung für einen Server


Logdatenstudie

M5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am Server – gilt auch für den Loghost, dessen Protokoll-Informationen in die Auswertung mit einfließenM5.10/C, Restriktive RechtevergabeM6.24/A, Erstellung eines Notfall-Bootmediums

G 4.13 Verlust gespeicherter Daten OK=JM6.24/A, Erstellen eines Notfall-BootmediumsM6.96/A, Notfallvorsorge für einen Server

G 4.39 Software-Konzeptionsfehler OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.273/A, Auswahl geeigneter Grundstrukturen für Sicherheits-GatewaysM2.315/A, Planung des Server-EinsatzesM2.317/C, Beschaffungskriterien für einen ServerM2.318/A, Sichere Installation eines ServersM2.319/C, Migration eines ServersM4.237/A, Sichere Grundfunktion eines IT-SystemsM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM4.249/Z, Windows XP-Systeme aktuell halten – dieser Client-Baustein für ist nicht für den Windows Server 2003 zutreffend

G 5.2 Manipulation an Daten oder Software OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.204/A, Verhinderung ungesicherter Netzzugänge M2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.93/B, Regelmäßige IntegritätsprüfungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM4.240/Z, Einrichten einer Testumgebung für einen ServerM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentisierungsdienstesM5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am ServerM5.10/A, Restriktive RechtevergabeM5.37/B, Einschränken der Peer-to-Peer-Funktion in einem serverge


Logdatenstudie

stützten Netz M5.138/Z, Einsatz von Radius-Servern

G 5.7 Abhören von Leitungen OK=JM2.204/A, Verhinderung ungesicherter NetzzugängeM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM2.318/A, Sichere Installation eines ServersM4.7/A, Änderung voreingestellter Passwörter M4.16/A, Zugangsbeschränkung für Accounts und/oder TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.239/A, Sicherer Betrieb eines ServersM4.250/Z, Auswahl eines zentralen, netzbasierten Authentisierungsdienstes M5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.10/A, Restriktive Rechtevergabe

G 5.18 Systematisches Ausprobieren von Passwörtern OK=JM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Änderung voreingestellter Passwörter M4.15/A, Gesichertes LoginM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.239/A, Sicherer Betrieb eines Servers

G 5.19 Missbrauch von Benutzerrechten OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Änderung von voreingestellten Passwörtern M4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkung für Accounts und/oder TerminalsM4.17/A, Sperren und Löschen nicht benötigter Accounts und Terminals M4.39/B, Abschalten des Anrufbeantworters bei Anwesenheit – nicht zutreffendM4.93/B, Regelmäßige IntegritätsprüfungM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentifizierungsdienstesM5.9/B, Protokollierung am ServerM5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz M5.138/Z Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

G 5.20 Missbrauch von Administratorrechten OK=N


Logdatenstudie

M2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen Server M4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.39/B, Abschalten des Anrufbeantworters bei Anwesenheit – nicht zutreffendM4.93/B, Regelmäßige IntegritätsprüfungM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentisierungsdienstesM5.9/B, Protokollierung am ServerM5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz M5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

Als zusätzliche Maßnahme zur Sicherung des Loghosts sollte aufgrund des hohen Schutzbedarfs der Daten bezüglich Vertraulichkeit und Integrität die Maßnahme M4.238 (Einsatz eines lokalen Paketfilters) umgesetzt werden. Nähere Ausführungen hierzu finden sich in der Risikobehandlung.

G 5.21 Missbrauch von Administratorrechten OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.273/A, Zeitnahes Einspielen sicherheitsrelevanter Patches und UpdatesM4.93/B, Regelmäßige IntegritätsprüfungM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM6.24/A, Erstellen eines Notfall-Bootmediums

G 5.23 Computer-Viren OK=JM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM4.239/A, Sicherer Betrieb eines ServersM6.24/A, Erstellen eines Notfall-Bootmediums

G 5.26 Analyse des Nachrichtenflusses OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.318/A, Sichere Installation eines ServersM4.239/A, Sicherer Betrieb eines Servers


Logdatenstudie

M5.8/B, Regelmäßiger Sicherheitscheck des NetzesG 5.71 Vertraulichkeitsverlust schützenswerter Informationen OK=J

M2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.138/B, Strukturierte DatenhaltungM2.273/A, Zeitnahes Einspielen sicherheitsrelevanter Patches und UpdatesM2.315/A, Planung des Server-EinsatzesM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen Server M2.320/A, Geregelte Außerbetriebnahme eines Servers M4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkung für Accounts und/oder TerminalsM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.40/C, Verhinderung der unautorisierten Nutzung des RechnermikrofonsM4.93/B, Regelmäßige IntegritätsprüfungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.239/A, Sicherer Betrieb eines ServersM4.240/Z, Einrichten einer Testumgebung für einen Server M4.250/Z, Auswahl eines zentralen, netzbasierten AuthentifizierungsdienstesM5.8/B, Regelmäßiger Sicherheitsscheck des NetzesM5.9/B, Protokollierung am Server M5.10/A, Restriktive Rechtevergabe M5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten NetzM5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

G 5.85 Integritätsverlust schützenswerter Informationen OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des Systems M2.138/B, Strukturierte DatenhaltungM2.237/A, Planung der Partitionierung und Replikation im Novell eDirectory – für den Loghost-Server nicht zutreffendM2.315/A, Informationen für alle Mitarbeiter über die Faxnutzung – für den Loghost-Server nicht zutreffendM2.316/A, Einweisung in die Bedienung des Anrufbeantworters – für den Loghost-Server nicht zutreffend


Logdatenstudie

M4.7/A, Änderung voreingestellter Passwörter M4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkungen für Accounts und/oder TerminalsM4.17/A, Sperren und Löschen nicht benötigter Accounts und Terminals M4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.93/B, Regelmäßige IntegritätsprüfungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4,239/A, Sicherer Betrieb eines Servers M4.240/Z, Einrichten einer Testumgebung für einen Server M5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am Server M5.10/A, Restriktive RechtevergabeM5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz

Tabelle 91: Gefährdungsbewertung B 3.1.1 bezogen auf den Loghost


Logdatenstudie

B 3.108 Windows Server 2003 bezogen auf den LoghostVertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 2.4 Unzureichende Kontrolle der IT-Sicherheitsmaßnahmen OK=JM2.174/A, Sicherer Betrieb eines WebserversM4.93/B, Regelmäßige Integritätsprüfung

G 2.22 Fehlende Auswertung von Protokolldaten OK=JM2.126/A, Erstellung eines DatenbanksicherheitskonzeptesM2.127/B, InferenzpräventionM2.133/A, Kontrolle der Protokolldateien eines Datenbanksystems

G 3.1 Vertraulichkeits-/Integritätsverlust von Daten durch Fehlverhalten der IT-Benutzer

OK=J

M2.173/A, Festlegung einer WWW-SicherheitsstrategieM2.174/A, Sicherer Betrieb eines WWW-ServersM2.176/B, Geeignete Auswahl eines Internet Service Providers – nicht zutreffendM4.34/Z, Einsatz von Verschlüsselungsmechanismen, Checksummen oder digitalen Signaturen. M4.64/C, Verifizieren der zu übertragenen Daten vor der Weitergabe/Beseitigung von Restinformationen – nicht zutreffend.M4.93/B, Regelmäßige Integritätsprüfung.M4.94/A, Schutz der WWW-DateienM4.95/A, Minimales BetriebssystemM4.99/C, Schutz gegen die nachträgliche Veränderung von DatenM6.64/Z, Behebung von Sicherheitsvorfällen. M5.66/Z, Verwendung von SSLM5.69/A Schutz vor aktiven Inhalten

G 3.2 Fahrlässige Zerstörung von Geräten oder Daten OK=JM2.32/Z, Einrichten einer eingeschränkten BenutzerumgebungM2.318/A, Sichere Installation eines ServersM4.17/A, Sperren und Löschen nicht benötigter AccountsM4.24/A, Sicherstellen einer konsistenten SystemverwaltungM4.240/Z, Einrichten einer Testumgebung für einen ServerM5.9/B, Protokollierung am Server

G 3.9 Fehlerhafte Administration des IT-Systems OK=JM2.315/A, Planung des Server-EinsatzesM2.316/A, Festlegen eine Sicherheitsrichtlinie für einen allgemeinen ServerM2.318/A, Sichere Installation eines ServersM4.240/Z, Einrichten einer TestumgebungM5.9/B, Protokollierung am ServerM5.10/C, Restriktive Rechtevergabe


Logdatenstudie

G 3.16 Fehlerhafte Administration von Zugangs- und Zugriffsrechten OK=JM2.31/A, Dokumentation der zugelassenen Benutzer und RechteprofileM2.127/B, InferenzpräventionM2.128/A, Zugangskontrolle für eine DatenbankM2.129/A, Zugriffskontrolle für eine DatenbankM2.131/C, Aufteilung von Administrationstätigkeiten bei DatenbankenM2.132/A, Regelung für die Einrichtung von Datenbankbenutzern/-gruppenM4.67/B, Sperren und Löschen nicht benötigter Datenbank-AccountsM4.68/A, Sicherstellung einer konsistenten DatenbankverwaltungM4.69/B, Regelmäßiger Sicherheitscheck der Datenbank

G 3.38 Konfigurations- und Bedienungsfehler OK=JM2.364/A, Planung der Administration für Windows Server 2003M2.366/B, Nutzung von Sicherheitsvorlagen unter Windows Server 2003M2.367/C, Einsatz von Kommandos und Skripten unter Windows Server 2003M2.368/C, Umgang mit administrativen Vorlagen unter Windows Server 2003M4.279/Z, Erweiterte Sicherheitsaspekte von Windows Server 2003 M4.280/A, Sichere Basiskonfiguration von Windows Server 2003M4.281/A, Sichere Installation und Bereitstellung von Windows Server 2003

G 4.13 Verlust gespeicherter Daten OK=JM 6.99/A, Regelmäßige Sicherung wichtiger Systemkomponenten von Windows Server 2003

G 5.2 Manipulation an Daten oder Software OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.204/A, Verhinderung ungesicherter NetzzugängeM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen Server M4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.93/B, Regelmäßige IntegritätsprüfungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM4.240/Z, Einrichtung einer Testumgebung für einen ServerM4.250/Z, Auswahl eines zentralen, netzbasierten Authentisierungs


Logdatenstudie

dienstesM5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am ServerM5.10/A, Restriktive RechtevergabeM5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten NetzM5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

G 5.7 Abhören von Leitungen OK=JM2.204/A, Verhinderung ungesicherter NetzzugängeM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM2.318/A, Sichere Installation einer ServersM4.7/A, Änderung voreingestellter PasswörterM4.16/A, Zugangsbeschränkungen für Accounts oder TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.239/A, Sicherer Betrieb eines ServersM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentisierungsdienstesM5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.10/A, Restriktive Rechtevergabe

G 5.19 Missbrauch von Benutzerrechten OK=JM2.32/Z, Einrichten einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkungen für Accounts und/oder Terminals M4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.39/B, Abschalten eines Anrufbeantworters bei Anwesenheit – nicht zutreffend M4.93/B, Regelmäßige IntegritätsprüfungM4.250/Z, Auswahl eines zentralen, netzbasierten Authentisierungsdienstes M5.9/B, Protokollierung am Server M5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz M5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

G 5.20 Missbrauch von Administratorrechten OK=N


Logdatenstudie

M2.32/Z, Einrichten einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellen einer konsistenten SystemverwaltungM4.39/B, Abschalten des Anrufbeantworters bei Anwesenheit – nicht zutreffend M4.93/B, Regelmäßige Integritätsprüfung M4.250/Z, Auswahl eines zentralen, netzbasierten AuthentifizierungsdienstesM5.9/B, Protokollierung am ServerM5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz M5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

Als zusätzliche Maßnahme zur Sicherung des Loghosts sollte aufgrund des hohen Schutzbedarfs der Daten bezüglich Vertraulichkeit und Integrität die Maßnahme M4.238 (Einsatz eines lokalen Paketfilters) umgesetzt werden. Nähere Ausführungen hierzu finden sich in der Risikobehandlung.

G 5.21 Trojanische Pferde OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.273/A, Zeitnahes Einspielen sicherheitsrelevanter Patches und UpdatesM4.93/B, Regelmäßige IntegritätsprüfungM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM6.24/A, Erstellen eines Notfall-Bootmediums

G 5.23 Computer-Viren OK=JM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM4.239/A, Sicherer Betrieb eines ServersM6.24/A, Erstellen eines Notfall-Bootmediums

G 5.26 Analyse des Nachrichtenflusses OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.318/A, Sichere Installation eines ServersM4.239/A, Sicherer Betrieb eines Servers


Logdatenstudie

M5.8/B, Regelmäßiger Sicherheitscheck des NetzesG 5.48 IP-Spoofing OK=J

M2.172/A, Entwicklung eines Konzeptes für die WWW-NutzungM5.64/Z, Secure Shell – für den Loghost nicht zutreffend

G 5.71 Vertraulichkeitsverlust schützenswerter Informationen OK=JM2.32/Z, Einrichten einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.138/B, Sichere Installation eines ServersM2.273/A, Zeitnahes Einspielen sicherheitsrelevanter Patches und Updates M2.315/A, Planung des Server-EinsatzesM2.316/A, Festlegen der Sicherheitsrichtlinie für einen allgemeinen ServerM2.320/A, Geregelte Außerbetriebnahme eines ServersM4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkungen für Accounts und/oder TerminalsM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.40/C, Verhinderung der unautorisierten Nutzung des RechnermikrofonsM4.93/B, Regelmäßige IntegritätsprüfungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.239/A, Sicherer Betrieb eines ServersM4.240/Z, Einrichtung einer Testumgebung für einen ServerM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentifizierungsdienstesM5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am ServerM5.10/A, Restriktive Rechtevergabe M5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten NetzM5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

G 5.79 Unberechtigtes Erlangen von Administratorrechten unter Windows Server 2003

OK=J

M2.364/A, Planung der Administration für Windows Server 2003M4.48/A, Passwortschutz für NT-basierte IT-SystemeM4.52/A, Geräteschutz für NT-basierte IT-Systeme M4.280/A, Sichere Basiskonfiguration von Windows Server 2003 M4.284/B, Umgang mit Diensten unter Windows Server 2003


Logdatenstudie

G 5.85 Integritätsverlust schützenswerter Informationen OK=JM2.32/Z, Einrichten einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.138/B, Strukturierte DatenhaltungM2.237/A, Planung der Partitionierung und Replikation im Novell eDirectory – nicht zutreffendM2.315/A, Planung des Server-EinsatzesM2.316/A, Festlegen einer Sicherheitsrichtlinie für eine allgemeinen Server M4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes Login M4.16/A, Zugangsbeschränkungen für Accounts und/oder Terminals M4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.93/B, Regelmäßige IntegritätsprüfungM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4,239/A, Sicherer Betrieb eines ServersM4.240/Z, Einrichten einer Testumgebung für einen ServerM5.8/B, Regelmäßiger Sicherheitscheck des NetzesM5.9/B, Protokollierung am ServerM5.10/A, Restriktive RechtevergabeM5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz

G 5.133 Unautorisierte Benutzung webbasierter Administrationswerkzeuge OK=JM2.31/A, Dokumentation der zugelassenen Benutzer und Rechteprofile M2.125/A, Installation und Konfiguration einer DatenbankM2.126/A, Erstellung eines DatenbanksicherheitskonzeptesM2.128/A, Zugangskontrolle für eine DatenbankM2.129/A, Zutrittskontrolle für eine DatenbankM2.133/A, Kontrolle der Protokolldateien einer DatenbankM2.363/B, Schutz gegen SQL-InjectionM4.70/C, Durchführung einer DatenbanküberwachungM4.71/C, Restriktive Handhabung von Datenbank-Links – nicht zutreffendM4.72/Z, Datenbankverschlüsselung – widerspricht den Anforderungen an die Performanz eines Logdaten-Managements

Tabelle 92: Gefährdungsbewertung B 3.108 bezogen auf den Loghost


Logdatenstudie

B 5.2 Webserver bezogen auf den LoghostVertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 4.39 Software-Konzeptionsfehler OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.273/A, Zeitnahes Einspielen sicherheitsrelevanter Patches und UpdatesM2.315/A, Planung des Service-EinsatzesM2.317/C, Beschaffungskriterien für einen Server M2.318/A, Sichere Installation eines ServersM2.319/C, Migration eines ServersM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM4.249/Z, Windows XP-Systeme aktuell halten – nicht zutreffend, da es sich hierbei um eine Maßnahme für ein Client-System handelt

G 5.19 Missbrauch von Benutzerrechten OK=JM2.32/Z, Einrichten einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen Server M4.7/A, Änderung voreingestellter PasswörterM4.15/A, Gesichertes LoginM4.16/A, Zugangsbeschränkungen für Accounts und/oder TerminalsM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.39/B, Abschalten des Anrufbeantworters bei Anwesenheit – für den Loghost-Server nicht zutreffendM4.93/B, Regelmäßige IntegritätsprüfungM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentisierungsdienstesM5.9/B, Protokollierung am Server M5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz M5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

G 5.20 Missbrauch von Administratorrechten OK=NM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen Server M4.7/A, Änderung voreingestellter Passwörter


Logdatenstudie

M4.15/A, Gesichertes LoginM4.17/A, Sperren und Löschen nicht benötigter Accounts und TerminalsM4.24/A, Sicherstellung einer konsistenten SystemverwaltungM4.39/B, Abschalten des Anrufbeantworters bei Anwesenheit – ist für den Loghost-Server nicht zutreffend M4.93/B, Regelmäßige IntegritätsprüfungM4.250/Z, Auswahl eines zentralen, netzbasierten AuthentisierungsdienstesM5.9/B, Protokollierung am Server M5.37/B, Einschränken der Peer-to-Peer-Funktionalitäten in einem servergestützten Netz M5.138/Z, Einsatz von Radius-Servern – aufgrund der Größe des IT-Verbunds der Recplast GmbH ist der Aufwand für den Einsatz eines Radius-Servers zu groß, er sollte aber bei einer Erweiterung des IT-Verbundes eingeplant werden

Als zusätzliche Maßnahme für die Sicherung des Loghosts sollte aufgrund des hohen Schutzbedarfs der Daten bezüglich Vertraulichkeit und Integrität die Maßnahme M4.238 (Einsatz eines lokalen Paketfilters) umgesetzt werden. Nähere Ausführungen finden sich in der Risikobehandlung.

G 5.21 Trojanische Pferde OK=JM2.32/Z, Einrichtung einer eingeschränkten BenutzerumgebungM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM2.273/A, Zeitnahes Einspielen sicherheitsrelevanter Patches und UpdatesM4.93/B, Regelmäßige IntegritätsprüfungM4.238/A, Einsatz eines lokalen PaketfiltersM4.239/A, Sicherer Betrieb eines ServersM6.24/A, Erstellen eines Notfall-Bootmediums

G 5.23 Computer-Viren OK=JM2.35/B, Informationsbeschaffung über Sicherheitslücken des SystemsM4.239/A, Reaktion auf Verletzungen der SicherheitsvorgabenM6.24/A, Erstellen eines Notfall-Bootmediums

G 5.48 IP-Spoofing OK=JM2.172/A, Entwicklung eines Konzeptes für die WWW-NutzungM5.64/Z, Secure Shell – nicht zutreffend für den Loghost im Recplast-Szenario

G 5.78 DNS-Spoofing OK=JM2.172/A, Entwicklung eines Konzeptes für die WWW-NutzungM2.176/B, Geeignete Auswahl eines Internet Service Providers Diese Maßnahme ist für den Loghost im Recplast-Szenario nicht zu


Logdatenstudie

treffend, da dieser nur für das Logdaten-Management verwendet wird.

M4.96/Z, Abschaltung von DNSM5.59/A, Schutz vor DNS-Spoofing



Logdatenstudie

B 5.7 Datenbanken bezogen auf den LoghostVertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 2.38 Fehlende oder unzureichende Aktivierung von Datenbank-Sicherheitsmechanismen

OK=J

M2.128/A, Zugangskontrolle für eine DatenbankM2.129/A, Zugriffskontrolle für eine DatenbankM2.130/A, Gewährleistung der DatenbankintegritätM4.7/A, Änderung voreingestellter Passwörter

G 3.24 Unbeabsichtigte Datenmanipulation OK=JM2.65/B, Kontrolle der Wirksamkeit der Benutzertrennung am IT-SystemM2.131/C, Aufteilung von Administrationstätigkeiten bei DatenbanksystemenM2.132/A, Regelung für die Einrichtung von Datenbankbenutzern/-benutzergruppenM2.134/B, Richtlinien für DatenbankanfragenM4.70/C, Durchführung einer DatenbanküberwachungM4.71/C, Restriktive Handhabung von Datenbank-Links – nicht zutreffendM4.72/Z, Datenbankverschlüsselung – widerspricht den Anforderungen an die Performanz eines Logdaten-ManagementsM6.49/A, Datensicherung einer Datenbank

G 4.30 Verlust der Datenbankintegrität/-konsistenz OK=JM2.130/A, Gewährleistung der DatenbankintegritätM2.136/C, Einhaltung von Regelungen bzgl. des Arbeitsplatzes und der ArbeitsumgebungM2.363/B, Schutz gegen SQL-InjectionM4.68/A, Sicherstellung einer konsistenten DatenbankM4.70/C, Durchführung einer DatenbanküberwachungM4.72/Z, Datenbankverschlüsselung – widerspricht den Anforderungen an die Performanz eines Logdaten-ManagementsM6.48/A, Verhaltensregeln nach einem Verlust der Datenbankintegrität

G 5.18 Systematisches Ausprobieren von Passwörter OK=JM2.316/A, Festlegen einer Sicherheitsrichtlinie für einen allgemeinen ServerM4.7/A, Durchführung einer DatenbanküberwachungM4.15/A, Gesichertes LoginM4.237/A, Sichere Grundkonfiguration eines IT-SystemsM4.239/A, Sicherer Betrieb eines Servers

G 5.131 SQL-Injection OK=J


Logdatenstudie

M2.31/A, Dokumentation der zugelassenen Benutzer und Rechteprofile M2.125/A, Installation und Konfiguration einer DatenbankM2.126/A, Erstellung eines DatenbanksicherheitskonzeptesM2.128/A, Zugangskontrolle für eine DatenbankM2.129/A, Zugriffskontrolle für eine DatenbankM2.133/A, Kontrolle der Protokolldateien eines Datenbanksystems M2.363/B, Schutz gegen SQL-InjectionM4.70/C, Durchführung einer DatenbanküberwachungM4.71/C, Restriktive Handhabung von Datenbank-Links – nicht zutreffendM4.72/Z, Datenbankverschlüsselung – widerspricht den Anforderungen an die Performanz eines Logdaten-Managements



Logdatenstudie

Logdaten-ManagementVertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 1.LM Kompromittierung der Logdaten-Kommunikation, fehlendes Out-of-band-Management

OK=N

Die bestehenden Grundschutzbausteine decken die Gefährdungen nicht vollständig ab. Es ist daher notwendig, die Maßnahmen M 2.143, M 4.204, M 4.205, M 2.110 im Kapitel „Behandlung von Risiken“ an die Rahmenbedingungen der Recplast GmbH anzupassen.

G 2.LM Falsche Platzierung des Loghosts im Netz OK=NEs gibt hier keine adäquaten Grundschutzbausteine. Diese Gefährdung wird im Kapitel „Behandlung von Risiken“ weiter ausgeführt.

G 3.LM Fehlende Authentifizierung von Log-relevanten Systemen OK=JM 4.205, Protokollierung bei Routern und Switches

G 4.LM Mangelndes Wissen und Fähigkeiten im Betrieb eines Loghosts OK=JM 3.4, Schulung vor der ProgrammnutzungM 3.11, Schulung des Wartungs- und AdministrationspersonalsM 3.33, Sicherheitsüberprüfung von Mitarbeitern

G 1.LM5 Zeitsynchronisation des Loghosts und der zu überwachenden Systeme OK=JM 4.227, Einsatz eines lokalen NTP Servers zur Zeitsynchronisation

G 1.LM6 Trennung von Überwachungs- und Kontrollaufgaben vom IT-Betrieb OK=JM 2.5, Aufgabenverteilung und FunktionstrennungM 3.3, VertretungsregelungM 2.65, Kontrolle der Wirksamkeit der Benutzertrennung am IT-SystemM 2.110,Datenschutzaspekte bei der Protokollierung

Tabelle 95: Gefährdungsbewertung der zusätzlichen Gefährdungen

7.2.4 Behandlung von Risiken

Das folgende Kapitel fasst die Gefährdungen zusammen, die nicht oder nicht ausschließlich mit den Maßnahmen aus dem Grundschutz erfüllt werden können. Hierbei handelt es sich um die Gefährdungen, die im vorhergehenden Kapitel mit OK=N gekennzeichnet wurden. Diese werden hier erneut aufgeführt. Zudem werden für diese Sicherheitsrisiken zusätzliche IT-Sicherheitsmaßnahmen erarbeitet, die den Gefährdungen hinreichend entgegenwirken. Dabei liegt der Schwerpunkt der Risikobehandlung auf der Risikoreduktion durch weitere Sicherheitsmaßnahmen. Als Informationsquellen für die zusätzlichen IT-Sicherheitsmaßnahmen wurden folgende Informationen herangezogen:

– Protokolle und Formate (siehe Arbeitspaket I)


Logdatenstudie

– Standards, Standardisierungsbestrebungen (siehe Arbeitspaket II)

– Durch die Hersteller beantwortete Fragenkataloge, Teststellungen, Dokumentationen von Logfile-Lösungen (siehe Arbeitspaket III)

– Best Practices – Erfahrungen aus vorangegangen Projekten und Teststellungen

– Publikationen und Veröffentlichungen in Fachgremien und Fachzeitungen

– Erfahrungen, die innerhalb der eigenen Institution und durch Kooperationspartner gewonnen wurden.

Anhand des Recplast-Szenarios gehen wir im Folgenden auf die zusätzlich möglichen Grundschutzmaßnahmen ein, die als Variante A genutzt werden können. Unter der Bezeichnung Variante B werden zusätzliche Beschreibungen für das Logdaten-Management konkreter ausgeführt.


Logdatenstudie

Logdaten-ManagementVertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 1.LM Kompromittierung der Logdaten-Kommunikation, fehlendes Out-of-band-ManagementZusätzliche IT-Sicherheitsmaßnahmen:Variante A:Die nachfolgend aufgeführten Grundschutzmaßnahmen können zur Abschwächung der Gefahren in der Logdaten-Kommunikation genutzt werden. Da sich diese Maßnahmen meist im Kern nicht direkt auf Logfile-Lösungen beziehen, treffen sie nicht vollständig darauf zu und werden in der Variante B weiter konkretisiert.

M 2.143 Entwicklung eines Netzwerk-Management-Konzeptes:In erster Linie wird ein zentrales Netzmanagement verwendet, um die Verfügbarkeit und Integrität des Netzes sowie die Integrität und Vertraulichkeit der übermittelten Daten zu gewährleisten.

M 4.204 Sichere Administration von Routern und Switches:Um den Risiken bei der Remote-Administration entgegenzuwirken, bieten einige Geräte die Möglichkeit, einen eigenen logischen Port (Management-Interface) zur Administration zu konfigurieren. Bei Switches sollte dieser Port einem VLAN zugeordnet werden, welches ausschließlich für administrative Zwecke verwendet wird (Out-of-Band-Management) und dem ausschließlich Management-Interfaces angehören. Das Management-Netz sollte vollständig von anderen Teilen des Netzes getrennt werden. Dadurch werden Schwachstellen wie unverschlüsselt übertragene Anmeldeinformationen bei den für administrative Aufgaben zur Anwendung kommenden Protokollen wie TELNET oder veraltete SNMP-Varianten kompensiert.

M 4.205 Protokollierung bei Routern und Switches:Router und Switches bieten in der Regel Möglichkeiten eines eigenen Loggings. Die Auswertung dieser Informationen ermöglicht die Beurteilung der korrekten Funktion des Geräts und das Erkennen von Angriffsversuchen. Mithilfe der Informationen der Protokolle kann oft auch die Art eines Angriffsversuches nachvollzogen und die Konfiguration entsprechend angepasst werden. Daher sollte die Protokollierung immer genutzt und sorgfältig eingerichtet werden. Die sorgfältige Konfiguration ist dabei besonders wichtig, da nur bei einer sinnvollen Filterung aus der Vielzahl von Informationen die relevanten Daten extrahiert werden können. Hierzu gehören vor allem das Erkennen abgewiesener Zugriffsversuche und Änderungen der Konfiguration.Da Logdaten in den vielen Fällen personenbezogene Daten enthalten, ist sicherzustellen, dass diese Daten nur zum Zweck der Datenschutzkontrolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemäßen Betriebes verwendet werden (M 2.110 Datenschutzaspekte bei der Protokollierung).Die Protokollierungsinformationen können über das Netz auf einen eigenen Sys


Logdatenstudie

log-Server (beispielsweise auf einem Unix-Rechner) übertragen werden. Diese Maßnahme dient der zentralen Sammlung und Archivierung der Protokollierungsinformationen, da auf den Netzkomponenten oft keine ausreichenden Betriebsmittel dafür vorhanden sind. Dadurch können an einer zentralen Stelle relevante Informationen erfasst und ausgewertet werden. Außerdem bietet sie den Vorteil, dass bei einer Kompromittierung eines Gerätes die bereits übertragenen Protokollierungsinformationen vom Angreifer nicht verändert oder gelöscht werden können.

M 2.110 Datenschutzaspekte bei der ProtokollierungUnter einer Protokollierung beim Betrieb von IT-Systemen ist im Datenschutzrechtlichen Sinne die Erstellung von manuellen oder automatisierten Aufzeichnungen zu verstehen, aus denen sich die folgende Frage beantworten lässt: "Wer hat wann mit welchen Mitteln was veranlasst bzw. worauf zugegriffen?" Außerdem müssen sich Systemzustände ableiten lassen: "Wer besaß von wann bis wann welche Zugriffsrechte?"Art und Umfang von Protokollierungen hängen vom allgemeinen Datenschutzrecht und auch von bereichsspezifischen Regelungen ab.Die Protokollierung der Administrationsaktivitäten entspricht einer Systemüberwachung, während die Protokollierung der Benutzeraktivitäten im Wesentlichen der Verfahrensüberwachung dient. Dementsprechend finden sich die Anforderungen an die Art und den Umfang der systemorientierten Protokollierung überwiegend im allgemeinen Datenschutzrecht, während die verfahrensorientierte Protokollierung oft durch bereichsspezifische Regelungen definiert wird. Beispiele für eine verfahrensorientierte Protokollierung sind u. a. Melde-, Polizei- und Verfassungsschutzgesetze.

Variante B konkretisiert für den Loghost:Die hier aufgeführten Anpassungen der Maßnahmen beziehen sich auf den Loghost.

M 2.143 Entwicklung eines Netzwerk-Management-Konzeptes:Ein zentrales Management speziell für eine Logdaten-Lösung ist unabhängig von einem Netzwerk-Management-Konzept zu erstellen. Wesentlicher Bestandteil eines solchen Konzeptes ist es, nicht kompromittiert zu werden, um somit die Vertraulichkeit und Integrität der Logdaten-Auswertung zu gewährleisten.

M 4.204 Sichere Administration von Routern und Switches:Die sichere Kommunikation zum Loghost hin entscheidet im Wesentlichen über die Vertraulichkeit und Integrität der Logdaten. Die Herausforderung besteht somit darin, innerhalb des verfügbaren Netzwerks Mechanismen für die Netz-Trennung zu nutzen. Dabei sollte sowohl auf eine physikalische als auch auf eine logische Trennung geachtet werden. Folgende Maßnahmen können beispielsweise zum Einsatz kommen:

● Agenten, wenn die Möglichkeit besteht● Layer 2-Trennung● Layer 3-Trennung● Über eine separate VPN-Verbindung für entfernte Einheiten


Logdatenstudie

● Out-of-Band-Management in einem physikalisch getrennten Teilnetz

M 4.205 Protokollierung bei Routern und Switches:Router und Switches bieten in der Regel Möglichkeiten zur Protokollierung. Indem man diese Informationen auswertet, kann man die korrekte Funktion des Geräts beurteilen und Angriffsversuche erkennen. Da das Logging sowohl in der Verarbeitung der Puffer der Router und Switches als auch auf den Interfaces ein untergeordneter Prozess ist, sollte hier eine Konfigurationsoptimierung der Geräte durchgeführt werden. Ferner ist es auf diesen Netzwerkkomponenten meist nicht möglich, eine sinnvolle Trennung auf logischer Ebene durchzuführen. Aufgrund dieser seitens des Systems vorgegebenen Limitationen empfiehlt es sich, separate Interfaces für gesicherte Management-LANs zu nutzen, um unsichere Syslog-Daten vor einer Manipulation zu sichern.

M 2.110 Datenschutzaspekte bei der ProtokollierungEs kann an dieser Stelle keine Rechtsberatung zu IT-Compliance Anforderungen stattfinden. Solche wären von Fachanwälten, DSB etc. zu erstellen bzw. auf ihre Richtigkeit zu prüfen.

G 2.LM Falsche Platzierung des Loghosts im NetzZusätzliche IT- Sicherheitsmaßnahmen:

Variante A (Recplast-Szenario):Die Platzierung des Loghosts ist im Recplast-Szenario nur analog zu den anderen Servern umsetzbar, da von Haus aus keine Netz-Segmentierung vorliegt. Durch eine solche Platzierung bringt der Loghost jedoch zumindest keine Risiko-Vergrößerung mit sich. Die korrekte Platzierung im Netz ist durch Tests abzusichern, um auszuschließen, dass eine fehlerhafte Verkabelung vorliegt. Der Loghost benötigt im Recplast-Szenario nur einen Netzwerk-Anschluss, weitere Anschlüsse zur Überbrückung ins öffentliche Internet sind unter allen Umständen zu vermeiden.

Variante B:Die Platzierung des Loghosts innerhalb eines Sicherheits-Gateways sieht nach BSI-Konzeption die Unterbringung in einem separaten Segment, beispielsweise dem Administrationsnetzwerk, vor. Der Loghost selbst wird somit durch Paketfilter geschützt. Die Kommunikation der Log-Quellen zum Loghost ist in diesem Szenario durch Paketfilter und Proxies abgesichert und die Angriffsmöglichkeiten reduzieren sich weiter. Keinesfalls sollte der Loghost mit mehreren Netzwerk-Schnittstellen in unterschiedlichen Segmenten verbunden sein, da hierdurch die Gefahr einer sukzessiven Kompromittierung durch den erfolgreich angegriffenen Loghost selbst besteht.

Tabelle 96: Behandlung von Risiken bei den zusätzlichen Gefährdungen


Logdatenstudie

G 5.20 Missbrauch von Administrator-RechtenZusätzliche IT-Sicherheitsmaßnahmen:

Variante A:M4.238 Einsatz eines lokalen PaketfiltersEin lokaler Paketfilter kann den Loghost gegen Angriffe schützen, die aus demselben Subnetz heraus gestartet werden. Außerdem kann ein solcher Paketfilter dazu benutzt werden, eine feiner abgestufte Zugriffskontrolle für einzelne Dienste zu realisieren, als dies beispielsweise mit Paketfiltern, die nur an Netzübergängen platziert werden, möglich ist.

Variante B konkretisiert auf den Loghost:Die Installation einer Host-Firewall auf dem Loghost in Verbindung mit einem Intrusion Prevention Modul sichert den Loghost vor Angriffsversuchen aus dem lokalen Netzwerk ab und ermöglicht die frühzeitige Entdeckung solcher Angriffe. Die Intrusion Prevention Komponente ist vor allem deshalb wichtig, um sicherzustellen, dass durchgeführte Angriffe unter Ausnutzung von Softwarefehlern abgewehrt werden. Solche Angriffe sind auf den vom Loghost angebotenen Diensten, z.B. dem syslog-Daemon, zu erwarten.

Tabelle 97: Behandlung von Risiken bei bereits vorhandenen Gefährdungen

7.3 Risikoanalyse zum P-A-P-Sicherheits-Gateway

7.3.1 Die Gefährdungsübersicht

Als Ausgangspunkt für die Risikoanalyse dienen die zuvor im Recplast-Szenario getroffenen Angaben , die hier um den Baustein Server unter Unix/Linux erweitert werden. Dabei werden ebenfalls die Gefährdungen aus den IT-Grundschutz-Katalogen herangezogen. Im Folgenden wird ferner ausschließlich auf den Loghost eingegangen, der restliche IT-Verbund wird in der Risikoanalyse nicht berücksichtigt. Nachfolgend werden aus den relevanten Grundschutzbausteinen die Gefährdungen ausgewählt, welche aufgrund des hohen Schutzbedarfs der Daten bezüglich Vertraulichkeit und Integrität einer ergänzenden Risikoanalyse zugeführt werden müssen (siehe rote Markierung). Der Grundwert Verfügbarkeit wird für nachfolgende Bausteine als normal angenommen. Gefährdungen, die über die Standardmaßnahmen „normal“ ausreichend abgesichert sind (siehe schwarze Markierung), werden nicht weiter betrachtet.


Logdatenstudie

B 3.102 Server unter Unix/Linux bezogen auf den Loghost im Szenario des P-A-P-Sicherheits-Gateways

Vertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 2.15G 2.23G 2.65

G 3.10G 3.11

G 4.11G 4.12

G 5.41G 5.89

Vertraulichkeitsverlust schutzbedürftiger Daten im Unix-SystemSchwachstellen bei der Einbindung von DOS-PCs in ein servergestütztes NetzKomplexität der SAMBA-Konfiguration

Falsches Exportieren von Dateisystemen unter LinuxFehlerhafte Konfiguration von Sendmail

Fehlende Authentisierungsmöglichkeit zwischen NIS-Server und NIS-ClientFehlende Authentisierungsmöglichkeit zwischen X-Server und X-Client

Missbräuchliche Nutzung eines Unix-Systems mithilfe von uucpHijacking von Netzverbindungen

Tabelle 98: Gefährdungsübersicht: B 3.102

7.3.2 Ermittlung zusätzlicher Gefährdungen

Zusätzlich zu den Gefährdungen aus den Grundschutzkatalogen und den aus dem Recplast-Szenario wurden für das P-A-P-Sicherheits-Gateway keine weiteren Gefährdungen festgestellt.

7.3.3 Gefährdungsbewertung

In der nachfolgenden Gefährdungsbewertung wurde nur der vom Recplast-Szenario abweichende Server- bzw. Unix-/Linux-Baustein und dessen IT-Sicherheitsmaßnahmen im Hinblick auf ihren ausreichenden Schutz überprüft. Es handelt sich dabei um Standard-Sicherheitsmaßnahmen aus den IT-Grundschutz-Katalogen. Bei der Prüfung werden in diesem Abschnitt folgender Kriterien berücksichtigt:

– Sind die vorgeschlagenen Standard-Sicherheitsmaßnahmen vollständig, um auch vor Gefährdungen mit der Schadensauswirkungen „hoch“ angemessenen Schutz zu bieten?

– Sind die Mechanismen der Standard-Sicherheitsmaßnahmen ausreichend stark, um auch die Anforderung für „hohe“ Schadensauswirkungen zu gewährleisten?

– Sind die vorgesehen Sicherheitsmechanismen zuverlässig genug, damit sie nicht umgangen werden können?

Die Ergebnisse werden in den nachfolgenden Tabellen bewertet. Zielobjekte, die durch die Maßnahmen der IT-Grundschutz-Kataloge ausreichend geschützt sind, werden mit OK=J gekennzeichnet. In den Fällen, in denen diese Maßnahmen nicht ausreichen und ein Restrisiko besteht, wird der Vermerk OK=N angegeben. Die Behandlung dieser Risiken ist Gegenstand des nächsten Abschnitts.


Logdatenstudie

B 3.102 Server unter Unix/Linux bezogen auf den Loghost im Szenario des P-A-P-Sicherheits-Gateways

Vertraulichkeit:Integrität:Verfügbarkeit:

hochhochnormal

G 3.11 Vertraulichkeitsverlust schutzbedürftiger Daten im Unix-System OK=JM 4.21/A, Verhinderung des unautorisierten Erlangens von AdministratorrechtenM 4.26/B, Regelmäßiger Sicherheitscheck des Unix-SystemsM 5.19/A, Einsatz der Sicherheitsmechanismen von Sendmail – nicht zutreffend

G 5.89 Hijacking von Netzverbindungen OK=JM 4.9/A, Einsatz der Sicherheitsmechanismen von X-Windows – nicht zutreffendM 5.36/Z, Verschlüsselung unter Unix und Windows NTM 5.64/Z, Secure ShellM 5.83/Z, Sichere Anbindung eines externen Netzes mit Linux FreeS/WAN – nicht zutreffend


7.3.4 Behandlung von Risiken

Das P-A-P-Sicherheits-Gateway baut wie vorangehend beschrieben auf dem Recplast-Szenario auf. Somit gelten die bei der vorangehenden Beschreibung angegebenen Empfehlungen auch für dieses Kapitel. Zusätzlich wurden aber die adäquaten Sicherheitsmaßnahmen für Server unter Unix/Linux aus dem IT-Grundschutz berücksichtigt. Weitergehende Maßnahmen konnten im Hinblick auf das P-A-P-Sicherheits-Gateway nicht erkannt werden.

7.4 Zusammenfassung

Mithilfe eines Logdaten-Managements sollen Logdaten hinsichtlich bestimmter Kriterien ausgewertet werden. Da der Betrieb einer Logdaten-Lösung mit besonderen Sicherheitsrisiken verbunden ist, wurden in diesem Arbeitspaket verschiedene Maßnahmen beschrieben, die bei der Einrichtung eines Logdaten-Managements berücksichtigt werden sollten. Einem Großteil der Gefährdungen kann durch Gegenmaßnahmen begegnet werden, weil der Loghost auf bekannten IT-Grundschutzbausteinen aufbaut.

Bevor eine Lösung zum Logdaten-Management eingeführt wird sollten die bestehenden Sicherheitsrisiken bekannt sein und die vorbeugenden Maßnahmen des IT-Grundschutzes gesetzt werden. Beim Aufbau der Lösung sollte das Logdaten-Management vom IT-Netz getrennt werden. Je nachdem, welches Budget für das Projekt zur Verfügung steht, kann zuerst eine Layer 2-Trennung durchgeführt werden. Anschließend man diese gegebenenfalls für abgesetzte Außenstellen über getrennte Routing-Instanzen fortgeführt werden.


Logdatenstudie

Bei mittelständischen Unternehmen wie der Recplast GmbH ist ein abgestuftes Konzept aus finanziellen und personellen Gründen am besten für die Logdaten-Lösung geeignet. Hierbei sollte auf vorhandene Bordmittel der eingesetzten Betriebssysteme zurückgegriffen werden (1. Stufe der Logdaten-Pyramide, vgl. Abbildung 7.1), damit keine Mehrkosten durch zusätzlich zu beschaffende Hard- und Software entstehen.

Anschließend kann eine Logdaten-Zentralisierung (2. Stufe) eingeführt werden. Für Mittelständler wird danach oft nur die Ausbaustufe „nachgelagerte Auswertung“ (3. Stufe) in Betracht kommen.

Hier setzt dann auch die komplexere P-A-P-Gateway-Lösung an, die in diesem Arbeitspaket als sicherheitstechnisch hochwertige Lösung beschrieben wurde. Diese kann die nächste Ausbaustufe der Echtzeit-Auswertung nutzen, welche unter optimalen Bedingungen als Basis für ein Frühwarnsystem eingesetzt werden kann.

Zu wichtigen weiteren Beweggründen für die Einführung eines Logdaten-Managements leitet folgende Fragestellung, zu welchen weiteren Zwecken außer der Frühwarnung man ein Logdaten-Management benötigt.

– Auditierung und Überwachung:

Bei der Verwendung für Auditierungen und Überwachung werden Logdaten und ihre Auswertung benutzt, um eine unabhängige Sicht auf die IT-gestützten operativen Prozesse zu erhalten. Aus diesem Grund sollten diese Systeme getrennt vom üblichen IT-Betrieb und den damit betrauten Führungskräften betrieben werden. Dieses wird aber erst ab einer gewissen Organisationsgröße möglich sein, da erst hier eine Funktionstrennung zum Kernbestandteil der Überwachung wird.

– Betriebsunterstützung:

Werden Logdaten zur Betriebsunterstützung verwendet, fließen diese in die Betriebsoptimierung und die Früherkennung von sicherheitsrelevanten Vorfällen mit ein. Der Schwerpunkt liegt hier allerdings mehr auf der Echtzeitauswertung der Daten, die es erlaubt, sehr zeitnah auf Anomalien und Sicherheitsverstöße reagieren zu können. Sowohl der technische Aufwand als auch der Betrieb solcher Lösungen ist zeit- und kostenintensiv. Eine erschwinglichere Variante stellt die nachgelagerte Logdaten-Auswertung dar, welche auch in abgewandelter Form als Compliance-Nachweis genutzt werden kann.

– Compliance-Nachweis:

Die nachgelagerte Logdaten-Auswertung stellt für das Führen des Compliance-Nachweises eine spezielle Form dar: Es muss neben der täglichen Betriebsunterstützung vor allem die Beweislastkette lückenlos sein. Für den Fall der Logdaten-Zentralisierung stellt sich damit die Frage nach dem Verbleib der Original-Logdaten, wenn ein zentraler Loghost genutzt worden ist. Darüber hinaus muss dieses System über die Möglichkeit verfügen, die Logdaten unverändert ablegen zu können.


Logdatenstudie

8 Anhang

8.1 Abbildungsverzeichnis

Abbildungsverzeichnis: BSI-Logo zur Internet-Sicherheit.......................................................................................................2: Logo des BSI......................................................................................................................................2: Logo der Computacenter....................................................................................................................2

8.2 Tabellenverzeichnis

TabellenverzeichnisKritikalitätstufen von Syslog..............................................................................................................12Herkunft von Syslog-Meldungen.......................................................................................................13Quellen von Syslog-ng-Meldungen....................................................................................................14Ziele von Syslog-ng-Meldungen........................................................................................................15Filter in Syslog-ng..............................................................................................................................15Opitionen in Syslog-ng.......................................................................................................................16Übersicht SNMP-Versionen...............................................................................................................19Netflow Paketheader..........................................................................................................................20Übersicht über Protokolle und deren Funktionen ..............................................................................27Felder einer Meldung im Windows Eventlog bis Server 2003..........................................................32Speicherorte für Meldungen inUnix/Linux-Derivaten.......................................................................34Felder im Message-Header von IPFIX...............................................................................................35Felder im Record-Set von IPFIX........................................................................................................36Felder im Header eines Record-Sets von IPFIX................................................................................36Felder im Header eines Template-Records von IPFIX .....................................................................36Felder im Header eines Options Template Records in IPFIX............................................................37Felder im Header von Netflow ..........................................................................................................38Felder eines Netflow-Records............................................................................................................38Quellangaben in einer Cisco IOS-Meldung.......................................................................................39Kritikalitätsstufen in einer Cisco-IOS-Meldung................................................................................39Felder einer Checkpoint VPN-1-Meldung.........................................................................................41Kritikalitätsstufen einer Cisco Pix-Meldung......................................................................................42Felder einer NSM-Meldung...............................................................................................................45Felder einer Cisco IPS-Meldung........................................................................................................46Felder einer Abfrage von SMS-Meldungen über Web-API...............................................................49Felder einer Tipping Point Meldungstabelle......................................................................................49Felder einer SMS-Meldung über Syslog............................................................................................50Felder einer IIS-Meldung...................................................................................................................51Variablen im Apache Common Log Format......................................................................................52


Logdatenstudie

Variablen im Pattern Layout von Tomcat..........................................................................................53Felder des erweiterten W3C-Formats in ISA-Server.........................................................................56Felder im Squid Native Log Format...................................................................................................58Felder einer NetCache-Meldung........................................................................................................62Logformate in BlueCoat.....................................................................................................................63Logdateien in Webwasher..................................................................................................................65Felder des Message Tracking Format in Exchange Server................................................................67Schlüsselwörter im Sendmail-Format................................................................................................68Schlüsselwörter im EXIM-Format.....................................................................................................70Module im Postfix-Format.................................................................................................................70Schlüsselwörter im Postfix-Format....................................................................................................71Kategorien in ISC Bind......................................................................................................................75Parameter für die Steuerung von Logs in SAMBA............................................................................76Meldungsarten in Asterisk-Format.....................................................................................................78Logdateien in McAfee Virusscan.......................................................................................................80Felder einer Symantec Antivirus-Meldung .......................................................................................83Übersicht beschriebener Formate.......................................................................................................90Übersicht über Drafts/RFCs der Arbeitsgruppe Syslog.....................................................................92Übersicht über Drafts/RFCs der Arbeitsgruppe IPFIX......................................................................97Übersicht über Drafts/RFCs der Arbeitsgruppe RMONMIB...........................................................101

8.3 Stichwort- und Abkürzungsverzeichnis


Studie ¼ber die Nutzung von Log - Institut f¼r Internet-Sicherheit

Documents

Transcript of Studie ¼ber die Nutzung von Log - Institut f¼r Internet-Sicherheit