Все больше компаний сегодня структурируют свои подходы к использованию CTI (Cyber Threat Intelligence), чтобы снизить риски ИБ, уменьшить затраты на устранение последствий от инцидентов и освободить время персонала, занимающегося их расследованием. В современной компании можно найти множество решений и технологий, направленных на обнаружение и предотвращение вредоносной активности злоумышленников: SIEM, SOAR, EDR, IPS, NGFW, SWG, SEG, CASB и т.д. В этой статье поговорим о программе Threat Intelligence.
Автор: Юрий Сергеев, RST Cloud
Программа Threat Intelligence включает много организационных мероприятий. Часть программы стратегическая и закрывает, например, такие вопросы, как инвестиции в средства защиты в соответствии с актуальностью угроз. А другая часть программы – операционная, она включает в себя технические мероприятия, например работу с индикаторами компрометации (IOC) – объектами, наблюдаемыми в сети или операционной системе, которые с большой долей вероятности указывают на взлом устройства или ПО.
В процессе насыщения ИБ-систем наиболее полными данными о существующих угрозах встает два вопроса. Первый – откуда получать эту информацию, второй – как проверить ее актуальность, то есть как информацию сделать знанием, имеющим под собой эмпирическую основу. Дело в том, что индикатор компрометации, который указывал на вредоносный домен неделю назад, сегодня уже может потерять свою актуальность. Например, из-за уязвимости в плагине CMS взломан легальный сайт, в результате чего злоумышленники залили на него фишинговую страницу для получения учетных данных пользователей для того или иного интернет-банкинга. Через неделю владелец сайта обнаруживает взлом и устраняет уязвимость. Таким образом, этот индикатор теряет свою ценность в настоящем.
Эти и ряд других важных условий мы учитывали в первую очередь при разработке облачного сервиса RST Threat Feed1, решив задачи сбора, агрегации, верификации и ранжирования индикаторов.
На данном этапе важно определить, какие источники должны стать частью вашей базы индикаторов. Нужно учитывать, что источники часто имеют пересечения, так как многие ресурсы копируют информацию друг у друга. Это не критично для самой фазы сбора, однако влияет на последующий скоринг собранной информации, поэтому важно исключать ресурсы, "вслепую" копирующие индикаторы без публикации дополнительной информации по ним, и стараться собирать сведения из независимых источников. В любом случае будут иметь место некоторые пересечения, так как зачастую одна и та же угроза может быть обнаружена специалистами независимо друг от друга в Китае, США, Иране и России. Следует отдельно отметить, что есть ряд уважаемых 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 или домены.
Расследования в целом можно соединить с ретроспективным анализом, так как в любом случае это взгляд в прошлое. В ходе расследования всегда хочется иметь самый подробный контекст свершившегося, чтобы наиболее полно восстановить детали произошедшего и принять оптимальное решение для предотвращения ущерба и дальнейшего распространения угрозы. Для этого ваши индикаторы должны быть обогащены достаточным количеством дополнительной информации, столь необходимой для принятия такого рода решений.