Guide de documentation interne sur la sécurité de l'information. Quoi, comment et pourquoi

Dans l'un de nos précédents articles, nous avons abordé la question de la constitution d'un ensemble de documents pour les examinateurs sur la protection des données personnelles. Nous avons donné un lien vers nos modèles de documents , mais nous nous sommes concentrés sur le sujet de la documentation sur la sécurité de l'information de manière très superficielle.

Dans cet article, je souhaite aborder ce sujet plus en détail tant dans le contexte des données personnelles en particulier que de la protection des informations en général. Quels documents doivent être avec l'opérateur, qui sont facultatifs. D'où vient la demande pour tel ou tel document. Quoi écrire dans les documents et ce qui n'en vaut pas la peine. Sous la coupe beaucoup de lettres sur ce sujet.

Quelques mots pour défendre la sécurité "papier"

Étant donné que l'article se concentrera sur la sécurité dite «papier», je voudrais immédiatement exposer notre position sur cette partie de la sécurité de l'information.

Pour de nombreux techniciens travaillant avec des «mains», cette sécurité «papier» provoque souvent un rejet brutal et une négligence. Cependant, curieusement, lorsqu'un tel technicien met à sa disposition un nouveau matériel ou logiciel (et parfois les deux dans un seul produit), il veut d'abord se familiariser avec la documentation de ce miracle de la technologie.

La justification la plus courante d'une telle position méprisante est que tous ces documents sont faits juste pour montrer afin de se conformer aux exigences de la loi, c'est une perte de temps, les documents doivent être pris en charge, mais personne ne le fera, etc., etc.

Malheureusement, cette position n'est pas sans fondement. Au fil des ans, tant parmi les agents de sécurité locaux que parmi les titulaires de licence, les intégrateurs et les autres parties intéressées, la triste pratique de la même attitude à l'égard des documents de sécurité de l'information s'est développée. En conséquence, un cercle vicieux a été établi - les documents sont rendus inutiles parce qu'ils sont négligés, et à leur tour sont négligés parce qu'ils sont inutiles.

Cela est en partie aggravé par le fait que souvent les documents de sécurité de l'information sont rédigés par des personnes qui sont loin des technologies de l'information. Après tout, comment puis-je écrire une section sur la protection des outils de virtualisation sans comprendre comment cette virtualisation fonctionne?

Pour inverser cette situation, il est nécessaire de produire des documents bons, informatifs et utiles. Dans le même temps, ces documents doivent être conformes à la législation applicable en matière de protection des informations. Voyons ce qui peut être fait avec tout cela.

Quelques clarifications

Pour commencer, afin d'éliminer les questions et les conjectures inutiles, nous estimons nécessaire de clarifier quelques points.

1. Dans l'article, nous ne considérerons que les documents internes d'organisation et d'administration (ci-après dénommés «ARD») pour la protection des informations. La conception, la certification et les autres documents ne seront pas pris en compte.
2. Nous ne considérerons pas non plus le modèle de menace, bien que son modèle soit ici . Le développement d'un modèle de menace est une autre histoire. Écrivez dans les commentaires - avez-vous besoin d'un manuel sur le développement d'un modèle de menace sur Habré?
3. L'article s'appuiera sur notre ensemble de modèles. Ce n'est pas une sorte d'ensemble standard ou généralement accepté. Cet ensemble reflète notre approche purement au développement de l'ARD. Étant donné que la législation ne prescrit souvent rien de spécifique à cet égard, vous pouvez avoir votre propre opinion sur l'exhaustivité et le contenu des documents et c'est normal!
4. Il peut y avoir des erreurs et des fautes de frappe dans les modèles. Nous les améliorons et les affinons constamment.
5. Dans le cadre du respect des exigences, les sujets des données personnelles (152- et statuts) et des systèmes d'information étatiques (17 arrêté du FSTEC) seront principalement concernés. De plus, il y a une autre histoire avec les organisations financières (exigences de la Banque centrale de la Fédération de Russie) et diverses normes (ISO 2700x et autres) - nous ne les examinerons pas ici.

Exhaustivité des documents

Si vous comptez sur la législation pour protéger les informations, il n'y a pas grand-chose à dire où exactement quels documents nous devons développer, nous devons donc nous fier à divers indices indirects.

Par exemple, nous donnons la partie 2 de l'article 19 de la loi n ° 152-FZ "Sur les données personnelles". Le texte brut sera le texte de la loi, en italique - les notes de l’auteur.

2. La sécurité des données personnelles est atteinte, en particulier:

1) la détermination des menaces à la sécurité des données personnelles lors de leur traitement dans les systèmes d'information sur les données personnelles; (besoin d'un modèle de menace)

