Всем привет! Я работаю инженером-разработчиком в STEP LOGIC. Наша команда создает технологическую платформу для автоматизации анализа данных и расследования инцидентов STEP Security Data Lake (SDL). Мы были первыми на российском рынке, кто смог внедрить AI-ассистента в SIEM/SOAR. Поэтому в этой статье я хотел бы поразмышлять о перспективах развития и особенностях применения интеллектуальных помощников в системах мониторинга кибербезопасности.

Аналитики оценивают среднегодовой темп роста рынка интеллектуальных помощников более чем в 30%. В сфере информационных технологий использование ИИ для решения рутинных задач уже стало повсеместной практикой ведущих компаний, такая же тенденция наблюдается в области информационной безопасности. Процесс обработки инцидентов ИБ требует тщательного анализа со стороны человека, тем не менее, из-за комплексности задачи, во время разбора инцидентов есть немало рутинной работы, которую можно было бы переложить на плечи интеллектуального помощника.

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

Поехали!

Перспективы и риски внедрения интеллектуальных помощников в SOC

В первую очередь поговорим о преимуществах применения AI‑ассистента. Главное и, по сути, основное — сокращение времени реагирования на инциденты за счёт автоматизации рутинных задач. Обработка инцидентов — кропотливый процесс, который включает нахождение связей между несколькими инцидентами в рамках одного расследования, анализ критичности выявленного инцидента, выполнение сценариев реагирования и многое другое. Аналитики SOC сталкиваются с огромным объёмом данных, которые необходимо обработать, классифицировать, отреагировать на них и подумать, связаны ли обнаруженные инциденты с произошедшими ранее.

Автоматическая классификация по уровню критичности

Как правило, подавляющее число инцидентов являются ложными срабатываниями, которые можно определить по формальным признакам. ИИ используется именно в качестве фильтра ложных инцидентов. В более продвинутом варианте ассистент может не только их классифицировать, но и передавать на обработку. Например, ложные инциденты просто отбрасываются, те, для которых подготовлены автоматические сценарии реагирования (блокировка АРМ, закрытие порта и т.д.), выполняются без участия аналитика, а оставшийся минимум направляется на анализ специалистам.

Обработка и нахождение связей в больших объёмах данных

Интеллектуальные помощники могут получать в качестве вспомогательной информации контекст с релевантными событиями и отвечать на запросы аналитиков в соответствии с ним. Например, если произошёл инцидент с участием пользователя А, аналитик может уточнить у ИИ, в каких других инцидентах он был замешан, как можно охарактеризовать его поведение в системе. Такой подход становится предварительным этапом для поведенческого анализа данных, когда AI-ассистент детектирует нехарактерные для узла или пользователя действия и помечает их как подозрительные.

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

Автоматические сценарии реагирования (playbooks)

Основная часть инцидентов подразумевает достаточно простые шаги по реагированию, такие как блокировка адресов, портов, отключение АРМ или учётной записи, сброс пароля и др. Применяя AI-ассистента в SOС, можно добиться автоматического выполнения всех перечисленных выше действий, что в несколько раз ускоряет процесс реагирования на инциденты.

Отсутствие человеческого фактора при принятии решений и мониторинге инфраструктуры

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

Риски внедрения интеллектуального помощника

Ложные срабатывания

При неправильной реализации ИИ может помешать аналитикам SOC, а в крайних случаях вызвать критические уязвимости в самом центре мониторинга. Главный риск, с которым можно столкнуться, — ложные срабатывания интеллектуального помощника. Если ассистент работает на недостаточно обученной модели, точность его выводов и действий резко снижается. В таком случае невозможно опираться на решения ассистента, а всё сэкономленное время придётся тратить на их перепроверку. Мы рекомендуем перед внедрением тщательно протестировать выполнение каждой запланированной задачи, чтобы убедиться в надёжности выбранной технологии.

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

Снижение эффективности работы SOC за счёт деградации компетенций сотрудников может произойти, если попытаться внедрить AI-ассистента во все задачи по обработке инцидентов, лишая работы аналитиков. В таком случае персонал может работать и принимать решения только на основе ответов внедрённого интеллектуального помощника, что повышает скорость работы, но может снизить её качество. Необходимо искать баланс между автоматизацией процессов и проверкой точности ответов ИИ, между делегированием задач и поддержкой компетенций персонала.

Пошаговая инструкция интеграции ИИ в процессы SOC на примере внедрения технологии RAG

В последнее время набирает обороты подход Retrieval Augmented Generation (RAG) — генерация с дополненной выборкой, при котором ИИ дают возможность взаимодействовать с определённой базой знаний, контекстом, на основании которого генерируются ответы на запросы пользователя. Разберем кейс, когда аналитику необходимо получить данные о пользователях, упоминавшихся в инцидентах. Генеративная модель запрашивает данные, которые прямо или косвенно содержат информацию о пользователе, и генерирует ответ на основании полученного контекста.

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

Помимо этого, RAG используют для автоматического составления карточки инцидента. Все перечисленные варианты могут применяться одновременно или по отдельности.

Например, в STEP Security Data Lake внедрён интеллектуальный помощник сразу с несколькими функциями. Он не только находит ключевую информацию в инцидентах, но и предлагает меры по закрытию уязвимостей.

Шаг 1. Определите задачи и постройте визуальные модели взаимодействия

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

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

Шаг 2. Сформируйте базу знаний

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

• Векторное — для поиска релевантных документов, в которых содержатся данные по вопросу пользователя.

• Текстовое — для передачи на вход генеративной модели в качестве контекста.

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

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

Шаг 3. Выберите конкретные технические решения и постройте тестовый прототип

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

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

Выберите векторную базу данных для хранения вашей базы знаний и иные решения, которые могут потребоваться при реализации полноценного продукта. В зависимости от объёма и сложности данных выберите размерность вектора, на основе которого будет производиться отбор релевантных документов при поиске по базе знаний, а также определитесь с математическим методом, используемым для установления степени схожести вопроса пользователя и документа. В основном используется косинусное или Евклидово расстояние, или скалярное произведение. Помните про необходимость нормализации данных, для некоторых алгоритмов оценки релевантности это критически необходимый пункт. Если есть возможность управлять алгоритмами поиска кандидатов, не пренебрегайте данной возможностью, наиболее используемым на данный момент алгоритмом является HNSW (графовые методы).

Шаг 4.  Протестируйте прототип, оцените его точность и скорость работы

Получившийся прототип рекомендую проверить на точность и при необходимости заменить используемые модели. Например, если база знаний на русском языке, а модель векторизации обучена на английских данных, точность будет низкой. Это может привести к некорректной выдаче документов для контекста во время поиска. Неотъемлемая часть тестирования — проверка защищённости построенного прототипа.

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

Заключение

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

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

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