Фантастический TI и где он обитает

Security Vision

В этой статье мы поговорим об аналитике угроз как о ещё одном источнике генерации и расследования инцидентов. Однако, прежде чем перейти к теме расследования и дополнительного потока данных, давайте определимся с тем, что же такое TI. Threat Intelligence (TI) — это информация об угрозах и злоумышленниках в кибер-пространстве.

Threat Intelligence

TI разделяют на несколько уровней данных. На самом нижнем уровне представлены технические индикаторы компрометации, такие как IP, Hash, URL, Domain, Email. Эти данные чаше всего ассоциируются с TI. Следующие два уровня — это операционные и тактические данные. Сюда входят данные по различным TTP злоумышленника (тактики, техники, процедуры, инструменты), описываемые поведенческими индикаторами, командные строки, ключи реестра, вредоносные сертификаты, именованные пайпы — то, что показывает вредоносную активность в динамике. Данный вид индикаторов описан в правилах обнаружения угроз Sigma.

Самый верхний уровень данных стратегической атрибуции рассказывает о злоумышленниках, ВПО, вредоносные кампании, и меняются эти данные крайне редко, в отличие от низкоуровневых данных, которые легко изменяются злоумышленником, чтобы скрыть следы своей деятельности. Такие данные не составляет труда найти в интернете в публичных источниках, они быстро идентифицируются в активах на хостах, но их не всегда хватает для полноценного анализа ситуации. Это как если бы Шерлок Холмс использовал только 3 приметы преступника, такие как цвет глаз, форма уха и размер ноги, и при этом полностью игнорировал весь остальной ландшафт данных, которые можно использовать в расследовании.

Проблематика использования технологии

Благодаря стратегической атрибуции формируется контекст конкретного индикатора. Это дает возможность расследовать инцидент информационной безопасности в более полном масштабе, но вместе с этим возникает ряд проблем. Дело в том, TI сегодня является довольно популярным направлением. Большое количество организаций заинтересовано в анализе собственных угроз и готово вкладывать в это направление значительные суммы денег. Однако бывают случаи, когда TIP используется неэффективно и, столкнувшись с громадным потоком данных, специалисты ИБ большую часть этой информации просто игнорируют. Это происходит потому, что перед внедрением не были четко сформулированы цели внедрения. Например, TIP может отслеживать кредитно-финансовые индикаторы, учитывать конкретный инфраструктурный стэк, локацию страны и конкретную модель угроз нарушителей. И в том случае если фиды не будут должным образом кастомизированы, организация может «захлебнуться» в потоке false positive или, напротив, TI не будет давать сработок по дорогостоящим фидам, что приведет к разочарованию в технологии (как произошло относительно недавно в зарубежном мире ИБ, когда TI попал в долину разочарования в соответствии с аналитикой по кривой Gartner).

Другой вопрос, что разнородность форматов данных, отсутствие стандартов и единого понятийного аппарата вкупе с огромным дефицитом квалифицированных кадров в области кибербезопасности не способствуют максимально эффективному использованию решения. Общепринятого стандарта по общепринятому описанию индикатора угрозы просто нет. Есть, конечно, распространенные и наиболее часто используемые форматы, такие как STIX и MISP, но даже там атрибутивный состав может сильно разниться от источника к источнику, а некоторые поставщики данных и вовсе предлагают свой проприетарный формат. Модель данных по технической, операционной и стратегической атрибуции часто у каждого вендора своя.

Как же решаются все эти проблемы? В первую очередь можно ограничить поток данных релевантным для вас ландшафтом угроз. Зная особенности собственной инфраструктуры, можно выстроить границы, исходя из актуальных именно для вас рисков, сосредоточиться на угрозах, которые наиболее актуальны именно для вас, отслеживать те вредоносные процессы, которые наиболее опасны именно для вашей инфраструктуры. Это позволит не утонуть в огромном количестве информации и наиболее эффективно использовать TIP как источник данных. Кроме этого, TI нужно внедрить в свои процессы, процедуры, плейбуки, планы реагирования. Это нужно сделать как для превентивного анализа, так и для расследования конкретных инцидентов.

«Плюшки» TI

Самое большое преимущество TI — это актуальность данных. Когда мы говорим про сигнатурный анализ, про базы решающих правил, про правила корреляции, мы понимаем, что новые данные приходят к нам в соответствии с некоторым релизным циклом (у разных вендоров по-разному: это может быть неделя или месяц). В промежутках между релизами мы наименее защищены для самых новых угроз. TIP может закрыть эту дыру в безопасности за счет информации, которую он может предоставить на следующий день после её возникновения в GitHub или даркнете. За счет сырых событий, которые мы храним, есть возможность ретроспективно проверить, не было ли новой угрозы в нашей инфраструктуре вчера. То есть, мы увидели новый C2 домен, получив его, например, из краулера, затем идем на свою инфраструктуру и проверяем, не было ли с наших хостов обращений к этому вредоносному домену вчера, когда мы ещё не знали о его вредоносности. Это обеспечивается быстрым подключением нового источника данных с плечом логистики не месяц-два, а сутки или вовсе несколько часов.

Кейсы использования TI: обнаружения IOC и ситуационная осведомленность

