Respuesta ante incidentes: ¿Puede dar algunos ejemplos de incidentes / tipos de incidentes que sean adecuados para una respuesta total o parcial automatizada? [cerrado]

3

Configura la supervisión de seguridad, ya sea un SIEM / SOC comercial completo o algo casero (por ejemplo, rsyslog - > OSSIM / MozDef / Splunk / ...). También configura algunas reglas para que se realice una clasificación de eventos, y solo recibe alertas para incidentes potenciales.

Me gustaría saber qué automatización se está haciendo más allá de este punto. No solo más alertas / envíos de correos electrónicos o informes, sino algo que intenta resolver el incidente en sí.

Algunos casos de uso y algunos ejemplos de soluciones de automatización (ya sean estándar o de bricolaje) serían útiles.

    
pregunta Sas3 16.06.2017 - 18:35
fuente

2 respuestas

3

De la parte superior de mi cabeza no diría nada. El objetivo de un SoC / SIEM es llamar la atención de un analista humano para evaluar el incidente y decidir qué acciones realizar a continuación. Cualquier cosa que no desees que un humano vea "los ojos puestos" debe ser sintonizado fuera del conjunto de reglas de SIEM.

Puede haber ciertas cosas de bajo riesgo que desee automatizar, por ejemplo, cada vez que se produce un AV con el malware puesto en cuarentena o eliminado, se genera un ticket para volver a escanear la caja mientras el analista realiza la investigación inicial, pero Típicamente esto no sería hecho por el SIEM. (Aunque algunos SIEM tendrán esta capacidad y algunos SoC utilizarán un SIEM para hacer esto).

Por lo general, un SoC maduro tendrá un libro de jugadas para alertas comunes que no están sintonizadas. Por ejemplo, si x sucede, haga a , b , c y luego pase a un analista de nivel dos para obtener más información. investigación. Esto se trata más de tener un procedimiento operativo estándar que de automatización.

    
respondido por el TheJulyPlot 19.06.2017 - 09:14
fuente
3

Las respuestas activas, como descartar e ignorar solicitudes, son el único tipo de respuesta automatizada en la que he participado.

Cualquier IPS comercial o Web Application Firewall hace esto. HIDS / HIPS también puede considerarse, para implementaciones extremadamente pequeñas.

Las reglas WAF simples pueden bloquear al atacante por un tiempo limitado si:

  • Si el User-Agent es wget o curl o una automatización similar
  • Si alguien intenta un exploit conocido, específico y bien definido
  • Si alguien intenta una categoría de vulnerabilidad bien definida: recorrido de directorios, inyección de SQL,

El WAF puede ajustarse para incluir bloques para cosas como:

  • solicitudes de páginas que indican una tecnología que no tiene (por ejemplo, aspx)
  • solicitudes de páginas administrativas comunes /admin.php

Los IPSes también pueden hacer esto, pero son menos precisos en sus firmas, ya que tienden a no proporcionar información sobre el protocolo http, sino paquetes sin procesar. Esto les da algunas habilidades adicionales, como la detección de ataques en el WAF o el propio proxy, o ataques no HTTP / HTTPs.

Este tipo de respuestas normalmente se limitan a firmas de alta confianza. Los proveedores comerciales tienden a incluir factores de confianza en su información de firma y le permiten limitar los bloques en consecuencia.

Snort, McAfee Intrushield, IBM SiteProtector son IPSes que he usado para esto. El ASM de F5 que he usado para las respuestas de WAF. fail2ban, OSSSEC, en el lado de HIDS.

enlace

enlace

Los bloques automatizados se revisan a diario y se monitorean en tiempo real. El riesgo de una firma impactando en la producción es muy real. Las firmas se implementan en un ciclo Dev / Stage / Prod para que las nuevas firmas no lleguen a producción sin un ciclo de prueba completo.

    
respondido por el mgjk 19.06.2017 - 11:22
fuente

Lea otras preguntas en las etiquetas