Накратко: Когато една атака засяга повече от един уебсайт, Ви е нужен доставчик на услуги за Incident Response, който обработва инцидента структурирано. Ние поемаме картината на положението, ограничаването, почистването и сигурното възстановяване, с ясни роли и безпропускова документация. Вие запазвате решенията, ние осигуряваме техническата основа.
Какво означава Incident Response при атаки на сървъри
Incident Response е подредената обработка на инцидент със сигурността. Вместо трескави единични действия работата следва твърди фази: разпознаване и класифициране, ограничаване, отстраняване, възстановяване, последваща работа. Всяка мярка се записва с момент и обосновка.
Особено при уеб сървърите това е важно. Сървър с PHP приложения често съдържа данни за достъп до бази данни, платежни доставчици, пощенски сървъри и интерфейси. Който е проникнал там, може да се придвижи нататък. Положението след PHP2Shell показва колко бързо може да възникне такава ситуация: изпълнение на код без удостоверяване, над 22,6 милиона изложени на риск инстанции според Unit 42 и никакви публикувани, потвърдени Indicators of Compromise.
Кога Ви е нужен доставчик на услуги за Incident Response
- засегнати са или може да са засегнати няколко сървъра или приложения
- има съмнение, че са изтекли лични данни или платежни данни
- атакуващият може още да е активен, например чрез текущи връзки или нови акаунти
- има изнудване или публично обявяване на атаката
- застраховател, органи или бизнес партньори очакват документиран ход
При един-единствен заразен уебсайт често е достатъчна спешната помощ при хакнат уебсайт. Прехода към пълна обработка на инцидента обсъждаме с Вас, щом се очертае по-голям мащаб.
Как помага PHP SOS конкретно?
- Триаж и картина на положението: Изясняваме какво е наблюдавано, кои системи и данни може да са засегнати и кой вътрешно трябва да бъде включен. Резултатът е първа, писмена картина на положението с отворените въпроси.
- Запазване на следите и ограничаване: Логовете, файловите системи и базите данни се архивират, преди да се намесим. След това изолираме засегнатите системи, блокираме компрометираните достъпи и прекъсваме разпознаваемите връзки на атакуващия.
- Отстраняване: Затваряме входния път, например чрез пачване до поправените PHP версии и рестартиране на всички worker процеси, премахваме задните вратички и сменяме тайните. За детайлния анализ при нужда включваме специализирани партньори за ИТ форензика.
- Възстановяване: Системите се връщат в работа контролирано, по възможност от чисти източници или на наново настроени сървъри. След това ги наблюдаваме засилено за нови аномалии.
- Последваща работа: Получавате заключителен доклад с времева линия, причини, мерки и препоръки. Заедно записваме какво трябва да върви по-бързо следващия път.
Запазете сървърните логове и не променяйте системите, преди да е направен архив. При PHP2Shell BSI препоръчва уеб сървърите, които не могат да бъдат пачнати веднага, да се изключат временно от мрежата.
Роли и комуникация по време на инцидента
Един инцидент се нуждае от ясни отговорности. Доказал се е малък кръг от лице с право да решава, технически човек за контакт от Ваша страна и ние като техническо ръководство. Оперативките се провеждат през определени интервали, резултатите се записват писмено.
Паралелно текат задачи, които не поемаме, но за които предоставяме факти: проверката на задължение за уведомяване по ОРЗД в рамките на 72 часа, информирането на застрахователя, евентуален сигнал до органите и кризисната комуникация към клиенти и партньори.
Какво ни е нужно от Вас и какво получавате
Нужни са ни административни достъпи до засегнатите системи, преглед на инфраструктурата и на доставчиците на услуги, лице с право да решава и готовност при нужда системите да се изключат временно. Полезни са налични планове за спешни случаи, мрежови скици и архиви с дата.
Получавате текущ протокол на инцидента, редовни картини на положението на разбираем език, заключителен доклад за управителите, длъжностното лице по защита на данните и застрахователя, както и приоритизиран списък с подобрения. Как да се подготвите по-добре за следващия инцидент, описва страницата Изготвяне на ИТ план за спешни случаи за уеб сървъри.
Типични грешки през първите часове
Много инциденти се влошават, защото в напрежението добронамерени стъпки се правят в грешен ред. Тези модели виждаме често:
- Незабавно ново настройване: Сървърът се изтрива и инсталира наново, преди да е направен архив. След това вече не може да се изясни дали са изтекли данни.
- Смяна на пароли от заразената система: Ако атакуващият още има достъп, той вижда и новите пароли.
- Изтриване само на видимия файл: Уеб шелът е изчезнал, но втората задна вратичка в cron задачата остава.
- Пачване без рестартиране: Новите PHP файлове лежат на диска, а старите worker процеси продължават да работят в паметта.
- Никой не води протокол: По-късно никой не знае кой кога какво е променил. Това затруднява разговорите със застраховател и органи.
Съгласуваният ход предотвратява тези грешки, без да забавя ограничаването.
Какво не обещаваме
Не обещаваме, че всеки инцидент ще бъде изяснен изцяло; без следи остават въпроси и така го пишем в доклада. Не даваме правни консултации и изявления за отговорност или застрахователна защита. Целта ни е ясен край: работим по инцидента, докато той бъде приключен и документиран.
Често задавани въпроси
Каква е разликата между Incident Response и ИТ форензика?
Incident Response има за цел да ограничи инцидента и да възстанови работата по сигурен начин. ИТ форензиката изяснява детайлно и с доказателствена стойност какво се е случило. На практика двете се преплитат, а форензиката често запазва следите паралелно.
Кога да привлека доставчик на услуги за Incident Response?
Веднага щом има съмнение, че атакуващ е имал достъп до системи и не можете да прецените сигурно мащаба. Колкото по-рано започне запазването на следите, толкова повече може да се докаже по-късно.
Кой взема решенията по време на инцидента?
Решенията вземате Вие, например за изключвания, комуникация или уведомявания. Ние подготвяме техническите основи, показваме вариантите с последиците им и изпълняваме решенията.
Трябва ли да уведомя полицията?
Подаването на сигнал в много случаи е разумно и за някои застрахователи е от значение. За това са компетентни Централните звена за контакт по киберпрестъпления (Zentrale Ansprechstellen Cybercrime) на германската полиция. Дали и кога да подадете сигнал, решавате заедно с Вашия адвокат.