Алексей Мальнев: R-Vision IRP — центральный элемент всего сервиса Jet CSIRT

Алексей Мальнев, руководитель Центра мониторинга и реагирования на инциденты ИБ Jet CSIRT компании «Инфосистемы Джет», и Игорь Сметанев, коммерческий директор R-Vision, рассказали Anti-Malware.ru о роли IRP-систем в коммерческом SOC и преимуществах использования системы от R-Vision, затронув тему автоматизации реагирования на киберинциденты.

Игорь, к вам первый вопрос. Последние несколько лет тема создания и аутсорсинга SOC [Security Operations Center] была ключевой на рынке информационной безопасности в России. Я правильно понимаю, что именно это дало толчок к использованию систем IRP [Incident Response Platform], о которых раньше мало кто слышал? Какие категории заказчиков сейчас больше всего созрели для автоматизации реагирования на инциденты ИБ и заинтересованы в ней?

И. С.: SOC стал в большей степени катализатором для развития этой темы. Любой продукт создаётся исходя из потребностей заказчика. Рынок формирует задачи, и в результате этого появляются компании, которые готовы данные задачи решать. Мы — не исключение. В момент разработки продукта у нас был блок инцидент-менеджмента, и мы заметили определённую активность заказчиков в части управления инцидентами. Эти задачи не решали ни SIEM-системы, ни service desk — их было недостаточно для обработки инцидентов именно в плане реагирования и оркестрации. У западных вендоров это направление стало развиваться отдельно в Incident Response Platform, и мы тоже начали его развивать. А немного позже, когда развитие этой темы уже набрало обороты, у нас в России появилась тема SOC. Продукты класса IRP являются одним из элементов SOC по определению, без них невозможно его автоматизировать. Об этом говорит и пишет Gartner. И технологии, используемые SOC, «завязаны» на IRP. Для нас SOC явился именно катализатором распространения данного продукта и вообще потребности в нём.

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

И. С.: У многих — разное представление о SOC. Мы знаем триаду «технологии — люди — процессы». Но многие под SOC подразумевают вообще все средства защиты. Для них система безопасности — это и есть SOC. Продукт можно использовать и без классического понимания SOC, потому что инциденты могут быть даже без SOC и без наличия SIEM-систем. Их необходимо агрегировать в одном месте и дальше обрабатывать, и с этим в большинстве случаев не справляются системы service desk, которые находятся во владении IT. Наш продукт и в целом класс таких решений помогают автоматизировать обработку инцидентов.

Игорь, а насколько использование R-Vision IRP в качестве модели MSSP в Jet CSIRT является уникальным проектом?

И. С.: На мой взгляд, тема Managed Security Service Provider (MSSP) сейчас набирает обороты, находится на стадии формирования.

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

У каждого MSS-провайдера есть свой опыт и свои наработки, так называемые внутренние процедуры реагирования и экспертиза, которые важно транспонировать в продукт. В частности, с коллегами из Jet CSIRT мы увидели, какой ещё функционал нужно доработать, чтобы максимально перенести их экспертизу  в продукты. Именно такой симбиоз и делает этот проект действительно уникальным.

В нашем недавнем сравнении услуг коммерческих SOC продукт R-Vision отметился неоднократно в качестве одного из компонентов различных платформ. Может ли IRP-система стать конкурентным преимуществом в коммерческом SOC?

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

А. М.: Согласен, без IRP невозможно реализовать полноценный SOC — конвейер со всеми выстроенными процессами, системным подходом к управлению инцидентами и командой, обеспечивающей их трёхуровневую обработку. Чтобы поставить этот конвейер на рельсы, безусловно, нужен специализированный инструмент. Конечно, есть примеры, когда коммерческие SOC обходятся без IRP-системы. Они могут работать, например, с какими-то кастомными решениями, использовать тикетные системы IT или системы open-source с очень большой вариативностью с точки зрения настроек. Но специализация IRP-инструментов в области Incident Response позволяет MSS-провайдеру брать на аутсорсинг целый ряд функций, выполняемых самим решением. Сотрудничая с R-Vision, мы избежали необходимости содержать штат из шести-восьми человек, которым пришлось бы «допиливать» ту самую тикетную систему либо опенсорсную IRP-систему.

