На старте сервиса по мониторингу и реагированию на киберинциденты у нас было довольно странное деление на две линии аналитики: не только и не столько по уровню экспертизы, сколько по направленности решаемых задач. Была первая линия, которая занималась мониторингом и расследованием инцидентов ИБ. И все остальные – “просто аналитики”, в чьи обязанности входило углубленное расследование инцидентов за рамками типового процесса и SLA, создание правил детектирования новых угроз, а также плотная работа с заказчиком (анализ общего уровня защищенности, проработка максимально эффективного пула сценариев для покрытия модели угроз, подключение новых источников, проработка необходимого уровня аудита, написание парсеров/коннекторов и т.д.).
Мы сознательно не строили многоуровневую линейную модель эскалации расследования инцидентов по линиям 1->2->3-> и т.д. Наверное, просто потому, что не смогли придумать, как уложить подобную парадигму расследования в экстремально короткий SLA на решение инцидентов (0,5–2 часа), причем 30 минут на разбор инцидента далеко не редкость, такие кейсы составляют значимую долю в общем потоке.
То есть по большому счету линия обработки инцидентов была одна – первая, она же и последняя. К ней предъявлялись требования по полному расследованию всего пула типовых инцидентов в рамках типового шаблона уведомлений. И эта схема работала вполне себе хорошо. До той поры, пока не заказчиков не стало больше. Это привело к необходимости масштабировать ресурсы и параллельно выполнять взаимоисключающие требования разных заказчиков. Одни говорили, что им нужны более глубокие расследования и вопрос тайминга вторичен, другие хотели максимально быстрых уведомлений об инцидентах, пусть даже с неполной информацией на начальном этапе.
Молодые инженеры после стажировки не могли равномерно выдавать качество и скорость расследования, как их более опытные коллеги. Плюс по некоторым заказчикам у нас накопился пул инцидентов с более высокими требованиями к глубине расследования и рассматриваемой дельте-окрестности, что было “по зубам” только части инженеров.
Это послужило отправной точкой формирования команды “углубленного расследования”, которая работала с общим пулом инцидентов, но фокусировалась на расследовании сложных случаев, которые, однако, были сильно недетерминированы. По этим причинам ее нельзя было назвать полноценной второй линией.
Вполне возможно, в такой парадигме мы бы и жили долго и счастливо, если бы не появление второй SIEM. Этот огромный и трудоемкий проект подвел нас к созданию второй линии, так как разбор инцидентов c новой SIEM-платформы требовал балансировки нагрузки на первую линию, которая не могла быстро усвоить навык работы в двух разных решениях. Ну и естественно, никуда не делась необходимость “углубленного расследования” инженерами новой, теперь уже по-честному второй линии. Но этот признак был все так же недетерминирован и требовал ручной обработки первой линией для принятия решения по каждому тикету. Это создавало ровно тот самый оверхед и рост таймингов, от которых мы стремились уйти.
Дополнительной сложностью стал рост нагрузки на первую линию из-за того, что трудоемкость расследования инцидентов на второй SIEM была более высокой. Как следствие – инженеры второй линии успевали решать уже меньшее число инцидентов, чем в те времена, когда линия была одна и инструментарий был един.
Тем временем, клиенты все чаще требовали раннего информирования – чтобы информация о подозрении на инцидент направлялась им сразу по факту детектирования, а расширенные данные, полученные в ходе расследования, и трудоемкие выгрузки/статистики предоставлялись позднее, в рамках SLA.
Все это, а также звучащая от инженеров линий мысль, что уже очень большая доля инцидентов требует исключительно механической работы – подсказало следующий шаг: реализацию автоматических оповещений.
В пул инцидентов, достойных автоматических оповещений попали:
Для инцидентов 1-го типа был реализован механизм DirectAlert: вся необходимая для реагирования информация агрегируется и обогащается автоматически, автоматически же формируется уведомление в сторону заказчика.
Для инцидентов типа 2 и 3 был реализован механизм Direct&Mon: при подозрении на инцидент для заказчика автоматизированно формируется оповещение с основными метаданными инцидента. После этого формируется тикет на линии аналитики для дорасследования, формирования аналитических справок и выгрузок/отчетов.
Что это дало:
Принцип маршрутизации тикетов на вторую линию мы впоследствии, естественно, изменили, об этом как раз ниже.
Вспоминая собранные грабли, хочется отдельно рассказать о проблеме сохранения/восстановления исторического контекста при расследовании инцидентов. Ведь согласитесь, одно дело – изолированный инцидент без какой-либо предыстории и совсем другое – случай с хостом или учеткой, которые недавно светились в других инцидентах. И если в первом варианте речь, скорее всего, идет просто о нарушении политик ИБ компании, зачастую непреднамеренном, то второй – с достаточно высокой вероятностью может свидетельствовать о целенаправленном вредоносном воздействии на информационные системы. И тут далеко не лишним будет подсветить всю цепочку инцидентов как самому заказчику, так и закрепленным за ним сервис-менеджеру и аналитику TIER-4. Но как это сделать, если первый инцидент цепочки расследовал один инженер, второй инцидент – другой (возможно, даже из другого регионального филиала), а последний инцидент – третий инженер в ночную смену после пересменки?
Даже когда структура Solar JSOC не была такой развесистой и расследование инцидентов было сосредоточено в нижегородском подразделении, мы сталкивались с тем, что при передаче смен теряется некий общий контекст линии. Из-за этого расследование вновь приходящих инцидентов происходит без учета предыдущих – не встречалась ли эта учетка недавно, не светился ли этот хост как источник сканирования и т.д.
Пентесты у наших заказчиков проявили эту проблему во всей красе. Было очень обидно, когда, отлично расследовав несколько инцидентов днем и несколько ночью, мы не смогли их связать воедино. А все потому, что не было возможности показать контекст связанных инцидентов ночному инженеру, расследующему, как потом выяснилось, развитие пентеста.
Проблема потери контекста при пересменке проявилась сразу после запуска 24х7, но до поры до времени не была очень острой. С увеличением же числа инженеров линий, а уж тем более с появлением новых региональных подразделений она потребовала скорейшего решения. Потому что контекст стал теряться не только при пересменках – просто с ростом команды вероятность того, что каждый из цепочки неизолированных инцидентов попадет в руки одного инженера и тот при расследовании вспомнит предысторию, стремится к нулю.
По привычке пропустив первый из «проклятых русских вопросов», мы сосредоточились на втором – “что делать?”
При разработке контента SIEM мы стараемся не создавать слишком длинных цепочек правил, поскольку наш опыт говорит об их малой эффективности в детектировании инцидентов. Мысли о реализации сложных сценариев, учитывающих глубокую ретроспективу были признаны бесперспективными, да и не получится создать сценарии на всю возможную вариативность сочетаний.
Тем не менее это не помешало нашему стремлению посмотреть на инциденты в ретроспективе и склеить их в некий killchain. Логика склейки была реализована в нашем сервис-деске, работы с инцидентами – в kayako.
Механизм анализирует ретроспективу сработок инцидентов заказчика в разных временных окнах и в случае нахождения инцидентов с ключевыми полями, соответствующими рассматриваемому инциденту, – выводит основную информацию и ссылку на него в тикет. Механизм рекурсивный – поиск производится по ключевым полям обнаруженных инцидентов – таким образом формируется дерево вероятных цепочек развития угрозы. Воспринимается сложно, зато выглядит просто и понятно – покажем на примерах.
Инциденты с историческим контекстом в нашем лексиконе называются неизолированными. Инциденты без предыстории – изолированные.
Механизм поиска киллчейна стал также одним из базовых критериев для балансировки тикетов между первой и второй линиями. Изолированный инцидент, в ключевых полях которого не встречаются критичные хосты/сети/учетки (на самом деле критериев много больше, но в данном примере рассмотрим только основные) – скорее всего, не наберет необходимый скоринг, чтобы отправиться на вторую линию, и будет обработан на первой без траты ресурсов на подробное изучение дельта-окрестности инцидента.
В случае неизолированного инцидента вероятность попадания на вторую линию существенно возрастает. А если в предыстории текущего инцидента были обнаружены сработки в рамках короткого временного окна (меньше суток), то этот инцидент – 100-процентный кандидат для рассмотрения на второй линии с обязательным изучением предыстории.
Ну и конечно, здесь предусмотрен механизм фильтрации, поскольку не все склейки одинаково полезны. Разработка и поддержание в актуальном состоянии фильтров под каждого заказчика, разумеется, требует определенных ресурсов со стороны аналитиков, но польза, которую приносит инструментарий склейки цепочек инцидентов, все равно многократно превышает эти затраты.
Такая вот счастливая «перестройка».
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
Мы сознательно не строили многоуровневую линейную модель эскалации расследования инцидентов по линиям 1->2->3-> и т.д. Наверное, просто потому, что не смогли придумать, как уложить подобную парадигму расследования в экстремально короткий SLA на решение инцидентов (0,5–2 часа), причем 30 минут на разбор инцидента далеко не редкость, такие кейсы составляют значимую долю в общем потоке.
То есть по большому счету линия обработки инцидентов была одна – первая, она же и последняя. К ней предъявлялись требования по полному расследованию всего пула типовых инцидентов в рамках типового шаблона уведомлений. И эта схема работала вполне себе хорошо. До той поры, пока не заказчиков не стало больше. Это привело к необходимости масштабировать ресурсы и параллельно выполнять взаимоисключающие требования разных заказчиков. Одни говорили, что им нужны более глубокие расследования и вопрос тайминга вторичен, другие хотели максимально быстрых уведомлений об инцидентах, пусть даже с неполной информацией на начальном этапе.
Молодые инженеры после стажировки не могли равномерно выдавать качество и скорость расследования, как их более опытные коллеги. Плюс по некоторым заказчикам у нас накопился пул инцидентов с более высокими требованиями к глубине расследования и рассматриваемой дельте-окрестности, что было “по зубам” только части инженеров.
Это послужило отправной точкой формирования команды “углубленного расследования”, которая работала с общим пулом инцидентов, но фокусировалась на расследовании сложных случаев, которые, однако, были сильно недетерминированы. По этим причинам ее нельзя было назвать полноценной второй линией.
Вполне возможно, в такой парадигме мы бы и жили долго и счастливо, если бы не появление второй SIEM. Этот огромный и трудоемкий проект подвел нас к созданию второй линии, так как разбор инцидентов c новой SIEM-платформы требовал балансировки нагрузки на первую линию, которая не могла быстро усвоить навык работы в двух разных решениях. Ну и естественно, никуда не делась необходимость “углубленного расследования” инженерами новой, теперь уже по-честному второй линии. Но этот признак был все так же недетерминирован и требовал ручной обработки первой линией для принятия решения по каждому тикету. Это создавало ровно тот самый оверхед и рост таймингов, от которых мы стремились уйти.
Дополнительной сложностью стал рост нагрузки на первую линию из-за того, что трудоемкость расследования инцидентов на второй SIEM была более высокой. Как следствие – инженеры второй линии успевали решать уже меньшее число инцидентов, чем в те времена, когда линия была одна и инструментарий был един.
Тем временем, клиенты все чаще требовали раннего информирования – чтобы информация о подозрении на инцидент направлялась им сразу по факту детектирования, а расширенные данные, полученные в ходе расследования, и трудоемкие выгрузки/статистики предоставлялись позднее, в рамках SLA.
Все это, а также звучащая от инженеров линий мысль, что уже очень большая доля инцидентов требует исключительно механической работы – подсказало следующий шаг: реализацию автоматических оповещений.
В пул инцидентов, достойных автоматических оповещений попали:
- Инциденты, не требующие высокоинтеллектуальной обработки, то есть те, расследование которых укладывается в линейную логику SIEM (в данном случае вся работа инженера представляла собой по большому счету copy-paste полей из SIEM в стандартное оповещение). При этом важно, чтобы инциденты генерировали невысокий процент ложных срабатываний.
- Инциденты с двумя фазами расследования – линейное расследование, как в п.1, и построение трудоемких неавтоматизируемых отчетов.
- Критичные инциденты, по которым заказчик предпочитает получить высокий процент ложных срабатываний, чем отфильтрованную информацию с задержкой.
Для инцидентов 1-го типа был реализован механизм DirectAlert: вся необходимая для реагирования информация агрегируется и обогащается автоматически, автоматически же формируется уведомление в сторону заказчика.
Для инцидентов типа 2 и 3 был реализован механизм Direct&Mon: при подозрении на инцидент для заказчика автоматизированно формируется оповещение с основными метаданными инцидента. После этого формируется тикет на линии аналитики для дорасследования, формирования аналитических справок и выгрузок/отчетов.
Что это дало:
- Порадовали заказчиков, ратовавших за раннее оповещение за счет DirectAlert’ов
- C их же помощью сэкономили часть ресурсов первой линии и добились «морали +30» (уменьшение количества рутины – это важно, согласитесь)
- Увеличили глубину расследования части инцидентов, завернув их на вторую линию обработки
- Встроили вторую SIEM в работу линий аналитики
- Ну и сделали более комфортным и понятным вектор роста аналитика инцидентов ИБ. Все-таки шагать по карьерной лестнице небольшими понятными этапами 1->2->3-> и т.д. комфортнее и доступнее для большинства, чем прыжок в бесконечность, которая разделяла линии аналитики изначально.
Принцип маршрутизации тикетов на вторую линию мы впоследствии, естественно, изменили, об этом как раз ниже.
В поисках исторического контекста: еще немного автоматизации
Вспоминая собранные грабли, хочется отдельно рассказать о проблеме сохранения/восстановления исторического контекста при расследовании инцидентов. Ведь согласитесь, одно дело – изолированный инцидент без какой-либо предыстории и совсем другое – случай с хостом или учеткой, которые недавно светились в других инцидентах. И если в первом варианте речь, скорее всего, идет просто о нарушении политик ИБ компании, зачастую непреднамеренном, то второй – с достаточно высокой вероятностью может свидетельствовать о целенаправленном вредоносном воздействии на информационные системы. И тут далеко не лишним будет подсветить всю цепочку инцидентов как самому заказчику, так и закрепленным за ним сервис-менеджеру и аналитику TIER-4. Но как это сделать, если первый инцидент цепочки расследовал один инженер, второй инцидент – другой (возможно, даже из другого регионального филиала), а последний инцидент – третий инженер в ночную смену после пересменки?
Даже когда структура Solar JSOC не была такой развесистой и расследование инцидентов было сосредоточено в нижегородском подразделении, мы сталкивались с тем, что при передаче смен теряется некий общий контекст линии. Из-за этого расследование вновь приходящих инцидентов происходит без учета предыдущих – не встречалась ли эта учетка недавно, не светился ли этот хост как источник сканирования и т.д.
Пентесты у наших заказчиков проявили эту проблему во всей красе. Было очень обидно, когда, отлично расследовав несколько инцидентов днем и несколько ночью, мы не смогли их связать воедино. А все потому, что не было возможности показать контекст связанных инцидентов ночному инженеру, расследующему, как потом выяснилось, развитие пентеста.
Проблема потери контекста при пересменке проявилась сразу после запуска 24х7, но до поры до времени не была очень острой. С увеличением же числа инженеров линий, а уж тем более с появлением новых региональных подразделений она потребовала скорейшего решения. Потому что контекст стал теряться не только при пересменках – просто с ростом команды вероятность того, что каждый из цепочки неизолированных инцидентов попадет в руки одного инженера и тот при расследовании вспомнит предысторию, стремится к нулю.
По привычке пропустив первый из «проклятых русских вопросов», мы сосредоточились на втором – “что делать?”
При разработке контента SIEM мы стараемся не создавать слишком длинных цепочек правил, поскольку наш опыт говорит об их малой эффективности в детектировании инцидентов. Мысли о реализации сложных сценариев, учитывающих глубокую ретроспективу были признаны бесперспективными, да и не получится создать сценарии на всю возможную вариативность сочетаний.
Тем не менее это не помешало нашему стремлению посмотреть на инциденты в ретроспективе и склеить их в некий killchain. Логика склейки была реализована в нашем сервис-деске, работы с инцидентами – в kayako.
Механизм анализирует ретроспективу сработок инцидентов заказчика в разных временных окнах и в случае нахождения инцидентов с ключевыми полями, соответствующими рассматриваемому инциденту, – выводит основную информацию и ссылку на него в тикет. Механизм рекурсивный – поиск производится по ключевым полям обнаруженных инцидентов – таким образом формируется дерево вероятных цепочек развития угрозы. Воспринимается сложно, зато выглядит просто и понятно – покажем на примерах.
Инциденты с историческим контекстом в нашем лексиконе называются неизолированными. Инциденты без предыстории – изолированные.
Механизм поиска киллчейна стал также одним из базовых критериев для балансировки тикетов между первой и второй линиями. Изолированный инцидент, в ключевых полях которого не встречаются критичные хосты/сети/учетки (на самом деле критериев много больше, но в данном примере рассмотрим только основные) – скорее всего, не наберет необходимый скоринг, чтобы отправиться на вторую линию, и будет обработан на первой без траты ресурсов на подробное изучение дельта-окрестности инцидента.
В случае неизолированного инцидента вероятность попадания на вторую линию существенно возрастает. А если в предыстории текущего инцидента были обнаружены сработки в рамках короткого временного окна (меньше суток), то этот инцидент – 100-процентный кандидат для рассмотрения на второй линии с обязательным изучением предыстории.
Ну и конечно, здесь предусмотрен механизм фильтрации, поскольку не все склейки одинаково полезны. Разработка и поддержание в актуальном состоянии фильтров под каждого заказчика, разумеется, требует определенных ресурсов со стороны аналитиков, но польза, которую приносит инструментарий склейки цепочек инцидентов, все равно многократно превышает эти затраты.
Такая вот счастливая «перестройка».
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
