En uno de nuestros
artículos anteriores, tocamos el tema de formar un conjunto de documentos para examinadores sobre la protección de datos personales. Dimos un enlace a nuestras
plantillas de documentos , pero nos centramos en el tema de la documentación de seguridad de la información de manera muy superficial.
En este artículo, me gustaría revelar este tema con más detalle tanto en el contexto de los datos personales en particular, como en la protección de la información en general. Qué documentos deben estar con el operador, que son opcionales. ¿De dónde viene la demanda de este o aquel documento? Qué escribir en los documentos y qué no vale la pena. Debajo del corte muchas letras sobre este tema.
Algunas palabras en defensa de la seguridad de "papel"
Dado que el artículo se centrará en la llamada seguridad "en papel", me gustaría describir de inmediato nuestra posición en esta parte de la seguridad de la información.
Para muchos técnicos que trabajan con “manos”, esta seguridad de “papel” a menudo causa un fuerte rechazo y negligencia. Sin embargo, por extraño que parezca, cuando un técnico de este tipo tiene a su disposición una nueva pieza de hardware o software (y a veces ambos en un solo producto), primero quiere familiarizarse con la documentación de este milagro de la tecnología.
La justificación más común para una posición tan despectiva es que todos estos documentos se hacen solo para mostrarlos con el fin de cumplir con los requisitos de la ley, esto es una pérdida de tiempo, los documentos deben ser respaldados, pero nadie hará esto, etc., etc.
Desafortunadamente, esta posición no es infundada. Con los años, tanto entre los guardias de seguridad locales como entre los licenciatarios, integradores y otras partes interesadas, se ha desarrollado una práctica triste de la misma manera con los documentos de seguridad de la información. Como resultado, se dibujó un círculo vicioso: los documentos se vuelven inútiles porque se descuidan y, a su vez, se descuidan porque son inútiles.
Esto se ve agravado en parte por el hecho de que a menudo los documentos de seguridad de la información están escritos por personas que están lejos de la tecnología de la información. Después de todo, ¿cómo puedo escribir una sección sobre la protección de las herramientas de virtualización sin comprender cómo funciona esta virtualización?
Para revertir esta situación, es necesario hacer documentos buenos, informativos y útiles. Al mismo tiempo, estos documentos deben cumplir con la legislación de protección de información aplicable. Veamos qué se puede hacer con todo esto.
Un par de aclaraciones
Para empezar, para eliminar preguntas y conjeturas innecesarias, consideramos necesario aclarar algunos puntos.
- En el artículo consideraremos solo los documentos internos organizativos y administrativos (en adelante, el "ARD") para la protección de la información. Diseño, certificación y otros documentos no serán considerados.
- Tampoco consideraremos el modelo de amenaza, aunque su plantilla está aquí . El desarrollo de un modelo de amenaza es otra historia. Escriba los comentarios: ¿necesita un manual sobre el desarrollo de un modelo de amenaza en Habré?
- El artículo se basará en nuestro conjunto de plantillas. No es un tipo de conjunto estándar o generalmente aceptado. Este conjunto refleja nuestro enfoque puramente para el desarrollo de la ARD. Dado que la legislación a menudo no prescribe nada específico a este respecto, puede tener su propia opinión sobre la integridad y el contenido de los documentos, ¡y esto es normal!
- Puede haber errores y errores tipográficos en las plantillas. Nosotros mismos los mejoramos y perfeccionamos constantemente.
- En el contexto del cumplimiento de los requisitos, los sujetos de datos personales (152- y reglamentos) y los sistemas de información estatales (17 orden del FSTEC) se verán afectados principalmente. Además, hay otra historia con organizaciones financieras (requisitos de la CBR) y varios estándares (ISO 2700x y otros): no los consideraremos aquí.
Integridad de los documentos
Si confía en la legislación para proteger la información, hay poco que decir dónde exactamente qué documentos debemos desarrollar, por lo que tenemos que confiar en varias sugerencias indirectas.
Por ejemplo, damos la parte 2 del artículo 19 de la ley Nº 152-FZ "Sobre datos personales". El texto sin formato será el texto de la ley, en cursiva: las notas del autor.
2. Se logra la seguridad de los datos personales, en particular:
1) la determinación de amenazas a la seguridad de los datos personales durante su procesamiento en los sistemas de información de datos personales; (necesita un modelo de amenaza)
2) la aplicación de medidas organizativas y técnicas para garantizar la seguridad de los datos personales durante su procesamiento en los sistemas de información de datos personales necesarios para cumplir con los requisitos para la protección de los datos personales, cuya implementación garantiza los niveles de seguridad de los datos personales establecidos por el Gobierno de la Federación de Rusia; (las medidas organizativas en su mayor parte son nuestros documentos, además de que aquí nos envían para leer más estatutos)
3) mediante el uso de los procedimientos para evaluar la conformidad de las instalaciones de protección de información que han pasado de la manera prescrita;
4) evaluación de la efectividad de las medidas tomadas para garantizar la seguridad de los datos personales antes de la puesta en marcha del sistema de información de datos personales;
5) teniendo en cuenta los portadores de datos personales de la máquina; (obviamente necesita algún tipo de diario de contabilidad y reglas desarrolladas para contabilizar los medios de la máquina)
6) el descubrimiento de acceso no autorizado a datos personales y la adopción de medidas; (es necesario desarrollar algunas reglas para detectar incidentes y eliminar sus consecuencias, puede ser necesario designar un equipo de respuesta a incidentes)
7) restauración de datos personales modificados o destruidos debido al acceso no autorizado a ellos; (se necesitan reglas de copia de seguridad y restauración)
8) el establecimiento de reglas para el acceso a datos personales procesados en el sistema de información de datos personales, así como el registro y registro de todas las acciones realizadas con datos personales en el sistema de información de datos personales; (el desarrollo de un sistema de acceso a los datos se puede hacer en función de los roles en el sistema, solo el software en sí mismo debería poder mantener registros de quién solía acceder a qué datos)
9) control sobre las medidas tomadas para garantizar la seguridad de los datos personales y el nivel de seguridad de los sistemas de información de datos personales. (necesitamos un cierto plan para el monitoreo periódico, más, probablemente, un diario en el que se registrarán los resultados de dicho monitoreo)
Con este ejemplo, queríamos mostrar la diferencia: cómo se redacta la ley y qué nos exige. Aquí no vemos el requisito directo "el operador debe desarrollar un modelo de amenaza", pero esta necesidad aún se desprende del texto de 152-FZ, ya que el cumplimiento de cualquier requisito está documentado.
Más específicamente, el FSTEC nos informa sobre la integridad y el contenido del ARD. En 2014, este regulador emitió un documento metodológico, Medidas de seguridad de la información en los sistemas de información estatales. Un documento sin sarcasmo es excelente, si no entendió algo en el orden de implementación de las medidas de las órdenes 17, 21 u otras del FSTEC (sí, aunque el documento está destinado a SIG, pero las medidas en su mayoría coinciden con el FSTEC), consulte esto El documento puede ser mucho más claro.
Entonces, en este documento, el FSTEC describe más ampliamente las medidas para garantizar la seguridad de la información y muy a menudo puede encontrar dicho texto:
Las normas y procedimientos para la identificación y autenticación de usuarios están regulados en los documentos organizativos y administrativos para la protección de la información. (IAF.1)
Las reglas y procedimientos para administrar las cuentas de usuario están reguladas en los documentos organizativos y administrativos del operador para proteger la información. (UPD.1)
Las normas y procedimientos para gestionar los flujos de información están regulados en los documentos organizativos y administrativos del operador para la protección de la información. (UPD.3)
Bueno, algo ya, pero estas reglas y procedimientos son un carro completo.
Como resultado, tuve que amordazarme con una placa que escribía todos los requisitos de todos los documentos e hizo notas y notas sobre el cumplimiento, el incumplimiento.
La idea principal de esta sección es que hay una gran cantidad de requisitos en la legislación sobre protección de la información, la implementación de muchos de ellos debe documentarse. Ya sea para hacer un documento separado para cada requisito o para fusionar todo en una gran "Política de IS" depende de todos. Todas las cosas adicionales que necesitamos registrar en los documentos no de acuerdo con los requisitos, sino sobre la base de la necesidad práctica, se agregan sin ningún problema.
Por cierto, tenga en cuenta que en la tabla y en los documentos mismos, algunas secciones o párrafos están etiquetados como "K1" o "K2 +". Esto significa que una sección o párrafo es necesario solo para sistemas de información de clase 2 y superiores o para la primera (clase máxima). Todo lo que no está marcado se realiza en todos los sistemas de información de estado e ISPD.
También es obvio que, por ejemplo, algunas secciones o incluso documentos completos pueden eliminarse si las características estructurales y funcionales del sistema de información u otras condiciones iniciales lo requieren. Por ejemplo, eliminamos la provisión de video vigilancia, si no es así. O eliminamos todas las secciones relacionadas con la protección de las herramientas de virtualización, si no se aplica.
Nuestras plantillas se dividen en 4 carpetas:
General : documentos que deben desarrollarse para todos los sistemas (según corresponda), ya sea ISPDn, GIS, sistema de control de proceso automatizado u objeto KII.
Solo GIS : documentos para sistemas de información estatales o sistemas de información municipales, solo se necesitan documentos únicos para GIS y MIS.
PD : documentos sobre la protección de datos personales y de conformidad con la legislación sobre protección de datos personales. Si, por ejemplo, tenemos un SIG en el que se procesan datos personales, debemos hacer documentos de todas las carpetas.
CIPF : los documentos relacionados con el uso de herramientas criptográficas, necesarios para la implementación de los documentos reglamentarios del FSB, se desarrollan para todos los sistemas que utilizan medios criptográficos certificados de protección de la información.
Consideremos con más detalle los documentos, de dónde provienen y qué requisitos cumplen.
General
01 Orden de nombramiento de personas responsables e instrucciones para estas personas.
Esta orden designa: la persona responsable de organizar el procesamiento de datos personales y el administrador de seguridad.
La necesidad de nombrar al primero está estipulada en el artículo 18.1 de la ley federal:
1. El operador debe tomar medidas ... Dichas medidas pueden incluir, entre otras:
1) el nombramiento por parte del operador, que es una entidad legal, de la persona responsable de organizar el procesamiento de datos personales;
Administrador de seguridad: la necesidad de este amigo se debe, por ejemplo, a la cláusula 9 de la Orden FSTEC No. 17:
Para garantizar la protección de la información contenida en el sistema de información, el operador nombra a la unidad estructural o al funcionario (empleado) responsable de la protección de la información.
Estas personas difieren en que el "responsable" está más en la parte de papel y el "administrador" en la parte técnica.
Para que el responsable y el administrador comprendan sus tareas y autoridades, tienen derecho a recibir instrucciones.
02 Orden sobre la designación de un equipo de respuesta a incidentes de seguridad de la información (GRIIB) e instrucciones de respuesta
La abreviatura de los SRIMS, aunque un poco ridícula, pero bastante oficial, fue introducida por GOST R ISO / IEC TO 18044-2007 “Tecnología de la información. Métodos y herramientas de seguridad. Gestión de incidentes de seguridad de la información ".
La necesidad de documentos es requerida por varios documentos reglamentarios. Por ejemplo, el mismo artículo 19 de la Ley de Datos Personales. Pero con más detalle la respuesta a los incidentes se revela en las órdenes de la FSTEC.
Orden FSTEC No. 17:
18.2 En el curso de la identificación y respuesta a incidentes:
- identificación de personas responsables de identificar incidentes y responder a ellos;
- detección e identificación de incidentes, incluida la denegación de servicio, fallas (reinicios) en la operación de hardware, software y herramientas de protección de información, violaciones de las reglas de control de acceso, acciones ilegales para recopilar información, introducciones de programas informáticos maliciosos (virus) y otros eventos, conduciendo a incidentes;
- informar oportunamente a las personas responsables de identificar incidentes y responder a ellos, sobre la ocurrencia de incidentes en el sistema de información por parte de usuarios y administradores;
- análisis de incidentes, incluida la determinación de las fuentes y causas de los incidentes, así como la evaluación de sus consecuencias;
- planificar y tomar medidas para eliminar incidentes, incluida la restauración del sistema de información y sus segmentos en caso de denegación de servicio o después de fallas, la eliminación de las consecuencias de violar las reglas de control de acceso, acciones ilegales para recopilar información, la introducción de programas informáticos maliciosos (virus) y otros eventos conduciendo a incidentes;
- Planificación y toma de medidas para evitar la recurrencia de incidentes.
Los mismos documentos cierran una serie de medidas organizativas, por ejemplo, RSB.1 "Determinación de los eventos de seguridad que se registrarán y sus períodos de almacenamiento" y SSB.2 "Determinación de la composición y el contenido de la información sobre los eventos de seguridad que se registrarán". Todas estas cosas pueden indicarse en las instrucciones de respuesta a incidentes para no producir documentos separados.
03 manual de usuario
La principal justificación legal de la necesidad de tal instrucción es en todos los lugares de la legislación donde dice sobre instruir a los usuarios sobre temas de seguridad de la información. Por ejemplo, la Parte 1 del Artículo 18.1 de la Ley de Datos Personales:
6) familiarización de los empleados del operador que procesan directamente datos personales con las disposiciones de la legislación de la Federación de Rusia sobre datos personales, incluidos los requisitos para la protección de datos personales, documentos que definen la política del operador con respecto al procesamiento de datos personales, actos locales sobre el procesamiento de datos personales y (o) capacitación de estos empleados.
Una necesidad indirecta de dicho documento es el registro legal de la responsabilidad del usuario por posibles incidentes de seguridad de la información. Como
muestra la práctica , en los casos en que tales instrucciones no existan y (o) el usuario no esté familiarizado con ellas, lo más probable es que un usuario que viole los requisitos de IS no rinda cuentas.
En cuanto al documento en sí, aquí decidimos no cargar a los usuarios con tonterías que no necesitaban, para que el documento no sea demasiado difícil de percibir y útil no solo en relación con la seguridad de la información en la empresa, sino también en cuestiones de seguridad de la información en la vida personal. Por ejemplo, describieron métodos de ingeniería social con ejemplos.
05 Política de seguridad de la información
Probablemente uno de los documentos más voluminosos de todo el conjunto. ¿Recuerda que escribimos sobre el documento "Medidas para proteger la información en el SIG" y sobre la gran cantidad de "reglas y procedimientos" que deben escribirse en el ARD? En realidad, la "Política del IB" es, de hecho, una colección de todas esas reglas y procedimientos.
Aquí, quizás, vale la pena detenerse en la palabra "Política". A menudo se nos dice que nuestra "Política" es demasiado específica, pero en realidad un documento con ese nombre debería ser más abstracto y de alto nivel. Puede ser así, pero aquí, como personas de seguridad, en primer lugar, con los antecedentes técnicos, la palabra "Política" se asocia, por ejemplo, con las políticas de grupo del dominio, que a su vez se asocia con reglas y configuraciones específicas.
De hecho, lo que se llamará dicho documento no es importante. Si no le gusta la palabra "Política", puede cambiarle el nombre a "Reglas y procedimientos para la seguridad de la información". Este no es el punto. Lo principal es que estas mismas reglas y procedimientos ya deberían estar claramente y específicamente enunciados en este documento.
Nos detendremos aquí con más detalle.
Si abre un documento y comienza a trabajar con él, notará que en algunos lugares no hay espacios en blanco específicos de texto, sino que hay un "Describir" seco. Esto se debe a que algunas cosas no se pueden describir para que el texto sea adecuado para al menos la mitad de los sistemas de información específicos al mismo tiempo. Para cada caso, es mejor describir estas secciones por separado. Es por eso que todavía somos escépticos con respecto a varios rellenos de documentos automáticos.
En el texto principal, todo debe quedar claro en su conjunto, me gustaría detenerme un poco en las aplicaciones.
Solicitud de cambios en las listas de usuariosA muchos les parece que este procedimiento para rastrear a los usuarios y sus credenciales en un sistema que es altamente burocrático, sin embargo, a menudo nos encontramos con situaciones en las que este enfoque ayudó a avanzar en la investigación de incidentes de seguridad de la información. Por ejemplo, fue necesario establecer qué poderes se otorgaron inicialmente al usuario. Cuando se presentaron solicitudes de la aplicación a la política de IS, resultó que una cuenta tenía un aumento no autorizado de autoridad.
En cualquier caso, corresponde a cada operador decidir si se realiza o no dicho procedimiento de registro de usuario. Aquí, probablemente valga la pena mencionar de inmediato que lo que se hace explícitamente exactamente como se describe en nuestro modelo de política de SI no es requerido por ningún acto legislativo. La plantilla de documento es probablemente la opción más severa y deprimente. Y luego todos deciden por sí mismos: dónde aflojar las tuercas y dónde apretar aún más.
Reglamento sobre la delimitación de los derechos de acceso y la lista de personas.La diferenciación de los derechos de acceso de los usuarios es una medida obvia para cualquier administrador del sistema. : .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 ), - , , . , .
Conclusión
,
. , , , . - , . , , , , « ».