Krótko: Świadomość bezpieczeństwa pracowników zespołu WWW oznacza: każda osoba prowadząca stronę zna trzy do czterech ryzyk swojej roli, rozpoznaje nieprawidłowości i zgłasza je szybko i bez obawy przed zarzutami. Redaktorzy potrzebują innych treści niż administratorzy. Krótkie, powtarzające się jednostki z przykładami z własnego CMS działają lepiej niż roczne obowiązkowe szkolenie.
Dlaczego właśnie teraz w centrum uwagi jest zespół WWW
Sytuacja wokół PHP2Shell pokazała, ile w ciągu kilku dni spada na operatorów stron internetowych: ostrzeżenia BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej), komunikaty firm hostingowych, rady na forach i w mediach społecznościowych, także fałszywe. W takich tygodniach o tym, którą wiadomość otworzą i w który link klikną, decydują nie tylko administratorzy, ale także redaktorzy, marketing i asystenci.
Duże wydarzenia w wiadomościach są, jak pokazuje doświadczenie, okazją dla oszustów. Proszę liczyć się z wiadomościami podającymi się za firmę hostingową, producenta CMS lub „dział IT”, wzywającymi do pilnego logowania albo rzekomej aktualizacji bezpieczeństwa. Kto zna prawdziwą sytuację, rzadziej się na to nabiera. Samej luki technicznej żaden redaktor nie zamknie, ale skradziony dostęp administratora otwiera drzwi także bez luki.
Świadomość bezpieczeństwa pracowników: kto czego potrzebuje?
Szkolenie dla wszystkich z tymi samymi slajdami zwykle mija się z celem. Sensowniejsze jest dopasowanie do ról. Poniższe zestawienie pomaga w planowaniu:
| Rola | Typowe ryzyka | Co osoba powinna umieć |
|---|---|---|
| Redaktor, marketing | wiadomości phishingowe, niebezpieczne przesyłanie plików, wspólne dostępy | sprawdzać nadawcę, przesyłać tylko oczekiwane typy plików, nigdy nie przekazywać własnych danych logowania |
| Administrator CMS | wtyczki z nieznanego źródła, zbyt wiele kont administratora, stare konta byłych pracowników | przydzielać uprawnienia oszczędnie, regularnie sprawdzać konta, instalować rozszerzenia tylko po zatwierdzeniu |
| Administrator serwera | niesprawdzone porady z sieci, zmiany bez protokołu, zapomniane pliki testowe | oceniać źródła, dokumentować zmiany, znać drogę awaryjną |
| Zarząd | presja na szybkie decyzje, niejasne odpowiedzialności | ustalić ścieżki decyzyjne, traktować zgłoszenia poważnie, zatwierdzać budżet na prewencję |
| Zewnętrzna agencja | wspólne dostępy, brak uzgodnień | używać własnych, osobistych kont, zapowiadać zmiany |
Tabela pokazuje też, gdzie musi pomóc technika. Osobiste konta zamiast dostępów zbiorczych i logowanie dwuskładnikowe dla wszystkich z uprawnieniami do zapisu zdejmują ze szkolenia dużo presji. Jak to zrobić, wyjaśnia artykuł Logowanie dwuskładnikowe dla dostępów administratora.
Co redaktorzy muszą wiedzieć, nie stając się technikami
Redaktorzy nie muszą wiedzieć, czym jest proces worker PHP. Powinni jednak pewnie opanować trzy rzeczy. Po pierwsze: wezwania do ponownego zalogowania się „z powodu incydentu bezpieczeństwa” nigdy nie realizuje się przez link w wiadomości, lecz zwykłą drogą do CMS albo przez zapytanie do administratora.
Po drugie: zgłaszać nieprawidłowości. Należą do nich nieznane konta użytkowników na liście użytkowników, strony lub wpisy, których nikt nie utworzył, nagłe przekierowania i ostrzeżenia w przeglądarce. Redaktor często widzi stronę częściej niż administrator i wcześniej zauważa zmiany.
Po trzecie: świadomie traktować przesyłane pliki. Obrazy i pliki PDF to codzienność, ale plik z nietypowym rozszerzeniem, archiwum „do przekazania dalej” lub dokument z makrami nie należy do CMS. Jeśli pliku nie da się przesłać, jest to zwykle zamierzone, a nie błąd, który należałoby obejść.
Czego dodatkowo potrzebują administratorzy
W przypadku administratorów chodzi mniej o phishing, a bardziej o osąd pod presją czasu. W tygodniu PHP2Shell krążyły rady, które autorzy fachowi wyraźnie odrzucają, na przykład blokowanie wszystkich żądań z PHPSESSID. Przegląd takich błędnych dróg daje wpis Niebezpieczne fałszywe porady dotyczące PHP2Shell. Dobrzy administratorzy sprawdzają najpierw źródło pierwotne, czyli php.net, BSI lub producenta, zanim zmienią konfigurację.
Należy do tego dyscyplina przy zmianach: co zostało zmienione, kiedy i dlaczego, i jak można to cofnąć? Wystarczy krótki wpis w zgłoszeniu lub wiki. W razie awarii ta lista jest na wagę złota, ponieważ pokazuje, która zmiana pochodzi od Państwa, a która nie.
Wreszcie administratorzy powinni wiedzieć, po czym rozpoznać możliwe włamanie i czego wtedy nie robić: nie usuwać w pośpiechu, nie instalować od razu od nowa, lecz zabezpieczyć i zgłosić. Typowe oznaki podsumowuje artykuł Czy już jestem skompromitowany?.
W 90 dni do czujnego zespołu WWW
Program nie musi być duży, aby działał. Sprawdziły się te kroki:
- Wyjaśnić stan faktyczny (tydzień 1 do 2): Kto ma jakie dostępy do CMS, hostingu, domeny i serwera? Rozwiązać konta zbiorcze, zablokować stare konta.
- Ustalić drogę zgłaszania (tydzień 2): Jeden adres lub kanał dla „coś mi się wydaje dziwne”. Na każde zgłoszenie jest odpowiedź, nawet jeśli było niegroźne.
- Pierwsza krótka jednostka dla każdej roli (tydzień 3 do 4): 20 minut, przykłady z własnego CMS, zrzuty ekranu prawdziwych menu.
- Wprowadzić logowanie dwuskładnikowe (do tygodnia 6): Dla wszystkich z uprawnieniami do zapisu, z kodami awaryjnymi w bezpiecznym miejscu.
- Wiadomość ćwiczebna i ocena (tydzień 8): Zapowiedziana kampania testowa bez piętnowania poszczególnych osób. Oceniane jest, czy zgłoszono, a nie kto kliknął.
- Druga jednostka z okazji (tydzień 10 do 12): Na przykład aktualna sytuacja bezpieczeństwa, przećwiczona na własnym systemie.
Sukces proszę mierzyć zgłoszeniami, a nie wskaźnikami kliknięć. Zespół, który dużo zgłasza, jest czujny. Zespół, który nigdy nie zgłasza, jest albo doskonały, albo niepewny, a to pierwsze zdarza się rzadko.
Jak konkretnie pomaga PHP SOS?
- Razem z Państwem ustalamy, kto ma jakie dostępy, i pokazujemy konta zbiorcze, nadmiarowych administratorów i zapomniane dostępy.
- Prowadzimy zdalnie krótkie jednostki dla każdej roli, z przykładami z Państwa CMS i środowiska serwerowego.
- Współtworzymy drogę zgłaszania i oceniamy napływające zgłoszenia podejrzeń, jeśli Państwo sobie tego życzą.
- W ramach umowy serwisowej w zakresie bezpieczeństwa powtarzamy jednostki przy aktualnych okazjach i regularnie sprawdzamy konta.
Podsumowanie
Świadomość bezpieczeństwa w zespole WWW nie bierze się ze strachu, lecz z jasności: każdy zna swoją rolę, swoje typowe ryzyka i drogę zgłaszania nieprawidłowości. W połączeniu z osobistymi kontami i logowaniem dwuskładnikowym jest to ochrona, która wytrzyma także następny tydzień kryzysowy.
Częste pytania
Czy redaktorzy w ogóle potrzebują szkolenia z bezpieczeństwa?
Tak. Redaktorzy mają dostęp do CMS, przesyłają pliki i otrzymują wiadomości, które wyglądają jak komunikaty systemowe. Nie muszą rozumieć techniki, ale powinni rozpoznawać, kiedy coś jest nietypowe, i wiedzieć, komu to zgłosić.
Jak często szkolić zespół WWW?
Lepiej krótko i regularnie niż raz w roku i długo. Sprawdziły się jednostki po 15 do 20 minut w odstępach kilku tygodni, uzupełnione okazją, taką jak aktualna sytuacja bezpieczeństwa.
Co zrobić, gdy pracownik kliknął link phishingowy?
Pozwolić zgłosić to od razu, bez zarzutów. Następnie zmienić dotknięte hasło, zakończyć aktywne sesje i sprawdzić, czy na koncie coś zostało zmienione. Im wcześniej nadejdzie zgłoszenie, tym mniejsza zwykle szkoda.
Czy szkolenie zastępuje techniczne środki ochrony?
Nie. Szkolenie i technika się uzupełniają. Logowanie dwuskładnikowe, rozdzielone role i aktualne oprogramowanie wychwytują błędy, które zdarzają się także dobrze wyszkolonym ludziom.