Закрыли все CVE, но оставили admin:admin: зачем специалисту по управлению уязвимостями комплаенс
Комплаенс в информационной безопасности - это не набор формальных документов и не подготовка к очередной проверке. Под этим термином понимают систему, которая помогает организации соблюдать требования законодательства, регуляторов, внутренних политик и отраслевых стандартов. Для VM-специалиста, отвечающего за управление уязвимостями, комплаенс задаёт понятные правила: что проверять, в какие сроки устранять проблемы, кто принимает остаточный риск и как подтвердить результат.
В России современный комплаенс начал формироваться в 1999 году. Тогда Центробанк выпустил указание № 603-У - один из первых отечественных документов, где появился термин "комплаенс-контроль". Сегодня в сфере информационной безопасности он связан с требованиями 187-ФЗ, 152-ФЗ, приказами ФСТЭК, нормативными документами Банка России и другими регуляторными актами.
Для бизнеса последствия несоответствия давно перестали быть исключительно репутационными. Организация может столкнуться со штрафами на миллионы рублей, ограничениями деятельности, предписаниями регулятора и персональной ответственностью руководителей.
Почему требования к комплаенсу ужесточаются
С 1 марта 2026 года приказ ФСТЭК № 117 устанавливает для государственных информационных систем конкретные сроки устранения уязвимостей: критические проблемы необходимо закрывать в течение 24 часов, а уязвимости высокой степени опасности - за семь дней. Это уже не общая рекомендация, а проверяемое обязательство.
С мая 2025 года увеличились штрафы за утечки персональных данных. За первое нарушение организации могут назначить от 3 до 15 млн рублей в зависимости от масштаба инцидента, а за утечку биометрической информации - до 20 млн. Повторное нарушение может обернуться штрафом в размере 1-3% годовой выручки. Дополнительно появилась уголовная ответственность по статье 272.1 УК РФ.
Финансовые организации обязаны учитывать положения 382-П, 683-П, 684-П, методические рекомендации 2-МР и требования ГОСТ Р 57580.1. Эти документы предусматривают анализ защищённости и регулярное проведение пентестов. Положение 821-П, в свою очередь, требует оценивать программное обеспечение для переводов денежных средств на уровне доверия ОУД4 и выше.
Указ Президента № 250 от 1 мая 2022 года закрепил персональную ответственность заместителя руководителя за информационную безопасность в государственных организациях и субъектах КИИ. С 1 января 2025 года также действует прямой запрет на использование средств защиты, происходящих из недружественных государств.
В таких условиях комплаенс превращается из "бумажной" функции в рабочий механизм управления рисками. Недостаточно заявить, что все CVE закрыты. Нужно доказать, что инфраструктура действительно соответствует требованиям, а очевидные слабости - например, стандартная пара `admin:admin`, включённая отладка или открытая панель управления, - устранены.
Кто отвечает за соответствие
В процессе обычно участвуют три группы специалистов:
- ИТ-команда отвечает за эксплуатацию систем и технические изменения;
- CISO формирует общую стратегию защиты и принимает решения по рискам;
- специалист по ИБ или комплаенсу переводит внешние требования в конкретные контролы и проверяет их выполнение.
VM-специалист находится на пересечении этих ролей. Он обнаруживает уязвимости, оценивает их критичность, назначает владельцев, отслеживает сроки исправления и подтверждает результат повторной проверкой. Но без комплаенса его работа может остаться набором разрозненных тикетов: сканер показывает множество CVE, инженеры закрывают самые заметные из них, а реальные причины риска сохраняются.
Три подхода к построению комплаенса
Полное отсутствие формальной системы
В этом случае организация полагается на сложившиеся привычки. Где-то установлена минимальная длина пароля, где-то запрещены root-учётные записи, но единого стандарта нет. Политики отличаются от системы к системе, контроль выполняется нерегулярно, а ответственность распределена неясно.
Такой подход может какое-то время работать в небольшой инфраструктуре, но по мере роста числа серверов и сервисов становится источником постоянных инцидентов. При проверке невозможно быстро доказать, какие требования выполняются и на каком основании.
Ориентация на требования регулятора
Наиболее распространённая модель - построение контроля вокруг документов ФСТЭК, Банка России и других профильных органов. CISO определяет применимые нормы, специалист по комплаенсу преобразует их в технические требования, а ИТ-команды внедряют необходимые настройки.
Далее проводится инвентаризация систем, выявляются отклонения, назначаются ответственные и устанавливаются сроки устранения. После изменений выполняется повторная проверка, а результаты фиксируются в отчётности.
Международные стандарты и бенчмарки
В качестве основы можно применять CIS Benchmarks и другие наборы рекомендаций. Они помогают проверить параметры операционных систем, баз данных, сетевого оборудования и прикладного ПО.
Однако у такого подхода есть ограничение - масштаб. Для одной Windows и офисного пакета могут набраться сотни контролей. Если в организации работает тысяча узлов, количество отдельных проверок исчисляется сотнями тысяч. Часть требований может конфликтовать с бизнес-функциями или между собой, поэтому добиться полного соответствия практически невозможно. На практике разумнее воспринимать международные стандарты как каталог улучшений, а не как безусловный норматив.
Почему нужен собственный стандарт
Оптимальный вариант - разработать внутренний стандарт конфигурации и защиты, учитывающий специфику организации. Его основу должны составлять:
- модель угроз;
- типы обрабатываемых данных;
- критичность сервисов;
- требования регуляторов;
- архитектура инфраструктуры;
- допустимый уровень простоя;
- возможности ИТ-команды.
Для интернет-магазина, промышленного предприятия и банка одинаковый набор контролей будет неравноценным. Одной организации важнее быстро закрывать уязвимости внешних веб-сервисов, другой - контролировать технологические сегменты, третьей - обеспечивать неизменность журналов и защиту платёжных систем.
Собственный стандарт должен отвечать на практические вопросы: запрещены ли стандартные учётные записи, какова минимальная длина пароля, требуется ли многофакторная аутентификация, какие службы разрешено публиковать наружу, как часто выполняется сканирование и кто утверждает исключения.
Как связать комплаенс и управление уязвимостями
Сначала необходимо составить полный перечень активов. В него должны попасть серверы, рабочие станции, сетевое оборудование, виртуальные машины, контейнеры, облачные ресурсы, базы данных и приложения. Без актуального реестра невозможно понять, что именно проверяется и какие системы выпали из контроля.
Затем активы следует классифицировать по критичности. Уязвимость на тестовом сервере и та же проблема в системе, обрабатывающей персональные или платёжные данные, не должны автоматически получать одинаковый приоритет.
Следующий шаг - связать технические находки с требованиями. Например, отсутствие обновления может быть одновременно CVE, нарушением внутреннего стандарта и несоответствием нормативному контролю. Такая связь позволяет объяснить руководству не только техническую опасность, но и потенциальные последствия.
Важно контролировать не только наличие патча. Повторная проверка должна подтверждать, что исправление действительно применилось, уязвимый компонент больше не используется, а временное исключение не осталось постоянным.
Исключения и остаточный риск
В реальной инфраструктуре невозможно устранить все проблемы мгновенно. Обновление может нарушить работу критичного приложения, а отключение устаревшего протокола - остановить производственный процесс. Поэтому комплаенс должен предусматривать процедуру исключений.
Для каждой отложенной уязвимости фиксируются причина, владелец риска, компенсирующие меры, срок пересмотра и дата окончательного решения. Исключение без срока действия превращается в скрытую уязвимость.
Компенсирующими мерами могут быть сегментация сети, ограничение доступа, виртуальный патчинг, усиленный мониторинг, отключение внешнего интерфейса или переход на выделенный административный контур. Такие меры не отменяют исправление, но снижают вероятность эксплуатации до момента полноценного устранения.
От ручных исправлений к эталонным образам
Постоянное "латание дыр" на уже работающих серверах плохо масштабируется. Гораздо эффективнее создавать эталонные образы операционных систем и приложений, в которых заранее заданы безопасные параметры.
В образе можно отключить ненужные службы, удалить стандартные учётные записи, задать политики паролей, включить журналирование, установить актуальные обновления и настроить защитные агенты. Новый сервер, развёрнутый из такого шаблона, сразу получает базовый уровень соответствия.
Контроль при этом должен быть непрерывным. Даже безопасный образ со временем устаревает, а настройки могут измениться после ручных действий администратора. Поэтому конфигурации следует регулярно сравнивать с утверждённым эталоном, а отклонения автоматически передавать на обработку.
Какие метрики действительно полезны
Количество закрытых CVE само по себе мало что говорит. Более информативны следующие показатели:
- доля активов, охваченных сканированием;
- процент критичных уязвимостей, устранённых в установленный срок;
- среднее время от обнаружения до исправления;
- количество просроченных исключений;
- доля систем, соответствующих эталонной конфигурации;
- число активов с неизвестным владельцем;
- повторяемость одних и тех же нарушений;
- количество критичных сервисов со стандартными учётными данными.
Такие метрики показывают зрелость процесса. Организация может быстро закрывать тысячи уязвимостей, но при этом оставлять доступ к административной панели с паролем по умолчанию. С точки зрения риска это будет очевидное несоответствие, даже если отчёт о CVE выглядит впечатляюще.
Практический результат для VM-специалиста
Комплаенс помогает расставлять приоритеты и защищает команду от бесконечной гонки за формальными показателями. Он отвечает на главный вопрос: какие проблемы необходимо устранять в первую очередь и почему.
Зрелая система строится по цепочке: требования превращаются в контролы, контролы - в технические проверки, результаты проверок - в задачи, а выполненные задачи подтверждаются повторным контролем. В этом случае управление уязвимостями становится частью единого процесса управления рисками.
Главный вывод прост: закрытые CVE не гарантируют защищённость. Настоящее соответствие означает, что организация контролирует конфигурации, учётные записи, доступы, обновления, исключения и состояние всей инфраструктуры. Если после устранения уязвимостей в системе остаётся `admin:admin`, значит, процесс смотрит только на известные дефекты и не видит реальный риск. Именно комплаенс помогает закрыть этот разрыв.