В декабре принято публиковать разные итоговые обзоры и топы событий. Мы тоже решили составить свой топ, на основе практики расследований и реагирований на инциденты в 2024 году: НЕлучшие практики во время инцидента. Избегание этих ошибок сильно поможет и пострадавшим, и тем, кто будет расследовать.
(1) Использование потенциально скомпрометированных каналов связи.
Не спешите писать про инцидент в корпоративных каналах коммуникации (пока эта информация не стала общедоступной). Если злоумышленники могут читать вашу почту с перепиской про расследование, они будут на шаг впереди.
Это касается и мессенджера Telegram, клиент которого может быть установлен на рабочей машине в скомпрометированном домене. Даже если вы твёрдо уверены, что вашу телегу не читают, это ещё не значит, что злоумышленники не читают телеги всех 30+ человек из чата по инциденту.
Вообще, делиться данными по своим инцидентам – очень полезная практика для сообщества. Но лучше делать это после, а не время расследования.
(2) Поспешное удаление вредоносного ПО.
«Наш инцидент – это зловредный файл на компьютере. Удалили файл – забороли инцидент». Ошибочная логика. Вредонос конечно заслуживает наказания, но для начала нужно восстановить хронологию событий: как он попал в инфраструктуру, что он там делал, есть ли вредоносное ПО на других хостах сети.
Потому что инцидент ещё не исперчен: заметив потерю коннекта к одному вредносу, злоумышленники могут подключиться через другой. И даже если вы удалили все обнаруженные вредоносы, атакующие уже могли собрать креды – и теперь могут подключаться к вам по штатным каналам - RDP, VPN...
(3) Слишком быстрое восстановление бизнес-процессов.
Конечно, всем хочется поскорее вернуться в строй. Однако необходимо собрать артефакты: файлы, журналы и другие данные для расследования. Не знаете, что это? Снимите побитовую копию (FTK Imager, dd). Не сделали? Скорее всего придётся показывать эффективность в восстановлении бизнеса ещё раз, как минимум.
Поспешная переустановка поломанных систем – типичная ситуация, при которой уничтожаются артефакты, что мешает восстановлению картины инцидента.
Ещё более неприятные последствия влечёт за собой поспешное восстановление из бекапов, которые уже были скомпрометированы на момент создания (что было подтверждено много раз в инцидентах этого года). Бэкап может быть заражён, в нём могут быть те же уязвимости, которые ранее использовал злоумышленник, или старые пароли, которые не сменили. Если вы будете восстанавливаться до того, как выяснили детали инцидента – вы просто дадите атакующим инфру под повторное злодеяние (например, вас снова зашифруют).
(4) Непредсказуемое выполнение рекомендаций специалистов по реагированию.
Например, просьба выключить всю коммуникацию между внутренними корпоративными сетями и внешними сетями может подразумевать множество действий (отключить пользователей, отключить онлайн-сервисы организации, отключить удаленный доступ админов, подрядчиков и т.д.). Клиенты могут понять задачу по-разному – и выполнить только часть этих действий.
Плохо сформулирована рекомендация? Потребуйте переформулировать. Нет компетенций выполнить рекомендации? Попросите инструкцию. Нет времени? Попросите помощи. Не откладывайте в долгий ящик – он не такой уж долгий.
(5) Проведение пентеста для купирования инцидента попыткой обнаружить "путь" злоумышленника.
Пентест может внести много дополнительного шума (детекты СЗИ; файлы/персистенс и т.д.) и затереть полезные артефакты. Поэтому лучше сделайте расследование инцидента вместо анализа защищенности во время инцидента.
(1) Использование потенциально скомпрометированных каналов связи.
Не спешите писать про инцидент в корпоративных каналах коммуникации (пока эта информация не стала общедоступной). Если злоумышленники могут читать вашу почту с перепиской про расследование, они будут на шаг впереди.
Это касается и мессенджера Telegram, клиент которого может быть установлен на рабочей машине в скомпрометированном домене. Даже если вы твёрдо уверены, что вашу телегу не читают, это ещё не значит, что злоумышленники не читают телеги всех 30+ человек из чата по инциденту.
Вообще, делиться данными по своим инцидентам – очень полезная практика для сообщества. Но лучше делать это после, а не время расследования.
(2) Поспешное удаление вредоносного ПО.
«Наш инцидент – это зловредный файл на компьютере. Удалили файл – забороли инцидент». Ошибочная логика. Вредонос конечно заслуживает наказания, но для начала нужно восстановить хронологию событий: как он попал в инфраструктуру, что он там делал, есть ли вредоносное ПО на других хостах сети.
Потому что инцидент ещё не исперчен: заметив потерю коннекта к одному вредносу, злоумышленники могут подключиться через другой. И даже если вы удалили все обнаруженные вредоносы, атакующие уже могли собрать креды – и теперь могут подключаться к вам по штатным каналам - RDP, VPN...
(3) Слишком быстрое восстановление бизнес-процессов.
Конечно, всем хочется поскорее вернуться в строй. Однако необходимо собрать артефакты: файлы, журналы и другие данные для расследования. Не знаете, что это? Снимите побитовую копию (FTK Imager, dd). Не сделали? Скорее всего придётся показывать эффективность в восстановлении бизнеса ещё раз, как минимум.
Поспешная переустановка поломанных систем – типичная ситуация, при которой уничтожаются артефакты, что мешает восстановлению картины инцидента.
Ещё более неприятные последствия влечёт за собой поспешное восстановление из бекапов, которые уже были скомпрометированы на момент создания (что было подтверждено много раз в инцидентах этого года). Бэкап может быть заражён, в нём могут быть те же уязвимости, которые ранее использовал злоумышленник, или старые пароли, которые не сменили. Если вы будете восстанавливаться до того, как выяснили детали инцидента – вы просто дадите атакующим инфру под повторное злодеяние (например, вас снова зашифруют).
(4) Непредсказуемое выполнение рекомендаций специалистов по реагированию.
Например, просьба выключить всю коммуникацию между внутренними корпоративными сетями и внешними сетями может подразумевать множество действий (отключить пользователей, отключить онлайн-сервисы организации, отключить удаленный доступ админов, подрядчиков и т.д.). Клиенты могут понять задачу по-разному – и выполнить только часть этих действий.
Плохо сформулирована рекомендация? Потребуйте переформулировать. Нет компетенций выполнить рекомендации? Попросите инструкцию. Нет времени? Попросите помощи. Не откладывайте в долгий ящик – он не такой уж долгий.
(5) Проведение пентеста для купирования инцидента попыткой обнаружить "путь" злоумышленника.
Пентест может внести много дополнительного шума (детекты СЗИ; файлы/персистенс и т.д.) и затереть полезные артефакты. Поэтому лучше сделайте расследование инцидента вместо анализа защищенности во время инцидента.