Monitoraggio Shibboleth: dal log al triage SOC

L’Identity Provider di un’università ha registrato una sequenza di tentativi di accesso falliti. Il SIEM l’ha riconosciuta come possibile brute force. Il segnale è arrivato al SOC, ma non dice ancora che cosa sia realmente accaduto.

Potrebbe essere un utente che ha digitato più volte la password sbagliata. Potrebbe essere un attacco di password spraying distribuito su molti account. Oppure la traccia iniziale di una credenziale già compromessa.

Per distinguerli bisogna tornare indietro, seguire gli accessi e ricostruire la storia dell’identità.

Da dove si è collegata? Quel dispositivo era già comparso? Ha cambiato indirizzo IP durante la sessione? Quali servizi ha raggiunto? Il suo comportamento è coerente con quello osservato nei giorni precedenti?

Le risposte esistono, ma sono disperse tra log, query e strumenti differenti. È qui che comincia il lavoro di CyberHunter.

Dietro un accesso, un intero ecosistema

Shibboleth è una delle soluzioni di gestione delle identità federate più utilizzate nel mondo accademico.

Consente a studenti, docenti, ricercatori e personale di accedere con la propria identità istituzionale a portali amministrativi, piattaforme didattiche, biblioteche digitali, servizi cloud e risorse scientifiche.

In Italia è alla base di IDEM, la Federazione delle infrastrutture di autenticazione e autorizzazione della comunità dell’istruzione e della ricerca, gestita da GARR.

La stessa identità accompagna quindi l’utente attraverso ambienti e servizi diversi. Questa interoperabilità semplifica lo studio, la ricerca e la collaborazione. Quando compare un’anomalia, però, amplia anche la scena che il SOC deve osservare.

Un singolo alert non basta. Serve sapere che cosa è avvenuto prima, durante e dopo quell’accesso.

Il segnale è soltanto l’inizio

Un SIEM può rilevare una serie di autenticazioni fallite, un indirizzo IP sospetto o un comportamento compatibile con un attacco di brute force.

Nel password spraying, per esempio, l’attaccante non concentra molti tentativi su un solo account. Utilizza poche password comuni contro numerose identità, spesso distribuendo le prove nel tempo per non superare le soglie di rilevamento più immediate.

La detection individua il segnale. Per valutarlo servono però il comportamento storico dell’utente, il dispositivo utilizzato, la provenienza dell’accesso e ciò che è accaduto nel corso della sessione.

Senza un processo automatico di enrichment, l’analista deve raccogliere ogni elemento manualmente. Apre una query, consulta una fonte, confronta un indirizzo IP, controlla gli accessi precedenti e ricompone poco alla volta la sequenza degli eventi.

CyberHunter è stato progettato per svolgere proprio questa parte dell’indagine.

*Il password spraying è classificato da MITRE ATT&CK come sottotecnica T1110.003.

Due playbook per ricostruire la storia

Il team Digimetrica ha sviluppato due playbook dedicati agli accessi Shibboleth e al contesto universitario.

Non producono un altro alert da aggiungere alla coda. Cercano gli indizi necessari a comprendere quello già ricevuto, li mettono in relazione e li portano direttamente nel processo di triage.

Shibboleth Login History

Il primo playbook torna indietro di 30 giorni e ricostruisce il comportamento abituale dell’identità.

Osserva le modalità di accesso, i dispositivi, gli indirizzi IP e i servizi utilizzati. L’evento che ha generato l’alert viene così confrontato con una baseline reale.

Un dispositivo mai incontrato prima, una provenienza insolita o un metodo di autenticazione anomalo non rimangono nascosti tra migliaia di righe di log. Diventano elementi immediatamente riconoscibili.

Shibboleth Last Session Timeline

Il secondo playbook segue l’ultima sessione osservabile dell’utente.

Ricostruisce i Service Provider raggiunti, verifica la presenza o l’assenza del logout e individua eventuali cambi di indirizzo IP o dello User-Agent. Considera i metodi di autenticazione, la geolocalizzazione e la reputazione degli IP, insieme agli indicatori relativi a TOR, VPN, proxy e datacenter.

La sessione viene quindi classificata come coerente, da verificare o anomala. L’analista può vedere quali elementi hanno determinato la valutazione e concentrarsi subito su quelli che meritano un approfondimento.

