? Это часть 4 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Место VM в управлении ИБ компании

Если спросить у ChatGPT, какое место занимает управление уязвимостями в информационной безопасности, он выдаст что-то вроде: “Процесс управления уязвимостями занимает одно из ключевых мест в управлении ИБ любой организации, поскольку уязвимости могут быть использованы злоумышленниками для атак и несанкционированного доступа к данным”. Гладко, правильно и совершенно неживо. Объясним по-человечески.

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

1. Поиск дыр в стенах. Вы обходите дом и ищете места, через которые могут пробраться воры: проверяете окна, двери, скрытые лазы. Так же и компьютеры с сетями имеют “дыры” - уязвимости, через которые проникают злоумышленники

2. Закрытие дыр. Нашли щель в стене - заделали. В ИБ мы закрываем уязвимости, чтобы их нельзя было использовать

3. Регулярные проверки. Вы же не осматриваете дом один раз в жизни. Проверяете периодически. С инфраструктурой так же: сканировать нужно постоянно

4. Безопасность важнее всего. Дыру в стене вы не оставите без внимания. Уязвимость игнорировать тоже нельзя

На этом простом примере видно: VM - фундамент информационной безопасности. Вот почему он так важен:

• Предотвращение атак. Уязвимости - точка входа для злоумышленника. Управление уязвимостями позволяет находить и закрывать их до того, как кто-то воспользуется

• Снижение рисков. Активное управление уязвимостями снижает риски, особенно когда ландшафт угроз меняется так быстро. И цена бездействия растет: по оценке IBM, в 2025 году один инцидент с утечкой данных обходился компаниям в среднем в 4,44 млн долларов по миру [5]. На этом фоне затраты на нормальный процесс VM выглядят скромно

• Соответствие требованиям. Множество стандартов и нормативных актов (152-ФЗ, приказы ФСТЭК № 21, 239 и новый № 117, ГОСТ Р 57580.1 для финансовых организаций, PCI DSS) требуют управлять уязвимостями. Причем регулятор перешел от общих слов к конкретике: приказ ФСТЭК № 117, заменивший устаревший № 17, прямо задает сроки - критические уязвимости в государственных системах закрываем не дольше суток, высокие - за семь дней, а инфраструктуру сканируем не реже раза в месяц [6]. Раньше многие отмахивались: “Серьезные последствия - это штраф в 60 тысяч рублей, что ли?” Так вот, эти времена прошли: с 30 мая 2025 года штраф за утечку персональных данных доходит до 15 млн рублей (а за утечку биометрии - до 20 млн), за повторную же утечку грозит оборотный штраф от 0,1 до 3% годовой выручки, но не меньше 20 млн и не больше 500 млн рублей [1]. Да и помимо штрафов: в каждом таком стандарте заложена база ИБ, без которой ничего толкового не построишь. А PCI DSS обязателен для всех, кто хранит и обрабатывает данные платежных карт, будь то ритейл, телеком или банк

• Защита цифровых активов. Уязвимости бьют по данным, а заодно и по репутации. Репутацию зарабатывают годами, а теряют за пять минут, “войдя не в ту дверь”. Хотя, честно говоря, иногда ее можно и быстро восстановить - если инцидент не катастрофичен и у компании большой запас доверия. Так что пункт работает не всегда

• Эффективное использование ресурсов. Фокус на критичных уязвимостях оптимизирует затраты. А постоянный патч-менеджмент приводит инфраструктуру к единообразию. Сравните: в первой компании серверы разношерстные (Linux 1.7.1, 1.6.5, 1.6.9), во второй везде одна версия 1.7. Где проще накатить обновление безопасности? Ответ очевиден

Спорить тут не с чем: управление уязвимостями - неотъемлемая часть стратегии ИБ.

Введение в построение процесса VM

Почему вообще все носятся с уязвимостями? Потому что их поток не иссякает. Я уже приводил примеры из без NVD или различным отчетам в главах ранее.

А что мы видим на практике? Часто слышу от коллег: “У нас внедрен сканер защищенности, значит, процесс есть”. Начинаю задавать вопросы: как часто сканируете, что именно, как анализируете уязвимости, кто отвечает за устранение, какие сроки? И когда в ответ звучит “не знаю”, “где-то записано”, “это вопрос не ко мне”, “спросите другую команду” - становится ясно: процесса нет. Есть купленный инструмент, который никто толком не использует.

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

Что такое процесс

Любой процесс складывается из четырех элементов.

Workflow - последовательность действий, которая по определенной методологии ведет из точки A в точку B. Это “маршрут”.

Технические решения - инструменты, автоматизирующие процесс целиком или его отдельные этапы. Это “транспорт”.

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

Метрики и управляющее воздействие. Процесс не существует в вакууме. Чтобы он давал результат, его нужно измерять и корректировать. Для этого используются метрики (MTTR, покрытие, доля просроченных уязвимостей), которые помогают отслеживать состояние и непрерывно улучшать процесс. Подробнее о метриках - в отдельной главе про зрелость VM.

И еще одна важная вещь, которая скрепляет все вместе, - SLA (Service Level Agreement). Это зафиксированные договоренности между командами: кто, что, в какие сроки и в каком формате делает.

Построение процесса управления уязвимостями

