CompTIA SY0-701: Управление уязвимостями и управление исправлениями — Руководство по подготовке

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Часть CompTIA Security+ SY0-701 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов CompTIA, или пройдите тесты на время на ExamRoll.io.

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

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

Жизненный цикл начинается с обнаружения активов — невозможно защитить то, о существовании чего вы не знаете. Активное сканирование (Nessus, Qualys, Rapid7) опрашивает сеть на наличие работающих хостов и открытых сервисов. Пассивное обнаружение (анализ сетевого трафика, журналы DHCP, интеграция с CMDB) выявляет активы, которые пропускает активное сканирование. Облачные среды требуют обнаружения на основе API, поскольку традиционное сетевое сканирование не позволяет перечислить бессерверные функции, управляемые сервисы или эфемерные контейнеры.

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

Приоритизация использует CVSS в качестве базового показателя, но должна учитывать контекст. Уязвимость с оценкой CVSS 9.8 на изолированном от сети сервере разработки менее срочна, чем уязвимость с оценкой CVSS 7.5 на общедоступной точке аутентификации. Оценки EPSS, членство в каталоге KEV, критичность актива и компенсирующие меры контроля — все это влияет на итоговый приоритет. Цель не в том, чтобы исправить всё, а в том, чтобы в первую очередь исправить самое важное.

Варианты устранения включают установку исправлений (предпочтительно), изменение конфигурации (отключение уязвимой функции), виртуальный патчинг (правило WAF, блокирующее эксплуатацию), сетевую изоляцию или формальное принятие риска с документированным обоснованием. SLA на устранение должны быть определены и отслеживаться; исключения требуют утверждения и применения компенсирующей меры контроля.

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

Операции по управлению исправлениями

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

Windows Server Update Services (WSUS) и Microsoft Endpoint Configuration Manager (MECM/SCCM) — распространенные инструменты для управления исправлениями Windows в больших масштабах. В средах Linux используются менеджеры пакетов (apt, yum, dnf) в сочетании с инструментами автоматизации (Ansible, Puppet, Chef) для принудительного применения исправлений. В облачных (cloud-native) средах используются AWS Systems Manager Patch Manager, Azure Update Management или аналогичные сервисы.

Отчетность о соответствии требованиям по установке исправлений отслеживает процент активов, находящихся в рамках SLA для каждого уровня серьезности. Панель мониторинга, показывающая 94% соответствия для критических исправлений, может показаться приемлемой, пока вы не осознаете, что 6% от 10 000 конечных точек — это 600 систем без исправлений, каждая из которых является потенциальной точкой входа. Абсолютные числа так же важны, как и проценты.

Управление конфигурациями и эталонные конфигурации

Управление конфигурациями поддерживает системы в известном, безопасном состоянии. Эталонные конфигурации определяют утвержденное состояние для каждого типа системы; обнаружение отклонений выявляет расхождения с этой эталонной конфигурацией. Инструменты, такие как CIS-CAT Pro, OpenSCAP, и облачные сервисы (AWS Config, Azure Policy) непрерывно оценивают соответствие конфигурации и оповещают об отклонениях.

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

Практический сценарий: реагирование на Log4Shell в условиях дефицита времени

Когда 9 декабря 2021 года была раскрыта уязвимость CVE-2021-44228 (Log4Shell) с оценкой CVSS 10.0 и ее активная эксплуатация началась в течение нескольких часов после раскрытия, организации столкнулись с кризисом, который проверил на прочность все аспекты их программ управления уязвимостями. Технологическая компания со зрелой программой отреагировала следующим образом: в течение двух часов команда безопасности запросила свой реестр активов на предмет всех Java-приложений и выявила 847 потенциально затронутых систем. В течение шести часов они подтвердили, что 312 систем используют уязвимые версии Log4j, с помощью аутентифицированного сканирования. В течение 24 часов они развернули правила WAF, блокирующие строковый шаблон ${jndi:} в качестве временной компенсирующей меры контроля на всех системах, доступных из интернета. В течение 72 часов 89% критически важных систем были исправлены. Оставшиеся 11% были изолированы в ограниченных сетевых сегментах в ожидании одобрения от владельцев приложений на окна для установки исправлений. Успех программы зависел от трех предварительных условий, которых не было у многих организаций: полный и точный реестр активов; возможность аутентифицированного сканирования; и заранее утвержденные процедуры экстренных изменений, которые можно было запустить без недельного цикла утверждения.

← Безопасность конечных точек · Все домены

Отработать эти вопросы → · Тесты на время на ExamRoll.io →