GosSOPKA bedeutet. Terminologie übersetzen

Wenn Sie für ein Unternehmen arbeiten, das unter die Maßnahme Nr. 187-FZ („Zur Sicherheit der kritischen Informationsinfrastruktur der Russischen Föderation“) fällt, müssen Sie nicht erklären, was GosSOPKA ist und warum es benötigt wird. Im Übrigen erklären wir: GosSOPKA steht für State System zur Erkennung, Verhinderung und Beseitigung der Folgen von Computerangriffen. Architektonisch handelt es sich um einen einzelnen geografisch verteilten Komplex von Zentren unterschiedlicher Größe, in dem Informationen über Cyber-Angriffe ausgetauscht werden. Solche Zentren müssen alle Unternehmen schaffen, die Eigentümer der Objekte kritischer Informationsinfrastruktur sind (solche Unternehmen werden als CII-Subjekte bezeichnet). Ziel dieser groß angelegten Regierungsinitiative ist es, ein System des Informationsaustauschs zwischen den wichtigsten Organisationen des Landes über anhaltende Cyberangriffe zu schaffen und damit die Möglichkeit eines vorbeugenden Schutzes zu schaffen.

Das Hauptdokument, das die Funktionsprinzipien von GosSOPKA-Zentren und deren Interaktion mit einem höheren Zentrum definiert, waren lange Zeit die vom FSB entwickelten „methodischen Empfehlungen für die Schaffung und den Betrieb von GosSOPKA-Zentren“. Wir haben dieses Dokument zuvor geprüft und festgestellt, dass der Schwerpunkt seiner Aufmerksamkeit auf der Konstruktion von Prozessen für das Incident Management und die Sicherheitskontrolle von GosSOPKA-Probanden lag. Gleichzeitig ließ dieser Ansatz ein ziemlich großes Feld für unterschiedliche Interpretationen darüber übrig, wie viele Aufgaben das GosSOPKA-Zentrum lösen sollte und welche spezifischen Werkzeuge dafür erforderlich sind. Kürzlich: „Anforderungen an Tools zum Erkennen, Verhindern und Beseitigen der Folgen von Computerangriffen und zum Reagieren auf Computervorfälle.“ Versuchen wir herauszufinden, was die Regulierungsbehörde von Unternehmen erwartet, die selbst GosSOPKA-Zentren bauen, und dieses Problem zu untersuchen.


Hierarchie der Interaktion von Zentren

Es sind Versuche bekannt, GosSOPKA-Zentren ausschließlich auf IDS-Systemen aufzubauen. Es gibt auch Anbieter auf dem Markt, die IDS oder SOA als universelle Lösung für das Problem positionieren. KII-Probanden hatten viele Fragen bezüglich der Funktionalität und der Anforderungen für SIEM-Systeme, die viele Unternehmen als fast das einzige Werkzeug betrachteten, das zur Schaffung eines GosSOPKA-Zentrums erforderlich war.

Mit dem Erscheinen des Dokuments „Anforderungen an Tools zur Erkennung, Verhinderung und Beseitigung der Folgen von Computerangriffen und zur Reaktion auf Computervorfälle“ zeigt sich nun die erste Klarheit hinsichtlich der tatsächlichen Anforderungen des Regulators an die Tools des Zentrums.

Das Dokument beschreibt fünf Haupt-Subsysteme des GosSOPKA-Zentrums:

1. Erkennungswerkzeuge
2. Warnung bedeutet
3. Liquidationswerkzeuge
4. Entschlüsselungswerkzeuge (PACA)
5. Tools für den Informationsaustausch
6. Mittel zum kryptografischen Schutz von Kommunikationskanälen

Lassen Sie uns versuchen, die einzelnen Elemente nacheinander durchzugehen. Wir werden sofort reservieren, dass wir die Probleme der „Orthodoxie“ des Produkts und die Notwendigkeit einer Importsubstitution nicht berücksichtigen, sondern uns ausschließlich auf technische Aspekte konzentrieren.

Erkennungswerkzeuge, aber keine SOA. Vier Buchstaben

Unserer Meinung nach ist dieser Punkt einer der wichtigsten im Hinblick auf die Beilegung von Streitigkeiten über die Mittel, die eingesetzt werden können, da die Diskussionen "Benötigen Sie SIEM oder einfach genug SOA-Subsysteme" noch andauern und nicht nachlassen.

Lesen wir das Dokument genauer durch:

Zunächst sprechen wir über ein Tool, das Informationssicherheitsereignisse sammelt. Keine Zwischenfälle (die Ergebnisse der Arbeit an Schutzausrüstung), kein roher Verkehr oder dessen Kopie, nämlich Ereignisse. Dies gibt uns einen ziemlich transparenten Hinweis darauf, dass wir Protokollverarbeitungsfunktionen benötigen.

