В рамках проведения штабных киберучений, последние из которых я проводил на конференции IT IS Conf, организованной УЦСБ, первый кейс, который я предлагал решить, касался бюллетеней ГосСОПКИ, в которых указано множество индикаторов компрометации, и вопрос звучал так: “Что вы будете делать с полученными индикаторами?” Этот вопрос достаточно неплохо характеризует ситуацию с процессом Cyber Threat Intelligence в организации. Кто-то не знает, какой должна быть последовательность действий при работе с IoCами. Кто-то сразу предлагает прогнать их через существующую SIEM и посмотреть на сработки. Кто-то предлагает разработать на их основе соответствующий use case и отдать его команде мониторинга в SOCе. Но почти никто (хотя допускаю, что это нюансы штабных киберучений в рамках публичных мероприятий, к которым относишься немного с пренебрежением, считая, что в ”боевой“ ситуации “Уж я-то спуску хакерам не дам, и я ууух…”) не рассказывает, как он будет оценивать ценность IoCов с течением времени? Ведь мы прекрасно понимаем, что с течением времени их ценность падает, а объем ложных срабатываний возрастает, что приводит к росту времени и усилий на расследования с использованием устаревших индикаторов компрометации.
Если посмотреть на жизненный цикл индикатора в процессе мониторинга, то выглядит это примерно следующим образом:
Проверять IOCи стоит ежедневно и в случае обнаружения уже неактуальных выводить их из эксплуатации (в зависимости от имеющихся запасов системных ресурсов для работы платформ SOC это можно делать и чуть реже, но не стоит ждать дольше недели). По статистике около 10% теряет свою актуальность ежегодно, но опять же этот показатель сильно зависит от организации, ее масштаба, сферы деятельности, страны нахождения и других параметров.
Как проверять неактуальность индикатора компрометации? Тут важно не сильно погружаться в многофакториальный анализ — достаточно всего нескольких показателей, которые могут лечь в основу автоматически проверяемой актуальности IoC, из которых первые два критерия первичны, а остальные вторичны.
Соответственно, индикатор теряет свою актуальность, когда мы получаем ответ “Нет” на оба первичных критерия и когда ответ “Нет” на больше чем 2 и более вторичных критериев.
Так как все новые IoCи добавляются в базу данных с указанием их источников и даты добавления, то мы можем ежедневно автоматические сравнивать IoCи с их первоначальным источником и датой создания, чтобы определить, соответствуют ли они соответствующим критериям вторичной оценки. Также, ежедневное сканирование позволяет извлекать из системы управления инцидентами информацию об уровне обнаружения IoC за прошлые месяцы (ответ на 2 первых критерия) при оценке целесообразности вывода IoC из эксплуатации.
Однако при реализации этого алгоритма у нас проявляется один риск — риск того, что удаление старых IoCов не позволит обнаруживать старые методы атак, которые вдруг будут снова использоваться хакерами и станут актуальными. В этом случае, можно включать старые индикаторы в месячные или двухмесячные сканы для проверки актуальности IoCов.
Исходя из описанного алгоритма, можно выбирать и платформу для Threat Intelligence, а также платформу для реагирования инцидента, которые должны уметь обмениваться данными между собой.
Возможно, ваша TIP-платформа уже содержит встроенные возможности по оценке актуальности индикаторов. Узнайте у вендора используемый ими алгоритм и оцените, подходит ли он вам?
