Si trabaja para una empresa que se encuentra bajo la acción del número 187-FZ ("Sobre la seguridad de la infraestructura de información crítica de la Federación de Rusia"), no necesita explicar qué es GosSOPKA y por qué es necesario. Por lo demás, explicamos: GosSOPKA significa sistema estatal para detectar, prevenir y eliminar las consecuencias de los ataques informáticos. Arquitectónicamente, es un complejo único de centros geográficamente distribuidos de varios tamaños, que intercambian información sobre ciberataques. Se requiere que dichos centros creen todas las compañías que poseen los objetos de infraestructura de información crítica (tales compañías se llaman sujetos de CII). El objetivo de esta iniciativa gubernamental a gran escala es crear un sistema de intercambio de información entre las organizaciones más importantes del país sobre los ciberataques en curso y, por lo tanto, ofrecer la posibilidad de protección preventiva.
Durante bastante tiempo, el documento principal que definió los principios de funcionamiento de los centros GosSOPKA y su interacción con un centro superior fueron las "Recomendaciones metodológicas para la creación y operación de los centros GosSOPKA" desarrolladas por el FSB. Anteriormente
revisamos este documento y notamos que el foco principal de su atención fue la construcción de procesos para la gestión de incidentes y el control de seguridad de los sujetos de GosSOPKA. Pero al mismo tiempo, este enfoque dejó un campo bastante amplio para diferentes interpretaciones de cuántas tareas debe resolver el centro GosSOPKA y qué herramientas específicas se requieren para esto. Recientemente, "Requisitos para herramientas diseñadas para detectar, prevenir y eliminar las consecuencias de los ataques informáticos y para responder a incidentes informáticos". Intentemos averiguar qué espera el regulador de las compañías que construyen los centros GosSOPKA por su cuenta, e investigar este problema.
Jerarquía de interacción de centros.Existen intentos conocidos de construir centros GosSOPKA exclusivamente en sistemas IDS. También hay vendedores en el mercado que posicionan IDS o SOA como una solución universal al problema. Los sujetos de KII tenían muchas preguntas sobre la funcionalidad y los requisitos para los sistemas SIEM, que muchas compañías consideraron casi la única herramienta necesaria para crear un centro GosSOPKA.
Ahora, con el advenimiento del documento "Requisitos para herramientas diseñadas para detectar, prevenir y eliminar las consecuencias de ataques informáticos y responder a incidentes informáticos", aparece la primera claridad con respecto a los requisitos reales del regulador para las herramientas del centro.
El documento describe cinco subsistemas principales del centro GosSOPKA:
- Herramientas de detección
- Advertencia significa
- Herramientas de liquidación
- Herramientas de descifrado (PACA)
- Herramientas de intercambio de información
- Medios de protección criptográfica de los canales de comunicación.
Intentemos revisar cada uno de los elementos secuencialmente. Haremos una reserva de inmediato para que no consideremos los problemas de "ortodoxia" del producto y la necesidad de sustitución de importaciones, nos centraremos exclusivamente en aspectos técnicos.
Herramientas de detección, pero no SOA. Cuatro letras
En nuestra opinión, este elemento es uno de los más importantes desde el punto de vista de la resolución de disputas sobre los medios que se pueden utilizar, ya que las discusiones "¿Necesita SIEM, o simplemente subsistemas suficientes de SOA" están en curso y no disminuyen.
Leamos el documento con más detalle:
En primer lugar, estamos hablando de una herramienta que recopila eventos de seguridad de la información. No incidentes (los resultados del trabajo del equipo de protección), ni tráfico en bruto o su copia, es decir, eventos. Esto nos da una pista bastante transparente de que necesitamos la funcionalidad de procesamiento de registros.
La nota a este párrafo también proporciona una lista bastante detallada y amplia de posibles fuentes que deberían dar estos eventos. La lista incluye no solo medios de protección clásicos (firewalls, SOA, antivirus), sino también fuentes de infraestructura (equipos de red y sistemas operativos), así como sistemas de gestión de aplicaciones para equipos de red, sistemas de monitoreo de calidad de servicio, etc.
Todo esto, así como las palabras "correlación y agregación de eventos" mencionadas en los requisitos funcionales, en nuestra opinión, definen con bastante precisión la tecnología objetivo del elemento como
la plataforma SIEM .
Esto sigue completamente las recomendaciones metodológicas emitidas anteriormente, porque para detectar completamente los incidentes informáticos de las categorías de "acceso no autorizado", "adivinación de contraseña" y "malware", un medio de protección activo no será suficiente.
¿Alguna plataforma comercializada como SIEM será igualmente adecuada? En nuestra opinión, no, ya que al menos dos requisitos bastante importantes se indican en el texto:
- El sistema de detección no solo debe correlacionar y detectar incidentes, sino también guardar los resultados de su procesamiento e “información sobre eventos de SI, incluso en su forma original”. Teniendo en cuenta la lista de fuentes indicada anteriormente, así como la profundidad de almacenamiento recomendada (al menos 6 meses), estamos hablando de una plataforma completa con funcionalidad avanzada de administración de registros y disposición para manejar flujos de eventos muy significativos. Esto reduce en gran medida la lista de posibles opciones.
- El sistema de detección debe tener "soporte integrado para varias fuentes de eventos de seguridad de la información y la capacidad de desarrollar módulos adicionales que brinden información de nuevas fuentes de eventos de seguridad de la información", es decir, la capacidad de refinar rápidamente la lista y la composición de las fuentes conectadas. Esto impone requisitos sobre la disponibilidad de una API abierta para el desarrollo de dichos métodos de conexión (en la jerga SIEM - conectores) o la capacidad de obtener rápidamente dicho refinamiento del proveedor.
Integralmente, estos requisitos demuestran una actitud muy seria del regulador hacia la funcionalidad del sistema de detección. En mi opinión, indirectamente dejan en claro que la ejecución formal de las recomendaciones metodológicas (por ejemplo, "el tráfico de red puede detectar incidentes de malware, no necesitamos un antivirus" o "solo necesitamos conectar dos fuentes para cumplir con los requisitos") es poco probable que tengan el derecho a la existencia Se requerirá un estudio serio del modelo de amenaza y trabajar en la configuración de escenarios de monitoreo.
Advertir o inventariar
La siguiente sección, medios de advertencia, es mucho más cercana y comprensible para el guardia de seguridad, tanto en términos como en enfoques. Las siguientes funciones se asignan a los medios de advertencia:
- Inventario de activos de infraestructura con la capacidad de almacenar y complementar información.
- Recopilación y evaluación de información sobre vulnerabilidades de recursos de información.
- Recopilación y evaluación de información sobre deficiencias (en nuestra lectura - errores de configuración) de recursos de información.
La lista de funciones descrita se implementa con mayor frecuencia mediante productos de software de la clase Vulnerability Scanner o escáneres de seguridad. Parece que el nombre no obvio "sistema de advertencia" lleva una lógica muy correcta: es imposible evitar un vector de ataque potencial e identificar puntos débiles de la infraestructura si no tiene información completa sobre su condición, los nodos utilizados, el software o las vulnerabilidades de proceso de sus activos.
La tarea de administrar activos y vulnerabilidades, con toda su aparente simplicidad, está plagada de una gran cantidad de dificultades. Pero una discusión de estos detalles no es parte del material actual y puede aparecer en nuestros futuros artículos. Solo quiero señalar que casi todas las empresas están equipadas con las herramientas necesarias para resolver el problema, ya que requisitos similares ya han aparecido en diferentes órdenes y órdenes de la FSTEC, e incluso en la ley de datos personales. La tarea clave es "revivir" una herramienta existente e iniciar procesos en la realidad, y no en papel.
Eliminación como eliminación colaborativa
Aquí, tanto el nombre del producto como los requisitos para él recibieron una interpretación bastante inesperada. Como medio de eliminación, tenemos una solución que tiene una función cercana a la plataforma de gestión de incidentes, que en el mundo de TI se llama la mesa de servicio, y el IS se enorgullece de referirse a la Plataforma de respuesta a incidentes (aunque IRP también tiene una funcionalidad especializada). De hecho, las tareas principales del subsistema son:
- Registro de incidentes con la capacidad de editar y complementar la tarjeta de incidentes.
- La capacidad de gestionar su ciclo de vida con la transferencia del incidente entre el responsable y las unidades.
- La capacidad de recoger la tarjeta de incidente final de acuerdo con los formatos aprobados por el SCCC.
En base a esto, también se construye la correspondencia de lo funcional con el nombre del sistema. La liquidación de un incidente requiere principalmente la interacción de diferentes departamentos de la empresa, y la gestión del proceso de liquidación, controlando su oportunidad y exhaustividad en este caso, se destaca. Por lo tanto, el centro GosSOPKA, como responsable de este proceso, debe tener las herramientas adecuadas.
La elección de soluciones y tecnologías creadas específicamente para tareas de IS en el mercado aún es muy limitada. Pero el documento no contiene restricciones directas sobre el uso para este propósito de un sistema informático común (en diseño estándar o individual) con algunas modificaciones para las tareas de IS. Por lo general, los sistemas de mesa de servicio son un constructor bien personalizable, por lo que la revisión no debería ser difícil.
Otras instalaciones del centro.
Las funciones y tareas del subsistema PACA tienen como objetivo principal analizar el tráfico de la red, tanto en modo en tiempo real (para detectar ataques o intentos de acceso no autorizado al equipo de la red) como para registrar y almacenar el tráfico de la red con miras a su uso posterior en retrospectiva. análisis de eventos o investigación del incidente. Estos requisitos no son fundamentalmente nuevos. La tarea de registrar el tráfico de red se ha establecido ante todos los propietarios de sistemas de información estatales desde 2010 como parte de una
orden conjunta
del FSTEC y el FSB. Estos requisitos pueden ser inesperados para las empresas comerciales, pero de hecho su implementación tampoco es particularmente difícil.
Los requisitos para los subsistemas de intercambio y la protección criptográfica de los canales de comunicación también son bastante familiares y, probablemente, no requieren explicaciones adicionales.
Como breve resumen, el lanzamiento de este documento ha puesto muchos puntos sobre I con respecto a las herramientas y tecnologías que necesitan equipar el centro de GosSOPKA. Ahora cada cliente tiene una lista formal de requisitos, que es útil tanto para comparar proveedores como para decidir sobre la compra / reemplazo de tecnología. Y la apariencia de claridad en tales asuntos siempre afecta positivamente la eficiencia y la velocidad de los pasos dados por actores específicos para conectarse, así como la seguridad general de las infraestructuras críticas de información.