«Одного пентеста в год уже недостаточно»: как меняется экономика киберустойчивости

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

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

Киберустойчивость добавляет вторую переменную: вы не просто строите периметр, а постоянно его проверяете. Индустрия прошла несколько стадий. Сначала были ручные пентесты: привлекаешь внешнюю команду, которая действует как хакеры, но под контролем заказчика. Это лучше пассивной защиты, однако дорого и долго. А инфраструктура сегодня меняется не раз в квартал, а иногда каждый день. Потом появились программы bug bounty: вы платите не за труд, а за результат, и целое сообщество исследователей начинает искать «дыры» за вас.

Но по-настоящему киберустойчивой я бы назвал модель, в которой поверх всего этого работает автоматизированный контур 24/7: инструмент, который не спит и не устает, непрерывно тестирует периметр и встроен во все процессы — от разработки до продакшена.

Важно понимать: киберустойчивость не отменяет ни пентесты, ни bug bounty. Она дополняет их и собирает в единую цепочку. И здесь ключевой вопрос для бизнеса — не «максимальная защита любой ценой», а баланс. Если выстраивать все и сразу, это будет стоить как космический корабль, и ни один бизнес такое не потянет. Задача — найти экономически оправданную точку в этой цепочке.

Если смотреть на реальные инциденты последних лет, где чаще всего рвется? Фишинг, забытые админки с дефолтными паролями, системные проблемы в архитектуре? Какие векторы сейчас доминируют и почему?

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

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

Одновременно совершенствуются и защитные инструменты. Это классическая борьба меча и щита.

Автоматизированная атака не может работать вечно: рано или поздно щит закрывает найденную уязвимость. Поэтому для защищающейся стороны важно не просто один раз закрыть периметр, а иметь инструмент, который умеет либо сам блокировать новый вектор атаки, либо позволяет очень быстро разработать и внедрить контрмеру.

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

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

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

Задача службы безопасности — перевести это на язык цифр, понятный бизнесу: что случится, если эта система не будет работать сутки? Сколько мы потеряем? И сколько стоит снизить этот риск до приемлемого уровня?

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

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

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

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

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

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

Парадокс: бюджеты на ИБ растут, а дыр меньше не становится. Это проблема нехватки людей, которым можно доверять, или сами инструменты стали слишком громоздкими во внедрении?

— Я бы поспорил с самой предпосылкой — дыр на самом деле становится меньше. Здесь работает эффект, похожий на историю с исследованием океана: чем глубже погружаешься и чем больше об этом рассказываешь, тем значительнее выглядит проблема. Хотя на самом деле просто растет ее видимость.

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

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

Скорость разработки сервисов стала критичным конкурентным фактором, а любая защита — это, по сути, задержка: нужно что-то проверить, прежде чем выпустить в прод. И бизнес нередко сначала выпускает, а потом проверяет. При этом атакующие сканеры работают 24/7, и их не один и не два, а миллионы. Если выставить незащищенный сервис в интернет, уязвимость могут найти в течение минут.

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

Обычно есть специализация по сервисам: CDN — один провайдер, DDoS-защита — другой, сканер уязвимостей — третий. Почему CURATOR решил собрать это под одной платформой?

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

Сканер уязвимостей, который мы вместе представили, логично встает в этот ряд. Мы уже отвечаем за сетевой периметр и за работу приложений в его составе, значит, можем предложить заказчику из одной точки не только инструменты пассивной защиты — анти-DDoS, WAF, сервисы доставки контента, — но и инструменты активной защиты. Это ровно та логика киберустойчивости, о которой мы говорили в начале: одна платформа закрывает и защиту, и ее постоянную проверку.

На рынке уже есть зрелые решения. С каким главным ограничением классических сканеров сталкиваются ИБ-директора сегодня — и почему здесь есть место для нового игрока?

— Если говорить прямо, ниша сканеров уязвимостей исторически была занята зарубежными вендорами — причем даже сильнее, чем рынок DDoS-защиты или WAF. Когда они ушли, рынок практически полностью оголился, и российские компании начали закрывать эту нишу. Это классическая история импортозамещения, во многом похожая на то, что происходило с NGFW. Кто предложит более сильный продукт, тот и займет нишу. Мы, разумеется, рассчитываем на свое решение.

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

