Certificación de sistemas de información sobre el principio de segmentos estándar. Mitos y realidad

Buen dia, Habr! Hoy nos gustaría considerar varios mitos relacionados con la certificación de objetos de informatización (OI) para los requisitos de seguridad de la información sobre el principio de los segmentos estándar. Y también descubriremos cómo hacer dicha certificación correctamente.

Hay que decir mitos sobre esto, muchos circulan y a menudo se contradicen entre sí. Por ejemplo, existe la opinión de que, de acuerdo con el principio de los segmentos estándar, puede certificar todos los ISPD en un país (aunque la certificación no es obligatoria para los ISPD), pero por otro lado, existe la opinión de que necesita certificar los sistemas de información solo a la antigua, y todos estos sus "segmentos típicos" de astuto

Introduccion

La certificación del objeto de informatización es quizás una de las etapas más reguladas y conservadoras en la construcción de un sistema de protección de la información.

El conservadurismo radica en el hecho de que la certificación está sujeta a un sistema específico con una lista específica de medios técnicos, que se reescriben cuidadosamente en el pasaporte técnico para el objeto de información y en el certificado de conformidad. Reemplazar, por ejemplo, una computadora quemada de un sistema de información certificado puede implicar al menos una larga correspondencia con la organización que realizó la certificación, y al menos pruebas de certificación adicionales (es decir, costos).

Este no fue un gran problema, mientras que la certificación de los requisitos de seguridad de la información eran computadoras independientes que procesan la información protegida o pequeñas redes de área local dedicadas.

Pero el progreso no se detiene. Ahora, para los sistemas de información estatales, el decimoséptimo decreto de la FSTEC determina su certificación obligatoria antes de la puesta en servicio. Y los sistemas de información estatales de hoy no son una computadora estática o una pequeña lokalka, sino grandes sistemas dinámicamente cambiantes, a menudo de escala regional o incluso federal.

Entonces, ¿qué hacer en este caso? Se requiere certificación, pero es imposible certificar un sistema estático, ya que casi todos los días se agregan elementos nuevos y se eliminan los antiguos. Los "segmentos típicos" vienen al rescate.

Este concepto fue introducido por la orden 17 del FSTEC y el estándar GOST RO 0043-003-2012 “Protección de la información. Certificación de objetos de informatización. Disposiciones generales ”en 2013. Desafortunadamente, GOST está marcado como "aglomerado", a diferencia del pedido FSTEC, por lo que el estándar no se puede citar aquí. Pero no se perderá nada de esto, ya que el orden del FSTEC en la orden de extender el certificado de conformidad a segmentos típicos es mucho más detallado (sección 17.3), y se dedican un par de párrafos cortos a esto en la norma.

Mitos sobre la Certificación de Segmento Tipo

Hay muchos mitos en torno a segmentos típicos. Aquí analizaremos los que nosotros mismos hemos encontrado. Si tiene ejemplos de mitos o preguntas similares (no está seguro de si esto es un mito o no), bienvenido a comentar.

Mito número 1. Un certificado sobre el principio de segmentos estándar puede certificar todos los sistemas de información en la Federación Rusa

Teóricamente, esto no está directamente prohibido por los documentos reglamentarios, pero en la práctica esto no será posible. Una de las cláusulas 17 de la orden FSTEC sobre segmentos modelo establece que la ejecución de la documentación organizativa y administrativa para la protección de la información debe garantizarse en segmentos estándar. Por lo tanto, el gran problema es el desarrollo de dicha documentación, que tendrá en cuenta diferentes procesos tecnológicos de procesamiento de información, diferente información protegida, diferentes requisitos de los reguladores, etc. Como resultado, la documentación desarrollada para un sistema no será relevante para otro.

Mito número 2. Los "segmentos típicos" se proporcionan solo para sistemas de información estatales

Esto no es asi. En primer lugar, el orden 17 del FSTEC permite que sus disposiciones se apliquen en el desarrollo de sistemas de protección de la información en cualquier otro sistema de información. En segundo lugar, GOST RO 0043-003-2012 utiliza el concepto más amplio de "objetos de información" en lugar de "sistemas de información de estado".

