Вениамин Левцов: Ключевая проблема ИБ — недостаточная связанность логики систем защиты

В интервью Anti-Malware.ru Вениамин Левцов, директор глобального центра экспертизы по корпоративным решениям «Лаборатории Касперского», рассказал о том, что, по его мнению, сегодня является основной болью крупных заказчиков, что заставляет их всерьёз рассматривать работу с поставщиками услуг ИБ и что делает «Лаборатория Касперского» в этой ситуации. В ходе беседы обсуждались вопросы построения инфраструктуры организаций в целом, сервис MDR от «Лаборатории Касперского», то, в каком направлении развивается защита конечных точек, и другие важные вопросы.

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

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

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

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

Фактически задача для сервис-провайдера формулируется в бизнес-терминах и более «завязана» на цели, а не на детали реализации. Эти цели всё ещё являются технологическими, но за ними уже гораздо более отчётливо прослеживается бизнес. Теперь от такого провайдера требуют брать на себя ответственность за то, чтобы система сетевой безопасности в компании функционировала с определённым уровнем качества, чтобы количество пропускаемых угроз уменьшалось, время реакции на угрозы снижалось, все основные KPI были в зелёной зоне; чтобы система следовала за духом времени, включая массированное использование «удалёнки» и облака. «Фактически вы становитесь владельцем нашей технологической стратегии в этой области, — говорят клиенты провайдеру. — Мы делегируем её вам, чтобы файрвол не просто работал, а через три года соответствовал актуальным реалиям; чтобы вы сейчас, выбирая вендора решения, понимали наше с вами будущее в этой области».

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

Первое, что вы обозначили, — это интеграция отдельных продуктов. Рынок ИТ прошёл через это лет десять назад, а на рынке ИБ это только началось: открытые API, общие стандарты обмена данными. Почему эта проблема вышла на первый план именно сейчас?

В. Л.: На мой взгляд, ключевая проблема здесь — это изменение ландшафта угроз. Раньше всё-таки начинали с того, что классический антивирус, проверяя по контрольной сумме или поведенческому шаблону то или иное приложение, принимает решение о том, что это — элемент атаки, вируса, и ограничивает его в действиях. То же самое, например, — классический файрвол: блокирует вредоносное соединение, и всё, точка. Сейчас же все эти системы редко когда могут охватить весь диапазон инструментария атаки. Потому что атака предполагает использование средств социальной инженерии, новых уязвимостей, связанных активностей распространения по сети (lateral movement), захвата учётных данных. Украденные подменённые сертификаты приложений, использование легитимных средств вроде PowerShell и средств удалённого администрирования — сигнатурный подход тут не помощник.

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

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

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

В. Л.: Примерно так, да. И идеологически эти средства защиты всё равно остались в рамках единственной функции. Да, конечно, их развивают, и очень сильно. Антивирус, например, 2005 года нельзя сравнивать с мощной, многокомпонентной защитой конечных точек, которая есть сейчас. При этом мы понимаем, что фактически эти обособленные системы уже не выполняют функцию полноценной защиты от многокомпонентных, многовекторных современных атак, и для того чтобы с этим бороться, человечество придумало решения класса Endpoint Detection and Response, EDR.

При использовании EDR защита конечных точек перестаёт работать как «чёрный ящик». Классический антивирус задумывался как следователь, судья и палач. Он что-то распознавал, уточнял у своего облака, затем сам принимал по этому поводу решение и уничтожал объект, изолировал его, посылал в карантин и так далее. И всё это — в рамках одного приложения и одного рабочего места. Тогда как EDR обеспечивает видимость всей сети, всего, что происходит. Фактически классический антивирус был самодостаточной системой, администрируемой инженером ИТ, в то время как EDR — это рабочий инструмент аналитика службы ИБ.

