Get best of the week

Informationssicherheit Automatisierte Plattform für die Reaktion auf Vorfälle

Stellen Sie sich ein typisches Situationszentrum für Informationssicherheit in einem großen Unternehmen vor. In einer idealen Welt erkennt Software verdächtige Aktivitäten und das Team der "weißen Hacker" beginnt, mit den Händen auf die Tastatur zu tippen. Und das passiert einmal im Monat.

In der realen Welt sind dies Hunderte von Fehlalarmen und müden Support-Mitarbeitern. Sie sind gezwungen, sich mit jedem Vorfall zu befassen, wenn der Benutzer das Passwort vergessen hat, das Spiel nicht von einem Torrent oder einem anderen Pornofilm im * .exe-Format herunterladen, die Netzwerkfehler beobachten und im Allgemeinen viele Situationen untersuchen kann.

SIEM-Systeme helfen bei der Organisation und Korrelation von Ereignissen aus Quellen. Und sie erzeugen positive Ergebnisse, mit denen sich jedes befassen muss. Von diesen "allen" ist die Mehrheit falsch. Sie können sich dem Problem andererseits mit Skripten für die Alarmverarbeitung nähern. Jedes Mal, wenn etwas funktioniert, wäre es schön, nicht nur die Ursache des Alarms zu haben und dann in vier bis fünf Systeme für unterschiedliche Daten zu klettern und sofort automatisch die gesamte Diagnose zu erfassen.



Wir haben ein solches Add-On erstellt, das die Belastung der Bediener erheblich verringert hat. Da die Skripte zum Sammeln von Informationen sofort gestartet werden und typische Aktionen ausgeführt werden, werden sie sofort ausgeführt. Das heißt, wenn Sie das System starten "in einer solchen Situation tun wir dies und das", wird die Karte für den Bediener geöffnet, wenn die Situation bereits geklärt ist.

Was ist falsch an SIEM-Systemen?


Die Liste der Offsets ist stark mit Rohdaten überladen. Eine spezielle Incident-Karte zum Befüllen wird auf unsere Plattform übertragen.

Typische Fälle haben Probenreaktionsflussdiagramme.

Hier berichtet beispielsweise die Datenanalyse über Benutzerauthentifizierungsfehler:



Es gibt Kriterien für falsch positive Ergebnisse: Ich habe es zum Beispiel zweimal versucht - ich bin vom dritten ins Spiel gegangen. Der Benutzer erhält nur einen Brief, der besagt, dass das Passwort sorgfältig eingegeben werden muss, das Ticket wird geschlossen. Wenn er es fünf oder sechs Mal versucht hat, beginnen sich bereits detaillierte Informationen zu sammeln: was als nächstes geschah, was vorher geschah und so weiter. Wenn er sich zum zehnten Mal angemeldet hat und dann zur Wissensdatenbank gegangen ist und mit dem Herunterladen von 10 Dateien begonnen hat, kann es eine Einstellung geben, die den Zugriff auf die Wissensdatenbank bis zum Ende des Verfahrens blockiert und den Betreiber benachrichtigt. Wenn der Benutzer nicht böswillig ist, erhält die IT-Abteilung in diesem Fall höchstwahrscheinlich automatisch eine E-Mail mit den Details. Vielleicht bringen sie dem Benutzer bei, das Passwort korrekt einzugeben, oder helfen ihm, es zu ändern.

Wenn die Aktivität gefährlicher ist, die Ebene "die ausführbare Datei in der E-Mail geöffnet hat und sich dann etwas im Web eingeschlichen hat", wird möglicherweise ein ganzes Segment oder Subnetz automatisch blockiert. Ja, SIEM kann dies alleine tun, aber ohne Feinabstimmung sind solche Maßnahmen möglicherweise die Grenze der Automatisierung.

In einer idealen Welt hat der Bediener wieder Zugriff auf alle Systeme und weiß sofort, was zu tun ist. In der realen Welt muss er oft jemanden finden, der dafür verantwortlich ist, etwas zu klären. Und er ist auch im Urlaub oder bei einem Meeting. Daher sollte ein weiterer wichtiger Teil - im Reaktionsflussdiagramm - sofort für bestimmte Abschnitte von Systemen und Abteilungen verantwortlich sein. Das heißt, Sie müssen nicht nach dem Handy des Mitarbeiters, dem Namen seines Chefs und seinem Telefon suchen, sondern sie sofort auf einer offenen Karte sehen.

Was haben wir getan


  1. , (), - .
  2. , ( ), , .
  3. , -. : , , .
  4. , .
  5. .
  6. ( , , ).
  7. .
  8. GUI -.