Der Hinweis zu diesem Absatz enthält auch eine ziemlich detaillierte und breite Liste potenzieller Quellen, aus denen diese Ereignisse hervorgehen sollten. Die Liste umfasst nicht nur klassische Schutzmaßnahmen (Firewalls, SOA, Virenschutzprogramme), sondern auch Infrastrukturquellen (Netzwerkgeräte und Betriebssysteme) sowie Anwendungsmanagementsysteme für Netzwerkgeräte, Systeme zur Überwachung der Dienstqualität usw.

All dies sowie die in den funktionalen Anforderungen erwähnten Wörter „Korrelation und Aggregation von Ereignissen“ definieren unserer Meinung nach die Zieltechnologie des Artikels als SIEM-Plattform ziemlich genau.

Dies folgt vollständig den zuvor herausgegebenen methodischen Empfehlungen, da ein aktives Schutzmittel nicht ausreicht, um Computervorfälle der Kategorien „nicht autorisierter Zugriff“, „Erraten von Passwörtern“ und „Malware“ vollständig zu erkennen.

Wird eine als SIEM vermarktete Plattform gleichermaßen geeignet sein? Nein, unserer Meinung nach, da im Text mindestens zwei ziemlich wichtige Anforderungen angegeben sind:

• Das Erkennungssystem sollte nicht nur Vorfälle korrelieren und erkennen, sondern auch die Ergebnisse ihrer Verarbeitung und "Informationen über IS-Ereignisse, auch in ihrer ursprünglichen Form" speichern. In Anbetracht der oben angegebenen Liste der Quellen sowie der empfohlenen Speichertiefe (mindestens 6 Monate) handelt es sich um eine vollwertige Plattform mit erweiterten Protokollverwaltungsfunktionen und der Bereitschaft, sehr wichtige Ereignisabläufe zu verarbeiten. Dies reduziert die Liste möglicher Optionen erheblich.
• Das Erkennungssystem sollte "eine integrierte Unterstützung für verschiedene Quellen von Informationssicherheitsereignissen und die Fähigkeit haben, zusätzliche Module zu entwickeln, die Informationen aus neuen Quellen für Informationssicherheitsereignisse bereitstellen", dh die Fähigkeit, die Liste und Zusammensetzung der verbundenen Quellen schnell zu verfeinern. Dies stellt Anforderungen an die Verfügbarkeit einer offenen API für die Entwicklung solcher Verbindungsmethoden (in den SIEM-Slang-Konnektoren) oder an die Fähigkeit, eine solche Verfeinerung schnell vom Anbieter zu erhalten.

Diese Anforderungen zeigen ganzheitlich eine sehr ernsthafte Einstellung des Reglers zur Funktionalität des Erkennungssystems. Meiner Meinung nach machen sie indirekt deutlich, dass die formelle Umsetzung der methodischen Empfehlungen (z. B. "Malware-Vorfälle können vom Netzwerkverkehr abgefangen werden, wir benötigen kein Antivirenprogramm" oder "Wir müssen nur zwei Quellen verbinden, um die Anforderungen zu erfüllen") wahrscheinlich nicht das richtige hat zur Existenz. Eine ernsthafte Untersuchung des Bedrohungsmodells und Arbeiten zur Einrichtung von Überwachungsszenarien sind erforderlich.

Warnen oder inventarisieren Sie es

Der nächste Abschnitt - Warnung bedeutet - ist für den Sicherheitsbeamten sowohl in Bezug auf als auch in Bezug auf die Ansätze viel näher und verständlicher. Den Warnmitteln sind folgende Funktionen zugeordnet:

• Bestandsaufnahme von Infrastruktur-Assets mit der Fähigkeit, Informationen zu speichern und zu ergänzen.
• Sammlung und Bewertung von Informationen zu Schwachstellen von Informationsressourcen.
• Sammlung und Auswertung von Informationen über Mängel (in unserem Lesen - Konfigurationsfehler) von Informationsressourcen.

Die beschriebene Liste von Funktionen wird am häufigsten von Softwareprodukten der Vulnerability Scanner-Klasse oder Sicherheitsscannern implementiert. Es scheint, dass der nicht offensichtliche Name „Warnsystem“ eine sehr korrekte Logik aufweist: Es ist unmöglich, einen potenziellen Angriffsvektor zu verhindern und Schwachstellen der Infrastruktur zu identifizieren, wenn Sie keine vollständigen Informationen über den Zustand, die verwendeten Knoten, die Software oder die Prozessschwachstellen Ihrer Assets haben.

