Интервью с Денисом Кувшиновым (Positive Technologies): ИИ и Threat Intelligence в кибербезопасности

Денис Кувшинов, Positive Technologies: Процесс реверс-инжиниринга постепенно сводится к тому, что ты проверяешь, что нареверсил ИИ

Денис Кувшинов, Positive Technologies: Процесс реверс-инжиниринга постепенно сводится к тому, что ты проверяешь, что нареверсил ИИ

Денис Кувшинов

Руководитель направления Threat Intelligence и сервиса PT Fusion от Positive Technologies

Окончил МГТУ им. Н. Э. Баумана в 2017 году.

Работал в компании «Информзащита». К команде Positive Technologies присоединился в 2017 году. Прошёл путь от специалиста отдела мониторинга информационной безопасности до руководителя направления Threat Intelligence экспертного центра безопасности Positive Technologies (PT Expert Security Center).

В зону ответственности его подразделения входят поиск новых хакерских группировок и отслеживание активности известных группировок, атакующих организации на территории РФ, анализ вредоносных программ, передача экспертных данных, включая индикаторы компрометации, для использования в продуктах Positive Technologies, поиск вредоносного кода в проектах с открытым исходным кодом.

Также Денис отвечает за развитие PT Fusion — сервиса киберразведки, который предоставляет специалистам ИБ данные об актуальных угрозах и инструменты для их анализа.

Постоянный спикер профильных российских и международных конференций. Среди прочего выступал на PHDays, Standoff 10, SAS, AVAR, GISEC, OffZone, SOC Forum.

...

Представьте: ночью компанию атакуют хакеры. ИИ самостоятельно восстанавливает ход атаки, выявляет системы под угрозой, выбирает защиту и останавливает вторжение. Утром аналитик получает готовый отчёт. Насколько реален такой сценарий уже сегодня? Обсудили с Денисом Кувшиновым, руководителем направления Threat Intelligence и сервиса PT Fusion в Positive Technologies.

Денис, как вы думаете, описанный сценарий станет реальностью в ближайшие три-пять лет?

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

Какую задачу решала киберразведка (тот самый Threat Intelligence), когда вы начинали работать в роли SOC-аналитика, и чего ей тогда не хватало?

Д. К.: Да, 10 лет назад я пришёл в Positive Technologies работать SOC-аналитиком, проработал буквально полгода и даже меньше — наверное, 3–4 месяца. И меня сразу переключили на задачу именно киберразведки. В тот момент были актуальны атаки на банки, когда группировки Cobalt, Silence потрошили банкоматы: дроп приходил к банкомату, вставлял карту, и банкомат выдавал все деньги — там несколько миллионов. Тогда мне было очень интересно разбираться в том, как вообще проводятся такие атаки на банки. Всегда практически они начинались с фишинга — такие базовые вещи. Для меня это было очень интересно.

Я помогал больше именно команде по реагированию. То есть ребята мне приносили образцы вредоносных программ, какие-то индикаторы компрометации, и я помогал им находить допследы. И в тот момент мне больше всего не хватало данных. Даже не столько, наверное, скорости нахождения этих данных, а вообще источников этих данных. Тогда киберразведка в Positive Technologies — да и в целом в мире — только зарождалась. Было модно эти данные начинать накапливать, и в начале пути мне этих данных как раз-таки и не хватало. 

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

Д. К.: Если говорить об атаках, то мы тогда отслеживали одну группировку, которая атаковала правительственные организации в России и Беларуси. Мы называли её SongXY, и на тот момент не понимали, что это за группировка: известная она или нет, находил ли её кто-то ещё или мы первые. В какой-то момент мы обнаружили интересный артефакт в макросе одного из документов, который помог установить связь этой группировки с уже известной и шире взглянуть на географию этих атак. Это как раз иллюстрирует те данные, о которых я говорю: в момент накопления их стало достаточно, и мы поняли, что столкнулись с известной угрозой.

Получается, что за это время киберразведка прошла путь от сбора каких-то разрозненных следов к системе, которая помогает принимать решения?

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

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

Кому вообще нужен TI?

Д. К.: Я отвечаю за продуктовое направление TI, поэтому готов сказать, что он нужен всем, но на практике это не совсем так. Threat Intelligence — это в некоторой степени вишенка на торте, когда экосистема защиты уже построена и работает для защиты инфраструктуры. TI добавляет в эту экосистему знания о том, кто потенциально может вас атаковать.

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

Как компании определить, что она созрела для внедрения Threat Intelligence?

Д. К.: Обычно это происходит, когда SOC растёт: расширяются первая, вторая и третья линии, и наступает момент, когда специалисты перестают понимать, с какими угрозами им бороться. Возникает вопрос: на какие угрозы писать правила корреляции, чтобы защититься? Какие техники и индикаторы компрометации активны сейчас? Кого атаковали, например, вчера?

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

То есть они достигают определённого потолка в развитии, и им нужна оркестрация уже имеющихся инструментов и процессов?

Д. К.: Это не совсем оркестрация — скорее информация о подготовке к атаке и защите от неё. Потому что даже большой SOC не может защититься от всего. Хакеры атакуют, я бы сказал, определённые отрасли — например, производство. Существует класс угроз, нацеленных именно на промышленность.

Понятно, что массовые угрозы затрагивают и производство, и госсектор, и финансовый сектор, но некоторые специфические угрозы направлены только на производство. Как именно они атакуют — неизвестно, и SOC не всегда понимает, каким образом злоумышленники действуют против промышленности. Как раз эту информацию TI собирает из материалов об инцидентах, отчётов и собственных источников, аккумулирует её, а затем ею пользуются специалисты SOC. Дальше это развивается в различные процессы — Threat Hunting, Purple Teaming и тому подобное.

Какой самый простой признак показывает, что TI в компании действительно работает? Например, что произойдёт, если его убрать из компании на неделю?

Д. К.: TI обычно становится нужен, когда что-то происходит — по опыту, это самый востребованный инструмент в такие моменты. У вас инцидент, есть какой-то индикатор или файл, и вы задаётесь вопросом: «А что это такое?» Это нужно где-то проверить, откуда-то взять информацию. Даже если известно название угрозы, вы не знаете, как с ней бороться и что она предпримет. Например, вы поймали её на этапе закрепления в инфраструктуре, но что она будет делать дальше и как попала — неизвестно.

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

Перейдём к практике. Что представляет собой PT Fusion?

Д. К.: PT Fusion — это единый портал знаний о киберугрозах. Как я уже говорил, в рамках построения киберразведки в Positive Technologies у нас существует множество различных систем, которые анализируют угрозы: это анализ файлов, индикаторов компрометации, данных даркнета, проверка файлов — очень много систем.

И в какой-то момент мы поняли, что ранее продавали фиды — это понятная тема. Но от клиента всегда поступал запрос: «А что значит этот контекст по фидам? Откуда он был получен? Какие ещё есть связанные индикаторы?» И мы подумали, что было бы хорошо сделать такую платформу, где мы не только можем что-то анализировать и собирать, но и предоставить это клиентам. Причём не просто дать веб-интерфейс, а, например, предоставить доступ ко всей накопленной базе, к разным системам, в том числе через API, к которому можно подключить искусственный интеллект, чтобы он в процессе мониторинга брал информацию киберразведки из наших баз.

PT Fusion подключается по подписке?

Д. К.: Да, по подписке. По сути, это облачная платформа, которая поставляется как сервис. У неё есть свои лимиты и ограничения в зависимости от уровня подписки, но мы стараемся быть максимально открытыми к клиентам. Они хотят получать информацию об индикаторе, проверять файлы, получать данные по подозрительным объектам, регистрационную информацию по домену, сведения о сущности — всё это доступно через API.

