Меня зовут Виктор Пронин, я старший аналитик киберугроз в центре компетенций группы компаний «Гарда». Для Гарда Threat Intelligence Feeds мы формируем данные об угрозах на основе обезличенной телеметрии из наших инсталляций, а чтобы получить более полную картину, обращаемся в том числе к информации из открытых источников. В статье я расскажу об автоматизированной обработке публикаций по информационной безопасности. Кейс будет полезен аналитикам киберугроз и специалистам, интересующимся применением ML в ИБ.

В целом публикации по информационной безопасности можно разделить на два типа: новости и отчеты. В автоматическом режиме мы сканируем около 70 источников. Набор этих источников дает порядка 38 публикаций в день, из которых по статистике примерно 30 – новости, 8 – отчеты.

Причем реально уникальных новостей остается в районе 10-15, так как одна и та же новость может дублироваться в нескольких источниках. Итого получается, что аналитикам необходимо обработать в день около 18 уникальных публикаций. 

Данные из публичных отчетов нужно обрабатывать, а для этого нужны ресурсы (прежде всего человеческие). Причем сама по себе задача обработки публикаций довольно рутинная.

Кроме того, аналитику при чтении отчетов приходится сталкиваться с огромным количеством различных сущностей, как новых, так и старых. Эти сущности могут служить дополнительным контекстом для индикаторов компрометации, входить в состав правил или фигурировать как термины в базе знаний киберугроз. Таким образом, встает задача извлечения именованных сущностей. О том, как мы это делаем с помощью NER (Named Entity Recognition), я расскажу далее.

Роль NER в обработке TI–данных

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

В результате обработки текста с помощью NER мы получаем список сущностей с заранее определенными классами. Что нам это дает? 

Во-первых, мы видим предварительный контекст публикации – упоминаемые сущности (например, группировки или ВПО). На раннем этапе обработки это может рассказать про актуальность той или иной публикации. Казалось бы, что контекст отражается в заголовке статьи, но это не всегда так. Мой любимый пример – заголовок говорит об атаках некой группировки на страны юго-восточной Азии, но в тексте статьи есть следующее упоминание: «также были замечены атаки на организации из России». NER в данном случае извлекла бы все упоминаемые страны из отчета, среди которых была бы и Россия, и аналитик словил бы диссонанс обратил бы внимание на этот отчет.

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

В-третьих, экономим время аналитиков. В результате автоматизированной, а затем ручной обработки публикации мы получаем условный JSON: индикаторы с контекстом, связи между сущностями и TTPs. Именно на этапе автоматизированной обработки извлекаются сущности, что позволяет специалистам тратить меньше времени на ручной анализ отчета или новости.

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

Схема обработки публикаций

Весь процесс обработки публикаций можно представить в виде такой схемы:

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

Сразу стоит отметить, что модель не идеальная, поэтому требуется дополнительная обработка. В частности, мы проводим коррекцию классов сущностей в соответствии с нашей внутренней базой данных. Это происходит в модуле постобработки. Только после завершения всех этих этапов аналитик начинает работать с публикацией: корректировать при необходимости классы сущностей, добавлять упущенные моделью сущности, извлекать из отчета TTP, выстраивать связи с индикаторами. В результате формируется набор индикаторов, TTP и сущностей, который и становится конечным продуктом аналитики.

В следующих разделах я подробно опишу принципы работы NER-модуля и модуля постобработки, а также расскажу о проблемах, с которыми мы столкнулись.

NER–модуль

NER-модуль фактически состоит из модели CyNER, которая была обучена на двух объединенных датасетах. Первый – исходный датасет из того же репозитория, а второй – APTNER. Здесь стоит отметить несколько важных моментов:

• Датасеты можно считать устаревшими – им уже более трех лет, что в области информационной безопасности является значительным сроком, поскольку ежегодно появляется множество новых наименований. Мы сравнивали как будет работать модель, если «скармливать» ей эти датасеты по отдельности. Также пробовали использовать и другие модели. Например, BERT-CRF. Однако, прогнав одни и те же тексты через эти модели, пришли к выводу, что нам больше всего подходит именно CyNER с исходным датасетом и датасетом APTNER. В других моделях, особенно в BERT-CRF, после обработки текста наблюдалось больше галлюцинаций: чаще происходило смешивание классов сущностей, а сами сущности извлекались некорректно.

