In breve: security awareness per i collaboratori del team web significa: ogni persona che cura un sito conosce i tre o quattro rischi del proprio ruolo, riconosce le anomalie e le segnala in fretta e senza timore di rimproveri. I redattori hanno bisogno di contenuti diversi dagli admin. Unità brevi e ricorrenti con esempi dal proprio CMS funzionano meglio di una formazione obbligatoria annuale.
Perché proprio ora il team web è al centro
La situazione attorno a PHP2Shell ha mostrato quanto si riversi in pochi giorni sui gestori di siti: avvisi del BSI (l'Ufficio federale tedesco per la sicurezza informatica), segnalazioni degli hoster, consigli in forum e social network, anche sbagliati. In settimane come queste non decidono solo gli admin, ma anche redattori, marketing e assistenza, quale e-mail aprire e quale link cliccare.
Per esperienza, le grandi notizie sono un'occasione per i truffatori. Metta in conto e-mail che si spacciano per hoster, produttori di CMS o «reparto IT» e invitano a un accesso urgente o a un presunto aggiornamento di sicurezza. Chi conosce la situazione reale ci cade più raramente. La falla tecnica non la chiude nessun redattore, ma un accesso admin rubato apre la porta anche senza falla.
Security awareness per i collaboratori: chi ha bisogno di che cosa?
Una formazione per tutti con le stesse slide di solito manca l'obiettivo. Più sensata è una calibrazione per ruolo. Il prospetto seguente aiuta nella pianificazione:
| Ruolo | Rischi tipici | Che cosa dovrebbe saper fare la persona |
|---|---|---|
| Redattore, marketing | e-mail di phishing, upload di file non sicuri, accessi condivisi | verificare il mittente, caricare solo i tipi di file attesi, non cedere mai le proprie credenziali |
| Amministratore CMS | plugin da fonti sconosciute, troppi account admin, vecchi account di ex collaboratori | assegnare i diritti con parsimonia, verificare regolarmente gli account, estensioni solo dopo approvazione |
| Admin del server | consigli non verificati dalla rete, modifiche senza registro, file di test dimenticati | valutare le fonti, documentare le modifiche, conoscere la via d'emergenza |
| Direzione | pressione per decisioni rapide, competenze poco chiare | definire i percorsi decisionali, prendere sul serio le segnalazioni, approvare il budget per la prevenzione |
| Agenzia esterna | accessi condivisi, mancanza di accordi | usare account propri e personali, annunciare le modifiche |
La tabella mostra anche dove la tecnica deve aiutare. Account personali al posto di accessi collettivi e un'autenticazione a due fattori per tutti coloro che hanno diritti di scrittura tolgono molta pressione alla formazione. Come fare è spiegato in Autenticazione a due fattori per gli accessi admin.
Che cosa devono sapere i redattori senza diventare tecnici
I redattori non devono sapere che cos'è un worker PHP. Dovrebbero però padroneggiare con sicurezza tre cose. Primo: l'invito a effettuare un nuovo accesso «a causa di un incidente di sicurezza» non si esegue mai tramite il link nell'e-mail, ma attraverso la consueta via di accesso al CMS o chiedendo conferma all'admin.
Secondo: segnalare le anomalie. Ne fanno parte account utente sconosciuti nell'elenco utenti, pagine o articoli che nessuno ha creato, reindirizzamenti improvvisi e avvisi nel browser. Un redattore vede il sito spesso più frequentemente dell'admin e nota prima i cambiamenti.
Terzo: trattare gli upload con consapevolezza. Immagini e PDF sono la routine, ma un file con un'estensione insolita, un archivio «da inoltrare» o un documento con macro non appartiene al CMS. Se un file non può essere caricato, di solito è voluto e non un errore da aggirare.
Che cosa serve in più agli admin
Per gli admin si tratta meno di phishing che di capacità di giudizio sotto pressione di tempo. Nella settimana di PHP2Shell circolavano consigli che gli autori specializzati rifiutano espressamente, ad esempio bloccare tutte le richieste con PHPSESSID. Una panoramica di tali strade sbagliate la offre l'articolo Falsi consigli pericolosi su PHP2Shell. I buoni admin verificano prima la fonte primaria, cioè php.net, il BSI o il produttore, prima di modificare una configurazione.
Vi rientra la disciplina nelle modifiche: che cosa è stato cambiato, quando e perché, e come lo si può annullare? Basta una breve voce nel ticket o nella wiki. Nell'emergenza questo elenco vale oro, perché mostra quale modifica proviene da Lei e quale no.
Infine gli admin dovrebbero sapere da che cosa riconoscono una possibile intrusione e che cosa non fare in quel caso: non cancellare in fretta, non reinstallare subito, ma conservare e segnalare. I segnali tipici sono riassunti in Sono già compromesso?.
In 90 giorni verso un team web vigile
Un programma non deve essere grande per funzionare. Questi passaggi si sono dimostrati validi:
- Chiarire la situazione attuale (settimane 1-2): chi ha quali accessi a CMS, hosting, dominio e server? Sciogliere gli account collettivi, bloccare i vecchi account.
- Stabilire il canale di segnalazione (settimana 2): un indirizzo o un canale per «qualcosa mi sembra strano». Ogni segnalazione riceve risposta, anche se era innocua.
- Prima unità breve per ruolo (settimane 3-4): 20 minuti, esempi dal proprio CMS, schermate di menu reali.
- Introdurre l'autenticazione a due fattori (entro la settimana 6): per tutti coloro che hanno diritti di scrittura, con codici di emergenza in un luogo sicuro.
- E-mail di prova e valutazione (settimana 8): una campagna di test annunciata, senza mettere in imbarazzo le singole persone. Si valuta se è stato segnalato, non chi ha cliccato.
- Seconda unità legata a un'occasione (settimane 10-12): ad esempio una situazione di sicurezza attuale, simulata sul proprio sistema.
Misuri il successo dalle segnalazioni, non dalle percentuali di clic. Un team che segnala molto è vigile. Un team che non segnala mai è o perfetto o intimidito, e la prima ipotesi è rara.
Come aiuta concretamente PHP SOS?
- Rileviamo insieme a Lei chi ha quali accessi e mostriamo account collettivi, admin in eccesso e accessi dimenticati.
- Teniamo da remoto unità brevi per ruolo, con esempi dal Suo CMS e dal Suo ambiente server.
- Configuriamo con Lei anche il canale di segnalazione e valutiamo le segnalazioni di sospetto in arrivo, se lo desidera.
- Nell'ambito di un contratto di manutenzione della sicurezza ripetiamo le unità in occasione di eventi attuali e verifichiamo regolarmente gli account.
Conclusione
La consapevolezza della sicurezza nel team web non nasce dalla paura, ma dalla chiarezza: ciascuno conosce il proprio ruolo, i suoi rischi tipici e la via per segnalare le anomalie. Combinata con account personali e autenticazione a due fattori, è una protezione che regge anche nella prossima settimana di crisi.
Domande frequenti
I redattori hanno davvero bisogno di una formazione sulla sicurezza?
Sì. I redattori hanno accesso al CMS, caricano file e ricevono e-mail che sembrano messaggi di sistema. Non devono capire la tecnica, ma riconoscere quando qualcosa è insolito e sapere a chi segnalarlo.
Ogni quanto formare il team web?
Meglio breve e regolare che lunga una volta l'anno. Si sono dimostrate valide unità di 15-20 minuti a distanza di poche settimane, integrate da un'occasione come una situazione di sicurezza attuale.
Che cosa fare se un collaboratore ha cliccato su un link di phishing?
Farlo segnalare subito, senza rimproveri. Poi cambiare la password interessata, chiudere le sessioni attive e verificare se con l'account è stato modificato qualcosa. Più presto arriva la segnalazione, più piccolo è di solito il danno.
La formazione sostituisce le misure tecniche di protezione?
No. Formazione e tecnica si integrano. Autenticazione a due fattori, ruoli separati e software aggiornato intercettano errori che capitano anche a persone ben formate.