Sfide nel monitoraggio dei log Microsoft: approfondimenti per il tuo SOC

I registri delle attività completi e tempestivi sono strumenti potenti che consentono il monitoraggio della sicurezza e la risposta agli incidenti nel cloud. Tuttavia, durante lo studio dei registri Microsoft, i nostri ricercatori hanno notato molte carenze che complicano la comprensione delle azioni degli utenti e potrebbero persino consentire a un aggressore di passare inosservato. In questo post discuteremo questi problemi e il loro impatto sul lavoro del blue team. 

Perché studiamo i log Microsoft    

Prima di discutere i dettagli specifici dei provider, è opportuno sottolineare che i log hanno un significato diverso a seconda della cloud e in quelli on-premise .

Gli amministratori hanno alcune opzioni a disposizione nelle configurazioni on-premise: è possibile attingere al traffico di rete per monitorare l'attività o raccogliere i log sul perimetro della rete e sui singoli computer. Le soluzioni di registrazione e monitoraggio (hardware e software) sono sostituibili e, se un prodotto di un determinato fornitore non funziona bene, è possibile installarne un altro.

Nel cloud non hai queste opzioni: il provider controlla completamente i log disponibili. Se sono di alta qualità, ottimo! Ma se ci sono problemi, sei alla mercé della disponibilità del provider a risolverli. Puoi segnalarli al fornitore e sperare che vengano risolti oppure cercare di aggirarli, ove possibile.

Durante il monitoraggio delle attività cloud , ci sono diverse aspettative:

• Nessuna modifica non annunciata alla struttura o al contenuto del registro
• Registrazione tempestiva degli eventi
• Registrazioni complete e accurate (senza valori mancanti o errati)
• Documentazione completa degli eventi registrati
• Un modo semplice per correlare eventi e sessioni utente tra diversi log
• Una serie di indicatori di minaccia da utilizzare nell'analisi degli incidenti

Quando si analizza l'attività, i seguenti dati devono essere disponibili in modo coerente in tutte le fonti di log e per tutti i tipi di eventi:

• Nomi e dettagli delle operazioni
• Identità dell'utente e informazioni sulla sessione
• IP
• Geolocalizzazione
• Informazioni sul dispositivo
• Indicatori di minaccia e reputazione