У нас уже было несколько кейсов, когда клиент приходил и говорил: «У меня есть модель, я подключу ваш API к ней, и она будет анализировать события, брать информацию по индикаторам компрометации из вашей базы и формировать отчёт для меня или для аналитиков». Это очень удобно: ему не нужно заходить в интерфейс, модель сама смотрит данные, а аналитик затем изучает готовый отчёт.

Напрашивается вопрос: зачем платить за ваш продукт, если можно обратиться к публичным отчётам и открытым фидам? В чём заключается уникальность ваших данных?

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

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

 

 

Хотелось бы также разобраться, где проходит граница между PT Fusion и другими системами. Что вы делаете сами, а что должны делать SIEM, EDR и SOC?

Д. К.: Сам PT Fusion не столько детектирует, сколько служит базой знаний. Например, в SIEM появляется алерт — командная строка, ключ реестра или индикатор компрометации. Но к какой угрозе это относится, не совсем понятно: это APT-атака, вымогатели или просто залётный майнер, который занесли через флешку? Накопленная база знаний, собранная в ходе расследований и киберразведки, помогает во время мониторинга классифицировать эти данные и дать им контекст. То есть понять, с какой угрозой мы боремся и как она действует, — это в некоторой степени экономия времени.

Когда мы проводим исследование или расследование, решающим элементом становится скорость реагирования и его правильность. В какую сторону двигаться дальше? Закрывать инцидент сейчас, потому что мы всё сделали, или где-то ещё не досмотрели? Возможно, нужно что-то дополнительно поискать.

Какую роль играет искусственный интеллект в PT Fusion? 

Д. К.: С появлением моделей вроде GPT-5 и подобных роль аналитика постепенно размывается, и я бы сказал, что она подходит к своему логическому исчезновению из-за автоматизации. Сбор информации сейчас можно выполнять с помощью агентов. Я, честно говоря, в некоторой степени ошеломлён развитием таких технологий. То, что когда-то делал я руками и очень радовался, когда что-то находил, сейчас можно сделать за секунды по тем системам, которые у нас есть.

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

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

Д. К.: Соответственно, в SIEM он видит сработку: такой-то процесс на такой-то машине начал обращаться к некоему ресурсу. Если в SIEM или другом средстве мониторинга трафика он видит сработку сигнатуры либо по фидам определяет, что индикатор компрометации указывает на нелегитимный ресурс, он идёт его исследовать: что это за ресурс, к какой угрозе относится. Если понимает, что это не ложное срабатывание, а нечто действительно подозрительное, принимает решение реагировать. Машину могут отключить от сети, провести расследование и выяснить, что пользователь открыл файл, который начал обращаться к нелегитимному ресурсу. Образно сейчас это выглядит именно так.

Понятно. Но где здесь тогда искусственный интеллект?

Д. К.: Агент подключается поверх PT Fusion. Он понимает, какие есть API-ручки и скиллы и для чего они предназначены, в том числе через подключение по MCP-серверу. Например, мы в SOC развиваем проект Naira от Positive Technologies, и мы в рамках своего департамента тестируем различные агенты. Когда происходит сработка, агент сразу обращается к базе, собирает нужный контекст, а при необходимости дополняет его.

Затем он сообщает аналитику: «Смотри, я собрал контекст: такой-то IP-адрес используется такой-то группировкой, её видели тогда-то». Может даже указать, в каком отчёте это упоминалось, если информация была в открытых источниках, и рассказать, что эта группировка атакует через фишинг и действует определённым образом. Аналитик отвечает: «Хорошо».

Давайте перейдём к обсуждению Design Intelligence. Разложим всё по полочкам: есть база знаний — PT Fusion. В ней аналитик может самостоятельно работать вручную, а может подключить агента — того самого Design Intelligence?

Д. К.: Это касается SOC, где сейчас активно обсуждается автоматизация. Нужны агенты, которые будут помогать — даже объяснять, что происходит в SIEM: инцидент или срабатывание правила корреляции.

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

И сверху мы накладываем уже Design Intelligence как философию, правильно? Чем она отличается от обычного SIEM?

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

