Inyectar experimentos de caos en canalizaciones de registros de seguridad

Los equipos de seguridad dependen de registros de alta calidad para la mayoría de sus esfuerzos de seguridad preventiva. Para evitar que ocurra un incidente, debe tener información detallada sobre el origen del error y los registros son una fuente importante de esa información. Cuando ocurre un incidente, las organizaciones deben poder responder y contenerlo lo más rápido posible. Los registros no solo son esenciales para encontrar el origen de un problema, sino que también ayudan a identificar las contramedidas adecuadas.

Pero, ¿qué sucede cuando una organización no tiene los datos de registro correctos? Cuando ocurre un evento desconocido o impredecible, ¿cómo podemos obtener información sobre por qué no lo vimos venir?

Considere este escenario: un lunes por la mañana, va a trabajar como ingeniero de respuesta a incidentes de seguridad. Tan pronto como ingresa a su oficina, se le informa que el departamento de recursos humanos ha perdido repentinamente el acceso al contenido, que incluye algunos datos altamente confidenciales, en sus unidades de red compartidas. Un examen más detallado muestra que todos los archivos y directorios de la unidad se han renombrado como .exe. En este punto, está casi seguro de que es el resultado de algún tipo de malware y tiene un incidente de seguridad en sus manos.

Como profesional experimentado, sabe por dónde empezar a investigar: revisa su solución de monitoreo de seguridad para ver los registros del firewall y ve que su solución de monitoreo no ha estado recopilando esos registros durante más de una semana. Al pasar a su firewall, nota que está configurado para mantener registros solo durante las últimas 48 horas. Los sigue lo más atrás posible, pero está claro que necesita registros más antiguos para obtener información significativa. ¿Qué pasa después?

En el mejor de los casos, en última instancia, puede eliminar una posible fuente del incidente mediante la recopilación de registros de todos sus dispositivos de red para encontrar otros eventos relevantes. Es un proceso que requiere mucho tiempo, pero podría ayudar a resolver el rompecabezas.

En el peor de los casos, descubre que su solución de monitoreo de seguridad no ha recibido registros de una gran cantidad de dispositivos de red en mucho tiempo, y la solución de problemas significa que tiene que esperar hasta que se apruebe su solicitud de acceso, luego inicie sesión manualmente para cada dispositivo relevante y rastrea manualmente toda la información relevante que puedas encontrar. No hay una manera fácil de girar en torno a esta información y no hay información de tendencias que observar. En tales situaciones, vale la pena recordar que no podemos cambiar el pasado y nuestro pasado suele convertirse en un prólogo.

¿Qué tan rápido usted y su equipo podrían responder al escenario descrito anteriormente? Si el flujo de registro se detiene repentinamente, ¿cuánto tiempo le tomaría a su equipo lograrlo? ¿Serían capaces de identificar rápidamente el error y corregirlo en minutos u horas? ¿Cómo lo detectarías y qué te hace creerlo objetivamente? En caso de que detecte la interrupción, ¿sabría cómo restaurar el sistema? ¿Quién sería el responsable de hacer esto? Primero, ¿cómo se construye una canalización de registro sólida?

En este artículo intentaré responder a estas preguntas.

Índice

Desafíos de automatización en DFIR (Digital Forensics & Incident Response)

Casi todas las organizaciones de seguridad de hoy en día están adoptando la automatización, aunque el grado varía según la industria y la escala de la empresa. La mayoría de las empresas de tecnología se ejecutan en una combinación de infraestructura alojada en la nube y espacio de centro de datos físico. Servicios como Suite de Google G o Microsoft Office 365, aplicaciones de recursos humanos de terceros, versiones internas o alojadas en la nube de GitHub o Bitbucket, cortafuegos, enrutadores, conmutadores y herramientas antivirus son algunos ejemplos de los tipos de infraestructura que se utilizan habitualmente. Estos componentes a menudo se necesitan para administrar una pequeña o mediana empresa en la economía digital actual; las empresas más grandes requieren pilas de tecnología más grandes.

