Un addetto del reparto IT riceve una telefonata da un manager che si presenta come un membro del board. Conosce il suo nome, il ruolo e il contesto lavorativo, e chiede di approvare una richiesta di autenticazione per risolvere un problema urgente di accesso a un sistema aziendale. In una situazione di questo tipo, un dipendente saprebbe distinguere un collega da un attaccante? Come anche recenti, ed eclatanti, casi in Italia hanno dimostrato, la risposta \u00e8 no.<\/p>\n
Il social engineering si basa infatti da tempo sulla manipolazione delle persone pi\u00f9 che sullo sfruttamento diretto della tecnologia, ma quello che gioca sempre di pi\u00f9 a favore dei cyber criminali \u00e8 la capacit\u00e0 di rendere questi attacchi sempre pi\u00f9 convincenti. Da una parte c\u2019\u00e8 l\u2019AI che consente loro di creare messaggi e impersonificazioni molto credibili, mentre dall\u2019altra, le informazioni disponibili online o ottenute attraverso dati compromessi forniscono il contesto necessario per rendere una richiesta ancora pi\u00f9 legittima.<\/strong><\/p>\n In questo contesto, la sfida per le organizzazioni \u00e8 intervenire su due fronti: da un lato, fornire agli utenti strumenti e procedure per identificare, verificare e segnalare le interazioni sospette; dall’altro, introdurre controlli sull’identit\u00e0 e sugli accessi che limitino le conseguenze di un’eventuale manipolazione umana riuscita, impedendo che si traduca in un accesso non autorizzato ai sistemi aziendali o processi critici.<\/p>\n Per le organizzazioni, la risposta deve quindi agire su due fronti: da un lato, fornire agli utenti strumenti e procedure per identificare, verificare e segnalare le interazioni sospette; dall’altro, progettare autenticazione, recupero degli account e autorizzazione in modo che una manipolazione riuscita non dia automaticamente accesso ai sistemi o ai processi critici.<\/p>\n Il primo aspetto da tenere presente \u00e8 che la formazione sulla sicurezza deve concentrarsi sui comportamenti e sulle richieste, non soltanto sulla forma delle comunicazioni. Un messaggio con il tono usuale, una voce familiare o una richiesta coerente con determinate attivit\u00e0 aziendali non costituiscono prove sufficienti dell\u2019identit\u00e0 dell’interlocutore. Allo stesso modo, conoscere il nome del dipendente a cui ci si rivolge, alcuni suoi dati personali o alcuni dettagli organizzativi non significa essere autorizzati a impartire istruzioni.<\/p>\n In questa prospettiva, gli utenti devono imparare a riconoscere soprattutto le situazioni che richiedono una verifica aggiuntiva. In particolare, dovrebbero essere considerati segnali di allarme:<\/p>\n \u00b7 richieste inattese accompagnate da un senso di urgenza<\/strong><\/p>\n \u00b7 pressioni a derogare procedure<\/strong><\/p>\n \u00b7 domande di credenziali o codici di autenticazione<\/strong><\/p>\n \u00b7 richieste di reimpostazione di un account<\/strong><\/p>\n \u00b7 notifiche MFA che non corrispondono a un’operazione avviata dall’utente<\/strong><\/p>\n \u00b7 resistenza a una verifica \u201cesterna\u201d dell\u2019identit\u00e0 di chi pone la richiesta<\/strong><\/p>\n Questi elementi non dimostrano da soli che sia in corso un attacco, ma indicano che la richiesta non dovrebbe essere approvata senza ulteriori verifiche.<\/p>\n Questi criteri devono, nello stesso tempo, essere tradotti in indicazioni operative semplici. Di fronte a una richiesta sospetta, la regola pu\u00f2 essere riassunta in tre semplici azioni: \u201cstop, verify, report\u201d<\/strong> <\/em>ovvero occorre interrompere l’interazione prima di fornire informazioni o autorizzare operazioni, verificare l’identit\u00e0 attraverso un canale ufficiale gi\u00e0 conosciuto e segnalare il tentativo al team di sicurezza<\/a> o al proprio referente.<\/p>\n La formazione deve essere periodica e accompagnata da simulazioni realistiche, procedure di segnalazione accessibili e indicazioni chiare su come comportarsi, ma \u00e8 ancora pi\u00f9 importante anche che i dipendenti sappiano che segnalare un dubbio \u00e8 preferibile a prendere una decisione sotto pressione e quindi che l’organizzazione metta le persone nelle condizioni di fermarsi e controllare senza essere criticate per aver ostacolato inutilmente il lavoro.<\/p>\n In un contesto in cui la pressione e l’urgenza fanno parte della tecnica di attacco, la possibilit\u00e0 di interrompere il processo \u00e8 a sua volta una pre-condizione per il controllo di sicurezza.<\/p>\n La consapevolezza degli utenti \u00e8 necessaria, ma non pu\u00f2 costituire l’unica linea di difesa. Un attacco pu\u00f2 andare a buon fine anche se un dipendente \u00e8 formato e sospettoso. Per questo, i processi di autenticazione, recupero degli account e concessione degli accessi devono essere progettati in modo da ridurre la dipendenza dal giudizio umano e rendere pi\u00f9 difficile sfruttare un’identit\u00e0 legittima per entrare nei sistemi.<\/p>\n Un primo ambito da \u201cmettere in sicurezza\u201d \u00e8 quello della verifica delle identit\u00e0 in carico ai service desk, dal momento che le procedure di reimpostazione delle password e di recupero degli account possono diventare un punto di accesso alternativo quando prevedono verifiche deboli o affidate alla valutazione del singolo operatore. In questo contesto, l’attaccante, sfruttando semplicemente informazioni facilmente reperibili o ottenibili attraverso tecniche di social engineering, pu\u00f2 limitarsi a convincere qualcuno a superare il meccanismo di autenticazione.<\/p>\n Le organizzazioni dovrebbero quindi applicare verifiche dell’identit\u00e0 solide e coerenti prima di autorizzare operazioni sensibili, in particolare reset delle credenziali, sblocco degli account e modifica dei metodi di autenticazione. Dove possibile, i processi di recupero devono essere automatizzati attraverso soluzioni self-service basate su fattori di autenticazione robusti e regole definite dall’organizzazione. L’automazione riduce la variabilit\u00e0 delle verifiche manuali, purch\u00e9 non riproduca le stesse debolezze in un nuovo flusso.<\/p>\n Un secondo livello riguarda l’autenticazione. L’adozione di metodi resistenti al phishing e di soluzioni passwordless pu\u00f2 ridurre la dipendenza da credenziali che possono essere rubate o condivise. \u00c8 inoltre importante che le richieste MFA siano legate a un’operazione effettivamente avviata dall’utente e che le notifiche inattese non diventino un mezzo per ottenere approvazioni sotto pressione. Nessun singolo controllo elimina ogni rischio e l\u2019efficacia di un attacco dipende anche da come sono gestite le eccezioni, il recupero degli account e gli altri percorsi di accesso.<\/p>\n Autenticazione e autorizzazione devono inoltre essere considerate separatamente. La prima serve a verificare che un soggetto controlli l’autenticatore associato a un’identit\u00e0; la seconda determina quali risorse e operazioni quell’identit\u00e0 pu\u00f2 utilizzare, e questo vale anche quando l’autenticazione \u00e8 stata superata correttamente, cosicch\u00e9 il principio del minimo privilegio possa limitare ci\u00f2 che un account compromesso \u00e8 in grado di fare. Inoltre, controlli basati sul rischio possono introdurre verifiche aggiuntive quando una richiesta presenta elementi anomali ed il monitoraggio delle attivit\u00e0 di accesso aiuta a individuare comportamenti che non corrispondono alle abitudini o alle autorizzazioni dell’utente, consentendo di approfondire possibili compromissioni.<\/p>\n Queste verifiche devono coprire l’intero ciclo di vita dell’identit\u00e0, dalla sua verifica iniziale alla gestione delle credenziali, dal recupero dell’account alla concessione o revoca dei privilegi, includendo ovviamente gli accessi di terze parti e quelli privilegiati. Rafforzare soltanto il momento del login non \u00e8 sufficiente se un’identit\u00e0 pu\u00f2 essere compromessa attraverso un processo di assistenza meno protetto.<\/p>\n Social engineering e AI rendono pi\u00f9 credibili le truffe basate sull\u2019identit\u00e0: Imprivata indica come rafforzare autenticazione, controlli sugli accessi e formazione dei dipendenti<\/p>\n","protected":false},"author":1,"featured_media":8538,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[4154,8,1],"tags":[5609,4484],"class_list":{"0":"post-8537","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-featured","8":"category-opinioni","9":"category-speciale-sicurezza","10":"tag-imprivata","11":"tag-social-engineering"},"yoast_head":"\nAiutare a riconoscere le interazioni sospette<\/h3>\n
Limitare le conseguenze di una manipolazione riuscita<\/h3>\n
A cura di di Gilberto Bonutti, Regional Sales Manager & Head of Italy di Imprivata, che sar\u00e0 protagonista di un webinar gratuito in programma marted\u00ec 27 ottobre dal titolo “Meno password, pi\u00f9 cure” (REGISTRATI QUI<\/a>).<\/h3>\n","protected":false},"excerpt":{"rendered":"