PSIRT: che cosa fa un Product Security Incident Response Team

Che cos'è un PSIRT?

Un Product Security Incident Response Team (PSIRT) è la funzione che gestisce le vulnerabilità di sicurezza nei prodotti che un'azienda realizza e vende. FIRST lo definisce come un'entità che si concentra su "the identification, assessment and disposition of the risks associated with security vulnerabilities within the products", comprese offerte, soluzioni, componenti e servizi.

In pratica un PSIRT:

• gestisce il canale attraverso cui ricercatori, clienti e partner segnalano le vulnerabilità;
• sorveglia le vulnerabilità nei componenti di terze parti e open source contenuti nei suoi prodotti;
• esegue il triage di ogni segnalazione: è reale, quali prodotti e versioni colpisce, quanto è grave;
• fa sì che il team di engineering responsabile la corregga, con tempi commisurati al rischio;
• pubblica gli advisory e coordina la divulgazione con chi ha trovato la vulnerabilità e con i vendor a valle;
• riferisce le metriche al management e forma le persone che costruiscono i prodotti.

Gran parte del lavoro avviene dopo il rilascio. FIRST osserva che la maggior parte delle vulnerabilità di prodotto viene segnalata come difetto di qualità sfuggito ai controlli quando il prodotto è già sul mercato, sebbene un PSIRT aggiunga valore anche prima, nelle revisioni di progettazione e nel threat modeling.

Dove si colloca un PSIRT nell'organizzazione

La differenza rispetto ad altri team di sicurezza è l'attenzione ai prodotti. Un CSIRT aziendale protegge i sistemi e le reti dell'azienda; un PSIRT protegge i clienti che utilizzano i prodotti dell'azienda. I due condividono competenze e spesso una linea di riporto, e si incontrano quando un incidente nell'infrastruttura dell'azienda, come un sistema di build compromesso, raggiunge un prodotto. Il confronto completo è in PSIRT e CSIRT a confronto.

FIRST descrive tre modelli operativi:

• Distribuito: un piccolo PSIRT centrale definisce le policy e coordina, mentre i referenti di sicurezza di ciascun team di prodotto si occupano di triage e correzioni. Scala su un portafoglio ampio e vario, ma le persone che svolgono il lavoro non riportano al PSIRT.
• Centralizzato: un PSIRT più grande con un proprio personale di gestione del programma, triage e remediation, che riporta a un dirigente senior per la sicurezza di prodotto. È adatto ad aziende più piccole o a un portafoglio uniforme e costa di più man mano che il portafoglio cresce.
• Ibrido: un mix dei due, scelto in base a dimensioni dell'azienda, portafoglio e strategia di sviluppo.

Qualunque sia il modello, FIRST sottolinea l'indipendenza: il PSIRT dovrebbe riportare a un dirigente che ne confermi l'autorità, così da poter assumere una posizione obiettiva sulle vulnerabilità nei prodotti dell'azienda.

Il FIRST PSIRT Services Framework

Il PSIRT Services Framework, pubblicato gratuitamente da FIRST e ora alla versione 1.1, è il riferimento su cui la maggior parte dei PSIRT costruisce il proprio catalogo di servizi. Definisce le basi operative (mandato, stakeholder, budget, policy) e poi sei aree di servizio:

Area di servizio	Che cosa comprende
1. Gestione dell'ecosistema degli stakeholder	Stakeholder interni, comunità di chi trova vulnerabilità, vendor a valle e clienti, comunicazioni sugli incidenti, riconoscimento di chi trova vulnerabilità, metriche sugli stakeholder
2. Scoperta delle vulnerabilità	Ricezione delle segnalazioni, individuazione di vulnerabilità non segnalate, monitoraggio dei componenti di prodotto per rilevare vulnerabilità, identificazione di nuove vulnerabilità, metriche di scoperta
3. Triage e analisi delle vulnerabilità	Qualificazione delle segnalazioni, collaborazione con ricercatori affermati, riproduzione delle vulnerabilità
4. Remediation	Piano di gestione del rilascio delle correzioni, remediation, gestione degli incidenti, metriche di rilascio
5. Divulgazione delle vulnerabilità	Notifica, coordinamento, divulgazione tramite advisory, metriche di divulgazione
6. Formazione e istruzione	Formazione del PSIRT, dei team di sviluppo e validazione e di altri stakeholder; meccanismi di feedback

Un servizio merita di essere evidenziato perché è diventato una parte consistente del lavoro: il monitoraggio delle vulnerabilità dei componenti di prodotto. La sua prima funzione è un inventario dei componenti di prodotto, un elenco di vendor, prodotti e versioni inclusi in ciascun prodotto, che FIRST definisce "essential to quickly identify affected products for inherited vulnerabilities". Nel software moderno, questo inventario è una software bill of materials (SBOM).

Il processo PSIRT in sintesi

Due standard ISO/IEC descrivono il processo. ISO/IEC 30111:2019 riguarda il modo in cui un vendor gestisce internamente le vulnerabilità. ISO/IEC 29147:2018 riguarda il modo in cui riceve segnalazioni dall'esterno e pubblica le informazioni sulla remediation. 30111 è pensato per essere usato con 29147, e le fasi che descrive offrono una traccia utile:

1. Preparazione. Policy, ruoli, un modo pubblico per segnalare le vulnerabilità, un metodo di punteggio, un inventario di ciò che viene distribuito.
2. Ricezione. Raccogliere le segnalazioni di ricercatori, clienti e partner, quelle dei propri test e gli advisory sui componenti utilizzati. Dare riscontro a chi ha segnalato.
3. Verifica. Confermare la vulnerabilità, riprodurla, assegnarle un punteggio e determinare ogni prodotto e versione colpiti. Registrare anche i prodotti non colpiti, e perché.
4. Sviluppo della remediation. Il team responsabile sviluppa e testa una correzione o una mitigazione. Il PSIRT ne segue l'avanzamento rispetto ai tempi concordati.
5. Rilascio. Distribuire la correzione e pubblicare l'advisory, in coordinamento con chi ha segnalato e con i vendor a valle che integrano il prodotto.
6. Post-rilascio. Sorvegliare eventuali problemi della correzione, rispondere ai clienti e riportare le cause profonde nello sviluppo.

Ogni fase, con ciò che va registrato e chi ne è responsabile, è trattata nel ciclo di vita della gestione delle vulnerabilità. Per decidere quali risultati affrontare per primi, veda la prioritizzazione delle vulnerabilità, con i segnali di sfruttamento di EPSS e del catalogo CISA KEV. Una vulnerabilità sfruttata prima che esista una correzione è una zero-day, e il PSIRT la gestisce come un incidente. Il percorso dall'advisory a una build corretta e distribuita è trattato in remediation delle CVE.

Divulgazione e advisory

La divulgazione è la parte del PSIRT che i clienti vedono. La pratica abituale è la divulgazione coordinata delle vulnerabilità: chi trova la vulnerabilità la segnala privatamente, il vendor la corregge ed entrambi pubblicano in una data concordata, con il riconoscimento a chi l'ha trovata. Si parte da una policy pubblica di divulgazione delle vulnerabilità che indica come segnalare, che cosa possono aspettarsi i segnalatori e per quanto tempo i prodotti sono supportati. Veda la divulgazione coordinata delle vulnerabilità.

Un buon advisory dice a un cliente, senza bisogno di una telefonata:

• quali prodotti e versioni sono colpiti e quali no;
• l'ID CVE e un punteggio di gravità;
• la versione corretta, o una mitigazione se non esiste ancora una correzione;
• chi ha trovato la vulnerabilità.

I grandi clienti vogliono sempre più spesso advisory in un formato leggibile dalle macchine, da confrontare automaticamente con il proprio inventario degli asset. CSAF è il formato standard OASIS per gli advisory, e VEX è il modo per dichiarare che un prodotto non è colpito da una vulnerabilità in uno dei suoi componenti, il che risparmia un ticket a entrambe le parti.

Metriche e maturità del PSIRT

Il framework prevede metriche in ogni area di servizio. Le più comuni:

