Совет директоров одобряет закупку EDR, PAM или защиты почты быстрее, чем строчку в бюджете на обучение команды, которая с этим продуктом будет работать. Логика понятна: продукт — это актив на балансе, а обучение выглядит статьей расходов без очевидной отдачи. На практике все наоборот. Продукт, который никто не умеет использовать до конца, простаивает в режиме коробки с настройками по умолчанию, а разбор инцидента необученной командой стоит организации больше, чем подготовка смены к этому инциденту заранее.
Эта статья — про то, как считать реальную стоимость необученного персонала в терминах, понятных финансовому директору и совету, а не только специалисту по безопасности, и как построить программу подготовки, которая эту стоимость снижает предсказуемо, а не разово.
Что такое экономика обучения персонала в ИБ
Экономика обучения персонала — это сопоставление двух статей затрат: стоимости подготовки специалистов к работе с конкретными средствами защиты и процессами реагирования против стоимости того, что происходит, когда неподготовленная команда сталкивается с реальным инцidentом. Это не разовое сравнение цены курса с ценой лицензии — это сравнение денежного эквивалента риска, который остается непокрытым, если люди не умеют пользоваться уже купленными инструментами.
Ключевая мысль простая и часто упускается при планировании бюджета: сама по себе закупка средства защиты не снижает риск. Риск снижает связка «продукт плюс обученный человек, который на него реагирует». Без второй части первая превращается в статью расходов без защитного эффекта — лицензия оплачена, а поверхность атаки не сократилась, потому что алерты не разбираются, а функции продукта не включены за пределами базовой настройки.
Из чего складывается стоимость инцидента, который разбирает необученная команда
Когда инцидент попадает на необученную команду, стоимость набирается из нескольких источников одновременно, и большинство из них не видны в моменте закупки средства защиты.
Простой процессов. Пока инцидент не локализован, затронутые системы либо продолжают работать под риском, либо останавливаются вручную из осторожности — оба варианта стоят организации рабочего времени и репутации перед внутренними заказчиками.
Ручной разбор вместо процедуры. Аналитик без наработанного алгоритма реагирования тратит время не на само расследование, а на то, чтобы понять, с чего начать: какие данные смотреть первыми, какой интерфейс продукта за что отвечает, кому эскалировать. Это время не создает защитной ценности — оно уходит на компенсацию пробела в подготовке.
Восстановление вместо предотвращения. Если инцидент не остановлен на ранней стадии — потому что связка сработала поздно или не сработала вовсе, — организация переходит из режима «расследовать» в режим «восстанавливать»: пересобирать системы, менять учетные данные, проверять целостность данных. Восстановление системно дороже локализации на раннем этапе.
Отвлечение смежных команд. Инцидент, который не удается закрыть силами дежурной смены, вытягивает в разбор архитекторов, инженеров инфраструктуры, а иногда и руководителей — людей, чье время стоит организации дороже времени штатного аналитика и которые в этот момент не занимаются своими прямыми задачами.
Регуляторные и репутационные последствия. Часть инцидентов требует уведомления регулятора или партнеров, разбора причин перед аудитом, объяснений перед клиентами. Скорость и качество этого разбора напрямую зависят от того, есть ли у команды привычка фиксировать действия и выводы в процессе реагирования, а не восстанавливать хронологию постфактум.
Ни один из этих пунктов не требует придуманной статистики, чтобы быть верным: достаточно сопоставить время дежурной смены, потраченное на подготовленный разбор по алгоритму, с временем, которое уходит на то же самое без алгоритма и без уверенного владения интерфейсом продукта. Разница всегда в пользу подготовленной команды, и она растет вместе с масштабом инцидента.
Почему необученная команда обесценивает уже купленные средства защиты
Средство защиты — это не автономный агент, который сам принимает решения за организацию. Даже самый зрелый продукт нуждается в человеке, который настраивает политики под конкретную инфраструктуру, разбирает срабатывания и включает функции сверх коробочного минимума. Разрыв между «продукт куплен» и «продукт защищает» закрывается только подготовленным персоналом.
Три типичных сценария, в которых уже оплаченная защита не приносит отдачи:
- Продукт настроен по умолчанию и таким остается годами. Команда прошла базовый онбординг от вендора, включила установку, но не углублялась в тонкую настройку политик под собственную инфраструктуру — потому что этому никто не учил отдельно.
- Алерты копятся, а не разбираются. Продукт генерирует срабатывания, но дежурная смена физически не успевает и не умеет их приоритизировать, поэтому значимые сигналы тонут в потоке несущественных.
- Функции продукта, которые требуют экспертизы, остаются выключенными. Расширенные сценарии реагирования, интеграции с другими системами, проактивный поиск угроз — все это существует в продукте, но не используется, потому что команда не обучена именно этим сценариям, а не базовой установке.
Здесь стоит явно разделить два продукта организации: сам инструмент — например, EDR как класс решений для конечных точек — и человека, который с ним работает. Статья «Типовые ошибки внедрения EDR» фиксирует ту же закономерность на конкретном классе продукта: значительная часть внедрений буксует не из-за архитектуры решения, а из-за того, что команда не прошла путь от установки до уверенной эксплуатации. То же самое относится к PAM, защите почты, SD-WAN и любому другому классу средств защиты — продукт без обученного оператора работает на часть своей проектной эффективности.
Чем практика на стенде отличается от лекции и вебинара
Лекция и вебинар передают знание — что делает продукт, зачем нужна та или иная функция, как выглядит архитектура решения. Это необходимый, но не достаточный уровень подготовки. Знание о том, как работает функция, и умение применить ее под давлением реального инцидента — разные навыки, и второй не формируется прослушиванием.
Навык закрепляется повторением на реальном интерфейсе, а не пересказом теории. Разница проявляется в конкретных вещах:
- После лекции специалист помнит, что в продукте есть функция ретроспективного поиска по телеметрии. После практики на стенде он помнит, в каком меню она находится, какие параметры запроса нужно указать и сколько шагов отделяет постановку вопроса от ответа — потому что уже проходил этот путь руками, а не наблюдал за демонстрацией.
- Лекция описывает типовой сценарий атаки в общих терминах. Практика на изолированном стенде показывает, как этот сценарий выглядит в интерфейсе конкретного продукта: что именно подсвечивается как аномалия, куда смотреть первым, какая последовательность действий сокращает время реагирования.
- Вебинар одинаков для всех участников и не проверяет, усвоил ли конкретный человек материал. Практика на стенде дает результат, который можно предъявить: разобранный кейс, зафиксированные шаги реагирования, повторяемый результат при повторном прохождении.
Изолированный стенд важен именно потому, что на нем можно безопасно ошибиться. Специалист, который тренируется на реальной боевой инфраструктуре, ограничен в действиях страхом сломать что-то важное — и поэтому избегает рискованных, но обучающих сценариев. На изолированном стенде это ограничение снимается: можно довести сценарий реагирования до конца, посмотреть, что происходит при неправильном решении, и повторить с исправлением.
Как выстроить программу обучения: роли и уровни
Программа обучения работает, когда она построена вокруг ролей, а не вокруг абстрактного «развития навыков по ИБ». У разных ролей разная глубина погружения в продукт и разные рабочие задачи, поэтому единый курс «для всех» почти всегда закрывает потребность только частично.
| Роль | Что нужно уметь | Типичный формат курса |
|---|---|---|
| Архитектор | Спроектировать внедрение под инфраструктуру, оценить архитектурные компромиссы, выбрать режим развертывания | Углубленный курс проектирования (например, по PAM — «Проектирование и внедрение BI.ZONE PAM») |
| Инженер | Настроить продукт, интегрировать с существующими системами, поддерживать в эксплуатации | Инженерный курс с практикой конфигурирования |
| Оператор / аналитик | Работать с продуктом ежедневно: разбирать срабатывания, реагировать по алгоритму | Пользовательский курс с упором на рабочие сценарии, например «Работа с BI.ZONE EDR» |
| Продавец / пресейл | Понимать продукт достаточно глубоко, чтобы честно отвечать на вопросы заказчика и не обещать того, чего продукт не делает | Курс с акцентом на возможности и ограничения, например «Специалист по продажам BI.ZONE EDR» |
Порядок прохождения имеет значение. Логичная последовательность — сначала базовое понимание класса продукта (что это и зачем), затем ролевой курс под конкретную задачу, и только потом — специализация: расследование инцидентов, проактивный поиск угроз, администрирование сложных сценариев. Попытка сразу отправить новичка на продвинутый курс без базы дает худший результат, чем последовательное прохождение уровней, потому что продвинутый материал предполагает уже сформированный словарь понятий и уверенность в интерфейсе.
Отдельная тема — рост аналитика внутри роли, от начального уровня разбора типовых срабатываний до самостоятельного расследования сложных инцидентов и участия в проактивном поиске угроз. Этому посвящена статья «Как вырастить SOC-аналитика: программа от L1 до L2» — там разобраны конкретные этапы такого роста и то, как их измерять.
С чего начать, если бюджет на обучение утверждают впервые
Если в организации никогда не было отдельной строки на обучение персонала работе со средствами защиты, начинать стоит не с максимальной программы, а с минимально достаточной, которая уже дает измеримый эффект.
- Определите, какие продукты уже внедрены и кто formально за них отвечает. Часто оказывается, что «ответственный» — это человек, который проходил только вводную демонстрацию от вендора при закупке.
- Выберите одну роль и один продукт для первого цикла обучения, а не пытайтесь закрыть все сразу. Приоритет — продукт с наибольшим числом ежедневных срабатываний, требующих разбора: там разрыв между купленным и используемым обычно самый заметный.
- Договоритесь заранее, как будет проверяться результат. Обучение без критерия готовности превращается в формальность — сертификат о прохождении не равен умению работать со сменой в реальном времени.
- Запланируйте практику на изолированном стенде, а не только просмотр материалов. Курс без практической части закрывает только часть разрыва, о котором шла речь выше.
- Зафиксируйте программу как повторяющийся процесс, а не разовое мероприятие: новые сотрудники и обновления продукта требуют повторного прохождения актуальных модулей.
Как аргументировать бюджет: язык риска, а не язык курсов
Внутри службы безопасности легко обсуждать обучение в терминах курсов, модулей и часов. Перед советом директоров и финансовым директором этот язык работает хуже, чем язык риска и непрерывности бизнеса.
Сравните две формулировки одного и того же запроса:
- «Нужен бюджет на курс по EDR для трех аналитиков» — звучит как операционная просьба, которую легко отложить до следующего квартала.
- «Команда, которая сегодня разбирает инциденты в EDR, не проходила формализованной подготовки — это означает, что при реальном инциденте время локализации будет зависеть от того, кто именно окажется на смене, а не от процедуры» — это формулировка риска, понятная совету директоров, потому что она указывает на непредсказуемость, а не на нехватку компетенции как таковой.
Аргумент усиливается, если он привязан к уже сделанным инвестициям: «мы оплатили лицензию на продукт, который использует часть своих возможностей, потому что команда не обучена остальному» — это прямое указание на то, что бюджет на обучение защищает уже потраченные деньги, а не добавляет новую статью расходов поверх них.
Какие показатели предъявить как доказательство результата
Чтобы аргумент не оставался качественным утверждением, полезно заранее договориться, какие наблюдаемые показатели программа обучения должна улучшить, и фиксировать их до и после цикла подготовки — без привязки к абсолютным цифрам, которые у каждой организации свои.
- Время разбора типового обращения. Сокращается ли время от получения алерта до принятого решения после прохождения программы, при сравнении одной и той же смены до и после.
- Доля обращений, закрытых без эскалации на более опытного специалиста или на архитектора. Рост этой доли — прямой признак того, что базовый уровень команды поднялся.
- Готовность смены к дежурству. Может ли смена, заступающая на дежурство, самостоятельно пройти через типовой сценарий реагирования от начала до конца без обращения к документации на каждом шаге.
- Повторяемость решений. Приходят ли разные аналитики к сопоставимому решению по одному и тому же инциденту, или результат сильно зависит от того, кто именно дежурит.
Эти показатели не требуют выдуманной статистики отраслевых исследований — они измеряются внутри собственной организации, на собственных данных, и поэтому убедительнее любого внешнего бенчмарка.
Частые ошибки при построении обучения
Обучили одного человека вместо команды. Организация отправляет на курс единственного «ответственного» сотрудника, и вся экспертиза концентрируется в одной точке отказа: отпуск, увольнение или просто загруженность этого человека — и продукт снова эксплуатируется по остаточному принципу.
Обучение идет после внедрения, а не параллельно с ним. Продукт закупают, разворачивают, начинают эксплуатировать — и только когда накапливаются проблемы, вспоминают про обучение. Правильный порядок — обучение параллельно с внедрением, чтобы команда участвовала в настройке осознанно, а не разбиралась в уже принятых архитектурных решениях постфактум.
Курс выбран без практической части. Формат «посмотреть записи вебинаров» экономит бюджет в моменте, но не закрывает разрыв между знанием и умением, о котором шла речь выше.
Нет проверки результата после обучения. Сертификат о прохождении курса — не то же самое, что подтвержденная готовность работать со сменой. Без отдельного шага проверки организация не знает, действительно ли программа сработала.
Обучение не повторяется. Продукты обновляются, появляются новые сценарии атак, приходят новые сотрудники — разовый цикл подготовки устаревает быстрее, чем кажется на старте.
Как проверить себя: короткий чек-лист перед защитой программы
Прежде чем выносить бюджет на обучение персонала на согласование, полезно честно ответить на несколько вопросов:
- Знаете ли вы, сколько человек в организации умеют работать с каждым внедренным средством защиты не на уровне демонстрации, а на уровне самостоятельного дежурства?
- Есть ли у вас критерий, по которому вы отличаете «прошел курс» от «готов к реальной смене»?
- Проходила ли команда практику на изолированном стенде, где можно ошибиться без риска для боевой инфраструктуры, или обучение ограничилось просмотром материалов?
- Что произойдет, если единственный обученный специалист уйдет из компании на следующей неделе — останется ли экспертиза в команде?
- Можете ли вы сформулировать запрос на бюджет в терминах риска и непрерывности, а не только в терминах часов курса?
Если хотя бы на два из этих вопросов ответ неуверенный — это сигнал, что программа обучения нуждается в пересмотре раньше, чем в закупке следующего средства защиты.
Куда идти учиться
Экономика обучения работает только тогда, когда за решением следует конкретная программа с практикой на реальном интерфейсе, а не общая рекомендация «обучать команду». BI.ZONE Cybersecurity Labs дает для этого ролевые курсы с практикой на изолированных стендах — по каждому классу продукта: EDR, PAM, защита почты, SD-WAN, защита DNS, GRC и модель нулевого доверия.
Для роли, которая ежедневно разбирает срабатывания и ведет дежурство, стартовая точка — курс «Работа с BI.ZONE EDR»: он дает практику именно с теми задачами, из-за отсутствия которых чаще всего обесценивается уже купленный продукт. Дальнейший рост той же роли — от разбора типовых срабатываний до самостоятельного расследования сложных инцидентов — описан в статье «Как вырастить SOC-аналитика: программа от L1 до L2». Для команд, которые проектируют внедрение, есть отдельные архитекторские курсы, а для тех, кто продает продукт заказчику, — курсы с акцентом на возможности и честные ограничения решения.
Практика на стенде — самый быстрый способ проверить тезис этой статьи на собственном опыте: пройти сценарий реагирования от первого сигнала до закрытия инцидента и увидеть разницу между «продукт куплен» и «продукт защищает» своими руками, а не в теории.