Test di phishing via SMS per i dipendenti: lista di controllo per i

Un test di phishing via SMS per i dipendenti dovrebbe verificare se le persone sono in grado di riconoscere, verificare e segnalare messaggi di testo sospetti senza raccogliere password, codici MFA, dati di pagamento o informazioni personali. Sui telefoni gestiti dall’azienda, il test dovrebbe anche verificare la registrazione del dispositivo, l’uso approvato del numero di telefono, la consegna da parte dell’operatore, la segnalazione mobile e l’accuratezza degli eventi. Chi acquista dovrebbe confrontare questi controlli operativi prima di confrontare le librerie di modelli.

I dispositivi gestiti semplificano alcune questioni, ma non rendono automaticamente autorizzata, riservata o utile una simulazione di smishing. Un numero di telefono aziendale può essere memorizzato in diversi sistemi, gli strumenti di sicurezza mobile possono ispezionare automaticamente i link e i dipendenti possono comunque utilizzare il dispositivo per attività personali limitate. Un programma sicuro richiede uno scopo documentato, una fonte controllata dei destinatari, un percorso di segnalazione funzionante e limiti chiari sui dati raccolti.

Questa guida è di carattere difensivo. Non fornisce modelli di SMS ingannevoli, tecniche di spoofing del mittente, istruzioni per aggirare la consegna, metodi di raccolta delle credenziali né indicazioni per test non autorizzati.

Definisci cosa dovrebbe dimostrare il test via SMS

Inizia con un comportamento che l’organizzazione vuole migliorare. “Misurare chi clicca” è troppo vago perché un clic può essere accidentale, generato da uno scanner di sicurezza o non avere nulla a che vedere con il fatto che il dipendente sapesse come rispondere in modo sicuro.

Un obiettivo utile potrebbe essere verificare se i dipendenti:

si fermano a riflettere prima di agire in risposta a una richiesta inaspettata sul cellulare;
verificano la richiesta tramite un canale aziendale approvato;
segnalano un messaggio sospetto seguendo la procedura documentata;
evitano di trasferire un’approvazione sensibile tramite SMS; oppure
sanno cosa fare dopo aver interagito con un messaggio sospetto.

Scegli un obiettivo principale per il progetto pilota e definisci quali elementi dimostrano che è andato a buon fine. Ad esempio, per la segnalazione è necessario che ci sia un destinatario noto, una conferma di ricezione, una registrazione della valutazione iniziale e un evento nel rapporto di formazione. Questo è un test di accettazione più significativo rispetto alla semplice conferma che un provider di SMS ha restituito uno stato di consegna.

Se i test su dispositivi mobili fanno parte di un programma più ampio, usa la guida all’acquisto per la formazione sulla consapevolezza del phishing per allineare simulazioni, istruzioni, rinforzo e governance.

Verifica l’autorizzazione e la titolarità del numero di telefono

Il fatto che l’azienda sia proprietaria di un telefono non risolve tutte le questioni relative all’autorizzazione. I rappresentanti dei reparti sicurezza, IT, privacy, risorse umane, legale e dei dipendenti potrebbero dover concordare chi rientra nell’ambito del test, come informare i dipendenti e quali risultati sono visibili ai manager. I requisiti variano a seconda dell’organizzazione e della giurisdizione.

Prima dell’acquisto o di una fase pilota, documenta:

quali gruppi di dispositivi gestiti sono idonei;
quale sistema è la fonte ufficiale per i numeri di telefono aziendali;
chi approva il test e l’elenco dei destinatari;
quali ruoli, regioni, stati di assenza o gruppi sensibili sono esclusi;
se gli appaltatori e il personale temporaneo hanno condizioni separate;
come i dipendenti possono correggere un numero non più valido o riassegnato; e
in quanto tempo un numero viene rimosso dopo la restituzione del dispositivo o la cessazione del rapporto di lavoro.

Non riutilizzare i numeri di emergenza o quelli personali presenti nei registri delle Risorse Umane. La piattaforma dovrebbe importare solo i dati di contatto aziendali approvati e conservare una registrazione chiara delle decisioni di inclusione ed esclusione.

Confronta l’integrazione dei dispositivi gestiti senza raccogliere dati in eccesso

