¿Es esta una buena manera de administrar Incidente-Respuesta

Suponiendo que este es su proceso completo, no un subconjunto donde ya se han tomado otras decisiones, sugeriría que su primer punto de decisión no es si hay una intrusión o no, sino si hay un impacto en el servicio comercial.

Alerta - > Revisar registros - > ¿Impacto en los servicios comerciales?

Una vez que haya determinado el impacto del servicio comercial, puede usarlo para dirigir el resto de la respuesta al incidente. Si su servicio se ve afectado, debe involucrar a las personas correctas en el negocio (que ya deberían estar documentadas) para notificarles el impacto, brindando una visión general del problema.

¿Impacto en los servicios empresariales? - > Sí - > Notificar al administrador de incidentes comerciales

Una vez que se notifique a la empresa, puede pasar a determinar la naturaleza exacta del problema y trabajar en el resto del flujo de su proceso.

Si no hay un impacto en el servicio de negocios, todavía se pasa a la determinación de problemas.

Impacto en los servicios empresariales - > No - > ¿Intrusión?

Mi siguiente punto sería que, incluso si el evento no es una Intrusión, aún puede ser un evento de seguridad que desee (o necesite) para realizar acciones como resultado de.

Por ejemplo, detecta algún tipo de análisis automatizado o manual de sus aplicaciones web. Puede decidir que desea bloquear la dirección IP del atacante. Este es solo un ejemplo simple.

Dicha decisión puede requerir la autorización de los representantes de negocios o tecnología apropiados, por lo que, nuevamente, los enganches necesarios para el negocio deben reflejarse en el flujo de su proceso.

En resumen, mis puntos de comentarios son:

1. No olvide que está defendiendo una aplicación empresarial, asegúrese de que el proceso de respuesta a incidentes refleje las necesidades de la empresa, no solo que detalla los pasos técnicos necesarios.

2. Una intrusión es obviamente el peor de los casos, pero no descuente las acciones requeridas para otros eventos relacionados con la seguridad. Puede que no sea simplemente una configuración errónea.

HTH !!

OSSIM tiene OSSEC. OSSEC se puede usar en elementos como las interfaces de seguridad UDF de modulación de seguridad, Wordpress y MySQL, además de la supervisión de integridad de archivos y la administración de syslog.

No entiendo la necesidad o el deseo de Splunk cuando Novell Sentinel Log Manager 25 y Q1Labs QRadar Log Manager tienen opciones que se pueden descargar libremente que son mejores, además de muchos otros proyectos de código abierto que también son mejores (especialmente por el precio). Estoy de acuerdo en que Splunk es demasiado caro.

Los principios son simples y en la línea que has descrito.

1. Registro remoto. No se retrasa el registro, sino en tiempo real. rsyslog funciona muy bien. Como perfeccionista, trato de capturar y enviar registros desde la fuente directamente, no primero a los archivos y luego los rsyslog los recoge, solo para evitar la posibilidad de intercepción entre ellos.
2. Incluir monitoreo de integridad de archivos. OSSEC es bueno en esta área, pero yo uso el mío.
3. Análisis en vivo. Uso MozDef (la plataforma de defensa de Mozilla). OSSIM era demasiado propietario y demasiado restrictivo (después de un tiempo, parecía que el único propósito de OSSIM era promover el producto pagado). Si eres un primer temporizador, prueba la imagen de la ventana acoplable. Para uso de producción, deberá comprender cómo se unen los componentes y crear una configuración personalizada para usted. Estaré encantado de ayudar si lo desea.
4. Gestión de la configuración. Sí.
5. Redistribución automatizada. ¡Espera! Como una función de DevOps, esto es genial, pero desea ser muy conservador cuando se trata de IR. Cualquier automatización necesita cubrir muchos escenarios. Hacemos esto con servidores web simples, no más que cualquier otra cosa. Eso es porque descubrimos que en la vida real, casi todos los escenarios son diferentes de lo que habíamos imaginado y preparado (sé que eso también podría significar que no estamos imaginando / preparando lo suficiente).
6. Análisis forense remoto con captura automatizada. Es agradable tenerlo, aunque sea automático o no, es discutible. Hay demasiados riesgos allí, a menos que tenga un entorno muy controlado (no he encontrado demasiados). Preferimos utilizar GRR / equivalente. La necesidad de análisis forense en vivo es infrecuente (nuestra experiencia). Para probar y configurar cada punto final (incluso solo los servidores) bajo su cuidado, esto podría estar exagerando un poco, a menos que esté administrando activos de alto valor (Bancos / Militares / ...). Así que hacemos esto de forma selectiva.