• Используемые датасеты содержат данные исключительно на английском языке, что на первый взгляд может вызвать сомнения в применимости моделей к русскоязычным отчетам. Однако на практике оказалось, что проблемы не столь критичны: даже в полностью русскоязычных отчетах ключевые сущности указаны на английском языке. Это позволяет модели с высокой точностью локализовать и извлекать эти сущности, несмотря на общий контекст на русском.

Вот мы обучили модель, настроили окружение, что в итоге? Мы видим данные в таком формате:

И получаем следующие поля:

• mention – найденная сущность;

• class – тип найденной сущности;

• confidence – численное значение вероятности, которое указывает на степень уверенности модели в корректности идентификации и классификации сущности.

Правда, модель не анализирует текст целиком, а разбивает его на фрагменты и ищет сущности в каждом из них. Поэтому одна и та же сущность может быть обнаружена с разной достоверностью в зависимости от контекста.

Ниже в таблице представлены классы сущностей, которые извлекает модель.

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

1. Передать в модель дополнительный контекст.

2. Прогнать найденные моделью сущностью через нашу внутреннюю базу знаний, где корректируются классы. Мы это делаем в модуле постобработки.

Далее подробнее разберу нюансы их применения.

Дополнительный контекст

Как я уже отмечал ранее, при обработке русскоязычных текстов модель часто «триггерилась» на англоязычные слова, что приводило к ошибкам классификации сущностей. Чтобы снизить шум и заставить модель лучше понимать контекст, мы провели эксперимент: дали модели дополнительный контекст. В частности, загрузили в модель не только текст публикации и заголовок, но и тезисы, автоматически сгенерированные сервисом YandexGPT.

В сервис генерации тезисов мы с помощью скрипта отправляем ссылку на статью и получаем тезисы на русском языке в следующем формате:

Использование комбинированного подхода позволяет компенсировать ограничения используемых нами датасетов.

Правда, сервис генерации тезисов может допускать ошибки. Например, иногда он дословно пытается перевести названия сущностей. Смотрите, как изменились названия «вайпер Shamoon» и «шифровальщик Lockbit» в одном из отчетов:

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

Модуль постобработки

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

{
 "mention": "Cobalt Strike",
 "Class": "MAL",
 "Confidence": 0.99,
 "count": 12,
 "count_text": 58,
 "count_title": 0,
 "dict_search": "TOOL",
 "Corrected_Confidence": 1.0,
 "confidence_corrections": "#DictCMP"
 }

Все эти поля помогают скорректировать класс сущности и определить, является ли она ключевой. Делается это с помощью нескольких простых действий:

• Найденные моделью сущности с Confidence меньше 0.85 отсекаются и в дальнейшей обработке не участвуют.

• Все сущности типа MAL, APT, TOOL, состоящие полностью из кириллицы, также исключаются из обработки.

• Производится поиск сущности во внутренней базе. Если сущность есть в базе, мы корректируем Class и устанавливаем Confidence, равный 1.

В случае если сущность прошла проверки из первого и второго пунктов, но отсутствует в базе, она считается новой и ее дальнейшая обработка ложится на плечи аналитика. Ниже показан пример новой статьи на нашей внутренней платформе:

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

Извлечение стран и атакуемых сфер

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

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

Этот процесс можно представить в виде схемы:

Подход также помог решить проблему с падежами. Например, слово «России» в исходном тексте отчета корректно преобразуется в «Russia» после перевода. Таким образом, сущности в базе не дублируются.

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

Альтернативные названия

Одна и та же группировка или ВПО часто встречается в отчетах под разными названиями. Это характерно для таксономии киберугроз. Похожая ситуация наблюдается и с атакуемыми сферами. Например, «финансы», «финансовые организации» – это одна и та же сфера.

Чтобы избежать бесконечного дублирования сущностей в базе, необходимо вести словарь альтернативных названий. Причем если для группировок такая практика очевидна, то для сфер ее важность может быть необоснованно занижена. Но это лишь до тех пор, пока лично не столкнешься с десятком отчетов, где одна сфера указана в нескольких вариациях. Например, как «IT», «информационные технологии» или просто «software».

Ведение словаря для всех типов сущностей позволяет на этапе постобработки дополнительно поискать обнаруженную моделью сущность в альтернативных названиях. Это упрощает ведение базы знаний об угрозах – все «разложено по полочкам».

Заключение

Использование NER в связке с модулем постобработки позволило нам в значительной мере упростить обработку публикаций с точки зрения ведения базы знаний и сократить на 30% время обработки аналитиком одной публикации.

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

К тому же компенсировать использование старых датасетов удалось c помощьюif/else модуля постобработки, который упростил ведение базы данных, учитывая большое количество альтернативных названий различных сущностей.