Perché Sicurezza richiede trasparenza

Ogni fornitore sostiene che il proprio prodotto sia “sicuro” fino a un certo punto, ma la parola ha perso significato. Sicurezza è diventato un descrittore di marketing più che una proprietà misurabile. Nei sistemi di backup e storage, dove la posta in gioco è massima, la trasparenza è l’unico modo per trasformare la sicurezza da slogan in qualcosa che le organizzazioni possano valutare.  

Gli amministratori devono capire non solo cosa dichiara un fornitore, ma su quali assunzioni si basano tali affermazioni, a cosa è progettata per resistere l’architettura e come questi obiettivi siano stati validati. 

Per valutare le architetture di Zero Trust e di resilienza dei dati Zero Trust, i fornitori devono articolare cosa presumono accadrà durante un attacco, cosa presumono non accadrà e come si comporta il loro sistema quando tali assunzioni vengono messe in discussione. Senza questa chiarezza, le organizzazioni restano a interpretare rassicurazioni vaghe invece di evidenze concrete. 

Quando i fornitori non sono trasparenti, i clienti sono costretti a separare la realtà dal rumore. La trasparenza è ciò che consente loro di capire cosa è effettivamente vero. 

Zero Trust parte dal presupposto che una violazione avverrà.

Zero Trust viene spesso ridotto a un insieme di funzionalità di hardening come MFA, TLS, controllo degli accessi basato sui ruoli; tuttavia, il principio generale più importante è una mentalità “Assume Breach”. Questo significa presumere la compromissione non solo dell’ambiente di rete, ma anche del prodotto del fornitore stesso. Se un attaccante ottiene accesso amministrativo, ruba credenziali o impersona un operatore, il sistema di storage deve comunque proteggere i dati di backup. Un progetto Zero Trust non può avere successo se ogni parte coinvolta non adotta la mentalità “Assume Breach”.  

Se accetti che non è una questione di “se” ma di “quando”, allora devi essere pronto a ripristinare dopo un attacco nello scenario peggiore, non solo dopo quello previsto. 

Ecco perché le decisioni architetturali contano più delle checklist di hardening. Deve essere applicato il principio del minimo privilegio, in modo che nessun singolo individuo possa distruggere i dati di backup di un’azienda. La segmentazione delle funzioni garantisce che il software di backup e lo storage di backup non facciano parte dello stesso dominio di fiducia.  

La segmentazione dei domini di autenticazione impedisce che una compromissione in un piano di identità si propaghi a un altro. E la segmentazione di rete riduce i percorsi che un attaccante può usare per raggiungere i sistemi critici. 

Le funzionalità di hardening non rispondono alla domanda fondamentale: Cosa succede quando l’attaccante ha già le chiavi?  

Per questo Object First è fortemente impegnata su Zero Trust e lo dimostra tramite test indipendenti che verificano che il sistema si comporti come progettato, anche quando tutti i segreti sono noti. 

Perché storicamente la trasparenza è stata scoraggiata 

Test di sicurezza significativi richiedono indipendenza, trasparenza e ripetibilità. I soli test interni del fornitore sono insufficienti perché non possono essere separati da pressioni e incentivi interni.  

I test indipendenti di terze parti forniscono una valutazione esterna del fatto che il sistema si comporti come dichiarato, in particolare in condizioni avverse. Questi report devono essere pubblicati integralmente, non estratti selettivamente per creare una facciata positiva costruita in modo fuorviante. 

Le organizzazioni dovrebbero anche avere la possibilità di testare il sistema in autonomia o di incaricare una terza parte di farlo. Molte organizzazioni non avranno il tempo o le risorse per eseguire tali test, ma la possibilità di farlo è essenziale. Se il contratto di licenza di un fornitore vieta i test, tale limitazione dovrebbe essere considerata un segnale di allarme. Un sistema che non può essere testato non può essere considerato affidabile. 

La maggior parte delle organizzazioni non ha il tempo o le competenze per validare ogni affermazione sulla sicurezza. Per questo i fornitori devono fornire evidenze e guadagnarsi la fiducia, non darla per scontata. 

Object First passa dalle parole ai fatti 

I test indipendenti sono anche l’unico modo affidabile per validare le affermazioni su immutabilità, Zero Access e segmentazione. Non si tratta di caratteristiche valutabili esclusivamente tramite documentazione; devono essere dimostrate tramite penetration test esterni che simulano le condizioni riscontrate durante un attacco ransomware in corso. Questo è particolarmente importante per l’Immutabilità Assoluta, che presuppone che l’attaccante sappia tutto ciò che sa l’amministratore e che, nonostante ciò, non possa modificare o eliminare i dati di backup. 

Lo storage Backup deve fungere da ultima linea di difesa quando ogni altro controllo fallisce e da prima linea di ripristino quando l’organizzazione deve riottenere i propri dati. 

Documentazione aperta e definizione della superficie di attacco 

Un fornitore deve anche essere in grado di definire chiaramente la propria superficie di attacco. Senza questa definizione, né i test interni né quelli esterni possono essere significativi. Un sistema di storage per backup ben progettato ha una superficie di attacco ridotta, rigorosamente delimitata, con confini, protocolli e comportamenti documentati in modo chiaro. 

Un fornitore che non documenta questi componenti sta chiedendo alle organizzazioni di fidarsi di una scatola nera. Senza documentazione, le organizzazioni non possono capire come funziona il sistema, cosa espone o come dovrebbe essere valutato. Quando i fornitori evitano la documentazione, di fatto tengono le organizzazioni “all’oscuro” di come il sistema è progettato e di come si comporta. 

Una documentazione nascosta o incompleta crea un rischio semplice ma grave: le organizzazioni non sanno su cosa stanno facendo affidamento. Non possono testare ciò che non possono vedere e non possono valutare ciò che non possono definire. La trasparenza non richiede di sommergere i team IT e di sicurezza con dettagli inutili; richiede di documentare la reale superficie di attacco e di mantenere tale documentazione allineata a pattern di deployment credibili e a modelli di minaccia realistici. 

Come gli acquirenti dovrebbero valutare le affermazioni di sicurezza dei fornitori 

Ogni fornitore, in ultima analisi, chiede ai clienti di fidarsi. La domanda è se quella fiducia sia meritata. I team IT e di sicurezza dovrebbero cercare spiegazioni chiare dell’architettura di sicurezza del fornitore, incluse le assunzioni su ciò che accadrà e ciò che non accadrà durante un attacco. Dovrebbero aspettarsi una definizione della superficie di attacco, documentazione che rispecchi l’uso nel mondo reale e termini di licenza che consentano test indipendenti. 

Soprattutto, i clienti dovrebbero aspettarsi test indipendenti di terze parti che validino l’immutabilità del sistema, i controlli Zero Access e la segmentazione in condizioni avverse. Dovrebbero inoltre cercare l’impegno del fornitore verso il pledge CISA Secure by Design, che segnala la volontà di affrontare apertamente le sfide di sicurezza. 

Le affermazioni di un fornitore devono essere supportate dai fatti, non dalle parole. La trasparenza è ciò che trasforma tali affermazioni in qualcosa di verificabile.