В отчётах Mandiant и CrowdStrike приводились данные: минимальное время атаки в прошлом году от компрометации до шифрования составило 22–26 секунд. Что SOC-аналитик может сделать за это время? EDR сработает (если он установлен) или антивирус. То есть мы находимся в ситуации, когда хакеры ускоряются за счёт искусственного интеллекта, а защитники, я бы сказал, пока не сильно. Мы не отдаём автономность и принятие решений Design Intelligence на откуп автоматизации.

Вернёмся к гипотезам. Как ИИ их строит? 

Д. К.: Как действуют аналитики? Есть индикаторы компрометации (IoC), и есть TTP — тактики, техники и процедуры. Самое важное — это не IoC, поскольку они быстро устаревают и могут быть нерелевантны вашей организации. Даже если вы в одной отрасли, это не значит, что вас будут атаковать — это скорее перестраховка от возможного нападения.

Если говорить о TTP, широта их применения больше. Во-первых, они не так сильно устаревают: от атаки к атаке хакеры могут их не менять. Но в эпоху развития искусственного интеллекта и автоматизированных атак, с которыми мы пока не сталкивались в рамках атак на Россию, они могут быть изменчивыми. Сейчас мы видим, что несколько месяцев подряд хакеры могут их не менять. И пока про них не написан публичный отчёт, их, в принципе, можно использовать. Обычно после этого они их меняют.

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

На их основе можно строить гипотезы. Во-первых, гипотеза используется для поиска компрометаций в инфраструктуре — не закрепились ли у меня где-то хакеры с помощью этой техники. Во-вторых, для своего рода киберучений внутри инфраструктуры, когда вы симулируете действия хакеров — это называется Purple Teaming — и смотрите, как средства защиты реагируют на ту или иную команду. Может оказаться, что вендор плохо покрыл эту технику, и если хакер к вам залетит и начнёт это делать, вы даже не увидите — это не будет покрыто реагированием.

Вы ведь не единственный игрок на рынке TI? Нужно ли клиенту устанавливать два TI-решения или, возможно, вы как-то договоритесь и будете обмениваться базами данных с конкурентами?

Д. К.: Подобные идеи обсуждались, но в условиях коммерческого рынка вряд ли кто-то станет так поступать — все зарабатывают деньги. Кроме того, специалисты обычно советуют выбирать нескольких поставщиков TI, поскольку у каждого свои данные, источники, команды реагирования, SOC, MSSP и EDR. У кого-то данные лучше, у кого-то хуже. Если говорить о зарубежном опыте, то, общаясь с заказчиками, я вижу, что там может быть семь-восемь поставщиков TI, и они вполне нормально сосуществуют. В России же столько игроков на рынке TI просто нет.

А какая практика в России? 

Д. К.: В основном выбирают одного поставщика, иногда встречаются два, а о трёх я ни разу не слышал. Обычно данные стараются интегрировать в какую-то единую точку внутри компании — например, в платформу OpenCTI или коммерческое решение. Кстати, сама платформа в этом случае становится третьим игроком, поскольку все данные с разных вендоров TI стараются агрегировать у себя внутри, иногда даже обогащая их собственными сведениями.

То есть, условно говоря, это какая-то свеженькая библиотека?

Д. К.: Да. Выбирают по-разному. Кто-то отдаёт предпочтение конкретной компании: «Только вы, и больше никто». А кто-то подходит к выбору дотошно, проводит полное сравнение функциональности — что есть, чего нет, — оценивает цену и другие критерии. Признаки могут быть самыми разными.

А какие отношения у вас с другими вендорами TI?

Д. К.: Поскольку мы являемся вендором TI и в определённой степени конкурируем, мы не продаём свои данные друг другу — это считается моветоном.

Мы обсудили, как искусственный интеллект ищет информацию, на чём основываются его рекомендации и кому они адресованы. Теперь логично перейти к вопросу о том, как он будет действовать — поговорим об автономности.

