PSIRT: Cos'è il Product Security Incident Response Team e Come Istituirne Uno

Quando un ricercatore di sicurezza trova una vulnerabilità nel tuo prodotto, dove deve segnalarla? Quanto tempo hai per rispondere? Come gestisci il processo di disclosure? Il PSIRT è la risposta strutturata a queste domande.

Cos'è un PSIRT

Il Product Security Incident Response Team (PSIRT) è la funzione aziendale responsabile di:

• Ricevere segnalazioni di vulnerabilità da ricercatori esterni e clienti
• Triaggiare e analizzare le vulnerabilità segnalate
• Coordinare la risposta interna (sviluppo, qualità, supporto)
• Sviluppare e rilasciare le patch
• Comunicare ai clienti le vulnerabilità e le correzioni disponibili
• Gestire la disclosure coordinata con i ricercatori

Senza un PSIRT, le segnalazioni di vulnerabilità rimangono senza risposta, i ricercatori frustrati pubblicano le vulnerabilità senza avvisare l'azienda, e i clienti restano esposti.

Il ciclo di vita di una vulnerabilità

1. Ricezione

Le segnalazioni arrivano da:

• Ricercatori di sicurezza attraverso il programma di disclosure
• Clienti che trovano problemi in produzione
• Bug bounty hunters se hai un programma attivo
• Scanner automatici o audit interni

Il canale standard è un indirizzo email dedicato (security@azienda.com) o una piattaforma di disclosure (HackerOne, Bugcrowd).

2. Triage e analisi

Ogni segnalazione viene analizzata per determinare:

• È una vera vulnerabilità di sicurezza?
• Qual è la severity? (CVSS score)
• Quale prodotto e versione è affetto?
• Quanti clienti sono a rischio?
• Esistono workaround?

Il triage iniziale dovrebbe avvenire entro 24-48 ore dalla ricezione.

3. Coordinamento interno

Il PSIRT coordina con:

• Engineering per lo sviluppo della patch
• QA per il testing
• Release management per il deployment
• Supporto clienti per la comunicazione
• Legal per aspetti legali e contrattuali
• Marketing/PR per comunicazioni esterne significative

4. Sviluppo e testing della patch

Tempistiche target per lo sviluppo della patch:

• Critica (CVSS 9-10): 7 giorni
• Alta (CVSS 7-8.9): 30 giorni
• Media (CVSS 4-6.9): 90 giorni
• Bassa (CVSS < 4): 180 giorni o nel prossimo ciclo di release

5. Disclosure coordinata

La Coordinated Vulnerability Disclosure (CVD) è il processo standard:

1. L'organizzazione e il ricercatore concordano una data di disclosure pubblica
2. L'organizzazione sviluppa e rilascia la patch
3. Viene assegnato un CVE ID (tramite MITRE o un CNA)
4. Il PSIRT pubblica un security advisory
5. Il ricercatore può pubblicare i dettagli della vulnerabilità

La finestra standard di embargo è 90 giorni. Google Project Zero e altri ricercatori rispettano questa finestra; se l'azienda non risponde, pubblicano comunque allo scadere.

Come istituire un PSIRT

Fase 1: Policy di disclosure

Prima di tutto, pubblica una policy di disclosure (Vulnerability Disclosure Policy - VDP). Dice ai ricercatori:

• Come segnalare vulnerabilità
• Cosa aspettarsi in risposta
• Le tempistiche di risposta
• Le regole di ingaggio (cosa possono testare)

Un template standard è disponibile su disclose.io.

Fase 2: Canali di comunicazione

Crea i canali per ricevere le segnalazioni:

• Indirizzo email dedicato con PGP per comunicazioni cifrate
• Piattaforma di disclosure (opzionale ma raccomandata)
• Sezione security del sito web

Fase 3: Processo interno

Documenta il processo interno:

• Chi riceve le segnalazioni
• Come si fa il triage
• Chi approva le patch
• Come si coordinano i rilasci
• Come si gestisce la comunicazione con i clienti

Fase 4: CVE Numbering Authority

Considera di diventare un CNA (CVE Numbering Authority). Permette di assegnare CVE autonomamente, senza passare per MITRE, velocizzando il processo.

Fase 5: Bug bounty (opzionale ma efficace)

Un programma di bug bounty incentiva i ricercatori a segnalare responsabilmente invece di vendere la vulnerabilità sul mercato grigio. Piattaforme come HackerOne e Bugcrowd gestiscono la logistica.

Il Cyber Resilience Act e il PSIRT

Il Cyber Resilience Act europeo (in vigore dal 2027 per molti prodotti) richiede esplicitamente ai produttori di:

• Avere processi di gestione delle vulnerabilità
• Gestire i report di vulnerabilità da terzi
• Notificare le vulnerabilità attivamente sfruttate all'ENISA entro 24 ore

In pratica, il CRA rende alcune funzioni del PSIRT obbligatorie per i produttori di software e hardware nell'UE.

Investire in un PSIRT maturo non è solo compliance: è reputazione. Le aziende che gestiscono le vulnerabilità in modo trasparente e rapido guadagnano la fiducia dei ricercatori e dei clienti.