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