Una reflexión sobre la alteración en el Análisis Forense

En multitud de ocasiones, cuando se habla de las actuaciones de un forense informático se remarca la necesidad de no alterar «la escena». Se nos recuerda que debemos ser muy cuidadosos para no alterar nada, no conectar nada, no ejecutar nada. Aunque en la práctica, en mi opinión, esto no siempre es del todo así.

A la cabeza me viene el Principio de incertidumbre de Heisenberg, que se puede resumir de una manera muy sencilla en su aplicación práctica como que cuando se quiere medir la posición de una partícula subatómica ésta se altera, por lo que nuestra medición ya no será la real. En definitiva, si queremos medir la posición o características de un electrón, alteraremos su estado. O en nuestro caso, si queremos recopilar información, seguro que alteraremos algo.

Bien, pues volviendo al tema del análisis forense, si bien es verdad que debemos tener cuidado en alterar lo menos posible, también debemos saber que no hay más remedio que hacerlo y más importante es saber qué es lo que estamos alterando. Me gustaría ilustrarlo utilizando un ejemplo en el que se encuentra una momia en unas excavaciones. Los técnicos tendrán que pisar y extraer la tierra (pudiendo eliminar restos arqueológicos que den más información sobre el hallazgo) y no por ello dejan de acceder al sepulcro para analizarlo. Lo que está claro es que quizá traten de pisar todos el mismo sitio y no deambular por las excavaciones.

Por esto, debemos saber qué consecuencias tendrán las acciones que hagamos pero son necesarias ya que necesitamos obtener la memoria volátil del sistema, que nos aportará una gran cantidad de información. He leído varios escritos en los que se recalca la idea de no alterar la prueba, de tirar del cable y analizar el disco, pero se ha omitido recoger la memoria volátil, algo que nos da muchísima información. Asimismo, cuando no enfrentamos a esto en el mundo real, no siempre es posible apagar el equipo por lo que en ocasiones nos vemos en la necesidad de hacer un análisis en vivo. A esto también se le añade el hecho de que quizá debamos acceder a él previamente para determinar si se ha producido o no un incidente. Por eso, no nos precipitemos en tirar del cable.

Como recomendación personal, he de decir que debemos acceder el menor tiempo posible y ejecutar el menor número de comandos (si son ajenos al sistema, mejor, para ello utilizaremos binarios preparados desde una unidad extraíble) para obtener la información volátil. Una vez hecho esto, se tendrá que valorar si al ejecutar el famoso «tirar del cable» vamos a perder información o no, y pasaremos a trabajar con la información persistente. Sería deseable poder apagar la máquina y mover los servicios a una otra máquina (en este punto viene muy bien las máquinas virtuales) mientras trabajamos con la copia clonada. Por último, no debemos demorarnos en el proceso, ni precipitarnos, por lo que debemos responder a todas las preguntas y restaurar el servicio lo antes posible. Debemos recordar que el negocio de la organización es el servicio que desde allí se ofrece, no el resultado de nuestro informe.

Imagen por Daniel Rocal – Flickr

Comments

  1. Hola,

    interesante comentario. Yo creo que el problema de capturar el contenido de la memoria volátil y usarlo como prueba tiene dos problemas:
    1. el que comentas, la inevitable alteración de la prueba: es imposible ejecutar algo en un sistema sin modificar el contenido de su memoria; y lo más grave,
    2. la imposibilidad de repetir la prueba y obtener el mismo resultado.

    Con estos dos argumentos en la mano, una captura de memoria sería fácilmente recusable como prueba. Lo que sí puede ocurrir es que en el volcado de la memoria se descubra un indicio que ayude a resolver el caso y luego se documento con pruebas «estáticas».

    Yo escribí sobre esto (el análisis de equipos «en vivo») en mi blog, donde comentaba una herramienta gratuita de Belkasoft que lo hace para sistemas Windows: http://javier-tobal.blogspot.com.es/2013/05/belkasoft-ramcapturer.html

  2. Muy buenas tardes a todos,

    Una de las bases de la informática forense es el principio de Locard [1], que viene a decir: «Siempre que dos objetos entran en contacto transfieren parte del material que incorporan al otro objeto». Es decir, toda acción que realicemos va a dejar una huella en el sistema, de forma ineludible.

    La cantidad de información que puede recuperarse de un sistema vivo, incluso sin hacer una captura de la memoria (un área apasionante y que está en plena ebullición) es tremenda, y su utilidad para resolver un caso es indudable.

    Sin embargo, la legislación es en informática forense tan importante (o más) que la técnica. Para que una técnica forense sea aceptable como prueba en un juicio, tiene que estar validada.

    En el caso de la informática, todo el procedimiento debe de estar validado basándonos en los principios de repetibilidad, de modo que podamos repetir el procedimiento en diversos entornos y varias veces obteniendo siempre los mismos resultados [2].

    Y en el caso del análisis en caliente, lo que debe de hacerse de forma previa es conocer los efectos de dichos procedimientos sobre el sistema, para documentar cuidadosamente los cambios que estas herramientas realizan. El objetivo es poder demostrar de forma veraz que, aunque estas herramientas modifican el sistema, lo hacen de modo que no afecta significativamente al mismo (por ejemplo, modificando unas claves del registro conocidas, y cuyo contenido no es crítico).

    Esta validación tiene que hacerse de forma previa, y tener el informe preparado para rebatir la (bastante probable) recusación de la defensa. Obviamente, el proceso de adquisición tiene que estar realizado de forma exquisita para no dejar duda alguna de la corrección del mismo, por lo que debe de ser documentado extensamente [3].

    En mi opinión, los beneficios superan con creces los problemas legales que estas técnicas suponen, y recomiendo el incorporar el análisis en caliente a los procedimientos de análisis forense [4].

    Un saludo,

    Antonio Sanz
    I3A/Universidad de Zaragoza

    [1] http://es.wikipedia.org/wiki/Edmond_Locard
    [2] http://www.dfinews.com/articles/2011/03/validation-forensic-tools-and-software-quick-guide-digital-forensic-examiner#.UemCDqyBYuM
    [3] http://forensic.belkasoft.com/en/live-ram-forensics
    [4]http://computer-forensics.sans.org/blog/2009/09/12/best-practices-in-digital-evidence-collection/

  3. Gracias por vuestros comentarios. Estoy muy interesado en aprender mejor sobre análisis forense y revisaré los enlaces que aportáis para conseguir información.

    Saludos

  4. Javier Toval, estas equivocado en esto «1. el que comentas, la inevitable alteración de la prueba: es imposible ejecutar algo en un sistema sin modificar el contenido de su memoria; y lo más grave,
    2. la imposibilidad de repetir la prueba y obtener el mismo resultado.»

    Si es posible aislar el contenido de la memoria USB del sistema, se hace en un pequeño paso que consiste en bloquear la escritura de los puertos USB, en el caso de un HDD hay que extraer la evidencia y con el mismo procedimiento o con el uso de BLOCKERs hacer el diagnostico con una imagen de la evidencia.

Trackbacks

  1. […] Continuar Leyendo. Tags:  informática forense […]

  2. […] En multitud de ocasiones, cuando se habla de las actuaciones de un forense informático se remarca la necesidad de no alterar "la escena". Se nos recuerda que debemos ser muy cuidadosos para no alte…  […]