Д. К.: Это, пожалуй, самое сложное. В концепции Design Intelligence главное — отсутствие галлюцинаций, чтобы не случилось чего-то непоправимого. Сейчас к этому точно никто не готов. Как я говорил, речь скорее о горизонте пяти лет — если не произойдёт кратного скачка в локальных моделях, поскольку не все готовы передавать данные даже внешним моделям. Я имею в виду именно внутренние модели.

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

Что вы готовы доверить ИИ уже сейчас?

Д. К.: Может, конечно. Например, обнаружена свежая утечка информации — есть логин и пароль бухгалтера, которые утекли с его личного устройства. Сейчас между тем, как учётку «слили», и тем, как её заблокировали, проходит точно больше суток: пока информация от вендора дойдёт до клиента, пока клиент примет решение. Если речь об автоматической блокировке, то TI сразу передаёт агенту внутри компании данные: «Учётка такая-то с таким-то паролем». Агент проверяет внутри и сразу блокирует, а разбираться можно потом. Это секунды.

Здесь вопрос просто риск-менеджмента в компании — готовы ли они рисковать такими утечками. Если хакер зайдёт через эту учётку в инфраструктуру, начнёт что-то делать, красть документы, шифровать, рассылать дальше спам — это уже денежные вопросы. Но всё сводится к тому, насколько компания готова к таким рискам.

Какие действия вы бы доверили ИИ в первую очередь: блокировку учётной записи, домена или отключение устройства? 

Д. К.: Я бы начал с блокировки некоторых индикаторов компрометации. Многие компании отслеживают появление фишинговых доменов, зарегистрированных под их бренд, — такие домены можно автоматически блокировать через ИИ: добавлять в red-листы SIEM, на NGFW и так далее. Это можно сделать быстро, поскольку особым риском вы здесь не подвергаетесь. А вот если речь о блокировке учётных записей, нужен надёжный источник информации.

Вендор должен доказать, что собирает качественные данные: они не дублируются, не берутся со старых «помоек» — словом, действительно хорошие. То есть здесь необходима ещё и оценка вендора.

Всё зависит от уверенности модели, критичности актива, обратимости действия и возможного ущерба от промедления?

Д. К.: Да, потому что блокировка может нанести больше вреда, чем пользы. Такое тоже возможно.

То есть нужно взвесить, что опаснее: ошибочное действие или потерянное время при реагировании, бездействие? И кто должен это определять — человек?

Д. К.: Я бы сказал, да — каждый определяет это индивидуально на своём уровне бизнес-процессов. Обычно те, кто уже сталкивался с масштабными инцидентами, к этому готовы, потому что понимают величину возможных потерь и уже знакомы с издержками от простоев. А они могут исчисляться миллиардами.

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

Здесь возникает закономерный вопрос: кто будет нести ответственность, если агент совершит ошибочное действие и что-то заблокирует? Кто вообще может отвечать в такой ситуации — разработчик, поставщик TI, который предоставил некорректные данные, CISO или сотрудник, разрешивший автономный режим?

Д. К.: Здесь начинается цепочка. SOC ведь тоже ошибается — нет такого SOC, который никогда не ошибался. Блокируются учётные записи, машины, бывает и по ложному срабатыванию. Обычно спрашивают: CISO, руководитель SOC, кто заблокировал? Потом идут к аналитику, а если дело в данных вендора — к вендору: «Почему сработало именно так?» Начинается цепочка, как при расследовании: откуда, куда и почему.

Получается, искусственный интеллект никто не накажет в итоге?

Д. К.: Я бы сказал, что нет — это же технология, её нельзя наказать. 

Стоит ли компаниям бояться внедрения ИИ?

Д. К.: Точно не нужно этого бояться и не нужно отрицать. Ещё недавно все думали: «Можно писать код с помощью ИИ, но нас-то никогда не заменят». А сейчас разработка уже немыслима без ИИ. Конечно, проверка после того, как модель выдала заказанный ей код, остаётся, но уйти от этого процесса уже не получится. Думаю, с безопасностью будет то же самое: все придут к тому, что нужно сокращать время и удешевлять технологии за счёт ИИ, чтобы сделать защиту более эффективной.

