Идея «у нас есть безопасник — значит, ИБ закрыта» появляется по двум причинам:
1. безопасность часто воспринимают как набор “настроек” (поставить антивирус, закрыть порты, написать пару регламентов);
2. результат ИБ трудно увидеть сразу — пока не случился инцидент.
Но отдел информационной безопасности (ИБ) — это не “один человек с доступом к SIEM”, а система ролей, процессов и ответственности. И вот почему один специалист почти никогда не может заменить эту систему.
1) Отдел ИБ — это разные функции, которые конфликтуют по времени и приоритетам
Если упростить, отдел ИБ делает сразу несколько “работ”, которые в реальности живут параллельно:
Управление (governance)
● политика и правила (как должно быть);
● управление рисками (что важнее защищать);
● требования регуляторов/клиентов, аудит, доказательства выполнения.
Инженерия (security engineering)
● проектирование: сегментация, доступы, криптография, резервирование;
● безопасные конфигурации, “эталонные” настройки;
● участие в проектах до внедрения (а не после).
Операции (security operations)
● мониторинг событий (логи, корреляции, расследования);
● реагирование на инциденты;
● управление уязвимостями и обновлениями (вместе с ИТ).
Люди и процессы
● обучение сотрудников, фишинг-тренировки, культура;
● контроль подрядчиков и поставщиков;
● разбор причин инцидентов и улучшения.
Один человек физически не может одинаково хорошо быть и “архитектором”, и “дежурной сменой 24/7”, и “аудитором”, и “методологом”, и “инженером внедрения”.
2) Безопасность требует специализаций (и это нормально)
ИБ давно стала “командным видом спорта”. Даже в небольших компаниях задачи разной природы:
● GRC (политики, риски, комплаенс, аудиты) — это про формализацию и доказательства.
● AppSec (безопасность приложений) — это про SDLC, код, тестирование, DevSecOps.
● SecOps/SOC — это про мониторинг, расследования, реагирование.
● Infra/Cloud security — это про сети, IAM (управление доступом), конфигурации, контейнеры, облака.
Когда это “всё в одном лице”, качество неизбежно проваливается где-то: либо регламенты есть, а технически дыряво; либо технически “крутят гайки”, а доказать соответствие и управлять рисками некому; либо человек постоянно тушит пожары и никогда не успевает сделать базовую профилактику.
3) Один человек не даёт устойчивости: ключевой риск — “single point of failure”
У отдела ИБ есть важное свойство: устойчивость. А у “одного безопасника” есть уязвимости:
● Отпуск/болезнь/увольнение = безопасность встала.
● Ключевые знания в голове (пароли, схемы, исключения, “почему так настроено”) = техдолг и риск.
● Выгорание: безопасность — это бесконечный поток задач с высокой ответственностью и размытым “готово”.
В реальном управлении рисками это называется просто: единственная точка отказа.
4) Нужны разделение полномочий и контроль — одному человеку это сделать сложно
В зрелой модели есть базовые принципы:
● разделение обязанностей (тот, кто настраивает, не должен единолично “проверять себя”);
● независимость контроля (аудит/проверки не должны зависеть от одного исполнителя);
● минимизация конфликта интересов (особенно когда ИБ подчиняется ИТ и вынуждена “согласовывать” риски ради сроков).
Если один человек одновременно пишет правила, внедряет, выдаёт исключения и сам себя проверяет — это не контроль, а самоотчёт.
5) “Отдел ИБ” — это ещё и управление ожиданиями бизнеса
Бизнес обычно хочет простого: “чтобы не взломали” и “чтобы нас не штрафанули”.
Отдел ИБ превращает это в понятные договорённости:
● какие риски принимаем, какие снижаем;
● что делаем в первую очередь и почему;
● какие метрики считаем (время закрытия уязвимостей, доля MFA, покрытие логированием, RTO/RPO резервного копирования и т.д.);
● кто владелец каждого риска (ИБ не может “владеть” всеми проблемами одна).
Один специалист чаще оказывается в роли “вечного виноватого”: у него нет ресурсов, но ожидания как у полноценного подразделения.
6) Типичный сценарий провала “одиночного ИБ”: пожар вместо системы
Когда ИБ одна, она почти всегда превращается в “реактивную” функцию:
● срочно закрыть инцидент;
● срочно пройти аудит;
● срочно внедрить средство защиты;
● срочно согласовать доступ.
А профилактика — управление уязвимостями, минимизация прав, сегментация, контроль конфигураций, обучение персонала — откладывается “на потом”.
В итоге безопасность выглядит как бесконечная гонка, а не как управляемая программа.
7) Что делать, если ИБ реально один человек (и бюджет ограничен)
Иногда это объективная реальность. Тогда цель — не “притворяться отделом”, а выстроить систему через приоритизацию и опору на ИТ/подрядчиков.
Практичный минимум:
1. Зафиксировать модель ответственности (RACI)
Кто владелец активов, кто отвечает за устранение уязвимостей, кто утверждает исключения.
2. Собрать базовую “гигиену”
● инвентаризация активов;
● MFA (многофакторная аутентификация) на ключевые сервисы;
● резервное копирование + регулярная проверка восстановления;
● управление обновлениями;
● минимизация прав (админ-доступ строго по необходимости);
● журналирование критичных систем и понятный порядок реагирования.
3. Снять “24/7” с одного человека
Если нужна круглосуточная реакция — подключать внешний SOC/MSSP (аутсорсинг мониторинга и реагирования) или хотя бы дежурства ИТ по простому регламенту.
4. Стандартизировать
Шаблоны политик, чек-листы, типовые решения, “эталонные конфигурации” — чтобы не изобретать заново каждый раз.
Так один специалист становится координатором безопасности, а не “человеком, который должен делать всё”.
Вместо вывода
Если в компании один ИБ-специалист, это не “плохая ИБ” — это стартовая стадия зрелости. Плохо другое: когда от одного человека ждут результат как от отдела.
Проверьте себя по трём вопросам:
1. Есть ли у вас распределённая ответственность (не всё на ИБ)?
2. Есть ли процессы, которые работают без героя (документы, регламенты, шаблоны, роли)?
3. Есть ли ресурс на операционку и развитие (а не только на пожары)?
©Автор-эксперт: Владислав Халяпин