Больше новостей об IT в Telegram канале «Код Дурова»
Дефицит специалистов по информационной безопасности перестал быть только кадровой проблемой. Для компаний он всё чаще превращается в вопрос устойчивости: сможет ли защита работать без постоянного ручного контроля, без зависимости от одного-двух сильных сотрудников и без режима бесконечного «тушения пожаров».
На рынке по-прежнему не хватает квалифицированных ИБ-кадров, но сама проблема глубже. Во многих компаниях архитектура защиты исторически строилась так, будто рядом всегда будет большая команда узких специалистов. Один отвечает за сетевую безопасность, другой за доступы, третий за мониторинг, четвёртый за расследование инцидентов, пятый помнит старые исключения и нестандартные настройки. Пока такая команда стабильна, система держится. Но стоит людям уйти, перегореть или переключиться на другие задачи, как защита быстро теряет управляемость.
Для руководителей это означает неприятный вывод: нехватку людей нельзя бесконечно компенсировать наймом. Если сама архитектура требует постоянного ручного сопровождения, новый специалист не решит проблему, а просто станет ещё одним участником сложной и плохо формализованной системы.
«Главная ошибка компаний в условиях кадрового дефицита — пытаться закрыть архитектурные проблемы людьми. Если защита держится на ручных процессах, устной памяти сотрудников и нестандартных связках между системами, она уязвима независимо от того, сколько инструментов закуплено. При первой же смене команды такая модель начинает проседать», — отметила Ольга Луценко, эксперт UDV Group.
Особенно уязвимы решения, которые требуют постоянной ручной настройки. Это касается сложных политик межсетевого экранирования, фрагментированного управления доступами, разрозненного мониторинга, нестандартных интеграций и процессов, которые не описаны в регламентах. В таких системах любое изменение становится зависимым от конкретного человека: кто-то должен помнить, зачем создавалось правило, почему был выдан доступ, как работает скрипт и что произойдёт при отключении одного из узлов.
Проблема усугубляется, когда документация устарела или существует формально. Новый сотрудник приходит не в понятную архитектуру, а в набор исторических решений, исключений и временных обходов, которые давно стали постоянными. В такой среде даже сильный специалист тратит время не на развитие защиты, а на расшифровку того, как она устроена.
Ещё один источник риска — накопление исключений. Бизнесу часто нужны быстрые изменения: открыть доступ, подключить подрядчика, дать расширенные права, временно обойти стандартную процедуру. В моменте такие решения могут быть оправданными. Но если исключения не фиксируются, не пересматриваются и не имеют срока действия, архитектура постепенно теряет логику. Через несколько лет разобраться в ней может только тот, кто сам принимал эти решения.
В условиях кадрового дефицита это становится критичным. Сложность уже нельзя перекрыть числом сотрудников. Компании приходится строить защиту так, чтобы она была понятной, повторяемой и воспроизводимой даже при смене команды. Для этого архитектура должна быть простой не в смысле примитивной, а в смысле объяснимой: новый специалист должен быстро понимать, как устроены сегменты, где проходят границы ответственности, какие политики действуют и какие действия автоматизированы.
«Устойчивая ИБ-архитектура должна быть рассчитана не на героизм отдельных сотрудников, а на предсказуемую работу обычной команды. Если систему невозможно объяснить новому специалисту, если её нельзя воспроизвести по документации, если каждое изменение требует личной памяти конкретного человека, это уже не зрелая защита, а скрытый операционный риск», — добавила Ольга Луценко, эксперт UDV Group.
Отдельная проблема связана с автоматизацией. Компании часто воспринимают её как способ заменить людей, но автоматизация не исправляет хаос. Если процесс плохо описан, содержит множество исключений и зависит от ручных согласований, его автоматизация только закрепит беспорядок в техническом контуре. Поэтому начинать нужно не с покупки новых инструментов, а с упрощения логики: убрать лишние шаги, формализовать типовые сценарии, определить правила принятия решений и только после этого автоматизировать повторяющиеся операции.
Наибольшую нагрузку на ИБ-команды обычно создают реагирование на инциденты, разбор потока событий, подготовка отчётности, управление доступами и сопровождение изменений. Именно эти процессы должны становиться приоритетом для автоматизации. Но автоматизировать нужно не всё подряд, а только те операции, которые повторяются, хорошо описаны и имеют понятный результат для управления рисками.
Например, первичная корреляция событий, типовые действия по изоляции узла, помещение файла в карантин, сбор контекста по инциденту, формирование управленческих метрик и регулярной отчётности не должны полностью зависеть от ручной работы. ИБ-специалисты должны заниматься анализом сложных случаев и развитием архитектуры, а не обслуживать поток однотипных операций.
При этом закупка дополнительных инструментов не всегда снижает нагрузку. На практике бывает наоборот: каждый новый продукт требует внедрения, настройки, интеграции, отдельного администрирования и анализа собственного потока событий. Если решения не встроены в единую модель управления, команда начинает обслуживать инструменты вместо того, чтобы управлять безопасностью.
Для ЛПР здесь важен принципиальный сдвиг в оценке ИБ. Смотреть нужно не только на то, какие классы решений есть в компании, а на то, как они работают вместе. Есть ли единая логика сегментации, понятная модель доступа, централизованный сбор событий, актуальная документация, автоматизированные сценарии реагирования, измеримые показатели эффективности. Без этого даже развитый набор продуктов может оставаться сложной и хрупкой конструкцией.
Ключевые метрики тоже должны быть управленческими, а не формальными. Компании важно понимать, сокращается ли время реакции на инциденты, уменьшается ли количество ручных изменений, быстрее ли новый сотрудник входит в работу, снижается ли зависимость от отдельных специалистов, становится ли проще контролировать доступы и изменения. Если внедрение ИБ-инструмента не влияет на эти показатели, его ценность для устойчивости бизнеса ограничена.
«Для руководителя показатель зрелости ИБ сегодня — не количество внедрённых решений, а способность системы работать при ограниченной команде. Хорошая архитектура снижает зависимость от персоналий, делает процессы повторяемыми и позволяет специалистам заниматься действительно критичными задачами, а не постоянно компенсировать сложность ручным трудом», — подчеркнула Ольга Луценко, эксперт UDV Group.
В ближайшие годы кадровый дефицит в ИБ вряд ли исчезнет. Поэтому компаниям придётся проектировать защиту с учётом этой реальности. Ставка на одного незаменимого эксперта или постоянное расширение команды становится всё менее надёжной стратегией. Более устойчивый подход — строить архитектуру, которая выдерживает смену людей, рост нагрузки и изменение инфраструктуры.
Для бизнеса это означает дополнительные усилия на старте: нужно пересмотреть процессы, актуализировать документацию, убрать избыточную сложность, стандартизировать управление и аккуратно внедрить автоматизацию. Но в долгосрочной перспективе такая работа снижает операционные риски. Компания получает не просто набор средств защиты, а управляемую систему, которая сохраняет эффективность даже тогда, когда ресурсов меньше, чем хотелось бы.
Больше новостей об IT в Telegram канале «Код Дурова»