event
Best Practice

Log-Management-Verwaltung für Sicherheit und Compliance

Hat jemand nicht autorisierte Änderungen an Ihren Active Directory-Richtlinien oder Zugriffssteuerungslisten (Access Control Lists, ACLs) für ein Verzeichnis auf einem Server vorgenommen, der geistiges Eigentum des Unternehmens enthält? Hat sich jemand unbefugten Zugriff auf Daten verschafft, die gesetzlich geregelt sind, wie z.B. als HIPAA? Versucht jemand, sich in Ihre internen Systeme zu hacken? Was ist, wenn Ihr Compliance-Beauftragter Sie nach SOX-zentrierten Berichten fragt?

Jeden Tag generieren Computernetzwerke auf der ganzen Welt Aufzeichnungen über die Ereignisse, die auftreten. Einige sind Routine. Andere sind Indikatoren für einen Rückgang des Netzwerkzustands oder versuchte Sicherheitsverletzungen. Protokolldateien enthalten eine Fülle von Informationen, um eine Die Exposition des Unternehmens gegenüber Eindringlingen, Malware, Schäden, Verlusten und rechtlichen Verpflichtungen. Protokolldaten müssen gesammelt, gespeichert, analysiert und überwacht werden, um regulatorische Compliance-Standards wie Sarbanes Oxley, Basel II, HIPAA, GLB, FISMA, PCI DSS, NISPOM. Dies ist eine gewaltige Aufgabe, da Protokolldateien aus vielen verschiedenen Quellen, in verschiedenen Formaten und in großen Mengen stammen und viele Unternehmen keine geeignete Protokollverwaltungsstrategie zur Überwachung und Sicherung haben. ihr Netzwerk.

Als Reaktion darauf werden in diesem Artikel allgemeine Anforderungen an das Ereignis- und Protokollmanagement (ELM) und bewährte Methoden erläutert, um das Potenzial für Sicherheitsverletzungen zu verringern und die Möglichkeit von Rechts- oder Compliance-Problemen zu verringern.

Warum zentralisierte Ereignis- und Protokollverwaltung (CENTRALIZED Event and Log Management, ELM) wichtig ist

Jedes System in Ihrem Netzwerk generiert eine Art Protokolldatei. Tatsächlich wird für jedes Ereignis oder jede Transaktion, die auf einem Computer oder einer Hardware stattfindet, ein Protokolleintrag erstellt – stellen Sie sich das als Ihr "Journal of Record" vor. Microsoft-basiert Systeme generieren Windows-Ereignisprotokolldateien, und UNIX-basierte Server und Netzwerkgeräte verwenden das Systemprotokoll oder den Syslog-Standard. Webanwendungsserver wie Apache oder IIS sowie Load Balancer, Firewalls, Proxyserver oder Content Security-Appliances W3C/IIS-Protokolldateien generieren.

Die zentralisierte Protokollverwaltung sollte eine Schlüsselkomponente Ihrer Compliance-Initiativen sein, da Sie mit zentralisierten Protokollen Dateizugriff, nicht autorisierte Aktivitäten von Benutzern, Richtlinienänderungen und andere kritische Aktivitäten überwachen, überwachen und Berichte erstellen können. für Dateien oder Ordner, die proprietäre oder regulierte personenbezogene Daten wie Mitarbeiter-, Patienten- oder Finanzunterlagen enthalten. Eine zentralisierte Protokollverwaltungsstrategie sollte die Überwachung von Ereignisprotokollen, Syslog- und W3C-Protokollen umfassen. Und das ist der Schlüssel, weil Informationsverletzungen kommen gleichermaßen aus internen und externen Quellen. Beispielsweise geben Ihnen Windows-Ereignisprotokolle Einblick in potenziell schädliche Aktivitäten, die von verärgerten Mitarbeitern durchgeführt werden, während die Syslog-Verwaltung Ihnen die Kontrolle über Ihren Netzwerkperimeter.

Windows-basierte Systeme verfügen über mehrere verschiedene Ereignisprotokolle, die konsistent überwacht werden sollten. Von diesen Protokollen ist das Sicherheitsprotokoll das wichtigste. Es liefert wichtige Informationen darüber, wer im Netzwerk angemeldet ist und was sie tun. Sicherheit Protokolle sind für das Sicherheitspersonal wichtig, um zu verstehen, ob in der Sicherheitsimplementierung Schwachstellen bestehen.

Syslog ist ein Protokollmeldungsformat und Protokollübertragungsprotokoll, das von der Internet Engineering Task Force (IETF) in RFC-3164 mit Entwurfsverbesserungen in RFC-5424 als Standard definiert wurde. Netzwerkgeräte, UNIX- und Linux-Systeme sowie viele Software und Hardware Plattformen implementieren Syslog als Standardprotokollierungsformat und Mittel zum Übertragen und Sammeln dieser Protokolldateien in einem zentralen Protokollverwaltungs-Repository. Mithilfe von Syslog-Informationen können Sie sehr detaillierte Informationen über den Status eines Geräts erfassen. oder eine Reihe von Geräten. Die Informationen können sortiert und analysiert werden, um atypisches Verhalten durch Änderungen in Betriebs- oder Leistungsmustern zu sehen. Diese Änderungen können auf ein einzelnes oder mehrere Probleme hinweisen. Die Speicherung von Syslog-Protokolldaten kann auch unterstützen Compliance-Bemühungen durch die Bereitstellung von Überwachungsprotokollen, um alle Ereignisse zu verfolgen, die die Netzwerkzuverlässigkeit und den Schutz von Daten beeinträchtigen können. Dies ist wichtig, da es den Prüfern die Kontrolle über alle Informationen beweist.

In ähnlicher Weise liefern W3C-Protokolle auch Informationen über Benutzer- und Serveraktivitäten. Auch diese Überwachungsprotokolle sollten überwacht werden, da sie wertvolle Informationen liefern, anhand derer Sie nicht autorisierte Kompromittierungsversuche, z. B. Ihren Webserver, identifizieren können. IIS-Protokolldateien sind ein festes (d. h. es kann nicht angepasst werden) ASCII-Format, das mehr Informationen als andere Protokolldateiformate auftakt, einschließlich grundlegender Elemente wie ip-Adresse des Benutzers, Benutzername, Anforderungsdatum und -uhrzeit, Dienststatuscode, und Anzahl der empfangenen Bytes. Darüber hinaus enthält das IIS-Protokolldateiformat detaillierte Elemente wie die verstrichene Zeit, die Anzahl der gesendeten Bytes, die Aktion und die Zieldatei.

Durch die Bereitstellung einer zentralisierten Protokollverwaltungslösung können Sie die häufig überwältigende Menge an Protokollinformationen, die von Ihren Systemen generiert werden, problemlos verwalten. Der Echtzeitzugriff auf Protokolldaten ermöglicht es Ihnen, diese eine "Nadel im Heuhaufen" zu filtern und zu lokalisieren Ereignis, das die Ursache für eine Sicherheitsverletzung sein könnte.

Wie viele Protokolldaten sind vorhanden?

Jeden Tag produzieren Ihre Server und andere Netzwerkgeräte 10 von Tausenden von Protokolleinträgen. Tatsächlich sammelt das durchschnittliche Unternehmen bis zu 4 GB Protokolldaten pro Tagan. Über 95% der Daten in den Logfiles bestehen aus detaillierten Einträge, die jedes erfolgreiche Ereignis oder jede Transaktion aufzeichnen, die auf dem System stattfindet. Zum Beispiel; Ein Serverabsturz, Benutzeranmeldungen, Starten und Stoppen von Anwendungen und Dateizugriff.

Viele Administratoren sind überrascht zu erfahren, dass "einfache" Protokolldateien zu einer so großen Datenmenge führen können, die gesammelt und dann gespeichert wird. Es ist die Wahrnehmung dieser meist routinemäßigen Daten, die im Mittelpunkt der Versäumnis, die ständig generierten Protokolldaten zu erfassen, zu speichern und zu analysieren. Sie sollten niemals die Bedeutung der Daten in diesen Dateien unterschätzen.

Beim manuellen Sammeln und Überprüfen von Protokolldaten müssen Sie sich darüber im Klaren sein, dass je mehr Server Protokolldaten erstellen, desto mehr Erkennungs- und Lokalisierungspotenzial für ein sicherheitsbezogenes oder Compliance-Problem nimmt im Laufe der Zeit exponentiell ab.

Sicherheit innerhalb des Perimeters

Sicherheit steht bei der IT-Strategie eines Unternehmens jeder Größe immer im Vordergrund. Normalerweise konzentriert sich diese Strategie auf den Umkreis des Netzwerks, um unbefugten Zugriff oder Angriffe von böswilligen Parteien zu verhindern, die nicht mit der Organisation verbunden sind.

Während externe Sicherheit unerlässlich ist, was ist mit den internen Aspekten? Ein nosy Mitarbeiter, der vertrauliche Finanzdaten des Unternehmens einsehen möchte und seine Zugriffsberechtigungen ändert? Oder ein verärgerter Mitarbeiter, der eine Hintertür zu einem Schlüsselserver geschaffen hat und ist dabei, Terabyte an Kundendaten zu löschen? Obwohl dies extreme Fälle sein können, sind Sie bereit, diesen möglichen Ereignissen entgegenzuwirken? Das Potenzial für eine Sicherheitsverletzung ist von einer internen Quelle genauso wahrscheinlich wie von außen. In Tatsache, es kann sogar höher sein. Wie wir in der Zusammenfassung besprochen haben, ist das Haftungspotenzial beträchtlich, wenn eine unbefugte Person auf Daten zugreift, die durch einen Gesetzgebungsakt geschützt gelten.

Durch die Etablierung einer umfassenden ELM-Strategie zur Sicherheitsüberwachung von Windows-Ereignisprotokollen für interne Aktivitäten und Änderungen, die außerhalb des Bereichs normaler Geschäftsaktivitäten liegen, können Sie kleine Ereignisse lokalisieren und verhindern, bevor sie zu eine große Katastrophe.

Compliance-Initiativen: Bereiten Sie sich auf das Schlimmste vor

Ihre Organisation kann mit der Einhaltung gesetzlicher Vorschriften konfrontiert sein oder auch nicht. Wenn Sie eine private Einheit sind, tun Sie dies höchstwahrscheinlich nicht. Dies sollte Sie jedoch nicht daran hindern, zu verstehen, was die regulatorischen Standards als Anforderungen definiert haben. Nutzung dieser Standards kann Ihnen eine Blaupause für Ihre eigenen internen Sicherheitspläne und Protokollverwaltungsstrategie liefern.

Wenn Ihre Organisation öffentlich ist, kann die Nichteinhaltung von Sarbanes-Oxley beispielsweise zu hohen Geldstrafen und gesetzlicher Haftung für die Beamten führen. Viele der Anforderungen der anderen gesetzlichen oder branchenspezifischen Initiativen für Sicherheit und Compliance, da sie sich auf die Protokollverwaltung beziehen, überschneiden sie sich mit denen von Sarbanes-Oxley. Infolgedessen orientieren sich alle öffentlichen und viele private Unternehmen an diesem Standard, um sich bei der Erstellung einer Protokollverwaltungsstrategie beraten zu lassen.

Eine kurze Überprüfung der folgenden Standards gibt Ihnen einen Überblick über jeden von ihnen und wie sie sich auf Ihre Protokollverwaltungsstrategie auswirken können.

Sarbanes-Oxley

In Sarbanes-Oxley ist der Ausdruck "interne Kontrollen" in Abschnitt 404 des Gesetzes von zentraler Bedeutung für die Compliance-Bemühungen.

Die Jahresberichte der Aktiengesellschaften müssen Folgendes enthalten:

[...] einen internen Kontrollbericht, der –

  1. die Verantwortung des Managements für die Einrichtung und Aufrechterhaltung einer angemessenen internen Kontrollstruktur und -verfahren für die Finanzberichterstattung dar; und
  2. eine Bewertung der Wirksamkeit der internen Kontrollstruktur und der Verfahren des Emittenten für die Finanzberichterstattung zum Ende des letzten Geschäftsjahres des Emittenten enthalten.

Mehrere Missverständnisse konzentrieren sich darauf, wer und was von diesen Anforderungen betroffen ist. Erstens gilt Sarbanes-Oxley nur für börsennotierte Organisationen mit einem Wert von mehr als 75 Millionen US-Dollar oder damit für private Unternehmen, die von öffentlichen Unternehmen erworben werden sollen. Sekunde Es sind nicht nur die Finanzdaten selbst oder die Berichterstattung über diese Daten, mit denen Sarbanes-Oxley befasst ist, wenn es sich um "Versagen der Kontrollstruktur" handelt; dies wurde sehr weit ausgelegt, um fast alles einzubeziehen dies könnte sogar die Zuverlässigkeit dieser Daten beeinträchtigen.

Aufgrund der inhärenten Unterschiede in Netzwerkkonfigurationen, Geschäftsmodellen, Märkten und den Präferenzen der Prüfer sollten die Best Practices, die später in diesem Dokument vorgeschlagen werden, als Ausgangspunkt betrachtet werden. Die untere Seitenleiste synthetisiert einige der ELM-Anforderungen, die in Ihre Audit- und Compliance-Strategien aufgenommen werden sollten.

Während sich diese Vorschläge auf Sarbanes-Oxley konzentrieren, können sie auch verwendet werden, um die Anforderungen von Basel II, GLBA, HIPAA, PCI und anderen Bemühungen zu erfüllen.

In den meisten Fällen wird dies Teil einer größeren Compliance-Strategie sein, also wenden Sie sich an Ihre Audit-Spezialisten, um weitere Details zu erhalten, die für die Compliance in Ihrer spezifischen Branche relevant sind.

Basel II

Im Vergleich zu Sarbanes-Oxley ist Basel II weniger bekannt und hat keine Schlagkraft. Ziel von Basel II ist es, international für mehr Stabilität in den Finanzsystemen zu werben. Für unsere Zwecke liegt der Fokus hier auf basels Sorge um das "operationelle Risiko", das der Interpretation unterliegt. Es ist möglich, dass ein guter Ausgangspunkt auch die oben aufgeführten für die Sarbanes-Oxley-Konformität sein könnten. Die Bemühungen erfordern die Interpretation der erweiterten Messung Ansatz (AMA), ein Teil des Basel II-Abkommens, durch die Management- und Prüfungsteams Ihrer Gruppe.

GLBA

In Bezug auf die IT-Compliance konzentriert sich der Gramm-Leach-Bliley Act (GLBA) auf den Schutz von Kundendaten durch Finanzinstitute. Ein Großteil von GLBA überschneidet sich mit den Anforderungen von Sarbanes-Oxley. Obwohl manchmal nur als ein anderer angesehen wird Sammlung von Regeln oder bloßen Richtlinien, GLBA hat Zähne. Zu den Folgen der Nichteinhaltung kann eine Zivilklage des US-Generalstaatsanwalts gehören. Das Gesetz kann über die Website der Federal Trade Commission abgerufen werden unter: http://www.ftc.gov/privacy/privacyinitiatives/glbact.html

HIPAA

Die Anforderungen von HIPAA ähneln denen von GLBA, da sie die Existenz eines zuverlässigen Audit-Trails zum Schutz der personenbezogenen Daten von medizinischen Patienten betonen. HIPAA besteht aus zwei Hauptregeln: den Datenschutz- und Sicherheitsregeln. Jeder von ihnen hat seine eigenen Anforderungen an die Implementierung und berichterstattung. Laut den Zentren für Medicaid und Medicare, zusätzlich zum Aufbau von IT-Infrastruktur und Strategien zum Schutz vor "Bedrohungen oder Gefahren für die Sicherheit oder Integrität der Informationen" müssen Vorbereitungen für die Untersuchung potenzieller Sicherheitsverletzungen vorhanden sein. Ein Audit-Trail muss in der Lage sein, "ausreichende Informationen zu liefern, um festzustellen, welche Ereignisse aufgetreten sind, als sie aufgetreten sind, und wer (oder was) sie verursacht hat."

FISMA

Der Federal Information Security Management Act (FISMA) soll kritische Informationsinfrastrukturen der US-Regierung schützen. Es legt Mindestsicherheitsstandards für Informations- und Informationssysteme fest und bietet Orientierungshilfen über die Bewertung und Auswahl der geeigneten Kontrollen zu ihrem Schutz. Jede Bundesbehörde und ihre Auftragnehmer sind verpflichtet, Richtlinien zu entwickeln, zu dokumentieren und umzusetzen, die den FISMA-Standards entsprechen. Das Nationale Institut für Standards und Technologie (NIST) hat eine Sonderpublikation 800-53 herausgegeben, um Richtlinien für die Auswahl und Spezifizierung von Sicherheitskontrollen für Informationssysteme bereitzustellen, die die Exekutivbehörden der Bundesregierung unterstützen.

NISPOM

Die Anforderungen in Kapitel 8 des National Industrial Security Program Operating Manual (NISPOM) sind für Regierungsbehörden und private Auftragnehmer mit Mitarbeitern, die Zugang zu sensiblen und klassifizierten Daten haben, von Interesse. Das manual gibt an, dass die Sicherheitsüberwachung das Erkennen, Aufzeichnen, Speichern und Analysieren von Informationen im Zusammenhang mit sicherheitsrelevanten Aktivitäten umfasst. 2 2. Angaben können aufgefordert werden, festzustellen, welche Aktivitäten stattgefunden haben und welcher Benutzer oder Prozess dafür verantwortlich war für sie.

PCI-DSS

Der von MasterCard und Visa entwickelte und von American Express durchgesetzte Payment Card Industry (PCI) Data Security Standard bietet IT-Shops, die sensible Kreditkartendaten von Verbrauchern verarbeiten, detaillierte Anforderungen. Jede Entität, die implementiert PCI-DSS muss in einem jährlichen PCI-DSS-Auditbericht nachweisen, dass sie dem Standard entsprechen, oder ihnen kann die Fähigkeit verweigert werden, kreditkartenbezogene Informationen zu verarbeiten oder zu speichern. Abschnitt 10 des Standards definiert Prüfungsinformationen und Anforderungen an Protokolldateien.

MA 201 CMR 17

Das Massachusetts Privacy Law – MA 201 CMR 17 definiert, dass "jede Person, die personenbezogene Daten über einen Einwohner des Commonwealth besitzt oder lizenziert", die Pflicht hat, ein System zu entwerfen, zu dokumentieren und zu implementieren, das schützt diese Informationen. Die betroffene Person könnte ein Mitarbeiter oder Kunde des Unternehmens sein. Das Datum des Inkrafttretens des Gesetzes war der 1. März 2010. Alle oben genannten rechts- oder branchenüblichen Standards spiegeln die anhaltende Notwendigkeit wider, nicht nur die Schutz und Integrität von finanziellen und personenbezogenen Daten, aber auch vorschreiben, dass jede einzelne Transaktion überprüfbar ist. Es wird dringend empfohlen, dass IT- und Sicherheitsexperten den Input und das Feedback ihrer Management- und Audit-Teams einholen. bei der Strukturierung von Compliance-Strategien auf Basis von ELM. Es sollte eine vollständige Beteiligung aller Disziplinen innerhalb einer Organisation erfolgen, um die Integrität des gesamten Prozesses von der Erfassung von Ereignis- und Protokolldaten bis hin zur Überwachung und Berichterstattung sicherzustellen.

Überwachung und Warnungen im Ereignisprotokoll

Erfahren Sie mehr über unsere Protokollverwaltungstools.

Weitere Informationen

Kontaktieren Sie unser Team

Sprechen Sie mit einem unserer Experten.

Weitere Informationen

Bewährte Methoden für die Ereignis- und Protokollverwaltung

Best Practice #1: Definieren der Überwachungsrichtlinienkategorien

Der Begriff Überwachungsrichtlinie bezieht sich im Microsoft Windows-Lexikon einfach auf die Arten von Sicherheitsereignissen, die in den Sicherheitsereignisprotokollen Ihrer Server und Arbeitsstationen aufgezeichnet werden sollen. Auf Microsoft Windows NT® Systemen müssen Sie die Überwachungsrichtlinie festlegen auf einzelnen Servern und Arbeitsstationen von Hand, aber in Windows 2000® oder Windows 2003® Active Directory® Domänen, bei aktivierter Gruppenrichtlinie können Sie einheitliche Überwachungsrichtlinieneinstellungen für Servergruppen oder die gesamte Domäne zuordnen. Für Eine Zusammenfassung der wichtigsten zu aktivierender Protokollierungskategorien finden Sie in der Tabelle "BASELINE ELM STRATEGY FOR SECURITY, COMPLIANCE AND AUDIT".

Best Practice #2: Automatische zentrale Konsolidierung aller Protokolldatensätze

Standardmäßig sind Windows-Ereignisprotokolle und Syslog-Dateien dezentralisiert, wobei jedes Netzwerkgerät oder System seine eigene Ereignisprotokollaktivität aufzeichnet. Um ein breiteres Bild der Trends im gesamten Netzwerk zu erhalten, müssen Administratoren mit Sicherheits- und Compliance-zentrierten Initiativen müssen einen Weg finden, diese Datensätze in einem zentralen Datenspeicher für eine vollständige Überwachung, Analyse und Berichterstattung zusammenzuführen. Die Erfassung und Speicherung von Protokolldaten ist von entscheidender Bedeutung, da einige Compliance-Standards eine Datenaufbewahrung von 7 Jahren oder mehr vorschreiben! Automatisierung kann hier wirklich helfen, weil es Zeit spart und die Zuverlässigkeit der Protokolldaten gewährleistet. Merken:

  1. Wenn die archivierten Protokolldateien abgerufen werden, muss es sich um eine zuverlässige Kopie der Daten handeln – es kann keine Debatte über die Integrität der Daten selbst geben. Da das menschliche Element mit der Automatisierung entfernt wird, wird die Datenzuverlässigkeit erhöht.
  • Die Anzahl der Computer, Benutzer und Administratoren im Unternehmen; und Überlegungen wie Bandbreite und konkurrierende Ressourcen können die Protokollerfassung so sehr erschweren, dass eine automatisierte Lösung die einzige Möglichkeit ist, sicherzustellen, dass jedes Ereignis erfasst wird. Können Sie sicherstellen, dass jedes einzelne Ereignis durch einen manuellen Prozess erfolgreich erfasst wurde?
  • In einem typischen Setup konfiguriert ein Administrator ein ELM-Tool, um Ereignisprotokollaufzeichnungen nachts (oder regelmäßig) von Servern und Arbeitsstationen in seinem Netzwerk zu sammeln. Dieser Prozess umfasst das Speichern und Löschen der aktiven Ereignisprotokolldateien aus jedem System, log entries aus den Logfiles in eine zentrale Datenbank (z.B. Microsoft SQL oder Oracle) einlesen und schließlich die gespeicherten Logfiles komprimieren und zentral auf einem sicheren Server speichern.

    Die Aufbewahrung Ihrer Protokolldaten in zwei Formaten – als Datenbankdatensätze und als komprimierte Flat Files – bietet einen deutlichen Überwachungsvorteil. Ereignisprotokolldaten in Flat Files werden extrem gut komprimiert, oft bis zu 5 % der ursprünglichen Größe. Daher kostet es in Bezug auf die Speicherkosten sehr wenig, archivierte Protokolldaten für viele Jahre aufzubewahren, sollte ein Auditor sie jemals benötigen. Flat Files sind jedoch ein sehr schlechtes Medium für Analysen und Berichte, so dass ein aktiver Arbeitsdatensatz (oft 60 bis 90 Tage) in einer Datenbank ermöglicht ad hoc Reporting sowie geplante Reportings für aktuelle Ereignisse. Suchen Sie nach einem ELM-Tool, das einen einfachen Mechanismus für den schnellen Wiedereinfuhr älterer gespeicherter Protokolldateien in Ihre Datenbank bietet, falls sie jemals benötigt werden. Es Wir haben die Erfahrung gemacht, dass die meisten Mitarbeiterstunden, wenn sie einem Audit gegenüberstehen, einfach darauf ausgerichtet sind, flache Dateien zu jagen und zu versuchen, die gleichen Arten von Daten aus allen zu extrahieren. Daten in einer zentralen Datenbank zur Bereithalten reduziert das Potenzial für verlorene Stunden, wenn ein Auditor anklopft.

    Best Practice # 3: Ereignisüberwachung - Echtzeitwarnungen und Benachrichtigungsrichtlinien

    Die meisten Unternehmen verfügen über eine heterogene IT-Umgebung mit einem breiten Mix aus Betriebssystemen, Geräten und Systemen. Auch wenn Ihre Umgebung zu Windows-Desktop- und Serverbetriebsbetriebsservern tendiert, möchten Sie möglicherweise auch die Möglichkeit, mehr als nur die Windows-Ereignisprotokollüberwachung auszuwählen. Syslog-Unterstützung ist nicht nur für Router, Switches, IDS und Firewalls wichtig, sondern auch für UNIX- oder LINUX-Systeme.

    Die meisten Softwareprodukte erfordern die Verwendung von Agenten, um protokolldateien in Echtzeit zu überwachen. Wenn ein Faktor Ihre Wahl einer Lösung beeinflusst, sollte dies der eine sein. Wenn Sie sich für eine agentenfreie Implementierung einer Überwachungslösung entscheiden können, tun Sie dies. Dies erspart Ihnen bei der ersten Implementierung, beim Wachstum Ihres Netzwerks und bei der laufenden Wartung Ihrer Überwachungslösung viele Kopfschmerzen.

    Bei der Entwicklung eines Protokollüberwachungsplans hat jede Organisation unterschiedliche Regeln, welche Arten von Ereignissen sie überwachen muss. IT-Abteilungen konzentrieren sich häufig auf Sicherheitsereignisse als alleinigen Indikator für Probleme. Während der Überwachung des Sicherheitsereignisprotokolls andere Ereignisprotokolle können auch auf Probleme mit Anwendungen, Hardwareprobleme oder bösartige Software hinweisen. Alle überwachten Ereignisse sollten mindestens ihren Ursprungspunkt zurückverfolgenkönnen. Die "BASELINE ELM STRATEGY" DIE SIDEBAR-Tabelle FOR SECURITY, COMPLIANCE AND AUDIT" im obigen Abschnitt stellt den Startpunkt für Ihre Protokollüberwachungsimplementierung bereit.

    Abhängig von Ihren Anforderungen und der Flexibilität der von Ihnen bereitgestellten ELM-Lösung sollten Sie eine Methodik für die kontinuierliche Überwachung definieren, die darauf basiert, wie häufig Sie Protokolle in Echtzeit auf interessante Ereignisse überprüfen möchten. Jeder Das definierte Ereignis wird in regelmäßigen Abständen abgefragt und generiert eine Warnung oder Benachrichtigung, wenn ein Eintrag von Interesse erkannt wird.

    Die Anzahl der konfigurierten Ereignisse, die Anzahl der Zielsysteme und die Abfragehäufigkeit bestimmen die Menge der Bandbreite, die während eines Abfragezyklus verbraucht wird. Wenn Sie die Ereignisse von Interesse auf bestimmten Systemen, die Sie überwachen möchten, bereits kennen, konfigurieren Sie weg.  Wenn Sie Ihre Ereignisüberwachung zum ersten Mal einrichten, ist es möglicherweise besser, zunächst alle Ereignisse zu aktivieren und eine höhere Abfragefrequenz zu konfigurieren. Nachdem Sich Ihr Vertrautheitsgrad erhöht hat, können Sie die Zahl von Ereignissen und Verringerung der Abfragehäufigkeit.

    Best Practice #4: Erstellen von Berichten für wichtige Stakeholder: Auditoren, Sicherheits- oder Compliance-Beauftragte und Managementteams

    Reporting ist ein Bereich, dem Sie besondere Aufmerksamkeit schenken sollten. Es liefert Ihnen aussagekräftigen Daten zu Sicherheitstrends und beweist Compliance. Die Berichterstellung kann Ihnen dabei helfen, die Notwendigkeit zu untermauern, Sicherheitsrichtlinien basierend auf Ereignissen zu ändern, die sich daraus ergeben können. oder zu einer Gefährdung der Sicherheit geführt haben.

    Jede VON Ihnen implementierte ELM-Lösung muss die folgenden Fragen beantworten:

    • Welche Berichtsformate sind verfügbar?
    • Wie viel Ihrer Arbeit bereits für Sie in vorgefertigten Ereignisprotokollberichten erledigt wurde, die mit dem Ereignis ausgeliefert werden
    • Sind Sie an ein bestimmtes Format gebunden? Werden HTML und die Verfügbarkeit dieses HTML-Berichts für mehrere Benutzer eine Rolle spielen?
    • Können kundenspezifische Filter leicht für die wiederholte Verwendung abgerufen werden?
    • Aus welchen Datenquellen können Berichte generiert werden? Enthält es EVT, Text, Microsoft Access und ODBC?
    • Ist die Lösung mit Ihrer Eventarchivierungslösung kompatibel?

    Weitere Informationen zur Protokollverwaltung

    Überwachen Sie alles in Ihrem Netzwerk

    Starten Sie Ihre Kostenfreie Testversion von WhatsUp Gold