È interessante il modo in cui è stato annunciato il recente furto di dati dai sistemi di Global Payments e chi si è sentito in dovere di darne comunicazione.
Le prime società che hanno dato l’annuncio sono state Visa e MasterCard. Non erano obbligate a farlo.
Global Payments invece lo era, in particolare aveva l’obbligo di segnalare specificamente il fatto che avevano subito la perdita di dati Track 1 o Track 2, che potevano includere nomi e numeri di carte dei clienti. Tuttavia inizialmente non è stato chiaro se la società avesse adempiuto o meno a questo obbligo, il che ha comportato per le società commerciali come la nostra, che potrebbero utilizzare Global Payments per la liquidazione delle transazioni, anche il dovere morale di rivelare l’inconveniente ai nostri clienti, come hanno dovuto fare Visa e MasterCard.
È difficile tenere traccia degli errori commessi all’interno della nostra rete di fornitori; questo nonostante i grandi vantaggi collaborativi di cui oggi godiamo grazie all’evoluzione della tecnologia cloud, che consente una crescente specializzazione mirata e ha reso possibile un mondo in cui non dobbiamo progettare direttamente i singoli componenti della soluzione IT attraverso cui forniamo i servizi ai nostri clienti. È un mondo, in effetti, in cui possiamo assemblare la rete di pagamento e affidare in outsourcing l’autenticazione, la sicurezza perimetrale ed eventualmente persino singoli sottocomponenti specifici dei nostri servizi e applicazioni (ad esempio, un servizio di geolocalizzazione da cui dipende la nostra applicazione), per consentire alle nostre risorse di concentrarsi sullo svolgimento del nostro ruolo nella catena del valore e, al tempo stesso, permettere ai nostri partner di sviluppare servizi esclusivi a partire dai nostri.
Ma la difficoltà sta proprio qui, perché la conseguenza del nuovo paradigma è una proliferazione della rete di interdipendenze tra i partner, mentre non è ancora chiaro a chi spetti il dovere di garantire attendibilità, responsabilità e trasparenza.
Le iniziative volte a chiarire questo aspetto e a regolarizzarlo sono in corso. Mi riferisco in particolare all’Open Data Center Alliance (ODCA), che ha creato un vocabolario che ci aiuta, nel nostro doppio ruolo di fornitori di servizi e consumatori di servizi, a comprendere i livelli di sicurezza, gli aspetti dell’architettura e gli elementi funzionali del servizio da noi fornito o ricevuto utilizzando l’ODCA come punto di riferimento.
È un inizio che potrebbe portarci a determinare non solo l’architettura tecnica di ciò che forniamo, ma anche l’architettura delle responsabilità. Ma non si tratta di una panacea, e qui ritorniamo al furto di dati subito da Global Payments.
La vulnerabilità emersa in questo incidente sembra essere stata l’attacco al front-end di autenticazione KBA (Knowledge-Based Authentication) di un sistema con account privilegiato, in cui gli autori hanno impersonato un utente con privilegi per irrompere all’interno della rete. Questo è accaduto nonostante l’account privilegiato fosse protetto con un livello di autenticazione a più fattori e KBA.
Quel meccanismo di protezione non aveva superato tutti i controlli e le ispezioni del caso? Per l’ODCA l’autenticazione a più fattori è infallibile.
Altre domande che i clienti di Global Payments dovrebbero porre in merito a questo furto di dati e che tutte le aziende dovrebbero seriamente porsi, includono:
– Come era distribuita l’autenticazione KBA?
– Quanto è effettivamente inconoscibile l’informazione che è stata utilizzata per valutare l’autenticità dell’utente?
– Che tipo di monitoraggio dei controlli era in atto per garantire l’esistenza di sistemi di intercettazione e analisi dei punti d’ingresso non autorizzati e/o di analisi a posteriori per agevolare il monitoraggio dei modelli di utilizzo e stabilire una strategia di difesa approfondita, che oltre all’autenticazione complessa prevedesse forme di analisi complessa, in modo da poter cercare eventuali anomalie?
– Perché non era stata considerata l’eventualità che persino quel sistema di front-end a più fattori potesse subire violazioni?
A dire il vero, è difficile per un qualsiasi cliente o partner imporre cambiamenti nella qualità di implementazione dei controlli di sicurezza di Global Payments o di qualsiasi altra società.
I clienti e i partner possono, tuttavia, decidere di evolversi, adottare le proprie contromisure, fare tutto quanto è in loro potere e partecipare alle discussioni del settore sulla protezione delle credenziali e lo sviluppo di nuove tecnologie di sicurezza.
Questa evoluzione sarà il risultato dell’iniziativa di identificazione elettronica dell’UE? Se sì, seguiamone lo sviluppo e adottiamola.
L’evoluzione sarà correlata a OAuth, un metodo standard di scambio di token di sicurezza e federazione SSO (Single signe-n) tra i servizi che offriamo e i servizi che i nostri partner forniscono ai loro clienti tramite noi? Se sì, adottiamo anche questo protocollo.
Tutte queste osservazioni possono essere riassunte con una delle mie parole preferite: trasparenza.
L’architettura orientata ai servizi è una tecnologia che prevede l’opacità e la capacità di consumare i servizi esclusivamente in base alla loro descrizione funzionale, per poi integrarli in un’architettura tecnica senza preoccuparsi di quale sia l’implementazione sottostante. Non importa se ad agire dietro le quinte è Java, PHP o sedici scimmie rinchiuse in una stanza con le macchine da scrivere: l’unica cosa che conta è rispettare un contratto di interfaccia e un accordo sul livello di servizio (SLA – Service Level Agreement).
Ma nella catena del valore aziendale, la trasparenza ha un’importanza capitale. Abbiamo bisogno della trasparenza per sapere dove si trovano i dati, quali standard vengono utilizzati nel data center, quali sono le iniziative per la conformità, a quali profili di sicurezza è conforme il servizio e cosa sta accadendo dal punto di vista della responsabilità.
In breve, l’opacità tecnica va bene, la trasparenza aziendale va bene e la trasparenza della sicurezza va bene.
Se riusciremo a monitorare l’evoluzione delle iniziative in materia di sicurezza, come ODCA, OAuth e identificazione elettronica dell’UE, mentre assembliamo i servizi che offriamo ai nostri clienti, assicurando al tempo stesso la precisione e l’opacità tecnica e, dal punto di vista della sicurezza, l’apertura e la trasparenza, forse la nostra duplice posizione, a metà tra fornitori e consumatori, non dovrà più essere così precaria come è certamente oggi.