Жизненный цикл управления уязвимостями

Управление уязвимостями (VM) — это не разовая проверка, а непрерывная программа. Рассмотрение этого процесса как жизненного цикла обеспечивает регулярный поиск, оценку, определение приоритетов, устранение и подтверждение закрытия уязвимостей, вместо того чтобы они накапливались в отчёте, который никто не просматривает.

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

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

• Узлы, облачные экземпляры, контейнеры, службы и версии программного обеспечения.
• Проверки с аутентификацией и без неё.
• Пассивное обнаружение и картирование внешней поверхности атаки.

Неполный перечень активов — самая распространённая причина, по которой программы управления уязвимостями терпят неудачу.

Оценка проверяет и дополняет контекстом исходные результаты. Сканер сообщает о CVE, а оценка помогает выяснить:

• Действительно ли это уязвимость или ложноположительный результат?
• Действительно ли затронутый компонент используется и доступен?
• Какова техническая степень серьезности и каков бизнес-контекст?

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

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

Грамотная расстановка приоритетов учитывает степень серьезности (CVSS), вероятность эксплуатации (EPSS), известную активную эксплуатацию (KEV), а также ценность и доступность актива для бизнеса. Установка исправлений только на основе CVSS приводит к напрасным затратам на теоретические проблемы, пока реальные угрозы остаются без внимания.

Устранение закрывает этот пробел. Возможные варианты в приблизительном порядке предпочтения:

• Установить исправление / обновить уязвимое программное обеспечение.
• Снизить риск / настроить систему (отключить функцию, ограничить доступ, добавить правило WAF).
• Принять риск с официальным согласованием, если устранение невозможно.

Устранение требует участия разных подразделений: служба безопасности выявляет проблему, но исправление обычно вносят IT, разработка и эксплуатация.

Заявка, помеченная как выполненная, не является доказательством. Проверка повторно сканирует систему или выполняет повторную проверку, чтобы подтвердить фактическое устранение уязвимости и отсутствие новых проблем.

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

Ежегодное или ежеквартальное сканирование оставляет длительные периоды невидимости. Современное управление уязвимостями (VM) должно быть непрерывным: новые активы, новый код и новые CVE появляются ежедневно.

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

VM работает только при четко распределенной ответственности:

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

Для каждого результата должен быть назначен ответственный и установлен срок, иначе работа остановится.

Оценивайте работу программы, а не только количество результатов:

• Среднее время устранения (MTTR) в зависимости от степени серьезности.
• Доля соблюдения SLA.
• Динамика открытых и закрытых результатов с течением времени.
• Охват (процент просканированных активов).
• Доля повторных открытий / повторного возникновения.

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

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

• Причина отсрочки исправления.
• Применяемые компенсирующие меры.
• Владелец риска, который его принимает.
• Дата окончания действия, требующая повторного рассмотрения.

Срок действия исключений должен быть ограничен; бессрочное исключение — это всего лишь игнорируемый риск.

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

Учитывайте эти выводы при обнаружении (улучшайте охват), расстановке приоритетов (настраивайте пороговые значения) и устранении (автоматизация, эталонные образы). Зрелость VM определяется тем, насколько быстро и надежно проходит этот цикл.

Жизненный цикл VM представляет собой непрерывный цикл: обнаружить активы и слабые места, оценить и проверить их, расставить приоритеты по реальному риску, устранить проблему путем установки исправления, снижения риска или принятия риска и убедиться, что исправление сохранилось. Четкая ответственность, SLA, метрики и исключения с ограниченным сроком действия помогают сохранять объективность.

Далее мы подробно разберем основу обнаружения: сканирование и создание точного реестра активов.