Накратко: Осведоменост за сигурността при служителите в уеб екипа означава: всеки, който поддържа уебсайт, познава трите-четири риска на своята роля, разпознава необичайното и го съобщава бързо и без страх от упреци. Редакторите се нуждаят от друго съдържание, отколкото администраторите. Кратки, повтарящи се занятия с примери от собствения CMS действат по-добре от годишно задължително обучение.
Защо именно сега уеб екипът е в центъра
Положението около PHP2Shell показа колко много неща се стоварват върху операторите на уебсайтове за няколко дни: предупреждения на BSI (Федералната служба за информационна сигурност на Германия), съобщения от хостинг доставчици, съвети във форуми и социални мрежи, сред тях и неверни. В такива седмици решават не само администраторите, но и редакторите, маркетингът и асистентите кой имейл да отворят и върху коя връзка да кликнат.
Големите новинарски ситуации според опита са повод за измамници. Разчитайте на имейли, които се представят за хостинг доставчик, производител на CMS или „ИТ отдел“ и призовават към спешен вход или уж ъпдейт за сигурност. Който познава истинското положение, по-рядко се връзва. Самата техническа уязвимост не се затваря от редактор, но откраднат администраторски достъп отваря вратата и без уязвимост.
Осведоменост за сигурността на служителите: кой от какво се нуждае?
Обучение за всички със същите слайдове обикновено не постига целта си. По-смислено е нагаждане по роли. Следният преглед помага при планирането:
| Роля | Типични рискове | Какво трябва да може лицето |
|---|---|---|
| Редактор, маркетинг | фишинг имейли, несигурно качване на файлове, споделени достъпи | да проверява подателя, да качва само очаквани видове файлове, никога да не предава собствените си данни за достъп |
| CMS администратор | добавки от неизвестен източник, твърде много администраторски акаунти, стари акаунти на бивши служители | да дава права пестеливо, да проверява акаунтите редовно, разширения само след одобрение |
| Сървърен администратор | непроверени съвети от мрежата, промени без протокол, забравени тестови файлове | да оценява източниците, да документира промените, да познава пътя при извънредни случаи |
| Управител | натиск за бързи решения, неясни отговорности | да определи пътищата за вземане на решения, да приема сериозно съобщенията, да отпусне бюджет за превенция |
| Външна агенция | общи достъпи, липса на уговорки | да използва собствени, лични акаунти, да обявява промените |
Таблицата показва и къде техниката трябва да помогне. Лични акаунти вместо общи достъпи и двуфакторно удостоверяване за всички с права за запис снемат много натиск от обучението. Как става това, е описано в Двуфакторно удостоверяване за администраторски достъпи.
Какво трябва да знаят редакторите, без да стават техници
Редакторите не е нужно да знаят какво е PHP worker. Трябва обаче да владеят сигурно три неща. Първо: покана да влезете наново „поради инцидент със сигурността“ никога не се изпълнява чрез връзката в имейла, а по обичайния път към CMS или чрез запитване до администратора.
Второ: съобщаване на необичайното. Към него спадат непознати потребителски акаунти в списъка с потребители, страници или публикации, които никой не е създал, внезапни пренасочвания и предупреждения в браузъра. Редакторът често вижда уебсайта по-често от администратора и забелязва промените по-рано.
Трето: съзнателно отношение към качваните файлове. Изображения и PDF са ежедневие, но файл с необичайно разширение, архив „за препращане“ или документ с макроси не принадлежи в CMS. Ако един файл не може да бъде качен, това обикновено е нарочно, а не грешка, която да се заобикаля.
От какво се нуждаят допълнително администраторите
За администраторите става дума по-малко за фишинг, а повече за преценка под натиск на времето. През седмицата на PHP2Shell циркулираха съвети, които специалистите изрично отхвърлят, например да се блокират всички заявки с PHPSESSID. Преглед на такива заблуди предлага материалът Опасни фалшиви съвети за PHP2Shell. Добрите администратори първо проверяват първичния източник, тоест php.net, BSI или производителя, преди да променят конфигурация.
Към това спада дисциплина при промените: какво е променено, кога и защо и как може да се върне назад? Достатъчен е кратък запис в тикета или уикито. В критичен момент този списък струва злато, защото показва коя промяна е от Вас и коя не.
Накрая администраторите трябва да знаят по какво се разпознава възможно проникване и какво тогава не бива да се прави: не се трие трескаво, не се преинсталира веднага, а се запазва и се съобщава. Типичните признаци обобщава Вече компрометирани ли сме?.
За 90 дни до бдителен уеб екип
Една програма не е нужно да е голяма, за да действа. Тези стъпки са се доказали:
- Изяснете състоянието (седмица 1 до 2): Кой какви достъпи има до CMS, хостинг, домейн и сървър? Разпуснете общите акаунти, блокирайте старите.
- Определете пътя за съобщаване (седмица 2): Един адрес или канал за „нещо ми се струва странно“. На всяко съобщение се отговаря, дори да е било безобидно.
- Първо кратко занятие за всяка роля (седмица 3 до 4): 20 минути, примери от собствения CMS, екранни снимки на истински менюта.
- Въведете двуфакторно удостоверяване (до седмица 6): За всички с права за запис, с аварийни кодове на сигурно място.
- Учебен имейл и оценка (седмица 8): Обявена тестова кампания без излагане на отделни лица. Оценява се дали е съобщено, а не кой е кликнал.
- Второ занятие по повод (седмица 10 до 12): Например актуална ситуация със сигурността, изиграна върху собствената система.
Измервайте успеха по съобщенията, а не по процента кликове. Екип, който съобщава много, е бдителен. Екип, който никога не съобщава, е или съвършен, или несигурен, а първото е рядкост.
Как помага PHP SOS конкретно?
- Установяваме заедно с Вас кой какви достъпи има и показваме общи акаунти, излишни администратори и забравени достъпи.
- Провеждаме кратки занятия за всяка роля отдалечено, с примери от Вашия CMS и Вашата сървърна среда.
- Помагаме да се настрои пътят за съобщаване и оценяваме постъпилите сигнали за подозрения, ако желаете.
- В рамките на договор за поддръжка на сигурността повтаряме занятията по актуални поводи и проверяваме акаунтите редовно.
Извод
Осведомеността за сигурността в уеб екипа не се поражда от страх, а от яснота: всеки познава своята роля, типичните си рискове и пътя за съобщаване на необичайното. В съчетание с лични акаунти и двуфакторно удостоверяване това е защита, която издържа и в следващата кризисна седмица.
Често задавани въпроси
Нужно ли е на редакторите изобщо обучение по сигурност?
Да. Редакторите имат достъп до CMS, качват файлове и получават имейли, които изглеждат като системни съобщения. Не е нужно да разбират от техника, но трябва да познават кога нещо е необичайно и на кого да го съобщят.
Колко често трябва да се обучава уеб екипът?
По-добре кратко и редовно, отколкото дълго веднъж годишно. Доказали са се занятия от 15 до 20 минути през няколко седмици, допълнени с повод като актуална ситуация със сигурността.
Какво да се направи, ако служител е кликнал върху фишинг връзка?
Да се съобщи веднага, без упреци. След това се сменя засегнатата парола, прекратяват се активните сесии и се проверява дали нещо е променено с акаунта. Колкото по-рано дойде съобщението, толкова по-малка е обикновено щетата.
Заменя ли обучението техническите защитни мерки?
Не. Обучението и техниката се допълват. Двуфакторното удостоверяване, разделените роли и актуалният софтуер улавят грешки, които се случват и на добре обучени хора.