Тематика искусственного интеллекта, зародившаяся еще в 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. Для подхода к задаче требуется на каком-то этапе создание условно стерильной среды, в которой мы все-таки знаем, кто есть кто и какие задачи решает. Процессы даже базового создания модели активов у большинства заказчиков… ну, в общем, не будем о грустном, вы и сами все знаете.
Тем не менее отметим перспективность применения ИИ в этой задаче как «когда-нибудь» и двинемся дальше.
2. Процесс управления уязвимостями. Конечно, речь не о базовом инструментальном сканировании и выявлении уязвимостей и дефектов конфигурации (тут даже ML на Python не нужен, не то что ИИ на Powerpoint — все работает на базовых алгоритмах). Задача — наложить выявленные уязвимости на фактическую карту активов, приоритизировать их в зависимости от критичности и стоимости активов, находящихся под угрозой, сформировать план… А вот здесь стоп. Действительно разобраться, какой из активов сколько стоит, — задача, с которой даже живой безопасник часто разобраться не может. Процесс анализа рисков и оценки активов, как правило, умирает на этапе оценки стоимости информации или согласования этой оценки с бизнесом. В России эту дорогу осилили не более десятка компаний.
Но, пожалуй, в облегченном режиме (когда стоимость ресурса или его критичность оценивается относительной 10- или 100-бальной шкалой), задачу решить точно можно. При этом вопросы автоматизации возвращают нас в первую очередь к предыдущему пункту — инвентаризации. После этого задача решается классическим статистическим анализом, без сложных ИИ-ухищрений.
3. Анализ угроз. Когда мы наконец инвентаризировали все активы, поняли все ошибки конфигурации и возможные уязвимости, неплохо бы наложить на эту картинку известные вектора атак и техники работы злоумышленника. Это позволит нам оценить вероятность того, что атакующий сможет достичь цели. Идеально добавить туда еще статистику по тестированию сотрудников на умение определять фишинг и возможности службы ИБ или SOC по выявлению инцидентов (объем подконтрольной части инфраструктуры, количество и типы отслеживаемых сценариев кибератак и т.д.).
Выглядит ли задача решаемой? При условии, что мы справились на предыдущих двух этапах, тут есть два ключевых нюанса.
1. Техники и способы атаки злоумышленника тоже требуют входной машинной интерпретации. И речь не об IoC, которые легко декомпозируются и применяются, а, в первую очередь, о TTP (Tactics, Techniques and Procedures) атакующих, которые влекут за собой гораздо более сложную цепочку условий («а при каких вводных я уязвим?»). Даже базовый анализ известных техник матрицы Mitre подтверждает, что дерево событий будет очень разветвленным, и для корректного принятия решения об актуальности угрозы каждая развилка требует алгоритмизации.
2. В данном случае вполне себе искусственному нейронному противостоит естественный — злоумышленника. И вероятности нестандартных, не описанных или напрямую не попадающих в TTP действий, здесь крайне немало.
4. Выявление/детектирование новых угроз/аномалий и т.д. Когда люди рассуждают о применении ИИ в SOC, обычно они подразумевают именно эти процессы. Действительно, неограниченные вычислительные мощности, отсутствие разбитого фокуса внимания, Data Lake — чем не основа для того, чтобы ИИ начал выявлять новые аномалии и угрозы, раньше не фиксировали?
Ключевая проблема в том, что для этого нужно как минимум кластеризовать деятельность по функциональным/бизнес-структурам и информационным активам (возвращаемся к пункту 1), иначе у всего огромного потока данных в нашем Data Lake не будет требуемого контекста для выявления аномалий. Применение ИИ в этой сфере ограничено четко обозначенным кругом прикладных задач, в общем случае он будет давать слишком много ложных срабатываний.
5. Анализ инцидентов — это «единорог» всех любителей автоматизации в вопросах SOC: автоматически собираются все данные, фильтруются ложные срабатывания, принимаются обоснованные решения, а дверь в Нарнию таится в каждом платяном шкафу.
К сожалению, этот подход несовместим с тем уровнем бардака энтропии, который мы видим в информационных потоках организаций. Объем детектируемых аномалий может ежедневно меняться – не из-за растущего объема кибератак, а из-за обновления и изменения принципов работы прикладного ПО, изменения функционала пользователя, настроения ИТ-директора, фазы Луны и т.д. Для того чтобы хоть как-то работать с инцидентами, получаемыми из Data Lake (а еще от систем UBA, NTA и т.д.), аналитику SOC нужно было бы не только долго и настойчиво гуглить вероятные причины такого странного поведения системы, но и иметь Full View информационных систем: видеть каждый запускаемый процесс и обновление, каждую корректировку реестра или флагов сетевого потока, понимать все производимые в системе действия. Даже если забыть, какой огромный поток событий это спровоцирует, и на сколько порядков увеличится стоимость лицензии на на любой продукт, используемый в работе SOC, остаются еще колоссальные эксплуатационные расходы на поддержание такой инфраструктуры. В одной из знакомых нам российских компаний удалось «причесать» все сетевые потоки, включить port security, настроить NAC — словом, сделать все по фен-шую. Это позволило очень качественно анализировать и расследовать все сетевые атаки, но заодно увеличило штат сетевых администраторов, поддерживающих это состояние, примерно на 60%. Стоит ли элегантное ИБ-решение таких дополнительных расходов — каждая компания решает и оценивает для себя.
Поэтому необходимым звеном в процессе анализа инцидентов по-прежнему остается телефонная трубка, общение с администраторами и пользователями, гипотезы, которые требуют проверки на стендах и т.д. А эти функции ИИ плохо делегируются.
В общем, пока что использованию ИИ в анализе инцидентов мы говорим строгое «не верю», но очень надеемся, что в скором времени мы сможем отдать ИИ хотя бы инвентаризацию активов и управление уязвимостями.
6. Реагирование и ликвидация последствий инцидентов. Как ни странно, в этой части применение ИИ выглядит достаточно жизнеспособной моделью. Действительно, после качественного разбора, классификации и фильтрации ложных срабатываний, как правило, уже понятно, что делать. Да и в работе многих SOC базовые playbook на реагирование и блокировку могут выполняться даже не ИБ-, а ИТ-специалистами. Это хорошее поле для возможного развития ИИ или более простых подходов к автоматизации.
Но, как всегда, возникают нюансы…
А. Еще раз подчеркну, что для успешной работы ИИ на данном этапе, необходимо, чтобы предыдущие прошел человек-аналитик, причем сделал это максимально полно и качественно. Это тоже не всегда простая задача.
В. Со стороны ИТ и бизнеса вы встретите резкое неприятие автоматизации даже базовых playbook по реагированию (блокирования IP-адресов и учетных записей, изоляции рабочей станции), так как все это чревато простоями и нарушением бизнес-процессов. И, пока данная парадигма не прошла успешную проверку практикой и временем – хотя бы в полуручном режиме по отмашке от аналитика, говорить о передаче функции машине, пожалуй, преждевременно.
Теперь посмотрим на ситуацию в целом. Часть процессов пока не отчуждаемы в пользу ИИ, часть требует проработки и поддержания полного контекста инфраструктуры. Кажется, время для широкого внедрения этих технологий еще не пришло — исключением является разве что задача повышения качества детектирования инцидентов за счет выявления аномалий. Однако есть основания полагать, что перечисленные задачи SOC в принципе поддаются автоматизации, а значит, в дальней перспективе ИИ вполне может найти там свое место.
Skynet не готов победить
В финале хотелось бы выделить еще несколько очень важных, на наш взгляд, моментов, позволяющих в том числе ответить на частый вопрос: «А может ли ИИ заменить мне первую линию/команду Threat hunting/SOC целиком?».
Во-первых, даже на очень больших упорядоченных и автоматизированных производствах, где большая часть функционала отдана машинам, всегда присутствует оператор. Это можно наблюдать в любой из отраслей нашей экономики. Задачи оператора в этом смысле детермированно простые — своим человеческим фактором исключить «машинный фактор» и своими руками стабилизировать ситуацию в случае сбоя/аварии/нарушения корректности процесса. Если мы автоматизируем или кибернетизируем задачи SOC, то автоматически возникает потребность в привлечении сильного профильного специалиста, который в состоянии быстро оценить импакто от машинной ошибки и результативность предпринятых действий. Поэтому автоматизация и развитие ИИ даже в будущем вряд ли приведет к отказу от круглосуточной дежурной смены.
Во-вторых, как мы увидели, любой ИИ так или иначе требует пополнения знаний и обратной связи. Причем в случае SOC — не только об изменении векторов атак или внешнего информационного контекста (что в теории может быть частью обучения/экспертных пакетов и т.д), но, в первую очередь, информационного контекста ваших инцидентов, вашей организации и бизнес-процессов. Значит, заменить штатных экспертов-аналитиков ИИ тоже не сможет. По крайней мере, в ближайшем будущем.
Таким образом, на наш взгляд, любые подходы к интеграции ИИ в SOC на текущем этапе можно рассматривать лишь как элементы автоматизации работы с контекстом и решения некоторых подзадач аналитики. К полной передаче в руки роботов такой сложный процесс, как обеспечение ИБ, пока не готов.
Автор: Solar_JSOC
