Понедельник, 9:15. Финтех на 400 сотрудников заказал gap-анализ по CIS Controls v8 - «подтвердить уровень для аудитора и показать совету директоров». Через две недели результат: из 56 safeguards базовой гигиены (IG1) закрыто 11. Инвентарь активов - выгрузка из AD трёхмесячной давности, без сетевого оборудования и IoT. Политика ИБ - PDF 2019 года в SharePoint, который не открывали 14 месяцев. Патч-менеджмент - «когда IT-отдел вспомнит». В прошлогоднем аудиторском отчёте подрядчик обозначил «уровень зрелости - средний». На деле - начальный, причём нижняя граница.
По опыту проведения подобных оценок в компаниях от 200 до 2000 человек - семь из десяти переоценивают собственную зрелость минимум на два уровня. Это не злой умысел, это self-assessment bias в чистом виде.
Ниже - пошаговый roadmap повышения зрелости ИБ: от честной диагностики до конкретных действий на каждом этапе перехода, с шаблонами и чеклистами.
Модель зрелости кибербезопасности: какой фреймворк взять за основу
На рынке десятки фреймворков, но для построения рабочего плана развития информационной безопасности в российских реалиях хватит трёх. Остальное - нюансы.NIST CSF v2.0 - шесть функций (Govern, Identify, Protect, Detect, Respond, Recover) и четыре уровня реализации (Tiers). Tier 1 (Partial) - реактивный подход без формализации, «чиним когда сломалось». Tier 4 (Adaptive) - процессы адаптируются к изменению угроз в реальном времени. Плюс: универсальность и совместимость с ISO 27001. Минус: не даёт конкретных контролей - только категории и ожидаемые результаты. Стратегия без тактики.
CIS Controls v8 - 18 контролей с разбивкой на три группы реализации (Implementation Groups). IG1 - 56 safeguards базовой кибергигиены для любой организации. IG2 добавляет 74 safeguard для компаний с усложнённой инфраструктурой. IG3 - ещё 23 safeguard для зрелых организаций с доступом к критическим данным. Плюс: prescriptive-подход с конкретными действиями. Для Blue Team - оптимальная операционная основа. Берёшь safeguard, делаешь, ставишь галочку.
CMMC 2.0 - три уровня зрелости, обязательные для подрядчиков Министерства обороны США. Level 1 (Foundational) - 17 практик из FAR 52.204-21, допускает самооценку. Level 2 (Advanced) - 110 практик, выровненных с NIST SP 800-171, требует внешнего аудита каждые три года. Level 3 (Expert) - расширение на подмножество NIST SP 800-172 с государственной оценкой, согласно документации DoD CIO.
| Критерий | NIST CSF v2.0 | CIS Controls v8 | CMMC 2.0 |
|---|---|---|---|
| Уровни зрелости | 4 Tiers | 3 IG | 3 Levels |
| Конкретность контролей | Категории и подкатегории | Конкретные safeguards | Конкретные практики |
| Обязательность | Добровольный | Добровольный | Обязательный для DIB |
| Применимость в РФ | Да, как стратегия | Да, как операционный план | Как ориентир |
| Когда брать за основу | Стратегический уровень | Тактический уровень | Работа с DoD-контрагентами |
Для повышения уровня ИБ в организации на российском рынке оптимальная связка: NIST CSF v2.0 для стратегического позиционирования перед руководством (функции Govern и Identify хорошо ложатся на язык бизнеса) плюс CIS Controls для операционного плана с конкретными задачами на каждую неделю. CMMC полезен как бенчмарк, если компания работает с международными контрагентами.
Можно неделю выбирать между фреймворками. А можно за это время провести инвентаризацию активов. Угадайте, что приближает к ML2 быстрее.
Оценка зрелости информационной безопасности: чеклист на 15 пунктов
Прежде чем строить roadmap, нужно честно зафиксировать текущее состояние. Вот чеклист зрелости ИБ из 15 пунктов, привязанных к конкретным контролям CIS и NIST. Ответ «да» засчитывается только при наличии документального подтверждения - «мы это делаем устно» не считается.Блок 1: Инвентаризация и контроль (CIS-1, CIS-2)
- Есть актуальный (обновлённый за последние 30 дней) реестр всех сетевых устройств и серверов (CIS 1.1 - Establish and maintain detailed enterprise asset inventory)
- Есть актуальный реестр установленного ПО с указанием версий и статуса поддержки (CIS 2.1 - Establish and maintain software inventory)
- Процедура обработки неавторизованных активов в сети документирована и выполняется (CIS 1.2, 2.3)
- Все учётные записи инвентаризированы, включая сервисные (CIS 5.1 - Establish and maintain inventory of accounts)
- Администраторские привилегии выделены на отдельные учётные записи (CIS 5.4 - Restrict administrator privileges to dedicated admin accounts)
- Неактивные учётные записи (>45 дней без входа) автоматически блокируются (CIS 5.3 - Disable dormant accounts)
- Существует и применяется baseline secure configuration для серверов и рабочих станций (CIS 4.1)
- Межсетевые экраны управляются централизованно по единой политике (CIS 4.4, 4.5)
- Стандартные учётные записи на сетевом оборудовании изменены или отключены (CIS 4.7)
- Данные классифицированы, ACL настроены в соответствии с классификацией (CIS 3.1, 3.3)
- Шифрование на конечных устройствах включено - BitLocker, FileVault или аналог (CIS 3.6)
- Логи с ключевых систем собираются централизованно - SIEM или хотя бы syslog-агрегатор (NIST CSF DE.AE-01 - A baseline of network operations and expected data flows is established and managed)
- Существует документированный план реагирования на инциденты с назначенными ролями (NIST SP 800-53 IR-1)
- За последние 12 месяцев проводились tabletop-учения по incident response (NIST CSF RS.AN-01)
- Сотрудники проходят обучение по ИБ минимум раз в год с проверкой знаний (NIST SP 800-53 AT-1)
| «Да» | Уровень | Характеристика |
|---|---|---|
| 0-4 | ML1 (Initial) | Реактивный подход, процессы отсутствуют или выполняются ad hoc |
| 5-9 | ML2 (Managed) | Базовая гигиена частично внедрена, формализации нет |
| 10-13 | ML3 (Defined) | Процессы документированы и выполняются регулярно |
| 14-15 | ML4 (Quantitatively Managed) | Процессы измеряются и целенаправленно оптимизируются |
Если честно ответили - у большинства будет 3-6 пунктов. И это нормальная стартовая точка, а не повод для паники.
Переход между уровнями зрелости ИБ: пошаговый план
ML1 → ML2: базовая гигиена за 90 дней
Переход от хаоса к управляемости. Цель - закрыть ядро CIS IG1 и выстроить минимальный baseline для дальнейшего развития.Неделя 1-2: инвентаризация. Начните с того, что не стоит денег: сканирование сети (
nmap -sn 10.0.0.0/8) плюс выгрузка из AD плюс DHCP-логи (CIS 1.4 - Use DHCP logging to update enterprise asset inventory). Сведите результаты в единую таблицу: IP, hostname, ОС, владелец, дата обнаружения. Это закрывает CIS 1.1 и даёт основу для каждого следующего шага. Без инвентаря активов любое повышение уровня ИБ в организации - стрельба в темноту. Вы не можете защитить то, о чём не знаете.Неделя 3-4: управление учётными записями. Выгрузите все учётные записи из AD. Ищите три вещи: сервисные аккаунты с паролем, не менявшимся более 180 дней; учётные записи уволенных сотрудников (сверьте с HR-списком - будете удивлены); администраторские привилегии на повседневных учётках. Задокументируйте, заведите тикеты на исправление каждой находки. Это CIS 5.1-5.4 - фундамент управления доступом.
Неделя 5-8: secure configuration baseline. Возьмите CIS Benchmarks для вашей ОС и выделите Critical и High рекомендации. Не пытайтесь закрыть всё - начните с 20% контролей, дающих 80% снижения attack surface. Для Windows: отключение SMBv1, настройка Windows Firewall, конфигурация audit policy для логирования входов и изменений в привилегированных группах. Для Linux: отключение неиспользуемых сервисов, настройка
sshd_config (запрет root login, смена порта), включение auditd. Сначала на одном сегменте, потом масштабируете.Неделя 9-12: централизованный сбор логов. Даже без полноценного SIEM начните собирать логи в одну точку. Wazuh (бесплатный, open source) или связка rsyslog + Elasticsearch. Минимальный набор источников: контроллеры домена, VPN-шлюз, межсетевой экран, почтовый сервер. Это формирует baseline сетевой активности (NIST CSF DE.AE-01) и даёт возможность ретроспективного анализа при инциденте. Когда (не «если») что-то случится - будет куда смотреть.
Бюджет: от 0 до 300 000 руб. при наличии внутреннего специалиста. Основные затраты - рабочее время, а не лицензии. Один ИБ-специалист при 50% загрузки на эти задачи закрывает переход за 90 дней.
ML2 → ML3: формализация процессов и почему здесь всё ломается
Самый тяжёлый переход. Не потому что технически сложно - а потому что меняется природа работы. На ML2 вы тушите пожары. На ML3 - строите систему, которая предотвращает пожары. Разница как между ремонтом протечки и проектированием водопровода. И именно здесь большинство компаний застревает на годы.Что формализовать в первую очередь:
- Политики и процедуры - рабочие, не ради аудитора. Минимальный набор: политика управления доступом (NIST SP 800-53 AC-1), политика реагирования на инциденты (IR-1), политика управления конфигурациями (CM-1), политика непрерывности (CP-1), политика аудита и подотчётности (AU-1). Каждый документ содержит: scope, роли и ответственности, конкретные процедуры, метрики выполнения, периодичность пересмотра. Если политику нельзя превратить в чеклист для исполнителя - переписывайте.
- SIEM с правилами корреляции. На ML2 у вас есть логи. На ML3 - алерты с контекстом. Минимальный набор detection use cases для SOC:
- Brute force: >5 неудачных попыток входа за 10 минут с одного IP
- Lateral movement: аутентификация одной учётной записи на >3 хостах за 5 минут
- Privilege escalation: добавление пользователя в группу Domain Admins
- Data exfiltration baseline: исходящий трафик с хоста превышает 2 стандартных отклонения от среднего за 30 дней
- Vulnerability management с SLA. Регулярное сканирование (минимум ежемесячно), приоритизация по CVSS + контексту (расположение актива, наличие публичного эксплойта), фиксированные сроки устранения: Critical - 72 часа, High - 14 дней, Medium - 30 дней, Low - 90 дней. Метрика: процент уязвимостей, устранённых в SLA. Если через три месяца этот процент ниже 60% - проблема не в сканере, а в процессе взаимодействия с IT.
- Incident response с тестированием. Документированный IR-план с ролями (IR Lead, Communications Lead, Technical Lead), протестированный минимум раз в полгода через tabletop exercises. Без тестирования план - макулатура. На одном из tabletop мы обнаружили, что номер телефона IR Lead в плане принадлежал сотруднику, уволившемуся восемь месяцев назад.
Почему ломается: программа развития ИБ предприятия на этом этапе перестаёт быть задачей одного специалиста. Формализация процессов требует организационного мандата от руководства. Технический специалист не может утвердить политику, обязывающую IT-отдел патчить серверы за 72 часа - для этого нужен CISO с поддержкой CEO. Нет поддержки сверху - roadmap повышения зрелости ИБ застрянет на ML2 навсегда. Это не технический барьер. Это организационный.
ML3 → ML4: метрики, SOC maturity и непрерывная оптимизация
На ML3 процессы работают. На ML4 вы измеряете, насколько хорошо они работают, и целенаправленно улучшаете слабые звенья. Разница - как между «мы тушим пожары по инструкции» и «мы знаем, что среднее время обнаружения возгорания - 47 минут, и работаем над тем, чтобы снизить его до 20».Ключевые метрики зрелости процессов ИБ:
| Метрика | Что измеряет | Целевое значение ML4 |
|---|---|---|
| MTTD (Mean Time to Detect) | Скорость обнаружения инцидента | <24 часа |
| MTTR (Mean Time to Respond) | Время от обнаружения до containment | <4 часа для Critical |
| Patch compliance rate | Процент систем с актуальными патчами | >95% |
| Vulnerability SLA compliance | Процент уязвимостей, устранённых в срок | >90% |
| Phishing simulation click rate | Эффективность awareness-программы | <5% |
| SIEM/EDR coverage ratio | Процент активов под мониторингом | >95% |
Если вы не можете назвать свой текущий MTTD хотя бы с точностью до порядка - вы не на ML4.
Что добавляется на этом уровне:
- Threat hunting - проактивный поиск аномалий, не покрытых существующими правилами корреляции. Выделяется 20% рабочего времени аналитика SOC на формулирование и проверку hunt-гипотез на основе threat intelligence и TTPs из MITRE ATT&CK. Не «посмотреть дашборд», а целенаправленный поиск следов конкретных техник.
- Purple team - регулярная проверка эффективности контролей: offensive-специалист проверяет конкретные detection use cases, Blue Team в реальном времени оценивает качество алертов. Не формальный пентест раз в год - continuous validation. После каждого раунда - конкретный список: «правило X не сработало на технику Y, потому что Z».
- Автоматизация реагирования (SOAR) - для типовых инцидентов с высокой частотой: автоматический карантин хоста при срабатывании EDR, блокировка учётной записи при подтверждённом brute force, обогащение IOC из threat intelligence фидов. Автоматизировать стоит только то, что вы уже умеете делать руками. Иначе автоматизируете хаос.
Шаблон roadmap информационной безопасности: матрица за один день
Ниже - шаблон матрицы зрелости, который можно заполнить по результатам чеклиста из предыдущего раздела. Один рабочий день - реалистичный срок для первичного заполнения.| Домен (CIS Control) | Текущий | Целевой (12 мес.) | Gap (конкретно) | Ответственный | Приоритет | Бюджет |
|---|---|---|---|---|---|---|
| CIS-1: Инвентарь активов | ML1 | ML2 | Нет автоматизированного обнаружения | IT-директор, Петров А. | P1 | 0 руб. |
| CIS-2: Инвентарь ПО | ML1 | ML2 | Нет реестра ПО | IT-директор, Петров А. | P1 | 0 руб. |
| CIS-4: Secure Config | ML1 | ML2 | Нет baseline конфигурации | ИБ-специалист, Сидоров К. | P1 | 50 000 руб. |
| CIS-5: Account Mgmt | ML2 | ML3 | Нет автоблокировки dormant | ИБ-специалист, Сидоров К. | P2 | 0 руб. |
| CIS-3: Data Protection | ML1 | ML2 | Нет классификации данных | CISO, Иванова М. | P2 | 200 000 руб. |
| NIST IR-1: Incident Response | ML1 | ML2 | Нет IR-плана и ролей | CISO, Иванова М. | P1 | 100 000 руб. |
| NIST DE.AE-01: Detection | ML1 | ML2 | Нет централизованного сбора логов | ИБ-специалист, Сидоров К. | P1 | 300 000 руб. |
Как работать с матрицей:
- Заполните «Текущий» по результатам чеклиста из 15 пунктов.
- Целевой уровень на 12 месяцев - повышение на одну ступень для каждого домена. Не пытайтесь перепрыгивать.
- Gap описывайте конкретно: не «нужно улучшить мониторинг», а «нет централизованного сбора логов с контроллеров домена».
- Один ответственный на каждый gap - с фамилией и должностью. «IT-отдел» - не ответственный.
- Приоритизация: P1 - снижает риск критического инцидента; P2 - закрывает compliance-требования; P3 - оптимизация существующих процессов.
Типичные ошибки в стратегии развития кибербезопасности
5. Отсутствие baseline для detection. Без документированного baseline нормальной сетевой активности (NIST CSF DE.AE-01) невозможно отличить аномалию от нормы. Прежде чем писать правила корреляции в SIEM, зафиксируйте: какие сервисы куда ходят, какой объём трафика типичен для каждого сегмента, кто и в какое время логинится на критичные серверы. Baseline - не разовая задача. Он начинается в первые 90 дней перехода с ML1 на ML2 и уточняется на каждом следующем уровне.
За три года проведения оценок зрелости в организациях от ритейла до финтеха закономерность одна: компании, которые строят roadmap «снизу» - от конкретных контролей и задач с дедлайнами - достигают целевого уровня за 12-18 месяцев. Те, кто начинают «сверху» - с выбора идеального фреймворка, написания стратегии, месяцев согласования - застревают на этапе планирования и через год остаются на том же уровне.
Фреймворк - карта, а не территория. Можно неделю выбирать между NIST CSF и CIS Controls, а можно за это время провести инвентаризацию активов и заблокировать 30 учётных записей уволенных сотрудников. Первое приближает к ML3 на слайдах. Второе - в реальности.
Начните с чеклиста из этой статьи, честно оцените текущее состояние и закройте три пункта с наивысшим приоритетом за первый месяц. Через месяц - следующие три. Через квартал будет рабочая программа, а не стратегия в PowerPoint. Если в процессе обнаружите, что gap-анализ по CIS Controls превращается в бесконечную таблицу - на codeby.net коллеги обсуждают автоматизацию оценки зрелости и делятся рабочими шаблонами матриц под разные стеки.
