L’agente di rete o agent è un nuovo concetto introdotto dalla Zero trust Security e si riferisce al connubio tra utente e dispositivo. In una rete ZTS, infatti, non è sufficiente trattare separatamente l’utente e il dispositivo, poiché i criteri devono considerarli insieme per imporre con precisione ed efficacia il comportamento desiderato.
Definendo formalmente un agent nel sistema, siamo in grado di catturare questa relazione e usarla per alimentare e guidare le policy di sicurezza.
Indice degli argomenti
Zero Trust Security e agent: uno scenario d’uso
Ipotizziamo uno scenario in cui abbiamo a che fare con un’azienda realmente attenta alla cyber security. Ogni dipendente riceverebbe una workstation (fisica o virtuale) adatta per svolgere il proprio lavoro: ma con la propria vita personale e il lavoro che oggi si mescolano insieme sempre più, verosimilmente alcuni vorranno utilizzare la posta elettronica e il calendario sul proprio smartphone personale.
In questa ipotetica azienda, il team di sicurezza informatica applicherà delle policy granulari in base alla determinata risorsa su cui viene chiesto l’accesso e al dispositivo utilizzato dall’utente in quel momento.
Ad esempio, sarà probabilmente consentito eseguire il commit del codice dal laptop assegnato dall’azienda al dipendente, ma farlo dal suo smartphone potrebbe costituire un evento anomalo (nonché la possibile generazione di un allarme).
Poiché l’accesso al codice sorgente da un dispositivo mobile personale è più rischioso rispetto a quello effettuabile da una workstation aziendale censita, il SOC aziendale bloccherà tale accesso (o quantomeno, questo è il mio auspicio).
Questo scenario giocattolo è un’applicazione abbastanza tipica della Zero Trust Security, in quanto si verificano molteplici fattori di autenticazione e autorizzazione che riguardano sia l’utente che il dispositivo.
In questo esempio, tuttavia, è chiaro che un fattore influenza l’altro: un utente che potrebbe “normalmente” avere accesso al codice sorgente non godrà di tale accesso dal proprio dispositivo mobile.
Inoltre, questa organizzazione non desidera che gli utenti autenticati eseguano il commit del codice da qualsiasi dispositivo attendibile, ma si aspettano che gli utenti utilizzino il proprio dispositivo aziendale. Ecco, quindi, che si torna al concetto di agente di rete o agent.
Il ruolo degli agent nella Zero Trust Security
Un agent fornisce una combinazione di dati sugli attori di una specifica richiesta di rete, combinazione che contiene quantomeno un utente, un’applicazione e un dispositivo.
Nelle reti tradizionali (ossia la maggior parte in Italia nel momento in cui sto scrivendo), da sempre queste entità vengono autorizzate separatamente, mentre nelle reti ZTS le policy sono definite avvalendosi di una combinazione di tutti i partecipanti a una richiesta.
Autorizzando (o negando) l’intero contesto di una richiesta, l’impatto del furto di credenziali viene notevolmente mitigato: è più proficuo pensare a un agent di rete come a un’entità che si forma su richiesta, al fine di valutare una policy.
I dati utilizzati per alimentare un agent
I dati utilizzati per alimentare un agent (informazioni sull’utente, sul dispositivo e sull’applicazione) vengono in genere archiviati in una memoria permanente, e interrogati periodicamente. Quando questi dati vengono interrogati, l’unione dei dati in quel preciso momento costituirà ciò che chiamiamo agent.
La granularità dei dati contenuti all’interno di un agent può variare in base alle esigenze e alla maturità: può essere di alto livello come l’account utente o il produttore di un dispositivo, o di più basso livello come i numeri di serie, il luogo di residenza o di emissione.
Il tipo di dati archiviati in un agent può variare notevolmente sia relativamente alla disponibilità, che alla granularità. Ecco alcuni esempi di dati che si potrebbe riscontrare in un agent:
- percentuale di affidabilità dell’agent;
- percentuale di affidabilità dell’utente;
- ruolo dell’utente o del gruppo;
- residenza o dimora dell’utente;
- metodo d’autenticazione dell’utente;
- percentuale di affidabilità del dispositivo utilizzato dall’utente in quel momento;
- produttore del dispositivo;
- vendor e versione dell’eventuale modulo TPM;
- attuale posizione del dispositivo;
- indirizzo IP.
Attendibilità dei dati contenuti nell’agent
Un altro punto di attenzione riguarda il dilemma se i dati contenuti nell’agent siano o meno effettivamente attendibili. Ad esempio, i dati del dispositivo censiti durante il processo di approvvigionamento sono più affidabili dei dati del dispositivo che vengono riportati da un agent in esecuzione su di esso.
Questa differenza di fiducia deriva dalle difficoltà nel garantire l’accuratezza e l’integrità delle informazioni riportate nel caso in cui il dispositivo sia stato compromesso.
Alcuni campi dell’agent sono resi disponibili specificamente per mitigare eventuali attacchi attivi, e pertanto cambieranno rapidamente rispetto alle modifiche non frequenti che normalmente le organizzazioni ICT si aspettano.
I punteggi di affidabilità sono un esempio di questo tipo di dati dinamici. I sistemi di punteggio di affidabilità possono valutare ogni richiesta in rete, utilizzando quel feed di attività per aggiornare i punteggi di affidabilità di utenti, applicazioni e dispositivi.
Pertanto, affinché un punteggio di affidabilità possa mitigare un nuovo attacco, dovrà essere aggiornato con una tempestività il più vicina possibile al tempo reale.
Oltre a dati in rapida evoluzione, gli agent disporranno spesso di dati sparsi. Un dispositivo sottoposto a bootstrap è uno scenario di esempio in cui l’agent avrà meno dati rispetto a un dispositivo maturo.
Durante il processo di bootstrap molti conoscono poco del dispositivo, ma sicuramente sappiamo che dovrà comunque interagire con l’infrastruttura aziendale per eseguire attività come la registrazione del dispositivo e l’eventuale installazione di software.
In un contesto in cui il dispositivo di bootstrap non è ancora assegnato a un utente, potrebbe incorrere in problemi se la policy che è stata configurata prevede che un utente assegnato sia presente nell’agent: questo scenario, ad esempio, dovrebbe essere previsto e riflesso nella policy di autorizzazione.
La carenza di dati non si verifica solo negli scenari di bootstrap: i sistemi autonomi in una rete ZTS hanno spesso dati non sufficienti rispetto ai sistemi gestiti dall’uomo. Questi sistemi generalmente non autenticano l’account utente con cui viene eseguita l’applicazione, basandosi invece sulla sicurezza del software di management utilizzato da quell’utente.
Usare informazioni di autorizzazione “non tradizionali”
In una rete ZTS, quando si decide di autorizzare è l’agent a essere effettivamente autorizzato. Sebbene si sia tentati di autorizzare il dispositivo e l’utente separatamente, questo approccio non è consigliato.
Poiché l’agent è l’entità autorizzata, è anche il fulcro per il quale la relativa policy è stata pensata e configurata.
L’agente trasporta molte informazioni, pertanto, mentre è ancora possibile utilizzare informazioni di autorizzazione più “tradizionali” come l’indirizzo IP, sfruttare l’agent vuol dire anche poter utilizzare informazioni di autorizzazione “non tradizionali” come il tipo di dispositivo o la città di residenza.
In quanto tale, una policy di rete ZTS viene scritta per l’agent nel suo insieme, invece di creare criteri disgiunti per utenti e dispositivi, come accade nelle reti tradizionali.
L’uso di un agent per guidare le policy ci invita a considerare il contesto di comunicazione nel suo complesso. L’unione di utente e dispositivo è fondamentale nelle decisioni di autorizzazione ZTS, e la collocazione dei dati in un agent rende difficile ignorare l’uno o l’altro.
Come con altre parti dell’architettura ZTS, l’abbassamento della barriera all’ingresso è fondamentale, e la collocazione dei dati per semplificare il confronto dispositivo/utente non è differente.
Essendo l’attore principale nella rete, un agent svolge un ruolo aggiuntivo nel calcolo dei punteggi di fiducia.
Il “motore di fiducia” può utilizzare le azioni registrate, oltre ai dati contenuti all’interno dell’agent stesso, per valutare altri agent in base alla loro affidabilità. Questo punteggio di affidabilità verrà quindi esposto come attributo aggiuntivo sull’agent rispetto al quale la maggior parte dei criteri dovrebbe essere definita.
Agent e differenza tra autenticazione e autorizzazione
È importante comprendere la differenza tra autenticazione e autorizzazione nel contesto degli agent. Gli agent fungono esclusivamente da componenti di autorizzazione e non svolgono alcun ruolo nell’autenticazione.
In effetti, l’autenticazione è un precursore della formazione degli agent, e viene generalmente eseguita separatamente per utente e dispositivo. Ad esempio, i dispositivi potrebbero venire autenticati con certificati X.509, mentre gli utenti potrebbero essere autenticati tramite un approccio multifattoriale tradizionale.
Dopo l’avvenuta autenticazione, gli identificatori canonici per utenti e dispositivi possono essere utilizzati per formare un agent e i suoi dettagli. Un certificato specifico del dispositivo potrebbe essere utilizzato come identificatore canonico per il dispositivo, quindi essere utilizzato per popolare informazioni come il tipo di dispositivo o il proprietario del dispositivo.
Allo stesso modo, un account utente potrebbe fungere da chiave di ricerca per le rimanenti informazioni sull’utente, come il ruolo in azienda. Generalmente le autenticazioni sono orientate alle sessioni, mentre nel caso delle autorizzazioni è più prudente orientarle alle richieste.
Di conseguenza, è opportuno memorizzare nella cache l’esito di una richiesta di autenticazione, mentre è caldamente sconsigliato memorizzare un agent o il risultato di una richiesta di autorizzazione.
Questo poiché i dettagli nell’agent (che vengono utilizzati per prendere decisioni di autorizzazione) possono cambiare rapidamente in base a una serie di fattori, ed è auspicabile prendere decisioni di autorizzazione utilizzando appunto dei dati “vivi” (quanto più recenti possibile).
Proteggere i dati contenuti nell’agent
I dati contenuti in un agent di rete sono potenzialmente sensibili. Le informazioni di identificazione personale dell’utente (ad esempio nome e cognome, indirizzo, numero di telefono ecc.) sono generalmente presenti sull’agent per facilitare dettagliate decisioni di autorizzazione.
Tali dati devono essere trattati con cura per tutelare la Privacy degli utenti. La natura sensibile dei dati va però oltre gli utenti: i dettagli del dispositivo, ad esempio, possono diventare dati critici quando cadono nelle mani di un attacker.
Un utente malintenzionato con una conoscenza dettagliata del dispositivo di un altro utente-target, potrebbe utilizzare quei dati per avviare un attacco remoto mirato, o persino apprendere uno schema della posizione fisica di quell’utente al fine di rubargli il dispositivo.
Per proteggere adeguatamente i dettagli dell’agent, l’intero ciclo di vita degli agent dovrà essere contenuto in sistemi affidabili del Piano di controllo, che a loro volta siano fortemente protetti. Questi sistemi dovrebbero essere logicamente e fisicamente separati dai sistemi del Piano dati, avere confini chiari e cambiare di rado.
La maggior parte delle policy dovrà essere configurata nei sistemi del Piano di controllo, poiché i dati dell’agent sono fondamentali per elaborare le relative azioni di autorizzazione/negazione.
Tuttavia, capita spesso che il motore di autorizzazione nel Piano di controllo non sia nella posizione migliore, ad esempio, per applicare la policy incentrata sull’applicazione, nonostante la sua capacità di imporre l’autorizzazione su base richiesta.
Questo è particolarmente vero nei sistemi rivolti all’utente.
Di conseguenza, alcuni dettagli dell’agent dovranno essere esposti ai sistemi del Piano dati. Ecco un esempio. Un’applicazione amministrativa memorizza i dettagli su tutti i clienti di una determinata azienda.
Questo sistema espone tali dati ai dipendenti in base al loro ruolo all’interno dell’azienda. Una funzione di ricerca consente ai dipendenti di eseguire ricerche all’interno del sottoinsieme di dati a cui possono accedere.
L’applicazione deve implementare questa logica, e per farlo ha bisogno dell’accesso al ruolo dell’utente.
Per consentire alle applicazioni di implementare la propria logica di autorizzazione granulare, i dettagli dell’agent possono essere esposti alle applicazioni tramite un canale di comunicazione affidabile.
Quest’attività potrebbe essere semplice come inserire le intestazioni nelle richieste di rete che fluiscono attraverso un proxy inverso.
Il proxy, essendo un sistema del Piano di controllo ZTS, può visualizzare l’agent per imporre le proprie decisioni di autorizzazione, ed esporre un sottoinsieme di dati all’applicazione a valle per un’ulteriore autorizzazione.
Anche l’esposizione dei dettagli dell’agent all’applicazione downstream può essere utile per consentire la compatibilità con applicazioni preesistenti che dispongono di un sistema di autorizzazione avanzato.
Questo obiettivo di compatibilità evidenzia che i dettagli dell’agent devono essere esposti all’applicazione in un formato preferito dall’applicazione.
Per le applicazioni di terze parti, il formato dei dati dell’agent varia.
Per le applicazioni proprietarie, una struttura comune per i dati dell’agent semplificherà la gestione del sistema. Una rete ZTS comprende molti sistemi che si occupano dell’agent.
Per far spazio alla riutilizzabilità in questi sistemi, occorrerà standardizzare l’agente. Molte reti ZTS sono costituite da sistemi costruiti internamente, e mentre quei sistemi hanno sviluppato i propri standard per gli agent, uno standard pubblico sbloccherebbe il Piano di controllo, consentendo ai componenti di essere mescolati e abbinati.
È importante conoscere il formato di un agent
Conoscere il formato di un agent e dove trovare particolari dati al suo interno è fondamentale quando consideriamo come, da cosa e da chi verrà utilizzato.
Le “coordinate” di alcuni dati devono essere fisse e ben note per garantire la coerenza tra i sistemi del Piano di controllo. Una buona analogia è lo schema di un database relazionale, di cui le applicazioni che accedono ai dati devono essere a conoscenza per estrarre le giuste informazioni.
Questa compatibilità dei dati è estremamente importante quando si tratta di implementare e mantenere sistemi del Piano di controllo ZTS.
Molte reti ZTS, in particolare quelle più mature, costituiscono agent da più sistemi e origini dati. Ma senza uno schema di sorta non solo è difficile far emergere i dati in modo coerente, ma contribuirà anche negativamente alla quantità di sforzo e lavoro richiesto per introdurre nuovi sistemi del Piano di controllo o dati degli agent, qualcosa che è considerato critico per una rete ZTS in fase di maturazione.
Un altro fattore da rammentare, è che a volte i dati degli agent sono piuttosto scarsi a causa di problemi di pulizia dei dati riscontrabili nei sistemi di origine (come gli inventari dei dispositivi). Il risultato è un agent “best-effort”, in cui molti campi potrebbero non essere popolati per un motivo o per l’altro.
Quindi, sebbene sia ancora necessario che un particolare dato sia presente nell’agent, costituisce un utile esercizio di riflessione considerare dati alternativi in sua assenza.
Il processo di standardizzazione
Il lettore potrebbe chiedersi come sia possibile standardizzare un formato di dati così indissolubilmente legato all’organizzazione che lo utilizza. Dopotutto, è probabile che un agent contenga tipi di informazioni che si riferiscono alla logica aziendale o ad altre informazioni proprietarie/locali.
La standardizzazione è fattibile anche in un caso del genere? Fortunatamente, esistono già alcuni standard che definiscono formati di dati che si comportano in questo modo.
Uno dei migliori esempi è il Simple Network Management Protocol (SNMP) e la relativa Management Information Base (MIB). SNMP è un protocollo utilizzato di frequente per la gestione dei dispositivi di rete, che consente ai dispositivi di esporre i dati agli operatori e ai sistemi di management in modo standard ma flessibile.
Il componente MIB descrive il formato dei dati stessi, che è costituito da una raccolta di identificatori di oggetti (da OID, Object IDentifiers). Ciascun OID descrive un particolare dato ed è registrato presso l’ISO, un ente di standardizzazione globale.
Questo si presta bene a “coordinate” ampiamente utilizzate per determinati dati. Questo elenco registrato può essere esteso, e spesso porzioni di spazio OID vengono ritagliate per organizzazioni o produttori. In questo modo, un OID può essere paragonato a un indirizzo IP, dove un indirizzo IP identifica globalmente un sistema informatico, mentre un OID identifica globalmente un dato.
Sfortunatamente, non esiste un buon equivalente OID dello spazio di indirizzi IP privato, che sarebbe utile per dati ad hoc o specifici del sito.
Il miglior compromesso disponibile è registrarsi per un Private Enterprise Number con IANA, che restituirà un prefisso OID dedicato per uso privato.
Fortunatamente tale registrazione è gratuita, peraltro con poche domande poste.
Ci sono stati alcuni sforzi per creare un intervallo privato simile a quello trovato in IP, tuttavia, tali sforzi non hanno avuto successo.
Nonostante la mancanza di uno spazio OID veramente libero/privato per uso sperimentale o interno, SNMP rimane un’utile analogia quando si considera la standardizzazione di un agent: descrive il formato e la confezione di un insieme di dati, dati che possono essere facilmente trovati e identificati utilizzando i loro OID univoci, e come tali dati possano essere trasmessi e compresi da un sistema all’altro.
Conclusioni
Le reti e le architetture ZTS sono ancora poco utilizzate in Italia, e del resto basterebbe intervistare i referenti tecnici di qualcuna delle aziende finite sui giornali per i recenti fatti di cronaca relativi a incidenti informatici imputabili ad attacchi ransomware, per scoprire che le loro infrastrutture ICT non abbracciavano metodologie ZTS per proteggere le loro architetture di rete, che viceversa, invece, stanno prendendo sempre più piede nel mercato nord europeo, in UK e USA.
Ad oggi non esiste uno standard che descriva esattamente un agent, e ci vorrà probabilmente del tempo prima che venga ratificato dalla comunità scientifica.
Nel frattempo che gli agent assumano la forma di un BLOB JSON o di un formato binario personalizzato, suggerisco di garantire che i dati in esso contenuti siano flessibili e facilmente estensibili.
La tipizzazione allentata o l’assenza di tipizzazione dovrebbe essere preferita alla tipizzazione forte, poiché quest’ultima renderà più difficile l’introduzione di nuovi dati e sistemi. I modelli di progettazione collegabili possono aiutare a definire un futuro agent standardizzato.
Tuttavia, questo è tutt’altro che necessario e non dovrebbe essere perseguito se a lungo andare impedisse l’adozione dell’agent nella propria rete.
