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

До «Лаборатории Касперского» я работал инженером по технической поддержке фиксированной сети в региональном подразделении телеком-оператора из топ-4, а затем в дальневосточном филиале оператора — крупном поставщике магистральных услуг связи для операторов и крупнейших корпораций России. Вырос от специалиста до руководителя отдела и уже контролировал работу оборудования технологической сети и систем управления. Продакт-менеджером стал, перейдя в вендоры инфраструктурного оборудования для телекома и ИТ, где развивал и выводил на рынок линейку коммутаторов для операторов связи и сегментов B2B2G.

В статье поделюсь опытом, полученным в ходе работы над собственным некст-ген фаерволом «Лаборатории Касперского» — Kaspersky NGFW. Думаю, узнать о пути такого комплексного продукта от идеи до релиза может быть интересно как коллегам по ремеслу, так и ИТ-сообществу в целом. Особенно учитывая, что (как это часто происходит) конечный продукт существенно отличается от изначального концепта.

От сервиса к «коробке», или Почувствуй себя героем сериала

История была «как в кино». Неожиданных поворотов в духе Гая Ричи ожидать, конечно, не стоит, но вот сюжет сериала «Кремниевая долина» имеет с проектом нашего NGFW много общего. Мы, как и команда Эрлиха Бахмана, прошли путь от идеи облачного сервиса до создания продукта в железе.

Изначально мы начали создавать решение по концепции, предложенной в свое время Gartner, — Secure Access Service Edge (SASE). Планировали, что на базе нашего SD-WAN мы сможем разворачивать несколько виртуальных машин NGFW и, держа это все в каком-нибудь ЦОДe, предоставлять соответствующий сервис нашим заказчикам. Для российского рынка поставка нашего SASE была возможна в виде on-prem-решения.

Однако уход зарубежных производителей NGFW с российского рынка в 2022 году круто изменил ситуацию и мы явно увидели потребность заказчиков в замене используемых ПАКов NGFW на отечественные решения. В результате мы приоритизировали реализацию NGFW «в железе». Так и зародился программно-аппаратный комплекс, известный сегодня как Kaspersky NGFW.

(Не)смешная нарезка роудмапа и выбор фич для беты

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

1. Количество ресурсов, доступных для разработки. Речь не только про людей в команде RnD и их возможности, но и про различные инструменты для функциональных и нагрузочных тестирований, а также про доступные на рынке аппаратные платформы для формирования линейки устройств. 

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

3. Приоритизация огромного количества требований — самое сложное. Перед командой продукта стоит задача за год пробежать пятилетку и по требованиям от заказчиков «сделать все так же, как у Fortinet, Palo Alto, Check Point и т. п.». При этом очевидно, что весь функционал, доступный в решениях западных вендоров, не будет реализован в первых версиях, поэтому необходимо выбрать наиболее важный и востребованный у большинства заказчиков. Это весьма непростая задача, поэтому приходилось постоянно искать компромиссы и потому периодически менять планы по развитию продукта. Конечно, я всегда стараюсь зафиксировать роадмап и вносить в него лишь минимальные изменения, но постоянный контакт с заказчиками приводит к тому, что приоритеты некоторых фич могут меняться и роадмап всегда получается «живым».

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

Фокус на Enterprise

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

Целевая аудитория Kaspersky NGFW сейчас — это Enterprise-компании, а также крупные представители среднего бизнеса. Эти организации, часто относящиеся к КИИ, во многом похожи на саму «Лабораторию Касперского». Они зрелые в плане информационной безопасности, у них высокие требования к тем решениям, которые используются для построения безопасной и отказоустойчивой сети. Мы их хорошо понимаем. И можем создать для них решение, которое действительно будет лучше других подходить под их требования.

Какая боль, какая боль — про выбор NGFW на российском рынке

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

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

Фичи для бета-версий

При выпуске первой бета-версии NGFW у нас уже был достаточно богатый функционал по обеспечению защиты инфраструктуры, в том числе и интеграция с другими решениями «Лаборатории Касперского», например с платформой для комплексной защиты от сложных угроз Kaspersky Anti Targeted Attack (KATA), в задачи которой входит, среди прочего, анализ объектов сетевого трафика в песочнице. А еще — с XDR-платформой, которая позволяет увеличить видимость того, что происходит в вашей сети и автоматизировать большую часть рутинных операций ИБ-специалистов, в т. ч. реагирование на угрозы через плейбуки.

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

