Hoy hablaremos sobre el Centro de Operaciones de Seguridad (SOC) de personas que no lo crean y configuran, pero que comprueban cómo lo hicieron otros. Se verifica la efectividad del SOC creado para su empresa de forma independiente o por alguien externo. El cheque responde a la pregunta "¿Cumple el SOC las tareas que se le asignaron o no, y qué tan efectivo es?". Después de todo, la presencia de SOC no significa que funcione como debería y usted es consciente de cualquier posible incidente y otros problemas de seguridad. Hablaremos sobre nuestra experiencia en la verificación de SOC en diferentes compañías dentro de nuestros proyectos.



Para aquellos que ya saben qué es SOC y con qué está borracho, les sugerimos que pasen inmediatamente a la segunda parte del artículo. El resto está invitado a leer el artículo completo.

Parte 1. Un poco sobre SOC para principiantes

La protección de los sistemas de información es lo primero en casi cualquier industria. Cualquier acceso no autorizado a la información puede generar serios problemas para la empresa.

El sistema de información de cualquiera, incluso la empresa más pequeña, es complejo, y todas sus partes deben protegerse de acuerdo con el mismo principio: primero las medidas organizativas, luego las preventivas, luego las herramientas de vigilancia que detectan anomalías y las herramientas de respuesta. Las personas se encuentran en la última etapa, pero no menos importante, de combatir las amenazas, aunque sucede que un problema de seguridad puede resolverse sin involucrar a las personas, por ejemplo, bloqueando automáticamente los puertos o desconectando una máquina de una red compartida. Las herramientas utilizadas para proteger cada uno de los componentes del sistema pueden variar de una compañía a otra, pero existe una tendencia general: gradualmente, las empresas, independientemente de su tamaño, tienen la idea de introducir SOC - Security Operation Center.

Hay varias razones para esto:

• El uso de SOC reduce el costo de rastrear manualmente los incidentes de seguridad
• los eventos del sistema se reúnen en un solo lugar, es menos probable que alguno de ellos se pierda;
• SOC le permite configurar reglas para clasificar eventos como incidentes de seguridad de acuerdo con las necesidades y características de una empresa en particular;
• SOC le permite minimizar el tiempo de detección y respuesta a incidentes de seguridad, reduciendo así el daño potencial a la empresa;
• Los registros que caen en el SOC tienen un solo aspecto, lo que le permite investigar eficazmente los incidentes de seguridad, incluso si un atacante intenta detectar los rastros de su presencia en el sistema.

SOC es una infraestructura con muchos componentes interconectados, su base es SIEM (información de seguridad y gestión de eventos). SIEM es un sistema de recopilación, normalización y correlación de datos que recopila registros de servidores web, máquinas host y otros componentes de infraestructura, así como herramientas de seguridad de la información instaladas en dispositivos de la red de la organización, las correlaciona y procesa para que vuelvan a la normalidad. Esta es la tarea principal de SIEM: traer una gran cantidad de registros de diferentes fuentes a un solo formato para la conveniencia de detectar las relaciones entre ellos. Esto es necesario para otro componente de SOC: los analistas de SOC que, mirando las enormes listas de registros de SIEM, deben responder a algunos de los eventos por su cuenta o transferirlos al trabajo de especialistas en seguridad.

No hay dos SOC idénticos porque su configuración es individual para cada organización. Las principales etapas de la creación de SOC son las siguientes:

• definiendo una infraestructura protegida, tanto organizativa como técnicamente;
• instalación de todos los medios de protección y monitoreo posibles / necesarios, así como su configuración;
• selección de un SIEM adecuado y su ajuste en función de las características de la empresa;
• crear reglas de correlación de eventos;
• selección del equipo de SOC: personas cuyo trabajo será monitorear eventos y hacer correcciones a las reglas de correlación, así como responder a eventos de seguridad.

Incluso después de que todo esté definido, instalado y configurado, nadie puede garantizar que SOC ahora funcione como quisiera o como se muestra en hermosas presentaciones de los desarrolladores de SIEM. El problema fundamental con el uso de cualquier medio de protección es que prácticamente nadie sabe qué tan efectivamente funcionan. Es importante no solo instalarlos y ejecutarlos, sino también asegurarse de que las medidas tomadas sean efectivas. El nivel de madurez de la empresa en materia de seguridad también es extremadamente importante.