Алексей, как в Jet CSIRT построен процесс реагирования на инциденты и какая техническая платформа для этого используется?

А. М.: Система IRP от R-Vision у нас занимает верхний уровень над остальными инструментами Incident Response.

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

Порядка 40-50% клиентов пользуются нашим облачным сервисом, в котором мы применяем FortiSIEM от Fortinet. Вместе с тем многие наши клиенты предпочитают и гибридную модель с использованием SIEM, развёрнутой в их инфраструктуре.

Какую роль в этом процессе играет IRP-система?

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

Использование IRP-системы подразумевает некую автоматизацию реагирования. В чём конкретно она состоит?

А. М.: Автоматизация может быть многогранной и применяться на разных этапах Incident Response. Уже на первых этапах обработки инцидента в IRP-системе реализуется разветвлённая логика по автоматизации. В Jet CSIRT, например, есть около сотни сценариев выявления угроз, каждому из которых соответствуют одно или несколько корреляционных правил. Для каждого сценария выявления угроз у нас реализован комплексный сценарий реагирования в IRP-системе. Это похоже на некий граф или дерево событий, где мы в рамках обработки инцидента идём по одной из веток этого дерева, в том числе — на этапе аналитики и первичной обработки инцидента.

В части автоматизации реагирования (response) глубокая специализация позволяет IRP работать с обширным потоком информации, большой вариативностью и возможностями масштабирования.

А эти инструменты, сценарии, плейбуки поставляются вендором IRP-системы или разрабатываются уже самим заказчиком? Вы делали это сами в Jet CSIRT или получили от R-Vision? Или — и то, и то?

А. М.: Значительную часть правил реагирования мы адаптировали под нашу услугу, оптимизируя их под каждый сценарий выявления угроз. При этом на многих этапах у нас были доработки, где требовалось взаимодействовать с R-Vision, и вендор охотно шёл нам навстречу.

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

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

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

А есть ли сейчас какие-то отраслевые стандарты? Как, например, должны строиться процессы реагирования на инциденты?

И. С.: Конечно, есть верхнеуровневые рекомендации: международные — как строить SOC, какие должны быть процессы; рекомендации от ЦБ — как в целом выстраивать процесс. Но они — не детализированные. Нет, например, такого: у вас есть 10 плейбуков, которые закрывают 95% инцидентов и состоят из определённого набора действий, который необходимо у себя обязательно настроить и использовать. Потому что на инцидент можно отреагировать и обработать его разными способами, технологиями и инструментами. Есть определённые шаги, какие-то блоки действий, но что использовать внутри этих блоков — на усмотрение каждого SOC и специалиста в этом SOC.

Алексей, по каким критериям вы выбирали IRP-систему для своего SOC? И почему выбрали именно IRP от компании R-Vision? В чём её удобства и преимущества?

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

У нас не было иллюзии, что система будет эффективно работать «из коробки». Таким свойством не обладает ни одна IRP-система.

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

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

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

А. М.: Это имело значение, но не было определяющим фактором. А вот зрелости команды разработчиков мы уделяли большое внимание. Мы выбирали IRP-систему примерно полгода. Вместе со специалистами из интеграционного блока протестировали и сравнили шесть open-source, известных иностранных и российских продуктов. Сначала отказались от варианта с open-source, так как он требовал высоких затрат на поддержку решения. Потом пришли к выводу, что ни одна из IRP-систем на тот момент не была адаптирована к MSSP-модели и концепции единой интеграционной шины. Это ещё сильнее укрепило наше требование к наличию зрелой команды разработчиков и технической поддержки, которое в итоге и обусловило выбор R-Vision.

То есть пришлось дорабатывать все эти моменты в IRP-системе, чтобы адаптировать её к модели MSSP?