Возвращаясь к роли аналитика: останется ли она, если мы говорим о горизонте трёх-пяти лет, или это всё будут делать автономные ИИ-агенты на хорошей базе TI?

Д. К.: Да. Если говорить об аналитиках SOC, то, думаю, первая линия, скорее всего, исчезнет. На первой и второй линиях людей практически не останется. Останутся те, кто будет в определённой степени контролировать действия ИИ — своего рода третья линия — и заниматься расследованиями. Пока моё видение такое; поменяется ли оно от года к году и что будет дальше — посмотрим. А если говорить об аналитиках TI, у меня складывается ощущение, что через два года можно будет автоматизировать весь процесс исследований и даже не проверять.

Вы начинали как аналитик. Что посоветуете молодым специалистам, которые хотят работать в киберразведке? 

Д. К.: В любом случае это базовые технологии. Самое важное, что я сейчас вижу: любой специалист должен обладать навыком автоматизации. В нашей работе, если ты не умеешь автоматизировать, то тебе придётся тяжело. Любой аналитик сейчас что-то делает с помощью ИИ. Аналитик SOC, аналитик TI, специалист по реагированию — все вайбкодят. Без этого навыка ИБ-специалисту будет сложно влиться, потому что нужно что-то дорабатывать, писать вспомогательные системы.

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

Получается, он будет неким продвинутым SOC-аналитиком, а джуны — искать для него то, что он, допустим, как руководитель, будет определять?

Д. К.: Нет, а зачем ему самому искать? У него нет ни рук, ни головы — у него множество проводов и вычислительных ресурсов, которые он подключает к базам знаний. Эти знания он, в принципе, может собирать самостоятельно и уже на их основе делать выводы.

Что вы готовы доверить ИИ уже сейчас? Может ли он самостоятельно что-то блокировать? 

Д. К.: То, что уже готово сейчас, — это строго рекомендации. Искать и собирать он может, мы это проверили, без проблем. Рекомендации зависят от задачи: написать запрос для Threat Hunting по определённым правилам или найти инфраструктуру хакеров по базе знаний — всё это он умеет. Но автономность — например, написать отчёт по атаке группировки или найти новые атаки — пока недоступна. Сейчас это просто Copilot для аналитика.

Мы движемся в сторону внедрения агентов в киберразведку — думаю, через год он сможет писать отчёты. Ты даёшь ему какие-то полузнания, он формирует отчёт, который можно отдать клиенту или опубликовать. А затем, когда мы соединим рекомендательную часть, поисковую и генерацию отчётов, он уже сам, как аналитик, сможет делать то, что нужно. Через три года, примерно.

Появится ли у вас отдельный продукт? Начнёт ли Positive Technologies продавать таких агентов?

Д. К.: Мы уже продаём такие решения: у нас есть PT Naira — по сути, это Copilot для SOC-аналитика. Он представлен не только в SOC, но и в продукте PT AI, который отвечает за безопасность процессов DevSecOps. Уже сейчас он даёт рекомендации: опираясь на предыдущие события и инциденты, сообщает: «Смотри, мы это уже видели, не обращай внимания — я пометил, что это встречалось раньше». Это, в принципе, не совсем новая технология. Но его можно усилить за счёт киберразведки, и мы сейчас движемся в эту сторону, чтобы интегрировать наши данные. Тогда он будет помогать SOC-аналитику не только на основе событий и схем, но и с мощью киберразведки. Однако об автономности пока сказать не могу — я не разрабатываю этот продукт.

Через три года посмотрим.

Д. К.: Мне кажется, три года — хороший срок. Сейчас всё ускоряется настолько, что уже не помнишь, когда это началось, а мы уже здесь.

Мы обсудили, как ИИ будет накладываться сверху. А как он сейчас устроен в самом Threat Intelligence и какие он там уже решает задачи?

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

