RFC 3227

Los RFC (Request For Comments) son una serie de documentos cuyo contenido es una propuesta oficial para un nuevo protocolo de la red o línea guía de desarrollo de un proceso, que explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambigüedades.

El “RFC 3227: Guía Para Recolectar y Archivar Evidencia” escrito en febrero de 2002 por Dominique Brezinski y Tom Killalea, ingenieros del Network Working Group. Es un documento que provee una guía de alto nivel para recolectar y archivar datos relacionados con intrusiones. 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. Su estructura es:

a)       Principios durante la recolección de evidencia:

·         Orden de volatilidad de los datos: Al recoger pruebas se debe proceder de la volatilidad a la menos volátil.

·         Cosas para evitar: Es muy fácil destruir la evidencia, aunque inadvertidamente.

ð  No parar hasta que se haya completado la recopilación de pruebas.

Muchas pruebas se pueden perder y el atacante pudo haber alterado la inicio / scripts / servicios para destruir la evidencia de apagado.

ð  No fiarse de los programas en el sistema. Ejecutar sus pruebas, reunir los programas de los medios de comunicación debidamente protegidas.

ð  No ejecutar programas que modifican el tiempo de acceso de todos los archivos de sistema.

ð  Cuando la eliminación de vías externas para el cambio en cuenta que simplemente desconectar o filtrado de la red puede desencadenar "Interruptores hombre muerto" que detectan cuando están fuera de la red y borrar la evidencia.

·         Consideraciones de privacidad:

ð  Respetar las normas y directrices de su empresa y privacidad su jurisdicción legal. En particular, asegúrese de que no información recogida junto con la evidencia que está buscando para la que está disponible para cualquier persona que normalmente no tienen acceso a esta información. Esto incluye el acceso a los archivos de registro (que puede revelar los patrones de comportamiento del usuario) así como datos personales archivos.

ð  No inmiscuirse en la privacidad de las personas que no tienen una fuerte justificación. En particular, no recogen información de áreas en las que normalmente no tienen razones para acceder (por ejemplo, almacenes de archivos personales), a menos que tenga indicios suficientes que no es un incidente real.

ð  Asegúrese de que tiene el respaldo de su empresa está establecida procedimientos de adopción de las medidas que usted hace para reunir pruebas de un incidente.

·         Consideraciones legales: Evidencia ordenador tiene que ser:

ð  Admisibilidad: debe ajustarse a ciertas normas legales que tiene ante sí puede ser puesto ante un tribunal.

ð  Auténtico: Debe ser posible vincular positivamente probatoria material al incidente.

ð  Completa: Debe contar toda la historia y no sólo un en particular perspectiva.

ð  Confiable: No debe haber nada acerca de cómo la evidencia era recogidos y sucesivamente tratados que arroja dudas sobre su autenticidad y veracidad.

ð  Creíble: Debe ser fácilmente creíble y comprensible por un tribunal.

b)       El proceso de recolección: Los procedimientos de recolección deben ser lo más detallado posible. Como es en el caso de los procedimientos generales de gestión de incidentes, deberían ser inequívoca y debe reducir al mínimo la cantidad de toma de decisiones sea necesario durante el proceso de recolección.

·         Transparencia: Los métodos utilizados para reunir pruebas deben ser transparentes y reproducibles. Usted debe estar preparado para reproducir con precisión el métodos que utiliza, y que esos métodos probados por expertos independientes expertos.

·         Pasos de recolección

ð  ¿Dónde está la evidencia? Lista de lo que los sistemas estaban involucrados en el incidente y de la que se recogerán pruebas.

ð  Establecer lo que es probable que sean pertinentes y admisibles. ¿Cuándo?

En caso de duda errar por el lado de la recogida demasiado en lugar de no suficiente.

ð  Para cada sistema, obtener la correspondiente orden de la volatilidad.

ð  Retirar vías externas para el cambio.

ð  Tras el fin de la volatilidad, reunir las pruebas con herramientas.

ð  Registre el grado de sincronización del reloj del sistema.

ð  Pregunta qué más puede ser evidencia a medida que trabaja a través de las medidas de recaudación.

ð   Documentar cada paso.

ð  No se olvide de las personas involucradas. Tome nota de que estaba allí y lo que estaban haciendo, lo que han observado y cómo reaccionado.

Siempre que sea posible se debe considerar las sumas de comprobación de generación y firmar criptográficamente las pruebas recogidas, ya que esto puede hacer que sea más fácil de conservar una fuerte cadena de pruebas. Al hacer esto usted debe

No alterar la evidencia.

c)       El proceso de archivo: La evidencia debe estar estrictamente protegida. Además, la cadena de custodia debe estar claramente documentada.

·         La cadena de custodia: Usted debe ser capaz de describir claramente cómo se encontró la evidencia, la forma en que se manejó y todo lo que pasó con él. La siguiente necesidad de documentar:

ð  ¿? Dónde, cuándo y por quién fue la evidencia descubierta y recogido.

ð  ¿? Dónde, cuándo y por quién fue la evidencia manejada o examinado.

ð  ¿? Quién tenía la custodia de la evidencia, durante qué período. ¿? Cómo fue se almacena.

ð  Cuando la evidencia cambió la custodia, cuando y como lo hizo el transferir ocurrir (incluir números de envío, etc.)

·         Donde y como archivar: Si es posible, los medios de comunicación de uso común (más que algunos de almacenamiento oscura los medios de comunicación) se debe utilizar para el archivado.

Acceso a las pruebas debe ser extremadamente limitado, y debe ser claramente documentado. Debería ser posible detectar no autorizada acceder.

Se debe de tener los programas que se necesitan para hacer la recopilación de pruebas y forense en medios de sólo lectura (por ejemplo, un CD). Se debe haber preparado este conjunto de herramientas para cada uno de los sistemas operativos que se gestionan antes de tener que usarlo.

Su conjunto de herramientas debe incluir lo siguiente:

o   Un programa para el examen de los procesos.

o   Programas para examinar el estado del sistema.

o   Un programa para hacer copias de bit a bit.

o   Programas para generar sumas de comprobación y firmas.

o   Programas para la generación de imágenes básicas y para examinarlas.

o   Secuencias de comandos para automatizar la recopilación de pruebas.

Se debe estar preparado para dar fe de la autenticidad y fiabilidad de las herramientas que se utilizan.