Zertifizierung von Informationssystemen nach dem Prinzip der Standardsegmente. Mythen und Wirklichkeit

Guten Tag, Habr! Heute möchten wir verschiedene Mythen im Zusammenhang mit der Zertifizierung von Informatisierungsobjekten (OI) für Informationssicherheitsanforderungen nach dem Prinzip der Standardsegmente betrachten. Außerdem werden wir herausfinden, wie eine solche Zertifizierung korrekt durchgeführt werden kann.

Mythen müssen darüber viel zirkulieren und oft widersprechen sie sich. Zum Beispiel gibt es eine Meinung, dass Sie nach dem Prinzip der Standardsegmente alle ISPDs in einem Land zertifizieren können (obwohl die Zertifizierung für ISPDs nicht obligatorisch ist), aber es gibt eine Meinung, dass Sie Informationssysteme nur auf die altmodische Weise zertifizieren müssen, und all diese Ihre „typischen Segmente“ schlau.

Einführung

Die Zertifizierung des Informatisierungsobjekts ist möglicherweise eine der am stärksten regulierten und konservativsten Phasen beim Aufbau eines Informationsschutzsystems.

Der Konservatismus liegt in der Tatsache, dass die Zertifizierung einem bestimmten System mit einer bestimmten Liste technischer Mittel unterliegt, die im technischen Pass zum Gegenstand der Informatisierung und in der Konformitätsbescheinigung selbst sauber umgeschrieben sind. Das Ersetzen beispielsweise eines ausgebrannten Computers durch ein zertifiziertes Informationssystem kann mindestens eine lange Korrespondenz mit der Organisation, die die Zertifizierung durchgeführt hat, und zumindest zusätzliche Zertifizierungstests (dh Kosten) erfordern.

Dies war kein großes Problem, während die Zertifizierung der Anforderungen an die Informationssicherheit entweder freistehende Computer waren, die die geschützten Informationen verarbeiten, oder kleine dedizierte lokale Netzwerke.

Aber der Fortschritt steht nicht still. Für staatliche Informationssysteme bestimmt nun das 17. Dekret der FSTEC ihre obligatorische Zertifizierung vor der Inbetriebnahme. Und staatliche Informationssysteme sind heutzutage kein statischer Computer oder ein kleiner Lokalka, sondern große sich dynamisch ändernde Systeme, oft auf regionaler oder sogar föderaler Ebene.

Was ist in diesem Fall zu tun? Eine Bescheinigung ist erforderlich, ein statisches System kann jedoch nicht zertifiziert werden, da dort fast täglich neue Elemente hinzugefügt und alte entfernt werden. "Typische Segmente" kommen zur Rettung.

Dieses Konzept wurde durch die 17. Ordnung der FSTEC und die Norm GOST RO 0043-003-2012 „Informationsschutz. Zertifizierung von Informatisierungsobjekten. Allgemeine Bestimmungen “im Jahr 2013. Leider ist GOST im Gegensatz zur FSTEC-Bestellung als „Spanplatte“ gekennzeichnet, sodass der Standard hier nicht angegeben werden kann. Dabei geht jedoch nichts verloren, da die Reihenfolge der FSTEC in der Reihenfolge der Erweiterung des Konformitätszertifikats auf typische Segmente viel ausführlicher beschrieben wird (Abschnitt 17.3) und einige kurze Absätze in der Norm diesem Thema gewidmet sind.

Mythen rund um die Typensegmentzertifizierung

Es gibt viele Mythen um typische Segmente. Hier werden wir diejenigen analysieren, denen wir selbst begegnet sind. Wenn Sie Beispiele für ähnliche Mythen oder Fragen haben (Sie sind sich nicht sicher, ob dies ein Mythos ist oder nicht), können Sie dies gerne kommentieren.

Mythos Nummer 1. Ein Zertifikat nach dem Prinzip der Standardsegmente kann alle Informationssysteme in der Russischen Föderation zertifizieren

