In einem unserer
vorherigen Artikel haben wir das Problem der Erstellung einer Reihe von Dokumenten für Prüfer zum Schutz personenbezogener Daten angesprochen. Wir haben einen Link zu unseren
Dokumentvorlagen gegeben , uns aber sehr oberflächlich auf das Thema Informationssicherheitsdokumentation konzentriert.
In diesem Artikel möchte ich dieses Thema sowohl im Zusammenhang mit personenbezogenen Daten im Besonderen als auch im Bereich des Informationsschutzes im Allgemeinen ausführlicher behandeln. Welche Dokumente sollten beim Betreiber sein, die optional sind. Woher kommt die Nachfrage nach diesem oder jenem Dokument? Was in Dokumente zu schreiben ist und was es nicht wert ist. Unter dem Schnitt viele Buchstaben zu diesem Thema.
Ein paar Worte zur Verteidigung der "Papier" -Sicherheit
Da sich der Artikel auf die sogenannte "Papiersicherheit" konzentrieren wird, möchte ich unsere Position zu diesem Teil der Informationssicherheit sofort umreißen.
Für viele Technikfreaks, die mit „Händen“ arbeiten, führt diese „Papier“ -Sicherheit häufig zu scharfer Ablehnung und Vernachlässigung. Seltsamerweise möchte ein solcher Technikfreak jedoch zuerst die Dokumentation für dieses Wunder der Technologie kennenlernen, wenn ihm ein neues Stück Hardware oder Software (und manchmal beides in einem Produkt) zur Verfügung steht.
Die häufigste Rechtfertigung für eine solche abweisende Position ist, dass alle diese Dokumente nur zur Vorführung erstellt werden, um den Anforderungen des Gesetzes zu entsprechen. Dies ist Zeitverschwendung. Dokumente müssen unterstützt werden, aber niemand wird dies tun usw. usw.
Leider ist diese Position nicht unbegründet. Im Laufe der Jahre hat sich sowohl bei lokalen Sicherheitskräften als auch bei Lizenznehmern, Integratoren und anderen interessierten Parteien die traurige Praxis entwickelt, dieselbe Haltung gegenüber Dokumenten zur Informationssicherheit einzunehmen. Infolgedessen wurde ein Teufelskreis gezogen - Dokumente werden unbrauchbar gemacht, weil sie vernachlässigt werden, und werden wiederum vernachlässigt, weil sie nutzlos sind.
Dies wird teilweise durch die Tatsache verstärkt, dass Informationssicherheitsdokumente häufig von Personen verfasst werden, die weit von der Informationstechnologie entfernt sind. Wie kann ich einen Abschnitt zum Schutz von Virtualisierungstools schreiben, ohne zu verstehen, wie diese Virtualisierung funktioniert?
Um diese Situation umzukehren, müssen gute, informative und nützliche Dokumente erstellt werden. Gleichzeitig müssen diese Dokumente den geltenden Informationsschutzgesetzen entsprechen. Mal sehen, was mit all dem gemacht werden kann.
Ein paar Klarstellungen
Um unnötige Fragen und Vermutungen zu vermeiden, halten wir es zunächst für notwendig, einige Punkte zu klären.
- In diesem Artikel werden nur interne Organisations- und Verwaltungsdokumente (im Folgenden als „ARD“ bezeichnet) für den Informationsschutz berücksichtigt. Design, Zertifizierung und andere Dokumente werden nicht berücksichtigt.
- Wir werden das Bedrohungsmodell auch nicht berücksichtigen, obwohl seine Vorlage hier ist . Die Entwicklung eines Bedrohungsmodells ist eine andere Geschichte. Schreiben Sie in die Kommentare - benötigen Sie ein Handbuch zur Entwicklung eines Bedrohungsmodells für Habré?
- Der Artikel basiert auf unseren Vorlagen. Es ist keine Art von Standard oder allgemein akzeptierter Satz. Dieses Set spiegelt unseren reinen Ansatz zur Entwicklung der ARD wider. Da die Gesetzgebung diesbezüglich häufig nichts Spezifisches vorschreibt, haben Sie möglicherweise Ihre eigene Meinung über die Vollständigkeit und den Inhalt von Dokumenten, und dies ist normal!
- Die Vorlagen enthalten möglicherweise Fehler und Tippfehler. Wir selbst verbessern und verfeinern sie ständig.
- Im Rahmen der Erfüllung der Anforderungen sind vor allem die Themen personenbezogene Daten (152- und Satzung) und staatliche Informationssysteme (17 Ordnung der FSTEC) betroffen. Darüber hinaus gibt es eine andere Geschichte mit Finanzorganisationen (Anforderungen der Zentralbank der Russischen Föderation) und verschiedenen Standards (ISO 2700x und andere) - wir werden sie hier nicht berücksichtigen.
Vollständigkeit der Unterlagen
Wenn Sie sich zum Schutz von Informationen auf Gesetze verlassen, gibt es wenig zu sagen, wo genau welche Dokumente wir entwickeln sollten. Daher müssen wir uns auf verschiedene indirekte Hinweise stützen.
Zum Beispiel geben wir Teil 2 von Artikel 19 des Gesetzes Nr. 152-FZ "Über personenbezogene Daten". Der Klartext ist der kursiv geschriebene Gesetzestext - die Notizen des Autors.
2. Die Sicherheit personenbezogener Daten wird insbesondere erreicht:
1) Feststellung von Bedrohungen für die Sicherheit personenbezogener Daten während ihrer Verarbeitung in Informationssystemen für personenbezogene Daten; (brauche ein Bedrohungsmodell)
2) die Anwendung organisatorischer und technischer Maßnahmen zur Gewährleistung der Sicherheit personenbezogener Daten während ihrer Verarbeitung in Informationssystemen für personenbezogene Daten, die zur Erfüllung der Anforderungen für den Schutz personenbezogener Daten erforderlich sind und deren Umsetzung das von der Regierung der Russischen Föderation festgelegte Maß an Sicherheit personenbezogener Daten gewährleistet; (Organisatorische Maßnahmen sind größtenteils unsere Dokumente, und hier senden sie uns, um weitere Satzungen zu lesen.)
3) durch Anwendung der Verfahren zur Bewertung der Konformität von Informationsschutzeinrichtungen, die in der vorgeschriebenen Weise bestanden wurden;
4) Bewertung der Wirksamkeit der Maßnahmen zur Gewährleistung der Sicherheit personenbezogener Daten vor der Inbetriebnahme des Informationssystems für personenbezogene Daten;
5) Berücksichtigung von Maschinenträgern personenbezogener Daten; (Offensichtlich benötigen Sie eine Art Buchhaltungsjournal und entwickelte Regeln für die Buchhaltung von Maschinenmedien.)
6) die Entdeckung eines unbefugten Zugriffs auf personenbezogene Daten und die Annahme von Maßnahmen; (Es ist erforderlich, einige Regeln zur Erkennung von Vorfällen und zur Beseitigung ihrer Folgen zu entwickeln. Möglicherweise muss ein Team für die Reaktion auf Vorfälle ernannt werden.)
7) Wiederherstellung personenbezogener Daten, die aufgrund unbefugten Zugriffs auf diese geändert oder zerstört wurden; (Sicherungs- und Wiederherstellungsregeln sind erforderlich)
8) die Festlegung von Regeln für den Zugang zu personenbezogenen Daten, die im Informationssystem für personenbezogene Daten verarbeitet werden, sowie die Registrierung und Aufzeichnung aller mit personenbezogenen Daten im Informationssystem für personenbezogene Daten durchgeführten Aktionen; (Die Entwicklung eines Systems für den Zugriff auf Daten kann auf der Grundlage von Rollen im System erfolgen. Nur die Software selbst sollte in der Lage sein, Protokolle darüber zu führen, wer auf welche Daten zugegriffen hat.)
9) Kontrolle über Maßnahmen zur Gewährleistung der Sicherheit personenbezogener Daten und des Sicherheitsniveaus personenbezogener Dateninformationssysteme. (Wir benötigen einen bestimmten Plan für die regelmäßige Überwachung sowie wahrscheinlich ein Tagebuch, in dem die Ergebnisse dieser Überwachung aufgezeichnet werden.)
Mit diesem Beispiel wollten wir den Unterschied zeigen: wie das Gesetz geschrieben ist und was es tatsächlich von uns verlangt. Hier sehen wir nicht die direkte Anforderung „Der Betreiber muss ein Bedrohungsmodell entwickeln“, aber diese Anforderung ergibt sich immer noch aus dem Text von 152-FZ, da die Erfüllung einer Anforderung dokumentiert ist.
Insbesondere informiert uns die FSTEC über die Vollständigkeit und den Inhalt der ARD. Im Jahr 2014 veröffentlichte diese Regulierungsbehörde ein methodisches Dokument mit dem Titel Informationssicherheitsmaßnahmen in staatlichen Informationssystemen. Ein Dokument ohne Sarkasmus ist ausgezeichnet, wenn Sie etwas in der Reihenfolge der Umsetzung der Maßnahmen des 17., 21. oder anderer FSTEC-Ordnungen nicht verstanden haben (ja, obwohl das Dokument für GIS bestimmt ist, die Maßnahmen jedoch größtenteils mit dem FSTEC übereinstimmen), beziehen Sie sich darauf Das Dokument kann viel klarer werden.
In diesem Dokument beschreibt der FSTEC daher Maßnahmen zur Gewährleistung der Informationssicherheit ausführlicher, und sehr oft finden Sie solchen Text:
Die Regeln und Verfahren zur Identifizierung und Authentifizierung von Benutzern sind in den Organisations- und Verwaltungsdokumenten zum Informationsschutz geregelt. (IAF.1)
Die Regeln und Verfahren für die Verwaltung von Benutzerkonten sind in den Organisations- und Verwaltungsdokumenten des Betreibers zum Schutz von Informationen geregelt. (UPD.1)
Regeln und Verfahren zur Verwaltung des Informationsflusses sind in den Organisations- und Verwaltungsdokumenten des Betreibers zum Schutz der Informationen geregelt. (UPD.3)
Nun, schon etwas, aber diese Regeln und Verfahren sind eine ganze Kutsche.
Infolgedessen musste ich mich mit einem Schild würgen, das alle Anforderungen aus allen Dokumenten aufschrieb und Notizen und Notizen zur Erfüllung und Nichterfüllung machte.
Die Hauptidee dieses Abschnitts ist, dass die Gesetzgebung zum Informationsschutz einen Berg von Anforderungen enthält, deren Umsetzung dokumentiert werden muss. Ob für jede Anforderung ein separates Dokument erstellt oder alles zu einer großen "IS-Richtlinie" zusammengeführt wird, liegt bei jedem. Alle zusätzlichen Dinge, die wir nicht entsprechend den Anforderungen, sondern aus praktischen Gründen in den Dokumenten registrieren müssen, werden problemlos hinzugefügt.
Beachten Sie übrigens, dass in der Tabelle und in den Dokumenten selbst einige Abschnitte oder Absätze mit „K1“ oder „K2 +“ gekennzeichnet sind. Dies bedeutet, dass ein Abschnitt oder Absatz nur für Informationssysteme der Klasse 2 und höher oder für die erste (maximale Klasse) erforderlich ist. Alles, was nicht markiert ist, wird in allen Zustandsinformationssystemen und ISPD durchgeführt.
Es ist auch offensichtlich, dass zum Beispiel einige Abschnitte oder sogar ganze Dokumente eliminiert werden können, wenn die strukturellen und funktionalen Eigenschaften des Informationssystems oder andere Anfangsbedingungen dies erfordern. Zum Beispiel entfernen wir die Bereitstellung von Videoüberwachung, wenn dies nicht der Fall ist. Oder wir entfernen alle Abschnitte, die sich auf den Schutz von Virtualisierungstools beziehen, wenn diese nicht angewendet werden.
Unsere Vorlagen sind in 4 Ordner unterteilt:
Allgemein - Dokumente, die für alle Systeme (sofern zutreffend) entwickelt werden müssen, unabhängig davon, ob es sich um ISPDn, GIS, ein automatisiertes Prozessleitsystem oder ein KII-Objekt handelt.
Nur GIS - Dokumente für staatliche Informationssysteme oder kommunale Informationssysteme, für GIS und MIS werden nur eindeutige Dokumente benötigt.
PD - Dokumente zum Schutz personenbezogener Daten und gemäß den Rechtsvorschriften zum Schutz personenbezogener Daten. Wenn wir zum Beispiel ein GIS haben, in dem personenbezogene Daten verarbeitet werden, müssen wir Dokumente aus allen Ordnern erstellen.
CIPF - Dokumente im Zusammenhang mit der Verwendung kryptografischer Tools, die für die Implementierung von Regulierungsdokumenten des FSB benötigt werden, werden für alle Systeme entwickelt, die zertifizierte kryptografische Mittel zum Informationsschutz verwenden.
Lassen Sie uns die Dokumente genauer betrachten, woher sie stammen und welche Anforderungen sie erfüllen.
Allgemein
01 Reihenfolge der Ernennung der Verantwortlichen und Anweisungen an diese Personen
In dieser Bestellung wird Folgendes festgelegt: die Person, die für die Organisation der Verarbeitung personenbezogener Daten verantwortlich ist, und der Sicherheitsadministrator.
Die Notwendigkeit, den ersten zu ernennen, ist in Artikel 18.1 des Bundesgesetzes festgelegt:
1. Der Betreiber muss Maßnahmen ergreifen ... Diese Maßnahmen können umfassen, sind aber nicht beschränkt auf:
1) die Ernennung der Person, die für die Organisation der Verarbeitung personenbezogener Daten verantwortlich ist, durch den Betreiber, der eine juristische Person ist;
Sicherheitsadministrator - Die Notwendigkeit für diesen Freund ist beispielsweise auf Klausel 9 der FSTEC-Verordnung Nr. 17 zurückzuführen:
Um den Schutz der im Informationssystem enthaltenen Informationen zu gewährleisten, ernennt der Betreiber die für den Schutz der Informationen zuständige Struktureinheit oder den Beamten (Mitarbeiter).
Diese Personen unterscheiden sich darin, dass der „Verantwortliche“ eher im Papierteil und der „Administrator“ im technischen Teil steht.
Damit der Verantwortliche und der Administrator ihre Aufgaben und Befugnisse verstehen, haben sie Anspruch auf Anweisungen.
02 Anordnung zur Benennung eines Teams für die Reaktion auf Sicherheitsvorfälle (GRIIB) und Anweisungen zur Reaktion
Die Abkürzung des SRIMS, obwohl etwas lächerlich, aber ziemlich offiziell, wurde von GOST R ISO / IEC TO 18044-2007 „Informationstechnologie. Sicherheitsmethoden und -werkzeuge. Incident Management für Informationssicherheit. “
Der Bedarf an Dokumenten wird durch eine Reihe von Regulierungsdokumenten gefordert. Zum Beispiel derselbe Artikel 19 des Gesetzes über personenbezogene Daten. Detaillierter ist jedoch die Reaktion auf Vorfälle in den Anordnungen des FSTEC angegeben.
FSTEC Bestellnummer 17:
18.2. Im Zuge der Identifizierung und Reaktion auf Vorfälle:
- Identifizierung von Personen, die für die Identifizierung von Vorfällen und deren Reaktion verantwortlich sind;
- Erkennung und Identifizierung von Vorfällen, einschließlich Denial-of-Service, Fehlern (Neustarts) beim Betrieb von Hardware, Software und Informationsschutz-Tools, Verstößen gegen Zugriffssteuerungsregeln, illegalen Aktionen zum Sammeln von Informationen, Einführung bösartiger Computerprogramme (Viren) und anderer Ereignisse; zu Zwischenfällen führen;
- rechtzeitige Information der Personen, die für die Identifizierung und Reaktion auf Vorfälle verantwortlich sind, über das Auftreten von Vorfällen im Informationssystem durch Benutzer und Administratoren;
- Analyse von Vorfällen, einschließlich Ermittlung der Ursachen und Ursachen von Vorfällen sowie Bewertung ihrer Folgen;
- Planung und Ergreifen von Maßnahmen zur Beseitigung von Vorfällen, einschließlich der Wiederherstellung des Informationssystems und seiner Segmente im Falle eines Denial-of-Service oder nach Ausfällen, Beseitigung der Folgen von Verstößen gegen Zugriffssteuerungsregeln, illegalen Maßnahmen zum Sammeln von Informationen, Einführung bösartiger Computerprogramme (Viren) und anderer Ereignisse zu Zwischenfällen führen;
- Planen und Ergreifen von Maßnahmen, um das Wiederauftreten von Vorfällen zu verhindern.
Dieselben Dokumente schließen eine Reihe von organisatorischen Maßnahmen ab, z. B. RSB.1 „Bestimmung der aufzuzeichnenden Sicherheitsereignisse und ihrer Speicherzeiten“ und SSB.2 „Bestimmung der Zusammensetzung und des Inhalts von Informationen über zu registrierende Sicherheitsereignisse“. All diese Dinge können in den Anweisungen zur Reaktion auf Vorfälle angegeben werden, um keine separaten Dokumente zu erstellen.
03 Benutzerhandbuch
Die wichtigste rechtliche Rechtfertigung für die Notwendigkeit einer solchen Anweisung sind alle Stellen in der Gesetzgebung, an denen es darum geht, Benutzer in Fragen der Informationssicherheit zu unterweisen. Zum Beispiel Artikel 18.1 Teil 1 des Gesetzes über personenbezogene Daten:
6) Bekanntmachung der Mitarbeiter des Betreibers, die personenbezogene Daten direkt verarbeiten, mit den Bestimmungen der Gesetzgebung der Russischen Föderation über personenbezogene Daten, einschließlich Anforderungen zum Schutz personenbezogener Daten, Dokumenten, in denen die Richtlinien des Betreibers zur Verarbeitung personenbezogener Daten definiert sind, lokalen Handlungen zur Verarbeitung personenbezogener Daten und (oder) Schulung dieser Mitarbeiter.
Eine indirekte Notwendigkeit für ein solches Dokument ist die rechtliche Registrierung der Benutzerverantwortung für mögliche Informationssicherheitsvorfälle. Wie die
Praxis zeigt , wird ein Benutzer, der gegen IS-Anforderungen verstößt, in Fällen, in denen solche Anweisungen nicht existieren und (oder) der Benutzer nicht damit vertraut ist, höchstwahrscheinlich nicht zur Rechenschaft gezogen.
Was das Dokument selbst betrifft, haben wir uns hier entschieden, Benutzer nicht mit Unsinn zu beladen, den sie nicht brauchten, um das Dokument nicht zu schwer wahrnehmbar und nützlich zu machen, nicht nur in Bezug auf die Informationssicherheit im Unternehmen, sondern auch in Bezug auf Fragen der Informationssicherheit im persönlichen Leben. Zum Beispiel beschrieben sie Methoden des Social Engineering anhand von Beispielen.
05 Informationssicherheitsrichtlinie
Wahrscheinlich eines der umfangreichsten Dokumente aus dem gesamten Set. Denken Sie daran, dass wir oben über das Dokument „Maßnahmen zum Schutz von Informationen im GIS“ und über die große Anzahl von „Regeln und Verfahren“ geschrieben haben, die in der ARD geschrieben werden müssen. Tatsächlich ist die „IB-Richtlinie“ eine Sammlung all dieser Regeln und Verfahren.
Hier lohnt es sich vielleicht, beim Wort "Politik" anzuhalten. Uns wird oft gesagt, dass unsere „Politik“ zu zielgerichtet ist, aber tatsächlich sollte ein Dokument mit diesem Namen abstrakter und hochrangiger sein. Es mag sein, aber hier als Sicherheitsleute, vor allem mit dem technischen Hintergrund, wird das Wort "Politik" beispielsweise mit Gruppenrichtlinien der Domäne verknüpft, die wiederum mit bestimmten Regeln und Einstellungen verknüpft sind.
In der Tat ist es nicht wichtig, wie ein solches Dokument genannt wird. Wenn Ihnen das Wort "Richtlinie" nicht gefällt, können Sie es in "Regeln und Verfahren für die Informationssicherheit" umbenennen. Dies ist nicht der Punkt. Die Hauptsache ist, dass genau diese Regeln und Verfahren in diesem Dokument bereits klar und spezifisch dargelegt werden sollten.
Wir werden hier genauer aufhören.
Wenn Sie ein Dokument öffnen und damit arbeiten, werden Sie feststellen, dass an einigen Stellen keine bestimmten Textlücken vorhanden sind, sondern ein trockenes „Beschreiben“. Dies liegt daran, dass einige Dinge nicht beschrieben werden können, sodass der Text gleichzeitig für mindestens die Hälfte der spezifischen Informationssysteme geeignet ist. Für jeden Fall ist es besser, diese Abschnitte separat zu beschreiben. «» .
, .
, , . , — . , , .
– , . , , , , - . . – , .
– . : .2 « (, , ), (, , ) », .4 « () , , » .
, .
. , , . . – , « » , « » , « » .
.3 « (, , , ) , , ».
, , , « ». , « » - . , .
.3 « () () ». , , .
, - . - - .
. , , .
. « 2 : , , ». , , , « , » .
10 .
( ), . , 2 19 « »:
, :
7) , ;
:
.4
. , , , .
, :
.3 , ,
06
: .2 « , , , , ».
, , , . ., . , , . , , «», , .
07 ...
2 – . 2 , .
: « , , , , ?». , – . , , , - . .
– , . , 1 18.1 « »:
1. … , , :
4) () , , , ;
08-14 ...
08-10 . :
- , , . .;
- (, , , . .);
- (, HDD, ).
. . , . , - . , , , 09 10 .
, . . .
, . . , , . .
01
, . , 17- « , ». , , , « ».
, .
02-03
. , , .
, , .
– , , .
04
17- , ( ) .
01
, , . , , . , . , - .
02
3 « » . , , , . . , .
, , , ( , ). .
03
, . , . , , , (, ). , .
04
! : « ?».
2 18.1 « »:
, , . , - , - , , , - .
, , . , , , .
05-06
, . : , , . , .
07
- , , , .
. . — , – . , , , , .
, . :
1. , ( — ), (), , , , , , .
2. , .
, . « » :
4) — ;
. , – , ( – ).
08
, , , , . , , . . .
09
. . , , . .
10
, . , 4 9 « ».
11
, , . - . , . , — , , .
12
, ( , ).
13
. – . , .
, . , , . ( 2001 ), - , , . , .
Fazit
Wir hoffen, dass dieser kleine Leitfaden zur internen Dokumentation zur Informationssicherheit hilfreich sein wird. Vielleicht wurde es etwas chaotisch geschrieben, da das Thema wirklich umfangreich ist und ich das Thema nicht in mehrere Teile aufteilen wollte. Wenn wir etwas verpasst haben und Fragen zum Thema haben, werden wir diese in den Kommentaren beantworten. Und natürlich ist die Hauptsache nicht zu vergessen, dass die in den Dokumenten deklarierten und beschriebenen tatsächlich ausgeführt werden müssen, dann werden die Dokumente kein nutzloser Müll "zur Schau" sein.