Und nichts schien gut zu sein, aber irgendwann tauchten Gedanken über die Notwendigkeit auf, mit einer alternativen Plattform zu arbeiten, und wurden immer hartnäckiger. Und die Hauptlokomotive hier war die aktive Entwicklung von GosSOPKA-Zentren. Um eines dieser Zentren zu werden, mussten wir die mitgelieferte Software verwenden"Garantie und technische Unterstützung durch russische Organisationen, die nicht unter der direkten oder indirekten Kontrolle ausländischer Personen und (oder) juristischer Personen stehen" (Beschluss des FSB vom 06.05.2019 Nr. 196, Ziffer 3.4). Wie wir
Rahmen aus der Zeichentrickserie "Catdog"
Wir haben gehört, dass es SOCs gibt, die sich zu
- Welche Lösung soll man wählen?
- Wie kann das neue SIEM-System in den TIER1-Betrieb integriert werden?
- Wie können all die vielen internen Integrationen, die ArcSight derzeit benötigt, auf die neue Plattform übertragen werden?
- Wie kann die Ideologie der SIEM-Inhaltsentwicklung synchronisiert und symmetrische Erkennungsregeln bereitgestellt werden?
Die Wahl einer Lösung war keine leichte Aufgabe. Überall mussten wir in einen Whirlpool eintauchen, dessen Tiefe wir nicht abschätzen konnten. Infolgedessen haben wir uns entschlossen, eine andere Wahl zu treffen - SIEM vom Anbieter zu verwenden, der uns eine hohe Priorität für Verbesserungen gemäß unseren Anforderungen versprochen hat und an dessen Versprechen wir geglaubt haben. So entstand eine technologische Partnerschaft mit Positive Technologies und MaxPatrol SIEM erschien im Trichter unserer SIEMs.
Ok, wir haben eine neue Plattform. Aber wer wird mit ihr arbeiten?
Um ehrlich zu sein, hatten wir zunächst das Gefühl, dass wir nicht auf ein zweites Team verzichten könnten, das parallel zum neuen Toolkit arbeitet. Dieses Gefühl wurde durch die Tatsache verstärkt, dass selbst die leitenden Analysten, die am Testen des zweiten SIEM teilnahmen, Schwierigkeiten hatten, dies zu akzeptieren. Daher wurde das Konzept zunächst wie folgt gezeichnet: zwei TIER1-Linien, die jeweils mit einem eigenen Instrument geschärft wurden, und die plattformübergreifende TIER2. Mit dem Multiplattform Readiness Factor als Wachstumsfaktor für einen Spezialisten von T1 bis T2.
Ungefähr zu dieser Zeit haben wir genügend Gründe gesammelt, unsere erste Spur in TIER1 und TIER2 aufzuteilen (mehr dazu in einer anderen Artikelserie). Und da im ursprünglichen Konzept T2 mit beiden Plattformen funktionieren sollte, haben wir alle MP SIEM-Vorfälle in die 2. Spur verwandelt, die aus den erfahrensten 1. Kämpfern besteht, die in das neue SIEM eingetaucht waren. Mit Blick auf die Zukunft werde ich sagen, dass die Ingenieure der 2. Linie das MP SIEM positiver wahrgenommen haben als ihre älteren Kollegen-Analysten - dies gab uns Hoffnung, dass die Plattform vollständig in der 1. Linie landen und nicht mehrere spezialisierte umzäunen könnte.
Das Problem der Integration in ein einziges Ökosystem war auch nicht so schmerzhaft wie erwartet - möglicherweise wurde es durch die Tatsache unterstützt, dass Flexibilität und Konfigurationsredundanz ursprünglich in die entwickelten Integrationsmechanismen einbezogen wurden. Es gab keine besonders großen Siege, mit denen ich mich rühmen möchte. Wir haben das neue System schnell in die Ökosystem- und Untersuchungsprozesse integriert, und jetzt unterscheidet sich die Verarbeitung von Vorfällen aus verschiedenen SIEMs für die Jungs nur noch in der Schnittstelle des SIEM selbst. Alle Routing- und Priorisierungsmechanismen, alle bereichernden Entscheidungsinformationen und alle Benachrichtigungsvorlagen sind identisch und befinden sich an denselben vertrauten Orten.
Was ist mit Inhalten?
Mit einem „leeren“ SIEM ohne Inhalt (Regeln für die Korrelation von Informationssicherheitsereignissen und die Identifizierung von Vorfällen) können Sie nicht weit kommen, und Sie werden nicht viele Bedrohungen aufdecken (wir verwenden keine Box-Inhalte). Daher entstand die Aufgabe, schnell Korrelationsregeln auf einer neuen Plattform für vorhandene JSOC-Szenarien zu entwickeln. Zuerst haben wir uns entschlossen, mit ein wenig Blut auszukommen und die Regeln von ArcSight mit dem Kopieren der Implementierungslogik zu übertragen. Dies stellte sich jedoch als Fehler heraus, bei dem wir uns ernsthaft verbrannt haben: Eine völlig andere Produktarchitektur erforderte einen "eigenen" Entwicklungsansatz. Ich musste diesen Ansatz in einem beschleunigten Tempo entwickeln. Die enge Interaktion mit dem Anbieter hat vielen geholfen, die in neu auftretenden Fragen berieten und unsere Anforderungen zur Verfeinerung bestehender und zur Schaffung neuer Chips in der Funktionalität umgesetzt haben.Die Kehrseite der Medaille ist, dass wir den Inhalt regelmäßig neu schreiben mussten, damit er bei dieser sehr neuen Funktionalität korrekt funktioniert. Aber wie sie sagen, ändern oder sterben, also haben wir uns nicht beschwert (naja, außer vielleicht im Team bei einem Glas Tee).
In der Anfangsphase waren nur erfahrene Analysten der 4. Linie, die den Hund während der Arbeit mit ArcSight gefressen hatten, mit der Entwicklung von Inhalten für das neue SIEM beschäftigt. Seltsamerweise hatten einige Leute zu diesem Zeitpunkt bereits eine professionelle Verformung erfahren und eine "Abhängigkeit" von einem bestimmten SIEM mit seinem hohen Reifegrad gebildet. Der Wechsel zu einer neuen Plattform war für sie sowohl psychologisch als auch technisch schwierig. Später wurde das Entwicklungsteam um neue Mitglieder erweitert, inkl. Jungs aus der 3. Reihe, und nur für sie hat sich dieses Thema viel einfacher und oft noch produktiver entwickelt.
Trotz der übergreifenden Liste von Szenarien für beide SIEMs kann sich ihre Implementierung erheblich unterscheiden, hauptsächlich aufgrund von Einschränkungen in der Architektur und Funktionalität verschiedener Plattformen. In ArcSight können Sie beispielsweise in der Korrelationsregel keine Überprüfung auf das Vorhandensein eines Datensatzes im aktiven Blatt durch nicht strikte Übereinstimmung angeben, in MP SIEM jedoch. Auf der anderen Seite generiert MP SIEM keine internen Ereignisse zum Hinzufügen oder Entfernen eines Datensatzes zur Tabellenliste. ArcSight kann dies jedoch. In einer Reihe von Szenarien wird diese Funktion verwendet. Ich musste
Gleichzeitig war es sehr wichtig, der ersten Zeile zu vermitteln, dass die Logik der Vorfalluntersuchung nicht davon abhängt, auf welchem SIEM sie generiert werden, und dass das neue SIEM ein neues Werkzeug zur Lösung derselben Aufgaben ist. Es hat seine eigenen Eigenschaften, die untersucht werden müssen, aber nichts ändert sich radikal.
Und die Arbeit an der 1. Linie begann zu kochen
Das Eintauchen von TIER1 in die Arbeit mit MP SIEM verlief schrittweise und entsprechend dem Prozess, der mit der Einführung neuer Mitarbeiter behoben wurde. Es wurden die Kriterien für Vorfälle festgelegt, die für die Analyse der 1. Zeile, die noch nicht viel Erfahrung mit MP SIEM hat, nicht sehr beängstigend sind:
- Details zu geringen kritischen Vorfällen (nicht kategorisierte Hosts / Netzwerke und Konten);
- lange SLA-Zeiten;
- geringe Arbeitsintensität des Vorfalls (wir haben Statistiken bei der Verarbeitung von Vorfällen bei TIER2 gesammelt);
- nicht sehr wütende Korrelationsregeln (ja, Sie müssen dort nach der ersten Zeile suchen).
Die Szenarien gemäß diesen Kriterien wurden in mehrere Phasen unterteilt und nacheinander an die TIER1-Ingenieure übergeben - nachdem die "Credits" bestanden und Zugang zur Lösung des Pools von Vorfällen erhalten wurden.
Infolgedessen haben wir in unserem Werkzeugportfolio zwei SIEMs, auf denen Szenarien gestartet werden, die im Wesentlichen absolut identisch sind und eine Verarbeitungslogik aufweisen.
Alexey Krivonogov, stellvertretender Direktor von Solar JSOC für regionale Netzwerkentwicklung