Copyright (C) The Internet Society (2002). Todos los derechos reservados.

 El “RFC 3227: Guía Para Recolectar y Archivar Evidencia” Es una guía escrita en febrero de 2002 por Dominique Brezinski y Tom Killalea, ingenieros del Network Working Group.

Este es un documento a modo de guía de alto nivel para recolectar y archivar las evidencias. Muestra las mejores prácticas para determinar la volatilidad de los datos, decidir que recolectar, desarrollar la recolección y determinar cómo almacenar y documentar los datos. También explica algunos conceptos relacionados a la parte legal.

A continuación se muestra una traducción interpretada del contenido íntegro de las Directrices RFC 3227. Ante cualquier duda de interpretación, se recomienda consultar esta norma en su versión original.

Extracto: 

Un «incidente de seguridad» como se define en el » Glosario de Seguriad de Internet», RFC 2828 , es un evento del sistema de seguridad, en el cual la política de seguridad del sistema se ha desobedecido o ha sido violada.

El propósito de este documento es proporcionar a los administradores de sistemas las pautas a seguir en la recopilación y archivo de las evidencias ante un incidente de seguridad.

Si la recopilación de pruebas se hace correctamente, será más fácil llegar hasta el atacante, además, existe una mayor posibilidad de que las evidencias sean admitidas ante un proceso judicial.

1.    Introducción

Un «incidente de seguridad» tal como se define en [RFC2828] es un evento del sistema de seguridad relevante en el que se desobedece la política de seguridad del sistema o se viola de otro modo. El propósito de este documento es proporcionar a los Administradores del Sistema directrices sobre la recolección y archivo de evidencia relevante para tal incidente de seguridad. No es nuestra intención insistir en que todos los Administradores del Sistema  sigan estas directrices cada vez que tienen un incidente de seguridad. Más bien, queremos proporcionar orientación sobre lo que deben hacer si eligen recopilar y proteger la información relacionada con una intrusión.

Esta recolección representa un esfuerzo considerable por parte del Administrador del Sistema. En los últimos años se han hecho grandes progresos para acelerar la reinstalación del sistema operativo y facilitar la reversión de un sistema a un estado «conocido», haciendo así más atractiva la «opción fácil». Mientras tanto, poco se ha hecho para proporcionar formas fáciles de archivar pruebas (la opción difícil). Además, el aumento de las capacidades de los discos y memoria, y el uso de las técnicas de ocultación por parte de los atacantes han agravado el problema. 

Si la recolección de evidencia se hace correctamente, es mucho más fácil llegar hasta el atacante, y existen una mayor posibilidad de que las evidencias sean admisibles en un caso de enjuiciamiento.

Se deben utilizar estas directrices como base para formular los procedimientos de recopilación de evidencias. Las directrices que forman este documento pueden no ser apropiadas en todas las jurisdicciones. Se ha de confirmar que los procedimientos de recopilación de evidencia, son los adecuados según la ley y jurisdicción.

1.2      Convenciones utilizadas en este documento

Las palabras clave «REQUERIDO», «DEBE», «NO DEBE», «DEBERÍA», «NO DEBERÍA», y «PUEDE» en este documento se han de interpretar como se describe en «palabras clave para indicar los niveles de exigencia para su uso en las RFC’s» [RFC2119].

2.    Guía para la recolección de evidencias

• Cumplir con la Política de seguridad de su puesto y disponer del personal apropiado para el manejo de incidentes según se indique en la ley.

• Obtener una imagen lo más precisa posible del sistema.

