Вопрос разработки и приготовления плейбуков по реагированию на инциденты сейчас очень активно обсуждается и порождает разное количество подходов, поиск баланса в которых крайне важен. Должен ли плейбук быть очень простым («выдернуть шнур, выдавить стекло») или должен давать возможность оператору подумать и принять решение на основании собственной экспертизы (хотя, как говорили в одной игре моего детства, «что тут думать – дергать надо»). За наплывом модных аббревиатур и системных рекомендаций достаточно сложно найти соль и серебряную пулю. Мы за 8 лет работы нашего центра мониторинга и реагирования на кибератаки успели наломать немало дров приобрести некоторый опыт в этом вопросе, поэтому постараемся поделиться с вами граблями и подводными камнями, которые встречались нам на этом пути, в 5 практических советах по вопросу.

Навыки синхронного плавания, или Выравнивание задач мониторинга и реагирования

Как известно, самым быстрым животным на свете должна быть сороконожка: у нее больше всех ног. Но бедному животному уж очень мешает потребность синхронизации своих шагов и активностей. Аналогичная история зачастую преследует жизнь SOC (Security Operation Center). Аналитики разрабатывают сценарии, морщат лоб, придумывает новые способы выявления атак, а со стороны команды реагирования зачастую нет понимания, что с этими инцидентами делать (и дистанция растет, если на первой линии баррикад стоит внешний коммерческий SOC). Такое положение дел обычно приводит к двум крайним ситуациям:

• Со стороны команды реагирования внутренний SLA формулируется в терминах «нет времени объяснять, просто реагируй», а каждый инцидент, фиксируемый в SOC, считается критичным. В итоге под потоком атомарных инцидентов совокупная активность действительно слегка напоминает эту самую сороконожку, которая очень спешит и стремится прибежать к финишу первой, но из-за обилия кочек и собственных ног начинает просто путаться в происходящем.
• Процесс реагирования происходит интуитивно – из потока инцидентов от команды мониторинга просто выхватываются произвольные «интересные» события. И, как правило, чутье команду реагирования не обманывает достаточно долго. Пока не случается очередная проверка в виде теста на проникновение или, хуже, настоящая атака. Почему-то именно в этот момент те три-четыре уведомления, которые зафиксированы SOC в скрытной деятельности настоящих или мнимых злоумышленников, оказываются незамеченными командой реагирования. Вроде бы и пули вылетели, и критичность подсвечена, а результата не последовало.

Помните мудрого Инь Фу Во, который вопрошал своего ученика, покупающего сканер защищенности, что же он потом будет делать с найденными уязвимостями? Следуя его примеру, очень хочется задать вопрос команде реагирования: а что именно и, главное, с какой скоростью вы будете делать с найденными инцидентами?

Возможности процесса реагирования позволяют «разлиновать» список инцидентов исходя из их внутренней критичности. Например, коммуникации по критичным изменениям процессов или атакам на веб логично перевести в режим телефонного звонка с немедленным сбором группы расследования. Для обработки запуска TeamViewer на некритичных машинах филиалов адекватным вариантом будет разбор в течение пары часов. А отчет по статистике вирусных заражений вполне допустимо «подавать» раз в день – к утреннему кофе и «ковровому» закрытию проблем, когда как раз и происходит массовое лечение вирусов, удаление запрещенного ПО, обновление ОС, закрытие уязвимостей и т.д. Это поможет существенно выровнять темпы работы мониторинга и реагирования и создать бесшовные и комфортные правила игры в рамках всего процесса управления инцидентами.

Совет 1. Выставьте приоритеты. Поскольку заниматься всем и сразу вы точно не сможете, определите, какие типы инцидентов действительно критичны для бизнеса вашей компании, и зафиксируйте требуемые сроки их решения.

Аналитика, аналитика, еще больше аналитики по инциденту

Многие коммерческие SOC, да и команды, разрабатывающие сценарии, очень часто и всерьез рассказывают о невероятных процентах фильтрации ложных срабатываний, за счет чего заказчиков уведомляют якобы не о подозрениях на инциденты, а только об атаках (как говорится, «Во всем мне хочется дойти до самой сути»).

Периодически это порождает удивительные процессы по анализу и расследованию инцидентов, например, такие:

• На основании анализа сетевого трафика SOC зафиксировал запуск Remote Admin Tools (RAT) на хосте.
• В результате анализа удалось выяснить, под какой учетной записью сейчас ведется работа на машине. Следующая задача – идентифицировать, был ли запуск RAT работой пользователя (тогда это просто нарушение политики ИБ) или он был запущен ВПО, заразившим хост как канал связи с центром управления.
• Для дальнейшей верификации и анализа инцидента заказчик просит подключить данный хост на уровне локальных логов и провести анализ всех событий в «окрестности инцидента». При этом отказывается от постоянного подключения всех серверов и рабочих станций к SIEM в целях экономии лицензий.

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

Главное же – с точки зрения результата весь этот сложный процесс проверки со стороны SOC и службы безопасности просто эквивалентен поднятию телефонной трубки и звонку конкретному пользователю с вопросом, он ли инициировал сессию RAT и по какой причине. В результате и сам ответ может быть получен многократно быстрее, и общее время, затраченное на расследование инцидента, сократится в разы. С учетом того, что запуск RAT на локальной машине в 98% процентах случаев – дело рук пользователя (что делает только более значимыми оставшиеся 2%), такой подход к реагированию гораздо эффективнее.

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

