От формальности к осознанности: 5 уровней зрелости культуры безопасности

«Чаще всего о культуре безопасности говорят либо в духе ‘нужно тренировать сотрудников’, либо в терминах стандартов. Но сама модель NIST не про то, чтобы просто достичь пятого уровня и выставить галочку. Она работает как зеркало — показывает, что твоя безопасность становится делом всех только тогда, когда ты даже не замечаешь, как она встроена в каждое решение».

Что скрывается за «культурой безопасности» в российском ИТ

В российском ИТ-контексте под «культурой безопасности» часто понимают два почти противоположных сценария. Первый — формальное выполнение требований 152-ФЗ и приказов ФСТЭК: обучение раз в год, подписи под инструкциями, акты проверок. Всё это есть, но работает по инерции. Второй сценарий встречается в более зрелых компаниях, особенно на стыке с разработкой и операционной деятельностью: безопасность становится частью процесса, а не его контролёром. Например, при обсуждении новой функции архитектор сразу предлагает варианты аутентификации, а разработчик проверяет библиотеки на уязвимости перед коммитом. Это уже не просто формальность, а естественный шаг в работе.

Проблема в том, что без структурированного подхода переход от первого сценария ко второму происходит хаотично и зависит от личной вовлечённости отдельных сотрудников или руководителей. Здесь и нужна модель зрелости — не как абстрактная теория, а как дорожная карта, которая помогает оценить текущее состояние и понять, какие конкретные действия приведут к системным изменениям.

Модель NIST SP 800-16: почему пять уровней, а не три

NIST Special Publication 800-16 «A Role-Based Model for Federal Information Technology/Cybersecurity Training» предлагает многоуровневую модель развития культуры безопасности. В отличие от упрощённых трёхуровневых схем («начальный — средний — продвинутый»), пять уровней позволяют точнее диагностировать стагнацию. Часто организация застревает между вторым и третьим уровнем, и трёхуровневая модель этого не показывает. Пять уровней выявляют эти плато.

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

Уровень 1: Начальный (Ad-hoc)

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

Обучение по 152-ФЗ проводится формально, «для галочки». Сотрудники проходят тесты, но не могут применить знания на практике.
Ответственность за безопасность возложена на одного человека или небольшой отдел, который воспринимается остальными как «мешающие бизнесу».
Политики безопасности существуют, но никто, включая руководство, их не читал. Изменения в инфраструктуре (новый сервис, облако) происходят без оценки рисков.

Ключевой индикатор этого уровня — безопасность всегда проигрывает в приоритетах. Если нужно срочно запустить фичу, вопросы защиты откладываются «на потом».

Уровень 2: Определённый (Defined)

Организация осознаёт необходимость системного подхода. Появляются документированные процессы и роли. Безопасность перестаёт быть исключительно реактивной. Характерные черты:

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

Главная ловушка этого уровня — ритуализация процессов. Всё делается по инструкции, но без понимания сути. Например, проводятся ежеквартальные пересмотры прав доступа, но списки выгружаются автоматически и согласуются без анализа. Культура безопасности существует на бумаге, но не в головах.

Уровень 3: Управляемый (Managed)

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

Внедрение автоматизированных средств контроля: сканеры уязвимостей в CI/CD, системы управления привилегированным доступом (PAM).
Появление качественных метрик: не просто «сотрудники прошли обучение», а «снижение числа успешных фишинговых атак на X% после тренинга».
Ответственность за безопасность начинает распределяться. Руководители подразделений отчитываются не только за бизнес-показатели, но и за инциденты в своей зоне.

На этом уровне часто возникает конфликт: метрики есть, но они могут подменять цель. Фокус смещается на «улучшение показателей», а не на реальное снижение рисков. Например, гонка за снижением количества критических уязвимостей до нуля приводит к тому, что их просто переклассифицируют в средние.

Уровень 4: Количественно управляемый (Quantitatively Managed)

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

Внедрены продвинутые системы мониторинга и анализа поведения (UEBA), которые выявляют аномалии, а не только известные угрозы.
Практики безопасной разработки (DevSecOps) интегрированы в жизненный цикл продукта. Безопасность становится частью требований на этапе проектирования.
Проводятся регулярные моделирования угроз и оценки зрелости не по чек-листам, а по адаптированным под бизнес-риски моделям.

Сложность перехода на этот уровень в России часто связана с доступностью инструментов и экспертизы. Многие решения, популярные на Западе, могут быть недоступны или требовать серьёзной адаптации. Поэтому зрелость часто достигается не внедрением «коробочного» продукта, а развитием собственных компетенций и скриптов.

Уровень 5: Оптимизируемый (Optimizing)

Высший уровень зрелости, где безопасность — не отдельная функция, а неотъемлемая часть корпоративной ДНК и каждого решения. Она не просто управляется, а постоянно совершенствуется на основе обратной связи и изменяющегося контекста. Признаки:

Сотрудники на всех уровнях, включая не-технические отделы, чувствуют личную ответственность за безопасность и предлагают улучшения.
Организация не просто соответствует стандартам, а сама влияет на их развитие, участвует в отраслевых рабочих группах, делится наработками (например, в рамках ГИС или отраслевых стандартов).
Существует культура непрерывного обучения и экспериментов. Провалы в тестовых упражнениях (например, на Red Team) рассматриваются не как негатив, а как возможность улучшить процессы.

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

Как применить модель на практике: шаги для российских компаний

Оценка по модели NIST не должна быть самоцелью. Её ценность — в определении точек роста. Вот практические шаги для начала работы:

Честная самооценка. Соберите фокус-группу из представителей разных отделов (разработка, эксплуатация, юристы, линейные руководители). Опросите их анонимно по ключевым индикаторам каждого уровня. Где чаще всего возникают трения с безопасностью?
Определите целевой уровень. Не нужно стремиться сразу на пятый. Для большинства организаций, работающих с персональными данными, устойчивый третий уровень уже будет значительным достижением. Цель должна быть реалистичной и привязанной к бизнес-задачам.
Создайте план развития. Разбейте путь от текущего состояния к целевому уровню на конкретные инициативы. Например, для перехода с первого на второй уровень: разработать и внедрить базовые политики, провести серию интерактивных тренингов (не лекций), назначить ответственных за безопасность в каждом департаменте.
Внедряйте изменения итеративно. Начните с одного пилотного отдела или проекта. Измеряйте не только формальные показатели (процент обученных), но и качественные изменения: уменьшение количества отклонений от процессов, скорость реакции на инциденты.
Пересматривайте оценку. Проводите повторную оценку зрелости раз в полгода или год. Это позволит увидеть прогресс и скорректировать план, если какие-то инициативы не работают.

Для российских реалий критически важно учитывать требования регуляторов. План развития культуры безопасности должен быть синхронизирован с дорожной картой по выполнению требований 152-ФЗ и приказов ФСТЭК. Это не только снижает риски штрафов, но и даёт формальный повод для выделения ресурсов.

Чего не хватает в модели NIST: российский контекст

Модель NIST, будучи качественным ориентиром, не учитывает некоторые специфические аспекты российского ИТ-рынка:

Влияние импортозамещения. Переход на отечественное ПО и оборудование часто приводит к временному снижению уровня зрелости, так как инструменты и процессы приходится выстраивать заново. Это нужно учитывать в оценках и планах.
Особенности регуляторики. Требования ФСТЭК часто носят жёсткий предписывающий характер. Это может способствовать формальному достижению второго уровня («определённый»), но тормозить переход к третьему, где требуется гибкость и управление рисками, а не простое следование инструкциям.
Кадровый вопрос. Дефицит специалистов по безопасности в регионах вынуждает компании полагаться на узкий круг экспертов, что противоречит идее распределённой ответственности на высоких уровнях зрелости.

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

От зрелости процессов к реальной устойчивости

Конечная цель развития культуры безопасности — не высокий балл по модели NIST, а повышение устойчивости организации к киберугрозам. Эта устойчивость проявляется в способности не только предотвращать атаки, но и быстро восстанавливаться после них, и главное — извлекать из инцидентов уроки для постоянного улучшения.

Развитая культура безопасности меняет мышление. Сотрудник перестаёт думать: «Это проблема отдела ИБ». Вместо этого он задаёт себе вопросы: «Какие данные я обрабатываю и как их защитить?», «Не выглядит ли это письмо подозрительным?», «Можно ли сделать эту функцию более безопасной для пользователя?». Когда такие вопросы становятся естественной частью рабочего процесса, формальные уровни зрелости отходят на второй план. Организация получает не просто защищённую инфраструктуру, а адаптивный организм, способный уверенно работать в условиях постоянно меняющихся угроз.