123% di CVE segnalate in più al giorno nel 2026 rispetto all'anno scorso.

PSIRT

PSIRT vs CSIRT: vulnerabilità di prodotto e incidenti nel Suo IT

Un CSIRT interviene quando vengono attaccati i Suoi sistemi. Un PSIRT interviene quando i prodotti che Lei vende hanno una vulnerabilità a cui sono esposti i Suoi clienti. Sono entrambi team di risposta agli incidenti, seguono entrambi i framework FIRST e in un incidente reale spesso hanno bisogno l'uno dell'altro.

Aggiornato il

Che cos'è un CSIRT?

Un CSIRT (Computer Security Incident Response Team) è il team che gestisce gli incidenti di sicurezza per un gruppo definito di persone od organizzazioni, chiamato constituency. Il CSIRT Services Framework di FIRST lo definisce come un'unità organizzativa, anche virtuale, o una capacità che fornisce a quella constituency servizi per prevenire, rilevare, gestire e affrontare gli incidenti di sicurezza informatica.

È la constituency a determinare di che tipo di CSIRT si tratta:

  • CSIRT aziendale: reti, sistemi, account e dati di una singola azienda.
  • CSIRT di settore: un gruppo di organizzazioni di uno stesso comparto, come la finanza o l'energia.
  • CSIRT nazionale: un intero Paese, spesso con un ruolo nel coordinamento transfrontaliero.
  • Team del vendor: i clienti di un'azienda, per i problemi nei suoi prodotti. Questo è il PSIRT.

Il CSIRT Services Framework (versione 2.1) raggruppa i servizi di un CSIRT in cinque aree: gestione degli eventi di sicurezza delle informazioni, gestione degli incidenti di sicurezza delle informazioni, gestione delle vulnerabilità, consapevolezza situazionale e trasferimento di conoscenze.

Che cos'è un PSIRT?

Un PSIRT (Product Security Incident Response Team) è, secondo la definizione di FIRST, l'entità all'interno di un'organizzazione che si concentra sull'identificazione, la valutazione e la gestione dei rischi legati alle vulnerabilità di sicurezza dei prodotti che l'organizzazione realizza o vende. Riceve le segnalazioni di vulnerabilità, stabilisce quali prodotti e versioni sono interessati, fa sviluppare e rilasciare una correzione e informa i clienti tramite gli advisory.

Il suo framework, il PSIRT Services Framework (versione 1.1), ha sei aree di servizio: gestione dell'ecosistema degli stakeholder, scoperta delle vulnerabilità, triage e analisi delle vulnerabilità, remediation, divulgazione delle vulnerabilità, formazione e istruzione.

La differenza fondamentale

La differenza sta in quali sistemi sono a rischio. Un CSIRT protegge l'organizzazione: l'incidente è nel Suo ambiente e Lei lo contiene. Un PSIRT protegge i Suoi clienti: la vulnerabilità è nel Suo prodotto, in esecuzione nei loro ambienti, e Lei non può applicare la patch al posto loro. Rilascia una correzione e dice loro di installarla.

FIRST lo dice chiaramente: l'attenzione ai prodotti è l'elemento distintivo principale tra un PSIRT e gli altri team di risposta agli incidenti della stessa organizzazione, e un CSIRT aziendale si concentra in genere sui sistemi e sulle reti che compongono l'infrastruttura dell'organizzazione stessa.

PSIRT e CSIRT a confronto

CSIRT aziendale PSIRT
Ambito Incidenti nelle reti, nei sistemi e nei dati dell'organizzazione Vulnerabilità nei prodotti che l'organizzazione distribuisce
Constituency Dipendenti e sistemi interni Clienti e utenti dei prodotti
Input tipici Alert, log, segnalazioni degli utenti, threat intelligence Segnalazioni dei ricercatori, advisory su componenti di terze parti, test interni, coordinatori
Output tipici Incidenti contenuti, sistemi ripristinati, analisi post-incidente Release corrette, advisory di sicurezza, record CVE, notifiche ai clienti
Quando parte il cronometro Quando viene rilevato un incidente Quando una vulnerabilità viene segnalata o pubblicata
Responsabile tipico Il CISO o la sicurezza IT La product security o l'engineering
Framework FIRST CSIRT Services Framework 2.1 PSIRT Services Framework 1.1
Standard ISO/IEC 27035 (gestione degli incidenti) ISO/IEC 29147 (divulgazione delle vulnerabilità), ISO/IEC 30111 (gestione delle vulnerabilità)