Mito número 3. Si nos dan un certificado que se puede extender a segmentos estándar, entonces podemos aplicarlo a cualquier cosa

Esto no es así, bajo el spoiler, el texto completo del párrafo 17.3 de la orden FSTEC No. 17 para segmentos típicos, luego consideraremos casos en los que el certificado emitido no se puede distribuir. Aquí tenemos que quedarnos con más detalle.


Además, tomaremos ejemplos específicos de errores y citaremos solo las citas apropiadas de este acto normativo como justificación de por qué esto no se puede hacer.

Ejemplo no 1

Solo la parte del servidor está certificada, pero quiero extender el certificado a las estaciones de trabajo (AWS). ¿Se puede hacer esto?



No! La certificación del sistema de información se permite sobre la base de los resultados de las pruebas de certificación de un conjunto seleccionado de segmentos del sistema de información que implementan la tecnología completa de procesamiento de información .

La transferencia de información a través de canales de comunicación también es una tecnología de procesamiento. Además, en este ejemplo, no se certifica una sola estación de trabajo, por lo que no podemos extender el certificado a otra estación de trabajo estándar.

Ejemplo no 2

Aquí tomamos en cuenta el error anterior e incluimos canales de transmisión de datos y una estación de trabajo típica en el certificado. De repente, tuvimos la necesidad de organizar una computadora portátil para un gran jefe con una conexión a un sistema certificado (a través de canales seguros, por supuesto). ¿Podemos extender el certificado de conformidad a esta computadora portátil?

No! Un segmento se considera apropiado para el segmento del sistema de información con respecto al cual se realizaron pruebas de certificación si se establecieron las mismas clases de seguridad y amenazas a la seguridad de la información para los segmentos indicados ...

Aquí, para los medios técnicos móviles, aparecen nuevas amenazas a la seguridad de la información que no son relevantes para las estaciones de trabajo estacionarias y muy probablemente no se consideran en el modelo de amenaza para un sistema certificado.

Ejemplo no 3

Bueno, tomamos en cuenta esta jamba y agregamos amenazas al modelo de crecimiento, amenazas a los dispositivos móviles. ¿Ahora puedo extender el certificado a la computadora portátil de un gran jefe?



No! Se considera que un segmento es relevante para el segmento del sistema de información para el que se han realizado pruebas de certificación ...

A pesar de que la herramienta móvil se describió en la documentación de diseño del sistema de protección de la información y el modelo de amenazas tomó en cuenta las amenazas asociadas con los medios técnicos móviles, no se realizaron pruebas de certificación para dicha herramienta.

Ejemplo no 4

¡Qué complicado es! Pero esta situación: hay una institución médica, hay dos sistemas de información: con empleados y un sistema de información médica (MIS) con pacientes. ¿Podemos guardar, certificar el sistema de información con los empleados y extender este certificado a los AII?



No! Un segmento se considera apropiado para el segmento del sistema de información con respecto al cual se realizaron pruebas de certificación si se establecieron las mismas clases de seguridad para los segmentos indicados ... las mismas soluciones de diseño para el sistema de información .



Aunque parece que todo es complicado aquí, de hecho, solo necesita pensar en las posibles opciones para segmentos típicos en preparación para construir un sistema de protección. Pero, de hecho, si tiene todo en cuenta (y no hay tantos requisitos), no habrá problemas con la distribución del certificado.

Mito número 4. Los segmentos típicos deben describirse en la documentación de diseño del sistema de protección, comenzando con el modelo de amenaza.

No hay tal requisito. Aunque esto no está directamente prohibido, este enfoque puede generar algunos problemas en el futuro. Lo que la 17ª orden FSTEC nos dice sobre esto:

Las características de la certificación de un sistema de información basado en los resultados de las pruebas de certificación de un conjunto seleccionado de sus segmentos, así como las condiciones y el procedimiento para distribuir un certificado de conformidad a otros segmentos de un sistema de información, se definen en el programa y los métodos de pruebas de certificación, conclusión y certificado de conformidad.

