Security Logs, Teil 1: Erfahrungen im Management

Security Logs, Teil 1

Erfahrungen im Management

Rocco Gagliardi
von Rocco Gagliardi
Lesezeit: 13 Minuten

Dieses Kapitel ist das erste eines Zwei-Parters. In diesem ersten Part werden wir uns ansehen, wie Log Management angegangen werden kann und teilen unsere Erfahrung damit. Im zweiten Kapitel werden wir die Anforderungen und Kosten der Stages beleuchten wie auch eine Übersicht der Tools bereitstellen.

Hören Sie den Devices zu

Während unseren Audits bekommen Mitarbeiter der scip AG oft diese Frage gestellt: Logging? Dabei möchten wir die Fähigkeit erhalten, die Daten, die ein Computer verschickt, zu analysieren genau wie auch die kontinuierlich gesammelte Information über den Status des Geräts. Sogar sorgfältige Firmen mit hohen Sicherheitsstandards beissen da auf Granit. Wir sehen oft eine Serie von Fehlern:

Diese Probleme sind nicht trivial. Sehr gute Tools versuchen, eine breite Palette an Nachrichten, die in hoher Geschwindigkeit aus einer Vielzahl Quellen über den Server jagen, aufzunehmen. Diese Nachrichten enthalten sowohl Datenmüll wie auch wichtige Information.

SIEM-Lösungen sind im Moment der State of the Art in Punkto Log-Collection und –Analysis. Die Spitzenprodukte, die auch entsprechend teuer sind, dieser Sparte sind Q1 Labs und HP ArcSight. Aber es existieren auch nützliche Open Source Tools, die eine solide Basis bilden.

“Kaufen Sie sich einen Server, schalten Sie ihn ein, und lassen Sie ihn ein paar Tage lang machen.” Dies wird oft schon als Lösung verkauft, aber so funktioniert Logging nicht. Log Management und Security Log Management im Besodnered, ist ein komplexes Unterfangen das mehrere Komponenten involviert die sowohl technischer wie auch menschlicher Natur sind und benötigt eine qualitativ sehr hohe Konzeptionierung.

Unsere Erfahrung

In den Jahren zwischen 2003 und 2008 hat scip AG SE.LO.R.SY – unser Security Log Reporting System – entwickelt und angewendet. Es handelt sich dabei um eine angepasste Security Log Management Solution. Wir haben SE.LO.R.SY entwickelt, da Kunden nach einer Lösung verlangt haben, die Daten korrellieren, die helfen sollen, Angriffe in einer heterogenen Umgebung mittels komplexen Kommunikationskanälen zu identfizieren. Unser Ziel war es, eine flexible, dedizierte, hochsichere Lösung für Early Adapters zu entwickeln, die sehr spezifische Bedürfnisse abdeckt. Wir haben diese Lösung (Software, Datenbanklogik und was alles dazugehört) ohne zusätzliche Kosten zur Verfügung gestellt. Unsere Kunden haben uns für die Konzeption und die Logik hinter den Logs bezahlt. Für das wo, das wieso und das wie der Reports und der Präsentationen für mehrere interne Abteilungen (Rechtsabteilung, Compliance, Audit, IT, Security) und für Personen von Technikern bis hin zu Risk Officers. Aber um diese Funktionalität zu wahren, auch bei einer kleinen Anzahl Logs, muss eine robuste und verlässliche Infrastruktur bestehen. Diese beinhaltet

Diese Funktionen müssen zusammen arbeiten und dabei noch gute Performance liefern. Wenn eine dieser Schlüsselfunktionen fehlt, könnte die gesamte Lösung unbrauchbar werden.Wir haben SE.LO.R.SY mit dem Fokus auf Reporting designt, damit wir nicht nur Resultate im Offlinemodus erhalten sondern auch – wenn wir wollen – in Echtzeit alarmiert werden (~min Intervall).

