Проверка CIS compliance Windows: измеряем до принуждения

Задача: проверить CIS и не остановить работу пользователей

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

Проблемы обычно начинаются, когда CIS пытаются "включить сразу и везде". Резкое ужесточение политик ломает привычные процессы: у сотрудников перестают запускаться программы, администраторы теряют доступ по RDP, службы не стартуют после перезагрузки, а поддержка получает лавину тикетов. Даже правильная по смыслу настройка может оказаться неподходящей именно вам, если есть устаревшие приложения, специальные учетные записи или нестандартные сценарии входа.

Чаще всего сбои возникают в нескольких зонах:

• пароли и блокировки (сложность, срок действия, попытки входа, блокировка учетной записи);
• UAC и права (повышение прав, установка драйверов и ПО, ограничения локального администратора);
• брандмауэр (закрытие нужных портов, блокировка внутренних сервисов, удаленное управление);
• шифрование (BitLocker, требования к TPM, восстановление ключей, совместимость с обслуживанием);
• RDP и удаленный доступ (NLA, запреты, ограничения протоколов и шифров).

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

Перед стартом: область проверки и базовая договоренность

Чтобы проверка соответствия CIS не превратилась в спор на встречах и внезапные поломки на рабочих местах, сначала договоритесь о границах и правилах. Это занимает час-два, но экономит недели разборов.

Начните с инвентаря: какие версии Windows вы реально проверяете (Windows 10, Windows 11, Windows Server), и какие роли у серверов (контроллер домена, файловый сервер, RDS, SQL и так далее). Рекомендации CIS зависят от роли, поэтому "один чеклист на все" почти всегда дает неверные выводы.

Дальше выберите профиль CIS. Level 1 обычно подходит как базовый безопасный минимум с умеренным влиянием на пользователей. Level 2 чаще требует жестких ограничений и лучше идет после пилота. Важно записать простое обоснование выбора, чтобы позже не менять курс из-за смены владельца процесса.

Отдельно зафиксируйте, что именно вы измеряете. В реальности часть настроек живет в GPO, часть в локальных политиках, часть в реестре, службах и параметрах безопасности. Если это не определить заранее, отчет получится "непроходимым": будет непонятно, где источник настройки и кто может ее менять.

Удобно оформить стартовую договоренность как короткий чеклист:

• Какие ОС и серверные роли входят в проверку, а какие исключены (с причиной).
• Какой профиль CIS выбран (Level 1 или Level 2) и почему.
• Какие источники настроек проверяем: GPO, локальные политики, реестр, службы.
• Какие критичные приложения, отделы и группы пользователей нельзя ломать (кассы, колл-центр, бухгалтерия, врачи, учебные классы).
• Как часто делаем замер и в какое "окно" (разово для базовой картины, затем еженедельно или ежемесячно для динамики).

Последний пункт, который стоит проговорить вслух: на этом этапе вы только измеряете и документируете отклонения. Никаких изменений, даже "маленьких правок", пока владельцы бизнеса и ИТ не подтвердят риск и план внедрения.

Стратегия "только измеряем": как организовать безопасный аудит

Идея простая: сначала фиксируете реальность, потом решаете, что менять. На этапе "только измеряем" любые действия должны быть в режиме чтения: сбор параметров, экспорт настроек, сравнение с эталоном. Никаких новых GPO, MDM-профилей, скриптов, которые правят реестр, и никаких "быстрых правок" по ходу проверки.

Полезно разложить измерение по слоям, чтобы не перепутать источники настроек и не сделать ложные выводы:

• локальная машина (локальные политики, локальные права, службы);
• домен (GPO и порядок применения);
• MDM/Intune (профили, конфигурации, compliance-политики);
• скрипты и агенты (логон-скрипты, EDR, hardening-агенты);
• ручные исключения (то, что админы меняли вне централизованных политик).

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

Дальше сделайте снимок базовой линии (baseline): дата, версия CIS Benchmarks для ваших редакций Windows, список проверенных хостов, источник данных (GPO, локально, MDM), кто запускал проверку и с какими правами. Это основа для повторной проверки и для споров в стиле "у нас всегда так было".

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

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