Come spiega Andrea Comignani, SOC Analyst Digimetrica:

«Il contesto e la valutazione del comportamento delle utenze sono indispensabili per comprendere rapidamente un alert e prendere decisioni più consapevoli. Dare maggiore visibilità agli accessi registrati da Shibboleth e trasformare i dati grezzi in informazioni immediatamente utilizzabili è stata una sfida complessa, ma altrettanto stimolante e soddisfacente.»

Quando gli indizi diventano una storia

Shibboleth Login History mostra se l’identità si sta comportando diversamente dal solito. Shibboleth Last Session Timeline racconta che cosa è accaduto durante la sessione che ha generato l’alert.

CyberHunter riunisce le due prospettive e le rende disponibili all’AI di triage, che produce una sintesi motivata e comprensibile.

Quando il segnale arriva al SOC non è più isolato. È accompagnato dalla baseline dell’identità, dalla cronologia della sessione e dagli elementi che possono modificarne la valutazione.

La decisione rimane all’analista. CyberHunter si occupa del lavoro ripetitivo necessario per arrivarci.

Da 5–10 minuti a 30–60 secondi

In un progetto pilota universitario, CyberHunter ha analizzato circa 550.000 eventi Shibboleth alla settimana.

Per raccogliere manualmente le informazioni necessarie a qualificare un alert servivano mediamente dai 5 ai 10 minuti. Attraverso i due playbook, lo stesso contesto è stato ricostruito in circa 30–60 secondi.

Non significa soltanto chiudere prima un’indagine. Significa applicare lo stesso metodo a ogni alert, ridurre i passaggi ripetitivi e restituire agli analisti il tempo necessario per occuparsi degli eventi realmente anomali.

Una tecnologia che entra nel modo di lavorare del SOC

CyberHunter può affiancare un SOC già esistente, integrandosi nei suoi processi e automatizzando l’enrichment e il triage degli alert Shibboleth.

Quando invece serve un presidio più ampio, può diventare la componente tecnologica dell’Autonomous SOC Digimetrica, insieme al monitoraggio continuativo, alla gestione delle escalation e al supporto alla risposta del team Digimetrica.

Ma il caso Shibboleth racconta anche qualcosa di più.

La forza di CyberHunter non risiede in una raccolta di automazioni standard da applicare nello stesso modo a ogni organizzazione. Risiede nella possibilità di costruire playbook intorno alle fonti, all’ambiente e alle procedure effettivamente utilizzate dal SOC.

Ogni organizzazione lascia tracce diverse e segue un proprio modo di analizzarle. CyberHunter può imparare quel metodo, trasformarlo in un processo ripetibile e continuare a evolvere insieme all’infrastruttura, ai servizi e alle esigenze del team.

È così che un alert smette di essere soltanto un segnale.

Diventa una storia leggibile, completa degli elementi necessari per decidere come intervenire.

Fonti: Shibboleth Consortium, Federazione IDEM-GARR, MITRE ATT&CK.

Domande frequenti

Che cos’è Shibboleth?

Shibboleth è una soluzione open source per la gestione delle identità federate e del Single Sign-On. È ampiamente utilizzata da università ed enti di ricerca per permettere agli utenti di accedere a risorse differenti attraverso l’identità digitale istituzionale.

Che cosa significa monitorare Shibboleth?

Significa raccogliere e analizzare gli eventi prodotti dall’Identity Provider e dai processi di autenticazione, correlandoli con informazioni su utenti, sessioni, indirizzi IP, dispositivi, metodi di accesso e Service Provider.

Un SIEM può rilevare un attacco di password spraying?

Può individuare sequenze compatibili con il password spraying quando dispone dei log e dei casi d’uso adeguati. Per qualificare il segnale servono però informazioni sul comportamento storico dell’identità e sulla sessione che ha generato l’alert.

CyberHunter sostituisce il SOC?

CyberHunter può affiancare un SOC esistente automatizzando enrichment e triage oppure essere utilizzato come componente tecnologica dell’Autonomous SOC gestito da Digimetrica.

I playbook funzionano soltanto con le università?

I due playbook descritti nell’articolo sono stati progettati per Shibboleth e rispondono a esigenze particolarmente diffuse negli ambienti universitari e della ricerca. CyberHunter permette però di sviluppare playbook su misura anche per altre fonti, infrastrutture e processi operativi.