Ты задаёшь алгоритм: что и куда сложить, какие данные в какой формат привести. На выходе получаешь небольшой отчёт или файл, который загружаешь в систему. В потоковом режиме это работает отлично, и аналитик не тратит на это время. Если же ему нужно почитать про угрозу, он идёт в базу знаний TI, в наш PT Fusion, смотрит на угрозу, видит связанные с ней отчёты и решает: «Вот это почитаю, потому что похоже на мой кейс с атакой». И уже с этим ознакамливается.

Правильно ли я понимаю, что в недалёком будущем искусственный интеллект будет работать в TI, самостоятельно составлять отчёты, систематизировать их и передавать искусственному интеллекту SOC?

Д. К.: Я думаю, это будет своего рода обмен знаниями. Сейчас отчёты публикуются на нашем сайте, другие вендоры тоже их публикуют. В дальнейшем это может стать обменом между базами. Но если история останется коммерческой, такого обмена не будет. Мы будем подключать базу TI, содержащую знания вендора, к агенту клиента, и он будет ею пользоваться. Либо клиент подключит несколько баз от разных вендоров. Некоторые крупные банки так и делают: у них несколько поставщиков, они связывают их, и агенты смотрят данные оттуда.

Мы также сейчас тестируем автоисследование инфраструктуры хакеров. У нас есть система со слепком интернета: домены, поддомены, связи, IP-адреса, DNS-записи, регистрационные данные. Мы даём на вход домен с запросом найти связанные с ним ресурсы, система ходит по всей базе, ищет похожие и выдаёт кандидатов, а аналитик уже их смотрит. У каждого кандидата указано, почему он был найден. Помню кейс, когда мы исследовали инфраструктуру группировки DarkGaboon: я делал это руками, а потом мы попросили ИИ — и он нашёл больше. Эффект уже есть.

Ещё одна история — реверс вредоносных программ, поскольку мой отдел в команде реагирования помогает исследовать их образцы. У клиента произошёл инцидент, образцы приносят нам, мы быстро смотрим и говорим: «Вот такой-то контрольный сервер, делайте то-то». С помощью ИИ мы подключаем плагин к IDA, отправляем базовые функции агенту, и он объясняет, что делает дизассемблированный код. Сейчас уже можно отдать ИИ всю программу — это будет не очень быстро и, возможно, не очень хорошо, но общий концепт работы, особенно если вредоносная программа не упакована и не обфусцирована, он опишет: команды, артефакты, контрольный сервер. 

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

А как избежать этого?

Д. К.: Перепроверять.

Достаточно ли ей сказать: «Не ври мне»?

Д. К.: Этого недостаточно. Она может придумать — не соврёт, но всё равно придумает, особенно если это локальная модель. А если говорить даже о Gemini, GPT или DeepSeek, то недавно обнаружили функцию: даёшь ей файл, она его анализирует, а если там есть URL — переходит по нему, скачивает содержимое, тоже анализирует и отдаёт отчёт. То есть это полностью работа аналитика: ты просто получаешь финальный отчёт.

Вы общаетесь с заказчиками. Какие сомнения по поводу TI возникают у них чаще всего?

Д. К.: Сейчас в России сохраняется базовая проблема с TI: мы пока ещё недалеко ушли от убеждения, что TI — это фиды. Почему так? Потому что нет людей, которые будут с ним работать. Фиды — понятная тема: скачали, установили в СЗИ, и это работает. Аналитику SOC остаётся сказать: «Вот тут инцидент, там фиды сработали».

Что может измениться в будущем с появлением автоматизации работы с TI? Она уже есть — например, обогащение в SOAR. Но если говорить о полноценной сборке артефактов по угрозе из базы TI, сейчас это должен делать человек: увидеть, что это группировка DarkGaboon, Cloud Atlas или GOFI, пойти в базу TI, посмотреть связанные индикаторы компрометации и TTP, проверить их у себя, провести Threat Hunting. Такой процесс может занять сутки, и не факт, что вы что-то найдёте. Поиск угроз — работа не очень благодарная: в 99% случаев вы ничего не найдёте. Может быть, у вас сеть хорошо защищена, то есть фишинг долетает, но никто не открывает письма, и дальше уже ничего не происходит.

