In breve: la gestione delle vulnerabilità nelle PMI è un ciclo snello e ricorrente: conoscere i propri sistemi, seguire le segnalazioni in modo mirato, valutare in base al rischio, decidere, attuare e documentare. Non contano gli strumenti costosi, ma responsabilità chiare e una priorità che tenga conto di raggiungibilità, dati e situazione degli attacchi. PHP2Shell è un buon esempio per esercitarsi, perché contiene tutti questi passaggi.
Centinaia di segnalazioni, poco personale
Ogni settimana vengono pubblicate nuove falle di sicurezza in sistemi operativi, linguaggi di programmazione, applicazioni e plugin. Un grande gruppo ha un team dedicato. Una PMI ha spesso un responsabile IT, uno o due amministratori e diversi fornitori esterni. Nessuno può leggere ogni segnalazione, e non serve.
Serve invece un filtro: quali segnalazioni riguardano i nostri sistemi, quali tra queste sono urgenti e chi se ne occupa? Senza questo filtro accade una di due cose. O si ignora tutto finché non succede qualcosa, oppure ogni segnalazione scatena agitazione e quella davvero critica si perde nel rumore.
Il ciclo della gestione delle vulnerabilità
Un processo sostenibile per le PMI si può descrivere in sei passaggi:
- Rilevare ciò che è in funzione. Senza inventario non c'è confronto. Quali siti web, server, versioni di PHP e applicazioni gestisce e dove? Come riuscirci lo mostra Sapere che cosa gira: l'inventario di tutti i siti e server.
- Seguire le segnalazioni. Sottoscrivere poche fonti affidabili: gli avvisi del BSI (l'Ufficio federale tedesco per la sicurezza informatica), le segnalazioni dei produttori del Suo software, le pagine di sicurezza della Sua distribuzione Linux e, per PHP, la home page di php.net.
- Valutare. La segnalazione ci riguarda? In caso affermativo, quanto è urgente? Ne parliamo più sotto.
- Decidere. Correggere, mettere in sicurezza in via provvisoria, isolare il sistema o accettare consapevolmente il rischio. Chi può decidere che cosa?
- Attuare. Installare l'aggiornamento, applicare una misura provvisoria, incaricare un fornitore.
- Provare e dare seguito. La falla è stata davvero chiusa? Quando verrà sostituita una soluzione provvisoria?
Poi il ciclo ricomincia. Arrivano nuovi sistemi, quelli vecchi escono di scena e compaiono nuove segnalazioni.
Per il passaggio 2 aiuta una regola semplice: meglio leggere con regolarità poche fonti che molte ogni tanto. Per un tipico ambiente web di una PMI bastano di solito gli avvisi del CERT-Bund presso il BSI (il CERT del governo tedesco), le segnalazioni di sicurezza della distribuzione Linux in uso, le pagine dei produttori di CMS e shop e la home page di php.net. Stabilisca chi legge queste fonti e crei a questo scopo una casella condivisa o un canale che non dipenda da una sola persona.
Vale la pena aggiungere uno sguardo dall'esterno. Una scansione periodica delle vulnerabilità dei sistemi raggiungibili pubblicamente mostra se sono visibili software obsoleto o servizi aperti senza necessità. Non sostituisce né l'inventario né gli aggiornamenti, ma porta alla luce sistemi che non compaiono in nessun elenco.
Valutare: che cosa viene per primo
Il punteggio CVSS, una classificazione standardizzata della gravità, è un buon punto di partenza. Per stabilire l'ordine in casa propria, però, non basta. Decidono altre tre domande:
| Domanda | Aumenta l'urgenza | Riduce l'urgenza |
|---|---|---|
| Il sistema è raggiungibile da Internet? | sito pubblico, shop, portale | solo interno, dietro VPN |
| Serve un accesso autenticato per sfruttare la falla? | no, non autenticato | sì, solo per amministratori |
| Quali dati tratta il sistema? | dati dei clienti, pagamenti, credenziali | contenuti pubblici senza account |
| Ci sono segnalazioni di attacchi? | tentativi di attacco segnalati | nessun tentativo noto |
| Esiste una misura provvisoria? | no | sì, con efficacia dimostrata |
PHP2Shell mostra come questi fattori si combinano. Entrambe le falle hanno un punteggio CVSS v4.0 di 9.2, consentono l'esecuzione di codice senza autenticazione e riguardano server web raggiungibili pubblicamente. Secondo i media, Cloudflare e Patchstack hanno riferito di tentativi di attacco, e il BSI ha classificato la situazione al livello di allerta 3. Le misure provvisorie di php.net non offrono espressamente una protezione completa. Tutte le domande puntano nella stessa direzione: agire subito. Che cosa ha raccomandato concretamente il BSI è spiegato in Che cosa raccomanda il BSI su PHP2Shell.
Decidere e documentare
Non ogni falla si può chiudere subito. Un sistema legacy gira su PHP 8.1, per il quale non esistono più aggiornamenti ufficiali (vedere PHP 8.1 e precedenti: che cosa vale ora), un'applicazione specialistica non sopporta ancora l'aggiornamento. Serve allora una decisione, e questa non spetta solo al reparto tecnico.
Una buona nota di decisione contiene il sistema interessato, la falla, la valutazione, l'opzione scelta, le misure provvisorie, la persona responsabile e una data per una nuova verifica. Se un rischio viene accettato consapevolmente, decide la direzione e non l'amministratore da solo. Anche il Cheat Sheet di OWASP sulla gestione delle dipendenze vulnerabili raccomanda di ancorare esplicitamente l'accettazione del rischio al livello direttivo.
Tenga un unico elenco delle vulnerabilità aperte, con stato, responsabile e scadenza. Basta una tabella. L'importante è che venga rivista con regolarità, ad esempio nell'incontro mensile con la direzione.
Che cosa c'entrano NIS2 e i fornitori
Per le aziende che rientrano nella NIS2, la gestione delle vulnerabilità fa parte degli obblighi di gestione del rischio. I dettagli sono descritti in NIS2 e sicurezza dei server web. Ma anche senza un obbligo di legge un processo documentato è un vantaggio, ad esempio verso clienti, assicuratori e la propria direzione.
Molti passaggi si possono affidare all'esterno, come il monitoraggio delle segnalazioni o l'installazione degli aggiornamenti. La decisione sui rischi e la visione d'insieme dovrebbero però restare in azienda. Chi affida l'intero ciclo a un fornitore, in caso di emergenza non sa più nemmeno quali sistemi possiede. Come organizzare l'attuazione come routine lo descrive Gestione delle patch come processo, non come emergenza.
Come aiuta concretamente PHP SOS?
- Creiamo insieme a Lei l'inventario dei Suoi siti web e server, come base per ogni confronto.
- Seguiamo per i Suoi sistemi le segnalazioni rilevanti e forniamo una valutazione in parole chiare con una raccomandazione.
- Prepariamo note di decisione per i casi in cui un aggiornamento non è possibile subito.
- Con il Security Monitoring controlliamo in modo continuativo se i sistemi diventano anomali mentre una falla è ancora aperta.
Conclusione: la gestione delle vulnerabilità nelle PMI non deve essere grande, ma vincolante. Chi conosce i propri sistemi, legge poche buone fonti e mette per iscritto le decisioni reagisce in modo rapido e corretto alla prossima segnalazione critica.
Domande frequenti
Che cos'è la gestione delle vulnerabilità?
È un processo ricorrente con cui un'azienda viene a conoscenza delle falle di sicurezza nei propri sistemi, le valuta, le corregge o le accetta consapevolmente e documenta il risultato. Non riguarda uno strumento, ma responsabilità e decisioni.
Il punteggio CVSS basta per stabilire le priorità?
È un buon punto di partenza, ma non basta. Conta anche se il sistema interessato è raggiungibile da Internet, quali dati tratta e se sono già stati osservati attacchi. Una falla con punteggio alto su un sistema di test interno può attendere, una sullo shop no.
Una piccola azienda ha bisogno di uno strumento apposito?
All'inizio no. Bastano un elenco aggiornato dei sistemi, avvisi di sicurezza sottoscritti e una tabella con i punti aperti. Gli scanner di vulnerabilità diventano utili quando il numero di sistemi cresce o quando le verifiche devono essere documentate con regolarità.
Si può scegliere di non correggere una vulnerabilità?
Sì, se il rischio è valutato, la decisione è presa dalla direzione competente e messa per iscritto, idealmente con misure provvisorie e una data per una nuova verifica.