Entrambi i framework sottolineano che i team non lavorano isolati. Il framework PSIRT descrive i CSIRT, compresi quelli nazionali, come stakeholder con cui un PSIRT dovrebbe costruire relazioni, perché spesso è grazie a loro che un vendor viene a sapere per tempo di una vulnerabilità.

CERT vs CSIRT

Il primo team di questo tipo è stato il CERT Coordination Center, che, secondo il SEI, è nato dalla risposta al worm Morris nel 1988, con finanziamenti DARPA, presso il Software Engineering Institute della Carnegie Mellon. CERT è un marchio registrato negli Stati Uniti dalla Carnegie Mellon University, e il SEI autorizza i team statunitensi a usarlo nel proprio nome. Non concede più il marchio in licenza al di fuori degli Stati Uniti.

Quindi "CERT" e "CSIRT" descrivono lo stesso tipo di team. CSIRT è il termine neutro, usato da FIRST e nel diritto dell'UE; molti team, soprattutto quelli nazionali, hanno ancora CERT nel nome.

CSIRT nazionali e coordinatori

Alcune organizzazioni contano per un team di prodotto perché si collocano tra chi trova le vulnerabilità, i vendor e gli utenti:

  • CERT/CC coordina la divulgazione delle vulnerabilità software dal 1988 e pubblica una guida alla divulgazione coordinata delle vulnerabilità per le organizzazioni che costruiscono il proprio processo.
  • CISA coordina la divulgazione tra segnalatori, fabbricanti e utenti negli Stati Uniti e può pubblicare già 45 giorni dopo il primo tentativo di contattare un vendor che non risponde, che esista o meno una correzione.
  • CSIRT nazionali dell'UE. La NIS2 impone a ogni Stato membro di designare o istituire uno o più CSIRT, che cooperano nel CSIRTs Network insieme a CERT-EU. L'ENISA, l'agenzia dell'UE per la cibersicurezza, ne fornisce il segretariato.

I CSIRT nazionali hanno anche un ruolo formale nella segnalazione delle vulnerabilità. Ai sensi dell'articolo 12 della NIS2, ogni Stato membro designa un CSIRT come coordinatore per la divulgazione coordinata delle vulnerabilità: un intermediario di fiducia tra chi segnala una vulnerabilità e il fabbricante, che può identificare i vendor interessati, assistere il segnalatore e negoziare le tempistiche di divulgazione. Il Cyber Resilience Act si basa sullo stesso ruolo: i fabbricanti notificano le vulnerabilità attivamente sfruttate nei propri prodotti al CSIRT designato come coordinatore e, contemporaneamente, all'ENISA.

Come collaborano un PSIRT e un CSIRT

Prenda un componente open source vulnerabile e sotto attacco, usato sia nel Suo prodotto sia nei Suoi sistemi interni. Entrambi i team ricevono lo stesso advisory e ciascuno ha il proprio compito:

  1. CSIRT: individua il componente su server e laptop interni, controlla nei log se è stato sfruttato, applica la patch o isola, e gestisce un incidente se qualcosa è stato compromesso.
  2. PSIRT: stabilisce quali prodotti, versioni e build includono il componente, valuta se il prodotto è interessato, rilascia una versione corretta e pubblica un advisory, con una dichiarazione VEX per le versioni non interessate.
  3. Entrambi: condividono indicatori e cronologie. Se il CSIRT scopre che l'attacco ha raggiunto il sistema di build, il PSIRT deve verificare se qualche release distribuita è stata manomessa, e questo trasforma un incidente interno in un incidente di prodotto. Un attacco alla supply chain di solito supera questo confine.

Il passaggio che rallenta il PSIRT è il secondo. Un CSIRT può scansionare il proprio parco sistemi. Un PSIRT deve rispondere di software già nelle mani dei clienti, il che significa sapere che cosa è entrato in ogni release distribuita. Le pagine sul ciclo di vita della gestione delle vulnerabilità e sulla divulgazione coordinata delle vulnerabilità coprono il resto del percorso del PSIRT verso una correzione.

CSIRT vs SOC

Un Security Operations Center (SOC) osserva: monitora alert e log 24 ore su 24, filtra il rumore e inoltra ciò che sembra reale. Un CSIRT risponde: prende in carico l'incidente confermato, lo contiene, indaga, si coordina con l'ufficio legale e la comunicazione e guida il ripristino. Nelle organizzazioni più piccole SOC e CSIRT sono spesso le stesse persone, e il SEI sottolinea che il nome di un team, CSIRT, SOC o altro, conta meno delle funzioni che svolge.