Инструменты: чем измерять CIS в Windows на практике

Чтобы оценить соответствие CIS, обычно нужен набор источников. Один инструмент редко видит все: часть настроек живет в локальных политиках, часть приходит из домена, а часть зависит от версий Windows и ролей серверов.

Что смотреть на самих Windows

На хостах важно измерять то, что реально применено, а не то, что "должно было примениться". Начните с локальных политик и параметров безопасности, состояния служб, прав пользователей (User Rights Assignment), настроек аудита и журналирования. Параллельно фиксируйте версию ОС, установленные роли и параметры UAC, RDP, SMB: многие рекомендации CIS завязаны на контекст.

Доменный слой: GPO, наследование и конфликты

Большая часть корпоративных отклонений объясняется GPO. Поэтому измеряйте не только итоговое значение на ПК, но и источник: какая политика его задает, есть ли наследование, блокировки, WMI-фильтры, security filtering, конфликтующие GPO с более высоким приоритетом. Иначе отчет получится "правильным", но не поможет убрать первопричину.

Практичный набор инструментов обычно такой:

• Microsoft Security Compliance Toolkit - удобная опора по шаблонам, базовым значениям и сравнению с эталоном.
• RSOP и gpresult - чтобы увидеть, что реально применилось и откуда пришло.
• Локальная проверка политик и параметров безопасности (включая audit policy и event logs) - чтобы поймать расхождения на конкретной машине.
• PowerShell-скрипты - быстро покрывают десятки хостов, но требуют валидации: разные редакции ОС, локализация, переопределения GPO, нюансы "Not Configured" vs "Disabled" часто дают ложные срабатывания.
• Коммерческие сканеры и SIEM - хорошо собирают факты (события, конфигурации, уязвимости), но не всегда корректно интерпретируют тонкости GPO и CIS, поэтому результаты лучше подтверждать точечными проверками.

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

Пошагово: как провести проверку и не вносить изменений

Правило режима "только измеряем" простое: собираете факты, но ничего не меняете. Даже "безобидные" правки в GPO или локальной политике могут неожиданно задеть вход в систему, сетевые диски или работу устаревших приложений.

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

Дальше двигайтесь по шагам:

1. Снимите "срез" среды: версии Windows, роли серверов, наличие важных приложений (бухгалтерия, медсистемы, банк-клиенты), владелец каждой группы.

2. Запустите проверку в режиме чтения: сбор параметров безопасности и конфигураций без внесения изменений.

3. Сведите результаты в единый формат, чтобы их можно было фильтровать и сравнивать между группами (таблица, CSV или JSON). В каждой строке должны быть: компьютер, параметр, текущее значение, ожидаемое значение, источник.

4. Проверьте источники настроек: что задано локально, что пришло через GPO, а что переопределено. Частая ловушка: политика "правильная" в одном GPO, но ниже по приоритету есть исключение, или настройка применена не к тем OU.

5. Отметьте "опасные для пользователей" пункты отдельным флагом. Это настройки, которые часто влияют на совместимость: правила паролей и блокировок, SMB и сетевой доступ, макросы и зоны в Office, ограничения PowerShell, политики обновлений, параметры брандмауэра.

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

Формат отчета: чтобы его читали и ИТ, и безопасность, и бизнес

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

Структура, которую реально читают

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

• Общая картина: доля соответствия по выбранному профилю (по ролям или группам устройств).
• Топ-5 критичных отклонений с кратким объяснением риска.
• Что затронуто: сколько устройств, какие подразделения или типы рабочих мест.
• Тренд: сравнение с прошлой проверкой (если это повторный замер).
• Решение, которое требуется: что берем в работу сейчас, что уходит на тест.

После резюме дайте "карту" отклонений: матрицу, где по строкам идут настройки, а по столбцам группы устройств (офисные ПК, ноутбуки, терминалы, серверы). Так быстро видно, что является единичным исключением, а что системной проблемой.

Карточка настройки: минимум, без которого нельзя