К базовой функциональности добавляется возможность запускаемых проверок — EDR получает индикатор (IoC) и сканирует сеть в его поисках. Если что-то находит, но сомневается (так называемая «серая зона»), то вовлекаются другие возможности. Тут нам на помощь приходят системы расширенного детектирования, включая песочницы, механизмы атрибуции, Threat Intelligence — потоки данных об угрозах (облачные, в первую очередь) и многое другое, включая проверки по совпадению с техниками, тактиками и подходами, описанными в базе MITRE.

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

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

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

Давайте как раз, не уходя далеко, поговорим про реагирование и про автоматизацию. Популяризация SOAR-систем в России говорит о том, что эта тема в целом очень востребованна. EDR, XDR — тоже. Об этом говорят всё больше, это находит отклик у заказчиков и у рынка. С другой стороны, я пока что вижу неготовность рынка что-то автоматизировать на практике: мол, это очень круто, что мы можем «на автомате» что-то удалить или заблокировать, но у нас этим занимаются айтишники, они нам ничего не дадут сделать, здесь нужно согласовать, а здесь — компьютер генерального директора, где мы просто боимся что-то делать автоматически. И на практике получается, что к процессу автоматизации не готовы.

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

Как мы обсуждали в эфире AM Live, пока в аббревиатуре SOAR выпадает последняя буква, R. То есть они уже умеют делать оркестровку и администрирование, а реагирование, скажем так, остаётся пока в теории.

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

Как это может работать? Возьмём такой пример: появился подозрительный исполняемый файл — его автоматом направляют в песочницу. В случае положительного вердикта песочница возвращает управление по API, например, на EDR, который, доверяя песочнице, блокирует распространение объекта на другие компьютеры и информирует средства сетевой безопасности: на таких-то компьютерах есть такое-то опасное приложение. Для того чтобы описать один такой сценарий, не требуется SOAR. И я считаю, что разумнее вкладываться не во внедрение подобной охватывающей всё и вся системы, а потратить силы на построение и внедрение связанных сценариев использования различных подсистем по модели с полуавтоматическим реагированием.

То есть речь идёт об автоматизации рутины?

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

Хорошо; допустим, мы автоматизировали рутину и в результате немного снизили нагрузку на нашу внутреннюю службу ИБ. Что ещё можно сделать, чтобы упростить их жизнь? Отдать на аутсорсинг отдельные функции — скажем, защиту удалённых сотрудников, сети, филиалов? Как это должно работать на уровне бизнеса?

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

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

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

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

В. Л.: В целом вы правы.

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

Впрочем, я бы хотел в этом контексте продолжить историю о EDR. Видимости только конечных точек со всем, что я перечислил, оказывается недостаточно. Требуется видимость как можно большего количества «контролов». Это и защита почты, и защита облаков, и, насколько это возможно, фильтры контролирующие сетевой трафик (почтовый, веб), и системы безопасности неофисных конечных точек, таких как банкоматы или АСУ ТП. Удобно было бы подчинить всё это единой логике работы и отражать в единых интерфейсах. Таким образом мы приходим к понятию XDR, когда обеспечивающие очень разнородную безопасность инструменты всё равно подчиняются единому набору политик. В идеале — генерируют единый поток телеметрии, разделяемой между ними и хранимой в едином «озере данных» (data lake). И мы сейчас стоим на пороге того, что на рынок попадёт большое количество таких систем.

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

Сама концепция XDR выглядит здраво и очень интересно. Каково здесь основное направление развития, куда всё должно двигаться? В сторону охвата облаков?

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

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

В. Л.: На самом деле компаниям надо просто расширять своё покрытие, охватывая домашние компьютеры. В идеале — выдавать их сотрудникам с полным набором предустановленного ПО, чтобы владельцем компьютеров оставалась компания.

Желательно и роутер тоже. Кстати, есть уже такое на рынке.

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

Кстати, наши заказчики, которые используют сервис MDR и которые разрешали своим домашним пользователям применять Kaspersky Endpoint Security на домашних компьютерах, фактически помещали эти компьютеры в поле защиты нашей MDR-команды.

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

