STIX e TAXII sono due standard OASIS complementari per rappresentare e scambiare Cyber Threat Intelligence (CTI). STIX definisce struttura, semantica e relazioni delle informazioni sulle minacce; TAXII definisce come client e server le pubblicano, le interrogano e le trasferiscono tramite API. In sintesi: STIX descrive il dato, TAXII ne governa il trasporto.
Usati insieme, permettono a CERT, SOC, Threat Intelligence Platform, SIEM, XDR e sistemi di automazione di condividere indicatori, osservazioni, malware, campagne, attori e contromisure in formato machine-readable. Per leggere correttamente i termini collegati, è disponibile anche il glossario Cybersecurity di Nexsys.
![minemeld: threat intelligence automation – connect to stix/taxii service [5] – scubarda](https://scubarda.com/wp-content/uploads/2018/03/stix-taxii-logo-small.png?w=300 "stix e taxii: cosa sono, differenze e come funzionano nella threat intelligence"){kind=logo}
STIX e TAXII in breve
| Standard | Funzione | Risponde alla domanda | Elemento operativo |
|---|---|---|---|
| STIX 2.1 | Linguaggio e formato di serializzazione per la CTI | Che cosa significa il dato? | Oggetti JSON, proprietà, pattern e relazioni |
| TAXII 2.1 | Protocollo applicativo e API REST per lo scambio di CTI | Come viene trasferito il dato? | Discovery, API Root, Collection, Manifest, Objects e Status |
La distinzione è fondamentale. Un file STIX può essere archiviato, inviato via canale sicuro o importato manualmente senza TAXII. Allo stesso modo, TAXII è progettato per STIX ma non trasforma automaticamente dati grezzi o non normalizzati in intelligence di qualità.
Cos’è STIX 2.1
STIX, acronimo di Structured Threat Information Expression, è un linguaggio e un formato di serializzazione per descrivere informazioni cyber in modo coerente e leggibile sia dalle persone sia dalle macchine. La versione 2.1 usa JSON e assegna a ogni entità proprietà, identificatori, timestamp, relazioni e marcature che consentono di correlare informazioni provenienti da fonti diverse.
Il valore di STIX non consiste nel rappresentare soltanto un indirizzo IP, un dominio o un hash. Consiste nel collegare l’osservabile al contesto: quale campagna lo ha utilizzato, quale malware è coinvolto, quale threat actor è associato, quali tecniche sono state osservate, quanto è attendibile la fonte e quali azioni di risposta sono pertinenti.
Le principali categorie di oggetti STIX
STIX Domain Objects (SDO): descrivono concetti di intelligence come Indicator, Malware, Threat Actor, Campaign, Intrusion Set, Attack Pattern, Infrastructure, Vulnerability, Report e Course of Action.
STIX Cyber-observable Objects (SCO): rappresentano elementi osservabili come indirizzi IPv4/IPv6, domini, URL, file, processi, account, chiavi di registro, traffico di rete e certificati X.509.
STIX Relationship Objects (SRO): esprimono relazioni e avvistamenti, collegando per esempio un malware a un’infrastruttura o un indicatore a una campagna.
STIX Meta Objects (SMO): aggiungono informazioni trasversali, tra cui marcature di distribuzione e contenuti localizzati.
Un Bundle STIX è un contenitore usato per raggruppare più oggetti durante uno scambio. Non attribuisce automaticamente fiducia, priorità o validità agli elementi contenuti: queste qualità devono essere definite mediante proprietà, marking, policy e processi di governance.
Esempio minimo di oggetto Indicator
L’esempio seguente descrive un pattern su un dominio dimostrativo. Il valore .test è riservato e non identifica un’infrastruttura reale.
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--0a1b2c3d-4e5f-4678-9abc-def012345678",
"created": "2026-07-29T10:00:00.000Z",
"modified": "2026-07-29T10:00:00.000Z",
"name": "Rilevamento dominio malevolo",
"pattern": "[domain-name:value = 'example-malicious.test']",
"pattern_type": "stix",
"pattern_version": "2.1",
"valid_from": "2026-07-29T10:00:00.000Z"
}Un oggetto Indicator non coincide con un semplice IoC. Contiene un pattern destinato al rilevamento e può essere collegato a osservazioni, campagne, malware, fonti e livelli di confidenza. Questa distinzione riduce l’errore frequente di trattare qualsiasi valore ricevuto da un feed come evidenza certa di compromissione.
Cos’è TAXII 2.1
TAXII, acronimo di Trusted Automated Exchange of Intelligence Information, è un protocollo applicativo che definisce una REST API per scambiare Cyber Threat Intelligence in modo scalabile. I client interagiscono con server TAXII tramite HTTPS, usando risorse e media type standardizzati. Il protocollo è stato progettato intorno a STIX 2, pur non essendo formalmente limitato a quel solo formato.
La struttura logica di TAXII 2.1 separa discovery, perimetri di accesso e raccolte dati. Questo consente allo stesso server di pubblicare collection differenti per clienti, community, settori o trust group, applicando autorizzazioni e criteri di distribuzione distinti.
Componenti principali di TAXII 2.1
Discovery: permette a un client autorizzato di individuare gli API Root esposti dal server.
API Root: rappresenta un’istanza logica dell’API e delimita collection, policy e trust group.
Collection: interfaccia verso un repository logico di oggetti CTI. Può consentire lettura, scrittura o entrambe.
Manifest: espone metadati sulle versioni degli oggetti presenti in una collection, evitando di scaricare subito l’intero contenuto.
Objects: endpoint per ottenere, aggiungere, eliminare o interrogare oggetti e relative versioni, secondo le capacità del server.
Status: consente di verificare l’esito di una pubblicazione asincrona e distinguere oggetti accettati, pendenti o rifiutati.
Attenzione alle versioni
Le voci Discovery, Collection Management, Inbox e Poll appartengono all’architettura TAXII 1.x. TAXII 2.1 è organizzato come API REST intorno a Discovery, API Root, Collection, Manifest, Objects e Status. La specifica 2.1 descrive il concetto di Channel, ma ne riserva i servizi a una versione successiva: non va presentato come endpoint operativo già definito dallo standard.
Come comunicano client e server TAXII
Un client può interrogare una collection con richieste GET, filtrare per tipo, ID, versione o data di inserimento e ricevere gli oggetti in una TAXII Envelope. Per pubblicare CTI usa normalmente POST verso l’endpoint objects della collection; il server risponde con uno status che può richiedere verifiche successive.
GET /api-root/collections/{collection-id}/objects/?match[type]=indicator Accept: application/taxii+json;version=2.1
POST /api-root/collections/{collection-id}/objects/ Accept: application/taxii+json;version=2.1 Content-Type: application/taxii+json;version=2.1
L’interoperabilità reale richiede comunque accordo su autenticazione, autorizzazioni, versioni supportate, filtri, paginazione, marcature, retention e gestione degli errori. La compatibilità sintattica non sostituisce una trust policy.
Differenza tra STIX e TAXII
| Aspetto | STIX | TAXII |
|---|---|---|
| Natura | Linguaggio, data model e serializzazione | Protocollo applicativo e API REST |
| Scopo | Rappresentare CTI e relazioni | Scambiare CTI tra client e server |
| Formato | Oggetti JSON STIX 2.1 | Risorse JSON, header HTTP e TAXII Envelope |
| Unità chiave | Indicator, Malware, Threat Actor, Observed Data, Relationship | API Root, Collection, Manifest, Objects, Status |
| Domanda | Che cosa significa questa informazione? | Come la recupero, pubblico o sincronizzo? |
| Limite | Non definisce da solo il canale di trasporto | Non garantisce qualità, attendibilità o rilevanza dei dati |
Come funzionano insieme STIX e TAXII
Il flusso operativo più comune parte da dati eterogenei e termina in una decisione di detection o risposta. La pipeline può essere automatizzata, ma ogni passaggio deve conservare provenienza, contesto e controllo umano.
Raccolta: una TIP, un CERT, un ISAC, un vendor o un team interno acquisisce indicatori, osservazioni e report da fonti affidabili.
Normalizzazione: i dati vengono convertiti in oggetti STIX 2.1, deduplicati e collegati tramite relazioni coerenti.
Arricchimento: si aggiungono fonte, confidenza, marking, validità temporale, contesto di campagna, malware e TTP.
Pubblicazione: gli oggetti vengono inseriti in una TAXII Collection con policy di accesso e distribuzione definite.
Ingestione: SIEM, XDR, TIP o sistemi di threat hunting interrogano la collection, recuperano gli aggiornamenti e applicano filtri.
Operationalization: gli analisti trasformano l’intelligence in query, watchlist, regole di detection, priorità di triage o azioni di risposta.
Dall'IoC alla Cyber Threat Intelligence azionabile
Un feed con migliaia di IP, hash e domini non è automaticamente Threat Intelligence. Un IoC isolato può essere scaduto, condiviso da servizi legittimi, generato da sandbox, non pertinente al proprio settore o già bloccato. STIX permette di arricchire il dato, ma non decide da solo se sia utile.
Per rendere l’informazione azionabile occorre associare almeno provenienza, timestamp, livello di confidenza, periodo di validità, classificazione TLP o marking equivalente, contesto dell’attacco, asset potenzialmente esposti e azione prevista. La priorità deve derivare dall’incrocio tra attendibilità della fonte, rilevanza per l’organizzazione e impatto sul perimetro reale.
Regola operativa
Un indicatore senza contesto alimenta rumore. Un indicatore contestualizzato, correlato a TTP e verificato sulla telemetria interna può alimentare una detection, un’attività di hunting o una decisione di contenimento.
STIX, TAXII e MITRE ATT&CK
STIX non sostituisce MITRE ATT&CK. I due strumenti svolgono funzioni diverse: ATT&CK fornisce una knowledge base sui comportamenti avversari; STIX consente di rappresentare e scambiare oggetti, relazioni e pattern di CTI. Una piattaforma può quindi collegare un Attack Pattern STIX a una tecnica ATT&CK, associare la tecnica a un threat actor e usare il risultato per misurare la copertura delle detection.
Questa integrazione sposta il focus dagli IoC più volatili alle tattiche, tecniche e procedure. Un dominio o un hash può cambiare in ore; un comportamento avversario tende a essere più stabile e consente di progettare controlli meno fragili.
Integrazione con MISP, TIP, XDR e SOAR
STIX e TAXII diventano realmente utili quando sono inseriti in una catena operativa. MISP e le Threat Intelligence Platform possono normalizzare e distribuire indicatori; SIEM e XDR correlano l’intelligence con la telemetria; SOAR e playbook orchestrano le azioni previste. La presenza di un connettore, tuttavia, non prova che l’integrazione sia efficace.
TIP/MISP: consolidamento delle fonti, deduplicazione, enrichment, scoring, marking e distribuzione selettiva.
SIEM: confronto con eventi storici e correnti, watchlist, correlazioni e query di threat hunting.
EDR/XDR: ricerca su endpoint, identità, email, cloud e rete; blocco o containment quando il contesto lo giustifica.
SOAR: approvazioni, enrichment automatico, ticketing, isolamento, revoca di sessioni e raccolta delle evidenze.
Case management: tracciamento di fonte, decisione, analista, azione eseguita ed esito per audit e miglioramento continuo.
Casi d'uso di STIX e TAXII
Condivisione: tra CERT, ISAC, enti pubblici, supply chain e organizzazioni appartenenti allo stesso trust group.
Distribuzione: di indicatori e campagne verso SOC, SIEM, XDR, firewall, DNS security e sistemi di email security.
Threat hunting retrospettivo: ricerca nella telemetria storica di indicatori o comportamenti collegati a una nuova campagna.
Arricchimento del triage: collegare un alert a malware, infrastruttura, threat actor, vulnerabilità sfruttata e tecniche osservate.
Incident response: preservare e distribuire rapidamente gli indicatori verificati, integrandoli in un Incident Response Plan con ruoli, autorizzazioni e procedure definite.
Purple teaming e detection engineering: mappare TTP, verificare copertura e trasformare i gap in nuove regole o casi di test.
Vantaggi per SOC e aziende
Lo standard comune riduce il lavoro necessario per tradurre formati proprietari, facilita il passaggio tra piattaforme e rende più ripetibile il ciclo di acquisizione, validazione e distribuzione della CTI. Il beneficio principale non è ricevere più indicatori, ma rendere più rapido il passaggio dal dato alla decisione.
Interoperabilità: tra prodotti, community e organizzazioni diverse.
Automazione: di import, export, sincronizzazione e aggiornamento delle collection.
Relazioni esplicite: tra osservabili, indicatori, campagne, malware, attori e contromisure.
Riduzione dei passaggi manuali: e degli errori di formattazione.
Maggiore tracciabilità: di fonte, marking, versioni e ciclo di vita degli oggetti.
Migliore integrazione: tra Threat Intelligence, detection engineering, hunting e incident response.
Limiti e rischi da governare
STIX e TAXII risolvono interoperabilità e trasporto, non la qualità intrinseca dell’intelligence. Automatizzare senza governance può produrre falsi positivi, blocchi impropri, sovraccarico degli analisti o diffusione eccessiva di informazioni sensibili.
Qualità della fonte: definire attendibilità, provenienza, metodo di raccolta e criteri di revoca.
Obsolescenza: applicare validità, TTL, versioning e procedure di rimozione agli indicatori volatili.
Duplicazione: normalizzare e deduplicare prima dell’ingestione per evitare moltiplicazione di alert equivalenti.
Distribuzione: rispettare marking, TLP, accordi di condivisione, privacy e requisiti contrattuali.
Sicurezza del servizio TAXII: usare TLS, validare i certificati, applicare least privilege per collection, ruotare le credenziali e monitorare accessi ed errori.
Automazione: distinguere enrichment, alerting e blocco; le azioni ad alto impatto devono richiedere soglie robuste o approvazione umana.
Checklist per implementare STIX/TAXII 2.1
01. Definire l’obiettivo: sharing, ingestion, hunting, arricchimento, detection o risposta. Senza un caso d’uso misurabile, il feed diventa rumore.
02. Verificare le versioni: supportate da client e server, inclusi media type, pattern STIX, filtri e gestione delle versioni oggetto.
03. Progettare API Root e Collection: in base a trust group, sensibilità, tenant, cliente o finalità operativa.
04. Stabilire policy: per autenticazione, autorizzazione, marking, TLP, retention, logging e revoca degli accessi.
05. Normalizzare i dati: fonte, confidence, valid_from, valid_until, first_seen, last_seen e relazioni prima della distribuzione.
06. Applicare deduplicazione: scoring e filtri di rilevanza per settore, geografia, tecnologia e asset aziendali.
07. Testare il mapping: verso SIEM, XDR, TIP e SOAR, verificando che le proprietà utili non vadano perse durante l’import.
08. Separare le azioni automatiche: distinguere i processi a basso rischio dalle azioni distruttive o bloccanti, che richiedono validazione più forte.
09. Misurare indicatori operativi: tasso di hit, falsi positivi, tempo di ingestione, oggetti scaduti, errori di parsing e detection generate.
10. Eseguire revisioni periodiche: di feed, collection, credenziali, permessi, mapping e valore prodotto per gli analisti.
Competenze necessarie per usare STIX e TAXII
La configurazione tecnica di un connettore è solo una parte del lavoro. Servono capacità di CTI analysis, JSON e API REST, gestione delle identità, detection engineering, threat hunting, incident response e valutazione della qualità delle fonti. Per i team che devono consolidare la risposta agli incidenti, il corso Incident Responder approfondisce triage, contenimento, analisi e procedure operative.
Domande frequenti su STIX e TAXII
STIX e TAXII sono la stessa cosa?
No. STIX è il linguaggio che struttura la Cyber Threat Intelligence; TAXII è il protocollo applicativo usato per scambiarla tramite API. Possono essere usati separatamente, ma insieme formano una pipeline interoperabile.
STIX 2.1 è basato su JSON?
Sì. STIX 2.1 usa JSON per serializzare oggetti, proprietà e relazioni. Essere JSON non basta però a rendere un documento conforme: tipi, identificatori, timestamp, proprietà obbligatorie e pattern devono rispettare la specifica.
TAXII 2.1 usa sempre STIX?
TAXII è progettato per lo scambio di STIX 2 e i requisiti della specifica sono costruiti su questo scenario. Il protocollo non vieta in assoluto altri formati, ma la massima interoperabilità si ottiene usando STIX 2.1.
Qual è la versione di riferimento?
Le versioni OASIS di riferimento sono STIX 2.1 e TAXII 2.1. In una nuova integrazione è necessario verificare il supporto effettivo di client e server, perché prodotti e connettori possono implementare sottoinsiemi differenti.
TAXII 2.1 supporta i Channel publish-subscribe?
La specifica descrive il concetto di Channel, ma riserva i relativi servizi a una versione successiva. In TAXII 2.1 l’interoperabilità operativa standardizzata è centrata sulle Collection e sul modello request-response tramite endpoint REST.
Qual è la differenza tra Observable e Indicator?
Un Observable rappresenta un fatto o artefatto osservabile, per esempio un dominio, un file o un evento di rete. Un Indicator contiene un pattern destinato a rilevare attività di interesse e può includere validità e relazioni con altro contesto CTI.
STIX sostituisce MITRE ATT&CK?
No. ATT&CK organizza tattiche, tecniche e procedure avversarie; STIX rappresenta e scambia dati e relazioni di Threat Intelligence. Possono essere integrati per collegare campagne, threat actor e indicatori alle tecniche ATT&CK.
Un feed STIX/TAXII può essere bloccato automaticamente?
Tecnicamente sì, ma non è sempre corretto. Prima di bloccare occorre valutare fonte, confidence, data di validità, contesto, tipo di indicatore e impatto sull’ambiente. Gli indicatori a bassa confidenza dovrebbero alimentare enrichment o hunting, non azioni automatiche irreversibili.
Dalla Threat Intelligence alla detection operativa
Formazione e presidio operativo
Il corso Cybersecurity Blue Team di Nexsys sviluppa competenze su Threat Intelligence, MITRE ATT&CK, SIEM, XDR e threat hunting. Per le aziende che richiedono monitoraggio e risposta continuativi, il SOC as a Service integra telemetria, detection e gestione operativa degli eventi. Contatta Nexsys per definire il percorso coerente con strumenti, team e maturità del tuo ambiente.