RFC 3227 - GUÍA PARA RECOLECTAR Y ARCHIVAR EVIDENCIAS (ESPAÑOL) - PERICIAS INFORMÁTICAS EN ARGENTINA
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.
Fuente original: https://www.ietf.org/rfc/rfc3227.txt
Mas info en esta disertación: http://prezi.com/qj7v6amnusy5/?utm_campaign=share&utm_medium=copy&rc=ex0share
Fuente original: https://www.ietf.org/rfc/rfc3227.txt
Mas info en esta disertación: http://prezi.com/qj7v6amnusy5/?utm_campaign=share&utm_medium=copy&rc=ex0share
Comentarios