Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Прошлый год проходил под эгидой вынужденного импортозамещения: вендоры ИТ и ИБ уходили, забирая с собой обновления, сигнатуры и лицензии. А хакеры радовались уязвимостям, которые компании просто не могли закрыть. Словом, патча нет, но вы держитесь! С поиском незакрытых уязвимостей тоже все оказалось непросто. Топовые зарубежные сканеры ушли из России. Многие остались без эффективного инструмента – и мы в том числе, ведь наш облачный сервис контроля уязвимостей (VM, Vulnerability Management) был построен с использованием технологической платформы американского Qualys. Мы уже рассказывали, как спасали наши сервисы ИБ после ухода зарубежных вендоров, но найти замену для VM оказалось сложнее всего. В этом посте поговорим о том, как мы выбирали альтернативу Qualys, и что происходит с российским рынком сканеров уязвимостей сейчас.
Итак, VM у нас облачный. И сначала все было неплохо: мы были на связи с российским офисом компании, об уходе с нашего рынка никто не говорил. Но вдруг 3 марта мониторинг зафиксировал недоступность платформы. Думали, что DDoS или технические работы на стороне вендора, но оказалось проще (и грустнее) – американский офис просто отозвал нашу лицензию (о чем, кстати, российское подразделение узнало вместе с нами). Так наши отношения с Qualys завершились.
Достойных российских продуктов на рынке были единицы, и они нам не очень подходили. Стало очевидно, что наш рынок сканеров уязвимостей очень долго жил и продолжает жить в парадигме on-premise. Отсюда проблема: отсутствие ориентированного на MSSP, то есть на сервис-провайдера, функционала (управляемая модель доступа и мультиклиентность, расчет на работу из облака).
Что сделали сразу
Для текущих клиентов все сложилось без особых потерь: на момент ухода Qulays у нас не было плановых сканирований. Были контракты на стадии заключения, но удалось договориться с заказчиками и немного перенести дату сканирования, которое в итоге сделали на альтернативном решении.
Конечно, говорить, что ситуация никак не нарушила наши планы – лукавство. Мы многого хотели от VM, а теперь нам пришлось сильно сузить воронку потенциальных клиентов: нового заказчика брали в работу только при наличии у него собственного сканера. Раньше мы такого не делали, но вариант оказался вполне рабочим и понятным для клиента (все-таки знакомый сканер).
Это позволило сохранить сервис, но в то же время принесло ряд сложностей. В частности, проблемы со сканером на стороне заказчика мог решать только сам заказчик. Например, если перестал работать токен лицензии или давно не обновлялись базы уязвимостей. Один раз нам выгрузили отчет на английском, чего наша автоматизация отчетов, уже приспособленная на этот момент к русскоязычным выгрузкам из отечественных сканеров, не ожидала и не смогла обработать данные.
Наша коммуникация с клиентом усложнялась и по другим причинам. Например, не у всех был собственный сканер в инфраструктуре, и его обслуживание с проведением работ по сканированию осуществлял подрядчик. Мы же должны были проанализировать полученные данные. Но коммуникация двух подрядчиков не всегда проходит гладко и эффективно, нам приходилось писать подробные инструкции по планируемым работам и о том, что именно мы хотим получить по итогу работ. Это сильно затягивало процесс, а результат иногда был непредсказуем.
Параллельно из-за изменений в параметрах сервиса и возможностях сканера нам потребовалось актуализировать все материалы, техническое задание, подготовить нужные инструкции. Весьма трудозатратным оказалось обновление шаблонов отчетов по сервису – потребовалась переработка формул и автоматизации.
Как развивалась ситуация
Конечно, и раньше мы искали идеальный сканер – наиболее функциональный и подходящий нам. Отечественных альтернатив было немного, да и необходимости смотреть в их сторону ранее не возникало. Возможно, это было не очень дальновидно с нашей стороны, но, согласитесь, почти никто не смотрел. Кроме того, развернуть свой облачный сканер на базе отечественного решения – это сложный процесс, который требует времени, трудозатрат и договоренностей с вендором о лицензировании.
В итоге мы начали тестировать разные отечественные сканеры, провели несколько сравнительных анализов. Важно было понять производительность, плюсы и минусы инструмента, с которым будем в дальнейшем работать. Расширяя горизонты технологий, мы пополняли и нашу экспертизу.
Мы одновременно работали с несколькими сканерами, а это разные форматы данных, различное представление информации. Это все необходимо было завернуть в стандартизированный сервис с похожим выходным результатом вне зависимости от сканера. Нам пришлось менять форматы отчетов, обновлять списки приоритизации уязвимостей и их категории. Дополнительная категоризация для замены TI (которая была в Qualys и отсутствует во всех отечественных сканерах) нарабатывалась нашими аналитиками за счет раскрытия качественных метрик (как из базы знаний сканеров, так и из внешних источников).
Для одного из сканеров пришлось писать специальный парсер для отчетов. Написали-то быстро, а вот в структуре отчета разбирались долго. Наше основное требование к сканеру – возможность выгрузки отчетов, пригодных к дальнейшей обработке в Excel, то есть pdf и html нам не походят. Почему – мы подробно описывали вот в этом посте. Если кратко, нам нужны табличные данные с простой понятной структурой. Идеально – формат csv. Хотя и xml в случае простой структуры тоже подходит. Например, в одном из сканеров имелась выгрузка в xml, состоящая из множества разных таблиц. Импорт таких результатов в Excel дает непригодную для работы и даже понимания сборку из всех таблиц на одном листе. Долго разбирались, как устроена структура данных в этом xml и как его правильно разделить на отдельные таблицы. Затем автоматизировали этот шаг с помощью парсера на Python. Справились, конечно, но хотелось бы иметь пригодные к работе отчеты из коробки.
С чем мы в итоге сейчас работаем
Идеально подходящего для MSSP сканера мы пока не нашли. Это не значит, что российские сканеры плохие, просто рынок очень сконцентрирован на решении задачи VM именно в формате in-house.
C некоторыми вендорами мы провели переговоры о лицензировании их продукта для облачного провайдера – получили версии сканеров, пригодные для использования в облаке и в основном соответсвующие нашему видению сервиса, провели ряд тестов и пилотов. Один из сканеров ввели в эксплуатацию в рамках сервиса. Словом, потребности клиентов закрыли, но поиски продолжаются.
В процессе выбора мы столкнулись с тем, что на отечественном рынке фактически нет сканера веб-приложений (WAS) или VM-сканеров c подобным функционалом. Это было значимой частью нашего сервиса, ведь в современных реалиях контроль веб-уязвимостей становится одной из ключевых задач VM. В 1 и 2 кварталах 2022 года именно веб-уязвимости были основной причиной критических инцидентов. Об этом мы писали в квартальных отчетах: тут и тут.
Тестировали несколько opensource-решений, но пришли к выводу что не сможем на текущем этапе их развития оказать с их помощью качественный сервис. Несмотря на появление нескольких WAS-сканеров на рынке в конце года, все равно подходящего под нужды нашего сервиса, увы, пока не нашли.
Сейчас серьезно рассматриваем 2 самостоятельных российских WAS-сканера, но для эксплуатации в рамках сервиса есть несколько преград. Например, в одном из них отсутствует возможность выгружать отчеты, а в другом – представление результатов очень сырое и непрозрачное. Мы провели анализ ПО, подсветили актуальные проблемы вендорам и получили от последних обратную связь (в некоторых случаях roadmap по развитию продукта, коррелирующий с нашим сервисом).
Выводы
Сканеры уязвимостей родом из России есть на рынке, и этот рынок существует. Есть хорошие решения, вендоры открыты к взаимодействию и развивают свои продукты. Это радует. Кстати, появляются новые решения и вне отечественного рынка (единицы вендоров готовы работать с Россией), на которые мы тоже обращаем внимание.
Несмотря на уход Qualys, сервис мы сохранили, а благодаря тестированию и работе с новыми для нас продуктами нарастили собственную экспертизу и развили саму услугу VM.
Наконец, хороший сканер – не равен хорошей экспертизе. Все-таки это лишь инструмент, который в той или иной степени подсвечивает проблемы в инфраструктуре. А вот обработка данных и их приоритизация требуют специалистов по эксплуатации и аналитиков.
Но именно благодаря взаимодействию экспертов, эксплуатирующих сервис, и вендоров можно реализовывать новые идеи и создавать крутые продукты.
Авторы:
Данила Лопаткин, инженер группы эксплуатации сервисных платформ "РТК-Солар"
Юрий Брежнев, аналитик группы эксплуатации сервисных платформ "РТК-Солар"