Theoretisch ist dies durch Regulierungsdokumente nicht direkt verboten, in der Praxis ist dies jedoch nicht möglich. Eine der Klauseln 17 der FSTEC-Verordnung über Modellsegmente besagt, dass die Ausführung der organisatorischen und administrativen Dokumentation zum Informationsschutz in Standardsegmenten sichergestellt werden sollte. Das große Problem liegt also genau in der Entwicklung einer solchen Dokumentation, die unterschiedliche technologische Prozesse der Informationsverarbeitung, unterschiedliche geschützte Informationen, unterschiedliche Anforderungen der Regulierungsbehörden usw. berücksichtigt. Infolgedessen ist die für ein System entwickelte Dokumentation für ein anderes nicht relevant.

Mythos Nummer 2. "Typische Segmente" werden nur für Zustandsinformationssysteme bereitgestellt

Es ist nicht so. Erstens erlaubt die 17. Ordnung des FSTEC selbst, dass seine Bestimmungen bei der Entwicklung von Informationsschutzsystemen in anderen Informationssystemen angewendet werden. Zweitens verwendet GOST RO 0043-003-2012 das umfassendere Konzept von „Informatisierungsobjekten“ anstelle von „Zustandsinformationssystemen“.

Mythos Nummer 3. Wenn sie uns ein Zertifikat geben, das auf Standardsegmente erweitert werden kann, können wir es auf alles anwenden

Dies ist nicht der Fall. Unter dem Spoiler wird der vollständige Text von Absatz 17.3 der FSTEC-Verordnung Nr. 17 für typische Segmente behandelt. Dann werden Fälle berücksichtigt, in denen das ausgestellte Zertifikat nicht verteilt werden kann. Hier müssen wir genauer bleiben.


Weiter werden wir spezifische Beispiele für Fehler nehmen und nur die entsprechenden Zitate aus diesem normativen Akt als Rechtfertigung dafür anführen, warum dies nicht möglich ist.

Beispiel Nr. 1

Nur der Serverteil ist zertifiziert, aber ich möchte das Zertifikat auf Workstations (AWS) erweitern. Kann das gemacht werden?



Nein! Die Zertifizierung des Informationssystems ist auf der Grundlage der Ergebnisse von Zertifizierungstests eines ausgewählten Satzes von Segmenten des Informationssystems zulässig, die die vollständige Technologie der Informationsverarbeitung implementieren .

Die Informationsübertragung über Kommunikationskanäle ist ebenfalls eine Verarbeitungstechnologie. Außerdem ist in diesem Beispiel keine einzelne Workstation zertifiziert, sodass das Zertifikat nicht auf eine andere Standardarbeitsstation erweitert werden kann.

Beispiel Nr. 2

Hier haben wir den vorherigen Fehler berücksichtigt und Datenübertragungskanäle und eine typische Workstation in das Zertifikat aufgenommen. Plötzlich mussten wir einen Laptop für einen großen Chef mit Verbindung zu einem zertifizierten System organisieren (natürlich über sichere Kanäle). Können wir das Konformitätszertifikat für diesen Laptop erweitern?

Nein! Ein Segment wird als geeignet für das Segment des Informationssystems angesehen, für das Zertifizierungstests durchgeführt wurden, wenn für die angegebenen Segmente dieselben Sicherheitsklassen und Bedrohungen für die Informationssicherheit festgestellt wurden ...

Für mobile technische Mittel treten hier neue Bedrohungen für die Informationssicherheit auf, die für stationäre Workstations nicht relevant sind und höchstwahrscheinlich nicht im Bedrohungsmodell für ein zertifiziertes System berücksichtigt werden.

Beispiel Nr. 3

Nun, wir haben diesen Pfosten berücksichtigt und dem Wachstumsmodell Bedrohungen hinzugefügt, Bedrohungen für mobile Geräte. Kann ich das Zertifikat jetzt auf den Laptop eines großen Chefs erweitern?



Nein! Ein Segment wird als relevant für das Segment des Informationssystems angesehen, für das Zertifizierungstests durchgeführt wurden ...

Trotz der Tatsache, dass das mobile Tool in der Konstruktionsdokumentation für das Informationsschutzsystem beschrieben wurde und das Bedrohungsmodell die mit den mobilen technischen Mitteln verbundenen Bedrohungen berücksichtigte, wurden für ein solches Tool keine Zertifizierungstests durchgeführt.

