Журнал "Information Security/ Информационная безопасность" #3, 2025

устранением уязвимости. В зависимости от внутренних процессов компании это может занять от пары дней до несколь- ких месяцев – зависит от ритма сприн- тов, заморозок, внутренних регламен- тов. И если кажется, что все сводится к обновлению версии компонента с младшей на старшую, то вы сильно ошибаетесь. На деле возникает масса сложностей: обратная несовместимость, каскадные зависимости, конфликты с другими компонентами и микросерви- сами. В результате даже первая версия с исправлением может потребовать немалого времени на подготовку. А тем временем уязвимый сервис по-прежне- му работает в продакшене. Фаза 7: Тестирование новой версии. Разумеется, никто (по крайней мере, хочется в это верить) не выкаты- вает новую версию сразу в продакшен. Сначала ее проверяют тестировщики: прогоняют через регрессионные и нагру- зочные тесты, оценивают стабильность, производительность, совместимость. Если возникают проблемы, компонент уходит на доработку. А время по-преж- нему работает против нас. Фаза 8. Выкатка на Test- и Pre- Prod-окружения. Если тестирование прошло успешно, начинается поэтапный выпуск новой версии: сначала в Test-, затем в Pre-Prod-окружения. Этот про- цесс тоже занимает время, и, как и раньше, оно жестко играет против нас. Фаза 9. Разворачивание на Prod-окружениях. И только теперь, спустя N дней или даже месяцев, начи- нается выкатка обновления в продакшен. Этот этап тоже не так прост, как может показаться. Его сдерживают регламент- ные окна, циклы обновлений, необходи- мость поэтапного развертывания, осо- бенности сегментации и доступности разных кластеров. В крупных распреде- ленных инфраструктурах обновление не происходит по щелчку пальцев – это сложный и чувствительный процесс. Фаза 10. Все сначала. Мы описали лишь упрощенный пример – одну уязви- мость в одном компоненте одного мик- росервиса. В реальности таких случаев на порядки больше. Этот процесс нико- гда не прекращается: с каждой новой версией компонентов появляются новые уязвимости. Работа по их выявлению и устранению непрерывна. Это по сути бесконечный цикл. Решение 1: Приоритизация уязви- мостей (реактивный подход) Исправить абсолютно все уязвимости невозможно – да и не нужно. Значитель- ная их часть никак не влияет на безопас- ность микросервисов: это могут быть неиспользуемые исполняемые файлы, библиотеки или пути в коде, которые не задействуются конечным приложением. Такие случаи – типичный False Positive. Мир уже отошел от парадигмы полной нетерпимости к уязвимостям (Zero Tole- rance). В ее рамках вы бы не выпустили ни одного релиза и ни одного продукта. В первую очередь необходимо закры- вать те уязвимости, через которые зло- умышленник с наибольшей вероятностью сможет нанести реальный ущерб. Для этого критично уметь приоритизировать результаты сканирования. В Luntry мы выделяем и предоставляем следующие критерии для такой приоритизации: l CVSS (Common Vulnerability Scoring System) – классическая оценка уровня уязвимости, база. l Severity – критичность уязвимости. l Type (RCE/DoS) – тип уязвимости. В микросервисной среде нас интересуют в первую очередь сетевые векторы. l Exploit – наличие в публичном доступе готового эксплойта. Это резко повышает риск: уязвимость становится легко воспроизводимой, провоцирует массо- вые атаки и серьезно увеличивает веро- ятность инцидента. l KEV (Known Exploited Vulnerabilities) – наличие уязвимости в базе инцидентов, подтверждающих ее реальное исполь- зование в атаках. Это означает, что уязвимость уже эксплуатируется зло- умышленниками "в поле", и риск ее эксплуатации в вашей инфраструктуре крайне высок. l EPSS (Exploit Prediction Scoring Sys- tem) – это система оценки вероятности эксплуатации уязвимости в будущем. l Runtime – подтвержденное наличие уязвимости в компонентах, запущенных в продакшене. Такой подход позволяет сосредоточиться на реально работающих и потенциально уязвимых элементах, исключая из анализа неиспользуемый код. Такая приоритизация позволяет сокра- тить объем задач для разработчиков с десятков тысяч до считанных десятков. Это экономит время всех команд и значи- тельно ускоряет повышение реального уровня безопасности, фокусируя усилия на том, что действительно важно. Можно пойти дальше и подключить дру- гие подсистемы Luntry – например, опре- делить, находится ли уязвимый сервис на поверхности атаки или защищен компен- сирующими мерами. Эти факторы допол- нительно снижают вероятность успешной атаки и, соответственно, позволяют пони- зить приоритет на исправление. Решение 2: Уменьшение поверх- ности атаки (проактивный подход) В этом случае мы делаем так, чтобы при наличии известных или даже неизвестных уязвимостей через них было бы невозможно или чрезвычайно сложно нанести ущерб. В этой парадигме Luntry позволяет: l С помощью контролей микросервисов запускать только доверенные микросер- висы, соответствующего уровня безопас- ности, что не позволит внутреннему нару- шителю выкатить приложение не соот- ветствующего уровня безопасности. l С помощью политик предотвращения создать список только доверенных про- цессов, что приводит к тому, что ата- кующий не способен запустить свой вредоносный код. l С помощью автоматической генера- ции и применения Network Policy, реали- зовать микросегментацию для создания Zero Trust-модели между микросерви- сами. Таким образом, атакующий не сможет что-то загрузить или выкачать из вашей сети. В результате это дает дополнительное время на устранение уязвимости – без риска быть скомпрометированным в про- цессе. Команды могут работать спокой- нее и системнее, не жертвуя безопас- ностью ради срочности. А вывод? Вывод такой: в современных реалиях необходимо грамотно сочетать про- активный и реактивный подход с приоритизацией. Только такой ком- плекс мер позволит дать реальный прирост уровня безопасности на деле, а не на бумаге. l • 65 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru Рис. 3. Результат фильтрации уязимостей в Luntry Рис. 2. Фильтрация уязимостей в Luntry На правах рекламы Ваше мнение и вопросы присылайте по адресу is@groteck.ru