Einer unserer Hauptkunden ist SIEM QRadar. Als gutes Bedrohungserkennungssystem gibt es für jeden Vorfall Aktionen und Schritte, aber Sie können keine Arbeitsliste für einen menschlichen Bediener erstellen. Wenn es um eine professionelle Superklasse geht, ist dies nicht erforderlich. Wenn es um den Betreiber der ersten Linie geht, ist es sehr wichtig, ihm Anweisungen zu geben, was und wie zu tun ist, und er wird in der Lage sein, die meisten typischen Vorfälle auf der Ebene eines coolen Spezialisten abzudecken.

Das heißt, wir haben alle offensichtlich langweiligen Ereignisse in der ersten Zeile entfernt und den Skripten Kriterien hinzugefügt, die langweilige von langweiligen trennen. Alles, was nach wie vor untypisch ist, fällt auf die Profis.

Als Ergebnis wurden Fälle für Unternehmen mit mehreren Zehntausenden von Arbeitsplätzen und mit ihren Serverkapazitäten in mehreren Rechenzentren für etwa ein Jahr ausgearbeitet und vorgeschrieben (es gibt schwierige Beziehungen zwischen Abteilungen, die die Integration in verschiedene Systeme erschwerten). Aber jetzt hat jede Unteraufgabe auf der Karte eine bestimmte verantwortliche Person, und sie ist immer relevant.

Die Einfachheit für die Betreiber kann daran gemessen werden, dass das System bei der Implementierung zunächst in Regionen eingeführt wurde und nach einigen Wochen offizielle Unterlagen versandt wurden. In dieser Zeit haben die Menschen bereits begonnen, Vorfälle sicher zu schließen.

Wie hat es angefangen?


Es gibt SIEM, aber es ist nicht klar, was ständig passiert. Genauer gesagt, QRadar generiert viele Ereignisse, sie fallen in die Abteilung für Informationssicherheit und es gibt einfach keine Hände, um alles richtig und detailliert zu zerlegen. Infolgedessen werden Berichte einfach oberflächlich betrachtet. Der Nutzen von SIEM mit diesem Ansatz ist nicht sehr hoch.

Es gibt ein Vermögensverwaltungssystem.

Es gibt Server zum Scannen des Netzwerks, die sehr gut konfiguriert sind.

Der Bericht würde ausgezeichnet sein, aber sie sahen ihn müde an und schoben ihn ab.

Der Kunde wollte, dass das, was er gekauft hat, zu Ergebnissen führt.

Wir haben den Service Desk für Sicherheitspersonal an die Spitze gestellt (eigentlich ein Ticketsystem, wie beim normalen Support), Datenanalysen visualisiert und die beschriebene Automatisierungsplattform auf der Grundlage von IBM Resilient + geschrieben und typische Reaktionen hinzugefügt. Resilient kommt nackt, es ist nur ein Rahmen. Wir haben die Korrelationsregeln von QRadar als Grundlage genommen und die Antwortpläne für Benutzerfälle fertiggestellt.



Mehrere Monate lang haben sie alles russifiziert und die richtigen Bundles per API aufgehängt. Sobald wir fertig waren, gab der Verkäufer Russification heraus und wir waren ein wenig traurig.

Ungefähr einen Monat lang haben sie die Dokumentation geschult und kennengelernt (insbesondere das Zeichnen neuer Flussdiagramme für Karten). Je weiter sie lernten, desto einfacher wurden Fälle: Zuerst wurden riesige Skripte von Aktionen geschrieben, und dann stellte sich heraus, dass sie zu einer Art Bibliothek typischer Fälle wurden. Und man könnte sich in fast jeder Reaktion auf sie beziehen.

Reaktionsvergleich


Vorfall "Wiederholte Virusinfektion mit derselben Malware in kurzer Zeit." Das heißt, der Virus wird an Arbeitsstationen erkannt, aber das Personal muss wissen, woher er kommt. Die Infektionsquelle ist aktiv.

Klassisch:

  1. Es gab eine wiederholte Virusinfektion des Hosts 192.168.10.5 mit derselben Malware für einen kurzen Zeitraum, Ereignisse wurden an SIEM gesendet und die entsprechende Regel funktionierte.
  2. .
  3. .
  4. .
  5. .
  6. /CMDB-.
  7. .
  8. - , .
  9. / .
  10. Service Desk .
  11. Füllt eine Anwendung im Service Desk-System basierend auf den Ergebnissen einer Untersuchung aus, um die Sicherheitsanfälligkeit zu beseitigen, aufgrund derer dieser Host infiziert wurde.
  12. Er wartet darauf, dass Service Desk-Anwendungen geschlossen werden, und überprüft dann deren Ausführung.
  13. Füllt eine Vorfallkarte aus und schließt den Vorfall.
  14. Es berichtet dem Management über die Ergebnisse seiner Arbeit.
  15. Der Analyst sammelt Ereignisstatistiken, um die Effektivität des Reaktionsprozesses zu analysieren.