Die Verwaltung von Assets und Schwachstellen mit all ihrer scheinbaren Einfachheit ist mit einer Vielzahl von Fallstricken behaftet. Eine Diskussion dieser Details ist jedoch nicht Teil des aktuellen Materials und kann in unseren zukünftigen Artikeln erscheinen. Ich möchte nur darauf hinweisen, dass fast alle Unternehmen mit den zur Lösung des Problems erforderlichen Tools ausgestattet sind, da ähnliche Anforderungen bereits in verschiedenen Aufträgen und Aufträgen des FSTEC und sogar im Gesetz über personenbezogene Daten enthalten sind. Die Hauptaufgabe besteht darin, ein vorhandenes Tool wiederzubeleben und Prozesse in der Realität und nicht auf dem Papier zu starten.

Eliminierung als kollaborative Eliminierung

Hier erhielten sowohl der Name des Produkts als auch die Anforderungen dafür eine eher unerwartete Interpretation. Zur Beseitigung haben wir eine Lösung, die in ihrer Funktion der Incident Management-Plattform nahe kommt, die in der IT-Welt als Service Desk bezeichnet wird, und der IS verweist stolz auf die Incident Response Platform (obwohl IRP auch über eine spezielle Funktionalität verfügt). Tatsächlich sind die Hauptaufgaben des Subsystems:

• Vorfallregistrierung mit der Möglichkeit, die Vorfallkarte zu bearbeiten und zu ergänzen.
• Die Fähigkeit, seinen Lebenszyklus mit der Übertragung des Vorfalls zwischen dem Verantwortlichen und den Einheiten zu verwalten.
• Die Möglichkeit, die endgültige Vorfallkarte gemäß den vom SCCC genehmigten Formaten zu sammeln.

Darauf aufbauend wird auch die Entsprechung der Funktion mit dem Namen des Systems aufgebaut. Die Liquidation eines Vorfalls erfordert in erster Linie das Zusammenspiel verschiedener Abteilungen des Unternehmens, und die Verwaltung des Liquidationsprozesses, die Kontrolle seines Zeitpunkts und die Vollständigkeit in diesem Fall stehen im Vordergrund. Daher sollte das für diesen Prozess zuständige Zentrum GosSOPKA über die entsprechenden Instrumente verfügen.

Die Auswahl an Lösungen und Technologien, die speziell für IS-Aufgaben auf dem Markt entwickelt wurden, ist immer noch sehr begrenzt. Das Dokument enthält jedoch keine direkten Einschränkungen für die Verwendung eines gemeinsamen IT-Systems (in Standard- oder Einzelausführung) für diesen Zweck mit einigen Änderungen für IS-Aufgaben. In der Regel sind Service Desk-Systeme ein gut anpassbarer Konstruktor, sodass eine Überarbeitung nicht schwierig sein sollte.

Andere Einrichtungen des Zentrums

Die Funktionen und Aufgaben des PACA-Subsystems zielen in erster Linie darauf ab, den Netzwerkverkehr sowohl im Echtzeitmodus (um Angriffe oder Versuche eines nicht autorisierten Zugriffs auf Netzwerkgeräte zu erkennen) als auch den Netzwerkverkehr im Hinblick auf seine weitere Verwendung im Nachhinein aufzuzeichnen und zu speichern Analyse von Ereignissen oder Untersuchung des Vorfalls. Diese Anforderungen sind nicht grundsätzlich neu. Die Aufgabe der Aufzeichnung des Netzwerkverkehrs wurde seit 2010 im Rahmen einer gemeinsamen Anordnung von FSTEC und FSB vor allen Eigentümern staatlicher Informationssysteme festgelegt. Diese Anforderungen mögen für kommerzielle Unternehmen unerwartet sein, aber tatsächlich ist ihre Implementierung auch nicht besonders schwierig.

Die Anforderungen an die Austauschsubsysteme und den kryptografischen Schutz von Kommunikationskanälen sind ebenfalls recht vertraut und erfordern wahrscheinlich keine zusätzlichen Erläuterungen.

Als kurze Zusammenfassung hat die Veröffentlichung dieses Dokuments viele Punkte in Bezug auf Tools und Technologien, die das Zentrum von GosSOPKA ausstatten müssen, über mich gestellt. Jetzt hat jeder Kunde eine formelle Liste von Anforderungen, die sowohl für den Vergleich von Anbietern als auch für die Entscheidung über den Kauf / Austausch von Technologie hilfreich ist. Das Auftreten von Klarheit in solchen Angelegenheiten wirkt sich immer positiv auf die Effizienz und Geschwindigkeit der Schritte aus, die von bestimmten Akteuren unternommen werden, um eine Verbindung herzustellen, sowie auf die Gesamtsicherheit kritischer Informationsinfrastrukturen.