Детальную часть удобнее вести в виде повторяющихся карточек на каждую настройку. Тогда ИТ может воспроизвести измерение, а безопасность - защитить приоритет.

• Как сейчас: текущее значение и на каких устройствах встречается.
• Как должно быть: целевое значение по CIS (точная формулировка).
• Откуда взялось: локально, через GPO, через MDM или смешанно.
• Риск и влияние: безопасность, удобство пользователей, совместимость приложений.
• Рекомендация: оставить, исправить, отложить, нужно тестирование.

Чтобы избежать споров, добавьте короткий комментарий "почему так". Например, включение SMB signing важно для защиты, но на старых файловых сервисах или некоторых моделях сканеров может вызвать сбои. В отчете это фиксируется как "исправить после пилота" с понятным владельцем и сроком.

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

Как интерпретировать результаты: приоритизация без паники

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

Удобно сначала сгруппировать отклонения по темам. Так быстрее видно повторяющиеся проблемы и становится понятнее, где один шаг закрывает десятки пунктов: учетные записи и пароли, права и UAC, сеть и удаленный доступ, журналы и аудит, криптография и TLS, обновления и защита.

Быстрые победы и "осторожные" пункты

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

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

Кто решает и как выглядит бэклог

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

Чтобы результаты не превратились в спор, оформите бэклог изменений с простыми полями:

• что меняем (настройка и где применяется);
• ожидаемый эффект и риск для пользователей;
• зависимость (например, обновление приложения или миграция протокола);
• приоритет (P1-P3) и срок;
• владелец и критерий проверки после внедрения.

Пример: отчет показал слабые настройки журналирования на терминальных серверах и устаревший TLS на одном внутреннем веб-сервисе. Первое можно поставить в P1 и включить почти сразу. Второе - P2 с зависимостью: сначала подтвердить клиентов и запланировать тест, иначе есть шанс "погасить" доступ для части пользователей.

Частые ошибки: что чаще всего ломает работу пользователей

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

Ошибка 1: включать Level 2 без пилота и без исключений

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

Ошибка 2: смешивать профили рабочих станций и серверов

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

Отдельно проверьте зоны, которые чаще всего "ломают": параметры входа и блокировки учетных записей, ограничения на макросы и скрипты (включая PowerShell), требования к SMB/NTLM и подписи, брандмауэр и правила для корпоративных приложений, RDP и сетевые уровни аутентификации.

Ошибка 3: путать "не применимо" с "не соответствует"

Если настройка не применима к роли или версии Windows, ее нельзя считать провалом. Иначе отчет раздувается, а реальные риски тонут в шуме. Это особенно заметно в парке, где есть разные сборки и роли.

Ошибка 4: игнорировать конфликты GPO

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

Ошибка 5: включать аудит и журналирование без расчета

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

Минимальный предохранитель перед расширением логов:

• оценить объем событий на пилотной группе;
• задать лимиты журналов и политику перезаписи;
• проверить место на диске и скорость доставки логов.

Быстрые проверки перед переходом к изменениям

Перед тем как включать принуждение, сделайте короткий "предполетный" набор проверок. Он занимает часы, а экономит дни разборов после того, как у кого-то перестал работать VPN или пропала печать.

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

Затем убедитесь, что у вас есть baseline и вы понимаете, откуда берется каждая настройка: локальная политика, GPO, MDM или скрипт. Без этого легко "исправить" параметр в одном месте, а он через час вернется из другого.

Проверьте пять вещей до первого изменения:

• Утвержден профиль CIS для каждой группы (и версия бенчмарка записана).
• Собран baseline на типовых ПК и серверах, и отмечен источник каждой настройки (локально, GPO, MDM).
• В отчете есть топ-10 критичных отклонений, и у каждого пункта назначен владелец решения (ИБ, AD-команда, владелец приложения).
• Есть пилотная группа (10-30 пользователей или 1-2 подразделения) и понятный план отката для каждого изменения.
• Заданы метрики влияния: рост обращений в поддержку, сбои входа, ошибки приложений, проблемы печати, просадки производительности.

