«Наивно думать, что сопротивление бизнеса ИБ, это просто глупость менеджеров. Часто это рациональная реакция на систему, которая создаёт препятствия, не предлагая ясных преимуществ. Преодолеть это можно только перестав быть ‘инспектором’ и начав говорить на языке рисков и возможностей.»
Почему ИБ воспринимается как враг, а не как партнёр
Сценарий повторяется раз за разом: новый проект проходит все стадии согласования, получает финансирование, и в финале упирается в отдел информационной безопасности. Специалисты ИБ выдают длинный список требований — установить дополнительные средства защиты, изменить архитектуру, провести дорогостоящую аттестацию. Сроки срываются, бюджет растёт, команда разработки в ярости. Руководитель проекта задаёт резонный вопрос: «Вы что, вообще не хотите, чтобы бизнес работал?».
Это не единичный конфликт, а системная проблема. ИБ попадает в роль «врага прогресса» по нескольким ключевым причинам:
- Язык запретов, а не возможностей. Большинство взаимодействий строится вокруг слова «нельзя». Нельзя запустить систему без СЗИ. Нельзя использовать облако. Нельзя передавать данные. При этом редко объясняется, какие именно угрозы блокируются и какие есть альтернативные, более безопасные пути достичь бизнес-цели.
- Отрыв от бизнес-процессов. Требования часто навязываются постфактум, как досадная формальность в конце пути. Бизнес-подразделения не вовлечены в обсуждение рисков на ранних этапах, а специалисты ИБ слабо представляют себе, как на самом деле работает продажа, логистика или производство.
- Фокус на формальном соответствии, а не на реальной безопасности. Погоня за «галочками» для проверяющих органов (ФСТЭК, ФСБ) становится самоцелью. Средства защиты внедряются потому, что «так надо по приказу», а не потому, что они эффективно закрывают конкретные уязвимости бизнес-процесса. Это порождает цинизм с обеих сторон.
Результат предсказуем: бизнес начинает искать обходные пути. Запускают «пилоты» без согласования, используют личные облачные диски для рабочих файлов, договариваются с IT-администраторами «по-тихому». Так стихийно формируется теневая IT-инфраструктура, которая в десятки раз опаснее легальной, потому что она полностью выпадает из поля зрения ИБ.
Смена парадигмы: от контролёра к архитектору безопасности
Чтобы разорвать этот порочный круг, необходимо сменить саму роль. Отдел ИБ должен перестать быть последней инстанцией для визирования и превратиться в проектного консультанта, который включается в работу на самых ранних этапах.
1. Говорить на языке бизнеса: риски, а не угрозы
Бизнес-руководитель мыслит категориями выгоды, упущенной прибыли, репутационных потерь и штрафов. Фраза «существует угроза утечки через уязвимость Zero-day» для него — абстракция. Но та же ситуация, описанная как риск, звучит иначе: «Если мы запустим новый онлайн-сервис без сегментации сети и DDoS-защиты, в случае успешной атаки мы можем потерять до 40% выручки в пиковый день продаж и получить штраф от Роскомнадзора до 6 млн рублей за недоступность персональных данных. Вероятность такой атаки в нашей нише в этом году оценивается как высокая».
Такой подход требует от специалиста ИБ глубокого понимания не только технологий, но и финансовой модели проекта, договорных обязательств перед клиентами и регуляторного поля. Без этого диалог невозможен.
2. Внедрять Security by Design, а не Security as Gate
Принцип «безопасность по умолчанию» должен быть заложен в процессы с самого начала. Для этого ИБ-специалисты должны участвовать в проектных комитетах и agile-спринтах. Их задача — не сказать «нет» готовому решению, а помочь архитекторам и разработчикам выбрать изначально более безопасные опции.
- На этапе проектирования: совместно оценить риски разных архитектурных решений (монолит vs микросервисы, своё ЦОД vs облако). Предложить шаблоны безопасной конфигурации для стандартных задач.
- На этапе разработки: внедрить статический и динамический анализ кода (SAST/DAST) в CI/CD-конвейер, чтобы находить уязвимости до сборки, а не после внедрения.
- На этапе закупок: оценивать безопасность сторонних решений и сервисов до подписания контракта, а не после его исполнения.
Это превращает ИБ из препятствия в союзника, который помогает команде делать работу правильно с первого раза, экономя время и ресурсы на переделках.
Практические шаги: как выстроить партнёрские отношения
Теория бесполезна без конкретных действий. Вот что можно начать делать уже в следующем квартале.
| Что делает ИБ сейчас (как враг) | Что должно делать ИБ (как партнёр) | Конкретный первый шаг |
|---|---|---|
| Выдаёт список невыполнимых требований по 152-ФЗ в конце проекта. | Проводит workshop по защите ПДн на старте проектирования, предлагая несколько сценариев соответствия с разной стоимостью. | Разработать и согласовать с юристами и бизнес-подразделениями чек-лист «Безопасный старт проекта». Включить его в регламент инициации любого IT-проекта. |
| Запрещает использовать облачные сервисы. | Составляет и публикует реестр предварительно оцененных и одобренных облачных решений (SaaS, PaaS) с готовыми инструкциями по безопасной настройке. | Выбрать один критически важный для бизнеса сервис (например, CRM или корпоративный мессенджер), провести его риск-оценку и выпустить официальный меморандум о порядке его безопасного использования. |
| Требует от сотрудников проходить скучные ежегодные тесты по ИБ. | Внедряет программу непрерывного обучения на основе реальных инцидентов и фишинговых симуляций, адаптированную под разные роли (бухгалтерия, разработка, продажи). | Заменить один обязательный годовой курс на серию коротких (5-7 минут) видео-роликов, смоделированных на основе последних инцидентов в компании или в отрасли. Измерять эффективность не по проценту прошедших, а по снижению числа кликов по фишинговым письмам в симуляциях. |
| Работает в режиме «чёрного ящика», отчитываясь только о количестве blocked-атак. | Регулярно готовит отчёты для руководства на языке бизнес-рисков: «Наши меры позволили избежать потенциальных простоев производства на сумму X рублей» или «Инвестиции в DDoS-защиту окупились, так как мы отразили N атак в период распродаж». | К следующему квартальному отчёту добавить один слайд с переводом технических метрик (число предотвращённых атак, закрытых уязвимостей) в гипотетический финансовый ущерб, используя отраслевые данные о средних cost of breach. |
Измеримость успеха: не проценты закрытых уязвимостей, а скорость бизнеса
Ключевой показатель, по которому бизнес оценит новую роль ИБ,, это не снижение числа инцидентов (хотя это важно), а отсутствие задержек из-за вопросов безопасности. Если раньше согласование с ИБ добавляло к проекту две недели, а теперь — два дня, это прямое свидетельство эффективности.
Метрики должны измениться:
- Вместо: «100% проектов прошли проверку ИБ».
- На: «Среднее время на согласование архитектуры безопасности нового проекта сократилось с 14 до 3 дней».
- Вместо: «Проведено 10 проверок отделов».
- На: «Количество запросов от бизнес-подразделений на консультацию по безопасности на ранних этапах проектов выросло на 50%».
Когда бизнес-руководители начинают сами приглашать специалистов по безопасности на планирование, это главный знак того, что ИБ превратилось из врага в ценного партнёра. Безопасность перестаёт быть проблемой, которую надо обойти, и становится конкурентным преимуществом, которое позволяет компании двигаться быстрее и с меньшими рисками.
Итоговая трансформация, это не про «сделать послабления» или «закрыть глаза на нарушения». Это про построение системы, в которой безопасность не противоречит развитию, а является его неотъемлемой частью. В условиях растущего давления регуляторов и изощрённости атак такая модель — не опция, а необходимость для выживания и роста.