У построения процесса множество подводных камней. Нужны вовлеченность и согласованность трех сторон: бизнеса, ИТ-департамента и подразделения ИБ. Из моего опыта - четыре типовые причины, по которым процесс “не взлетает”.

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

Вторая: параметры процесса не согласованы между участниками. Классика: команда ИБ сама определила сроки устранения уязвимостей, но не согласовала их с ИТ. Результат предсказуем: уязвимости не устраняются в срок, а на претензии ИТ отвечает: “У нас свои сроки, про ваши мы ничего не слышали, с нами никто не согласовывал”. И формально ИТ право.

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

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

Цель процесса управления уязвимостями

Цель проста на словах и сложна на деле: сделать проникновение злоумышленника в сеть максимально трудной или невыполнимой задачей. Для этого нужно:

• анализировать информацию о существующих и потенциальных уязвимостях

• оценивать их влияние на защищенность компании

• оперативно устранять

• контролировать результаты

• постоянно улучшать процесс

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

Напомню два ключевых понятия, вокруг которых все строится:

Целевая система - конечная цель злоумышленника при реализации недопустимого события. Например, для недопустимого события “кража денег на сумму N рублей” целевой системой будет “1С”.

Ключевая система - система, взлом которой существенно упрощает атаку или повышает ее эффективность. Для того же недопустимого события ключевой системой будет контроллер домена: захватив его, злоумышленник откроет себе путь к “1С”.

Именно недопустимые события позволяют определить объект защиты и расставить приоритеты для всего процесса VM. Не “защищаем все подряд”, а “защищаем то, через что нас реально могут уничтожить”.

Процесс безопасной разработки (AppSec)

Я не претендую на детальный разбор безопасной разработки - об этом написаны отдельные книги и специалисты точно найдут что добавить. Но “базу” подсветить стоит, потому что управление уязвимостями и безопасная разработка - близкие родственники.

Что такое DevOps и как он связан с AppSec

DevOps - подход, объединяющий разработку (Dev) и эксплуатацию (Ops): люди, процессы и технологии работают сообща на всех этапах - от планирования приложения до его эксплуатации. Раньше разделенные роли (разработчики, ИТ-операции, тестировщики, безопасники) начинают действовать заодно.

DevOps тесно связан с AppSec (безопасностью приложений), потому что безопасность - часть жизненного цикла разработки. Когда практики DevOps дополняются безопасностью, говорят о DevSecOps: безопасность встроена в каждый этап, от планирования до эксплуатации, а не прикручивается в конце “для галочки”.

В России AppSec активно развивается: на это влияют рост киберугроз, ужесточение нормативной базы (тот же ГОСТ Р 56939-2024 о безопасной разработке, который вместо разрозненных требований версии 2016 года описал уже 25 процессов, среди них моделирование угроз, управление секретами и композиционный анализ сторонних компонентов [7]) и формирование сообщества. Меняются подходы к работе со сторонним кодом, обсуждается автоматизация проверок безопасности в SDLC. Важно, что появились отечественные инструменты статического и динамического анализа, так что импортозамещение коснулось и этой области.

Этапы безопасной разработки

1. Анализ и требования. Определяются функциональные и нефункциональные требования, включая требования безопасности

2. Планирование. Формируется план разработки, в том числе план обеспечения безопасности

3. Проектирование. Архитектуру проектируют так, чтобы безопасность была заложена изначально (тут особенно важно не допустить “небезопасного дизайна” - в обновленном OWASP Top 10 версии 2025 года эта категория никуда не делась и держится на позиции A06)

4. Разработка. ПО пишется по плану

5. Тестирование. В том числе тестирование на безопасность

6. Развертывание и эксплуатация. ПО запускается, мониторинг безопасности продолжается

Безопасная разработка - это инструменты, но в первую очередь культура. Из инструментов главные:

• SAST (static application security testing) - статический анализ исходного кода

• DAST (dynamic application security testing) - анализ работающего приложения

• SCA (software composition analysis) - анализ сторонних компонентов и зависимостей (тесно связан с темой SBOM, “списка ингредиентов” приложения)

• IAST (interactive application security testing) - гибрид статического и динамического подходов

Плюс системы контроля версий (Git) и непрерывная интеграция (CI/CD), в которые встраиваются проверки безопасности.

Важная оговорка

Есть распространенное заблуждение: если выстроить безопасную разработку, уязвимости в ПО исчезнут. Передаю привет тем, кто так же думает про сертификат ФСТЭК. Полностью обезопаситься нельзя: уязвимость не обязательно ошибка в коде, иногда это изъян бизнес-логики. А иногда опасное поведение вообще считается “нормальной работой приложения”.

Аналогия с вредоносами: в зловреде может быть несколько файлов, и все, кроме одного, - доверенные подписанные библиотеки. Одна из них и запускает вредоносный код. Формально все легитимно, подписи на месте, а станция заражена. И архитектуру, которая это допускает, в компании назовут “не багом, а фичей”.

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

А как у вас?

У вас процесс VM описан в документах или держится на памяти конкретных людей? И главный вопрос: согласованы ли сроки устранения между ИБ и ИТ на бумаге - или каждый живет по своему регламенту, как в примере из статьи?

Навигация по серии: ⬅️ Предыдущая: Гл. 3. Через что вас взломают · ? Оглавление серии · Следующая: Гл. 5. Не строить, а арендовать ➡️

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