Владимир Дрюков: Внедрение SOAR обусловлено потребностью в реальной безопасности, а не "нормативкой"

Илья Шабанов, генеральный директор Anti-Malware.ru, и Владимир Дрюков, директор центра противодействия кибератакам Solar JSOC компании «Ростелеком-Солар», в рамках интервью обсудили российские реалии рынка ИБ, партнёрство с R-Vision, зрелость идеи использовать SOAR как услугу, особенности инцидентов в АСУ ТП и КИИ, а также автоматическую реакцию на инциденты в безопасности и её перспективы.

На наших эфирах AM Live мы многократно обсуждали реагирование и, самое главное, баланс между предотвращением и реагированием. Многие говорили, что до реагирования «руки не доходят» и сейчас им не до этого. Согласны ли вы с этим тезисом?

В. Д.: В 2020 году инцидентов стало намного больше — например, у наших заказчиков их количество выросло более чем на 70 %, и причин тому несколько. С одной стороны, повысилась активность злоумышленников, стали шире применяться автоматизированные системы. С другой — вырос и уровень энтропии, турбулентности в деятельности пользователей: «удалёнка» и последовавшие за ней увольнения сыграли свою роль.

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

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

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

Те заказчики, с которыми вы работаете, понимают, что реагирование — это важно и нужно? Они готовы на это тратить деньги, заниматься этим, но им не хватает ресурсов?

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

Про плейбуки мы поговорим ещё чуть дальше. Я вижу цифры из вашего отчёта Solar JSOC. Очевидно, что в любой организации количество инцидентов будет расти. Не становится ли сама тема реагирования некой утопией? Даже если мы будем иметь, например, 100 инцидентов в день, на них, мне кажется, уже будет тяжело реагировать.

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

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

Хорошо, допустим, мы видим через SIEM-систему какие-то аномалии, которые тоже признаны инцидентами, с которыми нужно разбираться. Как определить, на что точно нужно реагировать, а что из этого — «белый шум»?

В. Д.: Здесь возможны разные критерии. Это — вопрос приоритизации инцидентов в принципе. Например, идёт ли речь о частном инциденте или это — возможное звено в цепочке атаки? Инцидент произошёл в каком-нибудь дальнем филиале в Кандалакше или в центральном офисе? Он вообще типовой для текущего профиля системы? Например, запуск Remote Access, TeamViewer или Radmin может быть нормой для корпоративной сети клиента, а вот на машине оператора АСУ ТП это — уже проблема.

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

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

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

Давайте возьмём какую-нибудь компанию из технологического сегмента и найдём в ней все банк-клиенты. Будем ходить по ней два месяца, опросим всех айтишников и бизнес и найдём 25 узлов — а их в итоге окажется 40. Это и есть проблема номер один. И она, кстати, с коммерческим внешним SOC решаема только отчасти: в основном это — большая системная работа клиента на своей территории. А дальше — «выгрузка» всего этого контекста в инциденты, правильная параметризация, правильные математические модели для определения самого важного, самого высокого веса — это, конечно, SOC.

Мы разобрались с приоритизацией инцидентов, из нашей сотни отобрали 10–20 для реагирования. Каким образом можно эффективнее автоматизировать этот процесс? При помощи SOAR-системы?

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

По каждому типу инцидента важно определить, что мы блокируем автоматически, а что закрываем «процессно». И насколько быстро всё это надо делать.

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

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

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

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

В Solar JSOC вы пошли по пути автоматизации реагирования на лёгкие типовые инциденты или же как раз по пути использования SOAR?

В. Д.: С SOAR — почти как в статусе из соцсетей — «всё сложно». Когда мы говорим про задачу реагирования на стороне заказчика, самое главное — автоматизировать часть процессов и разгрузить его сотрудников, получив простой инструмент управления автоматической маршрутизацией и возможность разработки очень понятных плейбуков. А разобрать киберинцидент по косточкам — это уже наша задача. В этой части нам помогает внутренний IRP, который включает множество инструментов: шины автоматизации, склейки «килчейнов» (цепочек угроз. — Прим. ред.), сбор статусов с VirusTotal и прочее.

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

В. Д.: Всё правильно.

В прошлом году была новость о том, что вы стали использовать SOAR-систему от компании R-Vision. На что было направлено использование этой системы?

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

Почему в конечном итоге вы выбрали R-Vision, а не кого-то из альтернативных поставщиков, в том числе зарубежных?

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

Ещё одним важным фактором при выборе вендора являются требования связанные с реализацией закона о безопасности КИИ и особенностями подключения организаций к ГосСОПКА. Выбирая R-Vision, мы ориентировались на готовность вендора дорабатывать функциональность по нашему запросу. И пока мы довольны этим партнёрством.

Выбирая между развёртыванием SOAR внутри (on-premise) и использованием его как сервиса, чем может руководствоваться компания?

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

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