Beispiel Nr. 4

Wie kompliziert es ist! Aber diese Situation: Es gibt eine medizinische Einrichtung, es gibt zwei Informationssysteme - mit Mitarbeitern und ein medizinisches Informationssystem (MIS) mit Patienten. Können wir das Informationssystem mit Mitarbeitern speichern, zertifizieren und dieses Zertifikat auf IIAs ausweiten?



Nein! Ein Segment wird als geeignet für das Segment des Informationssystems angesehen, für das Zertifizierungstests durchgeführt wurden, wenn für die angegebenen Segmente dieselben Sicherheitsklassen festgelegt wurden ... dieselben Entwurfslösungen für das Informationssystem .



Obwohl hier alles kompliziert zu sein scheint, müssen Sie nur über die möglichen Optionen für typische Segmente nachdenken, um den Aufbau eines Schutzsystems vorzubereiten. Wenn Sie jedoch alles berücksichtigen (und es gibt nicht so viele Anforderungen), gibt es keine Probleme mit der Verteilung des Zertifikats.

Mythos Nummer 4. Typische Segmente müssen in der Konstruktionsdokumentation für das Schutzsystem beschrieben werden, beginnend mit dem Bedrohungsmodell

Es gibt keine solche Anforderung. Obwohl dies nicht direkt verboten ist, kann dieser Ansatz in Zukunft zu einigen Problemen führen. Was der 17. FSTEC-Befehl dazu sagt:

Die Merkmale der Zertifizierung eines Informationssystems auf der Grundlage der Ergebnisse von Zertifizierungstests eines ausgewählten Satzes seiner Segmente sowie die Bedingungen und Verfahren für die Verteilung eines Konformitätszertifikats an andere Segmente eines Informationssystems sind im Programm und in den Methoden für Zertifizierungstests, Abschluss und Konformitätszertifikat definiert.

Das heißt, wir haben das Recht, typische Segmente nur in der Phase der Zertifizierung zu erwähnen. In diesem Fall sind Ihre Segmente standardmäßig typisch, wenn die Bedingungen von Abschnitt 17.3 der FSTEC-Bestellung Nr. 17 erfüllt sind. Wir sind jedoch auf Fälle gestoßen, in denen versucht wurde, typische Segmente bereits in der Phase der Bedrohungsmodellierung zu beschreiben, wobei fast die Seriennummern der Geräte solcher Segmente angegeben wurden. Das Problem bei diesem Ansatz besteht darin, dass die Segmente, in die das Zertifikat bereits verteilt ist, beispielsweise unzulässig werden können, wenn ein Hardwareaustausch auftritt oder sich etwas in den Verarbeitungstechnologien ändert (z. B. wenn eine Virtualisierungsumgebung angezeigt wird). In diesem Fall kann es erforderlich sein, keine „zusätzlichen Zertifizierungstests“ durchzuführen, sondern den gesamten Testsatz gemäß dem neuen durchzuführen.

Im Allgemeinen empfehlen wir, typische Segmente in der Konstruktionsdokumentation überhaupt nicht zu erwähnen. In der Tat ist nach der aktuellen Gesetzgebung jedes Segment, das die festgelegten Bedingungen erfüllt, typisch.

WICHTIG! Wenn Sie Betreiber eines Informationssystems sind und beabsichtigen, ein Informationssystem mit der Möglichkeit zu zertifizieren, das Zertifikat auf Standardsegmente auszudehnen, sollten Sie dies mit Ihrer Zertifizierungsstelle besprechen, damit diese Möglichkeit in den Zertifizierungsdokumenten gemäß der 17. Bestellung des FSTEC berücksichtigt wird!

Mythos Nummer 5. FSTEC versteht keine "typischen Segmente" und wenn wir so zertifiziert sind, werden wir bestraft

Dieser Mythos klingt sehr seltsam, da typische Segmente in der Zulassungsdokumentation von FSTEC ausführlicher beschrieben werden. Diese Idee wird am häufigsten von den Sicherheitsleuten der sogenannten „alten Schule“ gehört.

