Come valutare i fornitori di soluzioni DSPM: il quadro di riferimento per la selezione destinato agli acquirenti aziendali

La scelta di una soluzione per la gestione della sicurezza dei dati rappresenta una delle decisioni di acquisto più importanti che un team di sicurezza dovrà prendere quest’anno. Se la scelta è quella giusta, otterrete una visibilità continua su dove si trovano i dati sensibili, chi può accedervi e quanto siano effettivamente esposti. Se si commette un errore, si finisce per acquistare una costosa dashboard che genera avvisi ai quali nessuno dà seguito. La sfida risiede nel fatto che tutti i fornitori del settore offrono dimostrazioni convincenti: motori di classificazione ben rifiniti che analizzano ambienti di test accuratamente selezionati, mappe di rischio ben strutturate e integrazioni elencate in una diapositiva. Il divario tra ciò che si vede in una dimostrazione del fornitore e ciò che si sperimenta in produzione è il motivo per cui la maggior parte degli acquisti di soluzioni DSPM fallisce.

La presente guida fornisce un quadro strutturato e indipendente dai fornitori per la valutazione delle piattaforme DSPM. Si basa sulle dimensioni di valutazione utilizzate da società di analisi quali Forrester e Gartner nelle loro Magic Quadrant “Wave” e Magic Quadrant — individuazione, classificazione, analisi dei rischi, correzione, profondità di integrazione e maturità operativa — ma traduce tali dimensioni in una metodologia di valutazione pratica che il vostro team potrà applicare durante la selezione dei candidati e i test di prova (proof-of-concept). Le linee guida DSPM della Cloud Security Alliance sottolineano inoltre che una valutazione efficace deve andare oltre i semplici elenchi di funzionalità, per valutare le prestazioni di una soluzione in relazione al vostro effettivo ambiente di dati, ai modelli di accesso e agli obblighi di conformità.

Che siate un CISO impegnato a elaborare un business case, un DPO incaricato di mappare i requisiti normativi in materia di documentazione, un ingegnere della sicurezza cloud che sottopone a stress test la copertura delle API, oppure un responsabile degli acquisti che sta modellando il costo totale di proprietà, il quadro di riferimento che segue offre a ciascun soggetto interessato un percorso chiaro all’interno di un unico processo di valutazione unificato.

La verifica della fattibilità del proof-of-concept

Le demo dei fornitori sono per loro natura ambienti ottimizzati. I dati di test sono puliti, le strutture delle autorizzazioni sono semplici e i modelli di classificazione sono stati ottimizzati per funzionare negli scenari specifici presentati. Valutazioni di proof-of-concept efficaci dovrebbero includere dati di produzione reali e ambienti SaaS su scala aziendale, ove opportuno, poiché i set di dati di test semplificati raramente mettono in luce le sfide operative, di visibilità e di governance che emergono nelle complesse implementazioni di Microsoft 365 e multi-cloud.

Il problema dell'M365

Ecco uno scenario che si ripete in quasi tutte le valutazioni DSPM aziendali: durante la demo, il fornitore esegue una scansione di un sito SharePoint di prova contenente alcune centinaia di documenti e con autorizzazioni semplici. L’accuratezza della classificazione appare eccellente: precisione superiore al 95% nel rilevamento delle informazioni personali identificabili (PII), valutazione dei rischi chiara e minima incidenza di falsi positivi. Successivamente, lo si collega al proprio ambiente Microsoft 365 reale.

Ciò che il fornitore non Le ha mostrato è ciò che accade quando il Suo scanner rileva autorizzazioni di Teams annidate ed ereditate attraverso le gerarchie dei canali, siti SharePoint con collegamenti di condivisione complessi (chiunque disponga del link, persone specifiche, a livello di organizzazione), autorizzazioni di accesso per utenti ospiti nascoste a tre livelli di profondità nell’appartenenza ai gruppi, file OneDrive condivisi tramite la chat di Teams (il che crea autorizzazioni di condivisione invisibili nell’amministrazione di SharePoint) ed etichette di riservatezza applicate in modo incoerente tra le diverse unità aziendali. In queste condizioni reali, l’accuratezza della classificazione spesso cala in modo significativo, i falsi positivi aumentano vertiginosamente poiché lo scanner non è in grado di risolvere le catene di eredità delle autorizzazioni e, per impostazione predefinita, contrassegna tutto come sovraesposto, mentre il pannello di controllo dei rischi diventa talmente confuso che il Suo team di sicurezza inizia a ignorarlo nel giro di poche settimane.