Una piattaforma di phishing via SMS raramente ha bisogno di un accesso esteso al dispositivo mobile. Le servono un numero approvato, dati di identità sufficienti per assegnare l’evento di formazione e un insieme limitato di eventi di invio e risposta. La gestione dei dispositivi mobili dovrebbe rimanere l’autorità di riferimento per l’inventario dei dispositivi e la conformità, piuttosto che diventare una scusa per raccogliere dati comportamentali extra.

Chiedi ai fornitori di dimostrare:

sincronizzazione o importazione controllata dei numeri di telefono idonei;
separazione dei numeri aziendali dai record di contatto personali;
convalida delle modifiche ai numeri, delle riassegnazioni e dei record duplicati;
accesso basato sui ruoli agli identificatori mobili e ai risultati;
conservazione e cancellazione configurabili;
registri di audit per importazioni, approvazioni di campagne, esportazioni e modifiche amministrative; e
un modo per eseguire il programma senza leggere il contenuto degli SMS dei dipendenti, i contatti, i dati delle app o la telemetria del dispositivo non correlati all’esercizio.

L’integrazione più sicura è circoscritta e trasparente. Un fornitore dovrebbe essere in grado di specificare quali campi di dati riceve, perché ogni campo è necessario, dove vengono elaborati i dati, per quanto tempo vengono conservati e come viene verificata la cancellazione.

Verifica della consegna come dipendenza operativa

La consegna degli SMS è diversa dalla posta elettronica aziendale. Operatori, paesi, tipi di mittenti, filtri, impostazioni del telefono, roaming e cambiamenti di numero possono tutti influire sull’arrivo di un messaggio e su come viene visualizzato. I risultati di consegna devono quindi essere convalidati separatamente prima di poter interpretare il comportamento dei dipendenti.

Durante un test tecnico limitato, verifica:

i paesi, gli operatori e i formati dei mittenti supportati;
come appare l’identità del mittente sulle configurazioni iOS e Android gestite incluse nell’ambito del test;
come vengono rappresentati i messaggi ritardati, bloccati, duplicati o non consegnati;
se i requisiti dell’operatore o delle telecomunicazioni aggiungono testo obbligatorio o opzioni di disiscrizione;
se la piattaforma può interrompere un test tempestivamente;
in che modo gli scanner di sicurezza, le anteprime dei link e gli strumenti di protezione mobile influenzano gli eventi; e
se i registri di consegna possono essere riconciliati senza rivelare i numeri di telefono completi nei report di routine.

Non chiedere a un provider di aggirare le protezioni degli operatori o di mascherare il traffico. Se un test dipende dall’aggiramento delle misure di sicurezza, non è un’attività di sensibilizzazione adeguata.

Richiedi un percorso di segnalazione da cellulare che i dipendenti possano usare

I pulsanti di segnalazione via e-mail non risolvono il problema della segnalazione degli SMS. Ai dipendenti potrebbe essere chiesto di inoltrare un messaggio, fare uno screenshot, aprire un portale di assistenza, chiamare un helpdesk o usare un’app di sicurezza per cellulari. Ogni metodo comporta diversi compromessi in termini di usabilità e privacy.

Prima di inviare una simulazione, definisci un percorso di segnalazione principale e uno di riserva. Poi testa l’intero percorso:

Un dipendente segnala l’SMS sospetto da un telefono gestito supportato.
La segnalazione raggiunge il SOC o la coda dell’helpdesk corretti.
Gli analisti riescono a distinguere una segnalazione di simulazione da un incidente reale senza ignorare nessuna delle due.
Il dipendente riceve una conferma di ricezione e indicazioni sicure su come procedere.
La piattaforma di formazione registra accuratamente la segnalazione.
L’organizzazione può segnalare a livello superiore una vera minaccia mobile scoperta durante l’esercitazione.

Gli screenshot e i messaggi inoltrati possono contenere notifiche non pertinenti, nomi di contatti o altri elementi di contesto. Il processo di segnalazione dovrebbe spiegare ai dipendenti come ridurre al minimo i dati non necessari e non dovrebbe richiedere loro di inviare contenuti aziendali tramite un account personale.

Imposta controlli di sicurezza rigorosi per ogni simulazione

Un telefono gestito è comunque un dispositivo destinato ai dipendenti, e gli SMS possono sembrare più personali e urgenti delle e-mail. La gestione degli scenari dovrebbe quindi essere visibile nel prodotto, non lasciata a una promessa informale.

Richiedi controlli che impediscano:

