Хабрахабр

ИИ в собственном SOC’у: мечтают ли руководители центров мониторинга кибератак об электроаналитиках

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

Все чаще мы слышим о необходимых подходах, прорабатываемых решениях и даже (иногда робко и неуверенно, а иногда громко и, к сожалению, не очень правдоподобно) о первых практических успехах в данной области. Информационная безопасность тоже не остается за границами хайпа вокруг ИИ (или его эволюции — тут уж каждый решает для себя). Кого заинтересовала тема или просто хочется пофлеймить в комментариях — добро пожаловать под кат.
Говорить за все ИБ мы, конечно, не возьмемся, но попробуем разобраться, каковы реальные возможности применения ИИ в профильном для нас направлении SOC (Security Operations Center).

Типизация ИИ под задачи ИБ, или не все ИИ одинаково полезны

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

Логический подход (компьютерная экспертная система) – ИИ формируется в первую очередь как система доказательства сложных фактов. 1. Если верить источникам, схожие подходы в своей работе использует система IBM Watson, печально известная всем российским любителям шахмат. Любую возникающую цель система интерпретирует как задачу, которую необходимо решить логическими методами.

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

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

Структурный подход — когда одной из основных инженерных задач ИИ является эмуляция работы человеческого мозга с его возможностью структурировать и анализировать информацию. 2. По факту подаваемых в систему потоков данных и предоставляемой ей обратной связи (что очень помогает и обыкновенным людям, в том числе и аналитикам SOC) она самообучается и улучшает внутренние алгоритмы принятия решений.

Это обработка изображений, персонализация данных, тегирование аудио-/видеоконтента или иной информации. Благодаря возможности развернутой обратной связи данные подходы часто используются применительно к массивам условно структурированных данных. Налицо сходство с работой человеческого мозга: чтобы ИИ «вырос», его надо учить, что хорошо и что плохо, что горячее, что холодное, где мама, а где чужой человек. В большинстве известных реализаций система, не являясь экспертной в чистом виде и не требуя режима приобретения знаний, тем не менее требует существенной операторской работы для формирования устойчивого и содержательного потока обратной связи.

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

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

Имитационный подход — создание симулятора действий в исследуемой области путем долгосрочных наблюдений за имитируемым предметом. 4. Если упростить, то задача заключается в считывании всех входных параметров и выходных данных (результатов анализа, действий и т.д.) для того, чтобы машина через какое-то время смогла выдавать ровно такие же результаты, как и исследуемый объект, и потенциально транслировать те же мысли, если объектом выступал человек.

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

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

В случае же с выявлением инцидентов все гораздо занимательнее. В общем случае часть ИБ-процессов (выявление мошенничества, защита веб-приложений, анализ прав и учетных данных пользователей) действительно поддерживает принцип больших чисел и «логическую» структуру.

ИИизируй это, или Возможности искусственного интеллекта в разрезе процессов SOC

Поскольку в обоих случаях подразумевается имитация человеческого логического мышления, стоит для начала задаться вопросом: а что бы я, аналитик SOC, мог сделать для того, чтобы решить эту задачу или получить ответ на нее откуда-то — автоматизировано? Теперь давайте попробуем «приземлить» логический и структурный подходы к искусственному интеллекту на ключевые процессы SOC. Пройдемся по ключевым процессам работы SOC:

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

При появлении новой системы можно достаточно достоверно «сравнить» ее с соседями (анализируя сетевой трафик, структуру ПО и связи с другими ИС) и из этого сделать предположение о ее назначении, классе, ключевой хранимой информации. В теории это благодатное поле для ИИ. А если добавить туда контекст создания («система написана Васей, а Вася в нашей компании – ИТ-специалист по документообороту, и последние десять созданных им систем были документооборотом» или «одновременно с ней было создано еще 4 системы, в которых явно указано назначение» и т.д.), то проведение инвентаризации и учета активов кажется посильной для ИИ задачей.

Возникающие нюансы или внешние проблемы

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

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

Тем не менее отметим перспективность применения ИИ в этой задаче как «когда-нибудь» и двинемся дальше.

Процесс управления уязвимостями. Конечно, речь не о базовом инструментальном сканировании и выявлении уязвимостей и дефектов конфигурации (тут даже ML на Python не нужен, не то что ИИ на Powerpoint — все работает на базовых алгоритмах). 2. Действительно разобраться, какой из активов сколько стоит, — задача, с которой даже живой безопасник часто разобраться не может. Задача — наложить выявленные уязвимости на фактическую карту активов, приоритизировать их в зависимости от критичности и стоимости активов, находящихся под угрозой, сформировать план… А вот здесь стоп. В России эту дорогу осилили не более десятка компаний. Процесс анализа рисков и оценки активов, как правило, умирает на этапе оценки стоимости информации или согласования этой оценки с бизнесом.

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

Анализ угроз. Когда мы наконец инвентаризировали все активы, поняли все ошибки конфигурации и возможные уязвимости, неплохо бы наложить на эту картинку известные вектора атак и техники работы злоумышленника. 3. Идеально добавить туда еще статистику по тестированию сотрудников на умение определять фишинг и возможности службы ИБ или SOC по выявлению инцидентов (объем подконтрольной части инфраструктуры, количество и типы отслеживаемых сценариев кибератак и т.д.). Это позволит нам оценить вероятность того, что атакующий сможет достичь цели.

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