Интерфейс централизованного управления NGFW через OSMP

Поскольку мы изначально целились в сегмент Enterprise, мы реализовали возможность централизованного управления NGFW через консоль Open Single Management Platform (OSMP), которая, в свою очередь, также является платформой для управления XDR-решением. Таким образом, возможно управлять как NGFW, так и XDR в рамках единого окна, гибче реагируя на угрозы и повышая общую эффективность защиты.

Вид интерфейса управления NGFW в OSMP, кстати, стал результатом ряда UX-исследований. В них участвовали и внутренние эксперты «Лаборатории Касперского» (команды телекома и ИБ, например), и внешние (в основном банки, представители промышленного сектора и системные интеграторы). Внешних экспертов мы привлекаем по самым разным каналам, включая работу с рекрутинговыми агентствами. Но также и я, как продакт-менеджер, согласовываю участие в исследованиях представителей наших заказчиков и после этого передаю исследователям их контакты.

В чем соль исследований? А в том, что на их основе меняются не просто отдельные компоненты UI, а целые сценарии в продукте.

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

Первые образцы

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

Так мы смогли проработать железку, которая на том этапе нас устроила, и запаковали всю «начинку» в созданный под нее брендированный корпус. Но, поскольку в приоритете был не безукоризненный внешний вид, а возможность поскорее дать продукт на тесты, первая бета-версия поехала к клиентам в коробках от нашего SD-WAN.

И все же первая бета свою задачу выполнила. Мы хотели получить ранний фидбек — мы его получили. Мы хотели выявить ранние баги — мы их выявили. Еще лучше поняли, что нужно заказчикам, и скорректировали роадмап. Например, план по производительности мы перевыполнили в начале 2024 года (180 Гбит/с в режиме L4 FW + Application control вместо 40 Гбит/с и 18 Гбит/с вместо 10 Гбит/с в режиме NGFW), нативную интеграцию с XDR сделали удобнее уже в первом квартале 2024 года, а работу над синхронизацией сессий в кластере отправили в версию 1.1, вложившись в первую очередь в поддержку дополнительных сценариев работы кластера. Вдобавок учли вопросы к общей производительности фаервола под нагрузкой со всеми включенными движками безопасности. В общем, спасибо лояльным заказчикам — с их грамотным фидбеком мы смогли многое поправить перед второй бетой.

Beta-2 перед коммерческим релизом

Вариант NGFW, который получился к beta-2, обладал более широким пулом сетевых функций. Его уже можно было встраивать в более сложные инфраструктуры, например с NAT, VLANами, агрегированными интерфейсами и прочим. Это подходило тем, ради кого вторая бета и делалась, — заказчикам, которые хотели получить новую версию для пилота перед релизом.

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

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

Внутреннее тестирование

Тестирование NGFW внутри «Лаборатории Касперского» было не менее серьезным, чем внешние испытания. Мы стремимся использовать в своей инфраструктуре свои же решения, поэтому к испытаниям подошли основательно.

Для начала у нас было два тестовых стенда для двух команд: телеком и ИБ. Почему? Потому что это позволило всесторонне оценить готовность продукта. Телеком в первую очередь хочет получить, например, отказоустойчивость, сетевую функциональность и базовые требования по сегментации сети. У команды ИБ приоритеты иные: функционал по работе с событиями, антивирусом, IDPS, веб-фильтрацией и прочим.

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

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

Внешнее тестирование

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

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

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

Послесловие

Процесс разработки Kaspersky NGFW еще раз подтвердил важность гибкого подхода к разработке вне зависимости от того, какой продукт вы создаете: software или hardware (или все сразу). Изначальная идея не подразумевала создание ПАКа, но вот он здесь. Изначальный роадмап где-то попал в точку, где-то его пришлось итеративно и довольно значительно корректировать. Но результат, определенно, стоит вложенных часов и труда.

Ну а текущий роадмап выглядит вот так:

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

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