280 подписчиков

5 примеров реагирования на инциденты. Разбор кейсов

9 минут

526 прочтений

1 декабря 2022

В теории все мы умеем распознавать инсульт, делать искусственное дыхание и четко и правильно реагировать на любой инцидент информационной безопасности.

На практике всё гораздо сложнее:

Проявляются факторы внезапности;
Инцидент может развиваться непредсказуемо, вопреки продуманному заранее сценарию
Приоритеты бизнеса в кризисной ситуации могут поменяться и сделать готовый план бесполезным;
В условиях нехватки времени и паники тщательно продуманные и подробные планы попросту забываются.

Этот эфир ток-шоу Код ИБ | БЕЗОПАСНАЯ СРЕДА провели в необычном формате и обсудили сценарии реагирования на 5 различных инцидентов ИБ:

Обнаружение вредоносного ПО на рабочей станции
Фишинговая атака на сотрудников
Брутфорс
DDoS-атака
Заражение шифровальщиком

Что из этих пяти типов атак является наиболее «популярным»?

Начиная с февраля участились случаи DDoS-атак. Со временем они стали более целенаправленными, и злоумышленники переключились на фишинг, обращенный против конкретных компаний.

Как ни удивительно, но общее число фишинговых атак за последнее время существенно снизилось. Это связано с тем, что основная масса атак была направлена на получение сведений, которые помогут украсть денежные средства, причем исходили эти атаки из-за границы, из стран бывшего СССР. После частичного отключения РФ от финансовой системы (в частности, SWIFT) перевод денежных средств стал технически трудным.

Однако число целевых атак на инфраструктуру компаний возросло. Также появились отдельные типы шифровальщиков, достаточно специфичные, направленные именно на пользователей из РФ и русскоязычных пользователей. Примечателен случай, когда фишинговое письмо с темой «на подпись руководителю» пересылалось более 7 раз внутри компании, пока не дошло до целевого адресата.

За последние полгода на РФ свалился вал утечек личных данных. Повлияло ли это на модель фишинговых атак? Пока скорее нет, поскольку утекает информация достаточно широкого профиля. Однако после восстановления доступа к мировой банковской системе платежей этот фактор может еще проявиться в полной мере. На целевые атаки это влияет мало, поскольку обычно это дает мало информации злоумышленнику, например, о структуре компании.

Заражение вредоносным ПО – это следующая стадия либо после удачного взлома, либо фишинговой атаки. Просто так вирус в инфраструктуру попадает редко (только если это не древняя Windows с торчащими в интернет уязвимыми SMB или RDP), поэтому как правило такое заражение сопровождается успешно проведенным взломом или фишингом.

Из атак на WEB-сервисы по-прежнему самой популярной является XSS.

Брутфорс

Представим ситуацию: утро техподдержки в офисе компании начинается со звонка пользователя о том, что не работает доступ по RDP. Пока системный администратор пытается разобраться с проблемой, ему поступает еще один звонок, потом еще и еще, и в течение короткого времени техподдержку заваливают жалобами на то, что пользователи не могут зайти на удаленный рабочий стол.

Что случилось? Очевидно, что речь идет о брутфорсе. На терминальные серверы массово посыпались попытки авторизации, и после нескольких неудачных попыток происходит блокирование пользователя. Через 30 минут учетки разблокируются, но эти 30 минут пользователь работать не может. Затем учетка блокируется вновь. Ситуация осложнятся тем, что из соображений безопасности системные администраторы напрямую не могут подключиться удаленно, поскольку входят в группу protected users. В итоге системным администраторам приходится ехать в офис и исправлять ситуацию локально. Этот случай – пример не до конца продуманной настройки политик безопасности и того, к чему может привести выставление RDP-сервера наружу в интернет.

Одной из ошибок реагирования было то, что системный администратор, который уже на тот момент был в системе и мог разблокировать учетки удаленно, решил проверить, что происходит и попробовал залогиниться снова, что у него, конечно же, не получилось.

Другой кейс – злоумышленники получили брутфорсом удаленный доступ к инфраструктуре компании с административными правами. Причиной этому послужило, во-первых, то, что консоль с правами администратора «смотрела» в интернет, во-вторых, сотрудник решил проверить надежность своего пароля с помощью сервиса checkmypassword и, вероятно, скомпрометировал его при этом, в-третьих, пароль не менялся более двух лет и мог быть подобран за это время, в-четвертых, пароль был достаточно слабым.

На сервисе Wikisec представлен бесплатный комплекс по выявлению слабых паролей в домене. Но как заставить пользователей поменять пароли, которые были расценены как слабые? Для этих учеток можно поставить срок действия пароля в 3 дня и так заставить пользователя его сменить.

Как можно автоматизировать распознавание и реагирование на bruteforce-атаки?

Выгрузка информации об инциденте из SIEM-системы и обогащение данными. Кто-то под учеткой пользователя попробовал залогиниться несколько раз неудачно. Инцидент имеет массовый характер?
Анализ контекста. Сервисная активность? Старый пароль?
Блокировка подозрительной активности в зависимости от контекста (например, с помощью SOAR-платформы).
Создание задач в Helpdesk по реагированию.
Подготовка отчетов.
Повторные проверки.

Шифровальщик

