Ошибки при реагировании на инциденты
Вы сисадмин, безопасник или просто разраб. Вас похекали, закидали фишинговым спамом и вымогают лавандос, как действовать чтобы не потерять контроль над ситуацией?
Ошибки при реагировании на инциденты и рекомендации к действиям.
Цель злоумышленников использовать полученный доступ.
Если ваша информация появилась в открытом доступе, это может лишь означать, что:
У них есть 100% способ вернуться.
Они хотят, чтобы служба ИТ запаниковала и совершила ошибку.
Они не могут проникнуть глубже.
Вывод:
Контроль и самообладание. (холодное сердце и твёрдый разум предотвратят ошибки)
Ошибка 2. Отсутствие инвентаризации хостов в сети компании
Знай свою инфру. (многие не знают свою инфру и все точки входа, нет перечня разрешенного и запрещенного софта и ОС)
Ошибка 3. Отсутствие регламента
Чтобы не паниковать, нужно заранее знать какие действия проводить:
Смоделировать последовательность действий в случае инцидента.
Описать их в регламенте и внедрить его в практику.
Провести учения.
Ошибка 4. Инстинктивная реакция
Любая реакция на стресс из набора "бей, замри или беги" неправильная, потому что инстинктивная.
Потребность злоумышленника - рычаг управления им. (Если знаешь чего хочет злоумышленник, то можешь этим манипулировать, выигрывать время, помогать совершать ошибки злоумышленнику, давать ошибиться)
Сначала думай, потом делай. (любое действие должно сопровождаться предварительным анализом)
Принимай решение - сознательно.
Делать бэкапы и хранить их на отдельном изолированном сервере.
Не сносить срочно. Отключить от сети хост/сервер чтобы не было последствий.
Регламент в помощь. Проделать благодаря регламенту, после докладывать об инциденте.
За полгода до инцидента согласовать стоимость простоя, стоимость работоспособности системы, бизнес values, знать окно возможностей.
Должно быть заранее в цифрах, начальству нравятся доллары, евро, рубли.
Получен доступ к файловым хранилищам и коммутационному оборудованию.
Слабые пароли на базы данных + никакой доказательной базы вредоносной активности
Вывод: либо злоумышленник не получил доступ в локальную сеть;
либо в утечке замешан внутренний инсайдер.
Ошибка 5. Поспешное лечение симптомов без анализа причин.
Сервер MS Exchange Outlook выведен из строя.
Сотрудники организации удалили с сервера роль почтового сервера Exhange
Журналы событий успели перезаписаться
Результат: серьезное усложнение расследование инцидента
Ошибка 6. Не устанавливать обновления
Служба ИТ. Все необходимые обновления установлены на сервер и находятся в актуальном состоянии.
Найти в shodan внешний ip-адрес сервера, проверить наличие на нем множества уязвимостей.
Выполнить внутри локальной сети сканирование на уязвимости с помощью nessus.
Устанавливать обновления Windows для закрытия уязвимостей.
Злоумышленники не получили доступ к файловой системе сервера и не скопировали базу.
Изучение логов web-сервера IIS.
Обнаружена успешная продолжительная атака на web-сервер owa.
Злоумышленники могут получить доступ к почтовой переписки путем SSRF-атаки.
Расследование SSRF-атаки - собираем итоги:
Отсутствие обновлений = уязвимости сервера Exchange
Информация об этом в базе shodan
+ эксплойт на github https://github.com/Jumbo-WJB/Exchange_SSRF/blob/main/exchange_ssrf_attacks.py
Прежде чем работать с инцидентами надо их как то замечать, находить и классифицировать. Вот это реально то что вы можете сделать.
Смысл в том что сделать пару экранов и мониторить что у вас происходит.
Вычленять что у вас происходит, это максимум самого полезного и эффективного то что вы можете сами делать.
Все зависит от ситуации и от контекста!
Обратите внимание к защите сетевой инфраструктуры, до взлома чтобы вам потом это не аукнулось!