la raccolta di password reali, codici MFA, dettagli di pagamento, token o dati personali;
link a destinazioni di terze parti non controllate;
richieste di installare applicazioni o di compromettere la sicurezza del dispositivo;
l’usurpazione dell’identità di dirigenti o colleghi reali senza approvazione esplicita;
temi che causano forte disagio, come salute, licenziamenti, immigrazione, emergenze o finanze personali;
classifiche punitive o l’identificazione pubblica di individui; e
modifiche o avviamenti non controllati da parte di amministratori che non hanno l’autorità di approvazione.

La destinazione prevista deve essere una pagina HTTPS approvata che registri solo l’evento minimo necessario per l’obiettivo didattico e fornisca poi un feedback formativo immediato. Per una panoramica delle funzionalità di simulazione sicure pensate per i dispositivi mobili, dai un’occhiata alla piattaforma di smishing AutoPhish.

Valuta il feedback sul dispositivo che i dipendenti usano davvero

Il momento di apprendimento deve funzionare sul dispositivo gestito, non solo su una dashboard desktop. Chiedi di vedere l’esperienza completa del dipendente sulle configurazioni iOS e Android supportate.

Un buon feedback dovrebbe:

spiegare i segnali di allarme rilevanti per lo scenario;
rafforzare le procedure approvate di verifica e segnalazione;
evitare un linguaggio umiliante;
rimanere accessibile su uno schermo piccolo;
supportare le lingue richieste dalla forza lavoro;
fornire un passo successivo sicuro sia dopo la segnalazione che dopo un’interazione rischiosa; e
evitare di raccogliere un’altra serie di informazioni personali.

La formazione di follow-up dovrebbe essere proporzionata al comportamento osservato. Un breve richiamo potrebbe essere appropriato dopo una singola interazione, mentre azioni rischiose ripetute potrebbero giustificare un ulteriore coaching. Il sistema dovrebbe supportare eccezioni, permessi, esigenze di accessibilità e finestre di completamento che gli amministratori possano spiegare.

Usa metriche che reggano a un’analisi tecnica approfondita

Il tasso di clic grezzo è particolarmente inaffidabile sui dispositivi mobili. I servizi di anteprima dei link, gli strumenti di sicurezza, i tocchi accidentali, i messaggi in ritardo e i numeri riutilizzati possono tutti distorcere i risultati.

Usa un insieme equilibrato di metriche:

destinatari idonei, tentativi di consegna, consegne confermate e errori;
tasso di segnalazione e tempo mediano per la segnalazione;
uso corretto del canale di segnalazione approvato;
rapporto tra segnalazioni e azioni rischiose;
ripetizione del comportamento in esercitazioni simili;
completamento del follow-up e comportamento successivo; e
eventi esclusi come attività di scansione, anteprima, test o amministrative.

Documenta le definizioni degli eventi prima della fase pilota. Gli acquirenti dovrebbero chiedere al fornitore di mostrare come la consegna di un SMS, il caricamento di una pagina, l’interazione di un dipendente, l’ispezione automatizzata, una segnalazione e il completamento della formazione appaiono sia nella dashboard che nell’esportazione.

Le linee guida del NIST per la creazione di programmi di formazione sulla sicurezza informatica e la privacy sostengono un programma di formazione basato sui ruoli, misurabile e in continuo miglioramento. Si tratta di un modello più solido rispetto al considerare un singolo grafico sul tasso di clic dello smishing come prova del rischio per i dipendenti.

Esegui una fase pilota con telefoni gestiti prima di un’implementazione più ampia

Una piccola fase pilota dovrebbe testare il funzionamento del sistema operativo durante la simulazione, non solo il messaggio stesso.

Scegli un gruppo rappresentativo. Includi una combinazione limitata di dispositivi iOS e Android gestiti, operatori, ruoli e regioni.
Verifica i destinatari. Assicurati che ogni numero aziendale sia aggiornato, autorizzato e assegnato al dipendente giusto.
Verifica la consegna e i “rumori” dell’automazione. Registra gli errori, i ritardi, gli eventi di anteprima e l’attività degli strumenti di sicurezza.
Metti alla prova il flusso di lavoro di segnalazione. Verifica la conferma da parte del dipendente, la coda del SOC o dell’helpdesk, il percorso di escalation e l’evento nella dashboard.
Punta a un obiettivo poco impegnativo. Testa un singolo comportamento di verifica o di reportistica senza richiedere informazioni riservate né replicare un incidente in corso.
Controlla la privacy e gli accessi. Verifica quali identificatori compaiono nelle dashboard, nelle esportazioni, nei ticket e nei registri di formazione.
Confronta le prove finali. Confronta l’idoneità, la consegna, le azioni dei dipendenti, i report, gli eventi automatici esclusi e gli incarichi di follow-up.