Cosa verificare in un vero e proprio POC

Strutturate il vostro proof of concept attorno agli scenari che mettono effettivamente alla prova una piattaforma DSPM. Collegate il fornitore a un ambiente M365 di produzione rappresentativo, non a un tenant di prova. Scegliete un segmento di tenant che presenti una reale complessità in termini di condivisione: un dipartimento che collabora intensamente con partner esterni, un ambiente Teams con canali privati annidati e siti SharePoint in cui si sono accumulate nel corso degli anni autorizzazioni di condivisione ad hoc.

Valutate la classificazione rispetto ai dati di riferimento. Prima del POC, contrassegnate manualmente un campione di 200–500 documenti a diversi livelli di sensibilità. Dopo le scansioni del DSPM, confrontate le sue classificazioni con i vostri dati di riferimento. Calcolate la precisione (quale percentuale degli elementi contrassegnati è effettivamente sensibile) e il richiamo (quale percentuale degli elementi effettivamente sensibili è stata individuata). I fornitori che non riescono a raggiungere una precisione superiore all’85% e un richiamo superiore all’80% sui vostri dati reali in un POC ottimizzato otterranno risultati inferiori in produzione.

Verificare il livello di risoluzione delle autorizzazioni. Creare scenari di test con catene di autorizzazioni complesse e note: un documento condiviso tramite la chat di una riunione su Teams, un file SharePoint con autorizzazioni ereditate tramite un gruppo di sicurezza annidato che include utenti ospiti, una cartella OneDrive condivisa con un gruppo M365. Verificare che il DSPM sia in grado di individuare con precisione chi dispone di accesso effettivo, e non solo chi possiede autorizzazioni nominali.

Valutate il flusso di lavoro relativo al triage dei falsi positivi. Un tasso elevato di falsi positivi è gestibile se il flusso di lavoro relativo al triage e all’esclusione è efficiente. Un tasso moderato di falsi positivi, abbinato a un’interfaccia di triage poco intuitiva, rappresenta invece una situazione peggiore. Misurate il tempo necessario a un analista per esaminare, convalidare ed escludere o inoltrare un risultato. Moltiplicate tale valore per il volume giornaliero previsto di avvisi.

Eseguite un ciclo completo di correzione. Selezionate cinque casi reali di sovraesposizione individuati dalla scansione POC. Cercate di correggerli seguendo il flusso di lavoro del DSPM: revocando un link di condivisione, modificando le autorizzazioni, applicando un’etichetta di riservatezza. Verificate se la correzione abbia effettivamente effetto in M365 e se il DSPM rifletta lo stato di sicurezza aggiornato nel ciclo di scansione successivo.

Effettuate il test sulla scala effettiva dei vostri dati. Se la vostra organizzazione dispone di 50 TB di dati distribuiti tra M365 e AWS S3, un POC che analizza 500 GB non fornisce alcuna indicazione in merito alle prestazioni, alla durata dell’analisi o all’efficienza delle analisi incrementali. Insistete affinché l’ambito del POC rappresenti almeno il 20% del volume dei vostri dati di produzione.

Domande da porre ai fornitori

Le liste di controllo generiche per le richieste di offerta (RFP) generano risposte generiche. Le domande riportate di seguito sono state concepite per mettere in luce specifiche lacune nelle capacità e realtà operative che i materiali di marketing dei fornitori non riescono a far emergere.

In merito all’accuratezza della classificazione: «Qual è il tasso di falsi positivi rilevato sui dati non strutturati in ambienti M365 con oltre 10.000 utenti? Potete fornire clienti di riferimento di dimensioni simili che possano condividere i propri indicatori di accuratezza post-ottimizzazione?» I fornitori che riportano dati sull’accuratezza solo in ambienti controllati o che si rifiutano di mettervi in contatto con clienti di riferimento per discutere di accuratezza stanno segnalando una lacuna.