Не инцидент красит место, а место – инцидент

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

Рассмотрим достаточно базовый инцидент – вирусное заражение хоста. Он имеет совершенно разный вес и критичность в зависимости от того, где этот хост находится:

• для рядового АРМ сотрудника – тайминг и сроки разбора инцидента могут быть достаточно неспешными, особенно если речь идет об известном и успешно вылеченном ВПО;
• для АРМ критичного или VIP-пользователя, как правило, проводится уже более детальный анализ – как минимум последующая проверка хоста на вирусы и экстренное обновление антивирусных баз;
• для серверного сегмента имеет смысл запустить полноценное расследование и выяснить путь и причины заражения хоста.

Еще большего внимания требуют процессы реагирования в компаниях промышленного цикла. Тот же инцидент с запуском RAT на машине приобретает совершенно другие акценты и критичность в случае, если такая утилита запускается там, где по логике ее быть не может – например, на АРМ оператора технологического процесса. В этом случае мера реагирования по умолчанию – отключение и изоляция хоста с последующим выяснением причин запуска утилиты и возможным детальным анализом хоста на признаки потенциальной компрометации внешним злоумышленником.

Совет 3. Проводите инвентаризацию активов. «Наложите» различные классы инцидентов на сегменты сети. Таким образом вы получите уже не линейную модель, где уровень критичности инцидента определяется исключительно его типом, а кастомизированную под вашу организацию базовую матрицу, которую со временем можно будет совершенствовать и уточнять.

Реальное реагирование vs идеальное реагирование

Описанная выше ситуация подсвечивает ключевой вопрос: насколько глубокое реагирование готова проводить внутренняя команда для гарантированной ликвидации последствий и причин возникновения инцидента? Вернемся к примеру с заражением машины ВПО – процесс реагирования может выглядеть следующим образом:

• Анализ канала проникновения ВПО (почта/веб/флешка)
• Получение информации о самом ВПО – какое семейство, потенциальные последствия, наличие связанных утилит
• Выявление индикаторов компрометации, характерных для данного ВПО, поиск индикаторов на соседних машинах (это особенно актуально, когда нет полного покрытия АРМ и серверов антивирусной защитой и ВПО может успешно внедриться в один из непокрытых хостов)
• Поиск всех связанных утилит в инфраструктуре и ликвидация последствий

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

• Уже упоминаемой выше модели активов и их критичности
• Характера поведения вредоносного семейства — черви, особенно несущие потенциально деструктивную нагрузку, требуют большего внимания
• «Старости» вируса и его известности антивирусным лабораториям
• Принадлежности его к инструментарию группировки, актуальной для компании или отрасли

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

Совет 4. Не ленитесь «заточить топор». Дополнительные условия позволяют уточнить приоритет и алгоритм действия в ходе реагирования на инцидент. Они позволяют не только более полно выполнять все необходимые работы по локализации инцидента и противодействию атаке, но и избежать лишних движений в более простых случаях.

Скажи мне, кто твой друг, и я скажу, как быть

Ну и немаловажным в разработке плейбуков, безусловно, является глубина экспертизы со стороны команды реагирования. На старте нашей работы как коммерческого SOC вся наша коммуникация строилась через выделенного человека в ИБ-службе заказчика. В этом случае мы говорили о сотруднике, пусть даже и молодом студенте, с профильным образованием, который из раза в раз реагируя на различные инциденты, накапливает собственную экспертизу и делает свою работу все более эффективно.

Мы условно можем разделить плейбуки на два типа – технический и бизнесовый. В первом описывается технологическая цепочка при работе с инцидентом, и он создается для группы реагирования со стороны уважаемого заказчика. А второй представляет собой описание цепочки вовлеченных в инцидент подразделений, и его потребителем является скорее линейный менеджмент. Соответственно, очень важно «знать свою аудиторию», иначе возникнут «трудности перевода», связанные с пониманием и трактовкой.

В последнее время заказчики все чаще включают напрямую в процесс реагирования ИТ-подразделения, бизнес-подразделения, технологов или даже службы helpdesk. И это нередко приводит к казусам. В начале пандемии несколько заказчиков неожиданно для себя вынуждены были (как и вся страна) массово перевести своих пользователей на удаленный доступ. Поскольку быстро внедрить второй фактор аутентификации не получалось, в качестве временной схемы было согласовано следующее: каждое удаленное привилегированное подключение служба helpdesk верифицировала через телефонный звонок. В случае отсутствия обратной связи вопрос эскалировался на бизнес-владельца системы, который мог принять решение о продолжении работ или блокировке учетной записи до выяснения обстоятельств – в случае подозрения на несогласованную активность. В плейбуке для helpdesk мы максимально подробно расписали процедуры звонков и поиска контактов бизнес-владельца. Но не написали, что нужно делать сотруднику helpdesk при получении команды на блокировку учетной записи (а такие права у службы были). И первый же тестовый прогон инцидента показал, что, получив письмо с сообщением «нелегитимно, блокировка», специалист helpdesk просто закрывал заявку, не проводя никакой блокировки.

Совет 5. Keep it simple. Крайне важно учитывать особенности квалификации и «текучесть» ресурсов в команде реагирования и декомпозировать плейбук от базовой инструкции со степенями свободы для специалиста до пошаговой «азбуки» для внешних служб.

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