Мы рассмотрели Threat Intelligence как источник индикаторов компрометации, но есть ещё один массив данных, нуждающихся в обработке, — это наши сырые события. Для наиболее эффективного поиска признаков вредоносной активности сырые события должны покрывать максимальное количество объектов инфраструктуры: сетевой, хостовой и почтовый трафик, с учетом отрасли и области; отраслевых протоколов, легитимных и нелегитимных приложений на вашем периметре.

Наличие этих двух источников данных дает нам два ключевых кейса использования TI-платформы. Первый кейс — это ситуационная осведомленность. Допустим, у нас есть какой-то домен, мы получили эту информацию из SIEM в рамках инцидента обращения к вредоносному домену. Что мы можем с этим сделать? Можем открыть TIP и выяснить, какие IP-адреса стояли за этим доменом в течение последней недели. Даже если IP меняются быстро, мы можем увидеть весь пул адресов и проверить их наличие в своей инфраструктуре. Можем увидеть связанные с вредоносным доменом хеши файлов, на основании этого можно выполнить действия по расследованию инцидента. Можем узнать, какой злоумышленник стоит за этим доменом и какое вредоносное ПО он использует. Этот кейс наиболее актуален для небольших SOC на 1-2 человека — для такой небольшой команды ещё один источник инцидентов был бы избыточен: это увеличение потока данных, который будет просто некому обрабатывать.

Для зрелой и большой команды SOC в дополнение к ситуационной осведомленности может быть добавлена функция обнаружения инцидентов. Ранее я упоминал две базы данных — хранилище индикаторов и исторические сырые события. Они объединяются в TIP для выполнения обнаружений. TIP мониторит сырые события (чаще всего в связке с SIEM) и syslog, в результате обработки события выбирается 5-6 ключевых параметров, таких как IP-исходный, IP-назначения, сетевой порт-назначения, домен, хеш, url, почтовый адрес. Далее производится поиск совпадений с базой данных индикаторов компрометации. Если происходит обнаружение, TIP автоматически генерирует инцидент. При следующем обнаружении происходит проверка на наличие открытого инцидента с одним из этих параметров. Если такой инцидент находится, происходит автоматическая агрегация, в результате чего SOC не заваливается большим количеством однотипных инцидентов.

Следующий параллельный поток данных — аномальная активность. Это касается machine learning, эвристики, отклонений от стандартного поведения, взвешенных цепей Маркова, random forrest, dga. По результату анализа этих данных может быть выявлена потенциальная вредоносная активность и создан инцидент.

Ещё один поток данных — это ретро-анализ, причем здесь нет повторения функционала SIEM. В TIP в оптимизированном виде хранятся упомянутые ранее 5-6 ключевых показателей. При получении новых индикаторов производится проверка на взаимодействие с индикаторами компрометации в прошлом, когда об этих индикаторах было ещё ничего не известно. Каждая организация сама определяет, за какой период хранить данные для эффективного анализа.

Пример из жизни

Давайте рассмотрим этот процесс на конкретном примере.

В SIEM при помощи корреляции обнаруживается инцидент, ключевым параметром в нашем случае выступает хеш из антивируса. Что с этим можно сделать? В TIP анализируется контекст индикатора, делаются проверки на наличие связей с другими индикаторами. Если замечено наличие индикатора, то автоматически создается инцидент, где мы можем проследить все связи этого хеша: например, какой злоумышленник ассоциируется с этим хешом, какие уязвимости и вредоносное программное обеспечение использует этот злоумышленник и связанные с этим вредоносным программным обеспечением ip-адреса. Таким образом, мы поняли, что у нас есть потенциально вредоносные ip-адреса, которые надо проверить. После этого логичным ходом будет выполнить ретро поиск, чтобы проверить, не было ли обращений с нашей инфраструктуры на ip-адреса, связанные со злоумышленником.

Предположим, что мы нашли с десяток обращений на часть этих адресов, и это уже потенциальный ландшафт атаки. Следующим шагом мы выполняем обогащение. Из аналитических сервисов, которым мы доверяем (VirusTotal, ANY.RUN, Kaspersky и пр.), автоматически собирается информация о связанных TTP. В результате мы получили ещё ряд индикаторов, но на этот раз поведенческих. Далее мы в своей инфраструктуре ищем индикаторы атак, т.е. проверяем, не обнаружатся ли вредоносные процессы на хостах, не контактировавших с C2-сервером, которые свидетельствовали бы о принадлежности к этой атаке. После того как мы нашли ещё 3-5 активов, затронутых этой угрозой, можно говорить том, что мы сформировали полноценный ландшафт атаки. Особо подчеркну, что большая часть этой аналитики может быть выполнена автоматически, если это позволяют возможности вашей TIP.

После того как расследование проведено, как правило, происходит стандартная операционная деятельность, в рамках которой блокируются вредоносные ip-адреса, какие-то активы выводятся в карантин, запускаются антивирусные проверки хостов, выполняется блокировка скомпрометированных учетных записей и т.п. Когда атака купирована и устранены её последствия, приходит время для постинцидентной обработки. В первую очередь это hardening активов, которые потенциально могут быть подвержены атаке. На основе сработавших индикаторов можно настроить правила корреляции, а также сигнатурные правила IDS/IPS, причем индикаторы могут автоматически перемещаться в табличные списки или в актив-листы SIEM, для того чтобы могли отработать корреляции. Также можно актуализировать модель угроз.

Заключение

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