Особенности сбора, агрегации и ранжирования индикаторов компрометации

Все больше компаний сегодня структурируют свои подходы к использованию CTI (Cyber Threat Intelligence), чтобы снизить риски ИБ, уменьшить затраты на устранение последствий от инцидентов и освободить время персонала, занимающегося их расследованием. В современной компании можно найти множество решений и технологий, направленных на обнаружение и предотвращение вредоносной активности злоумышленников: SIEM, SOAR, EDR, IPS, NGFW, SWG, SEG, CASB и т.д. В этой статье поговорим о программе Threat Intelligence.

Автор: Юрий Сергеев, RST Cloud

Программа Threat Intelligence включает много организационных мероприятий. Часть программы стратегическая и закрывает, например, такие вопросы, как инвестиции в средства защиты в соответствии с актуальностью угроз. А другая часть программы – операционная, она включает в себя технические мероприятия, например работу с индикаторами компрометации (IOC) – объектами, наблюдаемыми в сети или операционной системе, которые с большой долей вероятности указывают на взлом устройства или ПО.

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

Эти и ряд других важных условий мы учитывали в первую очередь при разработке облачного сервиса RST Threat Feed¹, решив задачи сбора, агрегации, верификации и ранжирования индикаторов.

Сбор индикаторов

На данном этапе важно определить, какие источники должны стать частью вашей базы индикаторов. Нужно учитывать, что источники часто имеют пересечения, так как многие ресурсы копируют информацию друг у друга. Это не критично для самой фазы сбора, однако влияет на последующий скоринг собранной информации, поэтому важно исключать ресурсы, "вслепую" копирующие индикаторы без публикации дополнительной информации по ним, и стараться собирать сведения из независимых источников. В любом случае будут иметь место некоторые пересечения, так как зачастую одна и та же угроза может быть обнаружена специалистами независимо друг от друга в Китае, США, Иране и России. Следует отдельно отметить, что есть ряд уважаемых malware-исследователей, которые делятся информацией о найденных индикаторах в Twitter, Pastebin и на других платформах. Такие результаты чаще всего будут уникальными и представляют реальный интерес. Сбор подобных сведений позволяет получать индикаторы, которые еще "зеленые" в VirusTotal и неизвестны многим antimalware-компаниям.

Каждый источник имеет свою историю ошибок первого (false positive) и второго (false negative) рода и специализацию. При формировании списка таких источников желательно определить, какой из них является более, а какой менее доверенным. Такой первоначальный скоринг может быть сформирован после сбора и анализа пересечений потенциальных ошибок первого рода с учетом устаревания индикаторов в течение продолжительного времени, когда накапливается достаточная статистика.

Кроме того, важно учитывать специализацию источника. Есть источники, которые ведут список хостов, которые пытаются подобрать пароли на открытых ssh-портах, а есть такие, которые публикуют информацию по C2-серверам определенного семейства троянов. Другой тип источников ведет списки узлов, участвующих в проверках веб-эксплойтов "по площадям", используя роботов для "проверки боем" на актуальные уязвимости. Такая "заточенность" на определенные виды угроз также помогает определить место источника с точки зрения важности предоставляемых им результатов и необходимости включения в "общий котел" для последующей обработки в скоринговой модели.

Одной из дополнительных сложностей сбора является необходимость нормализации данных, так как каждый источник публикует их в своем "любимом формате": текстовые файлы, csv, json, XML, STIX, MISP event, openioc и др. Формат живых сообщений исследователей зачастую требует лингвистического анализа и преобразования человеческого текста в язык машины.

Ранжирование индикаторов