И речь не об IoC, которые легко декомпозируются и применяются, а, в первую очередь, о TTP (Tactics, Techniques and Procedures) атакующих, которые влекут за собой гораздо более сложную цепочку условий («а при каких вводных я уязвим?»). 1. Техники и способы атаки злоумышленника тоже требуют входной машинной интерпретации. Даже базовый анализ известных техник матрицы Mitre подтверждает, что дерево событий будет очень разветвленным, и для корректного принятия решения об актуальности угрозы каждая развилка требует алгоритмизации.

И вероятности нестандартных, не описанных или напрямую не попадающих в TTP действий, здесь крайне немало. 2. В данном случае вполне себе искусственному нейронному мозгу противостоит естественный — злоумышленника.

Выявление/детектирование новых угроз/аномалий и т.д. Когда люди рассуждают о применении ИИ в SOC, обычно они подразумевают именно эти процессы. 4. Действительно, неограниченные вычислительные мощности, отсутствие разбитого фокуса внимания, Data Lake — чем не основа для того, чтобы ИИ начал выявлять новые аномалии и угрозы, раньше не фиксировали?

Применение ИИ в этой сфере ограничено четко обозначенным кругом прикладных задач, в общем случае он будет давать слишком много ложных срабатываний. Ключевая проблема в том, что для этого нужно как минимум кластеризовать деятельность по функциональным/бизнес-структурам и информационным активам (возвращаемся к пункту 1), иначе у всего огромного потока данных в нашем Data Lake не будет требуемого контекста для выявления аномалий.

Анализ инцидентов — это «единорог» всех любителей автоматизации в вопросах SOC: автоматически собираются все данные, фильтруются ложные срабатывания, принимаются обоснованные решения, а дверь в Нарнию таится в каждом платяном шкафу. 5.

Объем детектируемых аномалий может ежедневно меняться – не из-за растущего объема кибератак, а из-за обновления и изменения принципов работы прикладного ПО, изменения функционала пользователя, настроения ИТ-директора, фазы Луны и т.д. К сожалению, этот подход несовместим с тем уровнем бардака энтропии, который мы видим в информационных потоках организаций. Даже если забыть, какой огромный поток событий это спровоцирует, и на сколько порядков увеличится стоимость лицензии на на любой продукт, используемый в работе SOC, остаются еще колоссальные эксплуатационные расходы на поддержание такой инфраструктуры. Для того чтобы хоть как-то работать с инцидентами, получаемыми из Data Lake (а еще от систем UBA, NTA и т.д.), аналитику SOC нужно было бы не только долго и настойчиво гуглить вероятные причины такого странного поведения системы, но и иметь Full View информационных систем: видеть каждый запускаемый процесс и обновление, каждую корректировку реестра или флагов сетевого потока, понимать все производимые в системе действия. Это позволило очень качественно анализировать и расследовать все сетевые атаки, но заодно увеличило штат сетевых администраторов, поддерживающих это состояние, примерно на 60%. В одной из знакомых нам российских компаний удалось «причесать» все сетевые потоки, включить port security, настроить NAC — словом, сделать все по фен-шую. Стоит ли элегантное ИБ-решение таких дополнительных расходов — каждая компания решает и оценивает для себя.

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

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

Реагирование и ликвидация последствий инцидентов. Как ни странно, в этой части применение ИИ выглядит достаточно жизнеспособной моделью. 6. Да и в работе многих SOC базовые playbook на реагирование и блокировку могут выполняться даже не ИБ-, а ИТ-специалистами. Действительно, после качественного разбора, классификации и фильтрации ложных срабатываний, как правило, уже понятно, что делать. Это хорошее поле для возможного развития ИИ или более простых подходов к автоматизации.

Но, как всегда, возникают нюансы…

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

И, пока данная парадигма не прошла успешную проверку практикой и временем – хотя бы в полуручном режиме по отмашке от аналитика, говорить о передаче функции машине, пожалуй, преждевременно. В. Со стороны ИТ и бизнеса вы встретите резкое неприятие автоматизации даже базовых playbook по реагированию (блокирования IP-адресов и учетных записей, изоляции рабочей станции), так как все это чревато простоями и нарушением бизнес-процессов.

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

Skynet не готов победить

В финале хотелось бы выделить еще несколько очень важных, на наш взгляд, моментов, позволяющих в том числе ответить на частый вопрос: «А может ли ИИ заменить мне первую линию/команду Threat hunting/SOC целиком?».

Это можно наблюдать в любой из отраслей нашей экономики. Во-первых, даже на очень больших упорядоченных и автоматизированных производствах, где большая часть функционала отдана машинам, всегда присутствует оператор. Если мы автоматизируем или кибернетизируем задачи SOC, то автоматически возникает потребность в привлечении сильного профильного специалиста, который в состоянии быстро оценить импакто от машинной ошибки и результативность предпринятых действий. Задачи оператора в этом смысле детермированно простые — своим человеческим фактором исключить «машинный фактор» и своими руками стабилизировать ситуацию в случае сбоя/аварии/нарушения корректности процесса. Поэтому автоматизация и развитие ИИ даже в будущем вряд ли приведет к отказу от круглосуточной дежурной смены.

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть