Get best of the week

Seguridad de la información Plataforma automatizada de respuesta a incidentes

Imagine un centro de situación típico para la seguridad de la información en una gran empresa. En un mundo ideal, el software detecta actividad sospechosa, y el equipo de "hackers blancos" comienza a tocar el teclado. Y esto sucede una vez al mes.

En el mundo real, estos son cientos de falsos positivos y personal de soporte cansado. Se ven obligados a lidiar con cada incidente cuando el usuario ha olvidado la contraseña, no puede descargar el juego desde un torrent, otra película porno en formato * .exe, ver las fallas de la red y generalmente investigar muchas situaciones.

Los sistemas SIEM ayudan a organizar y correlacionar eventos de fuentes. Y generan aspectos positivos, cada uno de los cuales debe tratarse. De estos "todos", la mayoría son falsos. Puede abordar el problema por otro lado, con secuencias de comandos para el procesamiento de alarmas. Cada vez que algo funciona, sería bueno tener no solo la causa de la alarma, y ​​luego subir a cuatro o cinco sistemas para obtener datos diferentes, e inmediatamente recopilar automáticamente todo el diagnóstico.



Hicimos tal complemento, y ayudó mucho a reducir la carga en los operadores. Debido a que los scripts para recopilar información se inician de inmediato, y si hay acciones típicas, se toman de inmediato. Es decir, si inicia el sistema "en tal situación, hacemos esto y aquello", entonces la tarjeta se abrirá para el operador con la situación ya resuelta.

¿Qué hay de malo con los sistemas SIEM?


La lista de compensaciones está muy sobrecargada con datos sin procesar. Una tarjeta de incidente específica para el llenado se transfiere a nuestra plataforma.

Los casos típicos tienen diagramas de flujo de reacción de muestra.

Aquí, por ejemplo, informes de análisis de datos sobre errores de autenticación de usuarios:



Hay criterios para falsos positivos: por ejemplo, lo intenté dos veces; entré desde el tercero. El usuario acaba de recibir una carta que dice que la contraseña debe escribirse con cuidado, el ticket se cierra. Si lo intentó cinco o seis veces, entonces la información detallada ya está comenzando a reunirse: lo que sucedió después, lo que sucedió antes, y así sucesivamente. Si inició sesión por décima vez, y luego fue a la base de conocimiento y comenzó a descargar 10 archivos, entonces puede haber una configuración para "bloquear el acceso a la base de conocimiento hasta el final del procedimiento y notificar al operador". Lo más probable es que si el usuario no es malicioso, en este caso, el departamento de TI recibirá automáticamente un correo electrónico con los detalles. Quizás le enseñarán al usuario a ingresar la contraseña correctamente o ayudarán a cambiarla.

Si la actividad es más peligrosa, el nivel "abrió el archivo ejecutable en el correo y luego algo comenzó a arrastrarse en la Web", entonces un segmento completo o subred puede bloquearse automáticamente. Sí, SIEM puede hacer esto por sí solo, pero sin ajustes, tal vez, tales medidas son el límite de la automatización.

Nuevamente, en un mundo ideal, el operador tiene acceso a todos los sistemas e inmediatamente sabe qué hacer. En el mundo real, a menudo necesita encontrar a alguien responsable para aclarar algo. Y él también está de vacaciones o en una reunión. Por lo tanto, otra parte importante: en el diagrama de flujo de reacción debe ser inmediatamente responsable de secciones específicas de sistemas y departamentos. Es decir, no necesita buscar el teléfono celular del empleado, el nombre de su jefe y su teléfono, sino verlos inmediatamente en una tarjeta abierta.

Qué hemos hecho


  1. , (), - .
  2. , ( ), , .
  3. , -. : , , .
  4. , .
  5. .
  6. ( , , ).
  7. .
  8. GUI -.

Uno de nuestros principales clientes es SIEM QRadar. Un buen sistema de identificación de amenazas, hay acciones y pasos para cada incidente, pero al mismo tiempo, no se puede proporcionar una lista de trabajo para un operador humano. Cuando se trata de una superclase profesional, esto no es necesario. Cuando se trata del operador de la primera línea, es muy importante darle instrucciones sobre qué y cómo hacer, y podrá cubrir la mayoría de los incidentes típicos a nivel de un especialista genial.

Es decir, llevamos todos los eventos obviamente aburridos a la primera línea y agregamos criterios a los guiones que separan los aburridos de los aburridos. Todo lo atípico, como antes, recae en los profesionales.

Como resultado, se resolvieron y prescribieron casos para empresas de varias decenas de miles de lugares de trabajo y con sus capacidades de servidor en varios centros de datos durante aproximadamente un año (existen relaciones difíciles entre departamentos, lo que dificulta la integración en diferentes sistemas). Pero ahora cualquier subtarea en la tarjeta tiene una persona específica a cargo, y siempre es relevante.

La simplicidad para los operadores se puede juzgar por el hecho de que después de la implementación, el sistema se implementó primero en regiones y luego, después de un par de semanas, se comenzó a enviar documentación oficial. Entonces, durante este tiempo, la gente ya ha comenzado a cerrar incidentes con confianza.

¿Cómo comenzó?


Hay SIEM, pero no está claro qué sucede constantemente. Más precisamente, QRadar genera muchos eventos, caen en el departamento de seguridad de la información y simplemente no hay manos para desmontar todo correctamente y en detalle. Como resultado, los informes simplemente se ven superficialmente. El beneficio de SIEM con este enfoque no es muy alto.

Hay un sistema de gestión de activos.

Hay servidores para escanear la red, muy bien configurados.

El informe iba a ser excelente, pero lo miraron con cansancio y lo pospusieron.

El cliente quería lo que compraba para comenzar a producir resultados.

Pusimos el escritorio de servicio para los guardias de seguridad en la parte superior (en realidad, un sistema de tickets, como en el soporte normal), visualizamos el análisis de datos y escribimos la plataforma de automatización descrita sobre la base de las reacciones típicas agregadas de IBM Resilient +. Resistente viene desnudo, es solo un marco. Tomamos las reglas de correlación de QRadar como base y finalizamos los planes de respuesta para casos de usuarios.



Durante varios meses hicieron la rusificación de todo y colgaron los paquetes correctos por API. Tan pronto como terminamos, el vendedor emitió la rusificación, y estábamos un poco tristes.

Aproximadamente un mes se capacitaron y conocieron la documentación (en particular, cómo dibujar nuevos diagramas de flujo para tarjetas). Cuanto más aprendieron, los casos más simples se volvieron: al principio se escribieron enormes guiones de acciones, y luego resultó que se convirtieron en una especie de biblioteca de casos típicos. Y uno podría referirse a ellos en casi cualquier reacción.

Comparación de reacciones


Incidente "Infección de virus repetida con el mismo malware en un corto período de tiempo". Es decir, el virus se detecta en las estaciones de trabajo, pero se necesita personal para entender de dónde proviene. La fuente de infección es activa.

Clásico:

  1. Hubo una infección viral repetida del host 192.168.10.5 con el mismo malware durante un corto período de tiempo, los eventos se enviaron a SIEM y la regla correspondiente funcionó.
  2. .
  3. .
  4. .
  5. .
  6. /CMDB-.
  7. .
  8. - , .
  9. / .
  10. Service Desk .
  11. Completa una aplicación en el sistema Service Desk en función de los resultados de una investigación para eliminar la vulnerabilidad debido a la cual este host estaba infectado.
  12. Espera a que se cierren las aplicaciones de Service Desk y luego verifica su ejecución.
  13. Completa una tarjeta de incidente y cierra el incidente.
  14. Informa a la gerencia sobre los resultados de su trabajo.
  15. El analista recopila estadísticas de incidentes para analizar la efectividad del proceso de respuesta.

En nuestra plataforma:

  1. Hubo una infección viral repetida del host 192.168.10.5 con el mismo malware en un corto período de tiempo, los eventos se enviaron a SIEM y la regla correspondiente funcionó.
  2. El operador mira la tarjeta de incidentes, en la que ya se ha descargado información sobre este host, el estado de la herramienta de protección antivirus y sus registros, vulnerabilidades en el host, incidentes relacionados y las personas responsables de este host.
  3. , : , , Service Desk , - .
  4. Service Desk , .
  5. .
  6. .




Se hizo un poco más rápido. Pero lo principal no es esto, sino que es posible clasificar las tareas en "el operador de primera línea se encargará" y "necesidades especiales". Es decir, en promedio, la solución para cada boleto se ha vuelto significativamente más barata y el sistema es más escalable.



Además de muchos falsos positivos, hubo muchos duplicados que resultaron convenientes para ser detectados por el sistema.



Las tarjetas no se ven como un conjunto de datos oscuros de un informe, sino como "Vasya hizo esto y aquello en un host. Esto es malo. El anfitrión es responsable de Petya. Eso es exactamente lo que pasó. Tenemos que ir a Petya y decir que la computadora de Vasya desde el área de trabajo no se puede usar para mostrar presentaciones en conferencias ".

Otra cosa importante en todo esto es que, en función de la recopilación de datos primarios, es posible priorizar los tickets. Es decir, las principales amenazas potenciales aparecen y requieren atención inmediata, y no en una cola en vivo.

La automatización en la interfaz con los tickets de TI hizo posible no solo recopilar toda la información sobre el incidente, sino también colocar tickets de inmediato en el departamento de TI. Si necesita cambiar algunas configuraciones en el enrutador, ahora se genera automáticamente un ticket de TI, por ejemplo. Sorprendentemente, comenzaron a surgir casos "se olvidó de cambiar la cuenta en el servicio y está tratando de conectarse durante un mes". TI no ve tales situaciones ni ignora la infraestructura. Y aquí dice el IS: el servicio no puede iniciar sesión. Y pusieron un boleto.

Gracias a la tipificación de las tarjetas de reacción, los incidentes comenzaron a resolverse mediante métodos estándar. Anteriormente, cada uno se decidía de manera creativa: diferentes personas realizaban diferentes acciones.

El resultado es un flujo de trabajo tan bueno como en el CRM moderno. El incidente pasa por un embudo. Otro problema se resolvió en la última etapa: las personas anteriores a veces cerraban el boleto simplemente porque estaba cansado. Es decir, el resultado fue mal prescrito. Y ahora necesita demostrarle al sistema que esto es un falso positivo. Es decir, puede cerrarlo, como antes, pero está claro que, quién y bajo qué condiciones lo hizo, y es mucho más fácil abrir las jambas. No solo "el usuario no pudo ejecutar el archivo", sino que "trajo el juego a la unidad flash USB, quiso instalarlo, explicaron las reglas de la vida una vez más". Y ya está claro lo que pasó.

Versatilidad


Ahora hay un par de integraciones en la producción (una es muy grande con QRadar y un sistema de gestión de activos, otra es más pequeña). Es posible conectarse con cualquier SIEM utilizando API estándar, pero, por supuesto, la integración requiere tiempo para los conectores, el refinamiento de archivos y la escritura de reglas de reacción para las personas. Sin embargo, ayuda mucho responder realmente a los incidentes de seguridad y hacerlo de manera relativamente rápida y relativamente económica. Es probable que en 10 años los sistemas SIEM puedan hacerlo, pero hasta ahora nuestro complemento se ha mostrado bien.

Si desea sentirlo con nosotros o discutir cómo se vería con usted, aquí está mi correo AAMatveev@technoserv.com.

More articles:


All Articles