В процессе ранжирования индикаторов может быть выбрано много подходов и формул для вычисления степени доверия к индикатору. Если охарактеризовать степень доверия неким числом, то оно будет меняться во времени из-за динамического характера использования компьютерных ресурсов атакующими. Например, в код вредоноса может быть спрятана функция, вычисляющая доменное имя в зависимости от времени. Скажем, на октябрь это будет список из одних 100 доменов, а на ноябрь это уже будет список других доменов. Нередко те или иные замеченные IP-адреса перестают использоваться и доменные имена перерегистрируются на другие, как только злоумышленник видит, что эффективность его "деятельности" снижается. При этом часто инфраструктура, находящаяся во временном владении злоумышленника, может быть "переиспользована": по истечении некоторого времени он может решить, что данный IP-адрес давно не "работал" и пора его снова пустить в дело.

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

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

Обогащение индикаторов

Основная задача постанализа при работе с индикаторами – объяснить суть угрозы, продемонстрировать, что известно из окружения о данной сущности, с кем она связана и как это можно применить для снижения рисков. Базовые интерпретации, включающие сбор whois, asn, геоданных, принадлежности к хостинг-платформам или tor и другую подобную информацию об индикаторах, полезны в случаях атрибуции и при сравнении с другими взаимодействиями, которые считаются нормой в системе, для определения вероятности возникновения именно этого взаимодействия как легального. Есть ряд компаний, которые фокусируются на определенном регионе и не ожидают подключений из неожиданных локаций либо используют вероятностную модель при определении доверия к тем или иным подключениям или транзакциям, исходя из статистических данных. Для них эта информация о владельце или местоположении будет одной из определяющих.

Но все же базовый сценарий предполагает, что главным фактором, формирующим доверие к индикатору, является принадлежность к определенной и насущной угрозе. Возьмем, к примеру, топ-10 шифровальщиков. Знают ли мои средства защиты индикаторы для блокировки такого рода проблем? Как это проверить? Я не хочу бороться с последствиями, хочу, чтобы, даже если удастся обойти мои endpoint-системы через уязвимости zero day, была возможность просто блокировать взаимодействия с вредоносными серверами на этапе загрузки вредоносного контента или управления им. В этих случаях важна связь между непосредственным значением индикатора и тем или иным вредоносным программным обеспечением или угрозой. Такого рода информацию получить уже на порядок сложнее, чем просто узнать, кто непосредственно владеет сайтом или IP-адресом. Эта информация в основном поступает от независимых исследователей или специализированных компаний, которые более глубоко погружаются в вопрос во время анализа, и требует либо наличия достаточных человеческих ресурсов для ручного парсинга и анализа, либо эффективной семантической системы проверки и контроля.

Способы применения индикаторов

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

• детектирование;
• блокирование;
• ретроспективный анализ;
• расследование.

Детектирование

Наиболее очевидный сценарий – детектирование. Я хочу иметь дополнительный уровень контроля моих превентивных мер и следить за качеством их работы, а также реагировать в случаях, когда та или иная проблема не была решена на более низком инфраструктурном уровне. Зачастую такого рода действия реализуются на базе SIEM-систем. Основными проблемами при применении подобного сценария являются поиск и определение false positive среди всего множества срабатываний. Сервисы, доступные из сети Интернет, подвергаются мелким атакам ежедневно. Роботы тестируют сотни разных эксплойтов каждый день в поисках того неудачного для защищающего случая, когда его сервис не получил обновление. Такого рода детектирование создает информационный шум, требующий фильтрации, либо обработки не в realtime, а на периодической основе, либо корреляции с другими событиями – запуском Shellcode, созданием дополнительного пользователя в ОС или в БД и т.п. Важно правильно сформировать правила детектирования, чтобы была возможность избегать такого рода последствий. Это, в свою очередь, накладывает определенные требования к составу и качеству обогащения индикаторов. Например, информация о том, что IP-адрес является вредоносным, важна сама по себе, но она, весьма вероятно, будет лишь информацией, а не знанием, если известно, что на данном адресе существует еще десяток тысяч других доменов. В этом случае, если индикатор не обогащен такой информацией, скорее всего в результате обработки инцидента вы придете к выводу об ошибке первого рода (false positive) из-за того, что произошло детектирование подключения к легальному сайту на этом же адресе.

Блокировка

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

Ретроспективный анализ

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

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

Расследование

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

1. https://www.rstcloud.net/profeed