• Mantener en la medida de posible un registro de notas detalladas. Estas deben incluir fechas y horas. Si es posible, que estas sean generadas de manera automática. (Por ejemplo, en un sistema Unix se puede usar el programa ‘script’, sin embargo, el archivo de salida que se genera no debería estar ubicado en la propia evidencia. Las notas y los documentos impresos deben estar firmados y fechados.

• Tener en cuenta la diferencia entre el reloj del sistema y la hora en UTC. Para cada hora identificada, indicar si está en  UTC o en horario local.

• Esté preparado para testificar (más tarde) describiendo todas las acciones que se tomaron y en qué momentos. Las notas detalladas serán vitales.

• En el momento de la recopilación se debe evitar las posibles modificaciones sobre a evidencia.

• Eliminar las vías externas que pudieran producir un cambio en la evidencia.

• Si nos encontramos antes al dilema entre la colección y el análisis, se debe realizar siempre primero el proceso de recolección.

• Los procedimientos aplicados deben ser reproducibles. Como con cualquier aspecto de una política de respuesta a incidentes, los procedimientos deben ser probados para asegurar la viabilidad en una crisis. Si es posible, los procedimientos deben ser automatizados por razones de velocidad y precisión. Sea metódico.

• Para cada dispositivo, debe adoptarse un enfoque metódico que siga las directrices establecidas en su procedimiento de recogida. La velocidad será a menudo crítica así que donde hay una serie de dispositivos que requieren el examen puede ser apropiado repartir el trabajo entre un equipo de trabajo para recoger la evidencia en paralelo. Sin embargo, en un único sistema, la recolección debe hacerse paso a paso.

• Proceda desde lo más volatilidad a lo menos volátil (véase la Orden de Volatilidad a continuación).

• Debe hacer una copia a nivel de bits de los medios del sistema. Si desea realizar análisis forense, se debe hacer una copia de la evidencia a nivel de bits, ya que un análisis sobre la original alterará los tiempos de acceso a archivos. Evite hacer análisis forenses en la evidencia original.

2.1       Orden de volatilidad

Al recolectar la evidencia se debe proceder de lo más volátil a lo menos volátil. A continuación se muestra un ejemplo de orden de volatilidad para un sistema típico:

• Registros y caché.
• Tablas de enrutamientos, caché arp, tabla de procesos y memoria.
• Archivos temporales.
• Disco.
• Ficheros de logs.
• Configuración física, topología de red.
• Almacenamiento externo.

2.2       Actuaciones a evitar

Recomendaciones a tener en cuenta para evitar la contaminación de las evidencias:

• No apagar el equipo hasta que haya completado la recopilación de pruebas. Se podrían perder muchas evidencias ya que el atacante podría haber configurado script que se ejecuten durante el encendido o apagado del equipo para destruir pruebas. 

• No confiar en los programas del sistema. Ejecuta tus propios programas de recolección de evidencia en medios apropiadamente protegidos.

• No ejecutar programas que modifiquen el tiempo de acceso de los archivos del sistema (por ejemplo, ‘tar’ o ‘xcopy’).

2.3       Consideraciones sobre la privacidad

• Respetar las normas y directrices de privacidad de la empresa y su jurisdicción legal. Esto incluye el acceso a archivos de registro (que pueden revelar patrones de comportamiento del usuario), así como archivos de datos personales.

• No entrometerse en la privacidad de las personas sin una justificación. En general, no recopilar información de áreas a las que normalmente no se tiene acceso (como almacenes de archivos personales) a menos que se tenga suficientes indicios de que hay un incidente real.

• Asegurarse de poseer un documento por escrito haciendo costar el respaldo de la empresa.

3      El procedimiento de recolección

 Los procedimientos de recolección deben ser tan detallados como sea posible. Como es el caso con sus procedimientos generales de manejo de incidentes, deben ser inequívocos y deben minimizar la cantidad de toma de decisiones necesarias durante el proceso de recolección.

3.1      Transparencia

Los métodos utilizados para recopilar pruebas deben ser transparentes y reproducibles. Se debe estar preparado para reproducir con precisión los métodos que se han utilizado, y tener los métodos probados por expertos independientes.

3.2      Pasos de recolección

• Describir dónde está la evidencia

• En caso de duda, errar por recolectar demasiada información antes de no recolectar la suficiente.

• Para cada sistema, obtener las evidencias por orden de volatilidad.

• Anotar si existe alguna variación en el reloj del sistema con la zona horaria.

• Preguntarse qué más podrían ser evidencias mientras se trabaja en la recolección.

• Documentar cada paso.

• Tomar nota de las personas involucradas

• Siempre se ha de considerar la generación de Hashes que firmen la evidencia recopilada.

4      El procedimiento de almacenamiento

• La evidencia debe ser estrictamente asegurada.

• La Cadena de Custodia debe estar claramente documentada.

• Deben realizarse al menos dos copias de la original.

• Las evidencias deben guardarse en un lugar seguro.

4.1      Cadena de Custodia

Se debe describir claramente cómo la evidencia fue encontrada, cómo se manejó y todo lo que le sucedió.

Lo siguiente necesita ser documentado:

• Dónde, cuándo y por quién se descubrieron y recolectaron las pruebas.

• Dónde, cuándo y por quién se tramitaron o examinaron las pruebas.

• Quién tuvo la custodia de la evidencia, durante qué período. ¿Cómo se almacenó?.

• Cuando la evidencia cambió la custodia, cuándo y cómo ocurrió la transferencia (incluya números de envío, etc.).

• No olvidar mencionar a las personas involucradas. Anotar quiénes estaban allí y qué estaban haciendo, qué observaron y cómo reaccionaron.

4.2      Dónde y cómo almacenar

Si es posible, almacenar las evidencias en medios de comunes.

El acceso a la evidencia ha de estar extremadamente restringido, y debe estar claramente documentado. Debería ser posible detectar un acceso no autorizado.

5      Herramientas que necesitarás

Se deben tener los programas forenses adecuados para realizar la recolección de evidencia en medios de solo lectura (por ejemplo, un CD). Se debe haber preparado un conjunto de herramientas para cada uno de los Sistemas Operativos que se gestione.

El conjunto de herramientas debe incluir lo siguiente:

• Un programa para examinar procesos (por ejemplo, ‘ps’).

• Programas para examinar el estado del sistema (por ejemplo, ‘showrev’, ‘ifconfig’, ‘netstat’, ‘arp’).

• Un programa para hacer copias de bit a bit (por ejemplo, ‘dd’, ‘SafeBack’).

• Programas para generar comprobaciones y hashes (por ejemplo, ‘sha1sum’, ‘dd’, ‘SafeBack’, ‘pgp’ habilitado para la suma de comprobación).

• Programas para generar imágenes de core y para examinarlas (por ejemplo, ‘gcore’, ‘gdb’).

Scripts para automatizar la recopilación de pruebas (por ejemplo, The Coroner’s Toolkit [FAR1999]).

6      Referencias

 [FAR1999] Farmer, D., y W Venema, «Computer Forensics Análisis Clase Handouts», http://www.fish.com/forensics/

[RFC2119] Bradner, S., «palabras clave para su uso en RFCs para indicar los niveles de requisitos», BCP 14, RFC 2119, marzo 1997.

[RFC2196] Fraser, B., «Site Security Handbook», FYI 8, RFC 2196, septiembre de 1997.

[RFC2350] Brownlee, N. y E. Guttman, «Expectativas para la respuesta de incidentes de seguridad informática», FYI 8, RFC 2350, junio 1998.

[RFC2828] Shirey, R., «Internet Security Glosario», FYI 36, RFC 2828, mayo de 2000.

7      Agradecimientos

Agradecemos los comentarios constructivos de Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Andrew Rees, Steve Romig y Floyd Short.

8      Consideraciones de seguridad

Este documento completo, en su totalidad trata temas de seguridad.

9      Author’s Addresse

   Dominique Brezinski

   In-Q-Tel

   1000 Wilson Blvd., Ste. 2900

   Arlington, VA 22209 USA

   EMail: dbrezinski@In-Q-Tel.org

    Tom Killalea

   Lisi/n na Bro/n

   Be/al A/tha na Muice

   Co. Mhaigh Eo  IRELAND

   Phone: +1 206 266-2196

   EMail: tomk@neart.org

10  Declaración completa de derechos de autor

 Copyright (C) La Sociedad de Internet (2002). Todos los derechos reservados.

Este documento y las traducciones del mismo pueden ser copiados y entregados a terceros, y los trabajos derivados que comenten o expliquen o ayuden en su implementación pueden ser preparados, copiados, publicados y distribuidos, en su totalidad o en parte, sin restricción de ningún tipo, Siempre que el aviso de copyright anterior y este párrafo estén incluidos en todas las copias y trabajos derivados. Sin embargo, este documento en sí no puede ser modificado de ninguna manera, como por ejemplo, eliminando el aviso de copyright o referencias a la Internet Society u otras organizaciones de Internet, excepto cuando sea necesario para el propósito de desarrollar estándares de Internet en cuyo caso los procedimientos para derechos de autor definidos en Internet Standards Proceso debe ser seguido, o según sea necesario para traducirlo a otros idiomas que no sean el inglés.

Los permisos limitados otorgados anteriormente son perpetuos y no serán revocados por la Internet Society o sus sucesores o asignados.

Este documento y la información contenida en este documento se proporcionan «TAL CUAL ES» y EL GRUPO DE TRABAJO DE INTERNET Y LA SOCIEDAD DE INGENIERÍA DE  INTERNET RENUNCIA A TODAS LAS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUYENDO PERO NO LIMITADO A CUALQUIER GARANTÍA DE QUE EL USO DE LA INFORMACIÓN CONTENIDA NO INFRINGIRÁ NINGÚN DERECHO O CUALQUIER GARANTÍA IMPLÍCITA DE CONFIANZA O IDONEIDAD PARA UN PROPÓSITO PARTICULAR.