Komponente Nutzung Beschreibung
syslog-ng transport Intern intiierte ssh-Tunnel, die Syslog-Daten von externen Geräten auf dem DMZ-Server sammeln
perl/dbi parsing engine Parst und normalisiert. Transactional Insert Relational Records in drei verschiedene Tier-1 (optional auch Tier-2) mysql Datenbanken)
php reporting engine Reporting und Präsentation. Engine-basiert und proprietäres Präsentations-Framework

Auf einem einzigen Low-End-Server (i686, 4GB, RAID-5) konnte SE.LO.R.SY etwa 1000 Logs pro Sekunde parsen, normalisieren (indem es zwischen 10 und 15 Informationen aus der Logline entnommen hat) und speichern, ohne dass eine in-memory summarization vorgenommen werden musste. Gleichzeitig hat SE.LO.R.SY. tägliche Reports basierend auf Tabellen und Grafiken (Filtrierung und Zählung auf Basis von zwei Millionnen Logs pro Tag) erstellt. Die Erstellung nahm etwa 10 Minuten pro Report in Anspruch. Die Interaktivität wurde vom Kunden erhöht: Die Performance wurde verbessert indem strategische Indexes gesetzt wurden. Die Herausforderung dabei war es, Performance (insert/query) mit dem Platz für optimale Benutzbarkeit zu balancieren.

Wir haben Parser für Checkpoint Firewall, Sonic Wall, Windows Servers, Citrix, Unix Log und Audit, RACF und andere entwickelt. Schliesslich hatten wir Lösungen um Administratoren, AD Changes und Data Calls auf Windows Plattformen zu auditieren, um zu eskalieren sollte die Log-inChain nach dem initialen Log-in im Portal-Web korrupt sein, um Citrix-Accounts und Core Banking Applications zu überwachen, RACF-Logins mit Unix-Logins und dem Papier Workflow der gegebenen Rechte und vielen mehr zu korrelieren und noch viel mehr. Zudem war es auf einmal möglich, individuell angepasste Security Reports für verschiedene User zu erstellen, von Operators bis hin zu managern. SE.LO.R.SY zu entwickeln, aufzubauen, zu implementieren und auf die Kundenbedürfnisse anzupassen war keine einfache Aufgabe und hat uns – aus einer Insiderperspektive – viel über Log-Management gelehrt.

Begriffe

Was ist ein Log?

Ein Log ist eine Aufnahme von einem Ereignis, das in einer Organisation vorkommt. Logs sind aus Log-Einträgen aufgebaut. Jeder Eintrag beinhaltet Informationen, die mit einem spezifischen Ereignis, das passiert ist, zusammenhängen. Viele Logs innerhalb einer Organisation enthalten Aufzeichnungen, die mit Computer-Sicherheit zu tun haben (generiert von Firewalls, Authentication Software, Anti-Virus-Software und so weiter).

Logging und Auditing haben einen unterschiedlichen Zugang zur Datensammlung:

SIM (Security Information Management) ist eine Sammlung von Events, die von Applikationen und Operational Systems ausgehen, die im Normalfall für folgendes Verantwortlich sind:

SEM (Security Events Management) ist eine Sammlung von Events, die aus Sicherheitsgründen zusammenhängen und verantwortlich sind für:

SIEM: Security Information and Event Management.

Logging und Auditing: Gründe, Vorteile und Probleme

Erfolgreiche Angriffe auf ein System hinterlassen nicht zwingend eindeutige Hinweise auf das, was passiert ist. Es ist notwendig im Vorfeld eine Konfiguration vorzunehmen, die Beweise sammelt um sowohl festzustellen, ob etwas ausserhalb der normalen Parameter vorgefallen ist und um entsprechend reagieren zu können. Log Consolidation ist fundamental wichtig um APTs festzustellen. Standards benötigen das Logging von User, Applikation und Netzwerkaktivität.

