Pe scurt: Security awareness pentru angajații din echipa web înseamnă: fiecare persoană care întreține un site cunoaște cele trei-patru riscuri ale rolului său, recunoaște anomaliile și le raportează rapid și fără teama de reproșuri. Redactorii au nevoie de alt conținut decât administratorii. Sesiunile scurte, recurente, cu exemple din propriul CMS funcționează mai bine decât o instruire obligatorie anuală.
De ce echipa web este acum în centru
Situația din jurul PHP2Shell a arătat cât de multe se abat în câteva zile asupra operatorilor de site-uri: avertizări ale BSI (Oficiul Federal German pentru Securitatea Informațiilor), mesaje de la furnizorii de hosting, sfaturi pe forumuri și în rețelele sociale, printre ele și false. În astfel de săptămâni, nu doar administratorii, ci și redactorii, marketingul și asistența decid ce e-mail deschid și pe ce link dau clic.
Marile situații de știri sunt, din experiență, un prilej pentru escroci. Așteptați-vă la e-mailuri care se dau drept furnizor de hosting, producător de CMS sau „departament IT” și cer o autentificare urgentă sau un presupus update de securitate. Cine cunoaște situația reală cade mai rar în această capcană. Breșa tehnică în sine nu o închide niciun redactor, dar un acces de administrator furat deschide ușa și fără breșă.
Security awareness pentru angajați: cine are nevoie de ce?
O instruire pentru toți, cu aceleași prezentări, ratează de obicei ținta. Mai sensibilă este o adaptare pe roluri. Prezentarea următoare ajută la planificare:
| Rol | Riscuri tipice | Ce ar trebui să poată persoana |
|---|---|---|
| Redactor, marketing | e-mailuri de phishing, încărcări nesigure de fișiere, accese partajate | să verifice expeditorul, să încarce doar tipurile de fișiere așteptate, să nu transmită niciodată propriile date de acces |
| Administrator CMS | pluginuri din surse necunoscute, prea multe conturi de administrator, conturi vechi ale foștilor angajați | să acorde drepturi cu parcimonie, să verifice regulat conturile, să adauge extensii doar după aprobare |
| Administrator de server | sfaturi neverificate din rețea, modificări fără jurnal, fișiere de test uitate | să evalueze sursele, să documenteze modificările, să cunoască calea de urgență |
| Conducerea | presiune pentru decizii rapide, responsabilități neclare | să stabilească căile de decizie, să ia în serios avertizările, să aprobe buget pentru prevenție |
| Agenție externă | accese comune, lipsa înțelegerilor | să folosească conturi proprii, personale, să anunțe modificările |
Tabelul arată și unde trebuie să ajute tehnica. Conturile personale în loc de accese colective și o autentificare în doi factori pentru toți cei cu drepturi de scriere iau multă presiune de pe instruire. Cum se face aflați la Autentificarea în doi factori pentru accesele de administrator.
Ce trebuie să știe redactorii fără a deveni tehnicieni
Redactorii nu trebuie să știe ce este un worker PHP. Ar trebui însă să stăpânească sigur trei lucruri. În primul rând: o cerere de a vă autentifica din nou „din cauza unui incident de securitate” nu se rezolvă niciodată prin linkul din e-mail, ci pe calea obișnuită în CMS sau printr-o întrebare adresată administratorului.
În al doilea rând: raportarea anomaliilor. Aici intră conturile de utilizator necunoscute din lista de utilizatori, paginile sau articolele pe care nu le-a creat nimeni, redirecționările bruște și avertismentele din browser. Un redactor vede adesea site-ul mai des decât administratorul și observă modificările mai devreme.
În al treilea rând: tratarea conștientă a încărcărilor. Imaginile și PDF-urile sunt cotidiene, dar un fișier cu o extensie neobișnuită, o arhivă „pentru retransmitere” sau un document cu macrocomenzi nu au ce căuta în CMS. Dacă un fișier nu poate fi încărcat, de obicei este intenționat și nu o eroare pe care ar trebui s-o ocoliți.
Ce au nevoie în plus administratorii
Pentru administratori este vorba mai puțin de phishing și mai mult de discernământ sub presiunea timpului. În săptămâna PHP2Shell au circulat sfaturi pe care autorii de specialitate le resping în mod explicit, de exemplu blocarea tuturor cererilor cu PHPSESSID. O prezentare a unor astfel de rătăciri oferă articolul Sfaturi false periculoase despre PHP2Shell. Administratorii buni verifică mai întâi sursa primară, adică php.net, BSI sau producătorul, înainte de a modifica o configurație.
La aceasta se adaugă disciplina la modificări: ce s-a modificat, când și de ce, și cum poate fi anulat? O scurtă intrare în tichet sau wiki este suficientă. În caz de urgență, această listă valorează aur, pentru că arată care modificare vine de la dumneavoastră și care nu.
În sfârșit, administratorii ar trebui să știe după ce recunosc o posibilă intruziune și ce nu trebuie făcut atunci: să nu șteargă în grabă, să nu reinstaleze imediat, ci să securizeze și să raporteze. Semnele tipice le rezumă Sunt deja compromis?.
În 90 de zile către o echipă web atentă
Un program nu trebuie să fie mare pentru a funcționa. Acești pași s-au dovedit utili:
- Clarificați situația existentă (săptămânile 1 până la 2): Cine are ce accese la CMS, hosting, domeniu și server? Desființați conturile colective, blocați conturile vechi.
- Stabiliți calea de raportare (săptămâna 2): O adresă sau un canal pentru „mi se pare ciudat ceva”. Fiecare raportare primește răspuns, chiar dacă a fost inofensivă.
- Prima sesiune scurtă pe rol (săptămânile 3 până la 4): 20 de minute, exemple din propriul CMS, capturi de ecran ale unor meniuri reale.
- Introduceți autentificarea în doi factori (până în săptămâna 6): Pentru toți cei cu drepturi de scriere, cu coduri de urgență păstrate într-un loc sigur.
- E-mail de exercițiu și evaluare (săptămâna 8): O campanie de test anunțată, fără a expune persoane individuale. Se evaluează dacă s-a raportat, nu cine a dat clic.
- A doua sesiune pe o ocazie actuală (săptămânile 10 până la 12): De exemplu o situație actuală de securitate, jucată pe propriul sistem.
Măsurați succesul prin raportări, nu prin rate de clic. O echipă care raportează mult este atentă. O echipă care nu raportează niciodată este fie perfectă, fie nesigură, iar prima variantă este rară.
Cum ajută PHP SOS concret?
- Înregistrăm împreună cu dumneavoastră cine are ce accese și arătăm conturile colective, administratorii în plus și accesele uitate.
- Ținem sesiuni scurte pe roluri, la distanță, cu exemple din CMS-ul și mediul dumneavoastră de servere.
- Configurăm împreună calea de raportare și evaluăm raportările de suspiciune primite, dacă doriți.
- În cadrul unui contract de mentenanță de securitate repetăm sesiunile la ocazii actuale și verificăm regulat conturile.
Concluzie
Conștientizarea securității în echipa web nu apare din frică, ci din claritate: fiecare își cunoaște rolul, riscurile tipice și calea de raportare a anomaliilor. Combinată cu conturi personale și autentificare în doi factori, aceasta este o protecție care rezistă și în următoarea săptămână de criză.
Întrebări frecvente
Au redactorii nevoie de o instruire de securitate?
Da. Redactorii au acces la CMS, încarcă fișiere și primesc e-mailuri care arată ca mesaje de sistem. Nu trebuie să înțeleagă tehnica, dar să recunoască atunci când ceva este neobișnuit și să știe cui să raporteze.
Cât de des ar trebui instruită echipa web?
Mai bine scurt și regulat decât o dată pe an, îndelung. S-au dovedit utile sesiuni de 15 până la 20 de minute la câteva săptămâni distanță, completate cu o ocazie precum o situație actuală de securitate.
Ce fac dacă un angajat a dat clic pe un link de phishing?
Să raporteze imediat, fără reproșuri. Apoi se schimbă parola afectată, se încheie sesiunile active și se verifică dacă s-a modificat ceva cu contul. Cu cât raportarea vine mai devreme, cu atât paguba este de obicei mai mică.
Înlocuiește o instruire măsurile tehnice de protecție?
Nu. Instruirea și tehnica se completează. Autentificarea în doi factori, rolurile separate și software-ul actualizat prind erorile care se întâmplă și oamenilor bine instruiți.