Auf unserer Plattform:

  1. Es gab eine wiederholte Virusinfektion des Hosts 192.168.10.5 mit derselben Malware in kurzer Zeit, Ereignisse wurden an SIEM gesendet und die entsprechende Regel funktionierte.
  2. Der Bediener sieht sich die Vorfallkarte an, auf die Informationen zu diesem Host, den Status des Antiviren-Schutz-Tools und seiner Protokolle, Schwachstellen auf dem Host, verwandte Vorfälle und die für diesen Host verantwortlichen Personen bereits heruntergeladen wurden.
  3. , : , , Service Desk , - .
  4. Service Desk , .
  5. .
  6. .




Es wurde etwas schneller. Die Hauptsache ist jedoch nicht dies, sondern dass es möglich ist, die Aufgaben in "Der First-Line-Operator wird sich darum kümmern" und "Besondere Bedürfnisse" zu sortieren. Das heißt, die Lösung für jedes Ticket ist im Durchschnitt erheblich billiger geworden und das System ist skalierbarer.



Zusätzlich zu vielen Fehlalarmen gab es viele Duplikate, die vom System als bequem zu erkennen erwiesen wurden.



Karten sehen nicht wie eine Reihe dunkler Daten aus einem Bericht aus, sondern wie „Vasya hat dies und das auf einem Host getan. Das ist schlecht. Der Gastgeber ist für Petja verantwortlich. Genau das ist passiert. Wir müssen zu Petya gehen und sagen, dass Vasyas Computer aus dem Arbeitsbereich nicht verwendet werden kann, um Präsentationen auf Konferenzen zu zeigen.

Ein weiterer wichtiger Punkt dabei ist, dass es aufgrund der Erfassung von Primärdaten möglich geworden ist, Tickets zu priorisieren. Das heißt, die wichtigsten potenziellen Bedrohungen tauchen auf und erfordern sofortige Aufmerksamkeit und nicht in einer Live-Warteschlange.

Die Automatisierung an der Schnittstelle zu IT-Tickets ermöglichte es, nicht nur alle Informationen über den Vorfall zu sammeln, sondern auch sofort Tickets an die IT-Abteilung zu senden. Wenn Sie einige Einstellungen am Router ändern müssen, wird jetzt beispielsweise automatisch ein Ticket von der IT generiert. Überraschenderweise tauchten Fälle auf, in denen "vergessen wurde, das Konto im Dienst zu ändern, und er versucht, einen Monat lang eine Verbindung herzustellen". Die IT sieht solche Situationen nicht und ignoriert die Infrastruktur nicht. Und hier sagt der IS - der Dienst kann sich nicht anmelden. Und sie haben ein Ticket gestellt.

Dank der Eingabe von Reaktionskarten wurden Vorfälle mit Standardmethoden gelöst. Zuvor wurde jeder kreativ entschieden: Unterschiedliche Personen haben unterschiedliche Aktionen ausgeführt.

Das Ergebnis ist ein so guter Workflow wie im modernen CRM. Der Vorfall passiert einen Trichter. Ein weiteres Problem wurde in der letzten Phase gelöst: Frühere Leute schlossen das Ticket manchmal einfach, weil es müde war. Das heißt, das Ergebnis wurde schlecht verschrieben. Und jetzt müssen Sie dem System beweisen, dass dies falsch positiv ist. Das heißt, Sie können es wie zuvor schließen, aber es ist klar, wer und unter welchen Bedingungen es getan hat, und es ist viel einfacher, die Pfosten zu öffnen. Nicht nur "der Benutzer konnte die Datei nicht ausführen", sondern "brachte das Spiel auf den USB-Stick, wollte es installieren - sie erklärten die Regeln des Lebens noch einmal". Und es ist bereits klar, was passiert ist.

Vielseitigkeit


Jetzt gibt es einige Integrationen in der Produktion (eine ist mit QRadar und einem Asset-Management-System sehr groß, eine andere ist kleiner). Es ist möglich, mit jedem SIEM über Standard-APIs eine Verbindung herzustellen, aber die Integration erfordert natürlich Zeit für Konnektoren, die Verfeinerung von Dateien und das Aufschreiben von Reaktionsregeln für Personen. Trotzdem hilft es sehr, wirklich auf Sicherheitsvorfälle zu reagieren und dies relativ schnell und relativ billig zu tun. Es ist wahrscheinlich, dass SIEM-Systeme dies in 10 Jahren selbst können, aber bisher hat sich unser Add-On gut bewährt.

Wenn Sie es mit uns fühlen oder besprechen möchten, wie es mit Ihnen aussehen könnte, ist hier meine Mail AAMatveev@technoserv.com.

More articles:


All Articles