Почему один ИБ-специалист ≠ отдел ИБ

Идея «у нас есть безопасник — значит, ИБ закрыта» появляется по двум причинам:

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. Есть ли ресурс на операционку и развитие (а не только на пожары)?