Создание работающей СМИБ за полгода: от диагноза до прототипа

«Построить СМИБ за полгода, это не проставить галочки в списке контролей. Это проявить железную дисциплину, чтобы отказаться от 90% «нужного»

и добить до результата оставшиеся 10%. Это про то, как из одного работающего винта собрать двигатель, который потянет за собой всю махину»

СМИБ, это не самописный Excel с оповещениями на почту и не «купили коробку NGFW, вот вам СМИБ». Разработать систему управления информационной безопасностью, которая реально работает и не создаёт лишь имитацию бурной деятельности, — задача для целеустремлённого, но ограниченного в ресурсах подразделения.

Цель: оперативная система, а не полный фарш

План на шесть месяцев ставит цель не построить СМИБ «по всем канонам», а создать её минимально жизнеспособную версию (Minimum Viable ISMS, MVISMS). Основные процессы должны работать, угрозы — обнаруживаться и нейтрализоваться, а требования регуляторов — хотя бы формально соблюдаться. Всё это без штата в двадцать человек или бюджета, сопоставимого с доходом компании.

Ключевое отличие от попыток внедрить всё сразу: мы не пытаемся охватить все 152-ФЗ, приказы ФСТЭК и ISO 27001 одновременно. Вместо этого выбираем один, самый критичный для компании вектор и развиваем его до состояния, когда от его работы есть измеримая польза. Чаще всего таким вектором становятся внешние угрозы и инциденты.

Первый месяц: диагноз и направление

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

• Инвентаризация того, что есть. Составляем список всех средств защиты информации, не оценивая их эффективность. Это могут быть базовые вещи: антивирусы, межсетевые экраны, настройки политик паролей в Active Directory, системы резервного копирования. Формализовать это удобно в простой таблице, разделив по типам систем.
• Выбор главного вектора. Здесь нужно выбрать одну из трёх возможных стартовых точек. Попытка начать с двух сразу обречена на провал из-за распыления ресурсов.
  1. Внешние угрозы и инциденты. Путь для компаний, которые уже сталкиваются с атаками, фишингом или утечками. Цель — создать систему обнаружения и реагирования, которая сработает раньше, чем ущерб станет необратимым.
  2. Внутренние процессы и доступ. Вектор для организаций, где основной риск — неконтролируемый внутренний доступ. Например, когда уволенные сотрудники месяцами сохраняют активные учётные записи, а критические данные лежат в общедоступных сетевых папках.
  3. Регуляторное давление. Путь вынужденный, но иногда единственно возможный. Если на компанию уже оказывают давление проверяющие органы или есть жёсткие контрактные обязательства по 152-ФЗ, вектор — формальное соответствие самым базовым и проверяемым пунктам.
• Формирование ядра команды. Минимально жизнеспособная СМИБ не требует целого департамента. Часто достаточно одного-двух специалистов, которые будут её двигать. Но их необходимо официально выделить на эту задачу, защитив время от поглощения оперативной поддержкой или срочными, но не важными запросами.

Второй и третий месяц: прототип ключевого процесса

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

Если вектор — внешние угрозы и инциденты

• Создание рабочего канала для сообщений. Это не обязательно сложная ITSM-система. Достаточно выделенного канала в корпоративном мессенджере (Mattermost, VK Teams, аналог Slack), куда любой сотрудник может написать о подозрительном письме или сбое. Ключевое правило: на каждое сообщение в этом канале должен быть быстрый ответ.
• Базовый мониторинг угроз. Покупка SIEM не требуется. Можно начать с централизованного сбора логов с наиболее критичных систем: внешних веб-серверов, шлюзов VPN, почтовых серверов. Использовать связку rsyslog/Vector + простые скрипты на Python или готовые легковесные анализаторы (например, Wazuh в минимальной конфигурации) для триггеров на массовые неудачные логины или подозрительную активность.

[КОД: пример простого правила для триггера на 10 неудачных попыток входа в VPN за минуту]

Если вектор — внутренние процессы и доступ