Насколько часто возникает ситуация, когда заказчик говорит: «У меня другая модель рисков, и вы её не понимаете. И плейбуки мне нужны другие, а не такие, которые я получаю от вас. Помогите мне сделать всё по-другому»?

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

Типизация на уровне инфраструктуры и процессов ИБ достаточно высока. Это не значит, что все компании одинаковы. Речь — о том, что если правильно строить параметризацию, то для всех компаний работы будут примерно одинаковыми.

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

Как сейчас реализовано решение R-Vision IRP в рамках Solar JSOC?

В. Д.: Сейчас эта услуга дополнительно предоставляется клиентам, которые пользуются частью сервисов по мониторингу. В будущем ею смогут воспользоваться и те компании, которые не подключены к Solar JSOC.

Кому подойдёт такая услуга? Можно ли сказать, что она рассчитана на тех, у кого реагирования вообще нет, а не на тех, у кого этот процесс как-то настроен?

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

По итогам 2020 года можно точно сказать, что рынок созрел для такого рода услуги?

В. Д.: Кажется, что рынок более-менее стал понимать, как надо мониторить типовые угрозы, но APT-атаки для большинства по-прежнему остаются загадкой.

Но когда ты начинаешь выявлять угрозы в массовом сегменте, у тебя, естественно, возникает вопрос: а что с ними делать дальше? И здесь появляется потребность в автоматизации процессов реагирования.

Сколько заказчиков из числа ваших клиентов уже используют услугу SOAR-системы по модели аутсорсинга?

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

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

В. Д.: Всё правильно. Кажется, что драйвером развития всей тематики IRP / SOAR и их сервисной модели является не комплаенс и «бумажная» безопасность, а желание реализовать реальную защиту от киберугроз.

Как дальше будет развиваться тема IRP / SOAR с технической точки зрения? Или она уже находится в зрелом виде, так что дальше всё идёт по пути наращивания и совершенствования плейбуков?

В. Д.: Развитие IRP / SOAR сопряжено с развитием самого сервиса по мониторингу. И в первую очередь это касается направления КИИ. Несмотря на федеральный закон, очень многие субъекты КИИ до сих пор фокусировали свои SOC (коммерческие и внутренние) на корпоративном сегменте. Сейчас же набирает обороты тема реагирования на инциденты в сегменте АСУ ТП, который совершенно уникален в плане обеспечения ИБ. Очевидно, что нельзя просто остановить АЭС из-за того, что на компьютере сотрудника обнаружена подозрительная активность. Поэтому мы сейчас формируем уникальные подходы к реагированию на инциденты в закрытых сегментах промышленных предприятий. Это — большая история развития и плейбуков, и технологии, и вообще архитектуры.

Второй вектор развития IRP / SOAR — это типизация на уровне накопленной базы, автоматизация части процессов реагирования и сбора контекста по инцидентам, которая необходима для удобства самого заказчика.

Кроме того, сейчас строится очень много корпоративных коммерческих иерархических центров, которые обслуживают не одну компанию, а 50–60. Им нужна единая система реагирования на инциденты, правильная с точки зрения архитектуры, процессов, кастомизации и так далее. Последние год–полтора мы с R-Vision ведём и эту работу тоже.

Как вы оцениваете возможность интеграции SOAR-системы с другими средствами защиты и ИТ-системами? Насколько в этом смысле хватает возможностей решения R-Vision и как оно может развиваться в плане интеграции?

В. Д.: Это, на самом деле, — один из ключевых вопросов: а где после того, как мы запускаем систему IRP / SOAR, должен «жить» айтишник, ведь у него есть своя система Service Desk? А интеграция SOAR c Service Desk — это всегда некоторый компромисс, потому что функциональных возможностей SOAR нет в Service Desk (плейбук, возможности по реагированию, контекст). Это — скорее логические, а уже потом технические ограничения.

Насколько рынок готов к полной автоматизации процессов реагирования?

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

То есть пока сами заказчики не готовы автоматизировать реагирование в виде «нажал и запустил процесс реакции»?

В. Д.: Да. Проблема — ещё и в том, кто принимает решение. Основные пользователи SOAR — это ИБ-службы, а остальные подразделения туда только подтягиваются. Сетевику, например, страшно нажать кнопку «заблокировать доступ к IP-адресу» в какой-то сторонней системе. Словом, объяснять принципы и философию IPR / SOAR нужно не только безопасникам, но и всем подразделениям компании (от IT до бизнеса).

Получается, что у нас в аббревиатуре SOAR буква R (реагирование) по факту «отваливается»? Мы его отдаём куда-то дальше, на уровень Service Desk и других внешних систем?

В. Д.: Это — как раз задача евангелизации рынка и изменения подхода. Вендоры и провайдеры стараются постепенно «подтягивать» компании к SOAR.

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

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

Благодарю за интервью и желаю успехов!