Para un equipo de respuesta a incidentes de seguridad, hay al menos una docena de sistemas diferentes para recopilar registros, y cada uno de estos sistemas maneja el procesamiento y la transmisión de registros de manera diferente. En casos excepcionales, la recopilación de datos es tan simple como especificar el servidor de registro central/depósito al que deben ir los registros. Pero más a menudo requiere introducir una serie de agentes entre el origen del registro y el destino del registro, escribir secuencias de comandos para recuperar los registros del origen, encontrar una forma de programarlos, crear un agente para transferirlos al destino, etc. Como sugirió Lisanne Bainbridge en su trabajo de investigación hace 35 años, uno de los clásicos ironías de la automatización es que tratar de automatizar puede terminar haciendo que el sistema sea mucho más complejo que su contraparte manual. Además, el grado de automatización de un sistema depende enteramente de la creatividad e imaginación del autómata.

Obtener nuevos conocimientos con la ingeniería del caos de seguridad

Hay muchas maneras diferentes de abordar este desafío. Un lugar sólido para comenzar es comenzar a monitorear y alertar sobre las tendencias de registro. En la era de las costosas herramientas SIEM (Security Information and Event Management), es relativamente fácil configurar alertas para picos y caídas inusuales en el flujo de registros. Esto se puede hacer para cada tubería desde la cual un SIEM recibe registros. Se considera una buena práctica tener un lago de datos de registro centralizado cuyo acceso y actividad se controlen constantemente.

Para ser proactivo con respecto al estado de la canalización de registros, es importante planificar la prueba de la funcionalidad de los activadores de alerta al menos una vez al año. Sin embargo, según nuestra experiencia, las canalizaciones se prueban a medida que se implementan; después de este punto, los equipos dependen únicamente de la calidad de la alerta SIEM para informarles si una canalización está rota.

Con este caso de uso en mente, propongo un enfoque alternativo: la ingeniería del caos. Ganando popularidad rápidamente en el mundo de la ingeniería de confiabilidad del sitio (SRE), la ingeniería del caos es un enfoque empírico basado en sistemas que aborda el caos en sistemas distribuidos a gran escala y genera confianza en su capacidad para soportar condiciones realistas. El equipo aprende el comportamiento de un sistema distribuido observándolo durante un experimento controlado. En pocas palabras, la ingeniería del caos es la práctica de romper los sistemas de uno a propósito para observar y obtener nuevos conocimientos de los resultados, incluido el efecto dominó que tiene en los sistemas.

Algunos lectores pueden considerar que esta práctica es similar a la tradicional red teaming oa las pruebas de penetración, pero en realidad difiere tanto en el propósito como en la metodología. El objetivo final de los equipos rojos es obtener acceso a recursos confidenciales a través de métodos contradictorios engañosos sin causar interrupciones en los sistemas activos para determinar la efectividad de los controles de seguridad preventivos. Sin embargo, el objetivo final de la ingeniería del caos de seguridad es aprender a través de pruebas cuidadosas y metódicas de los sistemas. Nuestro enfoque se enfoca en inyectar fallas en componentes específicos para revelar problemas desconocidos e impredecibles en el sistema antes de que afecten la integridad operativa de los productos y servicios comerciales centrales.

Como Homo sapiens, tenemos que enfrentar el hecho de que los sistemas evolucionan más rápido de lo que nuestro razonamiento cognitivo puede interpretar. A pesar del conocimiento previo que poseemos, elegimos ver solo lo que queremos ver y escuchar solo lo que queremos escuchar. Nuestra comprensión y creencias reflejan lo que creemos. El propósito de la ingeniería del caos no es romper cosas, sino aprender nueva información sobre cómo funcionan realmente nuestros complejos sistemas adaptativos en relación con lo que creíamos saber.

Volviendo al ejemplo de registro de eventos descrito anteriormente, nosotros, como equipo de ingenieros, asumíamos que el sistema funcionaba correctamente. Este tipo de errores cuestan a las empresas millones de dólares cada hora. Considere la interrupción del Amazon Prime Day de julio de 2018 en la que Amazon incurrió en costos de hasta $ 33 millones por hora mientras los ingenieros se apresuraban a diagnosticar y evaluar el problema. Esa pausa de tres horas podría haberse identificado de manera proactiva utilizando técnicas de resiliencia como la ingeniería del caos.

Al buscar lo inesperado, el enfoque lógico es hacerlo objetivamente esperado. Nuestros sistemas evolucionan tan rápidamente y se vuelven tan complejos que debemos buscar nuevos métodos, como la ingeniería del caos, para comprender mejor cómo funcionan, mejorarlos y anticipar la naturaleza no lineal de sus resultados impredecibles.

Qué leer a continuación

Artículos de interés

Subir