El V SOC Forum, el mayor evento sobre la práctica de detectar y analizar incidentes en Rusia, comenzará mañana. Estoy seguro de que muchos lectores de este centro estarán allí y escucharán muchos informes profesionales en esta área de seguridad de la información. Pero además de los términos, definiciones y práctica establecida, que se cubre en el Foro SOC, en la vida real, cada uno de ustedes probablemente escuchó muchas opiniones diferentes sobre el funcionamiento del SOC, la protección contra los ataques APT, etc. Hoy discutiremos varios mitos y leyendas populares.
Estamos interesados en su opinión sobre cada uno de ellos, por lo que esperamos sus comentarios. Bienvenido a cat.
Mito 1: SOC en una cadena, o la magia de analizar el tráfico de red
Muy a menudo, cuando hablamos con el cliente sobre la protección integral contra intrusos externos, escuchamos: "Y tenemos hardware A, está enriquecido por la experiencia y la información del proveedor sobre nuevas amenazas, y nos protege completamente de ataques externos". Y está bien, si después de estas palabras se nos mostrara una solución Anti-APT de varios módulos, habría preguntas, pero habría muchas menos. Muy a menudo, detrás de este "dispositivo universal" hay un IDS ordinario, a veces con una funcionalidad básica para analizar el tráfico https. No cuestionamos la experiencia de los proveedores en el campo de la ciberseguridad y su conocimiento sobre las actividades de los piratas informáticos, así como la utilidad de registrar y analizar el tráfico de la red (este tema se planteará repetidamente en el Foro), pero queremos centrarnos en las limitaciones del enfoque, con que SOC se enfoca solo en eventos de red.
- Comencemos con la base y algunas ya maltratadas. Desde 2013, hemos estado observando ataques de piratas informáticos realizados sin el uso de malware como tal, y al menos sin un módulo para interactuar con el servidor de administración. A los atacantes les llegan herramientas legítimas de administración remota (Herramientas de acceso remoto), que con el archivo de configuración correcto se comportan de manera indistinguible de los usuarios que les gusta trabajar desde casa, o el trabajo de administradores remotos en empresas con un bajo nivel de madurez de TI. A nivel de eventos de red, es simplemente imposible distinguir una sesión de otra, y para un análisis completo del método y las razones para comenzar una sesión, se necesita información de los sistemas finales.
- Si la idea de RAT es desagradable para el atacante o no son aplicables en un caso de ataque específico, el protocolo https viene al rescate como una forma de interacción. En una copia del tráfico, el descifrado del protocolo no es posible, por lo que el sensor debe contentarse únicamente con información sobre los encabezados de los paquetes. Esto solo es útil cuando el centro de control está en un área específica y puede calcularse por IP. Pero más a menudo estamos hablando de grandes servicios de alojamiento o servicios públicos (escribimos sobre hackear páginas de Wordpress anteriormente ), lo que no nos permite identificar dónde está la conexión legítima y dónde está la comprometida.
- A pesar de su utilidad, las conexiones de red (y generalmente hablamos de una pieza de hierro en el área del perímetro) registran solo la relación entre el centro de control y la cadena superior de clientes bot. A menudo, los atacantes actuales usan una cadena de servidores proxy de C&C (el primer nivel de captura de infraestructura) para comunicarse con los clientes de bot internos. En este punto, las restricciones en la ubicación del equipo no detectan completamente el ataque.
- Con toda la variedad de acciones de un atacante, periódicamente no necesita venir de Internet. Es posible comprometer una cuenta de acceso remoto y luego trabajar bajo los derechos legítimos de un administrador o usuario. Cada vez más, los grupos están utilizando la metodología de la cadena de suministro, comenzando un ataque pirateando a un contratista, que a menudo tiene un canal estático y mal controlado para la infraestructura y las mismas cuentas privilegiadas. Cada año hay más y más vectores, y están cada vez más lejos de los remedios clásicos.
- En general, SOC no se trata solo de contrarrestar a los hackers. Los atacantes internos, la violación de las políticas de IS o el fraude, la descarga o el compromiso de los datos del cliente, y mucho más, también son parte de un enfoque integral de SOC. Y requiere técnicas y herramientas mucho más complejas en su trabajo.
Mito 2: SOC sin piernas, o trabajo sin la primera línea
Una de nuestras leyendas favoritas. Bromas sobre SOC, donde solo 1 persona trabaja, por lo que es un poco primero, una segunda segunda y una tercera tercera línea de soporte, ya inundó Internet. Pero muchos clientes, después de escuchar muchos informes diferentes y haber leído artículos, comienzan a hablar sobre la necesidad de una pieza mágica de hierro / procedimiento / tecnología (subrayar según sea necesario) que automatizará y resolverá todos los problemas de la primera línea. Y dado que a menudo en la cabeza del cliente, la primera línea es equivalente al modo de operación 24 * 7 (todos los demás, por regla general, funcionan de acuerdo con el cronograma estándar), esto crea automáticamente la sensación de una reducción significativa en los costos de personal y genera conversaciones en la clave "La primera línea no necesario, comencemos a construir de inmediato con el segundo ".
El problema clave de esta leyenda, en nuestra opinión, es la confusión en la terminología. A menudo, cuando el orador habla sobre la primera línea, se guía por las prácticas de ITIL, donde las tareas atómicas realmente caen en manos de los operadores:
- recepción de tareas
- clasificación
- Agregar contexto (activo o sistema de información)
- priorización o priorización
- Nombramiento a la persona responsable del sistema / examen / cola.
Cuando se trata de este tipo de tareas, por supuesto, no se necesita una primera línea dedicada: estos procesos, aunque no son fáciles, están completamente automatizados. Lo que queremos decir con la primera línea, ya lo hemos escrito varias veces, por ejemplo
aquí ). Aún así, la primera línea no es un sustituto de la automatización, y ni siquiera un equipo que trabaja exclusivamente en un libro de jugadas. Estos empleados son curiosos y buscan, aunque solo tienen habilidades básicas para analizar eventos e investigar incidentes. En términos de ITIL, dicha línea se llamaría 2da, lo que elimina de inmediato todas las preguntas y discrepancias.
No quisiera ignorar las preguntas 24 * 7. Sobre la organización del turno, la eficiencia de los operadores y analistas en la noche, la ceguera psicológica al ver eventos, se ha dicho demasiado. Las conclusiones integrales son aproximadamente las mismas: la primera línea SOC y un turno las 24 horas se vuelven ineficientes e innecesarios. Por nuestra parte, durante muchos años también hemos probado diferentes métodos, y en este momento, el nivel federal de SOC nos permite minimizar los riesgos de fatiga especializada durante el turno nocturno (un incidente crítico simplemente se envía a una zona horaria diferente), sin embargo, me gustaría señalar algunos puntos.
- Reducir los tiempos de turno para el operador es una muy buena idea. Trabajar según el principio del deber de TI durante un día o tres en seguridad de la información es bastante imposible. Sin embargo, mantener el foco en los incidentes es muy importante ...
- PERO ... el operador de la primera línea no se sienta, como el operador de la película "The Matrix", mirando el flujo de eventos sin procesar en busca de anomalías. Al menos en ningún SOC conocido por nosotros hemos encontrado tal enfoque. Su trabajo es analizar informes y cazas regulares, o resolver escenarios para identificar incidentes. En este modo de cambiar la atención y los tipos de actividad (con el equilibrio correcto de números en la línea), los riesgos de ceguera psicológica rápida nos parecen mínimos.
Y en conclusión: no importa cuán lejos haya llegado la automatización, es costumbre dejar a un especialista que supervise la situación con máquinas y robots en cualquier sitio de producción crítico. Y si su bifurcación en este caso es "puede la automatización ayudarme a no asignar 5-6 tasas para el turno de turno", entonces nuestra respuesta es inequívoca: no puede.
Mito 3: SOC perfecto sin un solo descanso, o Trabajamos sin falsos positivos
Cuanto más construya SOC o trabaje con un proveedor de MSSP / MDR, más querrá el ideal. Ahora, muchos clientes pasaron por tuberías de fuego, agua y cobre de los primeros enfoques independientes del proyectil o pilotos / contratos con proveedores externos y todos están tratando de luchar de alguna manera por el ideal. Y el ideal a los ojos del jefe / persona responsable del servicio externo generalmente se expresa con la frase "cada alerta es un incidente confirmado" o "no estamos monitoreando sospechas, estamos registrando ataques". Y en términos de aspectos clave de la eficiencia, es difícil discutir esa afirmación. Pero, como siempre, el diablo está en los detalles.
La mayoría de los SOC están dirigidos a un análisis eficiente y tan profundo del incidente como sea posible en toda la información disponible. Y se acercan cada vez más a la perfección, cuando tienen la oportunidad de recibir registros de
conchas para ella. Examinemos un ejemplo de un incidente sobre los hechos del funcionamiento de los indicadores de red del software de virus (la dirección de comunicación con el centro de control): para identificarlos, solo necesita información sobre los flujos de red a Internet, por ejemplo, registros de firewall, pero a menudo dan un resultado falso. Es suficiente que el atacante oculte su servidor de gestión de malware en el alojamiento, y automáticamente encontraremos una gran cantidad de falsos positivos. Para un filtrado y análisis efectivo del incidente, es necesario localizar la actividad en el host iniciador (procesos activados, sockets abiertos, etc.). Y esto nos lleva a la necesidad de conectar eventos de todos los hosts en la red.
Total: para que el SOC se acerque a la posibilidad de identificar ataques exclusivamente, sin falsos positivos, debemos garantizar la máxima cobertura de monitoreo de la infraestructura, idealmente, para recolectar TODOS los registros de TODOS los objetos.
Esto nos lleva a varios problemas a la vez.
- La oposición real de los departamentos de TI a elevar el nivel de auditoría o la instalación de sistemas adicionales para la recolección (para evitar el mal, ni siquiera tocaremos el tema de conectar segmentos ACS y tecnólogos). Las pruebas de compatibilidad, un aumento impredecible de la carga en los sistemas y otros factores que pueden afectar la disponibilidad general de la infraestructura son los factores desencadenantes de la próxima ronda de la guerra entre TI y la seguridad de la información. Y la mayoría de las veces simplemente dejan grandes puntos blancos en el mapa de monitoreo de infraestructura del SOC.
- Mantener una cobertura total. No es posible recopilar todos los registros de todos los servidores. Por ejemplo, en sistemas nuevos, los registros simplemente no se pueden incluir. A menudo, en el proceso de cambio de servidores, la configuración de auditoría en las estaciones de trabajo y las restricciones de acceso se pierden parcial o completamente. Además, la configuración debe actualizarse a medida que aparecen nuevos vectores de ataque. Todo esto crea costos operativos para proporcionar una cobertura completa, significativamente mayores que los riesgos de una revisión incompleta por monitoreo, y ciertamente mayores que los costos de una posible respuesta falsa positiva.
- El tercer problema nos lleva al viejo juego DOOM. Porque, entre otras cosas, la cobertura completa requiere que ingrese códigos.
a. IDKFA: munición completa en forma de capacidades infinitas de servidores para recopilar y almacenar eventos y, lo que es mucho más triste desde un punto de vista económico, licencias ilimitadas para SIEM y otras herramientas de SOC.
b. IDDQD es un equipo SOC enorme e inmortal que en cada incidente podrá analizar todas sus características obvias e indirectas.
La coincidencia de tales factores, tareas y la cantidad de presupuestos para la seguridad de la información se considera el caso de una reunión del elefante verde y, por lo tanto, no se considera una situación típica en la vida de SOC. Entonces, identificar solo los ataques confirmados (con todo el deseo de analizar lo más profundamente posible con herramientas automáticas) es un pequeño sueño fantástico de los guardias de seguridad modernos.
En lugar de un epílogo
Tratamos de discutir solo los mitos más comunes de la industria de construcción de SOC. Por lo tanto, en aguas estancadas complejas del inicio de procesos para monitorear y responder a incidentes, le recomendamos que se muestre escéptico sobre la información entrante, la verifique en diferentes fuentes y maximice el temor a la
falsificación de juicios no confirmados.
Y que la Fuerza te acompañe;).