InfoWatch ARMA Стена (NGFW). Реальный опыт внедрения на собственной инфраструктуре, результаты и выводы

InfoWatch ARMA Стена (NGFW). Реальный опыт внедрения на собственной инфраструктуре, результаты и выводы

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

На основе опыта внедрения собственного продукта InfoWatch ARMA Стена (NGFW) на инфраструктуре ГК InfoWatch рассказываем, как развиваются события, когда компания уже выбрала межсетевой экран и приступает к его пилотированию. Мы дадим рекомендации для заказчиков NGFW, какие важные моменты нужно учесть на старте, как сформировать список требований, какие шаги нужно предпринять для доработки и как на выходе получить рабочий продукт. Сегодня InfoWatch ARMA Стена (NGFW) защищает всю инфраструктуру ГК InfoWatch, а мы благодаря этому пилоту «прочувствовали» все этапы внедрения NGFW в двойном объеме как заказчик и как разработчик. Наш опыт будет полезен заказчикам любого NGFW, поскольку их ждут аналогичные вызовы, ведь большинство российских решений еще только проходит обкатку реальной практикой.

Созданием NGFW мы, как и большинство компаний на российском рынке, вплотную занимаемся последние несколько лет, при этом еще в 2019 году мы разработали и выпустили коммерческий релиз МСЭ для защиты промышленных сетей InfoWatch Industrial ARMA Firewall, который отлично зарекомендовал себя на рынке. То есть в разработке межсетевых экранов мы далеко не новички. На базе этого промышленного экрана была построена первая версия NGFW.

Владимир Садовников, СТО InfoWatch ARMA: «В 2022 году после ухода зарубежных производителей многие российские компании остались без защиты от кибератак, количество которых резко выросло, поэтому нам было важно предложить рынку рабочий вариант защиты сетевого периметра. Однако по мере разработки функциональности мы пришли к необходимости создания новой платформы для корпоративного NGFW – с новым уровнем производительности и широким набором опций, а значит и другой архитектурой».

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

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

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

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

В какой-то момент мы решили «съесть кактус» целиком и внедрить наш NGFW на инфраструктуру ГК InfoWatch в качестве основного решения. Этот переход также позволял нам отладить процесс технической поддержки продукта, провести эксплуатацию последней версии в рабочих условиях и предоставить в команду разработки максимально развернутый отчет о выявленных дефектах. Сейчас это звучит сильно упрощенно, но на практике все происходило гораздо сложнее. Внутреннее пилотирование оказало большое влияние на весь процесс разработки. Разработчики следовали старому принципу Eat your own dog food, так как фактически они сами первыми сталкивались с результатами своего труда. Весь процесс внедрения можно разделить на несколько ключевых блоков:

• Cоставление ТЗ и требований
• Доработка
• Внедрение
• Техническая поддержка
• Выводы

Составление ТЗ: торг, компромисс и урезание требований

В формировании ТЗ принимали участие департаменты ИТ и ИБ ГК InfoWatch, каждый из которых предоставил свой список требований. По факту эти списки представляли собой развернутый перечень возможностей иностранного NGFW.

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

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

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

Владимир Садовников: «Некоторые заказчики говорят нам, сделайте как у Check Point, а там еще более навороченный комбайн, еще более сложный маршрутизатор, еще больше протоколов, но не все это действительно необходимо. Давайте исходить из своих реальных потребностей, не нужно во всем ориентироваться на западные решения с их спецификой и более чем 50-летним опытом разработки. Не нужно искать цифры и показатели Cisco в отечественных продуктах, лучше оценить то, что реально нужно вашему бизнесу прямо сейчас».

Доработка: производительность и функциональность, которых достаточно

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

Много усилий пришлось потратить на мелкие доработки, чтобы все «поехало», как надо. Каждый пункт из списка требований сначала тестировался внутри команды разработки, потом в команде ГК InfoWatch. Значительная часть времени ушла на внутреннюю коммуникацию и консультирование, так как поначалу было сложно воспринимать свою компанию как внешнего заказчика: все сидят в одном офисе и для решения срочного вопроса проще дойти в коллегу ногами, вместо того, чтобы заводить тикет в CRM.

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

Сегодня мы производим NGFW в трех аппаратных конфигурациях: К10000, К1000 и К100. Все аппаратные платформы сертифицированы Минпромторгом и отличаются форм-факторами, количеством портов и пропускной способностью. Они отвечают запросам большинства коммерческих компаний на российском рынке – как сегмента средний бизнес, так и крупных. Как правило, в их распределенной инфраструктуре распространены именно сетевые интерфейсы 1 Гбит/сек и 10 Гбит/сек. К слову, в наших собственных сетях только в отдельных точках было 10 Гбит/сек, остальное все было гигабитное. Что касается интерфейсов 25 Гбит/сек или 40 Гбит/сек – это уже уровень дата-центров.