Il progetto pilota dovrebbe concludersi con una decisione: pronto per l’espansione, pronto dopo alcune correzioni specifiche o non adatto al programma previsto. Il semplice fatto che l’invio vada a buon fine non è di per sé un criterio di accettazione.

Poni ai fornitori queste domande da acquirente

Preferisci dimostrazioni concrete piuttosto che risposte basate su elenchi di funzionalità:

Come vengono importati, aggiornati, esclusi ed eliminati i numeri di telefono aziendali approvati?
Quali paesi, operatori, formati di mittente, versioni iOS e versioni Android sono supportati?
In che modo la piattaforma distingue le azioni dei dipendenti dalle anteprime dei link e dagli scanner di sicurezza?
Le simulazioni possono funzionare senza raccogliere password, codici MFA, dati di pagamento o altre informazioni riservate?
Quali canali di segnalazione da dispositivi mobili sono supportati e in che modo i rapporti entrano nel flusso di lavoro del nostro SOC o dell’helpdesk?
Cosa vede un dipendente dopo aver segnalato un problema o interagito su un telefono gestito?
Quali identificatori individuali vengono memorizzati, dove, per quanto tempo e chi può accedervi?
Gli amministratori possono applicare approvazioni, esclusioni, ruoli con ambito limitato, limiti di conservazione e registri di audit?
Come vengono rappresentati nei report i messaggi falliti, ritardati, duplicati o bloccati?
Le esportazioni riescono a conciliare idoneità, consegna, comportamento, reportistica e follow-up senza sopravvalutare l’efficacia?

La piattaforma giusta dovrebbe rendere visibili le eccezioni e gli errori. Una libreria di modelli ben curata non può compensare dati telefonici obsoleti, autorizzazioni deboli, reportistica inutilizzabile o metriche distorte dagli strumenti automatizzati.

Crea un programma mobile gestito di cui i dipendenti possano fidarsi

Un test di phishing via SMS efficace per i dipendenti combina destinatari autorizzati, uso mirato dei dati, consegna trasparente, scenari sicuri, reportistica pratica, apprendimento immediato e misurazioni attendibili. I telefoni gestiti dall’azienda possono semplificare la gestione del programma, ma solo se la piattaforma supporta esplicitamente questi controlli.

Se vuoi valutare simulazioni di smishing controllate e i flussi di lavoro di segnalazione dei dipendenti, Iscriviti per includere AutoPhish nel tuo progetto pilota sui telefoni gestiti.

Domande frequenti

Un datore di lavoro può eseguire un test di smishing su un telefono aziendale?

Il semplice possesso del dispositivo non è un’autorizzazione sufficiente. L’organizzazione dovrebbe definire lo scopo, la popolazione idonea, la fonte dei dati dei destinatari, la trasparenza per i dipendenti, l’accesso ai risultati, la conservazione dei dati, le esclusioni e le approvazioni delle parti interessate richieste nelle proprie giurisdizioni.

Un test di phishing via SMS dovrebbe raccogliere credenziali?

No. Un’esercitazione di sensibilizzazione difensiva può valutare l’interazione sicura, la verifica, la segnalazione e il follow-up senza memorizzare password reali, codici MFA, dati di pagamento o altre informazioni riservate.

Qual è la metrica migliore per i test di smishing sui dipendenti?

Nessuna singola metrica è sufficiente. Il tasso di segnalazione, il tempo impiegato per segnalare, il corretto percorso di segnalazione, il comportamento ripetitivo, la qualità della consegna e i risultati del follow-up sono più utili se considerati insieme rispetto al solo tasso di clic.

I telefoni gestiti sono più facili da testare rispetto ai dispositivi BYOD?

Di solito offrono maggiore chiarezza riguardo alla proprietà del dispositivo, alla configurazione e ai limiti di assistenza. Richiedono comunque l’uso di numeri approvati, limiti di privacy, convalida dell’operatore, scenari sicuri, segnalazione funzionante e gestione accurata degli eventi.

Test di phishing via SMS per i dipendenti: lista di controllo per i telefoni gestiti