Resumen
- RFC 3067 pidió un objeto común que mantuviera separados evento observable, evidencia, clasificación, daño real, impacto posible y confianza.
- El expediente debía crecer de alerta a archivo y conservar restricciones por elemento, cadena de custodia y acciones de los CSIRT anteriores.
Antes del esquema, una teoría del relevo
Publicada en febrero de 2001 como Informational, RFC 3067 recogió requisitos de TERENA para IODEF. Los ataques atravesaban países, lenguas, culturas y jurisdicciones operativas; los equipos necesitaban intercambiar alertas, investigaciones, estadísticas y aprendizaje.
El objeto no sería un sobre automático. Debía ser creado y autorizado por personas, legible con herramientas corrientes y procesable por sistemas. Un mensaje de detección podía iniciar la historia, pero la descripción de incidente tenía que transportar lo aprendido, decidido y hecho por varias organizaciones.
Por eso distinguía evento, evidencia, incidente, daño, impacto y confianza. Un suceso observable podía generar alerta; la evidencia apoyaba una conclusión; el incidente implicaba violación; el daño describía efecto real; el impacto, consecuencias comunitarias. La confianza medía fuerza del informe. No eran sinónimos repartidos en columnas.
La alerta no era dueña de la conclusión
Tres accesos fallidos podían activar una alarma sin demostrar atacante, compromiso, daño ni impacto. Un detector estimaba probabilidad; un CSIRT escalaba según política; otro correlacionaba con una campaña. El objeto común debía conservar cada paso sin convertir la primera señal en sentencia.
La norma exigía confianza, permitía impacto basado en listas o experiencia responsable y aceptaba un nombre temporal para tipos desconocidos. La estructura ayudaba a agregar; el texto libre guardaba lo aún inestable. El expediente también debía crecer durante la investigación y conservar acciones anteriores. Era un dossier cambiante, no una alarma congelada.
Cada compartimento podía tener otro público
Compartir coordinaba, pero también exponía contraseñas, identificadores y material forense. RFC 3067 exigía restricción de acceso en cada elemento, no una única etiqueta sobre el informe completo.
Un receptor podía conocer el tipo y la red sin ver la identidad de la víctima o la evidencia sellada. Una estadística podía conservar impacto agregado y quitar detalle operativo. La evidencia podía quedar externa porque su custodia y permisos diferían.
El cifrado no resolvía todo: un sistema autorizado podía descifrar y después distribuir mal. La marca debía acompañar al dato. Además, el intercambio normalmente requería decisión de un operador o responsable. La legibilidad automática ayudaba al relevo humano; no lo autorizaba.
La evidencia necesitaba historia de custodia
La RFC enumeró volcados, registros, memoria, caché, estadísticas del núcleo y archivos temporales. Pidió integridad, cifrado cuando fuera necesario, custodia documentada y respeto a la ley local. El receptor necesitaba bytes y también saber quién los obtuvo, cuándo, bajo qué condiciones y con qué transformaciones.
RFC 3227 desarrolló después el orden de volatilidad, la modificación mínima y la documentación. Ningún formato podía prometer admisibilidad en todos los sistemas jurídicos. Del mismo modo, hora local y desplazamiento UTC ayudaban a normalizar, pero no corregían un reloj falso, un retraso desconocido o una causalidad equivocada.
RFC 5070 convirtió estos requisitos en un modelo XML estándar en 2007 y aclaró que era formato de transporte, no definición universal de incidente ni almacén óptimo. RFC 7970 lo reemplazó en 2016. El esquema se hizo concreto, pero la autoridad siguió distribuida entre autor, custodio, organización emisora, receptor y derecho local.
Un objeto común podía volver legible el desacuerdo sin borrar observación, inferencia, decisión y resultado. El código podía validar y transportar el documento; no demostrar que la clasificación era correcta ni que la respuesta funcionó.
Fuentes
- https://www.rfc-editor.org/rfc/rfc3067.html
- https://www.rfc-editor.org/info/rfc3067/
- https://datatracker.ietf.org/doc/rfc3067/
- https://www.rfc-editor.org/rfc/rfc2350.html
- https://www.rfc-editor.org/rfc/rfc3227.html
- https://www.rfc-editor.org/rfc/rfc5070.html
- https://www.rfc-editor.org/rfc/rfc7970.html
- https://www.iana.org/assignments/xml-registry
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