• tempo per dare riscontro a una segnalazione, per il triage e per rilasciare una correzione, per gravità;
• vulnerabilità aperte per prodotto, gravità e anzianità;
• quota di correzioni consegnate entro gli obiettivi di remediation pubblicati;
• vulnerabilità trovate internamente rispetto a quelle segnalate dall'esterno;
• advisory pubblicati e correzioni agli advisory.

Il documento complementare di FIRST, il PSIRT Maturity Document, organizza i servizi in tre livelli:

• Livello 1, base: sponsorship del management, stakeholder, budget e policy; un modo per ricevere segnalazioni; un workflow di triage; correzioni documentate; advisory che usano CVE e CVSS e danno riconoscimento a chi ha trovato la vulnerabilità.
• Livello 2, intermedio: uno statuto e un modello organizzativo, metriche di base, un registro dei prodotti con mappatura delle dipendenze, un piano formale di correzione, un sistema per informare gli stakeholder e la formazione del team.
• Livello 3, avanzato: rapporto diretto con la comunità di chi trova vulnerabilità, monitoraggio dei componenti di prodotto per rilevare vulnerabilità, metriche di scoperta e rilascio, gestione avanzata degli incidenti e playbook per il coordinamento di settore.

Il passaggio tra i livelli va dal reattivo al proattivo.

Come creare un PSIRT: partire con poco

1. Ottenga un mandato scritto da un dirigente, con l'autorità di chiedere ai team di prodotto di correggere i problemi.
2. Pubblichi come segnalare una vulnerabilità: un indirizzo di contatto per la sicurezza, un modulo web o un file security.txt, e una breve policy di divulgazione.
3. Definisca triage e punteggio: chi decide se una segnalazione è valida, come viene valutata la gravità e gli obiettivi di remediation per ogni livello di gravità.
4. Sappia che cosa distribuisce. Per ogni versione di prodotto, i componenti e le versioni che contiene. Senza queste informazioni, ogni nuova CVE in una libreria diffusa si trasforma in giorni di domande ai team di engineering.
5. Nomini un responsabile per prodotto che riceva i risultati e pianifichi le correzioni.
6. Scriva un modello di advisory e pubblichi il primo, anche per un problema di poco conto.
7. Misuri alcune tempistiche fin dall'inizio, così potrà dimostrare i miglioramenti.

La pagina dedicata ai team PSIRT esamina il ruolo dal punto di vista del responsabile della sicurezza di prodotto, e i vendor industriali possono mappare questi passaggi su IEC 62443-4-1, i cui requisiti del ciclo di vita di sviluppo sicuro comprendono la gestione dei difetti e delle patch.

Le normative che presuppongono un PSIRT

Un tempo un PSIRT era il segno di un vendor maturo. Oggi diversi framework ne richiedono i risultati. L'articolo 21, paragrafo 2, lettera e), della NIS2 elenca "vulnerability handling and disclosure" tra le misure che i soggetti essenziali e importanti devono adottare. Negli Stati Uniti, la sezione 524B impone ai produttori di dispositivi medici di presentare un piano per monitorare, identificare e affrontare le vulnerabilità post-commercializzazione, compresa la divulgazione coordinata delle vulnerabilità, insieme a una SBOM. E il Cyber Resilience Act dell'UE impone ai fabbricanti di segnalare alle autorità le vulnerabilità attivamente sfruttate e gli incidenti gravi, a partire da un preallarme entro 24 ore; veda che cos'è il CRA.

Gli strumenti di cui un PSIRT ha bisogno

Esigenza	Perché
Ricezione delle segnalazioni e tracciamento dei casi	Ogni segnalazione ha un responsabile, uno stato e una tempistica
Inventario di ciò che viene distribuito	Una SBOM accurata per ogni versione di prodotto, comprese le dipendenze transitive
Monitoraggio continuo	Le nuove CVE vengono confrontate con i componenti di ogni versione rilasciata, non solo della prossima
Triage e instradamento	I risultati arrivano al team responsabile della correzione, con il contesto per intervenire
Dichiarazioni di prodotto colpito e non colpito	VEX registra quali prodotti sono colpiti da una vulnerabilità e perché gli altri non lo sono
Pubblicazione degli advisory	Advisory leggibili dalle persone e CSAF leggibile dalle macchine per i grandi clienti

