Интервью с Алексеем Булиховым, техническим директором компании Spacebit

Алексей Булихов: Можем ли мы доверить ИИ управление процессами реагирования?

Алексей Булихов: Можем ли мы доверить ИИ управление процессами реагирования?

Алексей Булихов

Технический директор Spacebit

Родился в г. Каспийске (Дагестан). В 1997 г. окончил Дагестанский государственный политехнический институт (ныне — технический университет) по специальности «Вычислительные машины, комплексы, системы и сети». В Дагестане работал в нескольких госкомпаниях в области разработки ПО. В 2001 г. переехал в Москву. В Москве получил ещё несколько образований, в том числе MBA в международной школе бизнеса MIRBIS по специальности «Стратегический менеджмент». В различных компаниях реализовывал ИТ-инфраструктурные проекты масштаба страны, участвуя в них в различных ролях, от инженерных до управленческих. Участвовал в проектах бизнес-консалтинга совместно с коллегами из Ernst & Young. Также, руководя различными подразделениями, выстраивал бизнес-процессы и сервисы, помогал руководителям крупных компаний достигать бизнес-целей.

...

Мы постоянно знакомим наших читателей с новинками на российском рынке ИБ. Большинство производителей до сих пор традиционно ориентировались на организации крупного, реже — среднего бизнеса. В условиях новой реальности, когда ландшафт угроз изменился до неузнаваемости и достиг колоссальных размеров, никто не чувствует себя защищённым. Хуже всех, пожалуй, приходится тем компаниям, которые относятся к малому бизнесу. Может ли рынок предложить что-то для их защиты? Об этом нам рассказал Алексей Булихов, технический директор компании Spacebit, выпустившей на рынок IRP-решение для защиты организаций малого и среднего бизнеса.

Мы знаем вашу компанию прежде всего по таким продуктам, как X-Control и X-Config. Но сегодня хотелось бы поговорить о вашем новом решении — SpaceView. Что это такое и какие задачи позволяет решить этот продукт?

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

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

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

IRP называют ещё SOAR-решениями. На российском рынке именно эта аббревиатура встречается наиболее часто. Считаете ли вы, что это одно и то же? Почему ваше решение является продуктом именно класса IRP?

А. Б.: Разница всё же существует, и для кого-то она даже значительна — например, для таких компаний, как R-Vision. Прежде чем переименовать свой очередной IRP-продукт в SOAR, они в течение шести-семи лет выпускали большое количество промежуточных версий, постепенно дополнявших и расширявших изначальную функциональность IRP.

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

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

При этом имеющиеся сейчас на рынке IRP- и SOAR-решения ориентированы на крупных заказчиков, так уж сложилось исторически. 

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

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

Для меня стало откровением, когда я прочитал в аналитическом обзоре за 2022 год, подготовленном Positive Technologies и «Лабораторией Касперского», о том, что 28 процентов атак — а это практически каждая третья, — которые привели к проблеме нарушения конфиденциальности персональных данных, были проведены с использованием ИИ.

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

А. Б.: Совершенно верно. Итак, можно говорить о том, что атаки выросли количественно и качественно.

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

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

Строилась классическая модель нарушителя и угроз, по которой подбирались адекватные угрозам защитные действия. Таким образом, построение SOC для малого и среднего бизнеса рассматривалось как что-то чрезмерное.

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

А. Б.: Возвращаясь к тому, о чём я начал говорить: мы убедились в том, что малым и средним бизнесом не то чтобы никто не занимался, но никто не задумывался о том, чтобы защищать его так же серьёзно, как и более крупные организации, то есть с помощью SOC. Считалось, что достаточно установить единичные простые решения, например антивирусы или WAF. Возможно, были отдельные случаи, когда использовались EDR или SIEM, но это и всё.

Что требуется для полноценного и эффективного внедрения вашего продукта со стороны заказчиков? Обязательно ли, например, наличие SOC? Ведь оно слабо соотносится с понятием «малый бизнес».

А. Б.: Наличие SOC не является необходимым условием, но я полагаю, что он в самом ближайшем будущем начнёт рассматриваться малым и средним бизнесом в качестве основного инструмента, и вот почему. Прежде всего, появились законодательные ограничения. Так, например, выпущенный в прошлом году Указ Президента № 250 обязывает ряд компаний, соответствующих опредёленным критериям, принять дополнительные меры по усилению информационной безопасности.

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

