Guerra de Fronteras: Respuestas de Incidentes vs. Investigación Forense

En mi trabajo, con frecuencia discutimos herramientas de seguridad y los procesos específicos que generan los requerimientos que demanda el uso de cada una de estas herramientas. Últimamente, hemos estado debatiendo las herramientas de respuesta a incidentes y procesos, contrastado con las herramientas de investigación forense y procesos. Obviamente, ambos tienen beneficios aparte que traen en conjunto a la disciplina general de seguridad. También tienen requerimientos diferentes, en términos del set de herramientas que se requieren para ejecutar aquellos procesos.

Para mí, los límites entre la investigación forense y la respuesta a incidentes siempre ha sido bastante clara. Quizás un poco confusa en el modo de comunicación entre ellas, pero no una gran nebulosa de incertidumbre. Como sea, últimamente, estoy comenzando a creer que allá afuera, para el resto de la comunidad puede que no esté tan claro. Podría estar errado… puede que no sea la primera vez, tampoco será la última, especialmente si me piden que mire a mis amigos cercanos.



Primer Trabajo: Clasificación

Todos sabemos que en la rama de la seguridad, la cadena de acción comienza con un evento de seguridad.

Evento de Seguridad“Un(as) ocurrencia(as) en un sistema que es relevante a la seguridad del sistema. (Ver: incidente de seguridad.)[RFC2828] – (ref. (en inglés): http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html#Appendix.)

Ok, bastante simple. Algo sucedió. Es bueno, es malo, o ¿está en algún punto entre los dos? Pensemos en esto en los términos del tipo de cosas que un departamento de bomberos pueda tener que manejar. Esto es algo que no sólo el departamento de bomberos local tendrá que revisar, sino que también demandará que se tomen ciertas acciones y otros procesos necesarios. Un evento puede ser alguien en un patio trasero que se entusiasmó por demás con el carbón y tiene su carne a la parrilla flameando y humeando lo suficiente como para causar preocupación en la casa del vecino. Puede que se asomen a echar una mirada, pero lo más probable es que no vayan a apagar el “incendio” ocasionado por tu parrilla con su manguera de metro y medio sólo porque a dicha persona le gusta su carne un poco más crocante.

Bueno, eso nos lleva al siguiente punto. Dentro del campo de respuesta a incidentes, si el evento es benigno, es ignorado o descontado, como también, simplemente percibido y desechado. Si es malo, se reclasifica como un incidente de seguridad.

Incidente de Seguridad“Cualquier evento posterior respecto a cualquier aspecto de la seguridad informática puede ser amenazado: pérdida de confidencialidad de datos, disrupción de datos o integridad de sistema, negación de disponibilidad [NIST-800-3]

Proposición hecha por el Glosario de Seguridad de Internet [RFC 2828]:

(I) Un evento de seguridad que involucra la violación de seguridad. (Ver: CERT, GRIP, Evento de Seguridad, Intrusión de Seguridad, Violación de Seguridad.)

(C) En otras palabras, un evento de seguridad relevante al sistema, en el cual la política del sistema de seguridad es desobedecido o incumplido. (ref, en inglés: http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html#Appendix.)

Buscar señales de malicia después que el incendio se apagó

Para mí, un incidente es algo en lo que tienes que dar la cara, de cierta manera, ahora. Digamos que, en vez de una parrilla que echa humo tenemos una casa quemándose. Esto es algo a lo que los bomberos locales no sólo tendrán que salir y echar un vistazo, sino que también tendrán que tomar alguna acción y hacer lo que hacen. Apagar el incendio y evitar la pérdida masiva, tanto material como humana. En términos de computación, esta respuesta a incidentes puede variar un poco si lo comparamos con evitar los procesos comprometidos, a cerrar el sistema, o bien rediseñar el punto de partida. Ciertamente esta lista no es exhaustiva, pero es información remedial de todas formas, ¿cierto? Tengo certeza que están diciendo: “Sí… entendemos este punto… tienes un punto verdadero? Si has leído hasta aquí, quédate un poco más conmigo, ya viene.

A continuación tenemos investigaciones forenses. Los incidentes de seguridad que son realmente malos y te hacen preguntar cosas respecto al motivo y mirar los aspectos de criminalidad posible o incluso comportamiento intencional se convierten en investigaciones forenses. Una investigación requiere que evoques un nivel diferente de disciplina. En nuestro ejemplo de un fuego en casa, este es el punto en el que los chicos con entrenamiento especializado entran a la casa después del incendio para buscar las causas del mismo. Importante denotar que dije “después del incendio”, porque está claro que no estarías haciendo dicha actividad cuando el edificio todavía está quemándose, puesto que sería muy peligroso.

Entonces se desglosa de la siguiente manera: Hay muchos eventos de seguridad. Algunos eventos de seguridad se convierten en incidentes. Algunos incidentes de seguridad se convierten en investigaciones.

Graficando, se ve algo como esto:



Análisis de Malware: ¿Respuesta a Incidentes o Investigación Forense?

Sí, sí, sabemos… es de conocimiento común. He aquí mi punto. ¿Qué tal análisis de malware (et. al.)? Claramente está en el borde o muy cerca del borde entre incidente e investigación.

Aquí mi argumento… si miras la naturaleza de la disciplina que estás usando para la tarea, se hace un poco más obvio cuál es. Si estás trabajando en un incidente y éste envuelve malware que está siendo encontrado en el sistema, tendrás que apegarte a la disciplina del investigador forense y no así a la persona que da respuesta del incidente. Ya no estás apagando el fuego, sino más bien investigando las causas del incendio. No estás arreglando, reparando o mitigando, estás analizando cómo ser mejor o hacerte menos susceptible. Dentro de los estándares de la metodología de respuesta a incidentes, esto es durante o luego la fase de análisis de post-incidente de tu respuesta/investigación. Comúnmente, en una situación de ensayo o de la vida real, ésta es la parte donde extraes lo aprendido y desempeñas una apreciación de tus actividades de respuesta. ¿Qué estuvo bien? ¿Dónde podría mejorar tu equipo de respuesta? ¿Dónde fallaron nuestras defensas? ¿Hay alguna mejora que se requiera hacer para incrementar la efectividad de nuestra postura en seguridad?

Tratar de determinar qué es lo que hace que el malware funcione o cómo fue que consiguió evadir nuestras defensas, es usar el mismo método que los investigadores forenses utilizan y seguramente algunas de las mismas herramientas. Con eso en mente, me gustaría aportar que los análisis post-incidente ocurren DESPUÉS que ha terminado el incidente. Después que se apaga el fuego. Ahora, por supuesto, todos sabemos que podrías haber encontrado dicho pedazo de malware en alguna parte media del incidente y todavía estar ocasionando incendios en un incidente particularmente grande y notorio, pero eso no quiere decir que el análisis de malware es parte del proceso de mitigación y respuesta, por sí sólo. Todavía no estás respondiendo, está analizando. Tus políticas locales puede que dicten que el incidente no puede cerrarse oficialmente hasta el análisis post incidente, o evaluación post mortem [odio ese término], es completo, pero eso no quiere decir que dichas evaluaciones son parte de la respuesta a incidentes. Diferentes conjuntos de habilidades para ser usadas en diferentes actividades. Diferentes objetivos de las actividades.

En conclusión, me gustaría simplemente ofrecer que la respuesta a incidentes es principalmente relacionado a el hecho de parar cualquier cosa mala que esté pasando. La investigación forense o análisis post incidente está relacionado con el “porque” en por qué sucedió y respaldando evidencia (hechos) para probar culpabilidad o inocencia. Cuando en duda, mira la disciplina lógica a la que estás inclinándote para saber si una actividad en particular está de un lado o del otro de la línea entre respuesta a incidentes o investigación forense. Eso te permitirá saber qué herramientas en tu caja de herramientas está más apta para dicha tarea.

Traducido del texto original publicado por Josh Beckett titulado: Border Wars: Incident Response vs. Forensic Investigation

RELACIONADOS

Cuando Viejos Procesos Encuentran Nueva Tecnología 

EnCase Analytics: Inteligencia de Seguridad Mediante el Análisis de Dispositivos 

Cómo EnCase Puede Complementar Sistemas de Prevención de Pérdida de Datos (DLP) 

Unirse a Nuestro Grupo de LinkedIn en Español Sobre EnCase

No hay comentarios :

Publicar un comentario