Perché non esiste uno standard per impedire che i file vengano allegati alle e-mail?

In parole semplici, sarebbe molto lavoro da implementare per un guadagno del mondo reale trascurabile.

Immaginiamo per un momento che esistesse un tale meccanismo "standard" per i metadati che descrivono il livello di riservatezza di un particolare file e siamo in grado di sviare i dettagli tecnici che implementano tale meccanismo su più formati di file, sistemi operativi , server di posta, client ecc.

Qualcuno sarà in definitiva responsabile della definizione di tali informazioni in base al file e, logicamente, saranno le persone che creano / lavorano con questi file.

Quindi, Joe Bloggs in contabilità ha lavorato alle cifre trimestrali della società in Excel per l'ultima settimana o giù di lì, e come l'impiegato diligente che ha ha spuntato la casella per indicare che si tratta di informazioni "riservate". Soddisfatto del lavoro ben fatto e certo che non appena Mr Grand Boss l'amministratore delegato vedrà i suoi grafici a torta dettagliati e colorati, riceverà quel rilancio che sperava, quindi allega il file Excel completato a una nuova e-mail e colpisce invia. Outlook rifiuta comunque di inviare la posta, poiché l'allegato è contrassegnato come "Riservato" e l'invio di tali file è vietato.

Joe ha ancora bisogno di ottenere queste cifre per l'amministratore delegato, ma anche lui:

a) Guarda in qualche modo che può crittografare il file? Ha già sentito la parola nei film, ma non sa veramente cosa significa, né da dove cominciare.

o

b) apri il file, deseleziona la casella "Riservato" e ricollegalo all'e-mail.

Posso quasi garantire che nel 99% dei casi sarà l'opzione B, e che non è qualcuno che cerca di eludere la sicurezza. Stanno solo cercando di fare il loro lavoro.

Per qualcuno che sta cercando di eluderlo, per inviare informazioni e documenti riservati ai concorrenti o chiunque per scopi nefandi. Quindi, se dispongono delle autorizzazioni per modificare il file, rimuoveranno la bandiera riservata, invieranno la posta e quindi la riattiveranno. Anche se tutto ciò che hanno è accesso in lettura, aprirà il file e copierà e incollerà il contenuto in uno nuovo e lo invierà.

Quindi in entrambi questi scenari il flag "Confidential" ha fatto esattamente nothing per aumentare la sicurezza

I sistemi di opt-in sono cattivi. Non c'è nulla che imponga tale protezione; si può sempre usare solo un client di posta elettronica / visualizzatore di documenti che ignora tali restrizioni. (Credo che il software di visualizzazione PDF "Okulus" abbia ancora un segno di spunta da qualche parte nelle sue impostazioni per "rispettare il DRM nei documenti", è deselezionato per impostazione predefinita). Evidenziare tali sistemi è facile; puoi modificare il file (oi suoi metadati), o inserirlo in una sorta di wrapper (come un archivio ZIP o tarball) che nasconde i metadati, o modificare l'estensione in qualcosa che non memorizza i metadati allo stesso modo, e i filtri del client non lo cattureranno.

Dove memorizzi i metadati? Alcuni file system consentono "attributi estesi" o "flussi di dati alternativi" o simili, ma molti non lo fanno, specialmente quelli come le onnipresenti varianti FAT utilizzate per quasi tutti gli archivi rimovibili. Anche quando i file system supportano tali strutture, di solito non sono compatibili con i file system across , quindi è necessario creare degli standard e gli sviluppatori dovrebbero controllare, con una vasta gamma di modi, un file potrebbe essere segnato. Alcuni tipi di file consentono di archiviare internamente quel tipo di dati, come parte del file stesso, ma sicuramente non funzionerà con semplici formati di testo semplice come CSV e non sarà mai universale ; potresti ottenere qualcosa che funzioni per i file di MS Office (che di fatto hanno una gamma di campi di metadati e il loro formato standardizzato) ma non per i formati Open Office (ODT, ecc.) che non hanno questo nei loro standard e sostanzialmente più tipi di file diversi, come le registrazioni audio, memorizzerebbero tali metadati in modo diverso se non lo fossero affatto.

Fondamentalmente, sarebbe un sacco di sforzo per un ritorno molto piccolo e l'implementazione avrebbe sempre dei buchi comunque (quando un nuovo formato salirà alla ribalta, o verrà adottato un nuovo sistema di comunicazione, o qualsiasi altra cosa).

Con alcune eccezioni (in particolare DMARC ), gli standard delle e-mail sono ignorati e siamo bloccati in un mondo di qualunque supporto e server di posta elettronica comuni supporteranno, nel bene o nel male (soprattutto peggio). Questo è paragonabile al modo in cui il web ha funzionato quando Netscape Navigator e Internet Explorer erano i migliori browser, anche se in modo abbastanza sicuro.

Pertanto, spetta ai grandi giocatori dettare i termini al resto. Google lo ha fatto fino ad un certo punto, decretando che ci sono alcuni formati di file che GMail rifiuta di inviare :

File types you can't include as attachments [at GMAIL]

.ADE, .ADP, .BAT, .CHM, .CMD, .COM, .CPL, .EXE, .HTA, .INS, .ISP, .JAR, .JS ^(NEW), .JSE, .LIB, .LNK, .MDE, .MSC, .MSI, .MSP, .MST, .NSH .PIF, .SCR, .SCT, .SHB, .SYS, .VB, .VBE, .VBS, .VXD, .WSC, .WSF, .WSH

Vedo .CSV , .XLS e formati simili come troppo comuni per il blocco all'ingrosso. .PDF è estremamente importante in quanto è l'unico formato di documento affidabile se è necessario garantire un rendering coerente (come per la pubblicazione di prove, marketing o curriculum).

Ci sono soluzioni là fuori che eseguono la protezione dalla perdita di dati per combattere i problemi di exfiltration, e ci sono altre soluzioni là fuori che presteranno particolare attenzione ai formati di documenti con aspetti eseguibili (come macro e flash incorporati). Penso che quelli siano il modo più semplice per fare questo genere di cose, anche se sono di parte (la soluzione di sicurezza della posta elettronica su cui lavoro offre queste cose).