Es decir, tenemos derecho a mencionar segmentos típicos solo en la etapa de certificación. En este caso, sus segmentos serán típicos por defecto, si se cumplen las condiciones de la sección 17.3 de la orden FSTEC No. 17. Pero encontramos casos en los que se intentaba describir segmentos típicos ya en la etapa de modelado de amenazas, casi indicando los números de serie del equipo de dichos segmentos. El problema con este enfoque es que si ocurre un reemplazo de hardware o algo cambia en las tecnologías de procesamiento (por ejemplo, aparece un entorno de virtualización), los segmentos en los que el certificado ya está distribuido pueden volverse, digamos, ilegítimos típicos. Y en este caso, puede ser necesario llevar a cabo no "pruebas de certificación adicionales", sino realizar todo el conjunto de pruebas de acuerdo con la nueva.

En general, nuestro consejo es no mencionar segmentos típicos en la documentación de diseño. De hecho, según la legislación actual, cualquier segmento que cumpla con las condiciones establecidas será típico.

¡IMPORTANTE! Si usted es un operador de un sistema de información y planea certificar un sistema de información con la capacidad de extender el certificado a segmentos estándar, asegúrese de discutir con su organismo de certificación para que esta posibilidad se refleje en los documentos de certificación, como lo exige la orden 17 del FSTEC.

Mito número 5. FSTEC no comprende "segmentos típicos" y si estamos certificados de esta manera, seremos castigados

Este mito suena muy extraño, dado que los segmentos típicos se describen con más detalle en la documentación reglamentaria de FSTEC. Esta idea se escucha con mayor frecuencia de los guardias de seguridad de la llamada "vieja escuela".

En general, excepto por "esto no es cierto", no tenemos nada que decir aquí. Por el contrario, el regulador está promoviendo este sistema de certificación de sistemas de información de todas las formas posibles y, recientemente, incluso nos encontramos con una afirmación del FSTEC de que un enorme sistema de información a nivel regional NO estaba certificado por el principio de los segmentos estándar. Allí tuve que explicar que en ese caso particular no era óptimo.

Mito número 6. Los segmentos típicos solo funcionan cuando la parte y los segmentos certificados son propiedad de una organización

Esto no es verdad Esto no está explícitamente establecido en la legislación, pero todo lo que no está prohibido está permitido. Pero, por supuesto, hay ciertas diferencias cuando la parte certificada y los segmentos del modelo son propiedad de una organización, y cuando los segmentos del modelo pertenecen a entidades legales de terceros, existen.

En los casos en que todo pertenece a una organización, esta organización puede llevar a cabo independientemente medidas para proteger la información en un segmento estándar, nombrar una comisión y extender el certificado a un segmento estándar.

En los casos en que hay un operador central del sistema de información estatal (por ejemplo, un Centro regional de tecnología de la información) y segmentos de otras entidades jurídicas (por ejemplo, un sistema regional de gestión de documentos de instituciones estatales), entonces todo es un poco más complicado. La dificultad radica en el hecho de que, según la ley, el operador de estos SIG es responsable de la protección de la información en los sistemas de información estatales. Por lo tanto, para que la próxima prueba no caliente al operador por el hecho de que en algún lugar de la escuela, a 400 km del centro regional, no se toman medidas de protección de la información, debe documentar este proceso al menos en la etapa de conexión de un segmento típico. En primer lugar, se crean las reglas para conectarse al sistema de información, donde el operador describe clara y claramente los requisitos para la protección de la información que debe cumplirse en el segmento conectado. Esto generalmente incluye el nombramiento de los responsables, la aprobación de documentos internos para la protección de la información (especialmente los operadores confusos pueden incluso desarrollar y proporcionar un conjunto estándar), la compra, instalación y configuración de las herramientas necesarias de protección de la información, análisis de vulnerabilidad, etc. Además, la organización que desea conectarse realiza todos los requisitos y de la manera especificada en las regulaciones lo confirman.