Im Allgemeinen haben wir hier nichts zu sagen, außer „das ist nicht wahr“. Im Gegenteil, die Regulierungsbehörde fördert dieses Zertifizierungssystem für Informationssysteme auf jede erdenkliche Weise, und vor kurzem stießen wir sogar auf die Behauptung der FSTEC, dass ein riesiges Informationssystem auf regionaler Ebene NICHT nach dem Prinzip der Standardsegmente zertifiziert wurde. Dort musste ich erklären, dass es in diesem speziellen Fall nicht optimal war.

Mythos Nummer 6. Typische Segmente funktionieren nur, wenn das zertifizierte Teil und die zertifizierten Segmente Eigentum einer Organisation sind

Das ist nicht wahr. Dies ist in der Gesetzgebung nicht ausdrücklich festgelegt, aber alles, was nicht verboten ist, ist erlaubt. Natürlich gibt es gewisse Unterschiede, wenn die zertifizierten Teil- und Modellsegmente Eigentum einer Organisation sind und wenn die Modellsegmente juristischen Personen Dritter gehören.

In Fällen, in denen alles zu einer Organisation gehört, kann diese Organisation unabhängig Maßnahmen zum Schutz von Informationen in einem Standardsegment durchführen, eine Kommission ernennen und das Zertifikat auf ein Standardsegment ausweiten.

In Fällen, in denen es einen zentralen Betreiber des staatlichen Informationssystems (z. B. ein regionales Informationstechnologiezentrum) und Segmente anderer juristischer Personen (z. B. ein regionales Dokumentenverwaltungssystem staatlicher Institutionen) gibt, ist alles etwas komplizierter. Die Schwierigkeit liegt in der Tatsache, dass der Betreiber dieser GIS laut Gesetz für den Schutz von Informationen in staatlichen Informationssystemen verantwortlich ist. Damit der nächste Test den Bediener nicht erwärmt, weil irgendwo in der Schule, 400 km vom regionalen Zentrum entfernt, keine Informationsschutzmaßnahmen ergriffen werden, muss er diesen Prozess zumindest in der Phase des Anschlusses eines typischen Segments dokumentieren. Zunächst werden die Regeln für die Verbindung zum Informationssystem erstellt, in denen der Betreiber die Anforderungen an den Schutz von Informationen, die auf dem verbundenen Segment erfüllt sein müssen, klar und deutlich beschreibt. Dies umfasst in der Regel die Ernennung der Verantwortlichen, die Genehmigung interner Dokumente für den Informationsschutz (insbesondere verwirrte Betreiber können sogar einen Standardsatz entwickeln und bereitstellen), den Kauf, die Installation und die Konfiguration der erforderlichen Informationsschutz-Tools, die Schwachstellenanalyse usw. Darüber hinaus führt die Organisation, die eine Verbindung herstellen möchte, eine Leistung durch Alle Anforderungen und in der in den Vorschriften festgelegten Weise bestätigen dies.

Andererseits sind alle beschriebenen Schwierigkeiten ein ungefährer Aktionsplan, den wir bereits zusammen mit einem dieser Betreiber erfunden haben. Wenn der Betreiber eines verteilten GIS keine Angst hat, die Verantwortung dafür zu tragen, dass er die Anforderungen zum Schutz von Informationen auf dem Remote-Segment zumindest in der Verbindungsphase nicht erfüllt, kann er einen vereinfachten Weg einschlagen (wie „vereinfacht“ dieser Betreiber entscheiden kann).

Leider tun dies einige Betreiber, weil sie aufrichtig an den folgenden Mythos glauben.

Mythos Nummer 7. Die Zertifizierungsstelle ist dafür verantwortlich, das Zertifikat auf Segmente auszudehnen, die die Anforderungen nicht erfüllen.

Für uns als Zertifizierungsstelle ist es sehr wichtig, die Grenzen unserer Verantwortung zu verstehen. Da das Gesetz die Frage „Wer ist für die Ausweitung des Zertifikats auf nicht konforme Segmente verantwortlich?“ Nicht eindeutig beantwortet, haben wir einen Brief an die FSTEC geschrieben.

FSTEC antwortete, dass die Zertifizierungsstelle nur für die Qualität der Zertifizierungstests selbst verantwortlich ist. Der Organisationsbetreiber des Informationssystems ist für die korrekte Verteilung des Zertifikats auf typische Segmente verantwortlich.

Mythos Nummer 8. Typische Segmente geben uns nichts. Auf jeden Fall müssen Sie einen Lizenznehmer gewinnen und ihm Geld bezahlen

Es ist nicht so. Zumindest in Fällen, in denen das Personal des Betreibers des Informationssystems über Spezialisten verfügt, die alle oben beschriebenen Tätigkeiten ausführen können.

Andererseits stoßen wir häufig auf die Tatsache, dass wir gebeten werden, beim Verbinden von Standardsegmenten zu helfen. Zumindest in solchen Segmenten müssen Sie die interne Dokumentation ausarbeiten, Informationssicherheitstools installieren und korrekt konfigurieren. Darüber hinaus vertrauen viele Betreiber von Informationssystemen den Schlussfolgerungen zur Konformität eines typischen Segments, die von einer Drittorganisation verfasst wurden, mehr als dem Bericht des Antragstellers über die Verbindung zum System.

Aber auch in diesem Fall ermöglichen typische Segmente dem Bediener, Geld zu sparen, da zumindest kein separates Bedrohungsmodell und keine Konstruktionsdokumentation für das Informationsschutzsystem für anbringbare Elemente entwickelt werden müssen. Es ist auch nicht erforderlich, umfassende Zertifizierungstests durchzuführen.

Mythos Nummer 9. In typischen Segmenten sollten nur dieselben technischen Mittel verwendet werden (z. B. Computer mit demselben Motherboard, demselben Prozessor, demselben RAM, je nach Typ, Hersteller und Modell).

Dieses Problem ist auch in der Gesetzgebung eindeutig nicht geregelt. Auf einer intuitiven Ebene ist klar, dass die vollständige Einhaltung des Bügeleisens des zertifizierten und verbundenen Segments nicht erforderlich ist, da sonst das Ganze wertlos ist. Und wenn wir eine ähnliche Frage klären müssen, was machen wir dann? Das ist richtig - wir schreiben einen Brief an die Aufsichtsbehörde. FSTEC antwortete erwartungsgemäß, dass in typischen Segmenten keine identischen (ein Hersteller, ein Modell usw.) technischen Lösungen verwendet werden sollten.

Damit ein Segment als für das zertifizierte Segment geeignet angesehen werden kann, muss dieselbe Sicherheitsklasse für dieses Segment festgelegt, dieselben Bedrohungen für die Informationssicherheit identifiziert und dieselben Entwurfslösungen für das System selbst und für das Informationsschutzsystem implementiert werden. Wie tatsächlich in der 17. Ordnung geschrieben.

Mythos Nummer 10. Für jedes anhängbare Typensegment müssen Sie Ihr eigenes Bedrohungsmodell erstellen.

Nein. Im typischen Segment sollten dieselben Bedrohungen relevant sein wie im zertifizierten Teil des Informationssystems. Dementsprechend ist das Bedrohungsmodell eines für das gesamte System. Wenn im zertifizierten Informationssystem wesentliche technologische Änderungen auftreten, die zur Entstehung neuer Bedrohungen für die Informationssicherheit führen könnten, muss das allgemeine Bedrohungsmodell überarbeitet und erforderlichenfalls zusätzliche Zertifizierungstests des gesamten Systems durchgeführt werden.

Mythos Nummer 11. Daten angehängter Standardsegmente müssen nicht im technischen Pass für das Informationssystem enthalten sein

Zu diesem Thema haben wir auch die FSTEC gefragt. Die Antwort ist, dass die Daten neuer Segmente in den technischen Pass eingegeben werden müssen. Es liegt jedoch beim Bediener, ob neue Daten in das allgemeine Datenblatt des Systems eingegeben oder ein separates Dokument für das Segment erstellt werden. .

. – . , .