• Аудит самых опасных учётных записей. Определить учётные записи с правами администратора домена, локального администратора на серверах, учётные записи к базам данных и ERP-системам. Провести ревизию: кто реально использует, необходимы ли все эти права, нет ли среди них записей уволенных сотрудников.
• Реализация простого контроля. Внедрить элементарный регламент: любое создание новой учётной записи с высокими привилегиями требует письменного запроса от руководителя подразделения. Автоматизировать это можно через простой веб-интерфейс или даже через тикет в существующей системе учёта. Написать скрипт, который раз в неделю проверяет активность административных учётных записей и отправляет отчёт ответственным.

Если вектор — регуляторное давление

• Определение минимального обязательного перечня. Из 152-ФЗ и приказов ФСТЭК (например, приказ №21) выбрать 5-7 пунктов, по которым регуляторы спрашивают в первую очередь и которые лежат на поверхности. Чаще всего это: наличие Перечня информационных систем, Модели угроз, Положения об СМИБ, Приказа о назначении ответственного.
• Создание черновиков этих документов. Не идеальные многостраничные документы, а заполненные шаблоны. Модель угроз может быть составлена по упрощённой методике ФСТЭК для ИС 4-го уровня. Цель — иметь на руках документы, которые можно предъявить на проверке как свидетельство того, что работа начата и ведётся.

Четвертый месяц: интеграция и первые испытания

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

• Проведение первой «прогонки». Если это процесс инцидентов — организовать учебную тревогу: симуляцию фишинговой рассылки и проверку реакции. Если процесс контроля доступа — провести реальную ревизию учётных записей в одной тестовой системе и выполнить процедуру отзыва лишних прав.
• Сбор прямой обратной связи. Первая реализация всегда будет сырой. Важно собрать мнения всех участников: что было неудобно, что не работало, что отнимало слишком много времени. Не через формальные опросы, а в личных беседах.
• Мини-корректировка. На основе обратной связи внести точечные изменения. Например, добавить в канал для инцидентов шаблон сообщения с обязательными полями (дата, система, описание), упростить форму запроса на доступ, дополнить шаблон документа новым разделом.

Пятый месяц: расширение и формализация

Рабочий процесс теперь нужно немного расширить и начать его формализовать, но без фанатизма.

• Добавление одного связанного подпроцесса. Не усложнять основной, а добавить смежную функцию. Если основной процесс — реагирование на инциденты, добавить подпроцесс расследования причин (root cause analysis) в виде простого шаблона отчёта. Если основной процесс — контроль доступа, добавить подпроцесс ежегодного пересмотра прав для ключевых ролей.
• Создание первых лёгких документов. Не политики, а инструкции или рабочие регламенты на 2-3 страницы. Например, «Инструкция по сообщению об инциденте ИБ» с картинками или «Порядок предоставления административного доступа к системам». Эти документы должны быть написаны так, чтобы их мог понять и использовать любой сотрудник, а не только специалист по ИБ.
• Краткое обучение ключевых пользователей. Провести короткий брифинг (15-20 минут) для руководителей отделов или системных администраторов, которые будут основными пользователями нового процесса. Цель — чтобы процесс использовался, а не существовал только на бумаге.

Шестой месяц: оценка результата и новый горизонт

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

• Оценка жизнеспособности. Проходит по трём практическим критериям:
  1. Процесс работает без сбоев? Инциденты обрабатываются за разумное время, доступ предоставляется по правилам, документы актуальны и готовы к запросу.
  2. Процесс приносит измеримую пользу? Сократилось ли время простоя из-за инцидентов? Уменьшилось ли количество учётных записей с избыточными правами? Была ли успешно пройдена какая-либо проверка?
  3. Процесс устойчив? Можно ли его поддерживать и развивать силами текущей команды с текущим бюджетом, или он уже требует дополнительных ресурсов?
• Определение следующего вектора. Если первый вектор успешно реализован и стал частью рутины, теперь можно выбирать следующий, опираясь на накопленные данные. Например, после создания системы реагирования логичным следующим шагом становится управление уязвимостями на основе данных о расследованных инцидентах.
• Создание реалистичного плана на следующие 6 месяцев. На основе полученного опыта (сколько времени реально ушло, какие были трудности) разрабатывается план второго этапа. Он должен быть таким же сфокусированным на одном векторе, но уже с учётом интеграции с ранее созданными процессами.

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