Стратегия ИБ при росте компании: что менять и когда
Статья «Стратегия ИБ: план на год и бюджет» описывает, как составить план для текущего размера компании. Этот план устаревает не через год по календарю, а при достижении определённых порогов роста — числа сотрудников, систем, объёма данных. Здесь — на какие пороги смотреть и что пересматривать в первую очередь.
Статья опирается на логику направления «Стратегия кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами.
Что должно получиться
| Уровень | Что это значит на практике |
|---|---|
| 2. Гигиенический | Стратегия ИБ пересматривается не только по календарю, но и при достижении порогов роста, которые делают прежние решения неработающими |
Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.
Почему одного календарного пересмотра не хватает
Годовой цикл пересмотра стратегии предполагает плавное изменение условий. Рост компании часто происходит скачками: за квартал удваивается штат, появляется новая линейка продуктов с собственной инфраструктурой, открывается филиал. Решение, рассчитанное на 20 человек (один совмещающий роли ответственный, ручная выдача доступа, аутсорс всего технического), на 150 человеках не ломается сразу — оно деградирует незаметно: доступ выдаётся с задержкой, инциденты замечаются позже, находки накапливаются без разбора. К моменту следующего планового пересмотра накопленный долг уже велик.
Пороги и что на них пересматривать
| Порог | Что перестаёт работать | Что заводить |
|---|---|---|
| Один человек совмещает ИБ с основной должностью (ИТ, разработка) на полную ставку | Решения по ИБ откладываются в пользу основных задач; нет времени на системную работу, только реакция на происшествия | Выделенное время или отдельная штатная единица, даже на неполную занятость — см. назначение ответственного |
| Доступ к системам выдаётся вручную по запросу в чате | Отсутствие единого списка, кто и к чему имеет доступ; отзыв доступа при увольнении зависит от памяти администратора | Формальный процесс выдачи и отзыва доступа с единым реестром, при достаточном масштабе — централизованное управление учётными записями |
| Количество серверов и сервисов превышает то, что один человек помнит наизусть | Инвентаризация «в голове» перестаёт быть надёжной; забытый сервер не получает обновлений и не проверяется | Автоматическая инвентаризация сети и учёт ПО вместо памяти |
| Появляется отдельный продукт или подразделение с собственной инфраструктурой | Единая модель угроз и архитектура перестают покрывать новую часть компании | Отдельный пересмотр модели угроз для новой части, не распространение старой «по умолчанию» |
| Компания начинает обрабатывать данные нового типа (платежи, биометрия, данные другой страны) | Прежняя оценка рисков и регуляторных требований не покрывает новый тип данных | Отдельная оценка рисков и регуляторных требований для нового типа данных, прежде чем он появится в системах, а не после |
| Число подрядчиков с доступом к данным растёт быстрее, чем успевают оцениваться | Договоры подписываются без оценки риска, потому что «нет времени» | Формальный процесс оценки рисков поставщиков, встроенный в закупку, а не отдельный шаг, который пропускают под давлением сроков |
Как не подготовиться слишком рано
Обратная ошибка — завести процессы и роли под компанию, которой ещё нет. Отдельная команда мониторинга на пять человек в штате, когда вся компания — пятнадцать человек, тратит бюджет, который нужнее на базовые меры защиты. Признак, что решение заводится вовремя, а не заранее: порог из таблицы выше уже пройден и проблема уже проявляется на практике (задержки, упущенные доступы, забытые серверы), а не предполагается теоретически «на будущее».
Как отслеживать пороги, а не пропустить момент
- Включите пороги роста в ежегодный пересмотр стратегии как отдельный пункт повестки, а не полагайтесь на то, что кто-то заметит проблему сам.
- Свяжите пересмотр с конкретными событиями компании (открытие нового направления, превышение штата определённого размера), а не только с календарной датой.
- Используйте метрики из отчётности для руководства как ранний сигнал: растущее время выдачи доступа или растущее число забытых серверов — признак, что порог уже пройден.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Инциденты и находки накапливаются без разбора | Один человек не успевает совмещать ИБ с основной работой. Выделите отдельное время или роль |
| При увольнении сотрудника доступ отзывается с задержкой | Нет единого реестра доступа, отзыв зависит от памяти администратора. Заведите формальный процесс |
| Стратегия пересмотрена в срок, но уже не соответствует реальности | Пересмотр был только календарным, без учёта порогов роста. Добавьте пороги явным пунктом в процесс пересмотра |
| Завели отдельную команду или процесс, которым никто не пользуется | Решение опередило реальную потребность. Дождитесь, пока порог будет пройден на практике, а не предполагается теоретически |
Где это в модели зрелости
Материал относится к направлению «Стратегия кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует, чтобы стратегия соответствовала реальному масштабу компании, а не оставалась неизменной годами: пороги роста — конкретный, проверяемый повод для пересмотра между плановыми циклами.
Как проверить
- Пороги роста (число сотрудников, систем, новые типы данных) включены в процесс пересмотра стратегии как отдельный пункт.
- Хотя бы один порог из таблицы выше сверен с текущим состоянием компании в последние полгода.
- Решения, введённые на опережение, обоснованы пройденным порогом, а не предположением о будущем.
- Метрики из отчётности для руководства используются как ранний сигнал пройденного порога, а не только для отчёта постфактум.
Источники
- Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