Dennoch tendieren sie dazu, sehr vage zu sein, wenn es darum geht, festzustellen, wie diese Information verarbeitet wird. Sie können im Normalfall davonkommen, indem Sie eine Black Box ins System einbauen, was superschöne und farbige Management Reports generiert, die sogar als compliant bezeichnet werden können. Die Reports können allerdings wenig hilfreich sein, wenn es darum geht, das eine System mit Backdoor zu finden, das nach ause telefoniert. Aber wenigstens ist der Standard erreicht.

Eine gut konfigurierte Logging und Audit-Infrastruktur wird Hinweise auf Fehlkonfigurationen geben, die ein System verwundbar machen. Die Infrastruktur dient somit als Präventionsmassnahme. Regelmässige Log-Analyse ist gut, um Security Incidents, Verstösse gegen die Policy, betrügerische Aktivität und operative Probleme festzustellen. Zudem sind Logs bei der Durchführung von Audits und forensischen Analysen, bei der Unterstützung von internen Untersuchungen, der Etablierung von Baselines und der Identifikation von operativen Trends sowie langfristigen Problemen nützlich.

Auditing hat den Vorteil, vollständiger zu sein. Der Nachteil beim Reporting von grossen Datenmengen liegt darin, dass ein Grossteil der Information uninteresant ist. Logging hat den Vorteil, mit einer vielzahl von Client Applications kompatibel zu sein und nur als wichtig bezeichnete Informationen zu reporten. Der Nachteil aber ist, dass der Information Report nich konsistent zwischen einzlnen Applikationen ist. Syslog ist standardmässig auf vielen System installiert, nur weil das MSG-Feld ein Freeform-Textfeld ist. Daher kann es mit beliebigem Text gefüttert werden. Derzeit werden mehr als 750 Logfile-Formate genutzt.

Unser Zugang zum Log Management

Die Herangehensweise definieren

Die Herangehensweise an den Aufbau der Infrastruktur ist das Fundament einer jeden Security Measure. Doch diese untersteht einigen Fragen: Wollen Sie die Sicherheit verbessern oder müssen Sie sich an eine Security Compliance Spezifikation halten? Sobald das primäre Ziel Compliance, Monitoring, Alerting oder eine Kombination dieser Punkte ist, dann geht das ganze Projekt in eine ganz andere Richtung.

Es ist wichtig, den Output des Systems zu definieren. Dies kann nach Ihren Präferenzen geschehen: Bevorzugen Sie die Angabe des Namens, von Sections, von Records, von Filtern? Wie sollen die Reports sortiert und gruppiert sein? Wie werden sie gezählt? Wer soll sie lesen?

Prozesse und Rollen identifizieren

Die Infrastruktur muss unterschiedlich Reports für mehrere Interessengruppen, jede mit ihren eigenen Bedürfnissen, produzieren. Zudem muss sie gewartet, kontrolliert und auditiert werden. Bestimmen Sie Teams, die gewisse Aufgaben der Wartung und Kontrolle mit Blick auf die Vertraulichkeit der Daten übernehmen. Im Normalfall haben die Wartungsteams keine Lese/Schreibberechtigung für die Daten. Definieren Sie die Zielgruppen: Security, Administratoren, Manager, Architekten … jede dieser Gruppen muss die selben Daten aus einem komplett anderen Blickwinkel betrachten. Definieren Sie das Management-Team sowie das Berechtigungs-Modell, das zu implementieren ist. Definieren Sie das Audit-Team und stellen Sie sicher, dass das Team regelmässig die Schlüsselemente des Systems begutachtet, von Generierung über die Transmission bis hin zum Speicher.

Planen Sie Ressourcen

Stellen Sie sicher, dass sie das Projekt nicht zu klein planen. Planen Sie genug Zeit für das Personal ein, damit die Teams und deren Mitglieder die Infrastruktur kennenlernen und Probleme identifizieren können. Lassen sie die Teams die Probleme lösen bis das System stabil läuft. Eine typische Vorgehensweise wäre die Analyse einer grossen Menge Logs, die meisten davon nutzlos, dann die reporteten Probleme aufzulisten, diese dann basierend auf der benötigten Anzahl Logs, die gleichzeitig eliminiert werden können, zu priorisieren, dann das Problem zu beheben. Und dann: Diesen Modus Operandi wiederholen bis der Log-Entry elminiert ist oder die Anzahl der überflüssigen Log-Einträge akzeptabel wird.

