Durante un audit ISO 27001 o una valutazione PCI DSS la domanda arriva quasi sempre allo stesso punto: come gestite le vulnerabilità dei vostri sistemi? Se nell’inventario compare un server con PHP 7.4 o PHP 5.6, la domanda si fa più precisa. L’auditor vuole sapere chi segue le vulnerabilità di quel componente, come vengono corrette visto che il progetto PHP non rilascia più aggiornamenti, e quale piano esiste per uscirne. Rispondere “funziona ed è protetto dal firewall” non basta.
In questo articolo vediamo quali controlli di ISO/IEC 27001:2022 e quali requisiti di PCI DSS v4.0.1 riguardano la gestione delle vulnerabilità, come si collegano tra loro, cosa cambia quando un componente è fuori supporto e quali evidenze preparare perché un auditor possa verificare il processo. L’obiettivo è un unico modo di lavorare che risponda a entrambi gli standard, e anche alle richieste della NIS2.
Cosa cerca un auditor
ISO 27001 e PCI DSS sono strumenti diversi. ISO/IEC 27001 è una norma per i sistemi di gestione della sicurezza delle informazioni: l’organizzazione definisce il proprio perimetro, valuta i rischi, sceglie i controlli e li dichiara nella Dichiarazione di applicabilità. PCI DSS è uno standard prescrittivo per chi tratta dati delle carte di pagamento, con requisiti puntuali e frequenze fissate.
Sulla gestione delle vulnerabilità però chiedono la stessa cosa: un processo definito, applicato con continuità e dimostrabile con documenti e registrazioni. L’assenza di vulnerabilità è impossibile da garantire: l’auditor verifica che l’organizzazione sappia quali ha, decida cosa farne in tempi coerenti con il rischio e tenga traccia delle decisioni.
ISO/IEC 27001:2022: i controlli coinvolti
Nella revisione del 2022 l’Annex A conta 93 controlli divisi in quattro temi: organizzativi (sezione 5), relativi alle persone (6), fisici (7) e tecnologici (8). Il periodo di transizione dalla versione 2013 si è chiuso il 31 ottobre 2025, quindi oggi le certificazioni valide fanno riferimento alla versione 2022. Per un PHP in produzione i controlli più rilevanti sono questi:
- 8.8, gestione delle vulnerabilità tecniche: ottenere informazioni sulle vulnerabilità dei sistemi in uso, valutare l’esposizione e adottare misure appropriate. È il controllo centrale;
- 5.9, inventario delle informazioni e degli altri beni associati: senza sapere dove gira PHP, e in quale versione, non si può gestire nulla;
- 5.7, intelligence sulle minacce: raccogliere e analizzare informazioni sulle minacce, utili anche per dare priorità alle vulnerabilità;
- 8.32, gestione dei cambiamenti: l’installazione di una patch o di un pacchetto ricostruito è un cambiamento e segue la procedura prevista;
- da 5.19 a 5.22, fornitori: sicurezza nei rapporti con i fornitori, accordi, catena di fornitura ICT e monitoraggio dei servizi.
Un componente fuori supporto entra anche nella valutazione e nel trattamento del rischio previsti dalla clausola 6.1 della norma. Se l’organizzazione decide di mantenerlo per un periodo, la decisione va motivata, approvata da chi ne ha l’autorità e accompagnata dalle misure che riducono il rischio.
PCI DSS v4.0.1: i requisiti
La versione 4.0.1 è una revisione limitata della 4.0, pubblicata a giugno 2024; la 4.0 è stata ritirata il 31 dicembre 2024 e i requisiti con data futura sono obbligatori dal 31 marzo 2025, come spiega il PCI Security Standards Council. Quelli che toccano direttamente PHP sono:
- 6.3.1: le nuove vulnerabilità sono identificate da fonti riconosciute, compresi gli avvisi dei CERT, e ricevono una classificazione del rischio che individui almeno quelle ad alto rischio e critiche;
- 6.3.2: inventario del software sviluppato su misura e dei componenti di terze parti che contiene, per facilitare la gestione di vulnerabilità e patch;
- 6.3.3: i componenti sono protetti dalle vulnerabilità note installando le patch applicabili. Nella versione 4.0.1 quelle per le vulnerabilità critiche vanno installate entro un mese dal rilascio, le altre entro un tempo definito dall’organizzazione;
- 11.3.1 e 11.3.2: scansioni di vulnerabilità interne ed esterne almeno ogni tre mesi, quelle esterne affidate a un fornitore approvato (ASV), con nuove scansioni per confermare la correzione;
- 12.3.4: almeno una volta ogni dodici mesi si verificano le tecnologie in uso, controllando che ricevano ancora correzioni dai fornitori e documentando un piano, approvato dal vertice, per sostituire quelle obsolete o a fine vita.
Il requisito 12.3.4 è quello che più direttamente riguarda un PHP in End of Life: non basta proteggerlo, serve un piano approvato per sostituirlo. Si aggiungono 6.4.1 e 6.4.2 per la protezione delle applicazioni web esposte, 6.5.1 per la gestione dei cambiamenti e la serie 12.8 sui fornitori terzi, che ricorda come affidarsi a un fornitore conforme non sollevi l’organizzazione dalla propria responsabilità.
Una mappa comune
Mettendo uno accanto all’altro controlli e requisiti, si vede che descrivono le stesse attività. Conviene quindi costruire un solo processo e indicare per ciascuna attività a quali punti dei due standard risponde.
Il testo completo di ISO/IEC 27001 è a pagamento e quello di PCI DSS si scarica dalla biblioteca documentale del PCI SSC: la mappa va sempre confrontata con le versioni ufficiali e con l’interpretazione del proprio ente di certificazione o del proprio QSA.
Quando PHP è fuori supporto
Un ramo di PHP in End of Life mette in difficoltà proprio il requisito 6.3.3 e il controllo 8.8: se il progetto non rilascia più correzioni, non c’è una patch ufficiale da installare entro un mese. Le strade per rispondere all’auditor sono tre, e spesso si combinano.
- Pacchetti ancora mantenuti. Se la distribuzione o un fornitore correggono il ramo in uso, la patch esiste: si documentano la fonte, la copertura e la scadenza di quel supporto.
- Backport delle patch. Le correzioni dei rami supportati vengono adattate al ramo in uso. L’evidenza è l’elenco delle CVE corrette per ogni pacchetto, con changelog, test e data di rilascio. Il backport chiude le vulnerabilità note, ma la versione resta fuori supporto: per il 12.3.4 serve comunque il piano di sostituzione.
- Misure compensative. Quando un requisito non si può soddisfare come scritto, PCI DSS prevede controlli compensativi documentati e valutati caso per caso. Sono una soluzione temporanea e vanno concordati con il QSA.
Un caso frequente è quello degli scanner. Molti strumenti di scansione deducono la versione dall’intestazione HTTP o dal banner e segnalano qualunque PHP vecchio come vulnerabile, anche quando il pacchetto è stato corretto con un backport. Per gestire questi risultati serve la prova della correzione; ne parliamo nell’articolo su scanner di sicurezza e PHP obsoleto. Queste sono le verifiche che usiamo per produrre l’evidenza sul server:
# Famiglia Red Hat: versione, rilascio, fornitore e data di build del pacchetto
rpm -qi php-cli | grep -E '^(Version|Release|Vendor|Build Date)'
# CVE citate nel changelog del pacchetto installato
rpm -q --changelog php-cli | grep -i cve | head -n 20
# Debian e Ubuntu (il nome del pacchetto dipende dalla versione)
dpkg -s php7.4-cli | grep -E '^(Version|Maintainer)'
zcat /usr/share/doc/php7.4-cli/changelog.Debian.gz | grep -i cve | head -n 20
# Non esporre la versione nelle intestazioni HTTP (in php.ini)
grep -i '^expose_php' /etc/php.ini /etc/php/*/fpm/php.ini 2>/dev/nullNascondere la versione con expose_php = Off riduce le informazioni utili a un attaccante, ma non corregge nulla: davanti a un auditor conta la prova che la vulnerabilità è chiusa.
Il fascicolo delle evidenze
Il modo più efficace per affrontare un audit è far sì che ogni vulnerabilità lasci una traccia completa, dal momento in cui viene conosciuta a quello in cui è chiusa.
In concreto, il fascicolo contiene:
- l’inventario aggiornato dei server con PHP, versione, origine dei pacchetti ed esposizione;
- la procedura scritta di gestione delle vulnerabilità, con fonti monitorate, criteri di priorità e tempi;
- per ogni CVE rilevante, la scheda di analisi con la decisione e chi l’ha approvata;
- i report dei test e i log dei rilasci, collegati alle richieste di cambiamento;
- i report delle scansioni prima e dopo la correzione;
- la revisione annuale delle tecnologie con il piano di migrazione approvato;
- i contratti e i report dei fornitori che intervengono su server e applicazioni.
Lo stesso materiale serve per dimostrare le misure richieste dalla NIS2, di cui parliamo nell’articolo su NIS2 e software fuori supporto.
Errori che emergono negli audit
- Inventario incompleto: il server dimenticato con un vecchio PHP è spesso quello che la scansione trova per primo.
- Versione della riga di comando scambiata per quella del sito:
php -vpuò restituire una versione diversa da quella usata da PHP-FPM. - Accettazione del rischio senza scadenza: una deroga senza data di revisione diventa permanente.
- Patch installate senza traccia: un intervento corretto ma non registrato, per l’auditor, è un intervento non dimostrato.
- Fornitori senza impegni scritti: se chi gestisce il server non ha obblighi contrattuali su tempi e comunicazioni, il controllo sui fornitori è scoperto.
In sintesi
ISO/IEC 27001:2022 e PCI DSS v4.0.1 chiedono di gestire le vulnerabilità con un processo dimostrabile. In ISO il riferimento centrale è il controllo 8.8, sostenuto da inventario (5.9), intelligence sulle minacce (5.7), gestione dei cambiamenti (8.32) e fornitori (da 5.19 a 5.22); in PCI DSS sono i requisiti 6.3.1, 6.3.2 e 6.3.3, le scansioni trimestrali 11.3.1 e 11.3.2 e la revisione annuale delle tecnologie 12.3.4. Un PHP fuori supporto si gestisce con pacchetti mantenuti o con il backport delle patch, documentando ogni CVE corretta, e con un piano di migrazione approvato. Il risultato è un unico fascicolo di evidenze, utile per entrambi gli audit e per la NIS2. Per l’interpretazione dei singoli requisiti nel tuo contesto, il riferimento resta il tuo ente di certificazione o il tuo QSA.