In merito alla risoluzione delle autorizzazioni: «Quando il Suo scanner rileva un file SharePoint il cui accesso effettivo deriva da un gruppo di sicurezza Azure AD annidato che include utenti ospiti B2B, come risolve le autorizzazioni effettive? Mi illustri le chiamate API specifiche e la logica di ereditarietà delle autorizzazioni». Questo verifica se la mappatura degli accessi del fornitore sia realmente “identity-aware” o se si basi su dati di autorizzazione nominali senza risolvere l’annidamento dei gruppi.

In merito alla personalizzazione della classificazione: «Disponiamo di tipi di dati sensibili specifici del settore che non sono coperti dai classificatori standard PII/PHI/PCI. Qual è la procedura per la creazione di classificatori personalizzati? Quanti campioni di addestramento sono necessari, qual è il ciclo di ottimizzazione tipico e quale accuratezza possiamo aspettarci dai tipi personalizzati rispetto a quelli integrati?» Ciò distingue i fornitori dotati di motori di classificazione realmente addestrabili da quelli che offrono regole personalizzate basate su espressioni regolari, commercializzate come machine learning.

Sulla trasparenza del modello di rischio: «Come viene calcolato il vostro punteggio di rischio? Quali variabili contribuiscono al punteggio, come vengono ponderate e possiamo modificarne i pesi? Se due file contengono le stesse informazioni personali identificabili (PII), ma uno è accessibile a 5 utenti e l’altro a 5.000, in che modo il vostro modello di rischio li distingue?» Un sistema di valutazione del rischio poco trasparente, che non può essere spiegato né modificato, non supererà l’esame approfondito del vostro CISO né le domande del vostro revisore.

In merito alle dinamiche di integrazione: «Mi mostri il payload effettivo degli eventi che la vostra piattaforma invia a un SIEM. Quali campi sono inclusi? Si tratta di un evento strutturato CEF/LEEF, di un webhook JSON o di un dump syslog? È possibile filtrare gli eventi da inoltrare?» La differenza tra un’integrazione SIEM che arricchisce il vostro SOC e una che lo sommerge di eventi inutilizzabili dipende dalla struttura del payload e dalla granularità del filtraggio.

Riguardo ai limiti delle azioni correttive: «Quali azioni correttive è in grado di eseguire la vostra piattaforma in modo nativo — non semplicemente di raccomandare, ma di eseguire effettivamente? Per quanto riguarda specificamente M365, siete in grado di revocare un link di condivisione, modificare le autorizzazioni di un sito, applicare un’etichetta di sensibilità e mettere in quarantena un file?» Molte piattaforme DSPM presentano le azioni correttive come una funzionalità, ma in realtà forniscono solo una raccomandazione che un operatore umano deve poi eseguire manualmente in una console separata.

Per quanto riguarda i costi operativi: «Dopo l’implementazione iniziale, quante ore FTE a settimana dedica un cliente tipico delle nostre dimensioni alla messa a punto della classificazione, alla selezione dei falsi positivi, all’adeguamento delle politiche e alla manutenzione dell’integrazione? Il supporto per la messa a punto è incluso o rientra nei servizi professionali a costo aggiuntivo?» Il costo totale di proprietà di un DSPM è determinato prevalentemente dai costi operativi, non dai canoni di licenza.

Allineamento delle esigenze delle parti interessate

Una valutazione DSPM fallisce quando ottimizza le priorità di un soggetto interessato a scapito di quelle degli altri. Ogni ruolo all’interno del comitato di valutazione apporta una prospettiva diversa e il quadro di valutazione deve tenerne conto tutte.

CISO: Rendicontazione dei rischi e comunicazione con il consiglio di amministrazione

Il CISO necessita di una piattaforma DSPM in grado di produrre report sui rischi destinati ai vertici aziendali — non solo risultati tecnici, ma dati sulle tendenze che mostrino se lo stato di sicurezza dei dati stia migliorando o peggiorando nel tempo. Valutate se la piattaforma sia in grado di generare sintesi pronte per il consiglio di amministrazione che traducano le metriche relative all’esposizione dei dati in termini di rischio aziendale. Verificate se la valutazione del rischio possa essere segmentata per unità aziendale, tipo di dati o ambito normativo, in modo che il CISO possa riferire sullo stato di sicurezza secondo le dimensioni che interessano al consiglio di amministrazione. Un DSPM che produca eccellenti risultati tecnici ma non sia in grado di aggregarli in narrazioni strategiche sul rischio non soddisferà le esigenze del CISO.