Недавно InfoWatch ARMA Стена (NGFW) успешно прошел независимое тестирование в формате vendor-agnostic в лаборатории «Инфосистемы Джет». По результатам тестов наше решение показало производительность 6,2 Гбит/с, что полностью отвечает требованиям корпоративного сегмента. На момент завершения тестов нашего NGFW, это был лидирующий результат среди российских решений, представленных в проекте.

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

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

Основные характеристики InfoWatch ARMA Стена (NGFW)

• Стабильная скорость до 8 Гбит/сек при 35000 правил IPS и 100 правилах МЭ (по результатам внутренних тестов InfoWatch).
• Cкорость до 6,2 Гбит/с при 55000 правилах IPS и 200 правилах МЭ (по результатам независимого тестирования компании «Инфосистемы Джет»).
• В линейке – три аппаратные конфигурации NGFW: с производительностью 100 Мбит/сек, 1 Гбит/сек и 10 Гбит/сек.

Почему NGFW показывает разные скорости?

Основная сложность тестирования заключается в том, что существуют очень разные сценарии использования. Результат, полученный во время тестирования в лаборатории «Инфосистемы Джет», показывает скорость, полученную во время атаки и при срабатывании практически всех правил, чего и требует методика. В реальной жизни мы можем написать гораздо больше правил и при этом получить еще более высокую скорость.  Однако для написания правил межсетевого экрана нужна определенная топология сети, без которой получится только множество надуманных правил, которые никогда не отработают или же будут слишком однотипными, что также слишком отдалит синтетические тесты от реальных сценариев использования. Во время тестирования в «Инфосистемы Джет» мы получили скорость 6,2 Гбит/с, хотя на практике при таком же наборе правил у наших заказчиков и на наших собственных мощностях мы легко получаем скорость свыше 8 Гбит/с. Часто слышу вопрос, почему нельзя получить ровно 10 Гбит/с? Это априори недостижимая цифра, так как по мере включения большего числа правил и усложнения логики разбора трафика затрачивается ненулевое время на его обработку, что как раз съедает часть пропускной способности.

Внедрение: ожидания и реальность

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

Проблема, с которой мы столкнулись – наша большая сеть, в которой все «крутилось» на разном оборудовании, оказалась не готова к NGFW. Реальность и наши ожидания сильно разошлись. Тогда мы сделали первый тестовый контур ARMA, который на данный момент работает как полноценная тестовая альфа-лаборатория, куда выгружаются самые свежие версии, а во внешний контур уходят протестированные и более стабильные релизы.

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

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

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

Изобретен аппарат автоматического бритья:

— Бросаешь рубль, суешь туда голову, и он тебя автоматически бреет.

— Но ведь у всех разные лица!?!?

— До первого бритья да...

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

Техническая поддержка, протестированная на себе

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

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

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

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

Что дальше?

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

До конца 2024 года мы расширим интеграционные возможности нашего продукта в части его взаимодействия с внешними SIEM-системами, консолью управления InfoWatch ARMA Management Console и линейкой DLP-продуктов компании InfoWatch. Интеграция крайне важна, поскольку внедрение NGFW происходит на сформированной инфраструктуре и наш продукт должен качественно дополнять все ее элементы – например, обогащать SIEM-систему данными, управляться централизованно через привычный клиенту интерфейс, давать возможность реализации новых сценариев DLP.

Также мы продолжаем процесс сертификации программной части нашего продукта. До конца 2024 года мы рассчитываем получить от ФСТЭК подтверждение по типам профилей защиты Б и Д, а в следующем году – по типам А и ММЭ.

Выводы по результатам внутреннего пилота

1. Компании, которая решила поставить у себя NGFW, нужно обязательно готовить к этому свою ИБ-службу: пересматривать правила, которыми они закрывали безопасность сети, и адаптировать их под новое решение. ИБ-специалистам должно быть удобно работать с новым инструментом.
2. Не стоит ориентироваться на абстрактные цифры по производительности из тендерных заданий. Лучше оценить реальные показатели, которые поддерживают ваши сети и сетевые карты, а также скорости ваших устройств. 
3. Даже при наличии типовых сценариев универсального NGFW нет и не может быть. Сегменты сети в каждой организации разные, и нагрузка в разных сегментах распределяется по-разному. В одном из наших пилотных проектов у заказчика из промышленного сектора не оказалось единой точки входа трафика, и мы после долгих совместных поисков нашли наиболее критичные места: две точки с кластерами, где реально проходил трафик 10 Гбит/с, и две без кластеров – чуть менее важный сегмент с трафиком до 100 Мбит/с. Это хороший пример того, как у одного клиента для закрытия его потребностей были применены сразу несколько продуктов нашей линейки.

И, наверное, самый общезначимый вывод:

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

Реклама. АО «ИНФОВОТЧ», ИНН: 7713515534, Erid: 2VfnxwV4orx