Con la RFC por delante

Resulta claro que las evidencias de cara a un juicio o a la resolución de un caso, son una parte fundamental (si no la máxima) desde el punto de vista informático para la resolución de la causa. Muchas veces me han preguntado un código de buenas prácticas para tomar evidencias o una referencia para estas. Evidentemente las circunstancias varían en función de muchas características:

- Los sistemas operativos involucrados.
- Donde se encuentra la información.
- Las consecuencias legales.
- Que herramientas utilizamos para la toma de información.
- …

Aunque al final cada cual establece un mecanismo para la recogida de las evidencias, su almacenamiento y establece sus controles oportunos, fue emitida por la Internet Society y la IETF, una RFC con una Guía para la recolección y almacenamiento de evidencias. Esta guía, la ETF RFC 3227, determina una serie de buenas prácticas, para la recogida, almacenamiento y análisis de las evidencias.

Evidentemente por muy buena RFC que pueda ser, la supeditación a las normativas vigentes en cada País es algo muy claro, máxime en el caso de las evidencias digitales, debido a la facilidad de su alteración y manipulación. Por ejemplo la RFC establece la necesidad de tomar evidencias en función de la volatilidad de las mismas:

“2.1 Order of Volatility

When collecting evidence you should proceed from the volatile to the
less volatile. Here is an example order of volatility for a typical
system.

- registers, cache

- routing table, arp cache, process table, kernel statistics,
memory

- temporary file systems

- disk

- remote logging and monitoring data that is relevant to the
system in question

- physical configuration, network topology

- archival media”

Claro que esto supone un pequeño problema. Algunas de las recogidas de estas evidencias, supone el uso de herramientas in situ, sobre la máquina afectada que podría implicar una modificación del estado de la máquina por muy cuidadoso que quiera ser uno, y claro si la necesidad del caso implica la judicialización del mismo, ¿Quién se arriesga posteriormente a que las pruebas presentadas puedan ser rechazadas por manipulación del entorno?

Este tema siempre ha abierto un debate muy interesante allí donde lo he llevado, puesto que por el hecho de no modificar el escenario puedes perder información relevante, pero si la tomas puedes invalidar el resto, con un astuto abogado por la otra parte o …

Bueno esta RFC por lo tanto tiene que ser tomado como lo que es: un guía, no un dogma de Fe y como me dijeron una vez, ¡ante la duda tira de cable y luego haz la copia!