Dado que SOC es una estructura compleja y de múltiples componentes, es importante comprender que en cada una de las etapas enumeradas de su creación, algo puede salir mal. Y es probable que esto afecte la seguridad general del sistema y la eficiencia del SOC en sí.

Parte 2. ¿Qué sucede si no verifica la efectividad del SOC, pero deja todo como está?

Para empezar, algo puede salir mal, incluso con el más mínimo cambio en la infraestructura de la organización. Y suceden con bastante frecuencia: alguien se va, viene gente nueva, algo se rompe, el hardware y el software se actualizan y mucho más. En este caso, la configuración del SPI y las reglas de correlación deben cambiarse rápidamente, pero a menudo se olvidan y, cuando lo recuerdan, es demasiado tarde.



La siguiente parte del SOC donde pueden ocurrir errores es el medio de protección desde el cual la información ingresa al SIEM, puede configurarse incorrectamente y omitir acciones dirigidas al sistema desde el exterior. Y si la acción del atacante no es detectada por ninguno de los SZI existentes, entonces no entrará en los registros y no estará en SIEM, y lo más probable es que el servicio de seguridad no lo sepa pronto.



El problema puede estar en SIEM . Puede que no funcione como te gustaría. Los eventos que caen en él pueden correlacionarse incorrectamente debido a errores en las reglas de correlación, lo que conducirá a omitir las acciones del atacante. Vale la pena aclarar aquí que no siempre hay suficientes datos de una fuente. Hay casos en que, para determinar incidentes de seguridad, es necesario combinar datos de varias fuentes a la vez para obtener una imagen completa de lo que está sucediendo en el sistema. Pero puede resultar que la regla esté configurada de modo que para determinar qué sucedió, el incidente puede no tener suficientes datos de una fuente, lo que indica el hecho de su finalización. Es decir un rompecabezas que consiste en datos de varias fuentes no funcionará. Además, las reglas para algunos eventos de seguridad pueden no existir en absoluto.

En la etapa de correlación de eventos en SIEM, pueden surgir varios problemas a la vez. Uno de ellos puede ser un retraso en la transmisión de eventos desde algunas fuentes, lo que puede interferir con una correlación exitosa.

Es posible que las reglas para clasificar eventos como incidentes en SIEM no estén configuradas correctamente por sí mismas o que no estén disponibles para ningún evento. Además, los incidentes suelen tener un nivel de gravedad que, si no se identifica correctamente, puede generar grandes problemas.



Las personas que trabajan con SIEM, cuyo trabajo es responder a incidentes de seguridad, también pueden causar ataques perdidos y problemas posteriores de seguridad de la información. Pueden perder algunas señales de SIEM o reaccionar incorrectamente a las acciones del atacante por varias razones. También existe el problema de que las personas dejarán de fumar tarde o temprano, y los nuevos empleados necesitan tiempo para capacitarse.

Dado lo anterior, las pruebas de SOC para verificar el rendimiento son extremadamente importantes tanto en la etapa de implementación de SOC como a lo largo del tiempo. Dado que los especialistas de nuestra empresa ya tienen experiencia en este asunto, decidimos describir los principales puntos y matices.

Parte 3. Verificación de la efectividad de SOC

Las pruebas de SOC en una empresa se pueden realizar en varios escenarios. Hablemos de los que nos parecen más efectivos.

Las tareas de prueba de SOC incluyen pruebas de seguridad al reproducir escenarios de comportamiento típicos inherentes a los cibercriminales. Estos incluyen:

• iterando a través de las cuentas de otros usuarios utilizando la fuerza bruta, así como utilizando la técnica de rociado de contraseña. Es posible utilizar esta técnica si tiene acceso a la lista de cuentas existentes en el sistema, por ejemplo, a través de la libreta de direcciones del cliente de correo. En nuestra experiencia, las técnicas de rociado de contraseñas a menudo se olvidan y, en consecuencia, las reglas de SOC apenas pueden detectar dicho ataque;
• bombear datos de un recurso web, ya sea un wiki corporativo o un administrador de tareas. Tal ataque puede llevarse a cabo incluyendo el uso de varios mecanismos de rastreo web y mecanismos brutos de directorio. Por separado, los auditores prestan atención a los servicios API y sus capacidades;
• intentos repetidos de acceder a recursos o proyectos que están fuera de la competencia del rol en nombre del cual trabaja el atacante. Un ejemplo simple son los intentos de autorizar a un usuario de un grupo de desarrolladores sobre los recursos de los administradores de red y los servicios de seguridad;
• Intenta descargar una gran cantidad de información de la red corporativa utilizando técnicas de filtrado de derivación. Se trata principalmente de túneles dns e icmp, pero a veces tiene sentido comenzar con comprobaciones más simples, por ejemplo, intente buscar un puerto tcp o udp abierto afuera, así como una puerta de enlace adicional. Para buscar pasarelas, por cierto, hay una implementación revisada de una herramienta popular de uno de los empleados.