Pochi prodotti coprono ogni riga; gli strumenti PSIRT a confronto mostra quale strumento fa che cosa. L'inventario è il punto in cui la maggior parte dei PSIRT è in difficoltà. Uno scanner che legge i lockfile a posteriori elenca dipendenze di sviluppo che non vengono mai distribuite e non vede i pacchetti che la build ha scaricato al di fuori del package manager, quindi la risposta a "siamo colpiti?" parte dal dubbio.

CRACI ricava questo inventario dalla build stessa. Esegue le build GitHub Actions sui propri runner e registra i pacchetti effettivamente scaricati da ogni job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache CI e le dipendenze che nessun lockfile elenca. Ogni SBOM riporta uno stato di completezza e si esporta in CycloneDX o SPDX. Le SBOM monitorate vengono rivalutate continuamente man mano che vengono pubblicate nuove vulnerabilità, la cronologia delle build mostra quali build passate contenevano una dipendenza vulnerabile e la vista inventario mostra quali versioni del software sono distribuite in quali prodotti. I team di sicurezza eseguono il triage dei risultati e li inviano ai team responsabili della correzione, e CRACI supporta VEX. Veda il tracciamento delle vulnerabilità e CRACI per i team PSIRT.

PSIRT: domande frequenti

Che cosa significa PSIRT?

PSIRT sta per Product Security Incident Response Team. FIRST lo definisce come un'entità all'interno di un'organizzazione che si concentra sull'identificazione, la valutazione e il trattamento dei rischi associati alle vulnerabilità di sicurezza nei prodotti, nelle offerte, nelle soluzioni, nei componenti e nei servizi che l'organizzazione produce o vende.

Qual è la differenza tra un PSIRT e un CSIRT?

Un PSIRT gestisce le vulnerabilità nei prodotti che un'azienda distribuisce ai clienti. Un CSIRT aziendale gestisce gli incidenti di sicurezza nei sistemi e nelle reti dell'azienda. I due collaborano, ad esempio quando una violazione dell'infrastruttura di build colpisce un prodotto. Veda PSIRT e CSIRT a confronto.

Che cos'è il FIRST PSIRT Services Framework?

Una guida gratuita di FIRST, il Forum of Incident Response and Security Teams, che elenca i servizi che un PSIRT può fornire. La versione 1.1 li raggruppa in sei aree di servizio: gestione dell'ecosistema degli stakeholder, scoperta delle vulnerabilità, triage e analisi delle vulnerabilità, remediation, divulgazione delle vulnerabilità, formazione e istruzione. Un documento complementare sulla maturità organizza i servizi in tre livelli.

Quali standard descrivono il processo PSIRT?

ISO/IEC 30111:2019 riguarda il modo in cui un vendor gestisce internamente le segnalazioni di vulnerabilità, dalla preparazione e ricezione fino a verifica, sviluppo della remediation, rilascio e post-rilascio. ISO/IEC 29147:2018 riguarda l'interfaccia con il mondo esterno: la ricezione delle segnalazioni e la pubblicazione delle informazioni sulla remediation. 30111 è pensato per essere usato con 29147. IEC 62443-4-1 stabilisce i requisiti del ciclo di vita di sviluppo sicuro, compresa la gestione di difetti e patch, per i prodotti di automazione industriale.

Una piccola azienda ha bisogno di un PSIRT?

Ha bisogno della funzione, non necessariamente di un reparto. Il documento sulla maturità di FIRST parte da sponsorship del management, stakeholder designati, un budget, alcune policy, un modo pubblico per segnalare le vulnerabilità, un workflow di triage, correzioni documentate e advisory che danno riconoscimento a chi ha trovato la vulnerabilità. Una o due persone con un mandato scritto possono gestire tutto questo.

Di quali strumenti ha bisogno un PSIRT?

Come minimo: un modo per ricevere le segnalazioni, un sistema di tracciamento dei casi, un metodo di punteggio delle vulnerabilità, un inventario di quali componenti vengono distribuiti in quali versioni di prodotto, il monitoraggio di tali componenti per rilevare nuove vulnerabilità, un modo per registrare se ogni prodotto è colpito (spesso come VEX) e un modo per pubblicare gli advisory, sempre più spesso in CSAF.