А. М.: Да, ведь создание «SOC для себя» и «SOC как MSSP» предполагает разную расстановку приоритетов. Например, гибкость системы и возможность её оперативно дорабатывать крайне важны для MSS-провайдера. А вот глубокая работа с информационными активами более востребованна уже внутренними SOC. Хотя и нам она тоже необходима.

Насколько трудоёмким оказался проект по развёртыванию R-Vision IRP?

А. М.: Весь цикл работ занял примерно восемь-девять месяцев. Первые два-три месяца ушли на проработку workflow-конвейера. Пожалуй, это — самый сложный этап в создании любого SOC.

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

Мы перестраивали внутренние процессы и продумывали оргструктуру команды. Почти каждый день собирались на «брейнштормы», проверяли работоспособность процессной модели. В результате разработали набор верхнеуровневых регламентов, определяющих общий состав услуг, условия их оказания и требования к SLA, а также более низкоуровневые документы — сценарии выявления угроз и плейбуки. Следующим этапом стала отладка процессов, после чего началась плотная совместная работа с вендором по развитию решения под задачи Jet CSIRT. Объединив усилия, примерно через три месяца мы смогли поставить наш конвейер на рельсы.

Игорь, со слов Алексея, на глубокую совместную работу ушло три месяца. Видимо, приходилось активно дорабатывать какие-то функции продукта, вносить индивидуальные изменения. В целом насколько уникальным по трудоёмкости оказался этот проект для компании R-Vision?

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

В процессе доработки мы давали коллегам из «Джет» опробовать продукт в тестовом режиме, чтобы можно было понять, насколько это является рабочим вариантом, чтобы они смогли оценить MVP (Minimum Viable Product — прим. ред.) и сказать: да, это — рабочий вариант, его надо дальше развивать. Такой подход и тесное взаимодействие с MSS-провайдером можно назвать уникальным.

То есть вы проверяли механизмы и гипотезы, что называется, «на горячую»?

И. С.: Не совсем «на горячую». У любого MSS-провайдера и у любого нашего заказчика, кто строит SOC, есть «продакшн» и есть «тест». Конечно, проверяли на тесте, но именно те свежие апдейты, которые мы сделали с «заточкой» под MSSP. Вот это важно. И в этом случае мы сразу получали обратную связь, видели, в какую сторону развиваться. Ведь важно, чтобы эти доработки могли использовать и другие наши заказчики и партнёры. Мы находили компромисс и удобный вариант использования.

На ваш взгляд, насколько российский рынок созрел для такой услуги? Насколько это востребованно? Какие требования к заказчику и его зрелости должны быть?

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

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

Сколько заказчиков уже использует R-Vision IRP по подписке?

И. С.: Пять заказчиков, которым мы поставили софт по подписке. Это — промышленность, СМИ, девелопмент, есть даже госзаказчик.

Какими вы видите перспективы развития MSSP в России?

А. М.: При запуске MSSP-направления мы ожидали, что пик его развития придётся на 2023-24 годы. Но сегодняшние события, вероятно, ускорят этот процесс, поскольку для многих компаний актуальность управляемых сервисов уже возросла. Заказчик может выбирать: приобретать решения и управлять ИТ-«зоопарком» или подключить к задаче сервис-провайдера и получить одновременно услугу и инструментарий для реализации своих процессов. Мы ожидаем, что тема ускорится и уже в течение года-двух выйдет на хороший уровень развития.

Тут важно отметить, что MSSP в контексте IRP предполагает два разных подхода. Один из них — Incident Response, когда поставщик оказывает комплексные услуги по обработке и управлению инцидентами, аналитике и прочему, используя IRP-систему как центральный элемент. Другая история — когда заказчикам по подписке предоставляется некий сервис, в который входит услуга по управлению инцидентами и сам инструментарий. Это — более узкая услуга.

Каковы отзывы ваших заказчиков?

А. М.: Бывают моменты, когда требуются доработки, но в целом клиенты довольны.

Косвенным подтверждением их удовлетворённости служит отсутствие штрафных санкций при весьма строгих условиях контрактов. Уровень соблюдения SLA у нас, как правило, равен или приближается к 100%.

