Una delle regole più frustranti della cybersecurity è che, indipendentemente dagli investimenti che le organizzazioni fanno nella loro tecnologia o da quanto sia sofisticata la loro architettura, di solito è più facile violare una persona o un processo che non una tecnologia. L'autenticazione a più fattori (MFA) è così efficace che gli aggressori non si preoccupano di attaccarla direttamente: invece, trovano il modo di eludere l'AMF e puntare ad altri livelli aziendali o agli utenti per prendere piede in un ambiente.
Per eludere l'MFA, i criminali informatici utilizzano e-mail, testi e notifiche truffaldine che si suppone provengano da "un account di posta elettronica dell'help desk" per indirizzare gli utenti in bombardamento immediato e Stanchezza da AMF attacchi. Ma cosa succede quando gli hacker evolvono le loro tattiche e prendono di mira l'help desk stesso?
Non è solo una questione teorica. Secondo quanto riferito, Caesars Entertainment ha pagato $15 milioni dopo che un gruppo di criminali informatici "è riuscito a infiltrarsi e a interrompere i suoi sistemi". L'organizzazione segnalato che la violazione è iniziata in parte con "un attacco di social engineering a un fornitore di supporto IT in outsourcing". L'anno scorso, LAPSUS$ ha chiamato l'help desk di un'organizzazione e ha cercato di convincere il personale di supporto a reimpostare le credenziali di un account privilegiato.
L'attacco al Caesars Entertainment dimostra perché le organizzazioni devono rafforzare i loro help desk. Ma le parole sono facili: lo sviluppo di operazioni orientate alla sicurezza richiede il supporto della leadership, investimenti tecnici e dei dipendenti, formazione e altro ancora. È importante notare che, sebbene alcuni degli attacchi più recenti abbiano preso di mira specificamente gli help desk, non è che questi ultimi siano particolarmente suscettibili di attacchi, insicuri o ad alto rischio. Al contrario: le organizzazioni devono adottare principi di sicurezza prioritari per ogni processo aziendale. Sono tutti a rischio.
Detto questo, Ragno sparso e ALPHV/BlackCat hanno messo sotto i riflettori gli help desk di recente. Passiamo quindi in rassegna alcune delle best practice che i team di sicurezza e gli help desk possono adottare e le domande che dovrebbero porsi per sviluppare un help desk Zero-Trust.
Gli help desk (o service desk) sono una parte standard del panorama IT della maggior parte delle aziende. Svolgono diverse funzioni, ma spesso sono il primo punto di contatto per chi non riesce ad accedere al proprio computer o ha problemi ad accedere alle risorse. Per risolvere questi problemi, l'help desk può essere in grado di eseguire alcune azioni ad alto rischio, tra cui:
- Ripristino delle password
- Rimozione dell'MFA per gli utenti bloccati
- Creare un nuovo account
Questo è solo l'inizio: il personale dell'help desk potrebbe essere il punto di accesso per eseguire azioni ancora più rischiose, come la creazione di account amministrativi o la rimozione temporanea dell'MFA per risolvere un problema a livello di sistema. Anche se il personale dell'help desk non può intraprendere direttamente queste azioni, potrebbe essere in grado di aprire ticket per altri gruppi che possono farlo.
Sono queste azioni che possono rendere l'help desk un bersaglio così attraente per un aggressore: un help desk può sospendere o aggirare i criteri di sicurezza. Inoltre, poiché le organizzazioni vogliono che i loro utenti e clienti rimangano connessi, produttivi e felici, sarà facile per gli attori delle minacce trovare le informazioni di contatto dell'help desk.
La buona notizia è che, sebbene l'help desk possa rappresentare un rischio significativo, i team di sicurezza possono ridurre al minimo questi pericoli dando priorità all'identità, alla documentazione dei processi, all'automazione e allo sviluppo della difesa in profondità.
Iniziate a conoscere il vostro help desk: chi vi lavora? Cosa fanno di solito? Che cosa potrebbe che fanno? A cosa hanno accesso e perché ne hanno bisogno?
Ogni organizzazione dovrebbe chiedersi quanto accesso ha l'help desk al proprio ambiente. I team di sicurezza dovranno esaminare regolarmente la risposta rispetto al concetto di minimo privilegio. Per avvicinarsi alla fiducia zero, l'help desk dovrebbe avere accesso solo alle funzioni necessarie per svolgere il proprio lavoro quando ne ha bisogno. L'accesso amministrativo ad ampio raggio per il personale dell'help desk è da escludere.
Un buon arbitro di questo è il catalogo dei servizi dell'help desk: il personale di supporto deve avere l'accesso necessario per eseguire quei servizi e solo quelli. Il team di sicurezza deve verificare se il personale dell'help desk dispone di più autorizzazioni di quelle necessarie, in particolare per le azioni che potrebbero modificare le impostazioni di sicurezza dell'identità di un utente; in tal caso, deve garantire controlli adeguati su tali autorizzazioni.
Una volta che vi siete fatti un'idea di cosa fa di solito l'help desk e di cosa potrebbe fare, chiedete di vedere i suoi runbook e la documentazione dei processi. Se non ne hanno, è il momento di scriverne alcuni e di verificarne le buone pratiche di sicurezza, compresa la verifica dell'identità.
Già che ci siete, i team di sicurezza dovrebbero anche sottolineare che le azioni di identità a più alto rischio dovrebbero seguire i processi standard di gestione delle modifiche: azioni come l'aggiunta di una nuova federazione o di un nuovo tenant alla vostra directory dovrebbero seguire processi più severi. Se qualcuno cerca di iniziare queste azioni ad alto rischio al di fuori di un normale processo, il sistema di sicurezza deve rilevare il tentativo, avvisare la sicurezza e bloccarlo.
E non fermatevi al team dell'help desk. Sebbene l'help desk possa avere un ampio margine di manovra per assistere gli utenti, a volte è necessario coinvolgere un altro gruppo per completare compiti complessi o rischiosi. Se c'è più di un gruppo che lavora insieme, assicuratevi che ogni team sappia quali compiti richiedono più di una funzione, chi deve verificare la richiesta e come documentarla.
I criminali informatici sfrutteranno tutte le ipotesi che si fanno su quale team sia responsabile di un'azione. Se un VIP dice di aver assunto un nuovo manager che ha bisogno di richieste di amministrazione immediate, come fa l'help desk a ricevere la richiesta, a verificarla e a coordinarsi con gli altri team? Dovete verificare tutte le ipotesi per assicurarvi che la richiesta provenga dall'interno della vostra organizzazione e che non stiate aiutando i cattivi.
I dipendenti dell'help desk devono sentirsi dire dalla leadership e dai team di sicurezza che devono seguire i processi stabiliti, richiedere la documentazione e verificare gli utenti.soprattutto per richieste eccezionali, per mantenere una pratica sicura.
L'help desk deve sapere che i team di sicurezza e di leadership gli coprono le spalle. Non si tratta solo di un cambiamento tecnico o operativo, ma di un valore culturale che la leadership deve coltivare in tutta l'organizzazione. Perché è altrettanto probabile che le richieste ad alto rischio provengano da leader interni, VIP esterni o attori delle minacce che potrebbero contattare il team di assistenza clienti con una richiesta "urgente" per risolvere un problema o ottenere un accesso.
In queste situazioni, un dipendente dell'help desk non può sempre dire "no". Invece, coltivate la tecnologia, i processi e la cultura che permettano loro di dire: "Sì, ed ecco cosa devi fare per riuscirci". Avere questi passaggi programmati in anticipo e sapere che la leadership e il team di sicurezza saranno al fianco dell'help desk quando saranno necessari ulteriori passaggi, potrebbe fare la differenza nel prevenire una violazione.
Non si tratta però solo di un processo dall'alto verso il basso: le organizzazioni dovrebbero usare automazione quando ha senso limitare l'esposizione ai processi manuali o alla pressione dei VIP. L'automazione non sarà una pallottola d'argento: il vostro help desk potrebbe ancora dover rispondere alle chiamate che richiedono eccezioni e rimandare i chiamanti all'automazione o avere una procedura di escalation che richiede approvazioni fidate.
Supponiamo che abbiate seguito tutti i passi precedenti: avete incontrato i vostri help desk, avete capito cosa possono fare, avete catalogato le azioni a più alto rischio a cui dare priorità, avete creato la documentazione e il vostro team di leadership vi spiega abitualmente che la vostra organizzazione sarà sempre dalla parte della sicurezza, anche se ciò significa creare disagi a un utente.
La domanda successiva a cui dovete rispondere è: come il vostro help desk o il team di assistenza clienti verificherà l'identità? L'autenticazione dell'identità dell'utente è assolutamente fondamentale, perché per quanto ben progettata o documentata possa essere la vostra sicurezza di assistenza, è inefficace se qualcuno del vostro team lavora per soddisfare una richiesta a cui un utente non ha diritto.
Recentemente, la verifica visiva è stata nominata come uno dei modi per affrontare i problemi di phishing. Le organizzazioni possono esaminare NIST 800.63A per vedere se le capacità necessarie per la verifica di forza "superiore" hanno senso per la loro situazione. Visti i requisiti tecnici necessari per arrivare a una verifica visiva indipendente e la formazione di cui l'help desk ha bisogno per implementare questo meccanismo, questa operazione va fatta con cautela. La verifica visiva potrebbe essere ancora suscettibile di deepfakes, che stanno diventando più facili da realizzare, se si tratta di un help desk remoto che non conosce la persona che effettua la richiesta. A causa di queste sfide, sono scettico sul fatto che la verifica visiva possa essere implementata efficacemente nella maggior parte delle situazioni.
Le organizzazioni possono invece utilizzare un approccio tradizionale di difesa in profondità e l'MFA per verificare che una persona sia chi dice di essere. Un metodo di richiesta e verifica ben formato può iniziare con un singolo vettore di fiducia iniziale, come un'e-mail definita o il login a un portale di supporto, ma dovrebbe anche integrare fattori aggiuntivi come un contatto fuori banda che utilizza un secondo sistema affidabile. I metodi per utilizzare un contatto fuori banda potrebbero includere:
- Approvazione del manager: verificare sistematicamente che il manager approvi la richiesta di accesso nel sistema di ticketing.
- Chiamare il responsabile (per i dipendenti) o il contatto in archivio (per i clienti) per verificare se la richiesta è valida. In genere, un manager dispone di un metodo fuori banda per contattare i propri dipendenti.
- Fate una teleconferenza con il dipendente del service desk e l'utente che ha fatto la richiesta. Poi chiedete a una terza persona di unirsi alla chiamata, come un manager o un membro del team, per verificare visivamente l'utente e la sua richiesta.
- Per accelerare l'approvazione, si può anche sostituire un collega o un assistente estratto dall'elenco aziendale per verificare la richiesta.
Qualsiasi sistema di verifica può essere danneggiato, ma combinare alcuni elementi non correlati per convalidare l'identità prima di servire una richiesta ad alto rischio può aiutare a garantire che l'help desk sia resistente alla maggior parte dei tentativi di phishing. Negli esempi riportati, considerate quanto gli elementi siano vicini o lontani nel panorama tecnico: ad esempio, se siete un negozio Microsoft che utilizza Active Directory, M365 per la posta elettronica e Teams, potreste non voler combinare questi elementi che sono interconnessi se volete l'approccio MFA più forte.
Un altro modo per proteggere l'help desk e le altre attività aziendali da attacchi di social engineering come questo è la verifica dell'identità. Presto avremo maggiori informazioni sull'identity proofing: tenete d'occhio questo spazio.
