Cybersecurity per Fornitori ICT e MSP: VA e Penetration Test

Piattaforme RMM, tenant amministrati in delega, bastion host, infrastrutture di backup condivise:
analizziamo i sistemi da cui si raggiunge il parco clienti, non solo la rete aziendale.

La gestione dei servizi TIC business-to-business rientra nell’Allegato I del decreto legislativo 138 del 2024, insieme alle infrastrutture digitali — cloud, data center, DNS, reti di distribuzione dei contenuti — e agli operatori di reti pubbliche di comunicazione elettronica.

L’elemento che distingue il comparto è la soglia: i fornitori di servizi gestiti e di sicurezza gestiti sono considerati soggetti essenziali indipendentemente dalla dimensione, quando erogano servizi critici per la continuità operativa dei clienti. Il decreto definisce il fornitore di servizi gestiti come chi eroga installazione, gestione, funzionamento o manutenzione di prodotti, reti, infrastrutture e applicazioni TIC tramite amministrazione attiva presso il cliente o a distanza: una definizione che descrive un’attività, non una dimensione aziendale.

Anche i tempi differiscono, perché per questi soggetti la finestra di registrazione sulla piattaforma ACN si chiude a metà gennaio, in anticipo rispetto a quella generale. E l’obbligo si estende alla vostra catena di fornitura, il che apre due fronti contemporanei: le misure che dovete adottare voi, e le richieste dei clienti tenuti a valutarvi con questionari che chiedono date ed esiti delle verifiche svolte. Servono un vulnerability assessment e un penetration test datati, non una dichiarazione.

Tra le misure previste per i soggetti dell’Allegato I, tre descrivono direttamente ciò che un’analisi tecnica produce.

Sulla prima riga vale la pena soffermarsi: le vulnerabilità vanno identificate e confermate.
Uno strumento automatico identifica, non conferma, e su un’infrastruttura condivisa la differenza è sostanziale: una criticità sull’hypervisor o sulla console di gestione non vale come una sulla postazione di un ufficio, perché il suo impatto si moltiplica per il numero di organizzazioni raggiungibili da quel sistema. La conferma è ciò che permette di ordinare le priorità su quel criterio invece che su un punteggio teorico.

Nel vostro caso il sistema da verificare per primo non è il firewall perimetrale, è la piattaforma da cui distribuite attività sugli endpoint dei clienti. Descriveteci come è organizzata l’amministrazione e definiamo quali sistemi entrano nell’analisi e in quale ordine.

I sistemi che concentrano privilegi su infrastrutture di terzi, in ordine di impatto in caso di compromissione.

Console di monitoraggio e gestione remota, distribuzione di pacchetti, esecuzione di script e attività pianificate sugli endpoint amministrati. Verifichiamo esposizione dell’interfaccia, copertura dell’autenticazione a più fattori, segregazione dei ruoli operatore e se un operatore con privilegi limitati può pubblicare attività su clienti non assegnati.

Amministrazione delegata sugli ambienti cloud dei clienti, applicazioni registrate, principal di servizio, consensi concessi a livello di tenant. Verifichiamo se i privilegi sono permanenti o attivati su richiesta, quali utenze del vostro dominio li detengono e quali segreti applicativi restano validi oltre la fine del contratto.

Jump host, tunnel site-to-site sempre attivi, concentratori di accesso remoto, postazioni dei tecnici che raggiungono più reti clienti nella stessa sessione. Il penetration test misura se da una postazione interna compromessa si raggiunge una rete cliente, e da lì una seconda.

Tra le misure previste per i soggetti dell’Allegato I, tre descrivono direttamente ciò che un’analisi tecnica produce. Nel vostro caso l’oggetto della verifica non è soltanto l’infrastruttura aziendale, ma i sistemi che detengono privilegi su infrastrutture di terzi.

Sulla prima riga vale la pena soffermarsi: le vulnerabilità vanno identificate e confermate. Uno strumento automatico identifica, non conferma, e su un’infrastruttura condivisa la differenza cambia le priorità: una criticità sull’hypervisor, sul dominio di gestione o sulla console con cui distribuite attività non ha lo stesso peso di una criticità su una postazione interna, perché il suo impatto si moltiplica per il numero di tenant raggiungibili da quel sistema.

C’è poi un vincolo che nel vostro caso rende la conferma indispensabile. La correzione di una vulnerabilità su un sistema condiviso richiede una finestra di manutenzione che coinvolge tutti i clienti ospitati, e va negoziata con ciascuno nei termini previsti dai livelli di servizio. Intervenire su una segnalazione non verificata significa consumare quella finestra per nulla, e le finestre disponibili in un anno sono un numero finito.