2) l'application de mesures organisationnelles et techniques pour garantir la sécurité des données à caractère personnel lors de leur traitement dans les systèmes d'information sur les données à caractère personnel nécessaires pour satisfaire aux exigences de protection des données à caractère personnel, dont la mise en œuvre garantit les niveaux de sécurité des données à caractère personnel établis par le gouvernement de la Fédération de Russie; (les mesures organisationnelles sont pour la plupart nos documents, plus ici ils nous envoient pour lire d'autres règlements)

3) en utilisant les procédures d'évaluation de la conformité des installations de protection des informations qui ont réussi de la manière prescrite;

4) évaluation de l'efficacité des mesures prises pour assurer la sécurité des données personnelles avant la mise en service du système d'information sur les données personnelles;

5) la prise en compte des supports machines de données personnelles; (évidemment, vous avez besoin d'une sorte de journal comptable et de règles développées pour la comptabilité des supports de machine)

6) la découverte d'un accès non autorisé aux données personnelles et l'adoption de mesures; (il est nécessaire d'élaborer certaines règles pour détecter les incidents et éliminer leurs conséquences, il peut être nécessaire de nommer une équipe de réponse aux incidents)

7) restauration de données personnelles modifiées ou détruites en raison d'un accès non autorisé à celles-ci; (des règles de sauvegarde et de restauration sont nécessaires)

8) l'établissement de règles d'accès aux données personnelles traitées dans le système d'information sur les données personnelles, ainsi que l'enregistrement et l'enregistrement de toutes les actions effectuées avec des données personnelles dans le système d'information sur les données personnelles; (le développement d'un système d'accès aux données peut se faire sur la base des rôles dans le système, seul le logiciel lui-même devrait être capable de conserver des journaux de qui a utilisé pour accéder à quelles données)

9) contrôle des mesures prises pour assurer la sécurité des données personnelles et le niveau de sécurité des systèmes d'information sur les données personnelles. (nous avons besoin d'un certain plan de suivi périodique, plus, probablement, d'un journal dans lequel les résultats de ce suivi seront enregistrés)

Avec cet exemple, nous avons voulu montrer la différence: comment la loi est écrite et ce qu'elle exige de nous. Ici, nous ne voyons pas l'exigence directe «l'opérateur doit développer un modèle de menace», mais ce besoin découle toujours du texte de 152-FZ, car la satisfaction de toute exigence est documentée.

Plus précisément, le FSTEC nous renseigne sur l'exhaustivité et le contenu de l'ARD. En 2014, ce régulateur a publié un document méthodologique, Mesures de sécurité de l'information dans les systèmes d'information de l'État. Un document sans sarcasme est excellent, si vous n'avez pas compris quelque chose dans l'ordre de mise en œuvre des mesures des 17e, 21e ou autres ordres du FSTEC (oui, bien que le document soit destiné au SIG, mais les mesures coïncident pour la plupart avec le FSTEC), référez-vous à ceci le document peut devenir beaucoup plus clair.

Ainsi, dans ce document, le FSTEC décrit plus en détail les mesures visant à garantir la sécurité des informations et très souvent, vous pouvez trouver un tel texte:

Les règles et procédures d'identification et d'authentification des utilisateurs sont réglementées dans les documents organisationnels et administratifs de protection des informations. (IAF.1)

Les règles et procédures de gestion des comptes utilisateurs sont réglementées dans les documents organisationnels et administratifs de l'opérateur pour protéger les informations. (UPD.1)

Les règles et procédures de gestion des flux d'informations sont réglementées dans les documents organisationnels et administratifs de l'opérateur pour la protection des informations. (UPD.3)

Eh bien, quelque chose déjà, mais ces règles et procédures sont un tout.

En conséquence, j'ai dû me bâillonner avec une plaque qui a écrit toutes les exigences de tous les documents et a pris des notes et des notes sur l'accomplissement, la non-exécution.



L'idée principale de cette section est qu'il existe une montagne d'exigences dans la législation sur la protection des informations, la mise en œuvre de bon nombre d'entre elles doit être documentée. Que ce soit pour créer un document séparé pour chaque exigence ou pour tout fusionner en une seule "politique SI", c'est à chacun de décider. Toutes les choses supplémentaires que nous devons enregistrer dans les documents non pas selon les exigences, mais sur la base de la nécessité pratique, sont ajoutées sans aucun problème.

Soit dit en passant, dans le tableau et dans les documents eux-mêmes, certaines sections ou paragraphes sont étiquetés «K1» ou «K2 +». Cela signifie qu'une section ou un paragraphe n'est nécessaire que pour les systèmes d'information de classe 2 et supérieure ou pour la première (classe maximale). Tout ce qui n'est pas marqué est effectué dans tous les systèmes d'information d'État et ISPD.