Вы в своей презентации на Kaspersky Security Day упоминали, что сейчас компания способна построить у заказчиков SOC на технологическом стеке своих продуктов.

В. Л.: Мы можем и SOC заказчику построить на базе нашего SIEM KUMA, вышедшего недавно. Но наибольшей зрелости мы добились в оказании услуг по расширенному детектированию сложных угроз на конечных точках. Это не про сбор и анализ логов, это про анализ потока телеметрии в нашем облаке.

То есть вы видите MDR на данном этапе зрелости скорее как некое дополнение и помощник для SOC, а не его альтернативу?

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

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

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

Вы часто говорите про Kaspersky Security Services. Вкратце: что это такое и для кого это нужно? У «Лаборатории Касперского» сейчас становится очень много сервисов, и разобраться во всём их многообразии очень тяжело.

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

По сути, это такой «коробочный» Threat Hunting?

В. Л.: Да. Этот сервис предоставляется в виде проекта, который длится определённое время и завершается отчётом. Его хорошо бы проводить хотя бы каждый квартал.

Этот сервис у нас есть, и имеется достаточно ресурсов, чтобы оказать его большому количеству заказчиков. Кстати, практически нет случаев, когда в результатах ничего бы не было — обязательно что-то важное находится. Этот сервис — проактивный, и его развитием в некотором смысле является проведение штабных учений. Думаю, уже лет через пять, если крупная компания не будет хотя бы раз в 2–3 года проводить полноценные штабные учения, это будет выглядеть странно.

О терминах, наверное, можно спорить; я хочу уточнить, что вы подразумеваете под штабными учениями.

В. Л.: Я это понимаю как Red Teaming. Когда совместно с бизнес-руководством служба ИБ выделяет некоторое количество наиболее критически важных бизнес-функций, которые с высокой степенью вероятности могут атаковать злоумышленники. Соответственно, выделяется этот список, определяются векторы атаки и затем в управляемом режиме с информированием ограниченного количества людей внутри компании проводятся управляемый взлом этих систем, управляемое сканирование внешних IP-адресов и полный набор активности повторяющей действия атакующей стороны.

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

Да, это важно. Таким образом, существуют два экспертных сервиса.

В. Л.: Есть ещё сервисы связанные с оценкой защищённости мобильных и веб-приложений. Перечислю всё вместе: диагностика системы, тест на проникновение (полноценная атака со взаимодействием со службами ИБ), «редтиминг» и анализ приложений на предмет того, насколько они могут быть взломаны, скомпрометированы. Таковы четыре основных превентивных сервиса. Они все доступны и могут быть очень полезны практически любому заказчику. Вопрос лишь в том, что выбрать.

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

Также у нас есть тренинговые сервисы, когда мы учим проводить IR и глубоко анализировать вредоносные объекты.

Есть также и сервисы для сотрудников SOC и отделов ИБ?

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

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

В контексте всех трендов, о которых мы сегодня говорили, как будет развиваться продуктовая линейка «Лаборатории Касперского» для крупного бизнеса? Я вижу очень большие изменения: появилась KUMA, потом была представлена и единая консоль управления, которая ожидается весной. Остаётся добавить NGFW от «Лаборатории Касперского», и получится полная экосистема.

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

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

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

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

Кстати, часть продуктов — та же песочница, например, — могла бы уже давно переехать в облако или стать некой альтернативой: хочешь — on-premise, хочешь — в облаке. Сейчас развивается концепция SASE, когда у вас есть функция очистки трафика — тоже очень интересная вещь, особенно на «удалёнке». Жаль только, что всё это приходит к нам с сильным опозданием.

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

Итак, вот те принципы, на основе которых мы развиваем наши продукты. Первое — единство политик и систем управления функциями ИБ, второе — облачность, а третье — это сервисы.

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

То есть вы делаете ставку на продажи через партнёров?

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

Спасибо большое за интервью! Желаю успехов!