Scritta su un treno delle 7 del mattino, dopo tre caffè decisamente pessimi.
Questo articolo è nato come un messaggio su Teams al nostro Direttore Marketing. Ero sul treno delle 7 diretto a Manhattan, con tre caffè decisamente pessimi già in corpo, e avevo appena finito di spiegare a un collega cosa fa realmente PKWARE per le banche.
Ecco la storia che gli ho raccontato.
Quando entro in una grande banca, la domanda non è: “Che cosa fa il vostro prodotto?“Ogni fornitore ha il suo prodotto e la sua presentazione.
La vera domanda, quella che nessuno esprime apertamente, è un’altra:
“Considerata la complessità della nostra infrastruttura, sappiamo davvero dove si trovano tutti i nostri dati sensibili? E siamo in grado di proteggerli prima che qualcun altro possa comprometterli?”
Questa non è una domanda sulla qualità del lavoro del team di sicurezza. È una domanda che nasce dalla complessità dell’infrastruttura.
Con oltre duecentomila endpoint, numerosi ambienti cloud, milioni di file in SharePoint e sistemi legacy che continuano a gestire processi mission critical, la visibilità dei dati non è più un problema operativo: è un problema di architettura.
Vediamo come questa conversazione si traduce nella pratica, attraverso alcuni esempi tratti dalle banche con cui lavoro.
JPMorgan Chase: oltre un quarto di milione di endpoint
JPMorgan Chase gestisce più di 250.000 endpoint: sale operative, filiali, call center, notebook dei consulenti e dispositivi distribuiti in sedi che spesso nemmeno l’inventario IT riesce a censire completamente.
Su ciascuno di questi sistemi può essere presente qualche dato sensibile lasciato lì per errore: informazioni sulle carte di pagamento (PCI), dati personali (PII), vecchi screenshot di conti clienti salvati durante attività di assistenza e mai rimossi.
È qui che interviene PK Protect.
La piattaforma non si limita a individuare questi dati. Identifica il tipo di informazione, da quanto tempo è presente, verifica se è ancora utilizzata oppure se è ormai obsoleta e applica automaticamente la policy di protezione prevista.
A seconda del caso, il dato può essere cifrato, mascherato, anonimizzato, archiviato o eliminato. La scelta dipende dal tipo di dato, dai requisiti normativi e dalle politiche definite dall’organizzazione.
Una sola scansione. Un unico motore di policy. Più di 250.000 endpoint gestiti.
Fiserv: mettere ordine per semplificare gli audit
Per Fiserv il problema è diverso.
I dati sensibili non sono sconosciuti: sono semplicemente ovunque. Server, cartelle condivise, repository legacy.
L’obiettivo del CISO non è tanto scoprirli, quanto poter affrontare serenamente un audit.
Per questo PK Protect esegue la scansione dell’infrastruttura e, oltre a proteggere i dati, li centralizza in repository definiti e controllati.
In questo modo esiste un unico punto in cui risiedono le policy, un unico punto di riferimento per gli auditor e un ambiente facilmente gestibile dal team Compliance.
Quando arriva un’ispezione da parte dell’autorità di vigilanza, la domanda “Dove sono conservati i dati delle carte di pagamento?“ non richiede una riunione di novanta minuti. Basta una semplice interrogazione del sistema.
Western Union: SharePoint oltre i limiti di scalabilità
Western Union gestisce centinaia di milioni di record dei clienti e un’enorme infrastruttura SharePoint.
Microsoft consente di applicare le Sensitivity Labels ai documenti, ma gli strumenti nativi presentano limiti di scalabilità quando i volumi diventano estremamente elevati.
È qui che PK Protect fa la differenza.
La piattaforma individua i contenuti sensibili e applica automaticamente le etichette Microsoft anche su volumi molto superiori.
E se un file non può essere etichettato, la policy non si interrompe.
Il sistema passa automaticamente all’azione successiva prevista: maschera il contenuto, lo anonimizza, lo sposta oppure lo mette in quarantena.
In altre parole, il dato viene comunque protetto.
Wells Fargo e USAA: la stessa protezione, anche su scala petabyte
Ora immaginiamo un’infrastruttura di dimensioni ancora maggiori. Non parliamo più di endpoint, ma di cluster HDFS, tabelle Hive, bucket S3 e Azure Data Lake: gli ambienti in cui operano organizzazioni come Wells Fargo e USAA.
In contesti di questo tipo, una sola configurazione errata di un bucket può esporre su Internet una quantità di dati personali (PII) superiore a quella gestita complessivamente da alcuni piccoli Paesi.
Il motore di scansione è lo stesso. Le policy sono le stesse. Anche le opzioni di protezione rimangono invariate.
Ciò che cambia è l’ambiente in cui i dati risiedono.
PK Protect tratta un data lake di dimensioni petabyte con lo stesso approccio utilizzato per il laptop di un responsabile marketing: individua i dati sensibili, li classifica, li protegge e ne dimostra la conformità.
Il livello di controllo rimane identico; cambia soltanto il contesto in cui viene applicato.
È questo il principio su cui si basa l’intera piattaforma.
Truist: il mainframe che molti fornitori preferiscono evitare
È a questo punto che la conversazione cambia spesso tono. Basta parlare di dataset COBOL, file GDG o file PDS perché molti fornitori di soluzioni di sicurezza “moderne” sfoggiano un sorriso di circostanza e cambino rapidamente argomento.
Noi no.
Con Truist applichiamo ai sistemi mainframe lo stesso approccio che utilizziamo per un laptop. Individuiamo i dati sensibili all’interno dei programmi COBOL e dei dataset associati, quindi applichiamo le policy di protezione previste: crittografia, mascheramento, anonimizzazione o eliminazione dei dati, a seconda delle esigenze.
Il mainframe entra così a far parte dello stesso piano di controllo che governa endpoint e ambienti cloud.
Per le banche che operano con infrastrutture di questo tipo – e sono molte più di quanto lascino intendere i report degli analisti – questa rappresenta una differenza sostanziale.
Pochissimi fornitori sono in grado di offrire una protezione unificata su tutti e tre gli ambienti: endpoint, cloud e mainframe. Ed è proprio questo che rende la conversazione con i clienti molto più concreta.
Cosa significa, in concreto
L’idea è semplice: un’unica interfaccia, un unico prodotto e un solo motore di policy in grado di operare sugli endpoint di JPMorgan Chase, sui file server di Fiserv, su SharePoint di Western Union, sui data lake di Wells Fargo e USAA e sui mainframe di Truist.
L’obiettivo non è vendere una singola funzionalità.
Le banche acquistano qualcosa di molto più importante: la certezza che i dati sensibili siano individuati correttamente, protetti in modo coerente e sempre conformi ai requisiti normativi.
Secondo PKWARE, questo livello di affidabilità può essere raggiunto soltanto attraverso un’architettura unica, capace di gestire ogni ambiente in cui i dati vengono archiviati.
Questa è la storia che racconto ogni volta. Mi ci sono voluti un viaggio in treno e tre pessimi caffè per metterla nero su bianco. ll caffè, per fortuna, è stato l’unica cosa davvero difficile di quella mattina.
La conclusione, però, rimane la stessa.
Se ti occupi di sicurezza o protezione dei dati nel settore bancario e questa conversazione ti suona familiare, parliamone
Fonte: EJ Pappas – Pkware