Отчет тоже стоит "приземлить" заранее: по каждому критичному отклонению нужен не только статус (pass/fail), но и решение - принять риск, компенсировать или исправлять, плюс срок и ответственный.

Пример: в пилоте бухгалтерии вы планируете усилить блокировку экрана и ограничения на макросы. До включения принуждения соберите неделю статистики: сколько было тикетов по входу, какие ошибки в 1С/Office, сколько раз пользователи блокировались из-за политики паролей. Если после изменения метрики резко растут, откатывайте конкретную настройку по заранее подготовленному плану, а не "откатывайте все подряд".

Пример сценария: как пройти путь от измерения к пилоту

Представим организацию на 300 рабочих станций и 40 серверов. Часть сотрудников работает удаленно, есть несколько критичных систем (например, бухгалтерия, медицина, терминальные фермы). Цель - пройти проверку соответствия CIS без резких изменений и остановок.

План на 4 недели

Неделя 1: только измеряем и собираем baseline. Вы выбираете версию CIS Benchmarks под свои версии ОС и фиксируете состав объектов: рабочие станции, серверы, доменные контроллеры, RDP-хосты. Запуск идет в режиме аудита: никаких GPO с принуждением, только сбор фактов. На выходе обычно получается не сотня мелочей, а 15-25 отклонений, которые реально влияют на риск. В нашем примере - 20 ключевых.

Чтобы результаты пригодились для пилота, сразу фиксируйте:

• дату и охват (сколько ПК/серверов проверено);
• топ отклонений по повторяемости;
• где настройка задается (локально или через GPO);
• какие подразделения/системы затронуты;
• предварительную оценку влияния на пользователей.

Неделя 2: пилот. Выбираете 20 ПК из разных ролей (офис, бухгалтерия, удаленка, инженерные) и 2 сервера не из самых критичных, но похожих по назначению. Службы безопасности и ИТ заранее согласуют исключения, например для бухгалтерии и медсистем, где старое ПО может не пережить ужесточение аутентификации или отключение макросов.

Недели 3-4: расширение. Охват увеличивается волнами, с коротким окном наблюдения после каждой. Вы смотрите не только на процент соответствия, но и на реальность: рост тикетов, сбои входа, проблемы печати, падение приложений. Хороший признак - снижение рисков без всплеска инцидентов.

Последними включайте настройки, которые заметно меняют поведение пользователей и приложений:

• правила блокировки макросов и скриптов;
• ограничения SMB/NTLM и ужесточение Kerberos-политик;
• AppLocker/WDAC и контроль запуска;
• изменения в UAC, запрет сохранения паролей и автозаполнения;
• параметры RDP (NLA, шифрование, запрет устаревших клиентов).

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

Следующие шаги: как мягко перейти от аудита к принуждению

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

Дорожная карта перехода

Зафиксируйте план, понятный ИТ, безопасности и владельцам процессов. Обычно хватает четырех этапов:

• Измерение: замеряем отклонения и собираем реальные инциденты от пользователей.
• Пилот: включаем политики на небольшой группе (например, 20-50 сотрудников из разных отделов).
• Поэтапное внедрение: раскатываем по подразделениям, начиная с самых устойчивых к изменениям.
• Контроль: сравниваем отчеты до и после, ловим откаты после обновлений Windows и правок GPO.

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

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

Чтобы внедрение не превратилось в ручную работу, заранее подготовьте шаблоны политик и процесс исключений. Иначе любая нестандартная роль (кассир, врач, оператор колл-центра) будет требовать отдельной правки.

Назначьте владельцев и договоритесь, как пользователи получат помощь в день изменений:

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

Практичный вариант отчета - показывать динамику, а не только "проценты соответствия". Например: за месяц закрыли 12 средних отклонений, но после обновления вернулись 3 настройки брандмауэра на части ноутбуков.

Если нужен внешний ресурс, чтобы пройти этот путь без перегруза команды, системный интегратор GSE.kz (gse.kz) может помочь с аудитом, пилотом и дальнейшим сопровождением, включая круглосуточную поддержку и подбор совместимой инфраструктуры под требования организации.