Среди многочисленных мер, названных в этом Указе, есть и те, что предполагают серьёзную переработку процессов связанных с мониторингом инцидентов, их своевременным обнаружением, обработкой и последующей безопасной транспортировкой в координационные центры, такие как ГосСОПКА и НКЦКИ.

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

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

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

Ещё несколько лет назад считалось, что для обслуживания SOC необходим персонал в количестве не менее 12–13 человек (а на практике это были десятки специалистов). И даже это количество людей со всеми необходимыми компетенциями найти весьма трудно.

С появлением услуги «SOC по подписке» это стало доступным как для среднего, так и для малого бизнеса. Им даже не нужно думать о том, какие решения используются для того, чтобы обеспечить информационную безопасность.

В этом же качестве — как одно из решений для внешнего SOC — можно использовать и наш продукт SpaceView.

Если же мы говорим про так называемые внутренние (in-house) SOC, то они по-прежнему будут доступны только для верхней границы того сегмента, в который мы целимся. А целимся мы в сегмент заказчиков, инфраструктура которых содержит не более 1500–2000 хостов.

Давайте в связи с этим поговорим об архитектуре самого продукта. SpaceView может поставляться как самостоятельное решение, или как SOC из облака, или и то и другое?

А. Б.: Мы не разворачиваем экземпляр SpaceView на площадке заказчика. Мы предоставляем услугу облачного SOC, которая доступна по годовой подписке.

Таким образом, его можно купить у вашего партнёра?

А. Б.: Совершенно верно.

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

А. Б.: Как известно, многие производители злоупотребляют возможностями, которые предоставляет открытый код. Так, компания Mozilla, прежде чем выставить на рынок свой самый известный браузер Firefox, взяла исходный код другого ранее очень популярного браузера Netscape Navigator, немного его модифицировала и назвала это своим продуктом. 

Мы не поступаем подобным образом. Мы применяем программы с открытым исходным кодом только как инструментарий, но не как базу. В частности, мы используем базу данных PostgreSQL, в качестве инструментария для разработки серверной (backend) части — .NET, а для разработки клиентской (frontend) части, для веб-форм, — Angular. Эти три составляющие имеют открытый код, но, повторюсь, они функционируют исключительно как инструментарий.

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

А. Б.: Да, наша разработка — полностью наша собственная.

Не секрет, что сейчас на рынке есть несколько систем IRP или SOAR. Мы выяснили, для кого разработано ваше решение. А чем отличается ваш продукт от того, что может предложить рынок, с точки зрения функциональности?

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

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

Создавая своё решение, мы руководствовались именно этой логикой.

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

При этом мы приняли решение отказаться от реализации ряда функций, которые могут быть очень полезными для организаций крупного бизнеса. Это так называемые «рюшечки», которые не несут дополнительной ценности (value) для малого и среднего бизнеса.

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

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

Хорошая аналогия. Действительно, на Ferrari не будешь возить картошку с дачи. Для этого нужен надёжный и недорогой автомобиль. Можно ли сказать, что Spacebit — это «рабочая лошадка» среди IRP-решений?

А. Б.: Именно так.

 

 

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

А. Б.: Говоря о возможностях, нужно отметить следующее. У нас есть базовый комплект, который поставляется «из коробки». Он предполагает возможность настройки корреляционных правил. Те правила, что у нас есть, — это аналоги того, что в других IRP-системах называется «плейбуками» или «ранбуками».

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

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

Отвечая же на вопрос, можно ли всё это сделать автоматически, скажу, что нет. Причём это даже не связано конкретно с нашим продуктом.

Я в принципе не верю в полную автоматизацию реагирования.

Этот вопрос — скорее методологический: можем ли мы отдать на откуп ИИ принятие решений по всему многообразию ситуаций, которые происходят в ИТ-инфраструктуре? Можем ли мы быть уверены, что результаты интерпретаций ИИ будут соотнесены с бизнес-целями?

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

Возможно, у вас есть полуавтоматический режим, при котором, как об этом мечтают все офицеры безопасности, можно нажать одну кнопку и всё станет по-прежнему?

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

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

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

Может ли заказчик дописать свои правила?

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

В каком виде существуют эти правила в самом продукте?

