«Мы требуем проактивности, но платим за исправление инцидентов. Ищем уязвимости в чужих продуктах, но боимся внедрять новые технологии в своих. Пишем политики на будущее, а отчитываемся за прошлое. Эта шизофрения — не ошибка отдельных специалистов, а системный конфликт в самой модели регуляторной безопасности.»
Разрыв между теорией и практикой
Проактивная защита, это предотвращение атак до их начала. Сканирование уязвимостей, безопасная разработка, моделирование угроз, обучение сотрудников. В теории она дёшева и эффективна. Реактивное реагирование, это действия после инцидента: расследование, восстановление, исправление ошибок. В теории это дорого и означает провал. На бумаге выбор очевиден. На практике всё наоборот.
Бюджеты на информацион
Реактивность имеет понятную окупаемость. Затраты на расследование и восстановление можно посчитать, ущерб — хотя бы примерно оценить. Проактивные же инвестиции измеряются в «ненаступивших инцидентах» — метрике, которую невозможно представить в отчёте. Как доказать, что тренинг по фишингу спас компанию от потери миллионов, если атака просто не произошла? В лучшем случае вас похвалят за тишину. В худшем — спросят, на что тратятся деньги.
Цикл регуляторного отставания
Государственные требования, такие как 152-ФЗ и приказы ФСТЭК, формально поощряют проактивный подход. Требуется оценка угроз, классификация информации, внедрение средств защиты. Но сама механика проверок и отчётности заставляет играть в догонялки.
Регуляторные акты часто пишутся как реакция на уже случившиеся громкие инциденты. Они фиксируют вчерашние угрозы и методы защиты. К моменту, когда документ вступает в силу и организации его внедряют, ландшафт угроз уже изменился. Вы строите укреплённую стену, пока противник учится летать.
Система аттестации объектов информатизации по требованиям безопасности — яркий пример. Она проверяет соответствие формальным, заранее известным критериям. Команда месяцами готовится к проверке, «причёсывает» документы и настраивает системы под конкретный чек-лист. Это не проактивная защита от реальных угроз, это реактивная подготовка к конкретному событию под названием «проверка». После успешного прохождения аттестации возникает иллюзия безопасности, которая часто расслабляет.
Психология «тушения пожаров»
В культуре многих IT-отделов и служб безопасности ценятся «герои», способные ночью приехать в офис и вручную отбить DDoS-атаку или восстановить данные с резервных копий. Эти истории становятся легендами. Систематическая, рутинная работа по обновлению патчей, ревизии правил файрвола или аудиту прав доступа не приносит славы. Она невидима.
Это создаёт перекос в мотивации. Молодой специалист видит, что карьерный рост и признание получает не тот, кто не допустил проблем, а тот, кто эффектно их решил. Система поощряет существование проблем, чтобы было что решать. Проактивная работа, если она выполнена идеально, приводит к тому, что отдел безопасности выглядит как затратный, не приносящий очевидной пользы центр расходов.
Технический долг безопасности
Аналогия с техническим долгом в разработке идеально ложится на безопасность. Каждый раз, когда для быстрого запуска проекта отключается система контроля цело
Но бизнес-логика поощряет взятие кредитов. «Выпусти фичу быстрее конкурентов, а безопасность допишем потом». «Пока нет проблем, нечего и оптимизировать». Долг копится, пока не случится дефолт в виде кризиса. Тогда выделяются экстренные средства (реакция), проблема локально латается, а системные причины остаются. Цикл повторяется.
Как сдвинуться с мёртвой точки
Выход из ловушки между проактивностью и реакцией — не в выборе одной крайности, а в изменении системы измерений и управления рисками.
Перевести проактивность в измеримые метрики
Вместо отчётов о «ненаступивших инцидентах» нужны показатели, отражающие состояние защиты:
- Время между выходом патча и его установкой на критичных системах (SLA на обновления).
- Процент сотрудников, прошедших проверку на знание политик безопасности (не просто обучение, а тестирование).
- Количество обнаруженных и устранённых уязвимостей на этапе разработки (статика/динамика).
- Время на восстановление работы тестового стенда после имитации инцидента (показатель готовности, а не реактивности).
Эти данные нужно встраивать в регулярные отчёты для руководства наряду с финансовыми показателями.
Использовать регуляторные требования как основу, а не как потолок
Соответствие 152-ФЗ, это обязательный минимум, точка отсчёта, а не конечная цель. На его базе можно строить более зрелую систему управления рисками. Например, карты угроз, требуемые регулятором, стоит развить до полноценной модели рисков с привязкой к бизнес-процессам и расчётом возможного ущерба. Это превратит формальный документ в инструмент для приоритизации проактивных инвестиций.
Легализовать и запланировать «реактивность»
Полностью избежать инцидентов невозможно. Поэтому часть ресурсов должна быть зарезервирована и запланирована именно на реагирование. Это включает:
- Регулярные учебные тревоги и киберучения на выделенном контуре.
- Бюджет на внешних экспертов для расследования сложных инцидентов.
- Время сотрудников на анализ произошеccccденных инцидентов и внесение изменений в конфигурации для предотвращения повторения.
Когда реактивные меры становятся плановой работой, они перестают быть противопо
Итог: безопасность как процесс, а не состояние
Застревание между проактивной защитой и реактивным реагированием — симптом того, что безопасность воспринимается как состояние, которое можно достичь («мы соответствуем требованиям») и поддерживать. В реальности это бесконечный итеративный процесс, где проактивные и реактивные фазы сменяют друг друга.
Проактивность без обратной связи от реальных инцидентов становится догматичной и оторванной от жизни. Реагирование без системных выводов — бегом на месте. Задача — замкнуть этот круг: каждое реактивное действие должно порождать проактивное улучшение, а каждая проактивная мера — проверяться на устойчивость через плановое моделирование угроз.
Только отказавшись от поиска магической точки «полной защищённости» и приняв цикличность работы, можно выйти из шизофреничного разрыва и начать двигаться вперёд.