Whitepaper di LayerT
Fail-closed per progettazione
Un controllo che funziona nel browser ha un punto debole evidente: il browser si trova sul laptop del dipendente. Se il laptop può smettere in silenzio di ricevere la policy, o accettare una policy che non dovrebbe, il controllo diventa un semplice suggerimento. Questo documento descrive come LayerT chiude queste lacune con una policy firmata e un comportamento predefinito fail-closed (in caso di errore blocca), e come appare tutto questo alla persona davanti alla tastiera.
Perché applicare le regole proprio nel browser
Gli strumenti di sicurezza di rete vedono traffico cifrato verso un sito web. Non possono vedere cosa è stato digitato in un modulo di login, né a chi appartenesse l’account. Quando una richiesta raggiunge la rete, un login personale su un laptop di lavoro appare identico a uno di lavoro.
LayerT gira là dove avviene la digitazione. Il suo content script vede il valore nel campo, lo confronta con le vostre regole e agisce prima che il codice del sito invii la richiesta. Questa posizione è il vantaggio del prodotto, ed è anche il motivo per cui la policy che applica deve essere affidabile.
Una policy, una firma
Gli amministratori scrivono le regole nella console come bozze. La pubblicazione trasforma tutte le bozze in sospeso in un’unica nuova versione della policy della vostra organizzazione. I numeri di versione possono solo crescere, e ogni pubblicazione prende il numero successivo sotto un lock, così due amministratori non possono produrre la stessa versione.
- ConsoleBozzeRegole, modifiche agli elenchi e revoche di eccezioni vengono preparate. Revisione facoltativa a due autori.
- Cloud di LayerTCompilazioneRegole, eccezioni approvate ed elenchi delle persone vengono raccolti in un unico documento per l’intera organizzazione.
- Cloud di LayerTFirmaJSON canonico (chiavi ordinate, firma esclusa) firmato con Ed25519.
- BrowserVerificaVerificato con Web Crypto rispetto alle chiavi integrate nell’estensione.
Il documento firmato riporta l’organizzazione a cui appartiene, la sua versione, quando è stato emesso e quando scade. Il rollback non riavvolge la cronologia. Pubblica le vecchie regole come una versione nuova e più alta, mantenendo le eccezioni approvate nel frattempo.
Cosa verifica il browser
L’estensione scarica la policy ogni 15 minuti, all’avvio e dopo la navigazione, usando richieste condizionali, così una policy invariata non costa quasi nulla. Prima di usare una policy, verifica:
| Verifica, nell’ordine | Rifiuta |
|---|---|
| Versione | Tutto ciò che non è più recente di ciò che ha già, così una policy vecchia non può essere riproposta |
| Organizzazione | Una policy destinata a qualsiasi organizzazione diversa dalla propria |
| Chiave | Tutto ciò che è firmato con una chiave che l’estensione non conosce |
| Firma | Tutto ciò che non risulta valido rispetto alla chiave pubblica integrata nell’estensione |
| Scadenza | Una policy oltre la sua ora di scadenza, secondo l’orologio del laptop |
Una policy rifiutata viene scartata, e il browser mantiene quella che aveva. Nell’estensione possono essere integrate più chiavi pubbliche contemporaneamente, così la chiave di firma può essere ruotata senza interruzioni. In produzione, la chiave di firma è custodita in Google Cloud KMS, configurata con protezione basata su hardware, e non può essere esportata: i server di LayerT chiedono a KMS ogni singola firma. Questo è realizzato e si attiva con il primo deploy in produzione di LayerT. Le build di sviluppo firmano con una chiave locale di cui le build di produzione dell’estensione non si fidano.
Il comportamento fail-closed
Ogni policy scade 7 giorni dopo l’emissione. LayerT la firma di nuovo automaticamente 48 ore prima, quindi un browser connesso non vede mai una policy scaduta. La vede solo un browser che non è riuscito a raggiungere LayerT per giorni.
In quel caso, LayerT non ripiega su “consenti”. Su qualsiasi pagina coperta da una regola blocca o forza il logout, ferma gli invii dei moduli e le operazioni di incolla nei campi della regola, e mostra una scheda che spiega il motivo:
Connectivity required (connessione necessaria). LayerT non è riuscito ad aggiornare la policy di questo browser, quindi non può verificare questa azione. Collegatevi alla vostra rete, poi riprovate.
Le regole avvisa e monitora continuano a funzionare. Quando il browser si riconnette e riceve una policy aggiornata, la scheda scompare da sola entro circa 30 secondi, senza ricaricare la pagina.
Abbiamo scelto il comportamento fail-closed solo dove si applica una regola di blocco, non sull’intero web. Una policy non aggiornata su un laptop ferma il login rischioso. Non impedisce alla persona di leggere le notizie.
L’arresto di emergenza
A volte serve disattivare l’applicazione delle regole, ovunque, subito: una regola è sbagliata e sta bloccando il team commerciale. L’Owner può attivare un arresto di emergenza. L’arresto è esso stesso una versione firmata della policy, quindi nessuno può inviare a un browser un arresto falsificato per disattivare LayerT. Viene registrato nel log, e i browser lo recepiscono alla sincronizzazione successiva: entro 15 minuti, prima se la persona naviga. L’arresto è contrassegnato come urgente all’interno della policy, ma oggi l’estensione non lo scarica più rapidamente delle altre modifiche.
Eccezioni senza backdoor
Una regola può permettere alle persone bloccate di chiedere l’accesso. Un approvatore sceglie per quanto tempo: un singolo tentativo (una finestra di cinque minuti), 15 minuti, oppure 1, 8 o 24 ore. Le eccezioni permanenti possono essere concesse solo dal Compliance Officer o dall’Owner, mai dall’IT, così chi scrive le regole non è chi concede eccezioni permanenti a quelle regole.
Un’approvazione diventa parte di una policy firmata di nuovo, in un unico passaggio atomico, quindi un’eccezione è affidabile esattamente quanto la regola che allenta. Nessuno può approvare la propria richiesta. Il server la rifiuta. Le richieste su cui nessuno decide scadono.
Un’applicazione che una pagina non può aggirare
LayerT agisce sugli invii dei moduli e sulle operazioni di incolla prima che vengano eseguiti i gestori del sito, e li annulla quando una regola trova una corrispondenza, quindi la richiesta del sito non parte mai. I prompt che spiegano un blocco sono costruiti per resistere alla pagina su cui sono disegnati:
- shadow root chiuse che gli script della pagina non possono raggiungere,
- pulsanti che rispondono solo a clic e pressioni di tasti reali,
- nessun campo password, mai, e un piè di pagina che dice che LayerT non ne chiede mai una,
- un puntino ambra sull’icona di LayerT nella barra degli strumenti, che la pagina non può disegnare.
Cosa viene registrato
Ogni blocco, ogni corrispondenza di una regola monitora e ogni uso di un’eccezione viene registrato nel log con il sito, il campo, il valore corrispondente e la persona. I valori sono leggibili di proposito, così un auditor può confermare che ciò che è stato bloccato era davvero un account personale. Gli eventi di audit sono conservati per 365 giorni di default.
Cosa contiene un pacchetto, e cosa può fare un laptop compromesso
La policy firmata che un browser riceve si chiama pacchetto di policy. È un unico documento JSON per l’intera organizzazione: ogni regola, gli elenchi a cui le regole fanno riferimento, l’impostazione dell’arresto di emergenza, l’elenco dei browser revocati e ogni eccezione approvata e attiva. Non contiene mai password degli account condivisi, codici dell’app di autenticazione, credenziali del dispositivo o chiavi di firma. Questi viaggiano separatamente, un login alla volta, e restano in memoria.
Da questa progettazione derivano due conseguenze, che dichiariamo apertamente.
Ogni laptop contiene il pacchetto dell’intera organizzazione. Oggi ogni browser riceve lo stesso pacchetto, quindi ogni laptop gestito contiene le allowlist e le appartenenze ai gruppi di altre persone, e ogni eccezione attiva con il valore approvato, chi l’ha approvata e la motivazione fornita. I pacchetti limitati a una singola persona fanno parte della progettazione di LayerT ma non sono realizzati. Trattate il pacchetto come dati aziendali interni.
La firma protegge il pacchetto in transito, non a riposo. Il browser verifica un pacchetto una sola volta, al suo arrivo, poi lo salva come JSON in chiaro nel profilo del browser e applica ciò che ha salvato. A riposo, lo protegge solo la cifratura del disco del laptop. Quindi:
| Chi | Cosa può fare |
|---|---|
| Una pagina web | Nulla sul pacchetto. Non può leggere lo storage dell’estensione né inviare messaggi all’estensione |
| Qualcuno sulla rete | Ritardare gli aggiornamenti fino a 7 giorni, dopodiché le regole di blocco vanno in fail-closed. Non può falsificare, alterare o riproporre un pacchetto |
| La persona, o software eseguito con la sua identità | Leggere l’intero pacchetto. Un software in grado di scrivere nello storage dell’estensione del profilo può modificarlo e disattivare l’applicazione delle regole |
| Un amministratore, o malware con diritti di amministratore | Aggirare LayerT su quel laptop: modificare lo storage, rimuovere le policy, sostituire l’estensione o cambiare l’orologio |
| Chi ha in mano un laptop bloccato con cifratura del disco | Nulla nel profilo. Revocate comunque il browser |
Nessun controllo che giri all’interno di un browser può resistere a un amministratore sullo stesso laptop, e LayerT non pretende di farlo. Si affida ai controlli che ogni parco macchine gestito dovrebbe avere: cifratura completa del disco, nessun diritto di amministratore locale, LayerT installato forzatamente tramite il vostro MDM, strumenti per sviluppatori delle estensioni e modalità sviluppatore bloccati, e una procedura che revoca il browser, sospende la persona e blocca il laptop contemporaneamente. La revoca di un browser lo esclude da LayerT e gli impedisce di applicare le regole. Non lo blocca.
Una violazione dei server di LayerT è un caso diverso. Un attaccante che controlla l’applicazione di LayerT potrebbe chiedere a Cloud KMS di firmare finché mantiene quell’accesso, e i browser accetterebbero ciò che ha firmato. Non potrebbe copiare la chiave all’esterno, ogni richiesta di firma viene registrata nel log, e rimuovere il suo accesso pone fine al problema. L’analisi completa, caso per caso, è in Pacchetti di policy e compromissione del dispositivo.
Limiti
- LayerT valuta gli invii dei moduli e le operazioni di incolla nei campi indicati da una regola. Non è una soluzione generica di data loss prevention.
- L’arresto di emergenza e le nuove regole raggiungono un browser alla sincronizzazione successiva, non istantaneamente.
- Un pacchetto viene verificato quando arriva, non ogni volta che viene letto. Chi può scrivere nello storage dell’estensione del profilo del browser, o ha diritti di amministratore locale, può aggirare l’applicazione delle regole su quel laptop. Impedite alle persone di avere diritti di amministratore locale.
- Ogni browser contiene il pacchetto dell’intera organizzazione, comprese le eccezioni approvate di altre persone.
- La scadenza viene valutata in base all’orologio del laptop.
- Il pacchetto firmato dell’estensione che l’MDM installa forzatamente è realizzato e verrà distribuito con il primo rilascio in produzione di LayerT. L’installazione forzata impedisce alle persone di disattivare LayerT nelle impostazioni di Chrome. Non ferma un amministratore.
Il modo migliore per giudicare una progettazione fail-closed è provare a romperla. Portate alla demo le vostre domande più difficili: vi mostreremo che cosa succede.