А. Б.: Эта часть называется «автомат» и представляет собой соотнесение всех информационных ресурсов, их характеристик и значений этих характеристик, при достижении которых должны запускаться определённые автоматические действия. Для этого существует отдельный раздел, где можно указать, какой конкретный скрипт должен быть реализован.

Можно ли говорить о том, что главным поставщиком экспертизы для SpaceView является IZ:SOC, который принадлежит компании «Информзащита»? Используют ли они ваше решение в своём SOC?

А. Б.: Да, SpaceView используется в IZ:SOC, причём сразу в двух ипостасях: как IRP во внутреннем SOC и как интерфейс взаимодействия с заказчиками, которые уже купили нашу услугу «SOC по подписке».

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

А. Б.: В нашем продукте реализована функция мультиарендности (multitenancy). Таким образом, у одного продукта может быть несколько объектов-организаций заказчиков. Для одного заказчика также можно создать несколько пользовательских аккаунтов. Соответственно, все представители одного заказчика могут видеть только ту часть инцидентов и отчётов, которая имеет отношение именно к данной организации.

Таким образом, сам заказчик посредством SpaceView может взаимодействовать со специалистами SOC?

А. Б.: Да, и более того, он сможет сам вносить корреляционные правила. Для этого нужно выставить соответствующее право. Это происходит редко, но иногда оказывается необходимым.

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

Особенно это актуально, когда речь идёт о блокировке опредёленного ресурса.

Что представляет собой интерфейс, с которым работает заказчик?

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

Какие существуют планы по развитию решения SpaceView в перспективе ближайших, скажем, двух лет?

А. Б.: В настоящий момент у нас реализована интеграция только с двумя SIEM-системами: IBM QRadar и MaxPatrol от компании Positive Technologies. После ухода ряда вендоров из России, а также после переориентации всего российского рынка на отечественное ПО большую популярность приобретает ещё одно решение — KUMA от «Лаборатории Касперского». Для нас сейчас интеграция с этим продуктом является приоритетным направлением.

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

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

Когда все продукты — из одной линейки, их гораздо легче поддерживать.

Кроме того, сама технология React сейчас в целом более перспективна, чем Angular.

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

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

Действительно, основным источником экспертизы для нас являются различные подразделения компании «Информзащита». В большей степени это сам Spacebit во главе с командой SpaceView.

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

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

В контексте планов развития SpaceView позвольте задать ещё такой вопрос. Для IRP- и SOAR-решений большой проблемой являются коннекторы со стороны хостов, СЗИ, возможно, других прикладных систем. Насколько быстро вы решаете эту проблему с увеличением количества существующих у вас коннекторов?

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

Для иллюстрации динамики приведу такие цифры. Сейчас этих шаблонов 530, а ещё полтора года назад их было 350. Это число постоянно увеличивается и адаптируется под новые угрозы.

Если говорить именно о коннекторах, в стандартном пакете у нас их не так много. Мы фактически интегрированы, как я уже сказал, с SIEM-системой. Кроме того, у нас есть интеграция с системой поддержки (Service Desk).

Один из сценариев использования нашей системы — это подключение к SIEM как напрямую, так и через посредника, коим является Jira Service Desk. Что даёт подключение через посредника? Оно даёт возможность непосредственно в Jira первично обработать все те события, которые поступили туда из SIEM, и отобрать только те из них, которые похожи на инциденты или могут быть с ними связаны.

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

У нас также есть связь с почтовыми сервисами и мы можем, как я уже упомянул, высылать сообщения в телеграм-канал. В то же время, если сравнить наше решение с более развитыми IRP / SOAR, то у нас число коннекторов исчисляется единицами, а не десятками, как у них.

Это может показаться серьёзным недостатком, но только на первый взгляд, и вот почему. Во-первых, высокое количество коннекторов является в определённой степени маркетинговым ходом. 

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

Во-вторых, важно понимать сам принцип того, как устроено применение этих коннекторов. Как правило, они используются для оркестровки данных. Отсутствие коннектора для конкретного СЗИ, такого как IPS / IDS, EDR, NDR и так далее, ещё не говорит об отсутствии связи с ним, и это очень важно понимать. Все современные СЗИ имеют интеграцию с SIEM-системой, а она интегрирована с нашим решением.

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

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

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

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

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

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

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

Реклама ООО "Спейсбит" ОГРН 1217700015136

LdtCKdAZj