Se puede continuar una lista similar de verificaciones durante mucho tiempo. Es muy importante guiarse por las necesidades reales del cliente y los controles implementados por él.

La prueba de SOC se puede hacer de dos maneras:

• a ciegas - caja negra;
• con conocimiento de infraestructura - whitebox.

Más detalles sobre cada uno de ellos.

En primer lugar, debe verificar el funcionamiento de SOC en el modo de prueba de blackbox. Su esencia es que los empleados del departamento de SOC no son conscientes del trabajo que se está llevando a cabo y reaccionan a todos los eventos en modo de combate. Los auditores / pentesters tienen acceso a la red corporativa, y las cuentas también se pueden dar desde los servicios más utilizados en la empresa.

Tal modelo supone que un atacante que no tiene información adicional obtuvo acceso a la red de la compañía y a cualquiera de las cuentas existentes de una manera desconocida. Las acciones de tal atacante se caracterizan por un alto grado de aleatoriedad y "ruido". Analiza activamente la red, itera sobre directorios, cuentas, envía todos los exploits que conoce a todos los puertos, lanza aplicaciones web XSS, SQLi, RCE, SSTI, NoSQLi, etc. con vectores. En general, se comporta de manera extremadamente agresiva con la esperanza de piratear al menos algo. Durante la auditoría, los auditores imitan las acciones de dicho atacante, manteniendo un cierto grado de locura, pero están listos para detenerse en cualquier momento a solicitud del servicio SOC o si surgen problemas técnicos. Por cierto, un resultado inesperado y agradable puede ser el descubrimiento de servicios y aplicaciones vulnerables en la infraestructura de la compañía.

Otro modelo de prueba es whitebox. En este caso, se resuelve el escenario de un empleado sin escrúpulos. Por lo general, en este punto, los auditores están bien versados ​​en la red del cliente y pueden desempeñar ese papel. El comportamiento de un atacante potencial en este caso puede caracterizarse por la alta selectividad tanto de los medios como de los objetivos del ataque. Aquí ya es posible establecer algunos paralelos con los ataques APT . Los auditores atacan solo los lugares más débiles en su opinión y usan vectores de ataque bien pensados ​​y estrechamente dirigidos, y también intentan acceder a información confidencial fuera de la competencia de su rol de cuenta con el posterior intento de extraerla del perímetro seguro. Intentan realizar todas las acciones de manera tal que el servicio de seguridad de la empresa no lo note.

Después de las pruebas, generalmente comienza el análisis y la comparación de los resultados obtenidos por los auditores y los incidentes detectados por los empleados de SOC. Esta etapa proporcionará una imagen general de la efectividad del trabajo actual de SOC y puede servir como punto de partida para todos los planes adicionales para expandir los controles y enfoques existentes.

Finalmente, cuando se compila una idea de la seguridad de la infraestructura probada, los auditores pueden usar la prueba de caja blanca para analizar el conjunto de reglas existente, así como los eventos en función de los cuales se forman estas reglas. Esta interacción entre auditores y analistas de SOC puede ser muy productiva, y durante la consulta ayudará a identificar errores lógicos y omisiones en la configuración de los componentes de SOC. Su raíz suele ser la falta de comprensión por parte de los analistas de SOC de cómo puede actuar un verdadero atacante y qué trucos puede realizar en los sistemas.

Conclusión

Los servicios más críticos que merecen más atención se prueban por separado utilizando dos modelos de intrusos.

Un conjunto similar de medidas le permite:

• aumentar significativamente la conciencia de los gerentes de seguridad sobre el estado de su infraestructura;
• realizar ejercicios militares para el departamento de SOC con la oportunidad de obtener asesoramiento de expertos en el campo de la auditoría;
• detectar y corregir errores existentes en el trabajo de SOC, así como en general aumentar la seguridad de la empresa.

Por su ayuda para escribir este artículo, agradezco a Denis _ttffdd_ Rybin e Ivan Chalykin .