Dies benötigt Zeit und könnte unerwünschte Nebenwirkungen auf mehrere firmeneigene Ressourcen haben. Zum Beispiel: Ein Firewall Log, das mit Drops aus einer Fehlkonfiguration gefüllt ist führt dazu, dass die Reparatur der Applikation andere Abteilungen involviert und kann daher lange dauern, bis die Lösung konzipiert, getestet, verifiziert, implementiert und im produktiven System eingesetzt ist.

Definieren Sie die Anforderungen

Definieren Sie die Anforderungen an die Lösung und die Methoden, die sie benutzen soll. Benutzen Sie diese Definitionen um sicherzustellen, dass die Log-Quellen diese gewünschten Informationen reporten.

Deklarieren Sie nicht nur Erfüllen der Anforderungen PCI-DSS sondern werden Sie detailliert. Spezifizieren Sie, welcher Part der Regulation erfüllt werden soll, welche Informationen aus welcher Quelle benötigt werden, was geprüft und gezählt werden soll, was der Normalfall ist, was eine Warnung produziert, was eine Fehlermeldung auslöst, die Frequenz der Report-Generierung, wer die Reports erhält, was überprüft werden muss, wie und wie lange die Reports gespeichert werden sollen, was im Falle einer Warnung oder einer Fehlermeldung zu tun ist.

Hier ein Beispiel einer solchen Definition:

Schreiben sie einen Request For Proposal

Wenn Sie etwas von einem Hersteller oder Händler kaufen oder ein Projekt intern mit Open-Source-Tools starten wollen, dann sollten Sie alle Anforderungen in einem Request for Proposal (RFP) festhalten. Dieser sollte klare, kurze und präzise Fragen enthalten. Denn die Antworten ihres Befragten werden auch so teilweise nebulös bleiben.

Beschreiben sie die Funktionalität, benutzen Sie Fallstudien, welche Daten geparts werden müssen, welche Daten geparst werden sollten, wie viele Events per Second (EPS) vom Reporting erwartet werden. Vergleichen Sie ihre Anforderungen mit Open-Source-Lösungen, aber betrachten Sie auch mögliche Kosten.

Zusammenfassung

In den Jahren der Entwicklung und der dabei gesammelten Erfahrung im Log Management haben wir gelernt, dass SE.LO.R.SY die wohl effektivste Security Solution ist. Wenn Sie sich wirklich um die Logs bemühen, dann wird SE.LO.R.SY tieferen Einblick ins Innenleben Ihres Netzwerks als jedes andere Tool. Ein Logging-System kann Ressourcen verschlingen, aber es kann auch von sehr hohem Nutzen sein.

Eine einheitliche Sprache in Sachen Logging fehlt und macht es schwierig, die grosse Menge an Information zu managen. Also erwarten Sie nicht, dass ein bestimmtes Tool all Ihre Probleme löst. Es ist wichtig, mit einem sehr guten Konzept zu starten. Das ist unbestreitbar der allererste Schritt. Damit dieser getan werden kann, ist es von grosser Wichtigkeit, alle Bedürfnisse und Inputs aus allen betreffenden Abteilungen einzuholen. Limitieren Sie sich nicht nur auf die Bedürfnisse der IT. Planen Sie Ressourcen ein und integrieren Sie das Log-Management in den Alltag. Und es ist naiv zu glauben, dass dies alles in ein paar Wochen bewältigt werden kann.

Über den Autor

Rocco Gagliardi

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Übergang zu OpenSearch

Übergang zu OpenSearch

Rocco Gagliardi

Graylog v5

Graylog v5

Rocco Gagliardi

auditd

auditd

Rocco Gagliardi

Security Frameworks

Security Frameworks

Rocco Gagliardi

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv