Security Incident and Event Management
SIEM leicht gemacht
Weitere Szenarien
Es gibt aber auch zahlreiche Fälle, für die eine geringere Priorität genügt, etwa im Fall der Nutzung eines Firefighter Accounts im Einsatz von SAP GRC mit der Funktion "Superuser-Berechtigungsverwaltung" oder auch Firefighter. Über den Vorgang zumindest informiert, kann das Security-Management-Team stichprobenartig Verwendung und die entsprechende Dokumentation prüfen.
Kategorie 1 - sicherheitsrelevante Ereignisse
Der einfachste Weg bei der Konfiguration führt über feste Eskalationswege für Meldungen der Kategorie 1 (Typische Meldungen für Security Events wie beispielsweise fehlgeschlagene Anmeldungen). Diese Meldungen haben Sicherheitsrelevanz, sollten also umgehend analysiert werden. Doch gibt es hier einige Fälle, die zu False Positives führen: Mitarbeiter vertippt sich, weiß nach dem Urlaub sein Passwort nicht mehr genau, tippt nach einem Passwortwechsel versehentlich das alte Passwort ein. Solche Fälle sollten keine Meldung auslösen.
Das Problem so zu lösen, dass nur noch auf gesperrte Accounts eine Reaktion erfolgen soll, ist jedoch unzureichend für Accounts, die im Routinebetrieb nicht verwendet werden sollen (beispielsweise Notfall-User wie root, sap<sid>) oder technische Accounts, die von Anwendungen, Batch Jobs oder ähnlichen benutzt werden. Hier kristallisieren sich schon die ersten Regeln heraus.
Regel Nummer 1: Accounts, die nicht im Regelbetrieb verwendet werden, müssen sofort eine Meldung bei einer fehlgeschlagenen Anmeldung auslösen, die Dringlichkeit des Events sollte entsprechend hoch klassifiziert werden. Treten bei technischen Accounts fehlgeschlagene Anmeldungen auf, so ist mit großer Wahrscheinlichkeit von einem Angriff auszugehen. Der Grund dafür ist der, dass Passworte technischer Nutzer in der Regel fest in Konfigurations-Dateien oder besser in Secure Wallets gespeichert sind und daher auch keine fehlerhafte Eingabe vorkommen kann.
Die Meldung ist an die zuständige Betriebseinheit und an den verantwortlichen Bereich für Informationssicherheit weiterzuleiten. Dort kann das Security Information and Event Management-System bei einem klaren Fehlalarm nach Absprache mit einem Security-Verantwortlichen geschlossen werden, falls ein berechtigter Fall vorliegt oder im ungeklärten Fall eine Recherche zur Aufklärung eingeleitet werden.
Regel Nummer 2: Accounts, die im Regelbetrieb genutzt werden (Konten von Administratoren und fachlichen Nutzern), brauchen bei fehlgeschlagenen Anmeldeversuchen nicht sofort ein Security Event auszulösen. Doch bei einer Häufung von fehlgeschlagenen Anmeldeversuchen bei einer Vielzahl von Accounts sollte eine Meldung mit hoher Dringlichkeit ausgelöst werden. Denn Angreifer versuchen es in der Regel nicht mit Brute Force an einem Account, sondern über mehrere Konten. Mit zunehmender Zahl von Accounts steigt die Wahrscheinlichkeit, dafür ein schwaches Passwort zu finden - beispielsweise der aktuelle Monat in Kombination mit der Jahreszahl - und somit für einen erfolgreichen Angriff.
Sind also sehr viele Konten in einem System vorhanden, dann sollte hierfür eine Regel eingerichtet werden, die diesen intelligenten Angriff erkennen kann, ohne andauernd False Postives auszulösen. Entsprechende Templates für eine solche Regel sind in SIEM-Systemen meist vorhanden.
Außerdem können im Lauf der Zeit individuelle Statistiken erstellt werden, die ein zeitabhängiges Grundrauschen von fehlgeschlagenen Anmeldungen, also ein typisches Verhalten im Unternehmen aufzeigt. Auf Basis dieser Information setzt man dann entsprechende SIEM-Regeln auf, die bei einer überdurchschnittlichen Abweichung eine Meldung auslösen. Die Dringlichkeit kann sich hierbei am Maß der Abweichung orientieren.
Bei überdurchschnittlicher Häufung von fehlgeschlagenen Anmeldeversuchen muss unbedingt die Einstufung in eine höhere Dringlichkeit erfolgen, da eine unmittelbare Störung der Verfügbarkeit vorliegt (Denial of Service). Diese Störung ist sowohl betrieblich als auch aus Sicht der Informationssicherheit unmittelbar kritisch.
- Schützen Sie Ihr Unternehmen gegen DDoS-Attacken
Die Frequenz und der Umfang von DDoS-Attacken nehmen täglich zu. Aufgrund der steigenden Popularität dieser Angriffe sollten Unternehmen frühzeitig Abwehrmaßnahmen in Stellung bringen. Denn schlechte Netzwerkperformance sowie Ausfälle der Website und der Applikationen verursachen nicht nur hohe Kosten, sondern auch einen nicht zu unterschätzenden Reputationsverlust. Die gute Nachricht: Es gibt Maßnahmen, um den negativen Effekt zu minimieren. Markus Härtner, Senior Director Sales bei <a href="https://f5.com/">F5 Networks</a> gibt Ihnen zehn Tipps zur Hand, wie Sie die Auswirkungen einer Attacke auf Ihr Unternehmen gering halten. - 1. Angriff verifizieren
Zunächst gilt es, Gründe wie DNS-Fehlkonfiguration, Probleme beim Upstream-Routing oder menschliches Versagen definitiv auszuschließen. - 2. Teamleiter informieren
Die für Betriebsabläufe und Applikationen zuständigen Teamleiter müssen die angegriffenen Bereiche identifizieren und die Attacke "offiziell" bestätigen. Dabei ist es wichtig, dass sich alle Beteiligten einig sind und kein Bereich übersehen wird. - 3. Ressourcen bündeln
Ist ein Unternehmen einer massiven DDoS-Attacke ausgesetzt, müssen zügig die wichtigsten Anwendungen bestimmt und am Laufen gehalten werden. Bei begrenzten Ressourcen sollten sich Unternehmen auf die Applikationen konzentrieren, die den meisten Umsatz generieren. - 4. Remote-User schützen
Durch Whitelisting der IP-Adressen von berechtigten Nutzern haben diese weiterhin Zugriff auf die Systeme, und die Geschäftskontinuität wird aufrechterhalten. Diese Liste sollte im Netzwerk und gegebenenfalls an den Service Provider weitergereicht werden. - 5. Attacke klassifizieren
Um welche Art von Angriff handelt es sich? Volumetrisch oder langsam und unauffällig? Ein Service Provider informiert seinen Kunden gewöhnlich, wenn es sich um eine volumetrische Attacke handelt, und hat dann bestenfalls schon Gegenmaßnahmen eingeleitet. - 6. Bestimmte IP-Adressenbereiche blockieren
Bei komplexen Angriffen kann es sein, dass der Service Provider die Quellenanzahl nicht bestimmen und die Attacke nicht abwehren kann. Dann empfiehlt es sich, identifizierte IP-Adressen von Angreifern direkt an der Firewall zu blockieren. Größere Angriffe lassen sich per Geolocation – dem Verbot des Zugriffs auf die Unternehmensserver aus bestimmten Regionen – bekämpfen. - 7. Angriffe auf Applikationslayer abwehren
Zunächst gilt es, den bösartigen Traffic zu identifizieren und festzustellen, ob dieser von einem bekannten Angriffstool stammt. Spezifische Attacken auf Applikationsebene lassen sich auf Fall-zu-Fall-Basis mit gezielten Gegenmaßnahmen abwehren – dazu sind möglicherweise die schon vorhandenen Security-Lösungen in der Lage. - 8. Sicherheitsperimeter richtig einsetzen
Sollte es immer noch Probleme geben, liegt das potenziell an einer asymmetrischen Layer-7-DDoS-Flut. In diesem Fall ist es sinnvoll, sich auf die Verteidigung der Applikationen zu konzentrieren, und zwar mittels Login-Walls, Human Detection und Real Browser Enforcement. - 9. Ressourcen einschränken
Sollten sich alle vorherigen Schritte als unwirksam herausstellen, ist die Begrenzung von Ressourcen, wie die Übertragungsrate und die Verbindungskapazitäten, eine letzte – radikale – Möglichkeit. Eine solche Maßnahme hält den schlechten, aber auch den guten Traffic ab. Stattdessen können Applikationen auch deaktiviert oder in den Blackhole-Modus geschaltet werden – dann läuft der Angriff ins Leere. - 10. Kommunikation planen
Gelangen Informationen über den Angriff an die Öffentlichkeit, sollten die Mitarbeiter informiert und eine offizielle Stellungnahme vorbereitet werden. Sofern es die Unternehmensrichtlinien erlauben, empfiehlt es sich, die Attacke zuzugeben. Andernfalls können „technische Probleme“ kommuniziert werden. Mitarbeiter sollten auf jeden Fall die Anweisung bekommen, sämtliche Anfragen an die PR-Abteilung weiterzuleiten.
Kategorie 2 - regelmäßig auftretende Meldungen
Es kann sein, dass die Meldung im Regelbetrieb systembedingt auftritt, dass ein betriebliches Problem vorliegt oder dass tatsächlich ein Angreifer das System auf Schwachstellen testet, um sich Zugang zu verschaffen.
Regel Nummer 3: Meldungen, die regelmäßig im System auftreten, können mit niedriger Dringlichkeit ("low") klassifiziert werden, wenn die Betriebsverantwortlichen sie kennen und erklären können. Meldungen, die nicht ohne weiteres nachvollziehbar sind, sollten hingegen schnell geklärt und entsprechend klassifiziert werden.
Betrieblichen Problemen und Angriffen ist natürlich entsprechend zu begegnen, doch das betrifft die wenigsten Meldungstypen, so dass der Aufwand überschaubar bleibt. Eine statistische Auswertung im Laufe der Zeit hilft dabei, Abweichungen zu erkennen und so systembedingte Meldungen im Regelbetrieb schnell von Problemen und Angriffen zu unterscheiden.
Kategorie 3 - neue Meldungen
In diese Kategorie gehören Meldungen, die zum ersten Mal oder nur sehr selten auftreten. Leider fällt ein großer Anteil der Meldungen in diese Kategorie - sie lassen sich oft nur mit großem Aufwand klären, weil Fehlermeldungen meist nicht sehr selbsterklärend sind und eine verständliche Dokumentation fehlt. Tritt eine solche Meldung auf, deutet sie auf ein bisher unbekanntes betriebliches Problem hin oder auf einen Angreifer, der gerade einen Weg ins System sucht. Deshalb gilt
Regel Nummer 4: Meldungen, die selten oder noch nie aufgetreten sind, sollten mit einer mittleren bis hohen Dringlichkeit - in Abhängigkeit von der Häufigkeit - versehen werden.