Nessuno dei due sostituisce un PSIRT. Un SOC monitora il Suo ambiente; non può vedere una vulnerabilità in un dispositivo gestito da un cliente.

Le servono entrambi?

Se realizza software o dispositivi e gestisce anche il proprio IT, Le servono entrambe le funzioni. Non Le servono due reparti. I piccoli vendor spesso iniziano con un unico responsabile della sicurezza che gestisce la risposta agli incidenti per l'azienda e un processo PSIRT scritto per i prodotti, con l'engineering reperibile per le correzioni. A dover essere separato è il processo: un incidente interno e una vulnerabilità di prodotto hanno responsabili diversi, scadenze diverse e persone diverse da informare.

Il ruolo di CRACI

CRACI supporta il lato PSIRT: sapere che cosa contiene il software che Lei distribuisce. Esegue le Sue build GitHub Actions sui propri runner, registra i pacchetti che ogni job ha effettivamente scaricato, comprese le dipendenze transitive e i pacchetti ripristinati dalle cache, ed esporta le SBOM in CycloneDX o SPDX.

Le SBOM monitorate vengono rivalutate continuamente e la cronologia delle build mostra quali build passate contenevano una dipendenza vulnerabile. La vista dell'inventario mostra quali versioni sono distribuite su quali prodotti, e i team di sicurezza esaminano i rilevamenti e li inoltrano ai team responsabili della correzione. Veda il tracciamento delle vulnerabilità e CRACI per i PSIRT.

PSIRT vs CSIRT: domande frequenti

Che cos'è un CSIRT?

Un Computer Security Incident Response Team. FIRST lo definisce come un'unità organizzativa, anche virtuale, o una capacità che fornisce servizi e supporto a una constituency definita per prevenire, rilevare, gestire e affrontare gli incidenti di sicurezza informatica. La constituency può essere una singola azienda, un settore o un intero Paese.

Qual è la differenza tra un PSIRT e un CSIRT?

Un PSIRT gestisce le vulnerabilità nei prodotti che un'azienda vende, a cui sono esposti i suoi clienti. Un CSIRT aziendale gestisce gli incidenti di sicurezza nei sistemi e nelle reti dell'azienda. Secondo FIRST, l'attenzione ai prodotti è l'elemento distintivo principale tra i due.

Un CERT è la stessa cosa di un CSIRT?

Dal punto di vista funzionale, sì. CERT è un marchio registrato negli Stati Uniti dalla Carnegie Mellon University, il cui CERT Coordination Center è stato il primo team di questo tipo, istituito nel 1988 dopo il worm Morris. CSIRT è il termine generico. Molti team nazionali usano CERT nel proprio nome, e l'UE usa CSIRT nella sua legislazione.

Qual è la differenza tra un SOC e un CSIRT?

Un SOC monitora e rileva 24 ore su 24: osserva alert e log e inoltra ciò che sembra reale. Un CSIRT è responsabile della risposta agli incidenti confermati: contenimento, indagine, coordinamento e ripristino. In molte organizzazioni i due si sovrappongono o condividono le persone, e il SEI osserva che ciò che conta sono le funzioni che un team svolge, non il suo nome.

Ci servono sia un PSIRT sia un CSIRT?

Se vende software o dispositivi e gestisce anche il proprio IT, Le servono entrambe le funzioni, anche se non necessariamente due reparti. In una piccola azienda spesso le stesse poche persone coprono entrambe, con processi separati: uno per gli incidenti nel Suo ambiente, uno per le vulnerabilità in ciò che distribuisce.

Che cosa fa un CSIRT nazionale?

Gestisce gli incidenti per una constituency nazionale, condivide gli allarmi e si coordina oltre confine. Ai sensi della NIS2, ogni Stato membro dell'UE designa almeno un CSIRT, e uno di essi agisce da coordinatore per la divulgazione coordinata delle vulnerabilità: un intermediario di fiducia tra chi segnala una vulnerabilità e il fabbricante.

Sappia quali build contengono un componente vulnerabile

Quando arriva un advisory, il Suo PSIRT deve sapere dove viene distribuito il componente. Prenoti una demo per vederlo da un registro di ciò che ogni build ha scaricato.

Prenota una demo