← Intelligence_Dept / LOG_ID_RFC-9116-SECURITY-TXT-ARCHITETTURA-DELLA-FIDUCIA

RFC 9116: Architettura della Fiducia oltre la Compliance

Author Sigilium Intelligence
Tags
SECURITY RFC-9116 PGP INFRASTRUCTURE

In caso di vulnerabilità critica, il Time-to-Mitigation (TTM) è l’unica metrica che conta. Eppure, vedo ancora aziende che trattano l’ingestion delle segnalazioni come un ticket di supporto generico: “Scrivi a info@”. Questo è broken by design. In uno scenario di crisi, cercare un contatto valido non deve richiedere OSINT. Deve essere deterministico.

Oltre il file di testo: RFC 9116

L’adozione della RFC 9116 (/.well-known/security.txt) rimuove l’attrito iniziale, fornendo un endpoint standardizzato per i ricercatori. Tuttavia, fermarsi all’implementazione base è ingenuo in un ambiente Zero Trust. Se un attaccante compromette il frontend e inietta un security.txt malevolo, può dirottare le segnalazioni dei ricercatori verso se stesso, comprandosi tempo prezioso mentre l’escalation dei privilegi continua indisturbata.

Per l’infrastruttura Sigilium, il file di testo non è sufficiente. Abbiamo implementato una validazione crittografica per garantire l’integrità del canale di segnalazione indipendentemente dallo stato del server web.

1. Chain of Trust Off-Line (OpenPGP)

Non serviamo un semplice file statico. Il nostro security.txt è firmato tramite Cleartext Signature con una chiave RSA-4096, le cui chiavi private risiedono su hardware air-gapped. La presenza della firma non è decorativa; trasforma il file in un artefatto verificabile.

Un ricercatore (o un sistema automatizzato) può validare la policy indipendentemente dal trasporto TLS:

# Verifica trustless della policy Sigilium
curl -sO https://www.sigilium.it/.well-known/security.txt
curl -sO https://www.sigilium.it/.well-known/security.txt.sig

# Se il server è compromesso e il contenuto alterato, questa verifica fallisce
gpg --verify security.txt.sig security.txt

Questo agisce come un canary passivo: se la firma è invalida, l’integrità dell’infrastruttura di front-end è già compromessa.

2. Canonical Hardcoding anti-spoofing

Il campo Canonical è spesso ignorato, ma è critico per mitigare attacchi di mirroring. Abbiamo forzato il binding tra il contenuto firmato e l’URL di residenza. Se un attaccante clona il sito su un dominio look-alike (sigillium.it) per intercettare traffico o segnalazioni, la discrepanza tra il canonico firmato e l’URL hostato rompe la catena di fiducia agli occhi dei bot di sicurezza e dei ricercatori attenti.

The Takeaway

L’ingegneria della sicurezza non riguarda solo la protezione degli asset, ma la resilienza dei protocolli di comunicazione durante il fallimento. Implementare la RFC 9116 con firma PGP e vincolo canonico non è burocrazia. È la differenza tra gestire un incidente in minuti o accorgersene quando è troppo tardi.