Шифровальщики примечательны тем, что им для работы не обязательно выходить за контекст допустимых прав пользователя: всё что он делает, он может делать и в рамках политик допустимого использования в компании. Шифрование производится от имени пользователя, как если бы это делал сам пользователь. Для того, чтобы вовремя выявлять его действия, приходится придумывать дополнительные, порой весьма изощренные критерии, иногда с использованием искусственного интеллекта.

Итак, сценарий достаточно типичный: у работников бухгалтерии на экране появляется сообщение о том, что «файлы зашифрованы, не предпринимайте ничего, обратитесь в службу безопасности, которые будут заниматься оплатой дешифровщика».

Пути проникновения шифровальщиков в инфраструктуру обычно идут через почту с прикрепленным файлом (word, pdf, xls, архивы с длинными именами), которые пользователи открывают и запускают не глядя.

Каков же алгоритм действий в этой ситуации?

Для предотвращения такой ситуации в первую очередь помогают резервные копии (главное, чтобы они не оказались зашифрованными вместе со всем остальным), запрет запуска исполняемых файлов из определенных директорий (например, /tmp), настройки антивируса.

Если инцидент уже случился, то необходимо:

Понять, что происходит
Оценить инцидент, классифицировать его
Сообщить в службу IT или ИБ

Очень важно знать, кому следует сообщать об инциденте, а кому нет. Реакция на инцидент может быть неадекватной, вопросом должны заниматься специалисты и важно предотвратить развитие паники.

Никаких четких алгоритмов реагирования на инциденты не бывает. Всегда есть варианты, как делать то или иное действие: как оценить инцидент, определить его границы и глубину, выявить файлы, которые относятся к шифровальщику, и которые были зашифрованы, продолжается ли шифрование, было ли шифрование в принципе, как его можно остановить. Только после этого алгоритм действий становится более или менее очевидным: что, как и сколько восстанавливать, как предотвратить повторное появление, поиск расшифровщика, стоит ли вести переговоры с вымогателями.

Конкретные действия очень сильно зависят от размеров и квалификации штата сотрудников, инфраструктуры, бизнес-процессов.

Реагирование на инцидент при работе шифровальщика со стороны IT:

первое что должен сделать СА – начать отсекать сегменты. Даже физически, если в этом есть необходимость. Потребуется дамп памяти для расследования, поэтому выключать зараженные ПК не стоит. Первоочередная задача – предотвратить распространение вируса по сети.
необходимо понять, в каком сегменте сети находился компьютер. Из этого можно понять охват проблемы, определив, куда у зараженного компьютера был доступ. Если это сегмент с серверными ресурсами, то это приоритет номер 1, необходимо запустить проверку антивируса на серверах для того, чтобы их защитить максимально возможным способом.
и только после этого разбираться с пользователями и проводить расследование.

Фишинговая атака

Ситуация: сотруднику на почту пришел архив, содержащий вирус, либо ссылку на фишинговую страницу авторизации, и сотрудник ввел учетные данные туда (например, outlook).

Что нужно сделать, если сотрудник попался и ввел учетные данные?

первая задача – как сотрудник поймет, что он попался на уловку? Необходимо выявлять это, например, в случае использования MFA фиксировать неудачные попытки аутентификации и инициировать смену пароля;
фиксированный IP-адрес клиентов – тоже возможное решение, но требует постоянного обслуживания и обновления баз разрешенных адресов;
готовить пользователей, чтобы они сообщали в поддержку о подозрительных письмах;
анализ письма и проверка информации, анализ ссылок и файлов в песочницах. Если подтверждается вредонос, во выявляются IOC и они распространяются по средствам защиты;
анализ, кому попало письмо и кто его открыл. У тех, кто не успел открыть, письмо просто удаляется, и остальных запускается антивирусная проверка;
если есть средства мониторинга или SOC – то по сообщениям средств реагирования изоляция отдельных сегментов либо блокировка учетных записей.

Автоматизировать такой процесс помогут SOAR-системы:

Анализ письма (выделение темы, содержимого, текста и ссылок)
Поиск и анализ подробностей (проверка отправителя, домена, вложений и ссылок)
Поиск похожих: поиск других получателей письма
Блокировка: добавление отправителя и домена в черный список
Очистка сервера от опасных писем или вложений
Проверка хостов: запуск проверки на рабочих станциях пользователей
Оповещение.

С использованием средств автоматизации весь этот процесс может занимать чуть более часа. Это достигается путем интеграции SOAR c внешними системами. Но это доступно только для компаний с высоким уровнем автоматизации процессов.

Один из наиболее доступных и дешевых способов предотвращения инцидентов с фишингом – проведение регулярных учений, особенно при невысоком уровне технологической и организационной оснащенности.

Вредоносное ПО на рабочей станции

В первую очередь желательно минимизировать частоту ложноположительных срабатываний.
Если антивирус удалил вредонос, то все равно желательно запустить после этого полную проверку рабочей станции.
Провести расследование или как минимум опрос пользователя, что он делал в тот момент и почему.

С точки зрения вредоносного ПО очень важно классифицировать, на что именно служба безопасности должна именно реагировать. Просто событий ИБ обычно до 98%, например, блокировка вредоносных ссылок. В любом случае, события должны быть классифицированы и определен порядок отработки инцидентов.

Как можно управлять процессом реагирования на инциденты? Как правило, это делается путем интеграции со сторонними системами управления задачами.