Se você já abriu sua caixa de abuse em uma manhã de segunda-feira, certamente se lembrará desta cena: centenas de e-mails, cada um com seu próprio formato, alguns com um registro colado sem contexto, outros com um PDF anexado. E no meio de tudo isso, um relatório que era realmente importante, mas você não teve tempo suficiente para analisá-lo.
Do outro lado, a história parece. Reportamos um incidente, não recebemos resposta e nunca sabemos se o problema foi a caixa de entrada, o formato ou se ninguém teve tempo de ler a nossa mensagem.
Não deve exigir o uso de um formulário para denunciar um abuso.
Deve garantir que as denúncias de abuso, logs, cabeçalhos, exemplos etc., relacionadas ao caso de abuso, sejam recebidas.
Em outras palavras: a caixa existe, é obrigatória e alguém se comprometeu por escrito a lê-la. O problema, então, é outro.
Por que um humano não consegue dar conta
Qual é o problema, então? É que não há um idioma comum. A Abusix, empresa por trás do XARF, afirma que precisou desenvolver mais de 500 parsers diferentes para poder processar os relatórios que os seus clientes recebem: cada fonte cria seu próprio formato.
Não deve exigir o uso de um formulário para denunciar um abuso.
Deve garantir que as denúncias de abuso, logs, cabeçalhos, exemplos etc., relacionadas ao caso de abuso, sejam recebidas.
Em outras palavras: a caixa existe, é obrigatória e alguém se comprometeu por escrito a lê-la. O problema, então, é outro.
Por que um humano não consegue dar conta
Qual é o problema, então? É que não há um idioma comum. A Abusix, empresa por trás do XARF, afirma que precisou desenvolver mais de 500 parsers diferentes para poder processar os relatórios que os seus clientes recebem: cada fonte cria seu próprio formato.
Um relatório em texto livre costuma falhar no básico:
a data sem indicar o fuso horário,
o IP de origem sem porta, não especificar o protocolo,
evidência sem o registro de data e hora que a vincula ao evento.
XARF: o formato pensado para este caso
O XARF (eXtended Abuse Reporting Format) é um formato de relatório de abuso baseado em JSON, mantido pela comunidade em xarf.org. A versão atual é a v4, que organiza 32 tipos de incidentes em 7 categorias —de spam e phishing a ataques de rede e vulnerabilidades—, cada um com seu próprio esquema.
O mínimo exigido pela v4 são sete campos: versão do esquema, identificador único, timestamp do incidente, quem reporta, a origem do abuso e a dupla categoria e tipo. Atenção para a origem: ela aponta para o IP ou o domínio infrator, não para a vítima. A evidência consta como recomendada, embora na prática seja o que torna o relatório acionável. Existe um detalhe de grande utilidade para os CSIRT: a v4 estabelece a distinção entre reporter (quem detectou o abuso) e sender (quem envia o relatório), justamente para o caso de um CERT nacional que reporta em nome de seus membros.
Para enviá-lo por e-mail, o XARF usa o ARF (RFC 5965): uma mensagem multipart/report de três partes, uma legível por humanos, uma legível por máquinas e uma com as evidências. Assim, o analista lê o texto e o sistema faz o parse do JSON. Ninguém precisa escolher.
Exemplo de relatório de ataque DDoS:
E-mail:
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
Versão: 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) é o padrão do IETF para troca de incidentes. Em formato XML, é mais detalhado que o XARF.
STIX e MISP são ferramentas ideais para a troca de inteligência entre pares (como indicadores, campanhas ou TTP); no entanto, não foram criadas com o objetivo de notificar um operador de que um de seus clientes está realizando varreduras ou hospedando phishing.
O texto simples continua sendo válido se respeitar os requisitos mínimos: recurso afetado, registro de data e hora em UTC, tipo de abuso, evidências e um contato que responda. Um bom texto simples ganha de um JSON mal formatado.
O que podemos começar a fazer
Se você reporta: use um formato estruturado, inclua sempre o fuso horário e consulte o abuse-c no WHOIS/RDAP antes de enviar.
Se você recebe: valide seu contato quando o LACNIC solicitar e responda aos relatórios recebidos.