— Главная проблема сегодня не в том, чтобы найти уязвимости. Найти их можно очень много. Проблема начинается потом: у команды ИБ ограничены люди и время, у ИТ — свои приоритеты, а бизнес хочет понимать не количество CVE, а что из этого реально может остановить сервис, привести к инциденту или повлиять на деньги. Поэтому хороший сканер должен не просто говорить: «У вас 15 тысяч уязвимостей». Он должен помогать понять, какие из них нужно закрыть сегодня, а какие могут подождать. Для этого мы смотрим на несколько факторов одновременно. EPSS (Exploit Prediction Scoring System — система прогнозирования вероятности эксплуатации уязвимости) помогает оценить, насколько уязвимость востребована у атакующих. Ресурсно-сервисная модель добавляет понимание того, насколько важен сам актив. Потому что один и тот же CVE (Common Vulnerabilities and Exposures — система идентификаторов общеизвестных уязвимостей) на тестовом стенде и на публичном сервисе, через который проходит бизнес, — это совершенно разный риск.

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

Российский энтерпрайз часто живет на самописном legacy без документации. Как современные инструменты анализируют такие системы, не роняя продакшен?

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

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

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

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

Разработчики не очень жалуют средства безопасности, ломающие сборку кода. Как современный сканер встраивается в DevOps-пайплайн, чтобы стать помощником девопса прямо в пулл-реквесте, а не очередным барьером перед деплоем?

— Сканер здесь встает в один ряд с уже привычными инструментами безопасной разработки — статическим и динамическим анализом кода, которые проверяют новую версию перед выкаткой. Его точно так же можно прогонять на тестовом контуре: перед релизом сравнить, не появились ли новые уязвимости по сравнению с предыдущим бенчмарком. Здесь всегда есть напряжение между скоростью разработки и глубиной проверки — та же борьба меча и щита, только внутри процесса разработки.

Для части компаний это не выбор, а обязательное требование. Например, при сертификации по PCI DSS этапы безопасной разработки должны быть встроены в пайплайн по определению. И в таких случаях разработчики особенно требовательны к скорости самого инструмента: раз обойти его нельзя, он должен работать быстро.

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

Ложные срабатывания остаются главной болью любого сканирования. За счет каких техник — проверки контекста, подтверждения эксплуатируемости — получается отсечь шум и показать команде только то, что действительно требует внимания?

— Сегодня я бы даже сказал, что проблема шире, чем просто false positive. Уязвимость может быть совершенно реальной — и при этом не заслуживать внимания команды прямо сейчас. Если у компании тысячи активов, вопрос формулируется по-другому. Не «есть ли у нас уязвимости?» Конечно, есть, к сожалению. Корректная формулировка — «какая из имеющихся уязвимостей с наибольшей вероятностью станет следующим инцидентом?»

Поэтому одного CVSS (Common Vulnerability Scoring System — общая система оценки критичности уязвимостей) недостаточно. Уязвимость может иметь высокий CVSS, но находиться на изолированной тестовой машине. А проблема со средней оценкой может находиться на критичном сервисе, доступном из интернета.

Мы добавляем к технической оценке контекст: EPSS, данные об активе, его роль в ресурсно-сервисной модели. И вот тогда вместо очереди из тысяч одинаково «красных» проблем появляется нормальная картина приоритетов.

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

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

Где физически выполняется проверка облачными инструментами — снаружи по портам, гибридная модель или на мощностях клиента? Как обеспечивается соблюдение ФЗ-152, если данные проходят через инфраструктуру провайдера?

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

Что касается ФЗ-152, здесь важно уточнение: в нашей модели клиентские данные через нас не проходят, потому что мы ищем уязвимости именно снаружи, не имея доступа внутрь инфраструктуры заказчика.

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

Заглянем на два-три года вперед. Киберустойчивость станет полностью автономной благодаря ИИ, который обгонит хакеров, — или мы окончательно уйдем от зоопарка инструментов к единым платформам?

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

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

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

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

А вот вопрос объединения инструментов в единые платформы — это на самом деле не столько технологический, сколько вопрос модели продаж.

В идеальном мире заказчика все инструменты одного класса имели бы общий API, и можно было бы легко тестировать несколько решений параллельно и переключаться на лучшее по мере выхода новых версий. Но экономически вендору выгоднее противоположное — удерживать заказчика внутри своей экосистемы, предлагая все больше сервисов на одной платформе, как это делают банки со своими экосистемами. Поэтому чистого рыночного объединения в духе «победитель забирает все» ждать не стоит.
Применительно к рынку сканеров — я думаю, консолидация займет заметно больше времени, чем в свое время произошло с NGFW. Сканеры значительно дешевле, и заказчики вполне могут позволить себе использовать сразу несколько решений параллельно ради более полного покрытия — в отличие от NGFW, который стоит в одной точке инфраструктуры и физически не размножается. Рынок будет какое-то время делиться по соотношению цены и качества, а не схлопываться в одного игрока.

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

Отдельно мы смотрим в сторону инструментов класса AI Gateway — решений, которые контролируют, чтобы данные не утекали наружу через корпоративное использование языковых моделей. Здесь скоро планируем совместный анонс с партнером.