Por otro lado, todas las dificultades descritas son un plan de acción aproximado que ya inventamos junto con uno de esos operadores. Si el operador de un SIG distribuido no tiene miedo de asumir la responsabilidad de no probar el hecho de cumplir los requisitos para proteger la información en el segmento remoto, al menos en la etapa de conexión, entonces puede seguir un camino simplificado (cómo "simplificado" también debería decidir este operador).

Desafortunadamente, algunos operadores lo hacen porque creen sinceramente en el siguiente mito.

Mito número 7. La autoridad de certificación es responsable de extender el certificado a segmentos que no cumplen con los requisitos.

Es muy importante para nosotros, como organismo de certificación, comprender los límites de nuestra responsabilidad. Dado que la ley no responde claramente a la pregunta "quién es responsable de extender el certificado a los segmentos no conformes", escribimos una carta al FSTEC.

FSTEC respondió que el organismo de certificación solo es responsable de la calidad de las pruebas de certificación. La organización-operador del sistema de información es responsable de la distribución correcta del certificado a segmentos típicos.

Mito número 8. Los segmentos típicos no nos darán nada. De todos modos, tienes que atraer a un licenciatario y pagarle dinero

Esto no es asi. Al menos en los casos en que el personal del operador del sistema de información tiene especialistas que pueden llevar a cabo todas las actividades descritas anteriormente.

Por otro lado, a menudo nos encontramos con el hecho de que se nos pide que ayudemos a conectar segmentos estándar. De todos modos, en tales segmentos, al menos, necesita elaborar documentación interna, instalar y configurar correctamente las herramientas de seguridad de la información. Además, muchos operadores de sistemas de información confían más en las conclusiones sobre la conformidad de un segmento típico escrito por una organización de terceros que en el informe del solicitante para la conexión al sistema.

Pero incluso en este caso, los segmentos típicos permiten que el operador ahorre dinero, ya que al menos no hay necesidad de desarrollar un modelo de amenaza y documentación de diseño por separado para el sistema de protección de la información para elementos conectables. Tampoco es necesario realizar pruebas de certificación a gran escala.

Mito número 9. En segmentos típicos, solo se deben usar los mismos medios técnicos (por ejemplo, computadoras con la misma placa base, el mismo procesador, la misma RAM, según el tipo, fabricante y modelo)

Este problema tampoco está claramente explicado en la legislación. En un nivel intuitivo, está claro que no se requiere el pleno cumplimiento de la plancha del segmento certificado y conectado, de lo contrario, todo esto no tiene valor. Y cuando necesitamos aclarar una pregunta similar, ¿qué hacemos? Así es, estamos escribiendo una carta al regulador. Se esperaba que FSTEC respondiera que no deberían usarse soluciones técnicas idénticas (un fabricante, un modelo, etc.) en segmentos típicos.

Para que un segmento se considere apropiado para el certificado, es necesario que se establezca la misma clase de seguridad para él, se identifiquen las mismas amenazas para la seguridad de la información y se implementen las mismas soluciones de diseño para el propio sistema y para el sistema de protección de la información. Como está escrito en el orden 17.

Mito número 10. Para cada segmento de tipo conectable, debe crear su propio modelo de amenaza.

No En el segmento típico, las mismas amenazas deberían ser relevantes como en la parte certificada del sistema de información. En consecuencia, el modelo de amenaza es uno para todo el sistema. Si se producen cambios tecnológicos significativos en el sistema de información certificado que podrían conducir a la aparición de nuevas amenazas a la seguridad de la información, es necesario revisar el modelo de amenaza general y, si es necesario, realizar pruebas de certificación adicionales del sistema en su conjunto.

Mito número 11. Los datos de los segmentos estándar adjuntos no necesitan reflejarse en el pasaporte técnico para el sistema de información

Sobre este tema, también le preguntamos al FSTEC. La respuesta es que los datos de los nuevos segmentos deben ingresarse en el pasaporte técnico. Pero si ingresar nuevos datos en la hoja de datos generales para el sistema o hacer un documento separado para el segmento depende del operador. .

. – . , .