In sostanza, si desidera poter stabilire chi ha fatto cosa e quando (e cos'altro ha fatto). Purtroppo, queste aspettative non sempre vengono soddisfatte nei log di Azure.

Come monitoriamo gli eventi nell'ambiente Microsoft

Azure dispone di una serie completa di prodotti per l'analisi e il monitoraggio degli eventi:  

• Microsoft Sentinel è un prodotto SIEM nativo che acquisisce i log da varie fonti. Dispone di una serie di rilevamenti integrati e consente di definirne di personalizzati. 
• Azure Log Analytics è una piattaforma di analisi dei log ideale per indagini ad hoc su eventi sospetti.    

Entrambi supportano Kusto, un potente linguaggio di query e analisi dei log. Inoltre, è possibile utilizzare soluzioni di terze parti per monitorare e interpretare i log.

Principali fonti di log Microsoft

L'infrastruttura di registrazione Microsoft è vasta e conta decine, se non centinaia, di origini di log. Sarebbe impossibile discuterle tutte, quindi concentriamoci sui log generati daAzure AD (ora Entra ID), la soluzione IAM di Azure, Microsoft 365, una suite per ufficio cloud e Azure Cloud.

Registri ID Entra

I registri Entra ID coprono: 

• Accessi: diversi registri che coprono l'attività di accesso di utenti interattivi e non interattivi, entità di servizio e identità gestite.
• Audit: un registro delle operazioni significative eseguite sulla directory
• Approvvigionamento - dati relativi alla fornitura di utenti da parte di servizi di terze parti

Questi log sono accessibili tramite Graph API e attualmente esistono in versione base (1.0) e Beta, con schemi diversi. 

Registri delle attività di Microsoft 365

I registri delle attività di Microsoft 365 vengono utilizzati tramite l'API Management Activity, che fornisce diversi registri per diversi tipi di eventi:

• Audit.AzureActiveDirectory - eventi dal servizio Entra ID (simili a quelli disponibili tramite Graph API), come assegnazioni e modifiche alla directory
• Audit.Exchange - Eventi di scambio
• Audit.SharePoint - Attività SharePoint
• Audit.Generale - la maggior parte delle altre azioni che non rientrano in nessuno degli altri registri
• DLP.Tutto - Eventi relativi alla prevenzione della perdita di dati

Registri Azure

Le risorse Azure e i registri delle attività vengono utilizzati tramite app aziendali e includono‍

• ‍AzureActivity - Attività di i eseguite su sottoscrizioni e risorse nel piano di controllo, quali creazione, eliminazione e modifica di risorse, assegnazione di ruoli e modifiche alle policy.
• Registri delle risorse - registri diagnostici generati dalle risorse Azure stesse, come l'accesso a Key Vault o i registri di flusso NSG

Problemi noti relativi ai log Microsoft

Ora che abbiamo esplorato l'importanza del monitoraggio dei log di Azure, approfondiamo alcune problematiche che abbiamo riscontrato in questi log. Esserne consapevoli può aiutartia creare query di analisi migliori e a perdere meno tempo a chiederti perché le cose si comportano in un certo modo.    

Le sfide specifiche che dovrebbero essere all'attenzione di ogni analista e architetto della sicurezza includono:

Sfide nella raccolta dei log

• Flusso di log
• Ritardi degli eventi
• Tassa di registrazione
• Eventi che non vengono mai registrati

Sfide relative alla correlazione dei log

• Incoerenze nell'ID
• Incoerenze IP
• Incoerenze nella geolocalizzazione
• Incoerenze nelle informazioni sul dispositivo

Sfide relative al contenuto dei log

• Schema fluido
• Eventi mancanti
• Documentazione carente
• Modifiche non annunciate
• Valori infranti

Esaminiamoli più nel dettaglio.

Sfide nella raccolta dei log

Flusso di log

In Azure si verificano occasionalmente interruzioni del servizio. Negli ultimi anni ne abbiamo riscontrate diverse. Sebbene una di esse sia durata diverse settimane e sia stata scoperta accidentalmente, Microsoft è generalmente brava a informare i clienti in tali situazioni.

Il problema è che durante un'interruzione, potresti non essere in grado di rilevare alcuna attività nell'ambiente. Se poi ti capita anche di perdere l'annuncio dell'interruzione, nulla ti indicherà che c'è un problema. È essenziale tenere sotto controllo lo stato di integrità del servizio in Azure ed eventualmente investire in una soluzione di monitoraggio che tenga traccia del flusso dei log.

Le interruzioni possono anche essere deliberate. La configurazione della registrazione è controllata in banda e la compromissione dell'account di un amministratore può portare l'autore dell'attacco a disabilitare la registrazione su larga scala (ad esempio tramite Set-AdminAuditLogConfig) o in modo più dettagliato e furtivo (ad esempio tramite Set-Mailbox -AuditEnabled).

Il monitoraggio del flusso dei log e delle modifiche alla configurazione è essenziale per mitigare tali problemi. Solo pochi utenti autorizzati devono poter modificare le impostazioni di registrazione. Sarebbe preferibile che Azure aggiungesse ulteriori controlli alla configurazione della registrazione, date le conseguenze negative significative derivanti dalla disabilitazione accidentale o deliberata dei log.

Ritardi degli eventi

Microsoft pubblica i tempi previsti per la disponibilità dei propri eventi di log. Il tempo di acquisizione delle API Graph è dichiarato essere inferiore a 3 minuti. In base alla nostra esperienza, possono essere necessari fino a 30 minuti prima che gli eventi in tali fonti vengano visualizzati.

La disponibilità tipica pubblicizzata per gli eventi Management ActivityAPI è compresa tra 60 e 90 minuti. In realtà, i ritardi che abbiamo osservato sono più significativi. Ecco alcuni valori massimi che abbiamo rilevato di recente: in alcuni casi si superano di gran lunga le 24 ore (la colonna max_delay contiene il tempo massimo osservato tra la creazione dell'evento e la sua disponibilità nel log):

Questi tempi di ritardo sono insostenibili. Alcuni aggressori agiscono con estrema rapidità. Se consideriamo il tempo necessario per l'elaborazione da parte degli strumenti di rilevamento, l'acquisizione da parte di SIEM esterni e la reazione da parte del personale SOC, è chiaro che, in molti casi, il blue team arriverà in ritardo, quasi per definizione. 

Più gli aggressori automatizzano i loro strumenti, più la situazione peggiorerà. Azure deve dare priorità alla rapida disponibilità dei log. Altrimenti, i difensori potranno solo reagire agli incidenti, senza poterli fermare. I ritardi degli eventi sono ancora più difficili da gestire quando i record dei log vengono inoltrati a un SIEM esterno. Le chiamate API dei log richiedono intervalli di tempo come parametri, quindi dovresti accettare la perdita di record o interrogare intervalli di tempo sovrapposti e rimuovere i record duplicati per non perdere gli eventi in ritardo.

Tassa di registrazione

Molti tipi di eventi di registrazione e dettagli sono disponibili solo con livelli a pagamento più elevati (ad esempio E5 e P2). Alcuni esempi includono eventiMailItemsAccessed, dettagli sui rischi nel registro degli accessi e altri. Ciò rappresenta un dilemma per molti clienti, poiché significa scegliere tra costi inferiori o una migliore visibilità delle attività nel proprio ambiente. 

Non è una scelta facile da fare e, secondo noi, le funzioni di sicurezza di base (come i registri) dovrebbero essere disponibili per tutti cloud . Come ha detto di recente il senatore statunitense Ron Wyden, "Far pagare le persone per funzioni premium necessarie per non essere hackerati è come vendere un'auto e poi far pagare un extra per le cinture di sicurezza e gli airbag". 

Questa mancanza di visibilità ha causato difficoltà in molti incidenti Vectra AI che abbiamo dovuto indagare. Una recente violazione pubblica da parte di APT Storm-0558, che Microsoft stessa ha dovuto affrontare, ha portato alla luce questo problema. A seguito di tale incidente, Microsoft ha concordato con la CISA di ampliare accesso alla registrazione a tutti i clienti questo autunno. 

Si spera che la situazione migliori presto. Nel frattempo, è necessario assicurarsi che la registrazione a cui si ha accesso tramite la propria licenza sia adeguata alle esigenze IR della propria organizzazione. In caso contrario, è il momento di effettuare un aggiornamento. Quando i dati essenziali non sono disponibili, alcuni di essi (ad esempio, la reputazione IP e le informazioni di geolocalizzazione) potrebbero essere acquisiti da fonti terze.

Alcuni eventi non vengono mai registrati

Azure è un "paradiso della ricognizione", con eventi di tipo "get" che corrispondono alla lettura di configurazioni e dati che, salvo rare eccezioni, non vengono registrati. A partire da ottobre 2023, è stato introdotto un nuovo log che registra le chiamate API Graph e copre alcune delle operazioni di ricognizione. Tuttavia, l'enumerazione tramite altre API rimane invisibile ai difensori.

Ciò significa che quando un aggressore ottiene l'accesso cloud , può enumerare la maggior parte delle informazioni (utenti, servizi, configurazione) senza essere visto dai difensori. Questo rappresenta un grande punto cieco: nei nostri test, la maggior parte degli strumenti di enumerazione M365/AAD open source non ha lasciato alcuna traccia nei log. 

Non è chiaro perché sia stata presa la decisione di non registrare tali eventi, anche se potrebbe essere per risparmiare spazio. Sfortunatamente, non esiste alcuna opzione per abilitare tale registrazione, anche se il cliente desidera visualizzare questo tipo di eventi. Ciò significa che rimarrai all'oscuro fino a quando gli aggressori non inizieranno ad apportare modifiche al tuo ambiente.

Sfide relative alla correlazione dei log

Supponendo che si riescano a ottenere i log, interpretarli non è un'impresa da poco. La correlazione tra i servizi è particolarmente compromessa. Microsoft Entra ID, M365, Exchange: ciascuno registra gli eventi in modo diverso. Il risultato è un'esperienza di indagine disordinata: i difensori passano il tempo a normalizzare manualmente i dati invece di seguire le tracce lasciate dagli aggressori.

Per gli aggressori che si muovono lateralmente dall'accesso iniziale entro 48 minuti, come dimostrano gli studi di settore, un ritardo nell'unione dei log è sufficiente per perdere le tracce.

Incoerenze nell'ID

Gli ID utente non sono sempre "stabili". A seconda del contesto e del tipo di operazione, lo stesso utente può comparire nei registri con diversi "nomi principali utente" (UPN). Ad esempio, il tuo utente potrebbe essere registrato come:

• john.smith@company.com
• John.Smith@company.com (notare la differenza nella maiuscola/minuscola)
• AN045789@company.com

M365 Exchange complica le cose aggiungendo nomi legacy come i seguenti (oltre ad altri):

"NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e" per conto di "NAMPR07A006.PROD.OUTLOOK.COM/Microsoft ExchangeHosted Organizations/ company.onmicrosoft.com/JohnSmith"

Nei casi di variabilità dei nomi, diventa difficile collegare eventi diversi allo stesso utente. Sebbene il primo impulso possa essere quello di correlare gli eventi tramite l'UPN, farlo tramite l'ID interno univoco può essere una strategia più solida (ma comunque non infallibile).  

Le difficoltà continuano:  

• Nomi diversi in log diversi possono avere nomi di campo sovrapposti con significati diversi. Ad esempio, user_id significherà un GUID utente in un log e un UPN in un altro.
• Gli ID utente possono avere valori che rappresentano il nome e il cognome dell'utente, i nomi delle applicazioni, i GUID delle applicazioni e altri nomi insoliti e ID univoci.
• Gli ID utente possono essere vuoti o contenere nomi inutili come "Non disponibile", "Sconosciuto", "Nessun UPN":

In qualità di difensore, devi essere pronto a vedere queste informazioni (poco utili) nei campi dell'identità dell'utente e creare una funzionalità di query di conseguenza.

Incoerenze IP

Un indirizzo IP valido è un requisito fondamentale per ogni registrazione di log. Sebbene nella maggior parte dei casi le voci di log contengano indirizzi IPv4 e IPv6 validi, talvolta si riscontrano indirizzi IP difficili da comprendere e utilizzare nell'analisi:

• IP con numeri di porta (sia v4 che v6)
• IP vuoti
• IP locali e privati: 127.0.0.1, 192.168.*, 10.*
• IP tutti zero: 0.0.0.0
• Maschere IP invece di IP: 255.255.255.255
• IP corrispondenti all'infrastruttura Azure, non all'utente che esegue l'operazione

Gli indirizzi IP non possono essere correlati ai registri di accesso per alcune operazioni, il che complica l'analisi degli incidenti. Gli indicatori di rischio e reputazione degli indirizzi IP possono essere occasionalmente disponibili, ma sono soggetti alla "tassa di registrazione".

In qualità di difensore, dovresti prevedere questi casi speciali quando scrivi query di ricerca e avvisi e tenerne conto nella tua logica.

Incoerenze nella geolocalizzazione

Attualmente, Microsoft fornisce solo la geolocalizzazione per i registri di accesso. Ciò sarebbe stato utile per altre fonti di log, poiché non è sempre possibile collegare l'attività a registri di accesso specifici.

Questa funzione non è perfetta. A volte ci sono dei problemi:

• Lo stesso IP risolve più posizioni (probabilmente correlate a dispositivi mobili).
• I record sonogeolocalizzati in modo errato in massa.
• Mancano le informazioni geografiche:

La geolocalizzazione può essere facilmente ingannata da TOR, VPN, proxy e IP cloud , e dovrebbe essere presa con le pinze.

Incoerenze nelle informazioni sul dispositivo

I dettagli del dispositivo sono complessi da determinare per Microsoft (a meno che non si tratti di un dispositivo registrato). Le informazioni sulla piattaforma e sul browser vengono normalmente analizzate dall'User Agent (UA).

Purtroppo, anche qui ci sono delle incongruenze: 

• Alcuni log analizzano l'UA e lo forniscono in modo frammentario, mentre altri forniscono l'intera stringa UA (che devi interpretare).
• Le informazioni sul dispositivo non sono disponibili in tutti i registri.
• I valori analizzati non sono sempre coerenti (ad esempio "Windows" contro "Windows 10").

Gli aggressori possono facilmente falsificare l'User Agent, ma questo rimane comunque utile per le indagini, poiché non tutti sono abbastanza disciplinati da modificarlo in modo discreto. 

Sfide relative al contenuto dei log

Anche se si riescono a raccogliere e correlare i log, il loro contenuto potrebbe comunque creare problemi.

Schema fluido

Lo schema in alcuni dei log (ad esempio Management Activity API) è "fluido". Ciò significa che un parametro univoco in una nuova operazione verrà aggiunto al log come nuova colonna.

Questo rende difficile la gestione, anche per Log Analytics. (Abbiamo osservato che vengono visualizzati errori relativi al "limite massimo di 500 colonne raggiunto"). Se desideri utilizzare gli eventi in un SIEM esterno, potresti dover selezionare le colonne da utilizzare ed è impossibile prevedere quelle nuove che Azure aggiungerà.

Un metodo migliore sarebbe stato uno schema statico in tutti i log, con campi strutturati (ad esempio in JSON) aggiunti per gestire la variabilità.

Eventi mancanti

Alcuni tipi di eventi possono essere presenti in più di un registro. Ad esempio, i record di accesso sono disponibili sia nell'API Graph che nell'API Management Activity. Confrontando i record relativi allo stesso evento in entrambe le fonti, è possibile individuare alcune differenze occasionali. 

Consideriamo i seguenti esempi tratti da una recente indagine su un incidente. Sebbene corrispondano tutti alle stesse azioni compiute da un aggressore, i registri non corrispondono esattamente:

API Graph (beta - in Azure Portal):

API Graph (v1.0): 

AuditAzureActiveDirectory nell'API Attività di gestione:

Questo tipo di incongruenza è difficile da riprodurre e spiegare, ma è necessario esserne consapevoli quando si esegue l'analisi dei log. I record potrebbero andare persi e potrebbe essere necessario analizzare più log per ottenere un quadro più completo di ciò che è accaduto.

Documentazione carente

Sebbene le API di Azure siano documentate in modo abbastanza esauriente, la documentazione relativa agli eventi di log è carente. Per molti eventi, l'unica cosa documentata è il nome dell'operazione, ma i singoli campi e il loro significato sono spesso un mistero. È necessario cercare nei blog e nei forum di discussione per cercare di interpretare ciò che sta accadendo.

Oltre alla mancanza di chiarezza riguardo allo scopo di un campo, talvolta anche i singoli valori dei dati sono documentati in modo inadeguato. Abbiamo riscontrato tipi di autenticazione specifici, codici di stato, sottotipi di operazioni e altri dati privi di descrizione. Anche un'approfondita ricerca non ha portato chiarezza su alcuni di questi valori.

Poiché non comprendiamo alcuni campi e valori, non siamo in grado di monitorarli e interpretarli durante l'analisi e la risposta agli incidenti.

Modifiche non annunciate

Con l'evoluzione cloud (come spesso accade), nei log compaiono nuovi tipi di eventi senza preavviso. Ad esempio, è stato aggiunto un nuovo codice di errore per gli errori di accesso senza password che abbiamo recentemente documentato. Il team di ricerca Vectra AI ha dovuto dedicare del tempo a indagare prima di poter capire cosa lo avesse causato e, fino ad allora, le nostre query di monitoraggio non erano in grado di rilevarlo.  

Ciò che è più preoccupante è che anche gli eventi esistenti potrebbero scomparire o cambiare formato. Alcuni esempi recenti includono:

• Evento MailboxLogin che stavamo monitorando e che è scomparso silenziosamente dai registri di Exchange.
• Errori di accesso per nomi utente inesistenti che abbiamo monitorato per individuare le prime fasi dell'attività di ricognizione e che non sono più stati registrati nei log di accesso.

Quando si utilizzano query di monitoraggio e analisi alla ricerca di eventi specifici, queste modifiche le renderanno inutilizzabili senza alcun preavviso. Si tratta del peggior tipo di guasto possibile: quando non si è nemmeno consapevoli dell'esistenza di un problema. Potrebbe essere necessario investire in logica per monitorare l'integrità dei log e tenere sotto stretto controllo i cambiamenti nei contenuti dei log e nella documentazione. Purtroppo, la maggior parte dei difensori è troppo occupata per dedicare tempo a questo aspetto.

Valori infranti

Alcuni campi di log hanno strutture complesse (ad esempio JSON) e le query di ricerca e monitoraggio devono analizzarli per fare riferimento a specifici sottocampi.

Occasionalmente, questi valori vengono troncati a causa dei limiti di dimensione, causando strutture danneggiate. Ad esempio, si consideri il seguente valore registrato per l'operazione Set-ConditionalAccessPolicy. Una parte di esso è troncata e sostituita con tre punti ("..."), il che confonderà il parser JSON: 

Le query di monitoraggio che incontrano tali record falliranno, causando punti ciechi.

In questi casi, affidarsi alla corretta analisi dei valori potrebbe non essere la strategia migliore, mentre le ricerche di sottostringhe potrebbero funzionare meglio.

Cosa devono ricordare i membri del red team

Finora abbiamo parlato solo delle difficoltà che questi problemi comportano per il vostro team. Ma è importante ricordare che ogni perdita della difesa è un vantaggio per l'attacco. Black hat, APT e red team competenti possono sfruttare le peculiarità della registrazione di Azure per nascondere le loro azioni e complicare il lavoro del blue team.

Ecco alcune delle tecniche che gli aggressori potrebbero utilizzare:

• Utilizzo di operazioni insolite che sono meno documentate o comprese
• Esecuzione di azioni che inseriscono valori errati o non documentati nei registri per complicare l'analisi
• Connessione da posizioni per le quali le informazioni di geolocalizzazione IPor sono registrate in modo errato
• Operazioni di temporizzazione per sfruttare i ritardi di acquisizione o complicare l'individuazione di eventi correlati

Naturalmente, sarebbero necessarie ulteriori ricerche per trasformare qualsiasi carenza di registrazione in una solida tecnica di evasione.

Cosa possono fare i difensori?

I team addetti alla sicurezza cloud devono approcciarsi ai log Microsoft con scetticismo e strategia. Ecco tre imperativi:

1. Non fidarti delle apparenze: verifica regolarmente il flusso e la completezza dei log. Controlla che non ci siano lacune. Imposta avvisi per quando la registrazione dei log è disabilitata o interrotta.
2. Scrivi query più intelligenti e affidati a fornitori affidabili per ricevere assistenza: comprendi come vengono registrati i dati relativi all'identità, all'IP e alle attività nei vari servizi. Tieni conto delle incongruenze. Quando possibile, preferisci i GUID ai nomi visualizzati.
3. Spingere per il cambiamento: i clienti Microsoft meritano registri accurati, tempestivi e ben documentati. Se i difensori hanno difficoltà a colmare queste lacune, gli aggressori ne approfitteranno. I risultati in materia di sicurezza migliorano quando il segnale migliora.

Noi di Vectra AI abbiamo investito molto per superare queste sfide: normalizzazione dei log, deduplicazione delle voci e rilevamento del comportamento degli aggressori anche quando i log sono danneggiati. Tuttavia, per elevare gli standard di riferimento del settore, abbiamo anche bisogno di standard di telemetria migliori da parte cloud .

Cosa occorre per migliorare la qualità dei registri?

Non siamo gli unici a criticare la qualità dei log di Azure (problemi simili sono stati sollevati in precedenza da CrowdStrike ed EricWoodruff) e possiamo solo ipotizzare il motivo per cui ce ne siano così tanti.

I log di solito passano in secondo piano rispetto ad altre funzionalità nello sviluppo di software. Le funzionalità dei servizi di back-end possono essere sacrificate quando il team di sviluppo è sotto pressione per rilasciare le funzionalità principali del prodotto.

In enormi ecosistemi di prodotti come Azure, vengono riuniti più prodotti indipendenti (e talvolta legacy). Far sì che tutti forniscano un buon segnale in un'architettura di registrazione comune può essere difficile e questa funzionalità non è esattamente "rivolta al cliente", quindi i reclami al riguardo potrebbero non essere considerati prioritari.

Qualunque sia la ragione, l'assenza di alternative in un cloud rende i problemi relativi ai log molto più gravi rispetto a quanto sarebbero stati in una configurazione tradizionale on-premise. Oltre ad essere consapevoli delle carenze dei log e a cercare di aggirarne alcune, i difensori non hanno altre opzioni. Microsoft possiede questa funzionalità e spetta a loro migliorarla.

Riteniamo che il team Azure possa (e debba) apportare una serie di modifiche non invasive:

• Tutti gli eventi, i campi e i valori delle enumerazioni devono essere documentati in modo completo per eliminare ogni margine di incertezza dall'analisi dei log.
• La struttura e i contenuti dei log devono essere trattati come un'API: qualsiasi modifica che possa compromettere la funzionalità di interrogazione dei log deve essere introdotta in modo controllato e ai clienti deve essere concesso il tempo necessario per adeguarsi ai cambiamenti.
• Tutte le aggiunte e (soprattutto) le rimozioni delle operazioni registrate devono essere chiaramente comunicate.
• I record devono essere consegnati in modo molto più tempestivo rispetto ad oggi, in pochi secondi anziché in minuti o ore, e gli eventi non devono subire ritardi o arrivare in ordine sparso.
• Tutti i valori registrati devono essere utili, corretti e non ambigui.
• I log devono contenere informazioni dettagliate utili per la risposta agli incidenti (ad esempio, la reputazione IP).

Idealmente, sarebbe utile rifattorizzare l'architettura di registrazione per renderla più snella (simile a quella disponibile in AWS e Okta).

Il tuo lavoro di difensore è difficile. Cercare di individuare e risolvere rapidamente gli attacchi è un'impresa ardua, che diventa ancora più laboriosa quando devi tenere a mente i problemi e aggirarli.

La promessa di una maggiore sicurezza nel cloud non cloud un sogno irrealizzabile, e uno dei modi per contribuire a realizzarla è fornire una registrazione di alta qualità. Sebbene i fornitori abbiano il potere di farlo, potrebbero non avere l'incentivo per renderlo un obiettivo prioritario. È qui che entriamo in gioco noi. Più la comunità di ricerca sulla sicurezza denuncia il problema e più pressione esercitiamo, più ci avviciniamo al miglioramento della qualità dei log.

Vuoi partecipare alla conversazione? Interagisci direttamente con il team di ricerca Vectra AI , su questo post del blog e su altri argomenti, suReddit.