Именно здесь автоматизация будет хорошо спасать SOC: мы покупаем агента у компании, устанавливаем у себя, и он выполняет Threat Hunting по сохранённым событиям SIEM. Плюс подключён TI, который поступает от Positive Technologies, — и всё отлично работает. Мы получаем инциденты, если что-то в рамках Threat Hunting было найдено. Если нет — значит, нет. Так мы экономим деньги на оплате специалистов и ментальное здоровье аналитика, который занимается поиском угроз.

То есть мы разрушаем стереотип о том, что TI — это только фиды. Какие ещё существуют стереотипы и предубеждения против Threat Intelligence?

Д. К.: Наверное, это предубеждение — что TI от одного вендора знает всё. Это точно не всегда так. Часто сталкиваешься с вопросом: почему этот индикатор красный на VirusTotal, а у вас он либо никак не отмечен, либо вообще числится чистым? Я объясняю: во-первых, на VirusTotal представлены десятки вендоров; во-вторых, красный индикатор там не означает, что объект вредоносный. Он мог быть вредоносным когда-то, может быть неактуальной угрозой для вас, либо метрики непонятны — там просто вердикт, и всё.

Как аналитику действовать, если два поставщика TI дают противоречивые сведения об одном индикаторе? 

Д. К.: Свежесть — это довольно условный критерий. Мне кажется, когда вы покупаете TI, вы ему доверяете. Вы же его пилотируете, понимаете, что бывают ошибки и ложные срабатывания. Но вы приобрели его за что-то — за хорошие данные, значит, вы доверяете вендору. Если купили второй TI, то тоже не просто так: это в любом случае недешёвое удовольствие, поскольку это продукт, который формируется в компании годами, а собранными данными такие компании дорожат.

Значит, нужен третий TI?

Д. К.: Нет, понятное дело, что мы смотрим в совокупности. Модель тоже будет принимать решение по многим факторам: не только по детектору или контексту, но и по связи с чем-то. Аналитик будет долго проверять такую связь, а модель за секунду сходит на какой-то IP и проверит. Это то, что нужно проверять.

Ещё одно предубеждение касается стоимости TI. Почему все выбирают фиды? Как я уже сказал, это понятная история. Чем больше доступа к данным вы даёте компаниям, тем дороже это становится. Потому что аналитик, который всё собирал, или система, которая собирала, — это стоит денег и закладывается в лицензию. У всех разные финансовые политики, разный ценник и разный доступ к данным. 

В любом случае ценность оценивает клиент: надо ли ему это и поможет ли улучшить процессы. Например, SOC-аналитик, работающий с SIEM, видит ценность, потому что говорит: «Смотрите, я нашёл инцидент благодаря порталу, увидел, что там такая группировка, нашёл связанные индикаторы, проверил — у нас всё чисто». А человек, принимающий решение, может сказать: «Зачем это? Ты же сидишь и мониторишь».

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

Когда компания обычно осознаёт ценность TI — во время пилотного внедрения или после реального инцидента? 

Д. К.: Пока не произойдёт какой-то инцидент. У меня есть клиенты, которые поняли, что им нужен TI, попробовав PT Fusion. Они говорили: «Нам что-то прислали, нужно это проверить». Я отвечал: «Пожалуйста, пробуйте». И они приходили к выводу: «Вообще класс, мы поняли, что это за группировка, всё проверили — отлично». А бывает иначе: люди смотрят на рынок TI и говорят: «Интересно, но мы не знаем, что с этим делать».

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

Денис, спасибо за честный и откровенный разговор про Threat Intelligence! Удачи и развития вашей компании!

Подпишитесь на новости

RSS: популярные интервью на Anti-Malware.ru