Il est également évident que, par exemple, certaines sections ou même des documents entiers peuvent être supprimés si les caractéristiques structurelles et fonctionnelles du système d'information ou d'autres conditions initiales l'exigent. Par exemple, nous supprimons la surveillance vidéo, si ce n'est pas le cas. Ou nous supprimons toutes les sections liées à la protection des outils de virtualisation, si elle n'est pas appliquée.

Nos modèles sont divisés en 4 dossiers:

Général - documents qui doivent être développés pour tous les systèmes (le cas échéant), que ce soit ISPDn, SIG, système de contrôle de processus automatisé ou objet KII.

Seulement SIG - documents pour les systèmes d'information de l'État ou les systèmes d'information municipaux, seuls les documents uniques sont nécessaires pour le SIG et le SIG.

PD - documents sur la protection des données personnelles et conformément à la législation sur la protection des données personnelles. Si, par exemple, nous avons un SIG dans lequel les données personnelles sont traitées, nous devons créer des documents à partir de tous les dossiers.

CIPF - des documents liés à l'utilisation d'outils cryptographiques, nécessaires à la mise en œuvre des documents réglementaires du FSB, sont développés pour tous les systèmes qui utilisent des moyens cryptographiques certifiés de protection des informations.

Examinons plus en détail les documents, d'où ils proviennent et quelles exigences ils remplissent.

Général

01 Ordonnance de nomination des personnes responsables et instructions à ces personnes

Cette commande désigne: la personne chargée d'organiser le traitement des données personnelles et l'administrateur de la sécurité.

La nécessité de désigner le premier est prévue par l'article 18.1 de la loi fédérale:

1. L'exploitant doit prendre des mesures ... Ces mesures peuvent comprendre, sans s'y limiter:

1) la nomination par l'opérateur, qui est une personne morale, de la personne chargée d'organiser le traitement des données personnelles;

Administrateur de la sécurité - le besoin de cet ami est dû, par exemple, à l'article 9 de l'arrêté n ° 17 du FSTEC:

Pour assurer la protection des informations contenues dans le système d'information, l'opérateur nomme l'unité structurelle ou le fonctionnaire (employé) responsable de la protection des informations.

Ces personnes diffèrent en ce que le «responsable» est plus dans la partie papier, et «l'administrateur» dans la partie technique.

Pour que le responsable et l'administrateur comprennent leurs tâches et leurs pouvoirs, ils ont droit à des instructions.

02 Ordonnance sur la désignation d'une équipe de réponse aux incidents de sécurité de l'information (GRIIB) et instructions de réponse

L'abréviation du SRIMS, bien qu'un peu ridicule, mais tout à fait officielle, a été introduite par GOST R ISO / IEC TO 18044-2007 «Technologies de l'information. Méthodes et outils de sécurité. Gestion des incidents de sécurité de l'information. "

La nécessité de documents est exigée par un certain nombre de documents réglementaires. Par exemple, le même article 19 de la loi sur les données personnelles. Mais plus en détail la réponse aux incidents est divulguée dans les ordonnances du FSTEC.

Ordonnance FSTEC n ° 17:

18.2. Au cours de l'identification et de la réponse aux incidents:

• identification des personnes chargées d'identifier les incidents et d'y répondre;
• détection et identification des incidents, y compris le déni de service, les pannes (redémarrages) dans le fonctionnement du matériel, des logiciels et des outils de protection des informations, les violations des règles de contrôle d'accès, les actions illégales pour collecter des informations, l'introduction de programmes informatiques malveillants (virus) et d'autres événements, conduisant à des incidents;
• informer en temps opportun les personnes chargées d'identifier les incidents et d'y répondre, de la survenue d'incidents dans le système d'information par les utilisateurs et les administrateurs;
• l'analyse des incidents, y compris la détermination des sources et des causes des incidents, ainsi que l'évaluation de leurs conséquences;
• planifier et prendre des mesures pour éliminer les incidents, y compris la restauration du système d'information et de ses segments en cas de déni de service ou après des pannes, éliminer les conséquences de la violation des règles de contrôle d'accès, des actions illégales pour collecter des informations, introduire des programmes informatiques malveillants (virus) et d'autres événements conduisant à des incidents;
• Planifier et prendre des mesures pour prévenir la répétition des incidents.

Les mêmes documents clôturent un certain nombre de mesures organisationnelles, par exemple RSB.1 «Détermination des événements de sécurité à enregistrer et de leurs périodes de stockage» et SSB.2 «Détermination de la composition et du contenu des informations sur les événements de sécurité à enregistrer». Toutes ces choses peuvent être indiquées dans les instructions de réponse aux incidents afin de ne pas produire de documents séparés.

03 Manuel d'utilisation

La principale justification juridique de la nécessité d'une telle instruction est tous les endroits de la législation où il est question d'instruire les utilisateurs sur les questions de sécurité de l'information. Par exemple, la partie 1 de l'article 18.1 de la loi sur les données personnelles:

6) familiarisation des employés de l'opérateur traitant directement des données personnelles avec les dispositions de la législation de la Fédération de Russie sur les données personnelles, y compris les exigences pour la protection des données personnelles, les documents définissant la politique de l'opérateur concernant le traitement des données personnelles, les lois locales sur le traitement des données personnelles, et (ou) la formation de ces employés.

Un besoin indirect d'un tel document est l'enregistrement légal de la responsabilité de l'utilisateur pour d'éventuels incidents de sécurité de l'information. Comme le montre la pratique , dans les cas où de telles instructions n'existent pas et (ou) si l'utilisateur ne les connaît pas, un utilisateur qui viole les exigences du SI ne sera probablement pas tenu responsable.

En ce qui concerne le document lui-même, nous avons décidé ici de ne pas charger les utilisateurs de non-sens dont ils n'avaient pas besoin, afin de rendre le document pas trop difficile à comprendre et utile non seulement en ce qui concerne la sécurité de l'information dans l'entreprise, mais également en matière de sécurité de l'information dans la vie personnelle. Par exemple, ils ont décrit des méthodes d'ingénierie sociale avec des exemples.

05 Politique de sécurité de l'information

Probablement l'un des documents les plus volumineux de l'ensemble. Rappelez-vous ci-dessus, nous avons écrit sur le document «Mesures pour protéger les informations dans le SIG» et sur le grand nombre de «règles et procédures» qui doivent être écrites dans l'ARD? En fait, la «Politique de l'IB» est, en fait, un ensemble de toutes ces règles et procédures.

Ici, peut-être vaut-il la peine de s'arrêter au mot «politique». On nous dit souvent que notre «politique» est trop ciblée, mais en fait, un document portant ce nom devrait être plus abstrait et de haut niveau. C'est peut-être le cas, mais ici, en tant que responsables de la sécurité, tout d'abord, avec le contexte technique, le mot «politique» est associé, par exemple, aux stratégies de groupe du domaine, qui à son tour est associé à des règles et des paramètres spécifiques.

En fait, le nom d'un tel document n'est pas important. Si vous n'aimez pas le mot «politique», vous pouvez le renommer «règles et procédures pour la sécurité de l'information». Ce n'est pas l'essentiel. L'essentiel est que ces règles et procédures mêmes soient déjà clairement et spécifiquement énoncées dans ce document.

Nous nous arrêterons ici plus en détail.

Si vous ouvrez un document et commencez à travailler avec lui, vous remarquerez qu'à certains endroits, il n'y a pas de blancs de texte spécifiques, mais à la place il y a un "Décrire" sec. En effet, certaines choses ne peuvent pas être décrites de sorte que le texte soit adapté à au moins la moitié des systèmes d'information spécifiques en même temps. Pour chaque cas, il est préférable de décrire ces sections séparément. C'est pourquoi nous restons sceptiques quant aux différents remplisseurs automatiques de documents.

Dans le texte principal, tout devrait être clair dans son ensemble, je voudrais m'attarder un peu sur les applications.

Demande de modification des listes d'utilisateurs

Une telle procédure de suivi des utilisateurs et de leurs informations d'identification dans un système très bureaucratique semble pour beaucoup, cependant, nous avons souvent rencontré des situations où cette approche a contribué à faire avancer l'enquête sur les incidents de sécurité de l'information. Par exemple, il a été nécessaire de déterminer les pouvoirs accordés initialement à l'utilisateur. Lorsque les demandes de l'application à la stratégie SI ont été augmentées, il s'est avéré qu'un compte avait une augmentation d'autorité non autorisée.

En tout état de cause, il appartient à chaque opérateur de décider de procéder ou non à une telle procédure d'enregistrement utilisateur. Ici, il vaut probablement la peine de mentionner tout de suite que ce qui est explicitement fait exactement comme décrit dans notre modèle de politique SI n'est requis par aucun acte législatif. Le modèle de document est probablement l'option la plus grave et la plus déprimante. Et puis tout le monde décide par lui-même - où desserrer les écrous et où serrer encore plus.

Règlement sur la délimitation des droits d'accès et la liste des personnes

La différenciation des droits d'accès des utilisateurs est une mesure évidente pour tout administrateur système. : .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 ), - , , . , .

Conclusion

, . , , , . - , . , , , , « ».