Wie alles begann
Seltsamerweise waren unsere ersten Schritte zur Bildung von KPIs für Solar JSOC in keiner Weise mit den Zentren für die Überwachung und Reaktion auf Cyber-Angriffe verbunden. „Zu Beginn unserer Jugend“ haben wir Unternehmen beim Aufbau von Systemen zur Bewertung der Wirksamkeit der Informationssicherheit unterstützt (ISMS 27001 und das ist alles). Das Verständnis für ihre Bedürfnisse entstand dann auf natürliche Weise auf dem Markt: Fast jede Abteilung für Informationssicherheit ist Tag für Tag gezwungen, große Datenmengen aus verschiedenen Systemen zu analysieren. Natürlich hat jeder von ihnen eine Art Berichterstattung, aber bei einer großen Anzahl von ihnen ist es sehr schwierig, sich ein ganzheitliches Bild über den Stand der Informationssicherheit zu machen und anschließend dem Management einen Bericht in einem geeigneten Format zur Verfügung zu stellen. Das Problem verschärft sich, wenn die Organisation geografisch verteilt ist.
Wir haben Kunden nur dabei geholfen, nicht nur einen Komplex von KPI / Metriken zu erstellen, sondern auch eine umfassende Analyselösung, die Daten aus Informationssicherheitssystemen aggregiert. Tatsächlich handelt es sich um ein Visualisierungssystem, in dem Sie schnell und einfach die Essenz des Problems und seine Lokalisierung erkennen können, um schnell die erforderlichen Entscheidungen zu treffen. In diesen Projekten haben wir Erfahrungen gesammelt und sind zu dem Schluss gekommen, dass das System wirklich praktisch und nützlich ist. Und auch - dass die Arbeit des SOC ebenfalls bewertet werden muss.
Warum die Wirksamkeit eines SOC bewerten, insbesondere eines externen?
Es ist ganz einfach: Einerseits möchten wir verstehen, wie gut wir den Service anbieten, und andererseits möchten wir ein möglichst vollständiges Bild der Infrastruktur des Kunden erhalten und alle „schwarzen Flecken“ sehen, die nicht in unsere Prüfung einbezogen wurden und zu Risikofaktoren für den Service wurden. Einfach ausgedrückt, wir wollen verstehen: Werden wir diesen oder jenen Angriff auf den Kunden sehen oder nicht?
Als wir anfingen, als Dienstanbieter zu arbeiten, weigerte sich der Client, uns bestimmte Quellen für die Verbindung zu geben, die für eine 100% ige Identifizierung des Angriffs erforderlich waren. Infolgedessen ereignete sich ein solcher Angriff, wir sahen ihn nicht und erhielten trotz unserer anfänglichen Warnung Vorwürfe.
Ein weiteres Beispiel: Um einen Vorfall korrekt und genau zu identifizieren, müssen Sie die Quellen auf eine bestimmte Weise konfigurieren. Sie haben eine Liste dieser Einstellungen angegeben, aber der Kunde hat diese Arbeit nicht ausgeführt. Das Ergebnis ist das gleiche - ein verpasster Vorfall.
Daher haben wir verstanden, dass es wichtig ist, sowohl den Kunden als auch uns selbst explizit hervorzuheben, was genau wir in seiner Infrastruktur sehen, wo es für uns „blinde Flecken“ gibt, welche Angriffsmethoden am häufigsten implementiert werden und in welchen Bereichen, welche IT Vermögenswerte sind am anfälligsten für Angriffe und wie sich dies auf das Geschäft auswirken kann. Dazu muss das Visualisierungssystem die reale Situation zeigen und bei seiner Analyse helfen und nicht nur ein "Wow-Effekt" für die Führung sein (wie dies häufig der Fall ist).
KPI für SOC - was und wie messen?
Zunächst müssen Sie verstehen: Warum, warum benötigen Sie genau dieses KPI / Metrik-System? Möchten Sie die Leistung Ihrer Informationssicherheitsabteilung messen? Verstehen Sie, wie gut / erfolgreich (oder umgekehrt) Ihre Prozesse ablaufen? Oder zeigen Sie dem Management einfach: "Wer ist großartig?" Oder hängen Abteilungsboni möglicherweise von der KPI-Leistung ab? Ohne die Ziele der Bewertung der Effektivität zu verstehen, ist es unmöglich, ein wirklich funktionierendes KPI-System aufzubauen.
Nehmen wir an, wir haben uns für die Ziele entschieden, und jetzt stellt sich die interessanteste Frage: Wie kann man etwas messen? Sie können nicht mit einem Lineal zum SOC gehen, hier ist alles etwas komplizierter. Schließlich ist dies nicht nur SIEM als System zum Sammeln und Korrelieren von Informationssicherheitsereignissen, sondern auch eine Vielzahl von Systemen, mit denen der Dienst ordnungsgemäß funktioniert. Es gibt eine verrückte Datenmenge im SOC, daher gibt es viel zu bewerten.
Und in dieser Angelegenheit versuchen wir, uns so weit wie möglich von subjektiven KPIs zu entfernen, d. H. die Metriken, die nicht automatisch gemessen werden können. Zum Beispiel ist die Metrik "Wie schlecht alles bei uns ist" ohne die Teilnahme einer Person (die ihre
Beim Aufbau unseres KPI-Systems halten wir uns an folgende Grundsätze:
- Der KPI sollte sowohl für den SOC als auch für den Kunden wirklich wichtig sein.
- der Indikator muss messbar sein, d.h. Es müssen spezifische Berechnungsformeln erstellt und Schwellenwerte festgelegt werden.
- Wir sollten in der Lage sein, den Wert des Indikators zu beeinflussen (dh Metriken aus der Kategorie „Prozentsatz der Sonnentage pro Jahr“ sind für uns nicht geeignet).
Wir sind auch zu dem Schluss gekommen, dass das KPI-System nicht flach sein kann und mindestens drei Ebenen haben muss:
- "Strategisch": Dies sind KPIs, die das Gesamtbild der Erreichung der gesetzten Ziele widerspiegeln.
- "Untersuchung, Analyse, Identifizierung von Zusammenhängen": Dies sind KPIs, auf deren Grundlage die erste Ebene gebildet wird und die zur Umsetzung des Hauptziels beitragen.
- « »: KPI, ( – ).
Jeder der Indikatoren wirkt sich auf den Vorgesetzten aus. Da dieser Einfluss nicht gleich ist, wird jedem Indikator ein Gewichtungsfaktor zugewiesen.
Das erste, was wir ständig sehen möchten, ist natürlich, wie effektiv unser Service für unsere Kunden ist. Und natürlich müssen diese Informationen aktuell sein. Zu diesem Zweck haben wir ein Metriksystem entwickelt (und verbessern es weiter), das die Arbeitsqualität der einzelnen Dienste widerspiegelt: 1. und 2. Zeile, Servicemanager, Analysten, Reaktion, Verwaltung usw. Für jeden dieser Bereiche a ca. 10-15 KPIs - sie wurden auf der Grundlage einer Datenbank aus den Systemen berechnet, in denen die Mitarbeiter arbeiten (ob Anfragen rechtzeitig erfüllt werden, wie schnell wir auf Kundenanfragen reagieren, wie Quellen verbunden sind und vieles mehr).
SLA ist gut, aber echte Servicequalität ist wichtiger
Für uns ist es wichtig, dass die Serviceabdeckung es uns ermöglicht, die maximale Anzahl von Vorfällen und Angriffen zu ermitteln und keine blinden Kätzchen zu sein. Damit wir Vorfälle beim Kunden im Format seiner eigenen IT-Ressourcen und nicht in abstrakten IPs interpretieren können. Damit sich unsere Benachrichtigungen nicht darauf beschränken, dass "Mimikatz auf dem Host 10.15.24.9 gefunden wurde", und den Kunden nicht dazu zwingen, unabhängig herauszufinden, um welche Art von Host es sich handelt, verschwenden Sie die Zeit, die erforderlich ist, um zu reagieren und die Konsequenzen zu beseitigen.
Mit anderen Worten, es ist wichtig für uns zu verstehen, wie gut unsere SOC-Kunden geschützt sind. Es ist also notwendig zu bestimmen, wie detailliert und ausreichend wir sie "sehen":
- sind alle wichtigen Quellen mit uns verbunden;
- wie effizient das Informationssicherheitssystem des Kunden (das auch Quellen für unseren Service ist) seine Infrastruktur abdeckt;
- Sind alle Quellen so konfiguriert, wie wir es empfehlen, und welche Abweichungen gibt es?
- ob alle notwendigen und ausreichenden Szenarien zur Erkennung von Angriffen und Vorfällen beim Kunden gestartet wurden;
- ob alle verbundenen Quellen uns Ereignisse mit einer bestimmten Regelmäßigkeit senden;
- ob der Kunde auf alle unsere Benachrichtigungen reagiert und wie rechtzeitig er dies tut.
Und auch - wie beängstigend es ist, in diesem Kunden zu leben, das heißt:
- Wie oft wird es angegriffen, wie schwer sind diese Angriffe (gezielt oder massiv), wie hoch ist der Angreifer?
- Wie effektiv ist der Schutz des Kunden (Prozesse und Informationssicherheitssysteme) und wie oft wird er aktualisiert?
- Was ist die Kritikalität der an Vorfällen beteiligten Assets, welche der Assets werden am häufigsten von Angreifern verwendet usw.
Um alle diese übergeordneten Indikatoren zu berechnen, müssen Sie sie zunächst in kleinere und diese in noch kleinere Indikatoren aufteilen - bis wir das
Das einfachste Beispiel: Es gibt einen übergeordneten Indikator "Wirksamkeit von Informationssicherheitsprozessen", der aus kleineren Prozessen besteht, z. B. "Schutzgrad gegen Malware", "Schutzgrad für Sicherheitslücken", "Schutzgrad vor IS-Vorfällen", "Effizienz der Zugriffskontrolle" usw. ... Da in einer Organisation viele Informationssicherheitsprozesse implementiert sind, gibt es ebenso viele Metriken der zweiten Ebene. Um die Metrik der zweiten Ebene zu berechnen, müssen Sie jedoch noch feinere Metriken erfassen, z. B. "Der Grad der Abdeckung der Hosts des Unternehmens durch Antiviren", "Der Prozentsatz kritischer Vorfälle mit Malware", "Die Anzahl der beteiligten Assets", "Der Prozentsatz falsch positiver Ergebnisse", "Der Grad der Cyberkompetenz der Benutzer". , "Prozentsatz der Hosts in einer Organisation mit deaktiviertem Virenschutz", "Prozentsatz der Hosts mit veralteten Antiviren-Datenbanken" - Sie können fortfahren.Diese Metriken der dritten Ebene können im automatischen Modus von Informationssicherheitstools und anderen Systemen erfasst werden, und die Berechnung kann im Informationssicherheits-Analysesystem durchgeführt werden.
Das Erstellen von KPIs und das Verwalten der Leistung von SOCs ist sowohl für die Entwickler dieser Metriken als auch für den Kunden nach wie vor eine Herausforderung (und dies ist ein exklusiver Paartanz). Aber das Spiel ist die Kerze wert: Auf diese Weise ist es möglich, den Zustand der Informationssicherheit vollständig, zentral und schnell zu bewerten, Schwachstellen zu finden, schnell auf Vorfälle zu reagieren und das Informationssicherheitssystem auf dem neuesten Stand zu halten.
Wenn sich das Thema als interessant herausstellt, werde ich in zukünftigen Artikeln mehr über Metriken sprechen. Wenn Sie also etwas über bestimmte Aspekte der Messung des SOC erfahren möchten, schreiben Sie in die Kommentare - ich werde versuchen, alle Fragen zu beantworten.
Elena Trescheva, leitende Analystin bei Solar JSOC