DPO: Prove di conformità e preparazione all’audit

Il Responsabile della protezione dei dati (DPO) necessita che il DSPM funga da motore di documentazione della conformità. Valutate i quadri normativi integrati relativi al GDPR, al CCPA, all’HIPAA, al PCI DSS e a qualsiasi normativa settoriale a cui la vostra organizzazione sia soggetta. Verifichi se la piattaforma è in grado di generare report pronti per l’audit che mettano in relazione i risultati dei dati con specifici requisiti normativi: non si tratta semplicemente di un dashboard di conformità, ma di prove esportabili che un revisore possa tracciare dal riscontro al controllo fino alla correzione. Il Responsabile della protezione dei dati (DPO) avrà inoltre bisogno di supporto per le richieste di accesso da parte degli interessati: il DSPM è in grado di individuare tutte le occorrenze dei dati relativi a una specifica persona in tutti gli archivi analizzati?

Ingegnere della sicurezza cloud: copertura delle API e automazione

L’ingegnere della sicurezza cloud valuta se il DSPM si integra nei flussi di lavoro esistenti relativi all’infrastruttura come codice (Infrastructure-as-Code) e all’automazione della sicurezza. È necessaria una copertura completa delle API: non solo un’API REST per recuperare i risultati, ma anche la capacità di avviare scansioni, aggiornare le politiche e eseguire le azioni correttive a livello di programmazione. Si valuti il supporto dei webhook, la disponibilità di provider Terraform o Pulumi e l’integrazione con le pipeline CI/CD. Il tecnico presta inoltre attenzione alle prestazioni delle scansioni: quanto tempo richiede una scansione incrementale, qual è la limitazione di velocità dell’API e l’architettura di scansione è in grado di scalare orizzontalmente al crescere dei volumi di dati?

Approvvigionamento: costo totale di proprietà

Il reparto acquisti deve calcolare il TCO (costo totale di proprietà) andando oltre il costo della licenza. I modelli di tariffazione DSPM variano notevolmente: per archivio dati, per TB analizzato, per utente, per risultato, canone forfettario per la piattaforma o modelli ibridi. Richieda ai fornitori un dettaglio completo dei costi in base alla scala prevista, inclusi i costi per il superamento dei limiti, i costi aggiuntivi per i connettori, i servizi professionali per l’implementazione e l’ottimizzazione, nonché le condizioni di aumento dei costi in caso di rinnovo. Calcoli il TCO triennale includendo i costi operativi interni (ore FTE per l’amministrazione, l’ottimizzazione e la selezione dei casi). Un DSPM che costa il 30% in meno in termini di licenza ma richiede un investimento in termini di FTE doppio non rappresenta l’opzione più conveniente.

Errori comuni commessi dagli acquirenti

Acquistare basandosi esclusivamente sull’ampiezza del portafoglio

L’errore di valutazione più comune consiste nel classificare i fornitori basandosi principalmente sul numero di archivi di dati che sono in grado di analizzare. L’ampiezza dell’individuazione è un requisito minimo: quasi tutti i fornitori di soluzioni DSPM aziendali coprono i principali provider IaaS, M365, Google Workspace e le piattaforme di database più diffuse. Ciò che distingue i fornitori è la profondità della classificazione, la contestualizzazione del rischio e la capacità di correzione. Una valutazione che attribuisca un peso superiore al 40% all’individuazione selezionerà il fornitore con l’elenco di connettori più lungo, che non è necessariamente lo stesso fornitore in grado di garantire i migliori risultati in termini di sicurezza.

Omissione della fase POC con dati reali

Eseguire un proof of concept su dati sintetici o su un tenant di test pulito è poco più istruttivo che guardare una demo. I dati reali presentano classificazioni disordinate, contenuti ambigui che si collocano al confine tra sensibile e non sensibile, e strutture di autorizzazioni che hanno accumulato anni di complessità organica. I fornitori ne sono consapevoli: ecco perché alcuni scoraggiano il collegamento agli ambienti di produzione durante la fase di valutazione. Insistete per un POC in produzione. Un fornitore che non è in grado di ottenere buoni risultati con i vostri dati reali non otterrà buoni risultati nemmeno dopo l’acquisto.

Ignorare i costi operativi generali