Алексей, вы сказали, что заказчики Jet CSIRT могут работать с интерфейсом R-Vision IRP. Как это для них выглядит?

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

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

А на стороне заказчика необходимо что-то устанавливать? Какие-то серверы, агенты или что-то ещё?

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

Под конкретного заказчика и то, что он сам настроит? Всё под него? Будет кастомный интерфейс?

А. М.: В части доступа к клиенту, конечно, делаем «под заказчика». По умолчанию предлагаем свой рекомендуемый набор.

Плейбуки и сценарии со временем меняются, нужно их обновлять и добавлять новые. Заказчик это делает самостоятельно или он обращается в Jet CSIRT, а потом вы направляете такие запросы вендору и сообщаете, что именно нужно добавить? Как это происходит?

А. М.: У нас в оргштатной структуре есть роль инцидент-менеджера — вот это как раз его задача. Он отвечает за разработку и корректность реализации workflow, контролирует обработку инцидентов, в режиме реального времени постоянно совершенствует логику в части реагирования. Некоторые задачи он решает вместе с группой разработки вендора. Например, результатом такой совместной деятельности стало появление в Jet CSIRT функции мониторинга метрик SLA, которая ранее не была реализована ни в одной IRP-системе.

Могут ли клиенты Jet CSIRT использовать R-Vision IRP для взаимодействия с НКЦКИ?

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

Получив статус корпоративного центра ГосСОПКА, мы реализовали в логике IRP «маппинг» между нашими сценариями и типами и категориями инцидентов НКЦКИ. Это даёт нам возможность понимать в реальном времени, какие из наших сценариев предполагают оперативное уведомление. В R-Vision коннектор к НКЦКИ реализован «из коробки» и не требует какой-то работы «напильником».

Игорь, если попробовать взглянуть на перспективу развития IRP-системы для использования в модели MSSP, то какие планы есть у R-Vision по доработке и увеличению функциональности продукта, по улучшению техподдержки?

И. С.: Мы отслеживаем, как развиваются другие продукты, в том числе — смежные отрасли, видим задачи, которые можно решить на базе нашего продукта и не могут решить рядом устанавливаемые комплексы, также связанные с обработкой инцидентов, такие как SIEM и service desk. Смотрим в сторону большей универсальности, больших возможностей, чтобы можно было свободно в продукт добавлять свою экспертизу, чтобы каждый мог ею делиться.

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

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

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

Алексей, можете со своей стороны дополнить, что вы бы хотели улучшить в продукте для совершенствования своей услуги?

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

С увеличением количества внедряемых на разных этапах модулей машинного обучения и искусственного интеллекта, в перспективе лет десяти, роль человека фактически может перейти в область логического управления всей информационной системой и системой защиты в целом. И здесь роль IRP / SOAR — ключевая. Если раньше считалось, что «мозгом» и финальным элементом системы защиты служит SIEM, то сейчас стало очевидно, что именно IRP / SOAR-система является самым верхнеуровневым инструментом и местом, где принимаются основные решения в рамках Inсident Response.

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

И. С.: Gartner не просто так в 2018 году думал, как назвать такой класс решений, куда они будут развиваться — именно IRP-класс, — и придумал аббревиатуру SOAR (Security Orchestration, Automation and Response). Это и есть автоматизация: оркестрация не только обработки инцидентов, но и, как сказал Алексей, других продуктов и технологий безопасности ещё до момента возникновения инцидента, когда нужно что-то проверить в безопасности, обратившись к разным системам, базам данных и т. д. Оркестрация безопасности, автоматизация — это то направление, в котором будет идти развитие всех систем. И мы, разумеется, туда уже идём.

А. М.: Кстати, 13 мая Jet CSIRT совместно с коллегами из R-Vision проведет вебинар на тему «Выстраивание процессов SOC, их автоматизация с помощью IRP-системы». Мы расскажем про практики выстраивания workflow по обработке инцидентов ИБ и сопутствующих процессов.

Спасибо за интервью! Успехов!