Si alguna vez abriste la casilla de abuse un lunes a la mañana, esta escena seguro te resulta familiar: cientos de correos, cada uno con su propio formato, algunos con un log pegado sin contexto, otros con un PDF adjunto. Y en el medio, un reporte que era realmente importante pero no contaste con el suficiente tiempo para analizarlo.
Del otro lado la historia es parecida. Reportamos un incidente, no recibimos respuesta y nunca sabemos si el problema fue la casilla, el formato o que nadie tuvo tiempo de leernos.
Este artículo es útil para los dos lados del mostrador.
No debe exigir el uso de un formulario para reportar un abuso.
Debe garantizar que los reportes de abuso, logs, cabeceras, ejemplos, etc., relativos al caso de abuso, sean recibidos.
Dicho de otro modo: la casilla existe, es obligatoria y alguien se comprometió por escrito a leerla. El problema, entonces, es otro.
Por qué un humano no da a basto
¿Cuál es el problema entonces? Que no hay un idioma común. Abusix, la empresa detrás de XARF, cuenta que necesitó desarrollar más de 500 parsers distintos para poder procesar los reportes que reciben sus clientes: cada fuente inventa su propio formato.
No debe exigir el uso de un formulario para reportar un abuso.
Debe garantizar que los reportes de abuso, logs, cabeceras, ejemplos, etc., relativos al caso de abuso, sean recibidos.
Dicho de otro modo: la casilla existe, es obligatoria y alguien se comprometió por escrito a leerla. El problema, entonces, es otro.
Por qué un humano no da a basto
¿Cuál es el problema entonces? Que no hay un idioma común. Abusix, la empresa detrás de XARF, cuenta que necesitó desarrollar más de 500 parsers distintos para poder procesar los reportes que reciben sus clientes: cada fuente inventa su propio formato.
Un reporte en texto libre suele fallar en lo básico:
la fecha sin indicar la zona horaria,
IP de origen sin puerto, no especificar el protocolo,
evidencia sin el timestamp que la ata al evento.
XARF: el formato pensado para este caso
XARF (eXtended Abuse Reporting Format) es un formato de reporte de abuso basado en JSON, mantenido por la comunidad en xarf.org. La versión vigente es la v4, que organiza 32 tipos de incidentes en 7 categorías, desde spam y phishing hasta ataques de red y vulnerabilidades, cada uno con su esquema propio.
Lo mínimo que exige la v4 son siete campos: versión del esquema, identificador único, timestamp del incidente, quién reporta, el origen del abuso y la dupla categoría más tipo. Ojo con el origen: apunta a la IP o el dominio infractor, no a la víctima. La evidencia figura como recomendada, aunque en los hechos es lo que vuelve accionable el reporte. Hay un detalle especialmente útil para los CSIRT: la v4 distingue entre reporter (quien detectó el abuso) y sender (quien envía el reporte), justamente para el caso de un CERT nacional que reporta en nombre de sus miembros.
Para enviarlo por correo, XARF se apoya en ARF (RFC 5965): un mensaje multipart/report de tres partes, una legible por humanos, una legible por máquinas y una con la evidencia. Así, el analista lee el texto y el sistema parsea el JSON. Nadie tiene que elegir.
Ejemplo de reporte sobre ataque DDoS:
From: Example ISP NOC <noc@example-isp.com>
To: abuse@upstream-provider.net
Subject: [XARF] ddos desde 192.0.2.100
Message-ID: <7d1e4f28-9b03-4a6c-8e51-c2f7a04b91d6@example-isp.com>
Date: Mon, 15 Jan 2024 10:00:32 +0000
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="----=_Part_XARF_9f31a"
------=_Part_XARF_9f31a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Automated abuse report.
Type: DDoS (UDP flood)
Source: 192.0.2.100:53
Destination: 203.0.113.50:53
First seen: 2024-01-15T09:52:00Z
Confidence: 0.95
See the attached XARF report for full details and evidence.
------=_Part_XARF_9f31a
Content-Type: message/feedback-report
Content-Disposition: inline
Feedback-Type: xarf
User-Agent: ExampleISP-AbuseReporter/2.0
Version: 1
------=_Part_XARF_9f31a
Content-Type: application/json; name="report.json"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.json"
ewogICJ4YXJmX3ZlcnNpb24iOiAiNC4yLjAiLAogICJyZXBvcnRfaWQiOiAiNTUw
ZTg0MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAwIiwKICAidGltZXN0YW1w
IjogIjIwMjQtMDEtMTVUMTA6MDA6MDBaIiwKICAicmVwb3J0ZXIiOiB7CiAgICAi
[... resto del JSON en base64 ...]
------=_Part_XARF_9f31a--
IODEF(RFC 7970) es el estándar del IETF para intercambio de incidentes. En formato XML, detallado que XARF.
STIX y MISP resultan herramientas ideales para el intercambio de inteligencia entre pares (como indicadores, campañas o TTPs), sin embargo, no fueron creadas con el fin de notificar a un operador que uno de sus clientes está realizando escaneos o aloja phishing.
Texto plano sigue siendo válido si respeta lo mínimo: recurso afectado, timestamp en UTC, tipo de abuso, evidencia y un contacto que responda. Un buen texto plano le gana a un JSON mal armado.
Qué podemos empezar a hacer
Si reportas: usa un formato estructurado, incluye siempre zona horaria, y consulta el abuse-c en el WHOIS/RDAP antes de enviarlo
Si recibes: valida tu contacto cuando LACNIC te lo pida, responde los reportes que recibas.