Il costo della licenza è la cifra più evidente in un appalto relativo a una piattaforma DSPM, ma i costi operativi — ovvero le ore di lavoro a tempo pieno (FTE) dedicate alla messa a punto, alla selezione dei casi, alla gestione delle politiche e alla manutenzione dell’integrazione — sono in genere da due a tre volte superiori al costo della licenza su un periodo di tre anni. Valutate in modo esplicito l’onere operativo: quanta messa a punto è necessaria per raggiungere un’accuratezza di classificazione accettabile, quanti falsi positivi dovrà elaborare quotidianamente il vostro team e quale livello di competenza è necessario per gestire la piattaforma.

Considerare il DSPM come sistema autonomo

Il DSPM non opera in modo isolato. Il suo valore viene amplificato o ridotto a seconda di quanto efficacemente si integri con la vostra architettura di sicurezza più ampia. La Cloud Security Alliance sottolinea che un’implementazione efficace del DSPM trae vantaggio da una piattaforma SSE che fornisca funzionalità di supporto quali CSPM, SSPM, UEBA e il monitoraggio delle attività in tempo reale. Valutate ogni fornitore di soluzioni DSPM nel contesto del vostro stack esistente: integra o duplica il vostro DLP? È in grado di trasmettere i risultati al vostro CASB per l’applicazione delle politiche? Arricchisce il vostro SIEM con dati contestuali o si limita ad aumentare il volume degli avvisi?

Sottovalutazione della governance dei dati nell'ambito dell'intelligenza artificiale

Man mano che le organizzazioni implementano strumenti di IA generativa, copiloti e pipeline RAG, i requisiti di governance dei dati si stanno estendendo oltre le tradizionali categorie di conformità. Un DSPM che si limiti a classificare i dati in base alle tassonomie PII/PHI/PCI potrebbe non tenere conto del requisito emergente di identificare e governare i dati che confluiscono nei set di addestramento dell’IA, nelle pipeline di ottimizzazione e negli archivi di generazione potenziata dal recupero. Si valuti se il DSPM sia in grado di rilevare l’esposizione di dati sensibili ai servizi di IA e se la sua tassonomia di classificazione sia sufficientemente estensibile da coprire i requisiti di governance specifici dell’IA.

Strutturazione del processo di valutazione

Un processo di valutazione rigoroso impedisce lo "scope creep" e gli orientamenti errati dettati dai fornitori.

Settimane 1–2: Definizione dei requisiti. Costituite il vostro comitato di valutazione (CISO o suo delegato, DPO, ingegnere della sicurezza cloud, responsabile degli appalti). Definite le funzionalità indispensabili rispetto a quelle auspicabili. Personalizzate la tabella di valutazione ponderata in base alle priorità della vostra organizzazione. Predisponete l’ambiente POC e il set di dati di riferimento.

Settimane 3–4: Richiesta di offerta (RFP) e selezione iniziale. Inviate richieste di offerta mirate utilizzando le domande relative ai fornitori contenute nella presente guida. Valutate le risposte scritte in base ai vostri criteri ponderati. Restringete la selezione a tre o quattro fornitori per le dimostrazioni.

Settimane 5–6: Dimostrazioni strutturate. Effettuare le dimostrazioni sulla base di un elenco standardizzato di scenari, anziché seguire lo script di dimostrazione preferito dal fornitore. Richiedere a ciascun fornitore di illustrare gli stessi casi d’uso: risoluzione delle autorizzazioni in M365, creazione di classificatori personalizzati, esecuzione delle misure correttive e integrazione SIEM.

Settimane 7–10: Proof of Concept. Sottoponete contemporaneamente i due fornitori finalisti a un POC in ambiente di produzione. Valutate le prestazioni del POC in base ai criteri ponderati utilizzando i dati misurati: accuratezza di classificazione, tasso di falsi positivi, prestazioni di scansione e tempo di andata e ritorno per la correzione.

Settimane 11–12: Valutazione finale, negoziazione e decisione. Riepilogo dei punteggi assegnati da tutti i valutatori. Presentazione della matrice di valutazione ai responsabili esecutivi, corredata di una chiara raccomandazione. Negoziazione dei termini contrattuali con il fornitore selezionato, utilizzando i dati relativi alle prestazioni del POC come leva per definire gli SLA.