Журнал "Information Security/ Информационная безопасность" #5, 2020

торинг их частотности в разных незави- симых источниках. Как только индикатор становится известен большинству ресур- сов, его актуальность падает. Можно попробовать много подходов определе- ния такой зависимости, от линейного до экспоненциального, но в этом случае, согласно нашей практике, выбор поли- номиальной функции устаревания дает достаточно предсказуемый результат: может обеспечивать быстрый сброс оценки, но при этом позволяет "вытянуть наверх" индикаторы, которые некоторое время "молчали". Подбор параметров функции осуществляется за счет накоп- ления истории и статистики, а с техни- ческой точки зрения является довольно интересной задачей. Таким образом, нужно определять не только значимость события в данный момент, но и степень изменения важно- сти того или иного индикатора с течени- ем времени. Обогащение индикаторов Основная задача постанализа при работе с индикаторами – объяснить суть угрозы, продемонстрировать, что извест- но из окружения о данной сущности, с кем она связана и как это можно при- менить для снижения рисков. Базовые интерпретации, включающие сбор whois, asn, геоданных, принадлежности к хостинг-платформам или tor и другую подобную информацию об индикаторах, полезны в случаях атрибуции и при сравнении с другими взаимодействиями, которые считаются нормой в системе, для определения вероятности возник- новения именно этого взаимодействия как легального. Есть ряд компаний, кото- рые фокусируются на определенном регионе и не ожидают подключений из неожиданных локаций либо используют вероятностную модель при определении доверия к тем или иным подключениям или транзакциям, исходя из статистиче- ских данных. Для них эта информация о владельце или местоположении будет одной из определяющих. Но все же базовый сценарий предпо- лагает, что главным фактором, форми- рующим доверие к индикатору, является принадлежность к определенной и насущ- ной угрозе. Возьмем, к примеру, топ-10 шифровальщиков. Знают ли мои сред- ства защиты индикаторы для блокировки такого рода проблем? Как это проверить? Я не хочу бороться с последствиями, хочу, чтобы, даже если удастся обойти мои endpoint-системы через уязвимости zero day, была возможность просто бло- кировать взаимодействия с вредоносны- ми серверами на этапе загрузки вредо- носного контента или управления им. В этих случаях важна связь между непо- средственным значением индикатора и тем или иным вредоносным программным обеспечением или угрозой. Такого рода информацию получить уже на порядок сложнее, чем просто узнать, кто непо- средственно владеет сайтом или IP-адре- сом. Эта информация в основном посту- пает от независимых исследователей или специализированных компаний, кото- рые более глубоко погружаются в вопрос во время анализа, и требует либо наличия достаточных человеческих ресурсов для ручного парсинга и анализа, либо эффек- тивной семантической системы проверки и контроля. Способы применения индикаторов Не секрет, что существует проблема реактивности защиты. Снижение вре- мени реагирования на случившиеся события ИБ часто представляется важ- ной задачей. Однако предотвращение таких событий всегда воспринимается как более позитивный результат. Такого рода задачи стоят и в том числе при использовании индикаторов компроме- тации в различных компаниях и органи- зациях. Обычно можно выделить сле- дующие основные сценарии применения индикаторов компрометации: l детектирование; l блокирование; l ретроспективный анализ; l расследование. Детектирование Наиболее очевидный сценарий – детектирование. Я хочу иметь дополни- тельный уровень контроля моих превен- тивных мер и следить за качеством их работы, а также реагировать в случаях, когда та или иная проблема не была решена на более низком инфраструк- турном уровне. Зачастую такого рода действия реализуются на базе SIEM- систем. Основными проблемами при применении подобного сценария являют- ся поиск и определение false positive среди всего множества срабатываний. Сервисы, доступные из сети Интернет, подвергаются мелким атакам ежеднев- но. Роботы тестируют сотни разных экс- плойтов каждый день в поисках того неудачного для защищающего случая, когда его сервис не получил обновление. Такого рода детектирование создает информационный шум, требующий фильтрации, либо обработки не в real- time, а на периодической основе, либо корреляции с другими событиями – запуском Shellcode, созданием допол- нительного пользователя в ОС или в БД и т.п. Важно правильно сформировать правила детектирования, чтобы была возможность избегать такого рода последствий. Это, в свою очередь, накла- дывает определенные требования к составу и качеству обогащения инди- каторов. Например, информация о том, что IP-адрес является вредоносным, важна сама по себе, но она, весьма вероятно, будет лишь информацией, а не знанием, если известно, что на данном адресе существует еще десяток тысяч других доменов. В этом случае, если индикатор не обогащен такой информацией, скорее всего в результате обработки инцидента вы придете к выво- ду об ошибке первого рода (false positive) из-за того, что произошло детектирова- ние подключения к легальному сайту на этом же адресе. Блокировка Вторым немаловажным сценарием является блокировка. Здесь очень высо- ка цена ошибок, так как блокировка может влиять на результаты взаимодей- ствия чувствительных ИТ-процессов внут- ри самой компании или организации на ее внешнем взаимоотношении с другими юридическими или физическими лицами либо государственными службами. Для этого сценария важен уровень доверия к индикатору и его скоринг. Обычно схема блокировки такая: блокируй оче- видные угрозы и присылай оповещение по сомнительным. В случае, когда инди- катор приходит без какого-либо рейтинга, использование его в такого рода сцена- риях проблематично ввиду сложности определения степени доверия к нему. С другой стороны, применение рейтинга при завышении порога чувствительности приводит к пропуску угрозы. Ретроспективный анализ Задача ретроспективного анализа воз- никает, когда мы узнаем о выходе инди- каторов, угрозы к которым существуют уже некоторое время. Зачастую о них было неизвестно общественности какой- то период времени, поэтому возникает желание проверить, а может ли данная угроза быть реализованной по отноше- нию к конкретной инфраструктуре. Бывает и так, что мы узнаем о ком- прометации через несколько месяцев. К сожалению, это не редкость в совре- менной практике. В этом случае в рамках расследования инцидента важно полу- чить полный контекст угрозы не только на текущий момент, но и обратиться к информации о ней в ретроспективе. На момент взлома это могли быть другие адреса, URL или домены. Расследование Расследования в целом можно соеди- нить с ретроспективным анализом, так как в любом случае это взгляд в про- шлое. В ходе расследования всегда хочется иметь самый подробный контекст свершившегося, чтобы наиболее полно восстановить детали произошедшего и принять оптимальное решение для пред- отвращения ущерба и дальнейшего рас- пространения угрозы. Для этого ваши индикаторы должны быть обогащены достаточным количеством дополнитель- ной информации, столь необходимой для принятия такого рода решений. l • 23 SOC www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru